# SEO JavaScript: problemas de renderizado y cómo arreglarlos

> SEO JavaScript: los problemas de renderizado ocultan contenido, enlaces y etiquetas a Google y a los bots de IA. 9 causas, cómo detectarlas y corregirlas.

URL: https://seorecheck.com/es/blog/javascript-seo-rendering-problems · Publicado: 2026-10-28 · [English](https://seorecheck.com/blog/javascript-seo-rendering-problems.md), [Українська](https://seorecheck.com/ua/blog/javascript-seo-rendering-problems.md)

Los problemas de renderizado JavaScript en SEO aparecen cuando el contenido, los enlaces o las metaetiquetas de una página solo se muestran después de que JavaScript se ejecute en el navegador. Google tiene que renderizar la página antes de poder verlos, y ese paso puede retrasarse o fallar; además, muchos rastreadores de IA no ejecutan JavaScript en absoluto. La solución es incluir el contenido crítico en el HTML que envía el servidor.

En esta guía verás cómo procesa Google el JavaScript, los nueve problemas de renderizado que más perjudican a los sitios, cómo comprobar lo que realmente ven los rastreadores y qué solución elegir.

## ¿Cómo renderiza Google las páginas con JavaScript?

Google procesa las páginas con JavaScript en tres fases: rastreo, renderizado e indexación. Primero descarga el HTML sin procesar, después pone la página en una cola para que la renderice un navegador Chromium sin interfaz (headless) y solo entonces indexa lo que muestra la página renderizada. Todo lo que falla en el renderizado nunca llega al índice.

Según los [conceptos básicos de SEO en JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=es) de Google, Googlebot pone en cola de renderizado todas las páginas con código de estado `200`, salvo que una metaetiqueta o encabezado robots indique que no se indexe la página. Una página «puede permanecer en esta cola unos segundos, pero puede tardar más». El renderizado usa una versión siempre actualizada (evergreen) de Chromium, así que el JavaScript moderno suele estar soportado.

Suena tranquilizador, pero tiene tres consecuencias:

- **Dos oportunidades de fallar.** El HTML sin procesar y el DOM renderizado pueden no coincidir, y Google usa el HTML sin procesar para algunas decisiones (códigos de estado, `noindex`) antes de renderizar.
- **Retraso.** El contenido que solo existe tras el renderizado se detecta más tarde que el que está en el HTML.
- **Sin interacción.** Googlebot carga la página; no hace clic, no hace scroll ni inicia sesión.

## ¿Por qué los problemas de renderizado JavaScript también afectan a la búsqueda con IA?

Muchos rastreadores de IA descargan tu HTML pero no ejecutan JavaScript, así que el contenido que solo aparece tras el renderizado es invisible para ellos. Una página que Google indexa perfectamente puede estar en blanco para los bots que alimentan las respuestas de ChatGPT, Claude o Perplexity.

El estudio de Vercel [The rise of the AI crawler](https://vercel.com/blog/the-rise-of-the-ai-crawler) (diciembre de 2024) analizó el tráfico de rastreadores en su red y concluyó que «ninguno de los principales rastreadores de IA renderiza JavaScript actualmente», incluidos GPTBot de OpenAI y ClaudeBot de Anthropic. En algunas peticiones descargaban archivos JavaScript, pero no los ejecutaban. Gemini era la excepción, porque usa la infraestructura de renderizado de Google. El comportamiento de los rastreadores puede cambiar y no todos los proveedores lo documentan, así que tómalo como una foto medida en un momento concreto, no como una garantía.

La regla práctica es la misma para ambos públicos: si una frase importa para posicionar o para que te citen en una respuesta de IA, debe estar en la respuesta del servidor. Para una visión más amplia, consulta nuestra guía sobre [GEO vs SEO](https://seorecheck.com/es/blog/geo-vs-seo-differences).

## ¿Cuáles son los problemas de SEO JavaScript más habituales?

Los más comunes son el contenido y los enlaces que solo se cargan en el navegador, la navegación exclusivamente con JavaScript, las páginas de error que devuelven `200`, las etiquetas `noindex` modificadas por script, los recursos bloqueados, el contenido que requiere un clic o scroll y los bundles en caché obsoletos. Cada uno oculta contenido a Google o le envía una señal equivocada.

| Problema | Qué ven Google o los rastreadores de IA | Solución habitual |
|---|---|---|
| Contenido renderizado solo en el cliente | Estructura vacía en el HTML sin procesar; contenido tarde o nunca | SSR, renderizado estático o prerenderizado |
| Enlaces sin `<a href>` | Ninguna URL que seguir, páginas huérfanas | Enlaces reales `<a href="/ruta">` |
| Enrutamiento con hash (`/#/productos`) | Una sola URL para toda la aplicación | History API con rutas reales |
| Páginas de error de SPA que devuelven `200` | Soft 404, páginas de error indexadas | 404 del servidor o `noindex` añadido por JS |
| `noindex` eliminado con JavaScript | La página puede quedar fuera del índice | Etiqueta robots correcta en el HTML sin procesar |
| JS/CSS/API bloqueados en robots.txt | Renderizado roto o vacío | Permitir los recursos de renderizado |
| Contenido tras clic, scroll o permisos | El contenido nunca se carga | Cargar al entrar en el viewport, URLs paginadas |
| Bundles en caché obsoletos | Renderizado antiguo o roto | Nombres de archivo con huella (fingerprint) |
| Estado en cookies/localStorage | Sesión nueva y vacía cada vez | No condicionar el contenido al estado guardado |

### 1. El contenido crítico solo existe tras el renderizado

La típica single-page app (SPA) envía un `<div id="root"></div>` y un bundle. Puede que Google la renderice bien, pero el contenido llega más tarde, y los rastreadores que no renderizan no ven nada. Descripciones de producto, precios, encabezados y cuerpos de artículo suelen ser las víctimas.

### 2. Enlaces que Google no puede seguir

Google indica que [solo puede descubrir enlaces](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=es) que sean elementos `<a>` con atributo `href`. Los menús construidos con `<span onclick>` o con botones que llaman a `router.push()` no le dan a Google nada que rastrear, así que las páginas más profundas quedan huérfanas. Nuestra [guía de enlazado interno](https://seorecheck.com/es/blog/internal-linking-seo-guide) explica cómo corregir la estructura una vez que los enlaces son rastreables.

```html
<!-- Rastreable -->
<a href="/pricing">Pricing</a>

<!-- No rastreable -->
<span onclick="goTo('/pricing')">Pricing</span>
<a onclick="goTo('/pricing')">Pricing</a>
```

### 3. Fragmentos hash en lugar de URLs reales

Las URLs como `example.com/#/servicios` parecen páginas distintas para el usuario, pero la [guía para corregir problemas de JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript?hl=es) de Google recuerda que el esquema de rastreo AJAX está obsoleto desde 2015, así que no se puede confiar en el enrutamiento basado en fragmentos. Usa la History API para que cada vista tenga su propia ruta.

### 4. Soft 404 en single-page apps

Cuando una SPA muestra «Producto no encontrado» pero el servidor sigue devolviendo `200`, Google puede indexar la página de error. Google recomienda redirigir a una URL en la que el servidor devuelva un `404` real o añadir `<meta name="robots" content="noindex">` con JavaScript en las vistas de error. Consulta [errores 404 y SEO](https://seorecheck.com/es/blog/404-errors-seo-impact) para saber cuándo un 404 es la respuesta correcta.

### 5. Un `noindex` que JavaScript debería eliminar

Este problema sorprende a muchos equipos. Google afirma que, cuando encuentra una etiqueta `noindex`, «puede omitir el renderizado y la ejecución de JavaScript», por lo que usar JavaScript para eliminar el `noindex` «puede no funcionar como se espera». Si el HTML sin procesar dice `noindex`, da por hecho que la página quedará fuera del índice haga lo que haga tu script después.

### 6. Recursos bloqueados

Si robots.txt bloquea `/static/`, `/_next/`, `/api/` o un script de terceros que renderiza contenido, Google renderiza una página rota. Comprueba que se puedan descargar todos los archivos necesarios para construir el contenido principal. Nuestra [guía de robots.txt](https://seorecheck.com/es/blog/robots-txt-seo-guide) explica los patrones seguros.

### 7. Contenido que requiere interacción del usuario

Las [indicaciones sobre carga diferida (lazy loading)](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading?hl=es) de Google señalan que la Búsqueda de Google «no interactúa con tu página», así que el contenido debe cargarse cuando es visible en el viewport, no al hacer scroll o clic. Los botones «Cargar más», las pestañas que traen contenido al hacer clic y el [scroll infinito](https://seorecheck.com/es/blog/pagination-seo-best-practices) sin URLs paginadas ocultan contenido. Para el scroll infinito, Google recomienda una URL persistente por bloque, como `?page=12`, enlazadas de forma secuencial. Googlebot también rechaza solicitudes de permisos como cámara o ubicación, así que el contenido no debe depender de ellas.

### 8. JavaScript obsoleto en caché

Google advierte que su Web Rendering Service puede ignorar los encabezados de caché y usar JS o CSS desactualizados. Si despliegas un bundle nuevo con el mismo nombre de archivo, Google puede renderizar la página con código antiguo que llama a un endpoint de API ya eliminado. La huella de contenido en el nombre (`main.2bb85551.js`) lo resuelve.

### 9. Depender de cookies, almacenamiento o WebSockets

Google indica que el almacenamiento local, el de sesión y las cookies se borran entre cargas de página, y que WebSockets y WebRTC no son compatibles porque Googlebot usa peticiones HTTP simples. Una página que lee una cookie de consentimiento o una región guardada antes de mostrar el contenido le enseña a Googlebot el estado vacío por defecto.

## ¿Cómo comprobar lo que Google renderiza realmente?

Compara tres versiones de la página: el HTML sin procesar (Ver código fuente o `curl`), el HTML que Google renderizó (Inspección de URLs en Search Console) y lo que ve un usuario en el navegador. Si faltan textos, enlaces o etiquetas importantes en las dos primeras, tienes un problema de renderizado.

Esta es una rutina práctica, plantilla por plantilla:

1. **Revisión del HTML sin procesar.** Ejecuta `curl -s https://example.com/page | grep "tu frase clave"` o abre Ver código fuente (no la pestaña Elements de DevTools, que muestra el DOM renderizado). Si el H1, el texto principal, la canonical y los enlaces internos están ahí, los rastreadores que no renderizan pueden leer la página.
2. **HTML renderizado en Search Console.** En Inspección de URLs, ejecuta *Probar URL publicada* y después *Ver página probada* para ver el HTML renderizado, una captura de pantalla y *Más información*, con los recursos de la página que no se pudieron cargar y los mensajes de la consola de JavaScript. Google remite a esta herramienta y a la prueba de resultados enriquecidos en su [guía de resolución de problemas](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript?hl=es).
3. **Compara las señales.** Comprueba que el title, la [meta description](https://seorecheck.com/es/blog/meta-description-best-practices), la canonical y la etiqueta robots coinciden en el HTML sin procesar y en el renderizado. Los valores contradictorios son una causa habitual de [problemas de indexación](https://seorecheck.com/es/blog/fix-website-indexing-problems).
4. **Revisa el índice.** Busca entre comillas una frase característica del contenido cargado por JS. Si la página está indexada pero la frase no aparece, probablemente Google indexó un renderizado parcial.
5. **Desactiva JavaScript.** Carga la página con JavaScript desactivado en tu navegador. Lo que queda es, aproximadamente, lo que recibe un rastreador de IA que no renderiza.

Hacerlo a mano funciona para unas pocas plantillas; con cientos de URLs necesitas un rastreador que guarde ambas versiones. Una [auditoría SEO gratuita de SEORecheck](https://seorecheck.com/es/request) carga tus páginas en un navegador real y señala el texto que solo es visible después de ejecutarse JavaScript, además de revisar el acceso de los rastreadores de IA en robots.txt.

Síntomas que apuntan al renderizado y no a la calidad del contenido: muchas URLs en «Rastreada: actualmente sin indexar» en plantillas con JS, Google mostrando títulos genéricos como el nombre de tu aplicación y páginas indexadas que no posicionan por nada de su texto. Nuestras guías sobre [rastreada: actualmente sin indexar](https://seorecheck.com/es/blog/crawled-currently-not-indexed-fix) y sobre los [errores de Search Console](https://seorecheck.com/es/blog/google-search-console-errors-explained) te ayudan a distinguir las causas.

## ¿Qué tipo de renderizado es mejor para el SEO?

El renderizado del lado del servidor (SSR) o el renderizado estático es la opción más segura para las páginas que quieres posicionar: todo el contenido está en el HTML, cualquier rastreador puede leerlo y luego JavaScript añade la interactividad. El renderizado del lado del cliente puro está bien para pantallas de aplicación con sesión iniciada que, de todos modos, no deberían indexarse.

| Enfoque | ¿Contenido en el HTML sin procesar? | Ideal para | Cuidado con |
|---|---|---|---|
| Renderizado en el cliente (CSR) | No | Paneles, aplicaciones con login | Invisible para rastreadores que no renderizan |
| Renderizado en el servidor (SSR) | Sí | Páginas de producto, categoría y dinámicas | Carga del servidor, desajustes de hidratación |
| Renderizado estático / SSG | Sí | Páginas de marketing, blogs, documentación | Recompilar cuando cambia el contenido |
| Híbrido (SSR/SSG + hidratación) | Sí | La mayoría de los sitios modernos | Mantener las metaetiquetas en la salida del servidor |
| Renderizado dinámico | Solo para bots | Parche heredado | Google lo considera una solución provisional |

La página de Google sobre [renderizado dinámico](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering?hl=es) es explícita: «era una solución provisional y no una solución a largo plazo», y Google recomienda en su lugar renderizado en el servidor, renderizado estático o hidratación. Si todavía usas un servicio de prerenderizado para bots, planifica sustituirlo.

La mayoría de los frameworks admiten salida desde el servidor: Next.js y Remix para React, Nuxt para Vue, Angular SSR, SvelteKit y Astro. Pasar una app CSR a SSR es un proyecto de verdad, así que empieza por las plantillas que generan tráfico, como las páginas de producto, categoría, servicio y artículo.

## ¿En qué orden corregir los problemas de renderizado JavaScript?

Corrige primero los problemas que ocultan páginas enteras, después los que ocultan contenido y, por último, los que solo ralentizan. Un `noindex` erróneo o una navegación no rastreable cuestan más que un renderizado tardío, así que ordena las correcciones según cuántas URLs valiosas afecta cada una.

Un orden sensato:

1. **Bloqueos de indexación:** `noindex` en el HTML sin procesar, archivos JS/CSS/API bloqueados, soft 404.
2. **Descubrimiento:** convierte la navegación con JavaScript en enlaces `<a href>` y las rutas con hash en rutas reales.
3. **Contenido en el HTML:** lleva los encabezados, el texto, los precios y los datos estructurados a la respuesta del servidor en las plantillas que generan negocio.
4. **Contenido que depende de interacción:** sustituye el contenido cargado con clic o scroll por carga en el viewport y URLs paginadas.
5. **Higiene:** pon huella a los bundles, elimina la dependencia de cookies y almacenamiento, y mantén idénticas las metaetiquetas renderizadas y sin procesar.

El renderizado también afecta a la experiencia de usuario: los bundles pesados retrasan el elemento de contenido más grande y bloquean la interacción, lo que se refleja en las [Core Web Vitals](https://seorecheck.com/es/blog/core-web-vitals-guide) como un LCP deficiente (más de 2,5 s) o un INP deficiente (más de 200 ms). El SSR suele mejorar ambos, pero mídelo en lugar de suponerlo. Tras cualquier actualización del framework, repite las comprobaciones de HTML sin procesar frente a renderizado dentro de tus [pruebas de regresión SEO](https://seorecheck.com/es/blog/seo-regression-testing-website-updates): el renderizado se rompe en silencio.

## Puntos clave

- Google renderiza JavaScript en un paso independiente y en cola; todo lo que falla ahí nunca llega al índice.
- Muchos rastreadores de IA no ejecutan JavaScript, así que el contenido que falta en el HTML sin procesar puede ser invisible para las respuestas de IA.
- Usa enlaces `<a href>` reales y rutas con History API, nunca manejadores de clic ni URLs `#/`.
- Un `noindex` en el HTML sin procesar puede impedir que Google renderice, así que JavaScript no puede eliminarlo de forma fiable.
- Las vistas de error de una SPA necesitan un estado 404 real o una etiqueta `noindex`.
- Compara el HTML sin procesar con el HTML renderizado en Inspección de URLs para cada plantilla.
- Prioriza el renderizado en el servidor o estático para las páginas que deben posicionar; Google considera el renderizado dinámico una solución provisional.

Para ver cómo aparecen estos problemas en un informe terminado, echa un vistazo al [informe de ejemplo](https://seorecheck.com/es/sample).

---

## ¿Quieres saber qué corregir en tu web?

Obtén una vista previa gratuita de la auditoría SEO: tu puntuación y problemas reales, con evidencias de tus páginas.

- [Recibir vista previa gratis](https://seorecheck.com/es/request)
- [Ver informe de ejemplo](https://seorecheck.com/es/sample)