El SEO para JavaScript arrastra todavía una idea recibida persistente: Google procesaría las páginas en «dos oleadas de indexación», con días o semanas de espera entre la lectura del HTML y la ejecución del JavaScript. Ese modelo, presentado por Google en 2018, ya no figura en su documentación. El renderizado funciona hoy como una cola asíncrona, y la documentación indica que una página espera allí normalmente unos segundos, a veces más. La pregunta útil ya no es cuándo ejecutará Google tu JavaScript, sino qué ha retenido realmente una vez terminado el renderizado. Esa información existe: la herramienta de inspección de URLs y el informe «Indexación de páginas» de Google Search Console registran, para cada URL, el veredicto emitido después de ejecutar el JavaScript. Dos preguntas organizan el diagnóstico: qué estados delatan un renderizado fallido, y cómo comprobar qué ha indexado Google sin fiarse del renderizado del propio crawler.
Cómo procesa Google el JavaScript hoy
Google procesa las páginas JavaScript en tres fases: rastreo, renderizado e indexación («Google processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing»). Googlebot lee primero el HTML que devuelve el servidor, coloca después la página en una cola de renderizado, un Chromium sin interfaz ejecuta el JavaScript («Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript»), y la indexación se aplica al resultado de ese renderizado.
Dos precisiones de la documentación actual corrigen creencias extendidas. Primera: la espera en la cola de renderizado se mide normalmente en segundos («The page may stay on this queue for a few seconds, but it can take longer than that»). Las esperas de varios días entre una «primera oleada» y una «segunda oleada» pertenecen a un modelo que Google ya no usa en su documentación, y el «límite de 5 segundos de ejecución», tan citado, tampoco aparece en ella. Segunda: el renderizado sigue sin estar garantizado; depende de los recursos de Google, y algunas instrucciones lo anulan. La documentación precisa, por ejemplo, que ante una etiqueta noindex Google puede saltarse el renderizado por completo («When Google encounters the noindex tag, it may skip rendering and JavaScript execution»): un script que retira un noindex colocado en el HTML inicial probablemente no se ejecutará nunca.
El motor de renderizado de Google tiene además sus propias reglas, distintas de las de un navegador. Rechaza las solicitudes de permisos («Expect Googlebot to decline user permission requests»), no abre conexiones WebSocket ni WebRTC, y no conserva ningún estado entre cargas: «Local Storage and Session Storage data are cleared across page loads. HTTP Cookies are cleared across page loads». Un contenido que dependa de una cookie, de una sesión o de una interacción del usuario tiene muchas probabilidades de no aparecer nunca en la versión renderizada.
El renderizado de tu crawler no es el veredicto de Google
Para revisar una página JavaScript, el reflejo habitual consiste en lanzar un crawler en modo renderizado (Screaming Frog, Sitebulb o la auditoría de una suite SEO) y comparar el HTML inicial con el DOM renderizado. Esa comparación es útil, pero tiene un límite estructural: muestra lo que tu herramienta ha renderizado, con su motor, sus tiempos y sus ajustes. No dice qué ha renderizado Google, y sobre todo no dice qué ha decidido indexar.
Los dos resultados pueden divergir por razones corrientes: un script bloqueado para Googlebot pero accesible para tu crawler, una llamada de red que expira del lado de Google, un recurso cacheado en una versión antigua, un contenido condicionado a un estado que el motor de Google borra (cookies, localStorage), o simplemente una ejecución parcial. Una página puede parecer completa en tu auditoría y quedar indexada incompleta por Google, sin que ningún error se muestre en ninguna parte.
Existe una fuente que zanja la cuestión: el veredicto oficial. La inspección de URLs de Search Console muestra el HTML renderizado por el propio Google, los recursos cargados y las excepciones de JavaScript encontradas. Y el informe «Indexación de páginas» registra la decisión final, URL a URL. Dicho de otro modo, para saber si tu JavaScript causa un problema de SEO no basta con perfeccionar tu propio renderizado: hay que leer lo que Google concluyó del suyo.
La tabla: síntoma de renderizado, estado, causa, corrección
Cada fallo de renderizado deja una huella reconocible en el informe de indexación. La tabla resume las correspondencias más frecuentes en los sitios con mucho JavaScript; otros estados siguen siendo posibles según la configuración.
| Síntoma | Estado más frecuente | Causa probable |
|---|---|---|
| El HTML inicial es un shell, el contenido llega con el JS | «Explorada, actualmente no indexada», o página indexada vacía | Renderizado incompleto o juzgado de poco valor |
| Enrutado cliente, URLs que muestran un estado vacío | «Soft 404» | Sin código de error real, página «no encontrada» servida como 200 |
| Sitio grande, JS pesado, páginas recientes en espera | «Descubierta, actualmente no indexada» | Cola de renderizado y presupuesto de rastreo |
| Etiquetas inyectadas o modificadas por JS (canonical, title, robots) | Estados de duplicado | Directivas divergentes entre HTML inicial y renderizado |
| Contenido inyectado, lazy loading, hydration defectuosa | Según el caso: rastreada sin el contenido, duplicados | El contenido no existe en la versión renderizada |
El shell CSR: renderizado, leído, descartado
En una página con client-side rendering, el HTML inicial no contiene casi nada; todo llega con el JavaScript. Cuando el renderizado funciona y el contenido convence, la página se indexa con normalidad. Cuando el renderizado falla o el resultado parece pobre, dos veredictos aparecen con más frecuencia: «Explorada, actualmente no indexada», cuando Google leyó la página renderizada y no la retuvo, y el caso más engañoso de la página indexada sin contenido, cuando Google indexa el shell renderizado vacío: la página figura en el índice, pero no aparece en ninguna búsqueda útil. Este segundo caso es el más emblemático del JavaScript, porque nada parece anómalo hasta que se compara lo indexado con lo que debía indexarse.
El enrutado cliente y los estados vacíos: «Soft 404»
En una aplicación con enrutado JavaScript, una URL inexistente no devuelve un código 404: el servidor responde 200 y el JavaScript muestra «sin resultados». Google reconoce ese patrón y clasifica estas páginas como «Soft 404». Su documentación dedica una sección entera a evitarlo con renderizado en cliente, devolviendo un código de error real desde el servidor o señalando el estado de error en la página renderizada. Fichas de producto agotadas, búsquedas sin resultados o rutas de respaldo mal configuradas pueden alimentar este estado en serie.
El JavaScript pesado en sitios grandes: la espera que se alarga
El renderizado consume recursos, del lado de Google y del tuyo. En un sitio voluminoso donde cada página exige una ejecución completa de JavaScript, el rastreo y el renderizado se ralentizan, y las páginas recientes se acumulan en «Descubierta, actualmente no indexada»: Google conoce la URL y todavía no la ha procesado. Este mecanismo conecta con el presupuesto de rastreo: cuanto menos cuesta procesar cada página, más páginas procesa Google. Servir el contenido esencial en el HTML inicial sigue siendo la recomendación de la documentación, que señala que el renderizado en servidor o el pre-renderizado «makes your website faster for users and crawlers».
Las etiquetas inyectadas por JavaScript: directivas que divergen
Un title, una canónica o una etiqueta robots que solo existen en la versión renderizada crean una situación ambigua: el HTML inicial dice una cosa y el DOM renderizado dice otra. Según el momento y la directiva, Google puede quedarse con una u otra versión, y ante directivas contradictorias aplica la más restrictiva. Los veredictos resultantes son los estados de duplicado: «Página duplicada sin URL canónica» cuando la canónica inyectada no se tuvo en cuenta, o «Página duplicada: Google eligió otra canónica» cuando falló en contra de tu declaración. La regla más segura consiste en colocar las directivas de indexación (canonical, robots, title) en el HTML inicial y no en el JavaScript.
Los problemas fuera de las SPA: contenido inyectado, lazy loading, hydration
El tema no se limita a las aplicaciones de página única. Un sitio clásico puede inyectar bloques enteros por JavaScript: reseñas de clientes, características de producto, FAQs, contenidos recomendados. Si el script falla del lado de Google, la página se indexa sin esos bloques, y nada lo señala. Un lazy loading mal configurado produce el mismo efecto: un contenido cargado solo al hacer scroll no existe para un motor de renderizado que no se desplaza como un usuario, y la documentación remite a sus directrices dedicadas para cargarlo de forma detectable. Las listas de scroll infinito reciben el mismo tratamiento, detallado en nuestro artículo sobre la paginación. Por último, en los frameworks híbridos, una hydration defectuosa puede sustituir un HTML de servidor correcto por un estado de cliente degradado. En todos estos casos el mecanismo es idéntico: la versión renderizada no contiene lo que crees haber publicado, y solo el veredicto de Google lo muestra.
El caso de las SPA
Una aplicación de página única (React, Vue, Angular) concentra estos problemas en su forma más aguda: todo el contenido depende del renderizado, el enrutado es enteramente de cliente y el fallo no produce ningún error visible. Ese caso tiene su artículo dedicado, con los cuatro estados que delatan una SPA mal indexada y el triaje que conviene hacer antes de pasarlo todo a SSR: SEO de SPA en React.
Diagnosticar a escala: los veredictos de Google sobre tus URLs con mucho JavaScript
La inspección de URLs muestra el renderizado de Google para una página. Es la herramienta de la prueba, no la del diagnóstico de conjunto: en un sitio donde miles de páginas dependen del JavaScript, la pregunta no es «¿está bien renderizada esta URL?» sino «¿qué parte de mis páginas con mucho JavaScript está realmente indexada, y con qué motivos de exclusión?».
El método consiste en inspeccionar en masa una lista de URLs que tú controlas: tu sitemap, una exportación o una selección construida desde Search Console con un patrón de URL. Eso es exactamente lo que hace IndexProbe: no renderiza tu JavaScript en local, consulta la API oficial de inspección y lee el veredicto que Google emitió tras su propio renderizado, URL a URL. Frente al JavaScript, esa diferencia con un crawler es decisiva: el resultado no es una simulación más, es la decisión del propio Google.
Con una segmentación por tipo de renderizado (generada por IA o definida a mano: páginas servidas en HTML completo, plantillas en client-side rendering, bloques inyectados, vistas con enrutado cliente), la lectura se vuelve directa: ¿concentran los segmentos con mucho JavaScript los estados de fallo de renderizado, o se comportan como las páginas servidas en HTML? Una diferencia clara entre las dos familias señala al renderizado como causa, antes incluso de abrir una sola página.
💡 Tu crawler puede renderizar 10.000 páginas a la perfección; eso no dice cuántas ha indexado Google tras su propio renderizado. Descubre IndexProbe en acceso anticipado →
Comprobar tras la corrección: el renderizado es asíncrono
Corregir un problema de renderizado (pasar una plantilla a SSR, servir el contenido esencial en el HTML inicial, reparar un lazy loading) no cambia el informe de indexación de inmediato. Google tiene que volver a pasar por cada URL, renderizarla de nuevo y decidir de nuevo, y ese ciclo depende de su cola de renderizado y de la frecuencia de rastreo de cada página. La comprobación exige por tanto un seguimiento con fechas: relanzar el mismo análisis sobre la misma lista de URLs unas semanas después del despliegue, y comparar.
Tras un paso a SSR, las páginas del segmento corregido deben salir de «Explorada, actualmente no indexada» y volver al índice; los «Soft 404» de enrutado deben apagarse a medida que Google ve los códigos de error reales; los duplicados ligados a etiquetas inyectadas deben resolverse. La vista Comparación de IndexProbe pone los dos análisis frente a frente, estado por estado, y el relanzamiento programado convierte esa comprobación en vigilancia: una regresión de renderizado introducida por una actualización del framework se detecta por el cambio de veredicto, antes de la caída de tráfico.
El recorrido completo: entender qué hace Google con tu JavaScript, leer los veredictos que emitió tras su renderizado, corregir lo que señalan y confirmar después el cambio en el tiempo. Prueba IndexProbe en acceso anticipado y lee esos veredictos sobre el conjunto de tus URLs con mucho JavaScript, en un solo análisis.
Preguntas frecuentes
¿Indexa Google el contenido JavaScript?
Sí. Google ejecuta el JavaScript con un Chromium sin interfaz e indexa el resultado del renderizado. El punto de atención no es la capacidad de Google para renderizar, sino el resultado del renderizado en cada página: un script bloqueado, una llamada que expira o un contenido que depende de una interacción pueden producir una versión renderizada incompleta, y esa es la versión que se indexa.
¿Es malo el client-side rendering para el SEO?
No en sí mismo: una página en CSR correctamente renderizada se indexa. El CSR añade, eso sí, una etapa falible entre la publicación y la indexación, y sus fallos son silenciosos. La documentación de Google recomienda el renderizado en servidor o el pre-renderizado, más rápidos para usuarios y robots; la elección se hace plantilla a plantilla, según lo que muestren los veredictos de indexación.
¿Cómo sé qué ha renderizado Google realmente en mi página?
Con la herramienta de inspección de URLs de Search Console: muestra el HTML renderizado por Google, los recursos cargados y las excepciones de JavaScript encontradas. Es la única fuente que enseña el renderizado de Google en lugar de una simulación. Para un sitio entero, la lectura se hace con los estados del informe «Indexación de páginas», en masa.
¿Siguen existiendo las «dos oleadas de indexación»?
Ese modelo ya no figura en la documentación de Google. El renderizado funciona como una cola asíncrona, donde una página espera normalmente unos segundos, a veces más. Las largas esperas sistemáticas entre la lectura del HTML y la ejecución del JavaScript describen el estado de 2018, no el funcionamiento actual.
¿Es obligatorio el SSR para posicionar bien?
No. Páginas en renderizado de cliente se indexan correctamente todos los días. El SSR o el pre-renderizado cobran sentido cuando los veredictos muestran un problema: segmentos CSR que concentran la «Explorada, no indexada», páginas indexadas vacías, una cola que se alarga en un sitio grande. La decisión sigue a esas observaciones, no a un principio.
¿Cuánto tarda Google en renderizar una página JavaScript?
La documentación habla de una espera en la cola de renderizado de unos segundos, a veces más, sin plazo garantizado. En la práctica, el plazo total depende sobre todo de la frecuencia de rastreo de la página y de los recursos que consume el sitio: en un sitio grande con JavaScript costoso, la espera se lee en la acumulación de páginas «Descubierta, actualmente no indexada».