JavaScript SEO: qué ve Google de una web hecha en React o Next

El fallo aquí no se parece a ningún otro del SEO técnico, y por eso se diagnostica tarde: la página funciona perfectamente en el navegador y llega vacía al buscador. No hay error, no hay aviso, no hay nada roto que se pueda enseñar. Simplemente el contenido no existe en el HTML que se sirve, aparece después de que el navegador ejecute código, y entre esas dos cosas hay una cola de procesamiento en la que Google decide cuándo y si vuelve.

Respuesta rápida

• Google renderiza, pero en dos fases y la segunda va en cola, sin plazo comprometido.
• El síntoma es contenido que existe para ti y no para el buscador. Se ve comparando dos vistas.
• La solución no es quitar JavaScript, es decidir dónde se genera el HTML.
• El caso peor no es la lentitud, es que la respuesta inicial venga vacía.

¿Cómo afecta JavaScript al SEO?

Google rastrea en dos fases: primero lee el HTML que devuelve el servidor y después, en una segunda pasada que va en cola, ejecuta el JavaScript y ve el resultado. Si el contenido solo existe tras esa ejecución, su indexación depende de una cola sin plazo comprometido, y los enlaces que aparecen ahí se descubren más tarde.

Qué tipo de problema es este

El modelo mental que retrasa el diagnóstico es que si la página se ve, está bien. Es el modelo que funciona para todo lo demás y aquí falla, porque tú la ves con un navegador que ejecuta código y el rastreador la mira dos veces con criterios distintos.

Lo que ocurre por debajo son dos pasadas. En la primera, Google pide la URL y guarda lo que le devuelve el servidor. Si eso es un esqueleto con un <div id="root"></div>, eso es lo que tiene. En la segunda, cuando le toca, renderiza la página como un navegador y actualiza lo que sabe.

Esa segunda pasada no tiene plazo comprometido. No es que Google no pueda: es que renderizar cuesta y se encola. En un sitio nuevo o de poca autoridad, la cola es más larga, que es justo donde más duele.

Y hay un efecto secundario que se pasa por alto: los enlaces que solo aparecen tras el render se descubren en la segunda pasada. Un menú o una paginación construidos por JavaScript retrasan el descubrimiento del sitio entero.

Cómo se ve el problema en dos minutos

Sin herramientas de pago y sin discusión posible.

Compara el código fuente con lo que ves. Botón derecho, ver código fuente, y busca un párrafo del texto principal. Si no está ahí, no está en la primera pasada. Cuidado: la herramienta de inspección del navegador muestra el DOM ya renderizado, así que no sirve para esto; hay que mirar el fuente.

Usa la prueba en vivo de la inspección de URL de Search Console. Devuelve el HTML renderizado que ve Google y una captura. Si el párrafo aparece ahí pero no en el fuente, dependes de la segunda pasada.

Y prueba con JavaScript desactivado. Es la aproximación más brusca y la más informativa: lo que quede en pantalla es aproximadamente lo que tiene Google en la primera lectura.

Las tres tardan menos que discutir sobre el tema, y conviene hacerlas en ese orden. La primera dice si hay problema; la segunda, si Google llegó a resolverlo; la tercera, cuánto se pierde mientras tanto.

Si las tres coinciden en que hay contenido, el problema es otro, y conviene volver al orden habitual de SEO técnico antes de tocar la arquitectura.

Qué hacer, por orden de coste

Servir el HTML ya hecho. Renderizado en servidor o generación estática. En los marcos modernos es una opción de configuración por ruta, no una reescritura, y resuelve el problema de raíz.

Empezar por las páginas que tienen que posicionar. No hace falta convertir la aplicación entera: las fichas, los artículos y las páginas de servicio son las que necesitan HTML completo. El panel privado tras un login no necesita nada.

Enlaces como enlaces. Un <a href> de verdad, no un div con un manejador de clic. Es el arreglo más barato de esta lista y el que más afecta al descubrimiento.

Contenido crítico fuera de interacciones. Lo que está detrás de una pestaña que carga al hacer clic, o de un scroll infinito, puede no existir para el buscador.

Y el prerenderizado para bots, como parche. Funciona y añade una pieza más que mantener, además de un riesgo de divergencia entre lo que ve una persona y lo que ve el rastreador. Sirve para salir del paso, no como decisión de arquitectura.

Cuándo esto no es el problema

Cuando el contenido sí está en el fuente. Entonces el marco no tiene la culpa, por mucho JavaScript que cargue después.

Cuando la página no está indexada por otra razón. Un noindex o un bloqueo se diagnostican antes, y están en por qué Google no indexa tu página.

Cuando el sitio es una aplicación tras un login. Ahí no hay nada que indexar, el renderizado en cliente es la decisión correcta, y forzar un servidor que pinte HTML para nadie es trabajo pagado dos veces: ni Google entra ni le interesa entrar.

Cuando lo que preocupa es la velocidad. Es un problema real y distinto: mucho JavaScript afecta a la interactividad, que es una métrica aparte y se trata en Core Web Vitals.

La herramienta que recomiendan y que Google apagó

Los primeros resultados en español para esta consulta explican bien las dos fases: Google rastrea el HTML inicial, la página entra en una cola de renderizado y más tarde el servicio ejecuta el JavaScript. Ahí no hay nada que corregir. La corrección está en el paso siguiente, cuando llega el momento de comprobarlo.

Varios recomiendan la prueba de optimización para móviles, y esa herramienta ya no existe. Google la retiró en diciembre de 2023. Un artículo de 2026 que la nombra manda a su lector a una puerta cerrada, y es de esos fallos que sobreviven porque nadie vuelve a abrir el enlace que puso hace tres años. La comprobación que sí funciona hoy está dentro de Google Search Console: la inspección de URL, que enseña el HTML renderizado tal como quedó después de ejecutar el JavaScript. Es además la única que responde por una URL concreta y no por el sitio entero, que es lo que hace falta aquí: los problemas de renderizado casi nunca son uniformes, afectan a una plantilla y no a otra. Cómo se lee ese informe está en cómo pedir la indexación de una página.

Y hay una comprobación anterior, gratis y de veinte segundos, que no aparece en ninguna de esas páginas: abre el código fuente de la página y busca ahí una frase de tu contenido principal. No en el inspector del navegador, que muestra el DOM ya construido, sino en el código fuente, que es aproximadamente lo que llega en la primera fase. Si la frase está, no dependes del renderizado. Si no está, todo tu contenido vive en la segunda fase y hereda su cola, sus tiempos y sus fallos.

Esa distinción entre el fuente y el DOM es la que se salta casi todo el mundo al diagnosticar, y explica el caso más frustrante de este tema: alguien mira su página en el inspector, ve el texto perfectamente, concluye que Google también lo ve, y no entiende por qué la página lleva semanas sin aparecer. Cuando eso ocurre, el sitio no tiene un problema de contenido: tiene uno de arquitectura, y se resuelve en la capa donde se sirve el HTML y no en la que lo escribe. Y hay un síntoma que lo delata desde fuera: si el sitemap declara doscientas URL y el informe de páginas reconoce cuarenta, el problema no es de cobertura sino de renderizado. Cómo se monta y se lee un sitemap es la comprobación de al lado.

Errores que se repiten

• Diagnosticar mirando el navegador. Muestra el DOM renderizado, no lo que se sirvió.
• Suponer que si Google renderiza, da igual. Renderiza en cola y sin plazo.
• Enlaces con div y manejador de clic. No se siguen y frenan el descubrimiento.
• Convertir la aplicación entera a renderizado en servidor. Basta con lo que debe posicionar.
• Usar prerenderizado para bots como arquitectura. Es un parche con riesgo de divergencia.
• Meter el contenido principal detrás de una interacción. Puede no existir para el buscador.

Datos y transparencia

Que Google retiró la prueba de optimización para móviles en diciembre de 2023 está en sus propios anuncios, comprobado el 12 de agosto de 2026, y la comprobación de renderizado se hace desde la inspección de URL de Search Console. Que varios de los primeros resultados en español para esta consulta siguen recomendándola es una observación del mismo día y se recoge como dato caducado, no como fuente. No se da aquí ninguna cifra de cuánto tarda la cola de renderizado: Google no publica ese plazo y varía con el sitio.

Que Google procesa el JavaScript en una segunda fase encolada, separada del rastreo inicial del HTML, y que los enlaces descubiertos durante el renderizado se procesan en esa segunda pasada, procede de la documentación pública de Google sobre conceptos básicos de JavaScript SEO, vigente a agosto de 2026. La prueba en vivo de la herramienta de inspección de URLs devuelve el HTML renderizado y está documentada en la ayuda de Search Console. No aparece aquí ninguna cifra sobre cuánto tarda la segunda pasada: Google no publica un plazo, depende del sitio y de su presupuesto de rastreo, y las cifras que circulan proceden de experimentos con muestras que no se pueden extrapolar. Tampoco se compara el rendimiento de marcos concretos, porque el resultado depende de cómo se configuren y no del marco. Verificado en agosto de 2026.

Lo que esto cambia

Este es el problema de SEO técnico que más tarda en detectarse, y no por dificultad técnica.

Se detecta tarde porque no produce ningún síntoma que alguien reconozca como error. La web va bien, se ve bien, carga rápido, y nadie de los que la usan a diario tiene motivo para sospechar. El único que ve el problema es un rastreador, y no se queja. Por eso conviene hacer las tres comprobaciones de este artículo el día que se lanza un sitio hecho con un marco moderno, y no el día que alguien pregunta por qué no aparece nada en Google seis meses después.

Preguntas frecuentes