Detección de navegadores headless: cómo te detectan

```html

¿Has cambiado tu proxy y configurado una huella digital independiente para cada perfil, pero sigues encontrando verificaciones adicionales o restricciones de acceso a sitios web? Esto indica que gestionar un entorno de navegador implica mucho más que modificar unos cuantos ajustes. En cada visita, los sitios web pueden analizar distintos tipos de datos para determinar si el visitante es una persona real o un bot.

Entonces, ¿cómo funcionan las técnicas de detección de bots y pueden detectarse los navegadores antidetect? Este artículo explica estos mecanismos y los factores que influyen en la forma en que los sitios web identifican la actividad automatizada del navegador.

1. ¿Qué es un navegador headless y en qué se diferencia de un navegador normal?

Un navegador headless es un navegador que se ejecuta sin una interfaz gráfica visible y que suele controlarse mediante código con herramientas como Puppeteer, Playwright o Selenium. Aun así, puede cargar páginas web, ejecutar JavaScript y enviar solicitudes igual que un navegador normal. Por eso, los sitios web deben examinar las diferencias en el entorno y el funcionamiento del navegador para identificar el tráfico automatizado.

1.1. ¿Cuál es la diferencia entre headless, headful y automatización?

Para entender cómo detectan los sitios web los navegadores headless, primero debes distinguir dos conceptos: el modo de visualización y el método de control del navegador. Headless describe si el navegador muestra una ventana visible, mientras que la automatización se refiere al control del navegador mediante scripts.

Estos tres escenarios habituales se pueden distinguir de la siguiente manera:

La clave es que headless no significa automatización. Un navegador con una interfaz visible también puede controlarse automáticamente mediante Puppeteer o Playwright. Por el contrario, la ausencia de una ventana visible no demuestra automáticamente que el navegador esté realizando actividades de bot.

Por ejemplo, cuando ejecutas Puppeteer en modo headful, Chrome sigue abriendo una ventana normal, pero sus acciones pueden realizarse mediante scripts. Por eso, los sitios web no se limitan a comprobar si el navegador tiene una interfaz gráfica. También pueden examinar señales relacionadas con la forma en que se controla el navegador.

1.2. ¿En qué se diferencian el nuevo Chrome headless y chrome-headless-shell?

Chrome headless ha experimentado varios cambios importantes a lo largo de sus distintas versiones. Antes, el modo headless utilizaba una implementación independiente que no compartía todo el código fuente con Chrome normal. Como resultado, el entorno headless presentaba ciertas diferencias que las herramientas de detección de bots podían utilizar como indicadores.

Actualmente, el nuevo modo headless se ha unificado con la implementación del modo headful normal. En concreto, a partir de Chrome 112, el modo headless utiliza el mismo código del navegador que Chrome normal, pero no crea una ventana visible. En Chrome 132, el antiguo modo headless se trasladó a un ejecutable independiente llamado chrome-headless-shell, distribuido a través de Chrome for Testing.

Al utilizar Puppeteer, puedes encontrar dos opciones:

• headless: true: ejecuta Chrome en el nuevo modo headless.
• headless: 'shell': ejecuta el archivo chrome-headless-shell con la antigua implementación headless.

Esta distinción es importante al investigar la detección de navegadores headless. Algunos tutoriales escritos durante la etapa del antiguo modo headless pueden basarse en características que ya no representan con precisión las versiones actuales de Chrome. Por eso, al revisar los resultados de las pruebas o la documentación técnica, debes comprobar la versión de Chrome y la configuración utilizada.

Los sitios web detectan principalmente los navegadores headless para distinguir a los usuarios legítimos del tráfico automatizado, como la recopilación de datos a gran escala, los intentos repetidos de adivinar contraseñas o los clics publicitarios falsos. Sin embargo, la detección no siempre provoca un bloqueo inmediato del acceso. Un sistema antibots puede evaluar otras señales antes de solicitar una verificación CAPTCHA o aplicar una restricción adecuada.

2. ¿Qué señales utilizan los sitios web para detectar navegadores headless?

Los sitios web detectan los navegadores headless combinando varios grupos de señales en lugar de depender de una sola característica. Los datos examinados pueden proceder de los encabezados HTTP, las propiedades de JavaScript, los protocolos de control del navegador, los entornos de los dispositivos, el comportamiento de interacción del usuario y las conexiones de red.

Cada grupo de señales revela un aspecto diferente del entorno de navegación. Por ejemplo, el User-Agent proporciona información sobre el navegador declarado, mientras que navigator.webdriver indica si el navegador está siendo controlado mediante automatización. Cuando varios datos no coinciden entre sí, los sitios web tienen más motivos para evaluar una visita como inusual.

2.1. Señales a nivel HTTP

Cuando visitas un sitio web, tu navegador envía encabezados HTTP que proporcionan al servidor cierta información sobre tu dispositivo y entorno de navegación. Los sitios web pueden analizar estos datos antes de realizar comprobaciones más detalladas mediante JavaScript.

Algunas de las señales que se examinan con frecuencia son:

• User-Agent que contiene HeadlessChrome: Algunas configuraciones de Chrome headless pueden enviar una cadena User-Agent que contiene HeadlessChrome. Los sitios web pueden leer este valor directamente desde las solicitudes del lado del servidor o mediante la propiedad navigator.userAgent del navegador. Sin embargo, esta cadena no aparece en todas las configuraciones headless, por lo que no puede utilizarse por sí sola para llegar a una conclusión.
• Client Hints incoherentes con User-Agent: Client Hints proporciona información adicional sobre la marca, la versión, el sistema operativo y el dispositivo del navegador mediante encabezados como Sec-CH-UA y Sec-CH-UA-Platform. Si User-Agent declara una versión de Chrome mientras que Client Hints proporciona información no relacionada, los sitios web pueden registrar esta incoherencia.
• Encabezados ausentes o inusuales: Encabezados como Accept-Language indican el idioma preferido del navegador. Si esta información falta o no coincide con otros datos, el sistema puede considerarla una señal que requiere una investigación adicional.

Ten en cuenta que los encabezados HTTP pueden variar según el navegador, la versión y la configuración. Por eso, los sitios web suelen compararlos con otras señales en lugar de considerar un único valor como una prueba concluyente. Chrome también ofrece el mecanismo User-Agent Client Hints para comunicar la información del navegador de una forma más estructurada.

2.2. Señales de las propiedades de JavaScript

Después de que se carga una página, JavaScript puede acceder a distintas propiedades del navegador para inspeccionar el entorno en el que se está ejecutando. Esta es una de las formas habituales en que los sistemas antibots buscan indicios de automatización.

Algunas propiedades importantes son:

• navigator.webdriver: Esta propiedad indica si el navegador está siendo controlado mediante automatización utilizando el mecanismo WebDriver. Según el estándar W3C, devuelve true cuando la bandera WebDriver está activa. En Chrome, esta propiedad puede devolver true cuando el navegador se inicia con determinados parámetros, como --enable-automation, --headless o --remote-debugging-port configurado en el puerto 0. Debes distinguir navigator.webdriver del modo headless, ya que está relacionado con el estado de automatización del navegador y no exclusivamente con su funcionamiento sin interfaz gráfica.
  W3C+1
• Renderizador WebGL: WebGL permite a los sitios web acceder a información relacionada con las capacidades de procesamiento gráfico de un dispositivo. En algunos entornos sin una GPU adecuada, el navegador puede utilizar un renderizador gráfico por software como SwiftShader. Si esta información no coincide con el sistema operativo o la configuración del dispositivo declarados, los sitios web pueden registrar la discrepancia.
• Dimensiones de pantalla y ventana: Valores como screen.width, screen.height, window.innerWidth y window.outerWidth proporcionan información sobre el área de visualización disponible. Algunas configuraciones de automatización pueden generar dimensiones predeterminadas o inconsistencias entre estas propiedades.

Puedes comprobar cierta información básica abriendo las herramientas de desarrollo del navegador e introduciendo los comandos JavaScript correspondientes en la Consola. Sin embargo, estos resultados solo reflejan el entorno en ese momento concreto. No permiten saber con certeza cómo evaluará tu navegador otro sitio web.

Puedes utilizar el siguiente código para inspeccionar rápidamente varias propiedades:

console.log("WebDriver:", navigator.webdriver);

console.log("Screen size:", screen.width, "x", screen.height);

console.log("Window size:", window.innerWidth, "x", window.innerHeight);

const canvas = document.createElement("canvas");
const gl = canvas.getContext("webgl");

if (gl) {
  const debugInfo = gl.getExtension("WEBGL_debug_renderer_info");

  console.log(
    "WebGL renderer:",
    debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL)
      : "Renderer information unavailable"
  );
}

2.3. Rastros del protocolo Chrome DevTools

Además de las propiedades a las que se puede acceder directamente mediante JavaScript, los sitios web también pueden buscar señales generadas cuando una herramienta externa controla el navegador. Uno de los mecanismos relacionados con este proceso es Chrome DevTools Protocol (CDP).

CDP es un protocolo que permite a las herramientas externas comunicarse con Chrome y controlar el navegador. También es el protocolo utilizado por Chrome DevTools y es compatible con herramientas de automatización como Puppeteer y Playwright.

Cuando se conecta a Chrome, una herramienta de automatización puede enviar comandos CDP para activar las funciones necesarias. Por ejemplo, Runtime.enable permite que una herramienta reciba eventos relacionados con el entorno JavaScript. Algunas operaciones realizadas mediante CDP pueden cambiar la forma en que el navegador procesa o muestra información en la Consola, generando señales que los sitios web pueden examinar.

Si estas señales difieren del comportamiento que suele observarse en los navegadores normales, un sistema antibots puede considerarlas pruebas de que el navegador está siendo automatizado. Sin embargo, los rastros de CDP no siempre indican actividad de bots. Los usuarios que abren Chrome DevTools para inspeccionar un sitio web también pueden producir algunos efectos similares. Por eso, los sistemas de detección deben combinar señales adicionales antes de llegar a una conclusión.

Además, las técnicas de detección basadas en CDP y la Consola pueden cambiar entre versiones del navegador. Algunos métodos que antes se utilizaban ampliamente han sido modificados o corregidos. Por lo tanto, no debes confiar en un script de detección obsoleto para determinar si un navegador está siendo automatizado actualmente.

2.4. Señales de un entorno de navegador modificado

Un navegador puede exponer distintos tipos de información sobre su sistema operativo, dispositivo y capacidades de hardware. Si algunas propiedades se modifican mientras que los datos relacionados permanecen sin cambios, los sitios web pueden detectar inconsistencias.

Hay dos grupos de señales importantes:

• Propiedades sobrescritas que no coinciden con su implementación nativa: Algunos scripts pueden modificar los valores de propiedades como navigator.webdriver u otra información del navegador. Sin embargo, las modificaciones incorrectas también pueden afectar a los getters, los prototipos o la forma en que se accede a las propiedades. Los sitios web pueden inspeccionar estas características para identificar datos manipulados.
• Información del dispositivo contradictoria: Por ejemplo, User-Agent puede declarar Windows, mientras que ciertos datos de la plataforma, fuentes o propiedades de WebGL no coinciden. Del mismo modo, la zona horaria y la ubicación de la IP pueden generar una combinación incoherente si no se tiene en cuenta el contexto de uso.

Estos datos suelen examinarse durante el análisis de huellas digitales del navegador. Puedes obtener más información sobre cómo los sitios web recopilan y comparan la información de los dispositivos en nuestro artículo sobre huellas digitales del navegador.

2.5. Señales del comportamiento del usuario

No todos los métodos de detección de bots se centran en las propiedades técnicas del navegador. Los sitios web también pueden analizar cómo interactúan los usuarios con una página, incluidos los movimientos del ratón, el desplazamiento, la escritura y el tiempo entre acciones.

Algunos comportamientos que pueden llamar la atención son:

• El ratón se mueve siguiendo trayectorias demasiado rectas o repite constantemente el mismo recorrido.
• Un formulario se completa y se envía casi inmediatamente después de cargar la página.
• Los visitantes realizan varias acciones consecutivas con intervalos de tiempo idénticos.
• Una página se desplaza o se hace clic en ella siguiendo la misma secuencia en varias visitas.

Sin embargo, no debes asumir automáticamente que los usuarios que interactúan rápidamente o no mueven el ratón son bots. Los usuarios reales pueden utilizar atajos de teclado, herramientas de asistencia o interactuar directamente con los elementos que necesitan en una página. Por eso, las señales de comportamiento deben evaluarse en su contexto y combinarse con otras actividades.

2.6. Señales de red

Además de las características del navegador y la interacción del usuario, la información de red también ayuda a los sitios web a evaluar el origen del tráfico. Algunos sistemas antibots examinan la reputación de la IP, el tipo de red y las características de la conexión para determinar si una visita parece inusual.

Dos grupos de datos que suelen examinarse son:

• Reputación de la IP: Los sitios web pueden evaluar el historial y la reputación de una dirección IP. Por ejemplo, una IP asociada anteriormente con múltiples intentos de inicio de sesión sospechosos o un gran volumen de solicitudes puede clasificarse como de alto riesgo. Las IP de centros de datos también pueden evaluarse de forma diferente a las IP residenciales, según las políticas de cada plataforma.
• Huella digital TLS: Una huella digital TLS refleja ciertas características del proceso de establecimiento de una conexión cifrada. Si esta información no coincide con el navegador o el entorno declarado, el sistema puede registrar una inconsistencia.

Las señales de red no revelan directamente si un navegador se está ejecutando en modo headless. En su lugar, proporcionan información adicional sobre las direcciones IP, las características de la conexión y la reputación del origen del tráfico, lo que ayuda a los sitios web a evaluar si una visita presenta indicios de actividad inusual.

Comparación rápida de las señales de detección

Cada grupo de señales proporciona un tipo de información diferente. La siguiente tabla te ayuda a entender qué pueden examinar los sitios web y la posibilidad de identificar erróneamente a usuarios legítimos en cada caso.

Por lo general, los sitios web no dependen de una sola señal para evaluar una visita. En su lugar, combinan datos del navegador, el comportamiento del usuario y la conexión de red. Un indicador inusual no basta para demostrar que un usuario está ejecutando un navegador headless. Sin embargo, cuando aparecen varias señales al mismo tiempo, el sistema puede considerar que la visita presenta un mayor riesgo.

2.7. ¿Qué técnicas antiguas de detección de navegadores headless deben revisarse?

Al investigar la detección de navegadores headless, puedes encontrar muchos tutoriales que mencionan propiedades como navigator.plugins, navigator.languages, window.chrome y WebRTC como formas de identificar navegadores headless. Estos indicadores aparecen con frecuencia en la documentación sobre versiones antiguas de Headless Chrome.

Sin embargo, Chrome modificó su implementación headless a partir de la versión 112. El nuevo modo headless comparte el código fuente con Chrome normal, mientras que la antigua implementación se separó en chrome-headless-shell a partir de Chrome 132. Como resultado, las características que antes se consideraban indicadores habituales no necesariamente representan con precisión el entorno headless actual.

Debes tratar las siguientes propiedades como aspectos que conviene comprobar según la versión del navegador correspondiente, en lugar de considerarlas pruebas definitivas de que un navegador se está ejecutando en modo headless.

Para obtener una evaluación más precisa, debes ejecutar la misma prueba en Chrome normal y en la configuración headless que estés utilizando. Los resultados serán más útiles si van acompañados de la versión de Chrome, el sistema operativo y el framework específico. También puedes consultar el procedimiento de autocomprobación de la sección 5.2.

Ten en cuenta que navigator.webdriver y un User-Agent que contiene HeadlessChrome son señales independientes. No deben agruparse con las técnicas de detección antiguas que necesitan revisarse. Ambos indicadores siguen teniendo que evaluarse según la configuración y la versión específicas del navegador.

3. ¿Cómo detectan los sitios web Puppeteer, Playwright y Selenium?

Cada framework de automatización de navegadores tiene su propio mecanismo de funcionamiento y sus características técnicas. Puppeteer y Playwright suelen utilizar Chrome DevTools Protocol para controlar Chromium, mientras que Selenium utiliza WebDriver. Estas diferencias pueden generar señales que los sitios web aprovechan para identificar actividades automatizadas.

Sin embargo, no debes considerar ningún indicador individual como una característica que siempre aparece en todas las versiones. Los resultados también dependen del navegador, el framework y la configuración de inicio.

3.1. Detección de Puppeteer

Puppeteer es una biblioteca de Node.js que permite controlar Chrome o Chromium mediante código. Se utiliza habitualmente para realizar pruebas de interfaz, capturar pantallas de sitios web, recopilar datos y automatizar tareas del navegador.

Al ejecutarse, Puppeteer puede dejar varias señales, entre ellas:

• Conexiones CDP: Puppeteer utiliza Chrome DevTools Protocol para enviar comandos y recibir datos del navegador. Algunas actividades relacionadas con este protocolo pueden generar rastros que los sitios web pueden observar.
• Scripts inyectados en las páginas: Puppeteer puede inyectar scripts en el entorno de la página web para facilitar el control del navegador y la supervisión de actividades. En algunos casos, pueden aparecer rastros de estos scripts en las trazas de la pila, como la cadena pptr:. Sin embargo, no es un indicador fijo en todas las versiones.
• Modo headless predeterminado: Actualmente, Puppeteer utiliza por defecto el nuevo modo headless. Si quieres ejecutar Chrome con una interfaz visible, puedes establecer headless: false. Cambiar el modo de visualización no modifica la naturaleza automatizada del framework.
  Puppeteer+1

Por ejemplo, puedes utilizar Puppeteer para abrir automáticamente una página de producto y realizar capturas de pantalla en tu ordenador personal. Cuando trasladas el mismo script a un VPS, el sitio web puede empezar a solicitar verificaciones CAPTCHA o restringir el acceso. La causa puede estar relacionada con diferencias en la dirección IP, el entorno del navegador o las señales de automatización que detecta el sitio web.

3.2. Detección de Playwright

Playwright es un framework de automatización de navegadores compatible con Chromium, Firefox y WebKit. Se utiliza habitualmente para realizar pruebas de interfaz, comprobar flujos de usuario y automatizar tareas en sitios web.

Al analizar la actividad de Playwright, los sitios web pueden examinar varios indicadores:

• Versión de Chromium incluida: Según la documentación de Playwright, cada versión del framework utiliza las versiones de navegador correspondientes. De forma predeterminada, Playwright puede ejecutar su propia versión de Chromium incluida en lugar de Google Chrome con su marca oficial. Las diferencias en las versiones y la información del navegador pueden provocar que Client Hints no coincida con una configuración normal de Chrome.
• Scripts de inicialización y variables globales: Playwright puede inyectar scripts en las páginas al crear un contexto o inicializar el entorno. Algunos rastros relacionados con este proceso pueden examinarse mediante JavaScript.

No obstante, estos indicadores deben comprobarse según las versiones específicas de Playwright y Chromium. No debes asumir que utilizar Playwright significa que un sitio web siempre detectará actividad automatizada.

3.3. Detección de Selenium

Selenium es una suite de automatización de navegadores muy utilizada para realizar pruebas de software. A diferencia de Puppeteer y Playwright, Selenium funciona mediante WebDriver, un estándar que permite a programas externos controlar los navegadores.

Los sitios web pueden prestar atención a varios indicadores relacionados:

• WebDriver: Selenium utiliza el mecanismo WebDriver para enviar comandos de control al navegador. La propiedad navigator.webdriver puede indicar que el navegador está siendo controlado automáticamente mediante este mecanismo.
• Rastros de ChromeDriver: En algunas configuraciones de ChromeDriver, las variables con el prefijo cdc_ se han identificado históricamente como indicadores relacionados con Selenium. Sin embargo, su aparición depende de la versión y la implementación, por lo que no deben considerarse características que siempre estén presentes.

Por lo tanto, Selenium puede dejar rastros diferentes a los de Puppeteer y Playwright porque utiliza el canal de control WebDriver. Puedes consultar el estándar W3C WebDriver para comprender mejor este mecanismo.

Comparación de frameworks

Para entender mejor las diferencias, puedes consultar el siguiente resumen:

Las señales de esta tabla son solo orientativas y no representan características fijas de cada framework. Al investigar un caso concreto, debes comprobar la versión correspondiente del navegador, el framework y las fuentes técnicas.

4. ¿Qué relación tiene Chrome Remote Debugging con la detección de automatización?

Chrome Remote Debugging es un mecanismo que permite a herramientas externas conectarse a Chrome para inspeccionar y controlar el navegador. Por su parte, Chrome DevTools Protocol (CDP) es el protocolo utilizado para llevar a cabo esta comunicación.

Es necesario distinguir claramente tres conceptos:

• Puerto de depuración remota: Un puerto de conexión que se abre cuando Chrome se inicia con la opción --remote-debugging-port.
• Chrome DevTools Protocol (CDP): Un protocolo que permite a las herramientas enviar comandos a Chrome y recibir datos del navegador.
• Rastros de CDP: Cambios o efectos secundarios que pueden aparecer en el entorno de la página cuando una herramienta utiliza CDP para controlar el navegador.

Lo importante es que observar rastros de CDP dentro de una página no significa que un sitio web pueda acceder directamente al puerto de depuración de tu ordenador.

Chrome también modificó el funcionamiento de las opciones de depuración remota a partir de la versión 136. Según el anuncio de Google del 17 de marzo de 2025, las opciones --remote-debugging-port y --remote-debugging-pipe dejaron de aceptarse cuando se utilizan con el directorio de datos predeterminado de Chrome. Los usuarios deben especificar un directorio independiente mediante --user-data-dir para seguir utilizando este mecanismo. El cambio se introdujo para mejorar la protección de las cookies y la información de inicio de sesión. Chrome for Testing no se ve afectado por este ajuste.

Si utilizas la depuración remota para desarrollo o pruebas, debes seguir varios principios de seguridad:

• No expongas el puerto de depuración a redes externas salvo que sea necesario.
• No utilices tu perfil principal de Chrome, que contiene sesiones de cuentas personales, para actividades de depuración.
• Utiliza un directorio de datos independiente para aislar el entorno de pruebas de los datos de navegación habituales.

5. Cómo comprobar qué señales expone tu navegador automatizado

Puedes utilizar varios sitios web de pruebas de huellas digitales para inspeccionar la información que expone tu navegador. Este enfoque te ayuda a identificar las diferencias entre Chrome normal y las configuraciones que se ejecutan mediante Puppeteer, Playwright o Selenium.

Sin embargo, ningún sitio web de pruebas puede representar por completo un sistema antibots. Cada herramienta se centra en distintos grupos de señales, por lo que debes combinar los resultados de varias fuentes.

5.1. Sitios web de pruebas recomendados

A continuación se muestran varias herramientas que puedes utilizar para inspeccionar las propiedades del navegador y la coherencia de tu entorno.

• bot.sannysoft.com: Bot Sannysoft ofrece varias pruebas relacionadas con navigator.webdriver, los plugins, los permisos y otras propiedades del navegador. Los resultados se muestran directamente en la página, lo que te permite identificar qué comprobaciones presentan indicadores inusuales.

• CreepJS: CreepJS analiza múltiples propiedades del navegador para identificar inconsistencias o indicios de manipulación del entorno. La herramienta también ofrece evaluaciones relacionadas con navegadores headless y la identificación de huellas digitales, lo que te ayuda a comprender mejor los datos que expone el navegador.

• BrowserLeaks: BrowserLeaks ofrece pruebas individuales para WebGL, Canvas, WebRTC y otras propiedades. En lugar de proporcionar una conclusión general sobre la automatización, el sitio web te ayuda a inspeccionar cada componente de la información que expone tu navegador.

• Pixelscan: Pixelscan comprueba información relacionada con las huellas digitales del navegador, las direcciones IP y la coherencia entre estos datos. Sus resultados pueden ayudarte a identificar ciertas inconsistencias en la configuración de tu navegador.

Ten en cuenta que superar estas pruebas no significa que un sitio web real vaya a aceptar tu visita. Los sistemas antibots pueden utilizar datos de comportamiento adicionales, el historial de la IP y modelos de análisis del lado del servidor que las herramientas públicas de prueba no pueden simular por completo.

5.2. Proceso de autocomprobación en cinco pasos

Para que tus resultados sean significativos, debes probar Chrome normal y el navegador automatizado en las mismas condiciones. El siguiente proceso te ayuda a identificar sistemáticamente las diferencias entre ambos entornos.

1. Registra tu configuración: Identifica la versión de Chrome, el framework, el sistema operativo y los parámetros de inicio del navegador que estás utilizando.
2. Prueba Chrome normal: Abre los sitios web de pruebas de huellas digitales en Chrome sin automatización para recopilar los resultados de referencia.
3. Ejecuta la configuración automatizada: Utiliza tu script para acceder a los mismos sitios web, tanto en modo headless como en modo headful, y recopila los resultados.
4. Compara los datos: Compara las propiedades individuales entre las distintas sesiones de prueba y registra cualquier diferencia.
5. Guarda los resultados: Haz capturas de pantalla, registra la fecha de las pruebas y guarda la versión del navegador para poder comparar los resultados después de cada actualización.

Durante las pruebas, debes mantener sin cambios otros factores, como el sistema operativo, la conexión de red y el dispositivo. Si modificas demasiados ajustes a la vez, será difícil identificar por qué los resultados de las pruebas son diferentes.

5.3. ¿Qué puede hacer Hidemyacc y cuáles son sus limitaciones?

Hidemyacc, un navegador antidetect, es una herramienta que permite crear y gestionar perfiles de navegador con huellas digitales independientes, combinados con proxies para administrar los entornos de navegación. Al utilizar Hidemyacc, cada perfil tiene sus propias cookies, proxy y huella digital, lo que ayuda a mantener la coherencia de la información del entorno descrita en la sección 2.4. Sin embargo, Hidemyacc no cambia la naturaleza de la automatización. Las señales relacionadas con la forma en que los scripts controlan los navegadores mediante CDP o con la manera en que los usuarios interactúan con los sitios web todavía pueden detectarse.

Si necesitas integrar herramientas de automatización, también puedes consultar la documentación oficial de Hidemyacc para obtener información sobre Profile API.

6. Conclusión

Los sitios web no detectan los navegadores headless simplemente comprobando si el navegador tiene una interfaz visible. En su lugar, los sistemas antibots pueden combinar información de los encabezados HTTP, JavaScript, CDP, las huellas digitales del navegador, las conexiones de red y el comportamiento de interacción del usuario para evaluar una visita.

Esto también explica por qué cambiar del modo headless al modo headful o simplemente modificar User-Agent puede no resolver el problema. Un navegador todavía puede exponer señales de automatización a través de la forma en que se controla o de las inconsistencias en su entorno.

Si estás desarrollando o probando aplicaciones, utiliza las herramientas de la sección 5 para examinar las diferencias entre los navegadores normales y los entornos automatizados. Si gestionas varias cuentas, debes prestar atención a la coherencia de las huellas digitales, los proxies y los datos de cada perfil, al mismo tiempo que cumples las políticas de las plataformas que utilizas.

Comprender cómo detectan los bots los sitios web te ayudará a elegir y gestionar los entornos de navegador de forma más eficaz, en lugar de centrarte en modificar ajustes individuales de manera aislada.

Más información: Navegadores antidetect para web scraping: las mejores herramientas de 2026

7. FAQ

1. ¿Que navigator.webdriver devuelva true significa que una cuenta será suspendida?

No necesariamente. navigator.webdriver es solo un indicador de que el navegador está siendo controlado automáticamente mediante el mecanismo WebDriver. Los sitios web pueden combinar esta información con las huellas digitales, el comportamiento y el historial de acceso para evaluar el riesgo. Que una cuenta deba verificar su identidad o sea restringida depende de las políticas de cada plataforma.

2. ¿Abrir DevTools mientras se navega puede hacer que un usuario sea identificado erróneamente como un bot?

Es posible. Algunas técnicas de detección de automatización basadas en CDP pueden registrar efectos secundarios cuando Chrome DevTools está abierto. Sin embargo, esto no es prueba suficiente para concluir que un usuario es un bot. Por lo general, los sistemas antibots necesitan examinar señales adicionales antes de tomar una decisión.

3. ¿Ejecutar Puppeteer en modo headful sigue considerándose automatización?

Sí. Los modos headless y headful solo indican si el navegador muestra una ventana visible, mientras que la automatización se refiere al control del navegador mediante scripts. Por lo tanto, Puppeteer ejecutado en modo headful todavía puede exponer señales relacionadas con CDP o con el control automatizado del navegador.

4. ¿Los sitios web pueden ver si Chrome ha abierto un puerto de depuración remota?

Por lo general, los sitios web pueden observar los efectos generados dentro de una página cuando un navegador está siendo controlado, pero no el puerto de depuración remota en sí. Los rastros de CDP no significan que un sitio web pueda acceder al puerto de depuración de tu ordenador. La posibilidad de que una página web compruebe un puerto local debe verificarse por separado en cada caso concreto.

5. ¿Puede Hidemyacc evitar que se detecten los scripts automatizados?

No es posible garantizar que Hidemyacc evite la detección de scripts automatizados. La herramienta permite gestionar perfiles con huellas digitales, cookies y proxies independientes, lo que ayuda a mantener un entorno de navegador coherente. Sin embargo, los sitios web todavía pueden detectar señales relacionadas con CDP, la forma en que los scripts controlan el navegador y el comportamiento de interacción del usuario.