SEO para JavaScript: por qué Google no puede ver tu contenido

La página funciona perfectamente en Chrome, pero Google indexa un título vacío y unas pocas líneas del pie de página. Desarrollo dice que los rastreadores modernos ejecutan JavaScript; el equipo de SEO ve URL que nunca ganan visibilidad. Ambos tienen solo la mitad de la razón.

Google puede renderizar JavaScript, pero eso no significa que cualquier aplicación JavaScript se rastree con rapidez, se entienda correctamente y se indexe por completo. Diagnostica la página a través de las tres etapas que Google usa realmente: rastrear el HTML, renderizar el JavaScript e indexar el resultado.

Cómo procesa Google las páginas con JavaScript

Etapa 1: rastreo

Googlebot descarga la URL y lee el estado HTTP, las cabeceras, las directivas de robots y el HTML inicial. Ya puede extraer los enlaces <a>, los canonical, los títulos y el contenido presente en la respuesta.

Si el servidor devuelve 404, 500, bloquea el rastreo o envía noindex, el procesamiento puede detenerse antes de que se ejecute la aplicación.

Etapa 2: renderizado

Una página con 200 puede entrar en una cola de renderizado. Una versión sin interfaz de Chromium ejecuta el JavaScript, descarga los recursos permitidos y crea el DOM renderizado. El tiempo de espera varía según los recursos del rastreador.

Etapa 3: indexación

Google lee el contenido y los enlaces del HTML renderizado y luego evalúa los canonical, la calidad, la duplicación y la posibilidad de indexar. Un renderizado correcto sigue sin garantizar la indexación; la página debe aportar valor y señales coherentes.

La prueba más rápida: desactivar JavaScript

Usa Ver código fuente o curl para inspeccionar la respuesta HTML. No te fíes solo de la pestaña Elements de DevTools, que muestra el DOM después de que se hayan ejecutado los scripts.

Busca cinco elementos:

1. ¿Están presentes el título y la meta description?
2. ¿Son visibles el H1 y el texto principal?
3. ¿Las rutas internas son enlaces <a href> reales?
4. ¿Son correctas desde el primer momento las etiquetas canonical y robots?
5. ¿Devuelve el servidor el estado adecuado?

Si la respuesta contiene solo <div id="app"></div>, el descubrimiento depende del renderizado. No está necesariamente roto, pero hace que la indexación y la depuración sean más lentas de lo necesario.

Siete fallos habituales del SEO para JavaScript

1. El contenido aparece solo tras una interacción del usuario

Googlebot no está obligado a hacer clic en pestañas, desplegar acordeones, manejar el scroll infinito ni pulsar «Cargar más». El contenido obtenido después de una acción puede no descubrirse nunca.

Renderiza el contenido importante en el HTML o proporciona una URL propia y un enlace rastreable para cada estado que merezca indexarse. Un acordeón cuyo contenido ya existe en el DOM es más seguro que uno que solo lo obtiene tras un clic.

2. Las rutas del cliente devuelven siempre 200

Una SPA puede mostrar «No encontrado» mientras el servidor devuelve 200, creando un soft 404. También ocurre lo contrario: una ruta válida recibe un 404 del servidor antes de que arranque el router del frontend.

Cada URL indexable necesita un estado del servidor con sentido. Las páginas inexistentes devuelven 404; el contenido movido redirige; los fallos temporales de la aplicación devuelven 5xx.

3. Los enlaces no se pueden rastrear

Esto parece navegación para un usuario, pero no es una vía de rastreo fiable:

<span onclick="goTo('/products')">Products</span>

Usa:

<a href="/products">Products</a>

Un router del cliente puede seguir interceptando la navegación siempre que el ancla contenga una URL real.

4. JavaScript reescribe el canonical

El canonical debe estar presente en el HTML de origen y mantenerse estable. Si el código fuente apunta a la URL A y un script lo cambia a B, el rastreador recibe señales contradictorias en etapas distintas. Del mismo modo, no esperes que JavaScript elimine el noindex; Google puede ver la directiva y omitir el renderizado.

5. Las reglas de robots bloquean bundles o API

La aplicación puede necesitar JavaScript, CSS o una API pública para construir el contenido. Cuando Googlebot no puede cargar esos recursos, el renderizado puede quedar en blanco o incompleto.

Proteja las API privadas. Verifique el renderizado público y los recursos con las herramientas de red del navegador e Inspección de URLs de Search Console; detectar Cloudflare no verifica políticas WAF privadas.

6. El renderizado depende del almacenamiento local, las cookies o la ubicación

Googlebot llega como un visitante nuevo. Si el contenido principal solo aparece cuando existe un token en localStorage, una cookie de consentimiento especial o un resultado de geolocalización, el rastreador puede recibir un estado vacío.

Sirve una versión predeterminada útil. La personalización debe mejorarla, no sustituir todo el tema de la URL.

7. La hidratación falla

El SSR puede enviar un HTML completo y después un error de hidratación borra contenido o crea un DOM distinto. El buscador aún puede leer la respuesta, pero la experiencia del usuario y los enlaces posteriores al renderizado pueden romperse.

Vigila en producción los errores de consola, los avisos de discrepancia de hidratación y las solicitudes fallidas. Los fallos que afectan a bots o a dispositivos más lentos son fáciles de pasar por alto en un QA rutinario.

CSR, SSR, SSG y renderizado híbrido

Los blogs, las landing pages, las categorías y la documentación suelen beneficiarse del SSR o el SSG. Un panel con autenticación no necesita indexarse, así que el CSR es perfectamente adecuado allí.

El dynamic rendering se ha usado para enviar un HTML especial a los bots, pero mantener dos versiones genera desviaciones y costes. Siempre que sea posible, sirve el mismo contenido principal prerrenderizado a usuarios y rastreadores.

Una auditoría de SEO para JavaScript paso a paso

Paso 1: compara tres versiones

Colócalas una junto a otra:

• el HTML de origen;
• el DOM renderizado en el navegador;
• el HTML renderizado o la captura de la inspección de URL.

Todo lo que exista solo en tu navegador y falte en la inspección de URL es una pista sólida.

Paso 2: revisa las solicitudes y los recursos

Busca recursos que devuelvan 403, 404, errores de CORS, timeouts o bloqueos de robots. Una sola API que falle puede eliminar toda una región de contenido aunque el bundle principal cargue.

Paso 3: audita los metadatos

Los títulos, las descripciones, los canonical, las directivas de robots y los datos estructurados deben ser específicos de cada ruta. Las SPA suelen conservar los metadatos de la ruta anterior o derivar los canonical de URL sin normalizar.

El Meta Tag Checker muestra el título, el canonical, las etiquetas Open Graph y los encabezados que se entregan para una URL.

Paso 4: inspecciona los enlaces y los sitemaps

Los enlaces internos necesitan href, los sitemaps solo deben contener URL canónicas y cada URL listada debe devolver el estado previsto. Un sitemap no puede compensar una navegación no rastreable.

Paso 5: mide el rendimiento

Los bundles grandes y las tareas largas perjudican a los usuarios y encarecen el renderizado. Ejecuta el Page Speed Checker y fíjate en LCP, INP, TBT y el JavaScript sin usar.

Paso 6: prueba plantillas, no solo la página de inicio

Toma muestras de un artículo, una categoría, un producto, un resultado filtrado, una paginación y una URL inexistente. La mayoría de los defectos de SEO para JavaScript están en rutas que los desarrolladores rara vez abren a mano.

Un fallo típico

Un sitio de empleo usa Vue para obtener las tarjetas de ofertas después de que se monte el componente de la categoría. El H1 de la categoría existe en el código fuente, pero cada tarjeta de oferta la genera JavaScript. Cada tarjeta usa @click en un <div> sin href.

Los visitantes pueden navegar por las ofertas con normalidad, pero a Google le cuesta encontrar los detalles porque el sitemap lista las URL de las ofertas y, sin embargo, faltan rutas rastreables y enlaces internos; usa el XML Sitemap Checker para mejorar el descubrimiento.

La solución no es abandonar Vue. El equipo cambia las tarjetas por <a href>, renderiza en el servidor la lista inicial, mantiene los filtros interactivos en el cliente y devuelve 404 reales para las ofertas caducadas. La arquitectura sigue siendo moderna y el descubrimiento deja de depender de la suerte.

Lista de verificación previa al lanzamiento

• El contenido principal existe en el HTML o se renderiza de forma fiable.
• Las rutas válidas devuelven 200; las rutas eliminadas devuelven 404/410.
• La navegación importante usa <a href>.
• Las directivas canonical y robots existen en el código fuente y se mantienen estables.
• Los CSS, JavaScript y API necesarios son rastreables.
• Los estados vacíos para visitantes nuevos no sustituyen al contenido principal.
• Los metadatos se actualizan correctamente al navegar.
• Los datos estructurados aparecen en el HTML renderizado.
• Móvil y escritorio muestran un contenido principal equivalente.
• La inspección de URL ve lo que ve un visitante.

Cómo monitorizar el SEO para JavaScript tras el lanzamiento

Una inspección puntual detecta los defectos evidentes, pero las aplicaciones JavaScript cambian con frecuencia. Añade un pequeño conjunto de comprobaciones en producción para que los fallos de SEO salgan a la luz antes de que Search Console informe de una tendencia.

Monitoriza rutas públicas representativas con una prueba a nivel de HTML:

• el título y el canonical esperados existen en la respuesta;
• el encabezado principal y un fragmento de contenido reconocible están presentes;
• el código de estado coincide con el estado de la ruta;
• al menos un enlace interno importante tiene un href real;
• las directivas de robots no cambian de forma inesperada.

Ejecuta una segunda comprobación con navegador renderizado para el contenido que depende legítimamente de la hidratación. Captura los errores de consola, las solicitudes de red fallidas, el canonical final, los datos estructurados y una captura de pantalla. La prueba de HTML protege los fundamentos del rastreador; la prueba renderizada protege la aplicación real.

Elige las URL por plantilla y no solo por tráfico. Un monitor de la página de inicio puede seguir en verde mientras se rompen el detalle de producto, la paginación o las rutas localizadas. Mantén un fixture estable para cada plantilla indexable y un fixture negativo que deba devolver 404.

Las anotaciones de lanzamientos son igualmente útiles. Cuando caen las páginas indexadas o las impresiones, saber exactamente cuándo cambió un router, un gestor de consentimiento, un framework de renderizado o una API acorta el diagnóstico. Sin ese historial, los equipos suelen culpar a una actualización del algoritmo por una regresión introducida por su propio despliegue.

En sitios más grandes, compara automáticamente el HTML de origen y el DOM renderizado. Genera una alerta cuando la página renderizada pierda una gran parte del texto o de los enlaces, o cuando el contenido aparezca solo tras una acción retrasada del usuario. Estas comprobaciones no sustituyen a la inspección de URL, pero detectan a diario errores evitables.

Comprobación completa: usa el SEO Checker en una URL representativa y una auditoría SEO gratuita para detectar problemas repetidos en las plantillas.

Conclusión

JavaScript no hace fracasar el SEO. El daño real lo causan el contenido que existe solo tras un clic, los códigos de estado incorrectos, los enlaces sin href y los metadatos que cambian tarde. Haz que la respuesta inicial tenga sentido, mantén honestas las URL y los estados, y usa JavaScript para mejorar la experiencia en lugar de ocultar el contenido principal.

Referencia: Google Search Central – JavaScript SEO basics.