Aprende a auditar las 13 reglas críticas de JavaScript rendering en SEO: DOM renderizado, diferencias entre HTML crudo y renderizado, detección de SSR, recursos bloqueados y modificaciones post-render. Guía técnica con ejemplos de código y checklist accionable.
Resumen: El JavaScript rendering es el punto ciego más peligroso del SEO técnico moderno. Puedes tener un title perfecto, un canonical impecable y un H1 optimizado en tu código fuente, pero si Google ve algo distinto cuando renderiza tu página con su motor JavaScript, todo ese trabajo no sirve para nada. Esta guía detalla las 13 reglas que debes auditar para asegurarte de que lo que Googlebot rastrea es exactamente lo que has construido — y que tu web puede escalar hasta las cimas más altas de las SERPs sin que el JavaScript te frene a mitad de la ruta.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Hace diez años, el SEO técnico era relativamente sencillo: el HTML que enviaba el servidor era exactamente lo que Googlebot leía. Si tu título estaba en el código, Google lo veía. Si tu canonical estaba en el <head>, Google lo respetaba. La relación entre lo que construías y lo que Google indexaba era directa y transparente.
Hoy esa relación es mucho más compleja. La proliferación de frameworks JavaScript — React, Vue, Angular, Next.js, Nuxt.js, Svelte — ha cambiado fundamentalmente la forma en que se construyen las webs. Muchas de ellas envían al navegador un HTML casi vacío (a veces solo <div id="root"></div>) y luego construyen todo el contenido dinámicamente con JavaScript. Para un usuario con un navegador moderno, la experiencia es fluida e invisible. Para Googlebot, es un obstáculo a superar.
El problema fundamental es que Google utiliza dos etapas separadas para procesar las páginas web con JavaScript:
La brecha temporal entre estas dos etapas puede ser de días, semanas o incluso más tiempo, dependiendo de la frecuencia de rastreo del sitio. Durante ese tiempo, tu contenido generado por JavaScript puede no estar indexado. Y si hay discrepancias entre el HTML crudo y el DOM renderizado, Google puede tomar decisiones de indexación basadas en información incorrecta o contradictoria.
Cuando alguien menciona «JavaScript rendering en SEO», la respuesta instintiva es pensar en SPAs (Single Page Applications) puras, construidas completamente en el lado del cliente. Pero el problema es mucho más amplio:
Si tu web utiliza JavaScript de alguna forma — y prácticamente todas lo hacen — las 13 reglas de esta guía son relevantes para ti.
Una auditoría de JavaScript rendering compara dos versiones de cada página:
La auditoría detecta discrepancias entre ambas versiones, verifica que el contenido crítico para el SEO (título, descripción, H1, canonical, noindex, enlaces internos) existe y es correcto en el DOM renderizado, y comprueba que los recursos necesarios para el renderizado no están bloqueados.
Para entender por qué las 13 reglas importan, necesitas tener claro cómo funciona el proceso de renderizado de Google. Este es el mapa del terreno que Googlebot recorre antes de indexar tu página:
Fase 1 — Rastreo inicial: Googlebot visita tu URL y descarga el HTML crudo del servidor. Si detecta que la página tiene JavaScript, la coloca en una cola de renderizado. La prioridad de esta cola depende del PageRank del sitio, la frecuencia de actualización de las páginas y la capacidad de recursos del sistema de Google.
Fase 2 — Renderizado (WRS): El Web Rendering Service (WRS) de Google procesa la URL. WRS es esencialmente Chromium — el motor del navegador Chrome — configurado para ejecutar JavaScript exactamente como lo haría un navegador real. Ejecuta los scripts, espera a que las peticiones asíncronas se resuelvan (hasta cierto punto), y captura el DOM resultante.
Fase 3 — Indexación del DOM renderizado: Google combina la información del HTML crudo con la del DOM renderizado para crear la versión final que se indexa. Si hay contradicciones entre ambas versiones (por ejemplo, un canonical diferente), Google debe decidir a cuál de las dos hacer caso — y esa decisión no siempre es la que tú esperarías.
Googlebot no renderiza exactamente igual que tu navegador. Hay restricciones importantes que tienes que conocer:
Tiempo de ejecución limitado: Google no espera indefinidamente a que el JavaScript se ejecute. Si tu contenido tarda demasiado en cargarse (por peticiones a APIs lentas, lazy loading agresivo, o código ineficiente), puede que Google lo indexe sin él.
Recursos bloqueados: Si tu robots.txt bloquea los archivos JavaScript o CSS que necesita tu página para renderizarse, Google no podrá construir el DOM completo. Esto es un error común y uno de los más graves.
Sin interacción del usuario: Google no hace clic, no hace scroll, no rellena formularios. El contenido que solo aparece tras una interacción del usuario (click en un acordeón, scroll para cargar más contenido con infinite scroll) puede no ser indexado.
Versión de Chromium: Google actualiza su versión de Chromium periódicamente, pero puede ir rezagado respecto a la versión actual. APIs de JavaScript muy recientes pueden no estar disponibles.
Sin cookies de sesión ni localStorage de usuario: Google renderiza la página como un usuario anónimo que visita por primera vez. El contenido que depende de cookies de sesión, autenticación o localStorage no se verá.
Entendidas estas limitaciones, las 13 reglas de auditoría tienen todo el sentido. Son una guía para asegurarte de que tu web supera estos obstáculos y que Googlebot puede recorrer tu ruta sin tropiezos.
El primer grupo de reglas verifica algo aparentemente básico pero que muchas webs con JavaScript no cumplen: que los elementos SEO más críticos existen en el DOM renderizado. No en el código fuente, no como comentarios, no como variables JavaScript pendientes de inyectarse: en el DOM real que Googlebot procesa.
ID de regla: js-rendered-title
El tag <title> es el elemento más importante de una página desde el punto de vista del SEO. Es lo que Google muestra en los resultados de búsqueda (aunque puede reescribirlo) y uno de los factores de ranking más directos que existen.
En webs con JavaScript del lado del cliente puro, el <title> inicial en el HTML puede ser genérico («Loading…», el nombre de la app, o incluso estar vacío), y el título real se inyecta dinámicamente después de que el JavaScript carga los datos de la página. Esta práctica rompe esta regla porque si Google no renderiza la página o la renderiza incompleta, indexa un título inútil o vacío.
Ejemplo del problema:
<!-- HTML crudo que envía el servidor — lo que Google ve inicialmente -->
<head>
<title>Mi App</title>
</head><!-- DOM renderizado después del JavaScript — lo que Google ve en la segunda pasada -->
<head>
<title>Auditoría SEO para empresas de Almería | Escala14</title>
</head>En este ejemplo, si Google no renderiza la página, indexa «Mi App» como título. Si la renderiza pero hay un retraso de semanas, durante ese tiempo el resultado en las SERPs muestra «Mi App» en lugar del título optimizado.
La solución correcta para sitios con frameworks JavaScript:
getServerSideProps), Nuxt.js o Astro hacen esto de forma nativa.✅ Cómo auditarlo: Compara el <title> en el código fuente (Ctrl+U en el navegador) con el <title> en el inspector de elementos (F12). Si son diferentes, tienes un problema. Herramientas como SEOmator, Screaming Frog con el modo JavaScript activado, o la herramienta de Inspección de URL en Google Search Console te muestran el DOM renderizado.
ID de regla: js-rendered-description
La meta description no es un factor de ranking directo, pero sí tiene un impacto real en el CTR porque Google la usa (cuando lo considera apropiado) como snippet en los resultados. Una página sin meta description, o con una meta description genérica, deja a Google elegir cualquier fragmento de texto de la página para el snippet — con resultados generalmente peores que un snippet controlado.
El mismo patrón problemático del título ocurre con la meta description en webs JavaScript-heavy:
<!-- HTML crudo -->
<meta name="description" content="">
<!-- DOM renderizado (correcto) -->
<meta name="description" content="Servicios de auditoría SEO técnica en Almería. Detectamos y corregimos los problemas que frenan tu posicionamiento. Sin compromiso.">Error especialmente frecuente con CMS headless: En arquitecturas headless (Sanity + Next.js, Contentful + Gatsby, etc.), la meta description se obtiene de una llamada API que se resuelve en el cliente. Si el desarrollador no configura correctamente el SSR para el <head>, la meta description llega vacía al rastreador.
✅ Cómo auditarlo: En Google Search Console, ve a «Páginas» y busca páginas con «Descripción duplicada» o sin descripción. También puedes hacer un fetch as Google desde la Inspección de URL para ver el DOM renderizado completo y comprobar el valor del tag <meta name="description">.
ID de regla: js-rendered-h1
El H1 es la señal más directa que le das a Google sobre el tema principal de la página. En páginas generadas dinámicamente con JavaScript, el H1 puede depender de datos que se cargan de forma asíncrona — el nombre de un producto en un e-commerce, el título de un artículo en un blog headless, el nombre de una categoría en una tienda.
Si esos datos tardan en llegar o si el renderizado está mal configurado, Google puede indexar la página sin H1 — con el consiguiente impacto en el ranking.
Patrón problemático con React:
// Componente que carga datos de forma asíncrona
function ProductPage({ productId }) {
const [product, setProduct] = useState(null);
useEffect(() => {
fetchProduct(productId).then(data => setProduct(data));
}, [productId]);
if (!product) {
return <div>Cargando...</div>; // Google puede indexar esto
}
return (
<div>
<h1>{product.name}</h1> {/* Google puede no ver esto */}
...
</div>
);
}En este ejemplo, si Google renderiza la página y la petición fetchProduct no se completa antes de que WRS capture el DOM, la página se indexa sin H1.
La solución: cargar los datos críticos para el SEO (H1, contenido principal, canonical) en el servidor, no en el cliente. Con Next.js, esto es getStaticProps para páginas estáticas o getServerSideProps para páginas dinámicas.
✅ Cómo auditarlo: usa la herramienta de Inspección de URL de GSC y haz clic en «Ver página renderizada». Busca el H1 en el HTML renderizado que muestra. Si no aparece, tienes un problema de renderizado.
ID de regla: js-rendered-canonical
El canonical (<link rel="canonical">) es la directiva que le dice a Google cuál es la URL principal de una página cuando hay contenido duplicado o muy similar en varias URLs. Es crítico para consolidar señales de ranking y evitar la canibalización de palabras clave.
Si el canonical se inyecta por JavaScript, el HTML crudo no tiene canonical — lo que significa que en la primera pasada de rastreo, Google no tiene orientación sobre la URL preferida. Puede indexar la URL con parámetros de seguimiento, la versión sin trailing slash, o cualquier otra variante que haya rastreado primero.
Ejemplo de canonical inyectado por JavaScript (problemático):
// En el componente Page
useEffect(() => {
const link = document.createElement('link');
link.rel = 'canonical';
link.href = 'https://escala14.com/agencia-seo/';
document.head.appendChild(link);
}, []);Este patrón es especialmente dañino porque el canonical no existe en el HTML crudo que Google recibe inicialmente. En la segunda pasada de renderizado, Google verá el canonical correcto — pero para entonces ya puede haber indexado la URL incorrecta basándose en el rastreo inicial.
La solución más robusta: el canonical debe estar siempre en el HTML que envía el servidor, nunca inyectarse por JavaScript. Frameworks como Astro, Next.js (con el componente <Head>), o Nuxt.js (con useHead) permiten renderizar el canonical en el servidor de forma nativa.
✅ Cómo auditarlo: inspecciona el código fuente (Ctrl+U) y busca <link rel="canonical". Si no aparece en el código fuente pero sí en el inspector de elementos (F12), estás en el patrón problemático descrito arriba.
El segundo grupo de reglas entra en un territorio más sofisticado — y más preocupante desde el punto de vista de la confianza de Google: la detección de discrepancias entre el HTML crudo y el DOM renderizado en elementos de control de indexación. Estas reglas no solo verifican que los elementos existen, sino que comprueban que son coherentes entre las dos versiones de la página.
ID de regla: js-canonical-mismatch
Esta regla es más grave que simplemente no tener canonical. Un mismatch de canonical ocurre cuando el HTML crudo tiene un canonical que apunta a una URL, y el DOM renderizado (tras el JavaScript) tiene un canonical que apunta a otra URL diferente.
¿Por qué es esto especialmente problemático? Porque es exactamente el patrón que usa el cloaking: mostrar contenido diferente a los bots que a los usuarios. Google es muy sensible a este tipo de señales, y aunque la mayoría de los casos de canonical mismatch son bugs involuntarios y no intentos deliberados de manipulación, el sistema de Google puede interpretar la discrepancia de forma negativa.
Escenarios reales donde ocurre el canonical mismatch:
Escenario A — Script de A/B testing: Una herramienta de A/B testing cambia la URL canónica para cada variante del test. El HTML crudo tiene el canonical de la variante A, pero el JavaScript de la herramienta de testing inyecta el canonical de la variante B en el DOM.
Escenario B — Sistema de personalización: Un sistema de recomendaciones reescribe el canonical de una página de producto basándose en de dónde viene el usuario (referral, email, directo). Desde el punto de vista del servidor, el canonical es siempre el mismo. Pero el script de personalización lo modifica según la fuente de tráfico.
Escenario C — Error en la migración de dominio: Durante una migración, los canonicals del HTML crudo todavía apuntan al dominio antiguo, pero un script de redirección fue actualizado para apuntar al dominio nuevo en el DOM renderizado.
<!-- HTML crudo — canonical original -->
<link rel="canonical" href="https://antiguo-dominio.com/producto/">
<!-- DOM renderizado — canonical actualizado por JavaScript -->
<link rel="canonical" href="https://nuevo-dominio.com/producto/">Qué hace Google ante un canonical mismatch: Google elige uno de los dos canonicals, generalmente favoreciendo el del HTML crudo por ser la señal más temprana y menos susceptible de manipulación. Esto significa que si tu canonical «real» está solo en el DOM renderizado, Google puede ignorarlo y usar el del HTML crudo — que puede ser incorrecto.
✅ Cómo auditarlo: Compara el valor de <link rel="canonical"> en el código fuente (Ctrl+U) con el valor en el DOM renderizado (F12, inspector). Si son diferentes, tienes un canonical mismatch que debes corregir.
ID de regla: js-noindex-mismatch
Esta es la regla más crítica de todo el grupo — y posiblemente la que tiene consecuencias más graves si falla. Un mismatch de noindex ocurre cuando la directiva de indexación (<meta name="robots" content="noindex">) es diferente entre el HTML crudo y el DOM renderizado.
Hay dos escenarios posibles, y ambos son problemáticos:
Escenario A — noindex en HTML crudo pero no en el DOM renderizado: El servidor envía noindex, pero el JavaScript lo elimina o lo reemplaza por index. Esto puede parecer «bueno» desde el punto de vista del webmaster que quiere que la página se indexe, pero desde el punto de vista de Google es una señal de alerta: ¿por qué el servidor dice «no me indexes» pero el JavaScript dice «indexame»? Este es exactamente el patrón que usaría alguien que quiere esconder contenido de los crawlers manuales de Google.
Escenario B — index en HTML crudo pero noindex en el DOM renderizado: Más común en webs con JavaScript mal configurado. El HTML crudo no tiene restricciones de indexación, pero el JavaScript inyecta un noindex basándose en alguna condición — por ejemplo, un script de gestión de contenido que marca ciertas variantes de página como noindex. El resultado es que Google puede no indexar páginas que sí quieres que estén indexadas.
<!-- HTML crudo — sin restricciones de indexación -->
<head>
<meta name="robots" content="index, follow">
</head>
<!-- DOM renderizado — noindex inyectado por JavaScript -->
<head>
<meta name="robots" content="noindex, follow">
</head>Por qué Google toma este muy en serio: Google sigue la directiva noindex independientemente de cómo se haya establecido — ya sea en el HTML crudo o en el DOM renderizado. Pero un mismatch es una señal de inconsistencia que puede derivar en comportamientos impredecibles de indexación. Además, cambiar la directiva de indexación dinámicamente es una técnica de cloaking conocida, lo que pone tu web bajo mayor escrutinio.
Origen más frecuente de este bug:
noindex las páginas de producto fuera de stock mediante JavaScriptnoindex en entornos de desarrollo pero que por error se activan en producción✅ Cómo auditarlo: Busca <meta name="robots"> en el código fuente y compáralo con el valor en el DOM renderizado. Cualquier diferencia debe investigarse y corregirse inmediatamente.
El tercer grupo de reglas es sutil pero importante. No se trata de que los elementos estén ausentes en el DOM renderizado (eso lo cubren las reglas 1-4), sino de detectar si el título, la meta description o el H1 cambian de valor entre el HTML crudo y el DOM renderizado. Un cambio en estos elementos post-render puede ser intencional (para personalización) o un bug — pero en cualquier caso, Google procesará el valor renderizado, no el del HTML crudo.
ID de regla: js-title-modified
Si el <title> del HTML crudo es «Agencia SEO Almería | Escala14» pero el DOM renderizado muestra «Agencia SEO | Escala14» (sin la ciudad), Google indexará el segundo. Tu estrategia de keyword targeting para búsquedas locales se va por la borda sin que te hayas dado cuenta.
Causas más frecuentes de modificación del título post-render:
Herramientas de A/B testing de títulos: Algunas herramientas de optimización de CTR (como ClickFlow o TitleTester) cambian el título de la página mediante JavaScript para testear cuál tiene mejor tasa de clics. Si Googlebot renderiza la variante B del título, indexa la variante B — lo que puede distorsionar tus datos y crear inconsistencias en el posicionamiento.
Scripts de personalización: Plataformas que personalizan el contenido según el tipo de usuario (nuevo vs. recurrente, por sector, por país) pueden modificar el título para cada segmento. Google siempre ve el título de un usuario nuevo anónimo — que puede no ser el título más optimizado.
Sistemas de traducción automática: Scripts como Weglot que traducen el contenido al vuelo pueden modificar el título según el idioma detectado, lo que puede crear inconsistencias con las directivas hreflang.
Errores en la inicialización de frameworks: En algunos casos, el framework JavaScript inicializa el <title> con un valor genérico («loading» o el nombre del sitio) y luego lo actualiza con el valor correcto. Si hay un estado intermedio que Google captura, puede que se indexe el valor genérico.
✅ Cómo auditarlo: Herramientas como SEOmator comparan automáticamente el título del HTML crudo con el del DOM renderizado y marcan cualquier diferencia. También puedes hacerlo manualmente: compara el valor de <title> en Ctrl+U con el del F12 > inspector de elementos.
ID de regla: js-description-modified
El mismo principio se aplica a la meta description. Si el servidor envía una meta description y el JavaScript la modifica después, Google procesa la versión modificada — que puede ser mejor, igual, o peor que la original.
El escenario más problemático: Imagina que tienes una meta description cuidadosamente redactada en tu servidor: «Auditoría SEO técnica en Almería. Detectamos los problemas que frenan tu posicionamiento y los corregimos. Contacta sin compromiso.» Pero tienes un script de personalización que reemplaza la meta description por un mensaje genérico para usuarios de determinadas regiones. Google renderiza la página y ve la versión genérica. Tu CTR cae porque el snippet en las SERPs es el genérico, no el optimizado.
Otro caso real: Herramientas de gestión de etiquetas (como Google Tag Manager) pueden incluir tags que modifican el <head> de la página. Si un webmaster añade un script en GTM que actualiza la meta description con fines de testing, ese cambio afecta al DOM renderizado que Google procesa.
La regla es simple: la meta description debe ser idéntica en el HTML crudo y en el DOM renderizado, o si cambia, que sea de forma controlada y conscientemente, sabiendo que Google indexará la versión renderizada.
✅ Cómo auditarlo: Compara <meta name="description" content="..."> en la vista de código fuente y en el inspector de elementos después de la carga completa de la página.
ID de regla: js-h1-modified
El H1 es la señal semántica más directa sobre el tema de la página. Si el H1 del HTML crudo y el H1 del DOM renderizado son diferentes, Google se queda con el del DOM renderizado — y si hay discrepancia, puede que no sea el que has optimizado para tu keyword principal.
Escenario habitual en e-commerce: Una tienda online sirve el HTML con el nombre completo del producto: «Zapatillas de trail running Salomon Speedcross 6 Hombre». Pero un script de personalización del catálogo recorta el nombre a «Salomon Speedcross 6» para que se ajuste al diseño en dispositivos móviles. Google indexa «Salomon Speedcross 6» — sin el contexto «zapatillas de trail running hombre» que es clave para el SEO.
En plataformas con contenido A/B: Webs que testean diferentes ángulos de contenido (por ejemplo, testear si un H1 orientado a beneficio («Posiciona más alto con nuestro SEO») funciona mejor que uno orientado a servicio («Agencia SEO en Almería»)) pueden crear confusión si Google renderiza una variante diferente en cada visita.
La solución en todos estos casos pasa por asegurarse de que el H1 se determina en el servidor (con SSR o SSG), no en el cliente. El H1 es demasiado crítico para el SEO como para dejarlo en manos de JavaScript del lado del cliente.
✅ Cómo auditarlo: Busca el elemento <h1> en Ctrl+U y en F12. Si el texto es diferente, investiga qué script está haciendo la modificación. Google Search Console → Inspección de URL → «Ver página renderizada» también muestra el H1 del DOM renderizado.
El cuarto grupo de reglas verifica que, más allá de los metadatos, el contenido sustancial de la página y su red de enlaces internos son accesibles para Google tras el renderizado. Sin contenido suficiente, Google no puede entender de qué trata la página. Sin enlaces internos, el PageRank no fluye y el rastreador no puede descubrir otras páginas de tu sitio.
ID de regla: js-rendered-content
Esta regla verifica que el DOM renderizado contiene texto significativo — no solo tags HTML vacíos, scripts y estilos. Una página que al renderizarse no tiene texto sustancial es, desde el punto de vista de Google, una página vacía. Y las páginas vacías no se indexan, o se indexan como «thin content» con valoraciones de calidad bajas.
El umbral para considerar que una página tiene «contenido suficiente» no es un número fijo, pero herramientas de auditoría como SEOmator tipicamente consideran que menos de 50-100 palabras de texto visible es insuficiente para una página de contenido.
Los casos más extremos: SPAs (Single Page Applications) que muestran una pantalla de carga o un esqueleto de interfaz mientras los datos se cargan de forma asíncrona. Si Google captura el DOM en ese estado intermedio, la «página» que indexa no tiene ningún contenido.
Ejemplo de skeleton que Google puede llegar a indexar:
<!-- Lo que Google puede ver si el renderizado es incompleto -->
<div class="container">
<div class="skeleton-title"></div>
<div class="skeleton-paragraph"></div>
<div class="skeleton-paragraph"></div>
</div>En lugar de el contenido real de la página, Google indexa divs de skeleton vacíos. No hay texto, no hay relevancia semántica, no hay palabras clave.
La magnitud del problema: En webs con SPAs puras construidas con React, Vue o Angular sin SSR ni SSG, esta puede ser la situación de todas o la mayoría de las páginas. Y el resultado es que Google no indexa el contenido — aunque el sitio funcione perfectamente bien para los usuarios.
Soluciones ordenadas por robustez:
SSG (Static Site Generation) — El contenido se genera en build time. Es la solución más robusta y la recomendada para contenido que no cambia en tiempo real. Astro, Next.js, Gatsby, Nuxt.js en modo static.
SSR (Server-Side Rendering) — El servidor genera el HTML con el contenido real en cada petición. Adecuado para contenido dinámico que cambia frecuentemente. Next.js con getServerSideProps, Nuxt.js.
ISR (Incremental Static Regeneration) — Un híbrido entre SSG y SSR: las páginas se pre-generan estáticamente pero se regeneran en el servidor cuando el contenido cambia. Disponible en Next.js.
Pre-rendering con servicio de terceros — Herramientas como Prerender.io, Rendertron o Puppeteer pueden generar versiones estáticas de las páginas para los bots. Funciona, pero añade complejidad y dependencias.
✅ Cómo auditarlo: Desactiva JavaScript en el navegador (F12 → Configuración → Deshabilitar JavaScript) y visita la página. Lo que ves es aproximadamente lo que Googlebot ve en el rastreo inicial (no en el renderizado). Si la página está vacía, tienes un problema grave de JavaScript rendering.
ID de regla: js-rendered-links
Los enlaces internos son el sistema circulatorio de tu web desde el punto de vista del SEO. Permiten a Googlebot descubrir nuevas páginas, distribuyen el PageRank por el sitio y establecen relaciones semánticas entre el contenido. Si los enlaces internos de tu web se generan dinámicamente con JavaScript y no están presentes en el DOM renderizado, Google puede no descubrir páginas importantes de tu sitio.
El problema con la navegación generada por JavaScript:
Muchos frameworks JavaScript generan los menús de navegación, los breadcrumbs, los enlaces de categorías y los links de artículos relacionados de forma dinámica. Si esos elementos no se renderizan correctamente, Googlebot puede no seguir esos enlaces y todo el contenido que apuntan se vuelve «huérfano» desde su perspectiva.
Caso específico — menús de React renderizados en cliente:
// Menú generado en el cliente — puede no ser visible para Googlebot
function Navigation() {
const [categories, setCategories] = useState([]);
useEffect(() => {
fetchCategories().then(data => setCategories(data));
}, []);
return (
<nav>
{categories.map(cat => (
<a href={`/${cat.slug}/`}>{cat.name}</a>
))}
</nav>
);
}Si Google renderiza este componente antes de que la llamada a fetchCategories() se complete, el <nav> aparece vacío en el DOM. Sin esos enlaces, Google no puede descubrir las páginas de categorías a través de la navegación.
Otro escenario crítico — paginación JavaScript: Si tu paginación se implementa con JavaScript (carga más artículos al hacer clic, infinite scroll) en lugar de con enlaces HTML reales (<a href="/campamento-base/?page=2">), Google no puede seguir la paginación y solo indexa el contenido de la primera «página».
La regla práctica: Todos los enlaces internos que son importantes para el descubrimiento de contenido (menú de navegación, breadcrumbs, artículos relacionados, paginación, links de categorías) deben ser tags <a href="..."> con URLs completas, presentes en el DOM renderizado. El routing del lado del cliente (con history.pushState) puede funcionar perfectamente para la experiencia del usuario, pero debe complementarse con tags <a> reales para los bots.
✅ Cómo auditarlo: En el inspector de elementos (F12), busca todos los <a href=""> y verifica que los principales enlaces de navegación están presentes. Herramientas como Screaming Frog con el modo JavaScript habilitado rastrean el DOM renderizado y reportan todos los enlaces internos encontrados.
El quinto y último grupo de reglas cubre dos aspectos infraestructurales que determinan la capacidad base de renderizado: si Google puede acceder a los recursos que necesita para ejecutar el JavaScript, y si tu web usa Server-Side Rendering (o al menos pre-rendering) como estrategia.
ID de regla: js-blocked-resources
Esta es la regla que más sitios violan sin saberlo — y una de las más fáciles de corregir una vez detectada. Si tu archivo robots.txt bloquea las rutas donde están alojados los archivos JavaScript o CSS necesarios para renderizar la página, Google no puede ejecutar ese JavaScript y la página queda sin renderizar correctamente.
Google explicitó hace años que bloquear JavaScript y CSS en robots.txt es un error grave de SEO. Sin embargo, el patrón sigue apareciendo, especialmente en:
robots.txt del sitio antiguo bloqueaba carpetas de recursos por error y se migró tal cual/js/ o /static/ pensando que es una práctica de seguridadEjemplo de robots.txt problemático:
User-agent: *
Disallow: /js/
Disallow: /static/
Disallow: /assets/
Disallow: /node_modules/Si tu bundle de JavaScript (por ejemplo, /js/app.bundle.js) está dentro de una carpeta bloqueada, Googlebot no puede descargarlo. Sin ese script, el JavaScript de tu página no se ejecuta y el DOM renderizado es solo el HTML inicial — sin contenido dinámico, sin menú, sin metadatos inyectados por JavaScript.
Cómo detectar qué recursos está bloqueando:
Google Search Console → Cobertura → Inspección de URL → «Ver página renderizada» muestra una lista de los recursos que Googlebot no pudo cargar durante el renderizado. Si ves archivos .js o .css en esa lista, están bloqueados.
La solución:
User-agent: *
Disallow: /admin/
Disallow: /privado/
# No bloquear nunca las carpetas de assets, js, css o static
# Allow: /js/ <-- no hace falta si no hay un Disallow más amplioLa regla es simple: no bloquees en robots.txt ninguna carpeta que contenga recursos (JavaScript, CSS, imágenes, fuentes) que se usen para renderizar las páginas. Puedes bloquear rutas de páginas que no quieres que se indexen, pero nunca las carpetas de recursos.
✅ Cómo auditarlo: En Google Search Console → Herramientas → Tester de robots.txt, prueba las URLs de tus archivos JavaScript principales (el bundle de tu framework, los scripts de terceros críticos). Si aparecen como «Bloqueado», tienes que actualizar el robots.txt inmediatamente.
ID de regla: js-ssr-check
La regla 13 es la más estratégica del grupo: verifica que tu web usa Server-Side Rendering (SSR) o al menos pre-rendering como estrategia de arquitectura. No es una regla que «pases» o «falles» de forma binaria en todos los casos — es más bien una evaluación de si tu infraestructura de rendering es compatible con un SEO óptimo.
Cómo se detecta SSR en una auditoría:
Un auditor de JavaScript rendering detecta SSR comparando el contenido del HTML crudo con el del DOM renderizado. Si el HTML crudo ya contiene el contenido completo (texto, metadatos, enlaces), la página es SSR o SSG. Si el HTML crudo está vacío o casi vacío y el DOM renderizado tiene el contenido, la página es CSR (Client-Side Rendering) pura.
La «firma» de cada tipo de rendering:
| Tipo de rendering | HTML crudo | DOM renderizado |
|---|---|---|
| SSR | Contenido completo | Igual o similar |
| SSG | Contenido completo | Igual o similar |
| ISR | Contenido completo (desde caché) | Igual o similar |
| CSR puro | HTML vacío o esqueleto | Contenido completo |
| CSR con hidratación | HTML completo (inicial) | Puede añadir contenido dinámico |
La diferencia práctica para el SEO:
Con SSR o SSG, Google puede indexar tu contenido en la primera pasada de rastreo, sin necesidad de esperar al proceso de renderizado. Esto significa:
Opciones de arquitectura para implementar SSR/SSG:
Para webs nuevas, las opciones más sólidas son:
getStaticProps), SSR (getServerSideProps) e ISR según la necesidad de cada página.Para webs existentes en CSR puro, la migración a SSR puede ser un proyecto significativo. Una alternativa intermedia es el pre-rendering dinámico: un proxy (Prerender.io, Rendertron) que detecta si la petición viene de un bot y sirve una versión pre-renderizada estática. No es la solución ideal, pero es mejor que CSR puro para el SEO.
✅ Cómo auditarlo: La forma más sencilla es desactivar JavaScript en el navegador y visitar tu web. Si el contenido principal sigue siendo visible, tu web usa SSR o SSG. Si la página aparece vacía o con solo un esqueleto, es CSR puro.
No todas las reglas tienen el mismo impacto en el SEO. Esta tabla te ayuda a priorizar las correcciones:
| Regla | ID | Severidad | Impacto SEO | Prioridad de corrección |
|---|---|---|---|---|
| Mismatch de noindex | js-noindex-mismatch | 🔴 Crítica | Páginas indexadas o no indexadas incorrectamente | Inmediata |
| Detección SSR | js-ssr-check | 🔴 Crítica | Arquitectura base de rendering | Inmediata |
| Recursos bloqueados | js-blocked-resources | 🔴 Crítica | Renderizado imposible | Inmediata |
| Mismatch de canonical | js-canonical-mismatch | 🔴 Alta | Señales de duplicado incorrectas | Alta |
| Canonical renderizado | js-rendered-canonical | 🔴 Alta | Consolidación de señales de ranking | Alta |
| Título renderizado | js-rendered-title | 🟠 Alta | Keyword targeting y CTR | Alta |
| H1 renderizado | js-rendered-h1 | 🟠 Alta | Señal semántica principal | Alta |
| Contenido renderizado | js-rendered-content | 🟠 Alta | Indexabilidad del contenido | Alta |
| H1 modificado | js-h1-modified | 🟠 Media | Coherencia semántica | Media |
| Título modificado | js-title-modified | 🟠 Media | Coherencia de keyword targeting | Media |
| Meta description renderizada | js-rendered-description | 🟡 Media | CTR en SERPs | Media |
| Meta description modificada | js-description-modified | 🟡 Media | Coherencia del snippet | Media-baja |
| Enlaces renderizados | js-rendered-links | 🟡 Media | Descubrimiento de páginas | Media |
Orden de corrección recomendado:
Usa esta lista para auditar el JavaScript rendering de cualquier web:
js-rendered-title): el DOM renderizado contiene un <title> no vacío con el título optimizado de la páginajs-rendered-description): el DOM renderizado contiene <meta name="description"> con contenido relevantejs-rendered-h1): el DOM renderizado contiene al menos un <h1> con el tema principal de la páginajs-rendered-canonical): el DOM renderizado contiene <link rel="canonical"> apuntando a la URL correctajs-canonical-mismatch): el canonical del HTML crudo y el del DOM renderizado son idénticosjs-noindex-mismatch): la directiva robots del HTML crudo y la del DOM renderizado son idénticasjs-title-modified): el <title> no cambia entre el HTML crudo y el DOM renderizadojs-description-modified): la <meta description> no cambia entre el HTML crudo y el DOM renderizadojs-h1-modified): el <h1> no cambia entre el HTML crudo y el DOM renderizadojs-rendered-content): el DOM renderizado contiene suficiente texto visible (mínimo 50-100 palabras de contenido relevante)js-rendered-links): el DOM renderizado contiene enlaces internos siguibles con tags <a href="..."> válidosjs-blocked-resources): ningún archivo JavaScript o CSS crítico para el renderizado está bloqueado por robots.txtjs-ssr-check): la web usa SSR, SSG o pre-rendering, de modo que el contenido principal es accesible en el HTML crudo sin necesidad de ejecutar JavaScriptGoogle puede renderizar la gran mayoría de JavaScript moderno, pero con limitaciones importantes. El mayor problema no es la capacidad técnica sino el tiempo: hay una brecha entre el rastreo inicial y el renderizado que puede durar días o semanas. Además, Google no ejecuta JavaScript infinitamente — hay un tiempo límite y recursos limitados. Si tu JavaScript es lento, depende de peticiones de red o carga contenido de forma muy lazy, puede que Google no lo procese completo. El SSR o SSG elimina estas incertidumbres: si el contenido está en el HTML, Google lo ve inmediatamente.
Generalmente sí, si están correctamente configuradas. Astro genera HTML estático por defecto, con todo el contenido en el HTML crudo. Next.js y Nuxt.js ofrecen SSR y SSG que también envían el HTML completo. Sin embargo, «usar Next.js» no garantiza automáticamente el SSR: si usas useEffect para cargar metadatos críticos, sigues en territorio de rendering del lado del cliente para esos elementos. La configuración correcta del SSR/SSG para el <head> de cada página es esencial.
El A/B testing es uno de los principales causantes de fallos en las reglas de mismatch. Herramientas de testing client-side que modifican el título, el H1, el canonical o el noindex pueden crear discrepancias entre el HTML crudo y el DOM renderizado. Lo más seguro es hacer A/B testing a nivel de servidor (server-side A/B testing) o, si usas testing client-side, excluir a Googlebot de los experimentos y asegurarte de que siempre ve la versión de control sin modificaciones.
Depende de la frecuencia de rastreo de tu web, que a su vez depende de su autoridad y la frecuencia de actualización de contenido. Después de una corrección, puedes solicitar la re-indexación de las páginas afectadas desde Google Search Console → Inspección de URL → «Solicitar indexación». Esto acelera el proceso para páginas individuales. Para cambios masivos en la arquitectura (por ejemplo, migrar de CSR a SSR), el re-rastreo puede tardar entre 1 y 4 semanas dependiendo del tamaño del sitio.
Sí, y de forma significativa. El CSR puro tiende a tener métricas de Core Web Vitals peores que el SSR/SSG, especialmente en el LCP (Largest Contentful Paint). Si el elemento más grande de la página (normalmente una imagen o un bloque de texto) se carga vía JavaScript, el LCP se dispara. Con SSR/SSG, el HTML ya contiene el elemento, y el LCP refleja el tiempo de carga de la imagen o el tiempo de renderizado del texto, que suelen ser mucho menores.
Las principales opciones gratuitas son: Google Search Console (Inspección de URL → «Ver página renderizada») es la herramienta más directa — te muestra exactamente lo que Google ve. Chrome DevTools (F12) permite ver el DOM renderizado en tiempo real y deshabilitar JavaScript para comparar con el HTML crudo. La herramienta Tester de robots.txt de Google Search Console te permite verificar si los recursos de tu web están bloqueados. Para un análisis más completo y automatizado de las 13 reglas, herramientas de auditoría SEO como SEOmator revisan el DOM renderizado de forma sistemática en múltiples páginas.
El presupuesto de renderizado (rendering budget) es el límite de recursos que Google destina al renderizado de JavaScript de cada sitio. A diferencia del crawl budget (el número de páginas que Google rastrea), el rendering budget es menos documentado, pero existe: Google no renderiza todas las páginas inmediatamente ni con la misma prioridad. Sitios con muchas páginas importantes en CSR pueden ver que algunas se renderizan rápido y otras tardan semanas. La mejor forma de gestionar el rendering budget es reducir la dependencia del renderizado client-side migrando a SSR o SSG, de modo que Google no necesite «gastar» presupuesto de renderizado para acceder al contenido.
El JavaScript rendering no es un detalle técnico menor — es la diferencia entre una web que Google puede rastrear, renderizar e indexar correctamente, y una web que parece perfecta en el navegador pero que desde el punto de vista del bot de búsqueda está llena de trampas.
Las 13 reglas que hemos recorrido en esta guía son el mapa del terreno. Con ellas puedes identificar exactamente dónde está el problema y con qué urgencia hay que resolverlo. La buena noticia es que la mayoría de estos problemas tienen soluciones claras: SSR o SSG para los problemas estructurales, ajustes de configuración para los problemas de metadatos, y una revisión del robots.txt para los recursos bloqueados.
El ascenso al SEO técnico exigente no requiere dar todos los pasos a la vez. Empieza por los críticos — la detección SSR, los recursos bloqueados, el mismatch de noindex — y ve avanzando hacia los de impacto medio. Cada regla que superas es un obstáculo menos entre tu web y las posiciones que merece.
Si quieres saber exactamente cómo pasa tu web las 13 reglas de JavaScript rendering — y cuáles necesitan atención — podemos hacer la auditoría juntos. Trazaremos la ruta más eficiente para que tu infraestructura técnica esté a la altura de tu contenido.
Solicitar auditoría SEO gratuita → Ver nuestros servicios SEO →
Audita las 10 reglas de internacionalización SEO: atributo lang correcto, validación de hreflang, return links, conflictos y mismatches. Guía técnica con ejemplos de código y herramientas.
Aprende a detectar y corregir los 5 problemas móviles que Google comprueba en tu web: tamaños de fuente, scroll horizontal, intersticiales intrusivos y configuración del viewport. Guía técnica con checklist.
Una redirección mal configurada puede costar posiciones, link equity y rastreabilidad. Audita las 8 reglas de redirects SEO: bucles, tipos 301/302, meta refresh, JavaScript redirects y más.
/ Volver al campamento
Más de 20 artículos publicados sobre SEO, diseño web y marketing digital, con datos reales y reglas auditables.