SEO para JavaScript: por qué tus páginas se vuelven invisibles para Google

El SEO para JavaScript es la práctica de asegurarse de que Google y otros buscadores puedan rastrear, renderizar e indexar el contenido que un navegador construye con JavaScript en lugar de HTML simple. Google renderiza las páginas en un paso distinto y diferido, posterior al rastreo inicial, así que el contenido puede pasar semanas sin que lo vean.

Si has construido tu sitio con React o Vue, o con un framework como Next.js, la brecha entre "rastreada" y "renderizada" es probablemente la mayor razón por la que hay páginas sin indexar. La solución suele no ser complicada una vez que sabes dónde se produce el fallo.

¿Qué es el SEO para JavaScript y por qué le cuesta tanto a Google?

El SEO para JavaScript es una rama del SEO técnico centrada en un solo problema: lograr que las páginas construidas con JavaScript sean tan rastreables e indexables como las páginas en HTML simple. Un sitio HTML tradicional le entrega a Google todo lo que necesita en una sola respuesta. Un sitio JavaScript suele entregar una carcasa casi vacía y construye el contenido real en el navegador.

Google puede ejecutar JavaScript y lo dice desde hace años. Sin embargo, hacerlo consume recursos de cómputo, y Google tiene que racionarlos entre miles de millones de páginas. Ese racionamiento es donde empiezan los problemas.

Cómo rastrea e indexa Google una página con JavaScript

La documentación de Google en Search Central describe el renderizado como un paso distinto del rastreo, y no como algo que ocurre durante la primera visita. El proceso consta de tres partes:

1. Rastreo: Googlebot solicita la página y lee el HTML sin procesar. En una página con mucho JavaScript, ese HTML puede contener poco más que un <div id="root"></div> y una etiqueta de script.
2. Renderizado: la página entra en una cola de renderizado, donde el Web Rendering Service de Google, basado en un motor Chromium siempre actualizado, ejecuta el JavaScript para construir la página final.
3. Indexación: solo cuando termina el renderizado, Google indexa el contenido, los enlaces y los metadatos que encuentra.

El Web Rendering Service intenta ahora renderizar cerca del 100% de las páginas HTML que Google rastrea. Intentar renderizar no es lo mismo que renderizar rápido. El intervalo entre el rastreo y el renderizado puede ir de unas pocas horas en un sitio consolidado a varias semanas en uno de menor autoridad, y en una página de producto nueva o un artículo sensible al tiempo eso puede significar perder la ventana de tráfico.

El problema de la indexación en dos etapas

Esta es la parte que sorprende a la mayoría de los propietarios de sitios. Tu página se rastrea casi de inmediato, pero el contenido que hay en ella no se ve hasta mucho después, si es que llega a verse.

Etapa	Qué ocurre	Tiempo habitual	Impacto en el SEO
Rastreo inicial	Googlebot obtiene el HTML sin procesar y extrae el texto estático, los enlaces y las etiquetas	Inmediato	Solo se indexa de inmediato el contenido que no depende de JS
Cola de renderizado	Chromium ejecuta el JavaScript y construye la página final	De horas a varias semanas, más en sitios de baja autoridad	El contenido, los enlaces y los datos estructurados generados por scripts siguen invisibles hasta que esto termina
Fallo de renderizado	Un error de script, un recurso bloqueado o un tiempo de espera agotado impiden que el renderizado se complete	Impredecible	El contenido no llega a indexarse nunca

Varios factores empujan una página hacia el extremo lento de ese intervalo: paquetes de JavaScript grandes, scripts bloqueados en robots.txt, errores de JavaScript no capturados, scripts de terceros que no se cargan y poca autoridad del sitio. El presupuesto de rastreo se asigna de forma desigual, por lo que los sitios más grandes o más nuevos suelen esperar más en la cola.

Renderizado del lado del cliente o del servidor: ¿cuál deberías usar?

Usa renderizado del lado del servidor (SSR) o generación de sitios estáticos (SSG) en lugar de renderizado del lado del cliente (CSR) para cualquier página que quieras indexar. Con CSR, Google tiene que esperar a la cola de renderizado. Con SSR o SSG, Google recibe el HTML terminado en la primera petición y no hay ninguna espera.

Enfoque	Cómo llega el contenido al navegador	Idoneidad para SEO	Mejor uso
Renderizado del lado del cliente (CSR)	El navegador (o Googlebot) ejecuta JavaScript para construir la página tras la carga	Débil para páginas públicas; depende de la cola de renderizado	Paneles con inicio de sesión, herramientas internas
Renderizado del lado del servidor (SSR)	El servidor construye el HTML completo en cada petición	Sólido; el contenido está en la primera respuesta	Páginas de producto, blogs, páginas de destino
Generación de sitios estáticos (SSG)	El HTML se construye de antemano en el momento del despliegue	Sólido, y el más rápido de servir	Sitios de marketing, documentación, portfolios
Regeneración estática incremental (ISR)	Páginas estáticas que se actualizan según un calendario o bajo demanda	Sólido	Catálogos de comercio electrónico, contenido que se actualiza con frecuencia
Instantáneas prerrenderizadas para bots	Se sirve una instantánea HTML aparte solo a los bots	Aceptable como puente, no como solución a largo plazo	Sitios CSR heredados en plena migración

Google ha dicho que servir a los bots una instantánea prerrenderizada no es cloaking, siempre que los bots y los usuarios acaben viendo un contenido equivalente. Eso sí, deja claro que debería ser una solución provisional. Mantener dos vías de renderizado en paralelo supone una complejidad añadida que tienes que sincronizar indefinidamente.

La mayoría de los equipos de desarrollo acaban con un modelo híbrido: SSR o SSG para todo lo que los buscadores o los motores de respuesta de IA deban encontrar, y CSR para las experiencias con inicio de sesión, donde indexar nunca fue el objetivo. Un proyecto de Next.js toma esta decisión a nivel de página, y los detalles se explican en esta guía de ajustes de SEO para Next.js.

Señales de que tu sitio tiene un problema de SEO con JavaScript

No necesitas un desarrollador para detectar las primeras señales de alerta. Busca estos patrones en Google Search Console y en tus analíticas:

• Las páginas siguen en "Discovered, currently not indexed" durante semanas después de publicarse.
• La vista renderizada de una página en Search Console no incluye texto, enlaces o imágenes que se ven claramente en el navegador.
• Los enlaces internos creados como controladores onClick de JavaScript en lugar de etiquetas <a href> reales no aparecen como "linked from" en Search Console.
• Las etiquetas de título o las metadescripciones que aparecen en los resultados de búsqueda no coinciden con lo que hay en la página.
• Los datos estructurados inyectados en el cliente no se validan en la Prueba de resultados enriquecidos (Rich Results Test).
• La paginación construida a partir del estado de JavaScript en lugar de URL únicas impide que se rastreen las páginas más profundas.

Cuando varias de estas señales aparecen juntas, la causa casi siempre es una brecha de renderizado y no un problema de contenido o de palabras clave. Una auditoría de SEO técnico que compare el HTML renderizado con el HTML sin procesar lo confirmará enseguida.

Qué debe estar en tu HTML inicial

Por mucho que JavaScript mejore la página después, ciertos elementos tienen que existir en la primera respuesta HTML. Sin ellos, Google puede tratar la página como casi vacía durante el rastreo, aunque la versión renderizada parezca completa.

Elemento	Por qué importa para el SEO con JavaScript	Riesgo si solo existe en JS
Etiqueta de título y metadescripción	Señal básica de posicionamiento y de clics	Puede que no aparezca en los resultados de búsqueda durante semanas
Encabezados H1, H2 y H3	Dan a Google la estructura temática de la página	Indexación retrasada, se pierde la opción de aparecer en fragmentos destacados
Texto del cuerpo	Establece la relevancia y la profundidad temática	La página parece vacía en el primer rastreo
Enlaces internos (<a href>)	El camino de rastreo que sigue Googlebot hacia otras páginas	Puede que las páginas enlazadas no se descubran nunca
Datos estructurados (JSON-LD)	Elegibilidad para resultados mejorados y citas en respuestas de IA	Quedan excluidos por completo de los resultados mejorados
Etiquetas canónicas	Evitan la confusión por contenido duplicado	Se indexa la versión equivocada de la URL

Haz una auditoría de marcado de esquema junto con tus revisiones de renderizado. El JSON-LD inyectado únicamente con JavaScript del lado del cliente es una de las cosas que más a menudo desaparecen de la versión que indexa Google.

Core Web Vitals: donde JavaScript hace más daño

El JavaScript pesado retrasa la indexación y además ralentiza la página para los visitantes reales, lo que juega en tu contra como factor de posicionamiento. Los Core Web Vitals de Google miden el tipo de retardo que causan los scripts sin optimizar.

Métrica	Qué mide	Umbral bueno	Causa habitual en JavaScript
Largest Contentful Paint (LCP)	Qué tan rápido aparece el contenido principal	Menos de 2,5 segundos	Los paquetes JS grandes retrasan el renderizado del contenido visible
Interaction to Next Paint (INP)	Qué tan receptiva es la página a clics y toques	Menos de 200 milisegundos	Las tareas largas de JavaScript bloquean el hilo principal del navegador
Cumulative Layout Shift (CLS)	Cuánto se mueve el diseño mientras carga	Menos de 0,1	Los elementos que JavaScript inyecta tarde desplazan el contenido

INP sustituyó a First Input Delay como Core Web Vital oficial en marzo de 2024, un cambio que se explica en la documentación de web.dev de Google. Es una medida de la capacidad de respuesta más estricta y más realista que su predecesora, y penaliza los scripts de ejecución larga que suelen incluir los sitios con mucho JavaScript.

Un objetivo que se cita con frecuencia es un paquete inicial comprimido de menos de 200KB, con cualquier tarea de más de 50 milisegundos dividida en fragmentos más pequeños para que no bloquee el hilo principal. Google no aplica ninguna de las dos cifras como límite estricto, pero ambas van muy de la mano de los sitios que superan los Core Web Vitals con holgura. Una lista de comprobación breve cubre la mayor parte del trabajo:

• Difiere los scripts que no hagan falta para el primer renderizado.
• Elimina del paquete el JavaScript que no uses.
• Divide las tareas largas para que el hilo principal quede libre para clics y toques.
• Corrige los errores de script y desbloquea los recursos que robots.txt oculta ahora mismo a Googlebot.

Por qué esto importa más en sitios SaaS y B2B

Las plataformas SaaS, los portales empresariales y los marketplaces tecnológicos suelen construirse desde cero como aplicaciones JavaScript. La indexación retrasada de las páginas de producto, los datos estructurados invisibles y unos Core Web Vitals débiles les perjudican a la vez, y colocan el sitio por debajo de la competencia en las búsquedas de alta intención donde se ganan o se pierden las ventas.

El fallo habitual es que un sitio de marketing y una aplicación de producto compartan un mismo código renderizado en el cliente. Un esquema más seguro renderiza las páginas públicas (precios, funciones, documentación, blog) en el servidor o en el momento de la compilación, y deja el CSR para la aplicación con inicio de sesión, donde la indexación no importa.

Soluciones según la plataforma

La solución adecuada depende de la plataforma sobre la que construyas.

• Los temas de Shopify dependen de JavaScript para el filtrado, la selección de variantes y las actualizaciones del carrito. En su mayor parte eso no supone un problema para el SEO mientras los títulos de producto, las descripciones y las etiquetas canónicas permanezcan en el HTML renderizado en el servidor. Los ajustes que conviene revisar se detallan en esta guía de SEO para Shopify.
• Wix ha mejorado mucho su gestión del renderizado, pero las secciones interactivas generadas por el editor pueden seguir retrasando la indexación si cargan el contenido de forma asíncrona. Repasa los ajustes pertinentes en esta guía de SEO para Wix.
• Las aplicaciones de Lovable suelen construirse por defecto como aplicaciones React de una sola página, lo que las sitúa en territorio CSR a menos que las configures de otro modo. Esta guía de SEO para sitios de Lovable explica cómo lograr que se indexe el contenido del blog en un sitio creado a partir de un solo prompt.
• Los sitios WordPress suelen ser ya HTML primero, pero los temas con mucho JavaScript, los constructores de páginas y algunos plugins reintroducen el riesgo de renderizado. Las soluciones se explican en esta guía de ajustes de SEO para WordPress.
• Los sitios basados en Git, creados con generadores de sitios estáticos y desplegados mediante GitHub, suelen usar SSG por defecto, que es la opción de renderizado más segura que existe. Los detalles de despliegue e indexación están en esta guía de SEO para sitios desplegados en GitHub.
• Next.js es el que te da más control, ya que te permite elegir SSR, SSG o ISR por página. Los metadatos, los sitemaps y robots.txt importan tanto como el modo de renderizado, y la guía de SEO para Next.js los trata.

La búsqueda con IA cambia lo que está en juego

El SEO para JavaScript antes era una preocupación exclusiva de Google. La mayoría de los rastreadores de IA, incluidos los bots de ChatGPT, Claude y Perplexity, no ejecutan JavaScript en absoluto. Gemini es la excepción notable porque usa la tecnología de renderizado de Google, aunque se describe como experimental y como algo en lo que no conviene confiar.

Por eso, una página que depende de JavaScript del lado del cliente para mostrar su contenido puede ser invisible para los motores de respuesta de IA aunque Googlebot acabe viéndola. Para poder ser citado en las respuestas generadas por IA, el contenido tiene que existir en el HTML sin procesar. El mismo principio recorre la optimización para motores de respuesta: escribe la respuesta donde cualquier rastreador, creado por humanos o por IA, pueda leerla.

Cómo probar y supervisar el SEO para JavaScript

Puedes comprobar si Google ve tu página como pretendes, sin adivinar.

1. Compara el HTML sin procesar y el renderizado. Mira el código fuente para ver la versión sin procesar y colócalo junto a lo que muestra Chrome DevTools cuando la página ha cargado por completo. Las diferencias grandes indican una dependencia del renderizado.
2. Usa la herramienta Inspección de URLs de Search Console. Muestra la captura renderizada y el HTML que usó Google, además de los errores de la consola de JavaScript que encontró.
3. Rastrea con JavaScript desactivado. Un modo de rastreo de "solo texto" revela lo que ve un bot que no renderiza, algo importante dada la cantidad de rastreadores de IA que ignoran JavaScript.
4. Vigila los archivos de registro del servidor a lo largo del tiempo. Revisar la frecuencia de rastreo en una ventana de tres a seis meses muestra si las plantillas importantes se visitan con la frecuencia suficiente y si las correcciones de renderizado mejoraron después la actividad de rastreo.
5. Vuelve a ejecutar una auditoría técnica después de cambios importantes de framework. Migrar a un nuevo framework es el momento en que las regresiones de renderizado se cuelan sin que nadie las note, y una auditoría de SEO técnico antes y después las detecta cuando todavía es barato corregirlas.

¿Puedes arreglar el SEO para JavaScript por tu cuenta?

En parte, sí. Comprobar si tus etiquetas de título y tus encabezados aparecen en el HTML sin procesar lleva cinco minutos y un clic en "ver código fuente". Añadir el atributo defer a los scripts no críticos, eliminar el JavaScript que no uses y asegurarte de que los enlaces internos usen etiquetas <a href> reales son cambios que el propietario de un sitio puede pedirle a un desarrollador sin tener que reconstruirlo todo.

Pasar una aplicación CSR a SSR, o configurar instantáneas prerrenderizadas como solución provisional, es un proyecto mayor. Normalmente requiere un desarrollador que conozca tu framework, porque una implementación incorrecta puede romper la funcionalidad que intentas conservar. Si sospechas que el culpable es la arquitectura de renderizado, trae a un desarrollador antes de que nadie toque el código de producción, y usa un plan de SEO estructurado para ordenar las correcciones y que una no deshaga otra.

Dónde encaja esto en el resto de tu trabajo de SEO

Un sitio con problemas de renderizado suele tener también carencias en visibilidad local, datos estructurados o salud técnica general. Si atiendes zonas concretas, combina tus correcciones de renderizado con páginas de SEO local creadas en torno a los barrios en los que quieres posicionarte. Si tu framework además genera URL duplicadas o canónicas incoherentes, algo habitual en los enrutadores del lado del cliente, resuélvelo en la misma pasada técnica en lugar de tratarlo más adelante como un proyecto aparte.

Preguntas frecuentes

¿Penaliza Google los sitios web con JavaScript?

No. Google no penaliza un sitio por usar JavaScript. El problema es indirecto: si JavaScript retrasa el renderizado u oculta contenido, las páginas se indexan tarde o no se indexan, lo que parece un problema de posicionamiento pero es de indexación.

¿Cuánto tarda Google en indexar una página con JavaScript?

Varía mucho. Los sitios consolidados y de alta autoridad pueden ver el renderizado en cuestión de horas, mientras que los sitios más nuevos o de menor autoridad pueden esperar semanas a que la misma página avance por la cola, según la propia descripción del proceso que da Google.

¿Es React malo para el SEO?

React en sí no, pero una aplicación React renderizada por completo en el cliente sí. Combinar React con un framework que admita renderizado del lado del servidor o generación estática, como Next.js, elimina la mayor parte del riesgo.

¿Cuál es la diferencia entre SSR y el prerrenderizado?

SSR construye el HTML completo en el servidor en cada petición, en tiempo real. El prerrenderizado genera una instantánea HTML estática de antemano (o en la primera petición de un bot) y sirve esa versión en caché a los rastreadores. Es más barato de mantener, pero hay que actualizarlo para que siga siendo exacto.

¿Los chatbots de IA como ChatGPT leen el contenido en JavaScript?

Por lo general, no. La mayoría de los rastreadores de IA no ejecutan JavaScript, así que el contenido que solo aparece después de ejecutar un script suele ser invisible para ellos. Gemini, de Google, es la excepción porque usa la infraestructura de renderizado de Google, aunque aún se considera un caso marginal.

Haz que revisen tu renderizado antes de que te cueste más posiciones

Los problemas de SEO con JavaScript son silenciosos. Las páginas no lanzan errores, simplemente no aparecen, y nada en tu panel avisa de un retraso de renderizado hasta que sabes dónde mirar. La forma más rápida de saber en qué punto estás es comparar lo que Google renderiza con lo que sirve tu sitio. Habla con el equipo y consigue un informe SEO de muestra que muestre lo que está pasando ahora mismo en tus páginas.

Recursos / Referencias

1. Search Central
2. web.dev

Fuentes

• The Complete JavaScript SEO Guide
• JavaScript SEO: 6 Best Practices to Boost Rankings
• Mastering JavaScript SEO: pre-rendering and log analysis
• Get the Best Javascript SEO Practices
• What is JavaScript SEO?