SEO para JavaScript: cómo indexar una app de JS

TL;DR: Google puede indexar JavaScript, pero el renderizado del lado del cliente añade un paso diferido entre el rastreo y la indexación. Coloca el contenido principal, los metadatos específicos de cada ruta y los enlaces rastreables en HTML renderizado en el servidor o en HTML estático. Luego usa la Herramienta de inspección de URL de Google Search Console para comprobar el DOM renderizado, los recursos y los errores de JavaScript, en vez de asumir que lo que ve tu navegador es lo que Google recibió.

Si tu app de React, Vue, Angular o supuestamente renderizada en el servidor no aparece en Google, deja de preguntarte si Googlebot “admite JavaScript”. Sí lo admite. La pregunta útil es si Google puede obtener los recursos necesarios, ejecutar la aplicación, descubrir sus enlaces y generar un DOM indexable antes de que falle algo.

El pipeline que tu app de JavaScript debe superar

Google Search Central describe el procesamiento de JavaScript en tres fases claramente diferenciadas:

“Google procesa las apps web con JavaScript en tres fases principales: 1. Rastreo 2. Renderizado 3. Indexación”

En primer lugar, Googlebot solicita la URL y analiza la respuesta. Si esa respuesta es casi un “shell” vacío, Google todavía no tiene el texto de tu producto, el cuerpo del artículo, los encabezados, los metadatos generados por el cliente ni los enlaces de las rutas. Lo que tiene es una URL, algo de andamiaje HTML y referencias a recursos.

Luego, Google pone en cola las páginas aptas para renderizar. Su documentación indica: “La página puede permanecer en esta cola durante unos segundos, pero puede tardar más”. Ese es el modelo correcto. Evita la afirmación antigua de que JavaScript siempre provoca un retraso de indexación de días o semanas; Google no dice eso. Sí existe una cola diferida, sin embargo, y tu página todavía tiene que renderizar correctamente cuando llegue al frente.

Ese es el punto en el que muchos desarrolladores suelen omitirlo mentalmente. En el navegador local todo se ve completo, pero la respuesta obtenida puede contener poco más que un elemento raíz y referencias a bundles (el “view-source” es útil aquí, aunque es solo medio diagnóstico).

Durante el renderizado, Google ejecuta la página en un navegador sin interfaz (headless). Google confirma que “Google Search ejecuta JavaScript con una versión evergreen de Chromium”. Por lo tanto, la sintaxis moderna de los frameworks probablemente no sea el problema. Bloqueos de recursos, solicitudes fallidas a APIs, excepciones en tiempo de ejecución, contenido condicionado por interacción y un marcado de enlaces deficiente son mejores sospechosos.

Después del renderizado, Google puede inspeccionar el DOM resultante y extraer URLs añadidas por JavaScript. Esas URLs vuelven a la cola de rastreo. La indexación ocurre más tarde. Nuestras guías sobre qué significa rastrear en SEO y cómo funciona la indexación en Google cubren los límites entre estas etapas.

Una página de categoría renderizada en el cliente puede, por tanto, ser conocida por Google como una URL, mientras que sus productos, descripciones y enlaces salientes sigan siendo desconocidos. Descubrimiento no es indexación. Una URL indexada tampoco es prueba de que Google haya visto la página completa.

CSR funciona, pero es un valor predeterminado frágil para páginas que deben posicionar

Addy Osmani y Jason Miller definen el renderizado del lado del cliente en web.dev como el renderizado de una aplicación en el navegador, usando JavaScript para modificar el DOM. El renderizado del lado del servidor envía HTML generado desde el servidor. El renderizado estático crea ese HTML en el momento de build. La hidratación añade estado de la aplicación y controladores de eventos al HTML que ya existe.

El problema SEO de CSR es estructural, no ideológico. Tu contenido importante no está en la respuesta inicial y depende de que otro sistema complete trabajo más tarde. Eso puede funcionar perfectamente. Aun así, no convertiría cada ruta pública en algo dependiente de ello cuando el HTML elimina una clase entera de fallos.

“A grandes rasgos, animamos a los desarrolladores a considerar el renderizado del lado del servidor o el renderizado estático en lugar de un enfoque de rehidratación completa.”

Ese es el consejo de Osmani y Miller, no una instrucción para convertir todas las aplicaciones en un sitio estático. Un dashboard privado de analítica tiene requisitos distintos a una categoría pública en un marketplace. Renderiza en el servidor o en tiempo de build lo que necesitas para posicionar y luego añade interactividad del lado del cliente donde realmente valga lo que cuesta.

Los frameworks ofrecen varias rutas hacia esta arquitectura. Nuestra guía de SEO para Next.js, React y Nuxt cubre las decisiones específicas del framework. Pero un framework compatible con SSR no garantiza una salida renderizada en servidor. Yo asumí que sí, hasta descubrir que los datos útiles todavía se obtenían después del montaje (el logo del framework no me salvó).

No resucites el renderizado dinámico

El renderizado dinámico le da a los bots una página pre-renderizada mientras que los usuarios reciben la aplicación JavaScript. Google lo documentó una vez como una solución alternativa, pero su guía actual es explícita:

“El renderizado dinámico era un workaround y no una solución a largo plazo para los problemas con el contenido generado con JavaScript en los motores de búsqueda.”

La documentación de Google sobre renderizado dinámico recomienda en su lugar el renderizado del lado del servidor, el renderizado estático o la hidratación. Ahí es donde pondría el tiempo de ingeniería. Detectar bots, usar cachés separadas y mantener dos representaciones posibles de cada página crea más oportunidades para que diverjan el contenido y los metadatos.

Si el renderizado dinámico ya está “sosteniendo” un sitio heredado, no lo arranques sin un plan de migración. Solo no confundas un workaround tolerado con una arquitectura nueva y sólida.

Los fallos de JavaScript SEO que revisaría primero

1. El contenido principal solo existe después de ejecutar JavaScript

Obtén la URL sin ejecutar JavaScript. Si la respuesta incluye un “root” de la aplicación, un mensaje de carga y poco más, cada elemento significativo depende de la fase de renderizado de Google. Mueve el texto principal de la página, encabezados, fichas de producto, cuerpo del artículo y navegación esencial hacia la salida de SSR o SSG.

No necesitas eliminar JavaScript. Necesitas una base HTML útil. Mantén filtros, calculadoras, estado de cuenta y controles interactivos en el cliente cuando tenga sentido. La prueba más exigente es: si falla el bundle principal, ¿la respuesta todavía explica qué contiene esa URL?

Prueba plantillas representativas, no una URL conveniente. Una home puede ser estática mientras que las páginas de categoría obtienen datos completamente después del montaje. Las páginas de producto pueden usar SSR mientras que las rutas filtradas devuelven el shell genérico. Una página que pasa demuestra menos de lo que la mayoría de los equipos querría que demostrara.

Yo lo arreglo antes de “pulir” metadatos. Un título renderizado en servidor no compensa un cuerpo de artículo vacío. A la inversa, un artículo completo sigue en problemas si Google recibe un estado de carga permanente. Primero la arquitectura.

2. Tus “enlaces” son controladores de eventos

Este es uno de los problemas más comunes que vemos en sitios conectados a SEOJuice. Una tarjeta o elemento de menú invoca un método del router, pero el marcado no contiene ningún elemento a ni destino. Se comporta como navegación para una persona. No es un enlace rastreable.

Google sigue anclas reales, no manejadores de clic:

<!-- Rastreable: un enlace real que Google puede seguir -->
<a href="/products/blue-widget/">Blue Widget</a>

<!-- Invisible para el rastreo: no es un enlace -->
<div onclick="navigate('/products/blue-widget/')">Blue Widget</div>

“Google solo puede descubrir tus enlaces si son elementos HTML <a> con el atributo href.”

Ese texto viene directamente de Google Search Central. Los destinos navegables deben usar anclas reales con un href. Tu router aún puede interceptar el clic y hacer navegación del lado del cliente; la mejora progresiva y el comportamiento SPA son compatibles.

El daño se acumula. Si un listado muestra 100 tarjetas clicables como botones o elementos div, entonces faltan 100 destinos en el mecanismo de descubrimiento de enlaces que Google documenta (un sitemap puede exponer las URLs, pero no repara sus relaciones internas de enlazado).

Revisa menús, tarjetas, paginación, breadcrumbs, módulos de contenido relacionado, filtros con destinos estables y la navegación del logo. Si grupos completos de rutas no están en Google, audita los enlaces desde páginas que ya conoce Google antes de culpar a la indexación. Nuestra guía de buenas prácticas de SEO para SPA profundiza en el descubrimiento de rutas y la navegación del lado del cliente.

3. robots.txt bloquea recursos de JavaScript, CSS o APIs

Google indica que Search no renderizará JavaScript desde archivos bloqueados ni en páginas bloqueadas. Revisa reglas generales de robots.txt para rutas de assets como /static/, /_next/, directorios de build y endpoints de API proxy necesarios para construir contenido público.

Inspecciona las URLs de assets desplegadas en lugar de confiar en la configuración del repositorio. Una regla de CDN, un archivo robots específico por entorno, una comprobación de autenticación o una ruta de despliegue desactualizada pueden hacer que producción se comporte distinto a desarrollo local (producción siempre se las arregla para ser creativa, de forma molesta).

También confirma que los recursos devuelven respuestas útiles para Googlebot. Un bundle que devuelve 403, una llamada a la API que falla sin cookie de sesión o una URL de chunk caducada pueden dejar al rastreador con un shell en blanco, aunque robots.txt parezca “limpio”.

4. El contenido importante requiere interacción

El contenido que solo se obtiene después de seleccionar una pestaña, pulsar “Cargar más”, activar una solicitud dependiente del scroll o conceder un permiso puede no aparecer en el DOM que Google indexa. La documentación de troubleshooting de Google indica a los desarrolladores que “esperen que Googlebot rechace solicitudes de permisos del usuario”.

Haz que el contenido indexable esté disponible sin exigir un recorrido del usuario. El contenido paginado debería tener URLs estables y enlaces rastreables. Si una pestaña contiene información distinta que vale la pena indexar, inclúyela en el HTML inicial o dale un destino rastreable. Un rastreador no debería necesitar simular el uso del producto para obtener tu contenido principal.

5. El router muestra un 404 mientras el servidor devuelve 200

Una SPA puede mostrar un componente pulido de “No encontrado” para una ruta inválida, mientras el servidor reporta 200 OK. Google lo trata como un patrón de soft-404. Las soluciones documentadas son redirigir a una URL donde el servidor devuelva un 404 real, o añadir o cambiar la meta de robots a noindex.

Yo prefiero el estado correcto del servidor cuando la pila lo permite. Los códigos de estado comunican lo que ocurrió antes de que arranque la aplicación. Además, son mucho más fáciles de monitorizar que el estado del router.

Revisa URLs de producto mal formadas, registros eliminados, paginación inválida, rutas de idioma/locale incorrectas y rutas catch-all. Estos casos límite a menudo heredan el mismo shell de la app que las páginas válidas y crean silenciosamente miles de URLs de error que “parecen” exitosas.

6. La hidratación daña HTML válido renderizado en servidor

SSR puede devolver HTML completo y aun así fallar después de cargar. web.dev señala que los controles renderizados en servidor no pueden responder hasta que ejecuten los scripts del cliente y se adjunten los event handlers. Una excepción de hidratación puede dejar a los usuarios con controles muertos; un desajuste puede reemplazar o eliminar contenido que existía en la respuesta.

Compara tres estados: el HTML crudo, el DOM del navegador después de la hidratación y el DOM renderizado por Google. Si la respuesta cruda es correcta pero el DOM renderizado pierde contenido, pasar a SSR no resolvió todo el problema. Trasladó el fallo.

7. Los títulos, canonicals y descripciones llegan demasiado tarde

Google confirma que JavaScript puede establecer o cambiar el título y la meta description. Aun así, los metadatos específicos de la ruta deberían estar en la respuesta del servidor o en la respuesta estática cuando sea práctico. Si falla el renderizado, Google podría encontrarse con el título genérico de la aplicación en lugar de la versión específica de la página.

Aplica el mismo rigor a las etiquetas canonical y a las directivas robots. Los cambios del lado del cliente se pueden procesar, pero hacer que señales críticas de indexación dependan de ejecución aporta poco y crea otro lugar donde los errores de ruteo se pueden filtrar entre plantillas.

Cómo ver qué es lo que realmente renderizó Google

La Herramienta de Inspección de URL en Google Search Console es la comprobación decisiva. Tu navegador, tu rastreador local y las ejecuciones de Lighthouse pueden revelar defectos, pero ninguno representa el resultado registrado por Googlebot.

1. Inspecciona la URL canónica exacta. No pruebes solo la home si las páginas que faltan usan otra plantilla o una ruta distinta para obtener datos.
2. Abre “View Crawled Page”. Para una página que aún no está indexada, usa “Test Live URL” e inspecciona el resultado probado.
3. Lee el HTML renderizado. Busca una frase distintiva del contenido principal, el título específico de la ruta, la URL canonical y enlaces hacia páginas más profundas.
4. Revisa la captura. Roots en blanco, estados de carga, overlays de consentimiento y secciones faltantes pueden revelar un render fallido con rapidez.
5. Revisa mensajes de consola y recursos de la página. Busca excepciones, bundles bloqueados, fallos en llamadas a APIs y errores de carga de chunks.
6. Compáralo con la respuesta cruda. Obtén la URL con un cliente HTTP de línea de comandos. La diferencia entre el HTML de la respuesta y el HTML renderizado por Google es la dependencia de JavaScript que necesitas evaluar.

La guía de troubleshooting de JavaScript de Google indica que estas herramientas muestran recursos cargados, salida de la consola de JavaScript y excepciones, el DOM renderizado y otra información de diagnóstico. Si un párrafo importante o un enlace no aparece en ese DOM, esperar a que mejoren los rankings no es una estrategia de test. Repara la ruta de renderizado.

En SEOJuice somos un equipo de dos personas: Lida y yo. La inspección directa importa porque no podemos permitirnos convertir cada problema de indexación en una semana de depuración especulativa. HTML crudo, HTML renderizado, recursos, consola. Cuatro comprobaciones reducen el problema rápidamente.

Vimos la diferencia con claridad durante nuestra migración de seojuice.io a seojuice.com en enero de 2026. Las páginas se veían correctas en un navegador normal, y las pruebas en vivo podían pasar, mientras que los rastreos registrados por Google para algunas rutas aún no se habían puesto al día. Una prueba en vivo exitosa demuestra que Google puede renderizar la página en el momento del test; no reescribe rastreos históricos ni garantiza indexación (me gustaría que ese botón también existiera).

Un “gate” de lanzamiento práctico para páginas JavaScript indexables

No trates el JavaScript SEO como una tarea de limpieza después del lanzamiento. Agrega un pequeño gate de release para cada plantilla pública:

• La URL devuelve el código de estado previsto sin depender del ruteo del cliente.
• El HTML crudo contiene el encabezado principal, el texto principal y metadatos específicos de la ruta.
• La navegación usa elementos ancla con atributos href.
• Los recursos de JavaScript, CSS y los datos públicos necesarios son rastreables.
• La página sigue siendo útil si falla la hidratación.
• El DOM renderizado contiene el mismo contenido principal y las mismas señales de indexación que la respuesta.
• Las rutas inválidas y eliminadas devuelven una respuesta de error real o una directiva noindex deliberada.

Esto no es una petición de HTML idéntico a píxel. El estado interactivo puede diferir. El requisito es que el significado de la página, los destinos descubiertos y las instrucciones de indexación sobrevivan a cada etapa del pipeline de Google.

Dónde encaja SEOJuice y dónde no

SEOJuice opera en un sitio en vivo mediante un snippet de JavaScript o un plugin de CMS. Aplica de forma continua tareas on-page como enlaces internos, títulos y descripciones de meta, marcado schema y texto alternativo de imágenes. Su auditoría también puede detectar metadatos faltantes, contenido renderizado escaso o inexistente, recursos bloqueados, patrones de enlace no rastreables y brechas de indexación.

No convierte una aplicación CSR en SSR. Como el snippet se ejecuta del lado del cliente, su salida comparte la dependencia de renderizado mencionada arriba. Si el contenido principal no está en el HTML, primero hay que corregir la arquitectura de renderizado; la automatización debe quedar encima de una página que Google pueda procesar de forma fiable.

Si la aplicación renderiza correctamente y quieres identificar los errores restantes de on-page e indexación, ejecuta el free SEO audit. Hay un plan gratuito disponible sin tarjeta de crédito.

Preguntas frecuentes

¿Google puede indexar JavaScript?

Sí. Google Search ejecuta JavaScript usando una versión evergreen de Chromium. Las páginas con JavaScript todavía pasan por una fase de renderizado diferido, así que el contenido puede retrasarse o perderse si los recursos están bloqueados, la ejecución falla o la información importante requiere interacción del usuario.

¿Por qué falta mi app de React, Vue o Angular en Google?

La causa probable no es el framework en sí. Revisa si el contenido esencial y los enlaces solo aparecen después de la ejecución del lado del cliente, si los bundles o APIs no están disponibles para Googlebot, y si los errores en runtime impiden el renderizado. También inspecciona soft-404, metadatos genéricos definidos en el cliente y navegación sin anclas reales.

¿Cuál es la diferencia entre SSR, SSG y CSR para SEO?

SSG genera HTML en el momento de build. SSR genera HTML en el servidor para cada solicitud. Ambos exponen el contenido principal en la respuesta. CSR construye la página en el navegador, haciendo que ese contenido dependa del renderizado posterior de Google. Para páginas públicas que se espera que posicionen, SSG o SSR suelen ser la opción predeterminada más segura.

¿Google aún recomienda el renderizado dinámico?

No. Google llama renderizado dinámico a un workaround, no a una solución a largo plazo. La guía actual orienta a los desarrolladores hacia el renderizado del lado del servidor, el renderizado estático o la hidratación. No empieces una implementación nueva basada en una salida separada para bots y usuarios.

¿Los botones en JavaScript y la navegación con onClick cuentan como enlaces?

No como enlaces rastreables. Google documenta el descubrimiento de enlaces a través de elementos ancla con atributos href. Usa anclas semánticas para destinos navegables, aunque un router del lado del cliente las intercepte para evitar una recarga completa de la página.

¿Cómo veo la página que renderizó Googlebot?

Inspecciona la URL exacta en Google Search Console, abre la página rastreada o probada en vivo y revisa su HTML renderizado, la captura, los recursos cargados y los mensajes de la consola de JavaScript. Busca el contenido principal y los enlaces internos en el HTML. Si no están ahí, Google no recibió la página completa durante esa prueba.