Chrome sin cabeza es un navegador que nunca ves, pero con el que te encuentras constantemente. Ejecuta pruebas automatizadas, genera PDF y capturas de pantalla, y los motores de búsqueda utilizan una tecnología similar para renderizar páginas. En este artículo, analizo cómo funciona internamente, cuáles son las diferencias entre sus modos, cómo se controla y dónde vale la pena aplicarlo. Sobre cómo los bots basados en él terminan en los informes y cómo detectarlos: «Tráfico sospechoso en GA4: cómo los bots con navegadores sin cabeza se disfrazan de personas y cómo detectarlos».
⚡ En resumen: ¿qué es Chrome sin cabeza?
✅ Es Chrome real sin interfaz visible. La documentación de Chrome lo describe como la ejecución del navegador en un entorno sin supervisión y sin interfaz de usuario. Se inicia con el indicador --headless.
✅ A partir de Chrome 112, es el mismo navegador. El modo crea ventanas de plataforma, pero no las muestra, y el resto de las funciones funcionan sin restricciones.
✅ Se controla mediante programación: a través del protocolo Chrome DevTools, WebDriver BiDi o las bibliotecas Puppeteer, Playwright, Selenium.
⚠️ Para el sitio web, es un visitante completo, ya que ejecuta JavaScript. Por lo tanto, las pruebas legítimas y los bots maliciosos se ven iguales para la analítica.
🧠 Cómo funciona internamente: el nuevo headless y chrome-headless-shell
Anteriormente, headless era una implementación separada del navegador que se incluía en el mismo binario, pero no utilizaba el código de Chrome del directorio //chrome. Hoy en día, los modos están unificados: en Chrome 112, headless se actualizó para que Chrome cree ventanas de plataforma, pero no las muestre. La implementación antigua, a partir de la versión 132.0.6793.0, solo está disponible como un binario separado chrome-headless-shell, que se puede descargar de la página Chrome for Testing.
Envoltorio ligero alrededor del módulo Chromium //content
Dependencias
Conjunto completo, como en Chrome
Mucho menos: no requiere X11/Wayland ni D-Bus
Fortaleza
Autenticidad, fiabilidad, más funciones
Velocidad y ligereza en algunos escenarios
Para qué es adecuado
Pruebas de extremo a extremo precisas, pruebas de extensiones
Capturas de pantalla automáticas, recopilación de datos de páginas
En pocas palabras, la elección depende del compromiso entre el rendimiento y la "autenticidad" del navegador. En Puppeteer, esto se ve en el parámetro de inicio: headless: true activa el nuevo modo (por defecto), headless: 'shell' activa chrome-headless-shell, y headless: false activa el modo normal con ventana. Ambos modos, a nivel de motor (Blink, V8), ejecutan la misma plataforma web, por lo que JavaScript, CSS y las solicitudes de red funcionan igual que en Chrome normal.
Las limitaciones que hacen que el comportamiento de los modos y la interfaz puedan diferir de Chrome normal, las analizo por separado: Limitaciones de Chrome sin cabeza.
🔌 Cómo se controla: DevTools Protocol y WebDriver BiDi
Sin ventana, el navegador se controla mediante comandos. Normalmente, esto se hace a través de un protocolo. Cuando Chrome se inicia con el indicador --remote-debugging-port=9222, se activa el protocolo Chrome DevTools: a través de él, las herramientas envían comandos al navegador, y así es como funcionan los depuradores en los editores. La dirección http://localhost:9222 en otro navegador muestra una lista de páginas que se pueden inspeccionar. El puerto de depuración da control total sobre el navegador, por lo que no se debe abrir externamente.
Chrome DevTools Protocol (CDP): es el protocolo propietario de Chromium. El manual completo de comandos está disponible en DevTools Protocol Viewer. Como se señala en la descripción de Selenium BiDi, CDP solo es compatible con navegadores basados en Chromium.
WebDriver BiDi: es un estándar bidireccional de W3C, creado por el equipo de Selenium junto con los proveedores de navegadores. Debe convertirse en una API estable entre navegadores: los eventos van del navegador al código de control a través de WebSocket. Como se explica en la documentación de Selenium, la compatibilidad con CDP allí es temporal hasta que se implemente BiDi. En el blog de Chrome de 2023, la compatibilidad con BiDi en Puppeteer se calificó de experimental, por lo que debe verificar el estado actual en la documentación.
Diagrama: cómo el script controla Chrome sin cabeza
🛠️ Puppeteer, Playwright, Selenium: cuáles son las diferencias
Chrome / Chromium; verifique la compatibilidad con otros navegadores en la documentación
Automatización rápida de Chrome: capturas de pantalla, PDF, recorrido de páginas. Biblioteca del equipo de Chrome, headless está habilitado por defecto en ella
Conjuntos de pruebas WebDriver existentes y control preciso sobre el controlador de un navegador específico
Para un desarrollador de Java, es importante que tanto Playwright como Selenium tengan clientes oficiales de Java. No existe una herramienta "mejor": Puppeteer es más simple para tareas rápidas en Chrome, Playwright es más conveniente cuando se necesitan varios motores, y Selenium se elige cuando ya existe una infraestructura WebDriver. Antes de fijar la elección en un proyecto, verifique las versiones actuales y los navegadores compatibles en la documentación de cada herramienta.
🚀 Qué se puede hacer desde la línea de comandos
Para tareas sencillas no se necesitan scripts. Según la guía de indicadores de Chrome, en modo headless y en chrome-headless-shell están disponibles los siguientes comandos (en lugar de chrome, introduce la ruta a Chrome en tu sistema):
DOM serializado
chrome --headless --dump-dom https://example.com/
Esto no es lo mismo que descargar el HTML a través de curl. Chrome primero analiza el HTML en un DOM, ejecuta scripts que pueden modificarlo y luego serializa el DOM de nuevo en una cadena. Así ves la página después de que JavaScript haya actuado.
Guarda la página como output.pdf; el indicador --no-pdf-header-footer elimina los encabezados y pies de página con la fecha y la dirección.
Esperas
--timeout=5000 — tiempo máximo de espera (ms), después del cual el contenido se captura, incluso si la página aún se está cargando.
--virtual-time-budget=42000 — «rebobina» el tiempo para el código en la página (setTimeout, setInterval): el navegador lo ejecuta lo más rápido posible, y la página cree que el tiempo realmente ha pasado.
🧪 Para qué se utiliza legalmente
Pruebas automáticas. Los desarrolladores de Chrome llaman directamente a headless una herramienta para pruebas automáticas y entornos de servidor donde la interfaz no es necesaria: se pueden ejecutar pruebas en una página real, crear su PDF o comprobar cómo el navegador la muestra.
Generación de PDF e imágenes: facturas, informes, vistas previas para redes sociales a partir de plantillas HTML.
Monitorización: apertura regular de páginas clave y comprobación de si realmente se muestran después de ejecutar JavaScript.
Auditoría SEO: comparación del HTML crudo y la página después del renderizado (ver la siguiente sección).
Recopilación de datos públicos, si las reglas del sitio lo permiten (ver la sección sobre ética).
📈 Headless y SEO: cómo los motores de búsqueda renderizan JavaScript
Para los profesionales de SEO, el navegador headless es importante también porque los motores de búsqueda utilizan una tecnología similar. Google explica que Google Search ejecuta JavaScript utilizando una versión actualizada de Chromium. Googlebot toma la URL de la cola de escaneo, lee robots.txt y pone las páginas en cola para el renderizado. Cuando los recursos lo permiten, Chromium headless renderiza la página y ejecuta JavaScript. Si la página o sus scripts están bloqueados en robots.txt, Google no ejecutará ese JavaScript.
La estrategia de renderizado afecta el rendimiento y la fiabilidad. En el material de web.dev se indica que el renderizado del lado del servidor con hidratación puede mejorar la velocidad y la experiencia del usuario, y las páginas deben probarse regularmente para ver si su contenido está disponible para Googlebot.
Comprobación local rápida. El comando --dump-dom muestra el DOM después de ejecutar los scripts. Esto te acerca a lo que verá el renderizador, pero no sustituye la comprobación en Google Search Console.
🐳 Ejecución en Docker y CI
En servidores y en pipelines de CI, Chrome headless se ejecuta sin entorno gráfico. Según el FAQ de la documentación de Chrome, no se necesita un visor virtual como Xvfb, ya que no hay ventana. Allí mismo se indica que el indicador --no-sandbox no es necesario si el usuario en el contenedor está configurado correctamente. No desactive el sandbox sin necesidad: esto reduce la seguridad, especialmente cuando el navegador abre páginas ajenas. (La página de FAQ es antigua, así que compruebe las recomendaciones para su versión de Chrome.)
Para no descargar el navegador completo, puede descargar una versión ligera de Chrome for Testing utilizando la utilidad Puppeteer:
Desde la perspectiva del sitio, headless Chrome es un cliente que descarga la página, ejecuta sus scripts y lanza todo lo que hay en ella, incluidos los tags de analítica. Por eso GA4 no lo distingue de una persona por defecto: solo descarta los bots conocidos de la lista. Cómo se ve esto en los informes, cómo confirmar la sospecha en Cloudflare y qué hacer al respecto, lo analicé en detalle en el artículo «Tráfico sospechoso en GA4: cómo los bots con navegadores headless se disfrazan de personas y cómo detectarlos». Sobre las diferencias entre un bot y un usuario real según los logs también se puede leer aquí: «Cómo distinguir un bot de un usuario real».
Un detalle práctico para los propietarios de sitios: sus propias pruebas automáticas y monitorización, que acceden a producción con el tag GA4, también entran en las estadísticas. Exclúyalos (por ejemplo, a través del tráfico interno o el tráfico de desarrolladores) para no contaminar los datos.
⚖️ Ética y reglas de uso
robots.txt no es un acceso con permiso. El estándar RFC 9309 indica explícitamente que estas reglas no son una forma de autorización. El archivo pide a los bots que se comporten cortésmente, pero técnicamente no prohíbe nada. Más detalles: guía de robots.txt.
No sobrecargue sitios ajenos. Limite la frecuencia de las solicitudes, no ejecute cientos de pestañas en paralelo.
Lea los términos de uso del sitio y tenga en cuenta las leyes de su país sobre la recopilación de datos. Esto no es un asesoramiento legal, sino un recordatorio para comprobar las reglas antes de empezar a trabajar.
No utilice navegadores headless para inflar el tráfico, clics o visualizaciones de publicidad. Esto infringe las reglas de las redes publicitarias y puede provocar el bloqueo de la cuenta.
⚠️ Problemas típicos
El contenido dinámico no tuvo tiempo de aparecer. La captura se realizó antes de que terminara la carga. En la línea de comandos ayudan --timeout y --virtual-time-budget, en las bibliotecas — esperar elementos o eventos específicos.
Resultados diferentes en headless y con ventana. Las discrepancias pueden deberse al tamaño de la ventana, fuentes, configuraciones y modo de ejecución. Por lo tanto, establezca el tamaño de la ventana explícitamente (--window-size) y reproduzca el problema en el mismo modo en que ocurrió.
Pruebas inestables. La causa típica es la dependencia de los tiempos. En lugar de «dormir» un tiempo determinado, espere una condición explícita.
Recursos del servidor. Cada instancia del navegador consume memoria y procesador, así que cierre el navegador después de terminar el trabajo y limite el paralelismo.
Lea más sobre los límites del modo y las diferencias con Chrome normal en un artículo aparte: Limitaciones de Headless Chrome.
❓ Preguntas frecuentes (FAQ)
¿En qué se diferencia Headless Chrome del Chrome normal?
A partir de Chrome 112, es el mismo navegador: crea, pero no muestra ventanas, y todas las demás funciones están disponibles. La diferencia principal es que no hay una interfaz visible y el control se realiza mediante programación. Describiré los detalles y las diferencias de comportamiento en el artículo «Limitaciones de Headless Chrome».
¿Se necesita Xvfb para headless Chrome?
No. Según el FAQ de la documentación de Chrome, no hay ventana, por lo que no se necesita una pantalla virtual.
¿Qué elegir: Puppeteer o Playwright?
Puppeteer es conveniente para la automatización rápida de Chrome en Node. Playwright vale la pena cuando se necesitan Chromium, Firefox y WebKit en una sola API o clientes para Python, .NET o Java.
¿Se puede usar headless Chrome en Java?
Sí: Playwright tiene un cliente oficial de Java, y Selenium admite Java entre los lenguajes principales.
¿Hay diferencia entre chrome-headless-shell y el modo --headless?
Sí. --headless inicia Chrome real sin ventana, mientras que chrome-headless-shell es un binario ligero separado con una implementación antigua, que tiene menos dependencias.
✅ Conclusiones
🔹 Headless Chrome es un navegador real sin interfaz visible. A partir de Chrome 112, su modo se ha unificado con el Chrome normal.
🔹 La antigua opción ahora está disponible como chrome-headless-shell independiente: más ligero, pero menos "auténtico".
🔹 Se controla a través de CDP, WebDriver BiDi o las bibliotecas Puppeteer, Playwright y Selenium. La elección depende del idioma, los navegadores y la infraestructura existente.
🔹 Para tareas rápidas, la línea de comandos es suficiente: --dump-dom, --screenshot, --print-to-pdf.
🔹 Para SEO, es importante entender que Google también renderiza páginas a través de headless Chromium, así que no bloquees los recursos necesarios para la visualización.
🔹 Para el sitio web, un navegador headless parece un visitante, así que consulta también el artículo sobre bots en GA4 y usa la herramienta de forma responsable.
Importante: las versiones de Chrome, las marcas y la compatibilidad con navegadores en Puppeteer, Playwright y Selenium cambian. Comprueba la documentación actual antes de usar. El material está actualizado a octubre de 2026.
