React, Vue o Angular permiten construir single-page applications (SPA): una sola página HTML, navegación sin recargas, una experiencia fluida para el usuario. En cambio, de cara al SEO, esa arquitectura tiene un reverso: el contenido solo existe una vez que se ejecuta el JavaScript y, en ciertas condiciones, nunca llega al índice de Google. Y eso no se juzga a simple vista: Google lo registra en el informe «Indexación de páginas» de Search Console, a través de cuatro estados que se repiten en este tipo de sitios.
¿Cuáles? ¿Qué revela cada uno sobre lo que Googlebot vio de verdad de la página? ¿Y cómo saber, a escala de un sitio entero, qué vistas acabó indexando Google y cuáles dejó de lado?
No aparece ningún error. El veredicto, en cambio, ya está escrito.
Qué es una SPA para Googlebot
Para Googlebot, una single-page application se presenta al principio como un armazón HTML casi vacío. El contenido, los enlaces y los metadatos solo existen una vez que se ejecuta el JavaScript, que los inyecta en la página del lado del navegador. Googlebot tiene que renderizar la página, por tanto, para llegar a lo que un usuario ve en pantalla.
Ese renderizado no sigue de inmediato al rastreo. Google rastrea primero el HTML en bruto, coloca la página en una cola de renderizado y luego ejecuta el JavaScript con una versión de Chromium antes de indexar el resultado. Google Search Central describe esa cola sin garantizar el plazo: «la página puede permanecer en esta cola unos segundos, pero puede tardar más que eso». Entre el rastreo y el renderizado, tu contenido permanece invisible para el índice.
Ese desfase entre rastreo y renderizado está en el corazón de los retos de rastreo e indexación propios del JavaScript. El funcionamiento detallado de ese motor de renderizado, cómo ejecuta Google el JavaScript y qué pesa sobre el presupuesto de renderizado, será objeto de un artículo próximamente. Aquí lo que importa es la consecuencia: mientras el renderizado no se completa, una SPA apenas expone nada que indexar.
Google lee el JavaScript, y aun así recomienda el renderizado en el servidor
Circulan dos ideas opuestas, y ambas son falsas. Por un lado, la idea de que Google «no lee el JavaScript»: falsa, Googlebot lleva años renderizando las páginas con una versión actualizada de Chromium. Por otro, la idea de que «lo renderiza todo sin esfuerzo»: también falsa, porque el renderizado se pospone, es costoso, y el entorno de renderizado no conserva nada de una página a otra.
Por eso Google Search Central no se limita a decir que gestiona el JavaScript. La documentación recomienda evitarlo: «ten en cuenta que el renderizado en el servidor o el prerenderizado sigue siendo una gran idea, porque hace que tu sitio sea más rápido para los usuarios y los rastreadores, y no todos los bots pueden ejecutar JavaScript». Dicho de otro modo, la empresa que mejor renderiza el JavaScript aconseja, aun así, entregarle el HTML directamente.
El renderizado JavaScript es, por tanto, una palanca real, ni una fatalidad ni una catástrofe. Funciona, pero añade un paso más donde las cosas pueden fallar sin hacer ruido. Y cuando fallan, dejan un rastro preciso.
Los 4 estados de Search Console que delatan una SPA mal indexada
Cuando el renderizado de una SPA falla, Google no muestra ningún mensaje de error. Sencillamente archiva la página bajo un estado de indexación. Cuatro estados, en particular, son la firma de un problema de renderizado. Cada uno corresponde a un momento preciso en que el proceso se salió de la vía.
| Modo de fallo de la SPA | Estado en Search Console | Qué hizo Google |
|---|---|---|
| El renderizado nunca ocurrió | Descubierta, actualmente no indexada | URL conocida, ni rastreada ni renderizada |
| Renderizado hecho, pero vista juzgada pobre | Explorada, actualmente no indexada | Rastreada y renderizada, valor no conservado |
| Un 200 devuelto en una vista vacía | Soft 404 | Servida con 200 pero percibida vacía |
| El armazón indexado antes de terminar el renderizado | Página indexada sin contenido | Indexada, pero sin el contenido esperado |
Descubierta, actualmente no indexada
«Descubierta, actualmente no indexada» es el estado de las páginas que Google conoce pero aún no ha rastreado y, por tanto, aún no ha renderizado. En una SPA sube rápido cuando el sitio expone miles de vistas mediante el enrutamiento del lado del cliente: Google descubre las URLs, las pone en cola, pero no encuentra tiempo para procesarlas todas. El renderizado no es el culpable aquí; sencillamente nunca ocurrió. Suele ser señal de un presupuesto de rastreo bajo presión.
Explorada, actualmente no indexada
«Explorada, actualmente no indexada» cuenta lo contrario: Google sí rastreó y renderizó la página, pero no la consideró digna de conservar. En una SPA se repiten dos causas. O el renderizado produjo una vista demasiado pobre, contenido todavía cargando o una llamada a la API que falló en el momento del renderizado; o varias vistas se parecen demasiado, por falta de un título y una descripción propios. Google vio la página. No lo convenció.
Soft 404
Una Soft 404 ocurre cuando una vista devuelve un código HTTP 200 cuando en realidad está vacía o en error. Es la trampa clásica del enrutamiento del lado del cliente: sin un servidor que devuelva un 404 de verdad, una URL inexistente muestra un armazón «página no encontrada» con un 200. Google Search Central lo describe sin rodeos: las single-page applications devuelven a menudo «un código HTTP 200 en lugar del código apropiado». Google lo detecta y archiva la página como Soft 404.
Página indexada sin contenido
«Página indexada sin contenido» es el más insidioso de los cuatro. Google indexó la URL, pero en la fase de armazón, antes de que terminara el renderizado. La página existe en el índice, vacía o casi. Para una SPA es el escenario en que Googlebot obtuvo el HTML inicial, lo conservó, pero donde el contenido que inyecta el JavaScript nunca llegó a la versión indexada.
Las trampas estructurales de una SPA, documentadas por Google
Más allá del renderizado en sí, la arquitectura de una SPA acumula trampas que Google documenta con precisión. Tienen un punto en común: privan a Googlebot de una referencia que los sitios clásicos le dan gratis, una URL limpia, un enlace que se pueda seguir, una etiqueta estable.
La primera tiene que ver con las URLs. Históricamente, las SPA cambiaban de vista modificando la parte de la dirección situada después del #. Google ya no sigue ese mecanismo: «el esquema de rastreo AJAX está obsoleto desde 2015, así que no puedes contar con que los fragmentos de URL funcionen con Googlebot. Recomendamos usar la History API». Cada vista que quieras indexar necesita su propia URL real.
Luego vienen los enlaces. Un enlace disparado por un onClick sobre un <div> no es un enlace para Googlebot. Sin una etiqueta <a href>, no descubre la vista de destino ni le transmite ninguna señal. La misma lógica vale para el contenido que solo aparece tras una interacción, un clic en una pestaña o la apertura de un acordeón: Googlebot no hace clic. Lo que importa debe estar en el renderizado inicial, no detrás de una acción del usuario.
Quedan las etiquetas. Inyectar la canónica en JavaScript es arriesgado: «no deberías usar JavaScript para cambiar la URL canónica por otra distinta», advierte Google Search Central. La misma cautela para la etiqueta meta robots: «usar JavaScript para cambiar o quitar la etiqueta meta robots de noindex puede no funcionar como esperas». Una página que se deja en noindex en el HTML inicial puede seguir así a ojos de Google, haga lo que haga el script después. Por último, el entorno de renderizado no guarda memoria de una página a otra: «los datos de Local Storage y Session Storage se borran entre cargas de página. Las cookies HTTP se borran entre cargas de página». Una vista cuyo contenido depende de un estado guardado del lado del cliente puede, por tanto, aparecer vacía en el renderizado.
💡 Antes de corregir nada, primero hay que saber cuáles de tus vistas indexó Google de verdad, y bajo qué estado. Descubre IndexProbe en acceso anticipado →
¿De verdad necesitas SSR?
No todas las vistas de una SPA necesitan indexarse. Antes de pasarlo todo a renderizado en el servidor, la pregunta correcta no es técnica sino editorial: ¿esta vista busca atraer tráfico desde la búsqueda? La respuesta decide el esfuerzo, no al revés.
Separa tus vistas en dos familias. Por un lado, las que deben posicionarse: página de inicio, fichas de producto, artículos, páginas de categoría. Necesitan que Google vea su contenido sin depender del renderizado, así que necesitan SSR (Server-Side Rendering, renderizado en el servidor), SSG (Static Site Generation, generación de sitio estático) o prerenderizado. Por otro, las vistas puramente aplicativas: panel de control, carrito, pantallas tras autenticación. No tienen nada que hacer en el índice; un noindex asumido vale más que un SSR inútil.
Entre SSR, SSG y prerenderizado, la elección depende de la frescura del contenido y de tus limitaciones técnicas, no de un proveedor al que favorecer. Una página que cambia sin parar se inclina hacia el SSR; un catálogo estable se presta a la generación estática; un prerenderizado puede sacar del apuro a un sitio existente sin reescribirlo. Lo esencial sigue siendo lo mismo: las vistas que importan deben llegar a Googlebot ya rellenas.
Comprobar a escala qué vistas indexa Google de verdad
Corregir el renderizado no basta: hay que comprobar, vista por vista, qué hizo Google con ellas. La herramienta de Inspección de URLs de Search Console da ese veredicto oficial, pero de una URL en una URL. En una SPA que expone miles de vistas, auditarla página por página se vuelve impracticable.
IndexProbe es la versión en masa de esa herramienta de Inspección de URLs. Le entregas la lista de vistas que quieres vigilar, mediante sitemap, CSV, copia y pega, o construyéndola directamente desde tu Search Console (por clics, impresiones o patrón de URL), y consulta para cada una la API oficial de Search Console. Para cada vista obtienes el estado de indexación detallado, el motivo de la no indexación, la canónica que eligió Google y la fecha del último paso de Googlebot. Con un filtro aíslas las vistas que siguen en «Explorada, actualmente no indexada» o en «Página indexada sin contenido», precisamente las que delata un renderizado fallido. La segmentación de las URLs, generada automáticamente o definida a mano, agrupa de paso tus vistas por familia (fichas de producto, categorías, pantallas de la aplicación…): si un tipo de vista concentra los fallos de renderizado, resalta de inmediato.
IndexProbe no es un rastreador: no descubre ninguna vista siguiendo enlaces, solo inspecciona la lista que le proporcionas o que construyes desde la GSC (Google Search Console). Donde el inspector de Search Console obliga a ir de una URL en una URL, obtienes el mismo veredicto oficial, fechado, sobre toda tu lista, en una tabla filtrable que relanzas cuando quieras.
Comprobar que la corrección dio resultado
Una corrección de renderizado no se constata el día en que la despliegas, sino el día en que Google vuelve a pasar y reevalúa la página. La medición se hace con el tiempo, comparando dos análisis de la misma lista de vistas, antes y después. La buena señal no es una cifra aislada, es un movimiento de estados.
Tras un cambio a SSR o a prerenderizado, las vistas que salen de «Explorada, actualmente no indexada» y de «Página indexada sin contenido» pasan, poco a poco, a «Enviada e indexada». La vista Comparación pone ese desplazamiento en evidencia, estado por estado, entre dos relanzamientos de la misma lista.
Este seguimiento vale también como salvaguarda. Una SPA bien indexada hoy puede degradarse tras un rediseño, la incorporación de un módulo o una regresión de compilación que rompa el renderizado. Relanzar con regularidad la misma lista convierte una deriva silenciosa en una señal que puedes detectar, antes de que las vistas salgan del índice.
💡 El renderizado de una SPA no se adivina: se lee en los estados de indexación de Search Console, estado por estado, vista por vista. IndexProbe te da, para toda la lista que proporcionas o construyes desde la GSC, el veredicto oficial y fechado de Google por URL, y sigue siendo repetible para seguir cada evolución de un análisis al siguiente. Prueba IndexProbe en acceso anticipado →
Preguntas frecuentes
¿Es React malo para el SEO?
No. React no impide la indexación; es el renderizado del lado del cliente lo que da problemas, cuando el contenido solo existe después de ejecutar el JavaScript. Un sitio React renderizado en el servidor, con Next.js por ejemplo, o prerenderizado se posiciona igual de bien que un sitio clásico. El framework no es el problema, lo es la estrategia de renderizado.
¿Indexa Google las single-page applications (SPA)?
Sí. Google rastrea y renderiza las single-page applications con una versión actualizada de Chromium y luego indexa el resultado. Pero ese renderizado se pospone y puede fallar sin mensaje de error. Una SPA sí se indexa, siempre que sus vistas expongan una URL limpia y un contenido accesible sin interacción del usuario.
¿Lee Google el JavaScript?
Sí. Googlebot ejecuta el JavaScript para renderizar las páginas antes de indexarlas. Aun así, Google Search Central recomienda el renderizado en el servidor o el prerenderizado, porque el renderizado JavaScript añade un paso costoso y propenso a fallos, y no todos los bots lo ejecutan.
¿Hace falta SSR para el SEO de una SPA?
No siempre. Solo las vistas que buscan atraer tráfico orgánico, inicio, fichas de producto, artículos, categorías, necesitan renderizado en el servidor, estático o prerenderizado. Las vistas de aplicación privadas, como un panel de control o un carrito, no necesitan indexarse y pueden quedarse en renderizado del lado del cliente.
¿Por qué no se indexa mi página React?
Mira su estado en Search Console. «Descubierta, actualmente no indexada» indica que la página aún no se ha rastreado; «Explorada, actualmente no indexada», que Google la renderizó pero la juzgó demasiado pobre; «Soft 404», que devuelve un 200 en una vista vacía; «Página indexada sin contenido», que Google indexó el armazón antes de terminar el renderizado. Cada estado apunta a una causa distinta.
¿Qué es una single-page application (SPA)?
Una single-page application (SPA), o aplicación de página única, es un sitio que carga una sola página HTML y luego actualiza su contenido con JavaScript a medida que el usuario navega, sin recargar la página. React, Vue y Angular se usan a menudo para construirlas. El enfoque resulta fluido para el usuario, pero exige un cuidado especial con el renderizado para seguir siendo indexable.