Métodos de detección de problemas de renderizado de Javascript que impiden el rastreo de Google

Inspección de URL en GSC

Introduzca la URL en Search Console, haga clic en “Ver página rastreada” y compare el código fuente HTML para confirmar si el contenido principal desaparece tras el renderizado.

Comparación de diferencias de texto

Compare el número de caracteres de texto entre “Ver código fuente” e “Inspeccionar elemento”; si la tasa de diferencia de texto es > 20%, existe un riesgo muy alto de indexación.

Rich Results Test

Utilice la herramienta de prueba de resultados enriquecidos de Google para ver la captura de pantalla y asegurarse de que el contenido clave de la parte superior de la página se cargue por completo dentro de la ventana de renderizado de 5 segundos.

Herramientas oficiales de Google

La herramienta de inspección de URL de Google Search Console (GSC) es la puerta de entrada para obtener el estado real del rastreo de Googlebot.

A través de “Probar URL en vivo”, se puede invocar el WRS (Web Rendering Service) para generar la estructura DOM completa en un plazo de 60 a 90 segundos.

GSC proporciona el HTML renderizado, capturas de pantalla y una lista de carga de recursos.

Actualmente, Googlebot utiliza el núcleo de la última versión estable de Chrome, pero establece un umbral de aproximadamente 5 segundos para la ejecución de scripts en una sola página.

En combinación con la “Prueba de resultados enriquecidos”, se pueden comparar las diferencias de bytes entre la respuesta original y el resultado final del renderizado, e identificar problemas de carga de scripts 403 o 404 causados por bloqueos en el archivo Robots.txt.

Google Search Console

En la navegación de la barra lateral de Google Search Console, tras introducir una URL específica, el sistema recuperará una instantánea de los datos del rastreo más reciente de la base de datos del índice de Google.

Si el estado de la página muestra “La URL está en Google”, se puede ver si hubo errores de análisis HTML o problemas de optimización móvil durante el rastreo.

Para investigar a fondo la falta de contenido causada por el renderizado de JavaScript, se debe hacer clic en el botón “Probar URL en vivo”.

Esta operación activará el WRS (Web Rendering Service) para iniciar un navegador headless basado en el último núcleo estable de Chromium y realizar una visita en tiempo real a la página de destino.

Cuando el WRS ejecuta el renderizado, establece el ancho de la ventana gráfica en 1280 píxeles y adopta una estrategia de rastreo prioritaria para dispositivos móviles.

En el panel “Ver página renderizada”, la pestaña HTML muestra la estructura DOM completa una vez finalizada la ejecución de los scripts.

El personal técnico debe realizar una comparación cuantitativa entre el número de líneas de código o el volumen de bytes de caracteres HTML que se muestran aquí y el “Ver código fuente de la página” (respuesta original del servidor) que se ve al hacer clic con el botón derecho en el navegador.

Si el HTML original tiene solo 2 KB y el HTML renderizado aumenta a 50 KB, indica que la página depende en gran medida del renderizado del lado del cliente.

Si el HTML renderizado carece del texto principal o de las etiquetas de la lista de productos, se determina que el renderizado ha fallado.

Googlebot asigna recursos de computación limitados a la ejecución de scripts en una sola página. Aunque no se ha dado oficialmente un tiempo de corte absoluto, numerosos experimentos indican que si el tiempo de carga del contenido supera los 5 segundos, la probabilidad de que esa parte de los datos se omita en la fase de indexación aumenta significativamente.

“Googlebot no espera indefinidamente a que JavaScript complete todas las tareas asíncronas; su presupuesto de renderizado está limitado conjuntamente por la velocidad de carga de la página, el retraso en la respuesta del servidor (TTFB) y la complejidad del análisis de scripts. Si el tiempo de respuesta de la interfaz API supera los 2000 milisegundos, a menudo el contenido todavía estará en estado de carga en el momento en que se genera la instantánea del renderizado.”

En la lista de “Recursos de la página” bajo la pestaña “Más información”, se enumerarán todos los archivos JS y CSS que no se cargaron correctamente.

Los códigos de estado 403 o 404 indican claramente errores de configuración de permisos del servidor o rutas de recursos inválidas, pero a lo que más hay que prestar atención es al estado “Bloqueado por Robots.txt”.

Dado que muchas aplicaciones de una sola página (SPA) encapsulan la lógica de enrutamiento y la lógica de renderizado de datos en archivos de scripts específicos, si el archivo /robots.txt del sitio contiene reglas como Disallow: /assets/ o similares que impiden que Googlebot obtenga los scripts principales, el WRS no podrá construir un árbol DOM completo.

El resultado es que, aunque el usuario vea la página completa en el navegador, desde la perspectiva del rastreo del motor de búsqueda, la página puede aparecer en blanco o contener solo un marco básico.

La investigación de errores de scripts debe centrarse en el área de “Mensajes de la consola de JavaScript”.

Aquí se registrarán las excepciones lanzadas por el WRS al ejecutar el código.

Si el equipo de desarrollo ha utilizado nuevas características de ES6+ sin tratamiento de Polyfill (como BigInt, ResizeObserver, etc.) y la versión de Chromium correspondiente en el momento del rastreo aún no es totalmente compatible con ciertas API no estándar, aparecerán errores como Uncaught ReferenceError o SyntaxError en la consola.

Este tipo de errores provocará la interrupción de todo el proceso de análisis de scripts, invalidando toda la lógica posterior de inyección de contenido.

Al observar el número de línea y el nombre del archivo específicos mencionados en el registro de errores, se puede localizar con precisión qué archivo de biblioteca o bloque de lógica de negocio está impidiendo el rastreo.

La “Captura de pantalla” tras el renderizado es otro medio de detección cuantitativa.

Por ejemplo, algunos scripts calculan dinámicamente la altura o la transparencia de los elementos; si la captura muestra grandes áreas en blanco, incluso si existen palabras en las etiquetas HTML, el algoritmo de Google puede determinar que la página no es amigable para el usuario, reduciendo así la prioridad de indexación.

Al tratar con sitios altamente dinámicos, es necesario asegurarse de que todo el contenido situado en la parte superior de la página (Above the Fold) complete el renderizado en un plazo de 2 segundos.

Prueba de resultados enriquecidos

La herramienta de prueba de resultados enriquecidos es un entorno de detección público proporcionado por Google. A diferencia de Search Console, que requiere la verificación de la propiedad del sitio, esta herramienta permite a cualquier persona analizar cualquier URL pública o fragmentos de código pegados.

Tras introducir la URL e iniciar la prueba, el sistema activará un navegador headless basado en la última versión estable de Chromium para simular el comportamiento de acceso de Googlebot Smartphone o Googlebot Desktop.

Para las aplicaciones de una sola página (SPA) construidas con marcos de JavaScript como React, Angular o Vue.js, la función “Ver página probada” que ofrece esta herramienta es el estándar para determinar si el contenido ha entrado con éxito en el árbol DOM.

Dado que Googlebot tiene un límite claro en la asignación de recursos al procesar scripts, si la página requiere ejecutar una gran cantidad de cálculos intensivos o iniciar más de 20 solicitudes API asíncronas en la fase de inicialización, el WRS podría finalizar la captura de HTML antes de que se complete la ejecución de los scripts.

Al realizar una detección en tiempo real, el sistema generará una instantánea del HTML renderizado.

A través de esta instantánea, el personal técnico puede comparar con precisión la diferencia entre los bytes devueltos por el servidor original y los bytes tras el renderizado final.

Por ejemplo, una página de renderizado puramente en el lado del cliente (CSR) suele tener menos de 5 KB de código de plantilla base en su HTML original; si el HTML renderizado a través de esta herramienta alcanza más de 100 KB, indica que Googlebot ejecutó con éxito los scripts y extrajo el contenido dinámico.

Por el contrario, si el HTML renderizado sigue en torno a los 5 KB y no contiene las etiquetas del texto principal, indica que la ejecución del script se interrumpió a nivel de WRS.

El motor de renderizado de Google establece un mecanismo de tiempo de espera estricto para la descarga de recursos individuales; normalmente, el tiempo de carga de un solo archivo JS no debe superar los 2000 milisegundos.

Si las bibliotecas de terceros o las interfaces API referenciadas en la página responden con demasiada lentitud, la pestaña “Recursos de la página” en los resultados de la prueba marcará el estado de fallo de carga correspondiente.

• Modo de prueba de fragmentos de código: permite pegar lógica de código HTML no publicada, lo cual es vital para detectar si la lógica de renderizado JS cumple con las normas de rastreo durante la fase de entorno de Staging. De esta forma, se puede detectar cuantitativamente si ciertos marcadores Schema generados dinámicamente se pueden analizar correctamente antes de fusionar el código en la rama principal.
• Simulación de cambio de User-Agent: aunque se adopta por defecto el rastreo móvil, al tratar con sitios que tienen una lógica responsiva compleja, cambiar a la simulación de dispositivo de escritorio puede revelar el impacto de la prioridad de carga de CSS en el orden de ejecución de JS.
• Comparación de instantáneas de renderizado: las capturas de pantalla proporcionadas por el sistema no son solo una referencia visual, sino también una base para juzgar si la página presenta “desplazamiento de contenido” o “inestabilidad de diseño”, ya que cambios bruscos en el diseño pueden llevar a Googlebot a juzgar erróneamente la usabilidad de la página.

“La prueba de resultados enriquecidos no solo valida los datos estructurados, sino que es un laboratorio para detectar la visibilidad del contenido dinámico. Si el texto de la página se carga de forma asíncrona a través de JS, buscar si ese texto existe en ‘Ver página probada’ es el método más rápido para validar la tasa de éxito de la indexación SEO.”

Cuando la página contiene JSON-LD o Microdata inyectados a través de scripts, esta herramienta extraerá esa información estructurada del DOM renderizado.

Si existen errores de sintaxis en el código, o si un error de JS provoca que el script se detenga antes de inyectar el marcador Schema, la herramienta mostrará el aviso “No se detectaron resultados enriquecidos”.

Esta detección es especialmente importante en sitios de comercio electrónico o de reseñas, ya que Google necesita identificar atributos específicos como el precio, el estado del inventario y la calificación al mismo tiempo que indexa la página.

Si estos atributos faltan en el HTML de la “página probada”, aunque la página frontal se muestre con normalidad, la página de resultados de búsqueda (SERP) no presentará estrellas ni previsualizaciones de precios.

Se debe prestar especial atención a los registros de errores de la consola, ya que el entorno WRS tiene restricciones de uso de memoria más estrictas que el navegador de un usuario común.

Si un script consume demasiados recursos de CPU, Googlebot podría descartar el renderizado de esa página, dejando solo una plantilla vacía en el índice.

• Número total de recursos cargados: se recomienda limitar los recursos JS solicitados por una sola página a menos de 50. Demasiadas solicitudes paralelas pueden causar retrasos en la programación del WRS, aumentando el riesgo de fallos en el renderizado.
• Monitoreo de errores de ejecución de scripts: la herramienta capturará excepciones fatales como ReferenceError o TypeError que rompen la cadena de renderizado. Si se ven errores de incompatibilidad con la norma ES debido a la falta de Polyfill, se debe ajustar inmediatamente el objetivo de compilación de las herramientas de construcción.
• Validez de la respuesta de la API: compruebe los puntos finales de la API de todo el contenido extraído dinámicamente a través de la lista de recursos. Si el código de estado aparece como “Bloqueado” o “Tiempo de espera agotado”, indica que Googlebot ha sido bloqueado por un firewall o que el rendimiento de la API no alcanza el umbral de rastreo.

En el informe generado por esta herramienta de prueba, cada “advertencia” o “error” se corresponde con el comportamiento de Googlebot en un entorno de indexación real.

Si la herramienta indica que “no se pudieron cargar algunos scripts”, incluso si estos funcionan normalmente en el navegador Chrome de un usuario común, se debe tomar en serio, ya que esto podría deberse a que las IPs de los rastreadores de Googlebot sufrieron una limitación de frecuencia (Rate Limiting) por parte del servidor al acceder a esos recursos.

Chrome DevTools

En el entorno de desarrollo local, el panel de “Condiciones de red” (Network conditions) de Chrome DevTools es el punto de partida para simular el comportamiento de rastreo de Googlebot.

Presionando F12 o haciendo clic derecho y seleccionando “Inspeccionar” para abrir la barra de herramientas, entre en More tools -> Network conditions desde el menú de tres puntos en la esquina superior derecha.

En este panel, desmarque “Usar valores predeterminados del navegador” (Use browser default) y seleccione manualmente Googlebot en la lista desplegable.

Esta operación modificará la cadena User-Agent que envía el navegador, por ejemplo, cambiándola a Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).

El propósito de este paso es detectar si el servidor tiene una lógica especial dirigida a los rastreadores.

Si el servidor está configurado para devolver un código HTML diferente según el UA, el entorno local presentará inmediatamente resultados de respuesta drásticamente distintos a los de un acceso de usuario normal.

El personal técnico debe comparar la información de las cabeceras de respuesta en este momento, comprobando si han cambiado el Content-Type o las instrucciones de control de caché (Cache-Control).

Si el servidor devuelve un acceso denegado 403 o una redirección inesperada 301 para Googlebot, indica que la ruta de indexación del motor de búsqueda ha sido bloqueada a nivel del servidor.

Para simular la “primera ola de indexación” (First-wave indexing) de Googlebot, es imprescindible probar el comportamiento de la página con JavaScript desactivado.

Vaya a la página de configuración (Settings) de DevTools, busque la sección del depurador (Debugger) en las preferencias y marque “Desactivar JavaScript” (Disable JavaScript).

Tras refrescar la página, el navegador presentará únicamente la estructura HTML original servida por el servidor.

Para sitios que utilizan una arquitectura de aplicación de una sola página (SPA), esta operación suele resultar en una página completamente en blanco o que solo muestra una animación de carga.

Si la información de texto principal, los menús de navegación o las listas de productos de la página desaparecen por completo tras desactivar los scripts, indica que el motor de búsqueda debe entrar en la compleja “segunda ola de indexación”, es decir, la fase de renderizado WRS, para obtener el contenido.

En este punto, se debe registrar el número de bytes del HTML original, por ejemplo, 15 KB de código de marco base, y compararlo con el DOM tras el renderizado completo para determinar la escala del contenido inyectado por JS.

“En un entorno de simulación local, desactivar JavaScript es la prueba de estrés más efectiva. Si el HTML original de una página carece de etiquetas H1 o párrafos de cuerpo que contengan información semántica principal, esa página corre un riesgo muy alto de ser indexada como una página en blanco ante fluctuaciones del entorno de red o escasez de cuota de renderizado de Google.”

El entorno en el que se ejecuta Googlebot no es una computadora de escritorio de alto rendimiento; utilizando el panel de “Rendimiento” (Performance) en DevTools, se puede simular de forma más realista la capacidad de cómputo de Googlebot.

En la configuración de rendimiento, ajuste la limitación de CPU (CPU Throttling) a una reducción de velocidad de 4x o 6x.

Si una tarea de renderizado que solo tarda 800 milisegundos en una MacBook de alto rendimiento aumenta a 5500 milisegundos con una reducción de 6x, ya se ha alcanzado el umbral común de renderizado de 5 segundos de Googlebot.

Al observar las tareas largas (Long Tasks) en el gráfico de llamas, se pueden identificar qué bibliotecas JS voluminosas están bloqueando el hilo principal, causando retrasos en el renderizado.

Si indicadores cuantitativos como el tiempo de bloqueo total (TBT) superan los 2000 milisegundos en este entorno, generalmente predice que Googlebot podría desistir de esperar antes de que el contenido se genere por completo, optando por capturar la instantánea actual de un DOM incompleto.

Validación manual del navegador

La validación manual confirma el estado del renderizado comparando las diferencias de datos entre el Initial HTML y el Rendered DOM.

Googlebot utiliza el último motor de renderizado de Chrome, pero si la ejecución de JS supera el umbral de 5 segundos o si las solicitudes de recursos de una sola página superan las 50, es posible que el contenido no sea indexado.

Las pruebas manuales deben centrarse en la cadena de carga de recursos, asegurándose de que el atributo href de la etiqueta <a> sea previsible en el código fuente HTML, en lugar de generarse dinámicamente a través de eventos onclick, para garantizar la conectividad de la ruta del rastreador.

Código fuente y DOM en tiempo real

El código que se ve a través de view-source en el navegador refleja el flujo de texto original enviado por el servidor, mientras que el panel Elements de las herramientas de desarrollo muestra el modelo de objetos de memoria (DOM) tras haber sido analizado por el motor de renderizado, ejecutado los scripts y corregido los errores.

Para sitios que utilizan una arquitectura de aplicación de una sola página (SPA), el código fuente original a menudo solo contiene una etiqueta de contenedor vacía con id="app" o id="root" y varias referencias a scripts con un tamaño total superior a 500 KB.

Al comparar la cantidad de caracteres de texto plano en el código fuente con la cantidad en el DOM renderizado, cuando esta proporción supera el 1:20 (es decir, el HTML original solo tiene 100 palabras mientras que tras el renderizado alcanza las 2000), la primera ola de rastreo del motor de búsqueda casi no podrá obtener ninguna información semántica válida.

Esta diferencia provocará que la página se encuentre en un vacío de contenido durante el inicio de la indexación, debiendo esperar al procesamiento secundario de la cola de renderizado.

Dimensión de comparación	Características de los datos del Código Fuente Original (Initial HTML)	Características de los datos del DOM Renderizado (Rendered DOM)	Impacto de la diferencia técnica en la indexación
Número total de nodos DOM	Normalmente menos de 50 nodos, estructura extremadamente plana.	Puede superar los 1500 nodos, aumenta la profundidad de niveles.	Un aumento drástico de nodos indica que la generación de contenido depende totalmente de JS.
Estado de etiquetas Meta	Contiene títulos genéricos o descripciones de marcadores de posición fijos.	Contiene etiquetas SEO específicas de la página inyectadas dinámicamente por scripts.	Las herramientas de rastreo pueden registrar metadatos de página erróneos antes de que se ejecuten los scripts.
Etiqueta Canonical	Ausente o apunta a la URL fija de la página de inicio del sitio.	Actualizada dinámicamente a la ruta absoluta estándar de la página actual.	La inconsistencia de las etiquetas provocará conflictos de análisis en las propiedades de la página para el motor de búsqueda.
Datos estructurados JSON-LD	Vacío en el segmento de código o solo con el marco básico de Schema.	Relleno con datos completos de precios de productos, reseñas o inventario.	Determina si la página de resultados de búsqueda (SERP) puede mostrar fragmentos enriquecidos.
Enlaces internos (Internal Links)	La barra de navegación puede estar vacía, los enlaces aún no se han generado.	Contiene etiquetas <a> completas y rutas de categorías dinámicas.	Afecta la eficiencia del rastreador para descubrir otras URL profundas dentro del sitio.

Al realizar una comparación profunda, introduciendo document.body.innerText.length en la consola se puede obtener el número total de caracteres tras el renderizado actual para compararlo con el tamaño en bytes del archivo de código fuente.

Si el tamaño del código fuente es de 30 KB, pero el innerText tras el renderizado alcanza los 15,000 caracteres, todo el peso del texto principal se concentra en la capa de renderizado.

En este caso, si existe en el script una función recursiva que tarda más de 200 ms en ejecutarse, o se referencia una API externa con un tiempo de carga superior a 2.0 s, el motor de renderizado de Googlebot podría dejar de registrar antes de que el contenido se inyecte por completo debido a las estrategias de asignación de recursos.

Indicador cuantitativo	Umbral de riesgo	Consecuencias reales para el rastreo y la indexación
Tasa de diferencia de texto de código (Text Ratio Gap)	> 80% del texto generado por JS	La página es muy propensa a ser juzgada como “contenido pobre” en entornos sin scripts.
Tasa de éxito de extracción de enlaces	< 5 etiquetas <a> válidas en el código fuente	El presupuesto de rastreo (Crawl Budget) se desperdiciará en una espera interminable.
Uso de memoria por ejecución de scripts	Consumo de memoria de pila superior a 50 MB	El servidor de renderizado podría terminar forzosamente la tarea debido a límites de memoria.
Integridad del HTML en la parte superior	< 10% del contenido visual principal visible en el código fuente	Los usuarios verán una pantalla blanca prolongada en redes lentas, dañando las señales de clasificación.

Compruebe el menú de navegación en el panel Elements; si un enlace aparece como <a href="javascript:void(0)" onclick="navigateTo('/page')">, aunque parezca un enlace en el DOM renderizado, para el rastreador del motor de búsqueda es un callejón sin salida que no puede seguir.

El atributo href estándar debe existir ya en el HTML original devuelto por el servidor, o generarse con el formato estándar <a href="/target-path"> tras la ejecución del script.

Los sitios con una estructura de enlaces HTML original completa suelen ver sus nuevas páginas indexadas entre un 40% y un 70% más rápido que los sitios que dependen totalmente de la inyección de enlaces por JS.

Si en el código fuente existe una etiqueta meta noindex y la lógica del script intenta eliminarla y reemplazarla por index tras el renderizado, esta práctica suele ser ineficaz.

Los motores de búsqueda suelen dar prioridad a las instrucciones encontradas en el HTML inicial, lo que provoca que la página no pueda entrar en el proceso normal de indexación.

Validación de simulación de entorno

Abra las herramientas de desarrollo (DevTools) en el navegador Chrome, presione Ctrl+Shift+P para invocar el menú de comandos, escriba Disable JavaScript y pulse Intro; este es el punto de partida para simular el estado del primer rastreo del motor de búsqueda.

Vuelva a cargar la página con los scripts desactivados; si la pantalla se muestra en blanco o solo con el marco básico, indica que el Initial HTML del lado del servidor no tiene ningún contenido de texto sustancial.

Para un archivo HTML de 100 KB, si el 90% de su contenido de texto depende de la carga posterior de un paquete comprimido de JavaScript de 2 MB, es muy probable que el motor de búsqueda solo registre una etiqueta de contenedor vacía ante retrasos en la red o errores de ejecución de scripts.

Parámetro de simulación	Estándar y valor de configuración	Resultados observados e indicadores de datos
Limitación de red (Network Throttling)	Fast 3G (simula 1.5 Mbps de bajada, 40 ms de retraso)	Si el renderizado del contenido principal tarda más de 5000 ms (5 s), la cola de renderizado de Google podría dejar de esperar.
Limitación de CPU (CPU Throttling)	Reducción de 4x (simula el rendimiento de un procesador móvil)	Cuando el tiempo de análisis de scripts (Script Evaluation) supera los 1.5 s, la ocupación prolongada del hilo principal retrasará el renderizado.
Simulación de User-Agent	Googlebot Smartphone (Chrome/W.X.Y.Z)	Compruebe si el servidor devuelve un error 403 o código específico de adaptación móvil.
Tamaño de la ventana (Viewport)	411 x 731 píxeles (ancho móvil estándar)	Confirme si el contenido se carga automáticamente sin realizar acciones de interacción como clics o deslizamientos.

Cambie la cadena User-Agent del navegador a Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).

Marque Disable cache en el panel Network y observe la cadena de carga de recursos bajo la identidad de Googlebot.

En el proceso de rastreo estándar, Googlebot normalmente no carga todos los archivos multimedia; prioriza el análisis del texto y los datos estructurados.

Si la página detecta el User-Agent mediante un script y aplica una lógica diferente, como cerrar ciertas interfaces asíncronas para el rastreador, la estructura DOM en el panel Elements será totalmente distinta a la que ve un usuario normal.

Establezca manualmente la velocidad de red en Fast 3G y limite el rendimiento de la CPU a una reducción de 4x en el panel Network.

Los recursos de computación asignados a una sola página por los servidores de renderizado de Googlebot son limitados al procesar miles de millones de páginas web en todo el mundo. Grabe el proceso de carga a través del panel Performance y fíjese especialmente en la actividad del hilo Main.

Si las tareas largas (Long Tasks) generadas por Evaluate Script superan los 50 milisegundos y el total ocupa más del 70% del ciclo de carga, entonces en un entorno de rastreo real, el motor de renderizado podría completar el registro de la instantánea antes de que el contenido se rellene por completo.

Si el intervalo entre First Contentful Paint (FCP) y Largest Contentful Paint (LCP) se amplía a más de 3 segundos debido a una ejecución prolongada de JS, la probabilidad de que el motor de búsqueda capture una página incompleta aumenta aproximadamente un 40%.

Utilice la pestaña Sensors en la parte inferior de las herramientas de desarrollo para simular manualmente diferentes ubicaciones geográficas (como San Francisco o Londres).

Los nodos de rastreo de Googlebot se distribuyen principalmente en los Estados Unidos; si la lógica JS del sitio incluye redirecciones automáticas basadas en la dirección IP o generación de contenido según la zona horaria local, esto podría causar que la versión de la página rastreada no coincida con la versión de la región de la audiencia objetivo.

Compruebe los mensajes de error en el panel Console, especialmente ReferenceError o TypeError.

Aunque la versión del motor de renderizado de Google (Evergreen Googlebot) se mantiene actualizada, puede haber diferencias en el soporte de algunas API web muy nuevas (como la última WebGPU o versiones específicas de WebAssembly).

Si no se ha realizado un tratamiento de compatibilidad con Polyfill en el código, el script se interrumpirá a mitad de camino, provocando que la construcción del árbol DOM se detenga.

• Límite de cantidad de solicitudes: cuente el número total de solicitudes de red emitidas antes de que se complete el renderizado. Si las solicitudes de una sola página superan los 50 recursos JS o CSS, algunos scripts podrían no cargarse a tiempo debido a los límites de concurrencia del navegador y las cuotas de recursos del rastreador.
• Estado de Shadow DOM: compruebe en el panel Elements si existe el marcador #shadow-root (closed). Googlebot puede analizar el Shadow DOM en modo Open, pero el contenido en modo Closed es invisible para el rastreador; asegúrese de que todos los Web Components estén en estado Open.
• Validación de formato de enlaces: busque etiquetas <a en el DOM renderizado usando Ctrl+F. Asegúrese de que todos los enlaces de redirección contengan el atributo href completo. Si el salto se controla mediante eventos JS como window.location.href o router.push y no se deja un ancla estándar en el HTML, el motor de búsqueda no podrá descubrir esas subpáginas.
• Carga diferida de imágenes (Lazy Load): compruebe si las etiquetas <img> han reemplazado el contenido de data-src por el atributo src sin necesidad de desplazarse por la página. Googlebot puede simular parte del desplazamiento, pero para scripts que dependen de escuchadores de eventos scroll complejos, el efecto de rastreo no es estable. Usar el atributo estándar loading="lazy" es una práctica más segura.

Compare el tamaño en bytes y el número de nodos de texto entre el Initial HTML y el Rendered DOM.

Si la diferencia en la cobertura de texto entre ambos supera el 80% y la mayor parte del contenido de texto se inyecta después del evento DOMContentLoaded, esto indica que el SEO del sitio depende en gran medida de la eficiencia del renderizado.

Se recomienda registrar el Total Blocking Time (TBT) en las pruebas; si este valor supera los 300 ms, normalmente predice que el proceso de ejecución del script obstaculizará el análisis del DOM por parte del rastreador.

Utilice el panel Coverage de Chrome para ver la tasa de utilización de los archivos JS; si el 80% del código en un script de 500 KB no se ejecuta durante la carga de la parte superior de la página, ese código redundante consumirá inútilmente capacidad de cómputo del servidor de renderizado, afectando la velocidad de indexación del contenido.

Herramientas de rastreo profesional

Las herramientas de rastreo profesional pueden simular el entorno de Chrome (como Screaming Frog v20+).

Los datos indican que el gasto de rastreo ejecutando scripts es 20 veces superior al del HTML estático.

Cuando la diferencia en el recuento de palabras HTML entre el “antes del renderizado” y el “después del renderizado” supera el 10%, o la diferencia en el número de enlaces internos identificados supera el 5%, la tasa de éxito de la indexación suele disminuir.

La detección debe centrarse en la tasa de finalización del renderizado en 5 segundos y si la carga de scripts falló debido a códigos de estado 403.

Screaming Frog SEO Spider

Al utilizar Screaming Frog para rastreos a gran escala, cambiar el modo de renderizado de “Solo texto (Text Only)” a “JavaScript” transformará el comportamiento del rastreador de simples solicitudes HTTP a una simulación completa de navegador.

El software iniciará instancias de Headless Chrome subyacentes para analizar cada archivo de script de la página web.

En cuanto a la configuración técnica, el usuario debe seleccionar explícitamente la opción JavaScript en el menú Configuration > Spider > Rendering.

Los cambios a nivel de datos son muy significativos; el proceso de rastreo ejecutando JavaScript suele aumentar la demanda de memoria (RAM) entre 5 y 10 veces.

Por ejemplo, al rastrear 100,000 páginas que contienen marcos complejos de React o Angular, se recomienda asignar al menos de 16 GB a 32 GB de RAM al software; de lo contrario, los procesos de renderizado de Chrome podrían colapsar por falta de recursos.

El rastreador simulará la versión del motor de renderizado de Chrome durante su ejecución, asegurando que la estructura DOM capturada sea coherente con el “Evergreen Chrome” que utiliza actualmente Googlebot.

Categoría de indicador	HTML original (Source)	HTML renderizado (Rendered)	Sugerencia de umbral de diferencia
Recuento de palabras (Word Count)	Contiene solo el marco base y metadatos	Contiene el texto cargado de forma asíncrona	Diferencia > 15% requiere revisión manual
Número de enlaces internos (Internal Links)	0 o muy pocos enlaces de marcador de posición	Enlaces de navegación y productos generados dinámicamente	Diferencia > 0 indica riesgo de rastreo
Etiqueta Canonical	Puede estar ausente o apuntar a un valor por defecto	Versión final modificada a través de JS	Debe tomarse como válida la versión renderizada
Tamaño de página (Size)	Normalmente < 50 KB	Puede aumentar hasta 500 KB – 2 MB	Un tamaño excesivo puede causar truncamiento por Google

Cuando el software simula la ejecución de scripts, el ajuste predeterminado de AJAX Timeout (tiempo de espera de carga asíncrona) suele ser de 5 segundos, similar a la estrategia de Googlebot.

Si la interfaz de datos de una página responde lentamente, provocando que el contenido se rellene en el DOM después de los 5 segundos, el resultado capturado por Screaming Frog será una página “vacía”.

A través de la columna de datos Word Count, se puede cuantificar este fenómeno:

Si el número de palabras tras el renderizado es menor que en el código fuente, o si ambos son idénticos pero la página tiene en realidad mucho texto, normalmente indica que el script de renderizado no pudo completarse en el tiempo estipulado.

En pruebas dirigidas a sitios de comercio electrónico, si la lista de productos se carga mediante desplazamiento dinámico, el rastreador también puede configurarse con “Window Size” o simular una acción de desplazamiento hacia abajo para activar la ejecución de scripts, capturando así la información de productos que originalmente estaba oculta.

Para auditorías técnicas de sitios grandes, el uso de la función “JavaScript Rendering Table” en “Bulk Export” permite exportar un informe de diferencias de renderizado de todo el sitio.

Este informe enumerará fila por fila los cambios en las etiquetas Title, Meta Description y H1 de cada URL antes y después del renderizado.

En casos reales, si se descubre que la etiqueta H1 tras el renderizado se convierte en “Loading…” o “Undefined”, esto demuestra que el motor de búsqueda está capturando código de estado intermedio en lugar del contenido final.

La pestaña “Resource” del software registrará el código de estado HTTP de cada archivo de script (.js) y hoja de estilo (.css).

Si ciertos scripts funcionales devuelven un 403 Forbidden, suele deberse a que el firewall del servidor (WAF) identificó erróneamente el comportamiento de Headless Chrome del rastreador como un ataque malicioso y lo bloqueó, lo que impedirá que el diseño y el contenido de toda la página se presenten correctamente.

Estado del recurso de renderizado	Causa del suceso	Impacto en el rastreo
Blocked by robots.txt	La ruta del script se estableció como Disallow	Googlebot no puede leer el script, fallo de renderizado
Status Code: 429	Frecuencia de solicitudes demasiado alta, activando la limitación	Carga incompleta de recursos, falta de contenido
Status Code: 404	Ruta del archivo de script inválida	Los componentes dinámicos que dependen de ese script no se muestran
Timeout (Exceeded 5s)	Respuesta de interfaz lenta o lógica de script compleja	El HTML capturado está vacío o contiene avisos de error

La vista “Rendered Page” que ofrece el software permite a los usuarios comparar en paralelo la instantánea del código original con la instantánea visual renderizada.

De esta manera, se pueden descubrir visualmente aquellos contenidos ocultos por JavaScript, como el texto ubicado en pestañas (Tabs) que solo se muestran tras hacer clic.

Si el contenido de texto de una página representa menos del 20% en el HTML original y el 80% depende de la generación por renderizado, la estabilidad de esa página en el índice de Google enfrentará desafíos.

Screaming Frog también puede capturar Console Errors (errores de consola); si la página genera un error de sintaxis de JavaScript fatal durante la carga, el software lo resaltará en el informe.

Al tratar con cientos de miles de URL, se recomienda activar las opciones “Store Images” y “Store Rendered HTML”, lo que permite recuperar la instantánea de renderizado de cualquier página en cualquier momento una vez finalizado el rastreo.

Mediante el análisis de la diferencia en “Link Discovery”, se puede calcular qué proporción de enlaces internos requieren necesariamente la ejecución de scripts para ser descubiertos.

Si esta proporción supera el 30%, la profundidad de rastreo (Crawl Depth) del sitio puede volverse incontrolable debido al retraso en la ejecución de los scripts.

Lumar (DeepCrawl)

Lumar utiliza capacidad de cómputo distribuida en la nube, diseñada específicamente para el escaneo automatizado de sitios grandes con millones de URL.

Al procesar tareas que requieren la ejecución de JavaScript, funciona en segundo plano mediante miles de instancias de navegadores simulados.

Las herramientas locales convencionales están limitadas por la memoria física; por ejemplo, una computadora con 32 GB de RAM ejecutando el modo de renderizado normalmente solo puede admitir de 20 a 50 hilos paralelos.

En cambio, Lumar se ejecuta en servidores en la nube y puede expandirse automáticamente a más de 500 hilos según la escala de la tarea, asegurando completar el rastreo de renderizado completo de 1 millón de páginas en 24 horas.

Si la ejecución del script de una página supera los 5000 milisegundos (es decir, 5 segundos), el sistema marcará esa URL como una “página de alto costo”, ya que Googlebot normalmente no esperará demasiado por un solo recurso en el acceso real, lo que resultaría en un espacio en blanco en el índice.

En un proyecto estándar de React o Vue, el HTML original puede contener solo de 2 KB a 5 KB de código de marco base, mientras que el árbol DOM (DOM Tree) tras el renderizado puede expandirse de 300 KB a 800 KB.

Este crecimiento de bytes de más de 100 veces indica que la página depende extremadamente de los scripts.

Los indicadores proporcionados por Lumar incluyen el número total de nodos DOM (DOM Node Count); si el número de nodos supera los 1500 recomendados por Google, la eficiencia del renderizado disminuirá drásticamente.

Al registrar en la nube el Time to Interactive (tiempo hasta que es interactiva) y el Total Blocking Time (tiempo de bloqueo total), esta herramienta puede identificar qué archivos JS (por ejemplo, un solo paquete vendor.js de más de 500 KB) están impidiendo la visualización normal del contenido.

Para sitios de comercio electrónico grandes o multinacionales, al realizar solicitudes desde nodos de servidores en diferentes regiones, se puede detectar si ciertos scripts encargados de renderizar contenido no se cargan en áreas específicas debido a errores de configuración de la CDN.

Los informes de datos enumerarán la proporción de recursos de scripts con códigos de estado 4xx y 5xx.

Si el 20% de las solicitudes de scripts de una página devuelven un error 403 (normalmente debido al bloqueo por robots.txt o firewall), el resultado del renderizado de esa página estará incompleto.

El sistema de informes de Lumar generará un “mapa de diferencias de renderizado”, detallando los cambios en el número de enlaces internos de la página con el JavaScript activado y desactivado.

Si tras desactivar los scripts, el número de enlaces en la página se reduce de 200 a 0, indica que la estructura de direccionamiento del sitio depende totalmente de la ejecución dinámica, lo cual tiene un impacto negativo en la velocidad con la que Googlebot descubre nuevas páginas.

La plataforma también admite la integración de los datos de renderizado capturados con la API de Google Search Console.

Si los datos muestran que el número de palabras aumentó un 300% tras el renderizado, pero el tráfico de búsqueda no ha aumentado proporcionalmente, podría indicar que el contenido insertado dinámicamente no ha sido reconocido eficazmente por Google.

Lumar proporcionará el indicador Rendered Page Word Count y lo comparará con el Source HTML Word Count.

Las páginas con una mayor diferencia de proporción (Ratio Gap) suelen mostrar un comportamiento más inestable en la frecuencia de rastreo. Tras observar más de 500,000 muestras, cuando el Rendering Gap supera el 80%, el retraso en la indexación de la página suele aumentar de 3 a 7 días.