SEO con JavaScript

TL;DR — El SEO para JavaScript gira en torno a una pregunta: ¿pueden los motores de búsqueda ver tu contenido? Los sitios modernos construyen gran parte de la página en el navegador con JavaScript. Si el texto y los enlaces importantes solo aparecen después de ejecutar los scripts, debes confirmar que Google todavía puede acceder a ellos. Normalmente puede hacerlo; los problemas están en los detalles.

Qué es JavaScript SEO

Muchos sitios construyen parte de la página —o toda ella— en el navegador mediante JavaScript. El servidor envía algo de HTML y, después, los scripts completan el contenido, cargan más elementos o cambian de vista sin recargar la página entera. El SEO para JavaScript consiste en asegurarse de que los motores de búsqueda todavía puedan rastrear, renderizar e indexar ese contenido.

Este es el orden en que suceden las cosas para Google:

1. Rastreo — Google descarga el HTML inicial de la URL.
2. Renderizado — Google ejecuta el JavaScript de la página en un navegador para construir la página final (la fase de renderizado).
3. Indexación — Google lee esa página final y la guarda en su índice.

Google las documenta como las tres fases principales para procesar aplicaciones web JavaScript.

Si tu contenido solo aparece después de ejecutar JavaScript, Google debe renderizar la página correctamente antes de poder verlo. La mayoría de las veces lo hace. Cuando no lo consigue, el contenido puede desaparecer de los resultados sin que sea evidente.

Las buenas noticias primero

JavaScript no es malo para el SEO. Google ejecuta una versión actualizada de Chrome y puede ejecutar el mismo JavaScript que tus visitantes. El viejo temor —«Google no puede leer JavaScript»— ya no es cierto.

Lo que sí puede fallar es más específico:

• El contenido necesita un clic o un desplazamiento para cargarse, y Google no hace clic ni se desplaza. Evidencia de esta afirmación Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Alcance: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Fix lazy-loaded content
• Los enlaces no son enlaces reales —son botones o controladores de clic—, así que Google no puede seguirlos. Evidencia de esta afirmación Google can reliably discover links only when they are HTML anchor elements with an href attribute. Alcance: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Make your links crawlable
• Has bloqueado por error los archivos JavaScript o CSS en robots.txt, por lo que Google no puede renderizar correctamente la página.
• La página se ve bien en tu navegador, pero el contenido no aparece en la vista renderizada de Google.

          
            
            
          
          1
          <nav aria-label="Product categories">
        
          
            −
            Línea eliminada. 
          
          2
          <button onclick="goTo('/shoes')">Shoes</button>
        
          
            −
            Línea eliminada. 
          
          3
          <button onclick="goTo('/boots')">Boots</button>
        
          
            
            
          
          4
          </nav>
        

          
            
            
          
          1
          <nav aria-label="Product categories">
        
          
            +
            Línea añadida. 
          
          2
          <a href="/shoes/">Shoes</a>
        
          
            +
            Línea añadida. 
          
          3
          <a href="/boots/">Boots</a>
        
          
            
            
          
          4
          </nav>
        

La lista de verificación simple

• Compara el HTML inicial (clic derecho → Ver código fuente) con el HTML renderizado (herramienta de inspección de URLs de Google Search Console). Si falta contenido importante en la vista renderizada, ese es el problema.
• Comprueba que los enlaces sean elementos <a href> reales, no controladores de clic en un <div>.
• No bloquees los archivos JavaScript o CSS en robots.txt.
• Si una función necesita un clic o un desplazamiento para cargar contenido, asegúrate de que ese contenido también sea accesible de otra manera.
• Para el contenido que deba posicionarse, prefiere el renderizado del lado del servidor o una compilación estática o prerenderizada, donde el contenido ya esté en el HTML inicial. Evidencia de esta afirmación Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Alcance: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

¿Quieres una explicación más profunda de los modos de fallo reales, la trampa del desplazamiento infinito que hace que dos páginas se indexen como una y las pruebas del HTML renderizado? Cambia a la pestaña Avanzado. Para saber cómo funciona el renderizador de Google y qué configuración elegir, consulta la página sobre renderizado.

TL;DR — Google puede ejecutar JavaScript, así que «¿puede Google leer JS?» no es la pregunta correcta. Los modos de fallo son la paridad (DOM inicial frente al renderizado), la interacción (Google no se desplaza ni hace clic), el estado (el renderizador no conserva estado) y el tiempo. Mantén los enlaces como anclas <a href> reales, no bloquees JS ni CSS, carga de forma diferida según el viewport y no según una interacción, devuelve estados reales para los 404 del lado del cliente y recuerda que un noindex en el HTML inicial puede impedir el renderizado antes de que JavaScript lo elimine. Combina únicamente las directivas que se hayan procesado; no supongas que el HTML inicial o el renderizado gana siempre. Vigila especialmente el desplazamiento infinito: un viewport de renderizado alto puede activar el cargador y fusionar dos URL en una sola página indexada. Para conocer el funcionamiento interno y elegir un modo, consulta renderizado.

¿Puede Google leer JavaScript? Sí, esa no es la pregunta.

Google procesa las aplicaciones JavaScript en tres fases: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traducción) «Google procesa las aplicaciones web JavaScript en tres fases principales: 1. Rastreo, 2. Renderizado y 3. Indexación». En la fase intermedia ejecuta el JS en una versión actualizada y sin interfaz gráfica de Chrome para construir el DOM que se indexará. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (traducción) «El renderizado es importante porque los sitios web suelen depender de JavaScript para incorporar contenido a la página y, sin él, es posible que Google no vea ese contenido».

Por tanto, Google sí puede ejecutar tu JavaScript. Las preguntas útiles son más específicas:

• Paridad — ¿El DOM renderizado contiene realmente lo que crees?
• Interacción — ¿Hay algo que requiera un desplazamiento o un clic que Google no vaya a realizar?
• Estado — ¿Dependes de cookies o del almacenamiento local que el renderizador sin estado borra?
• Tiempo — ¿El contenido crítico queda pospuesto detrás de JavaScript lento o tardío?

En cuanto al tiempo, Google pone en cola para el renderizado una página rastreada que ha devuelto un 200: “the page may stay on this queue for a few seconds, but it can take longer than that.” (traducción) «La página puede permanecer en esta cola unos segundos, aunque también puede tardar más». No se ha publicado un retraso ni un tiempo de espera fijo. Una página que devuelva un estado distinto de 200 o que empiece con una directiva noindex puede saltarse la cola de renderizado en lugar de esperar a que JavaScript la cambie.

La mecánica de cómo renderiza Google —el servicio de renderizado web, la ausencia de estado, el almacenamiento en caché y el mito de las «dos oleadas»— se explica en la página sobre renderizado. Aquí me centraré en los problemas prácticos y sus soluciones.

Los enlaces deben ser anclas <a href> reales

Este es el error de SEO para JavaScript más común. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (traducción) «Google solo puede descubrir tus enlaces si son elementos HTML «a» con un atributo href». Un <div> con un controlador onclick, aunque sea pulsable, no es visible para Google como enlace: no lo seguirá y puede que no rastree las páginas que dependan de él para su descubrimiento. Es perfectamente válido inyectar enlaces con JavaScript siempre que terminen como anclas <a href> reales en el DOM renderizado. Sin embargo, esas anclas se analizan después de ejecutar JavaScript: aparecer en el DOM renderizado hace que el enlace sea detectable, pero no garantiza que la URL se rastree, se indexe o se trate igual que un enlace presente en el HTML inicial.

Contenido de carga diferida y controlado por interacción

El renderizador no se comporta como un usuario curioso: “Google Search does not interact with your page.” (traducción) «La Búsqueda de Google no interactúa con tu página». No se desplaza, no hace clic ni pasa el cursor. Por eso no verá el contenido que solo se cargue tras uno de esos eventos.

La recomendación de Google es cargar el contenido cuando entra en el viewport, no cuando actúa el usuario: “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (traducción) «asegúrate de que la implementación de carga diferida cargue todo el contenido pertinente cuando sea visible en el viewport», y “don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.” (traducción) «no apliques carga diferida al contenido que probablemente sea visible en cuanto el usuario abra la página». Usa Intersection Observer o loading="lazy" nativo para las imágenes, nunca un controlador de desplazamiento o clic, de modo que el contenido se cargue durante un renderizado normal.

Desplazamiento infinito: cuando dos páginas se indexan como una

Este es el problema que casi nadie explica, y merece una sección completa.

Googlebot puede renderizar con un viewport considerablemente más alto que una ventana de navegador habitual. Google no publica su tamaño exacto —y este puede cambiar—, así que no diseñes para una cifra concreta: prueba tu propia implementación. Lo importante es el mecanismo. Si el cargador del desplazamiento infinito se activa según la posición del desplazamiento o la altura del viewport, uno más alto de lo esperado puede activar el cargador durante el propio renderizado y añadir al mismo DOM el contenido del siguiente artículo o producto. El contenido de dos URL distintas queda renderizado junto y Google puede indexarlo como una sola página. En mi experiencia, “occasionally, two pages get indexed as one” (traducción) «en ocasiones, dos páginas se indexan como una sola». Me han comunicado páginas «no indexadas» que en realidad se habían indexado dentro de otra página —normalmente la entrada anterior del feed— porque “when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (traducción) «cuando Google alargó el viewport… activó el desplazamiento infinito y cargó otro artículo mientras renderizaba». Comprueba si tu configuración hace esto inspeccionando el HTML renderizado de una URL que debería detenerse antes. No des por hecho un tamaño ni que la implementación sea segura.

Hay dos capas para hacer esto bien.

Haz que el desplazamiento infinito sea compatible con la búsqueda desde el principio. Ofrece una carga paginada debajo del desplazamiento infinito. Cada bloque debe tener “its own persistent, unique URL,” (traducción) «su propia URL única y permanente»; el contenido de cada URL debe ser el mismo cada vez que se cargue; debes evitar parámetros relativos como ?date=yesterday; y conviene “link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set,” (traducción) «enlazar secuencialmente las URL individuales para que los motores de búsqueda puedan descubrirlas en un conjunto paginado». Cuando se cargue un nuevo bloque al desplazarse, debes “update the displayed URL using the History API.” (traducción) «actualizar la URL mostrada mediante la History API». Usa enlaces de paginación <a href> reales y URL únicas; “don’t use URL fragment identifiers” (traducción) «no uses identificadores de fragmento de URL» —la parte situada tras #— para los números de página, porque Google los ignora. Como digo en mi guía de SEO para JavaScript, “if you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (traducción) «Si tienes una configuración de desplazamiento infinito, sigo recomendando una versión paginada para que Google pueda rastrearla correctamente».

Si un cargador defectuoso está fusionando páginas, la solución más rápida es directa: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (traducción) «bloquea el archivo JavaScript que gestiona el desplazamiento infinito para que la función no pueda activarse». Si el cargador no puede ejecutarse durante el renderizado, tampoco puede añadir el contenido de la página siguiente y cada URL vuelve a renderizarse por separado.

Soft-404 después del enrutamiento del lado del cliente

Las aplicaciones de una sola página pueden cambiar el contenido sin modificar el código de estado HTTP, por lo que una vista «no encontrada» puede seguir devolviendo 200. Google puede clasificar esa respuesta como un soft 404 después de evaluar el contenido, pero una petición estática por sí sola no demuestra que Google lo haya hecho. Hay dos correcciones: navegar con la History API y, cuando el recurso no exista de verdad, dirigir a una URL que devuelva un estado 404 real o añadir una etiqueta noindex. Tampoco debes depender de fragmentos de URL para el enrutamiento: “the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.” (traducción) «El sistema de rastreo AJAX está obsoleto desde 2015, así que no puedes confiar en que los fragmentos de URL funcionen con Googlebot».

Una redirección del lado del cliente plantea el mismo problema de evidencia: la respuesta inicial puede seguir siendo 200 hasta que se ejecute JavaScript. Google admite las redirecciones de JavaScript solo como alternativa cuando no son posibles las redirecciones del servidor o mediante actualización meta. Informa por separado del estado estático y de la navegación renderizada observada; no reescribas el estado HTTP en la auditoría ni llames redirección a cada cambio de URL renderizado.

No bloquees JavaScript o CSS en robots.txt

Google no renderizará JavaScript desde archivos bloqueados ni en páginas bloqueadas. Una regla de robots.txt que impida acceder al paquete —o al directorio /_next/, /static/ o /assets/ que lo contiene— puede romper por completo el renderizado: Google obtiene la carcasa, no puede ejecutar los scripts e indexa una página vacía. Comprueba en los recursos de la página de la inspección de URLs si hay elementos bloqueados.

Directivas de paridad DOM y robots conscientes de la etapa

Compara el HTML inicial (Ver código fuente) con el HTML renderizado (inspección de URLs). El contenido que solo existe en el HTML renderizado puede indexarse si el renderizado se completa. El contenido que no aparece en ninguno de los dos estados no existe para Google.

Google documenta un riesgo relacionado con el orden de las fases: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (traducción) «Cuando Google encuentra la etiqueta noindex, puede omitir el renderizado y la ejecución de JavaScript; por eso, usar JavaScript para cambiar o eliminar noindex de la etiqueta meta robots podría no funcionar como se espera». Si el HTML inicial incluye un noindex que pretendías sustituir con JavaScript, Google puede actuar sobre esa directiva inicial y no ejecutar nunca el script que debía eliminarla.

No conviertas esto en una regla universal según la cual «gana lo renderizado». La conciliación depende de cada campo:

Por esta razón, una auditoría debe mantener separados el código fuente, el estado renderizado, los encabezados de respuesta y el estado observado en la búsqueda, en vez de reducirlos a un único valor «efectivo».

Elija un modo de renderizado que coloque el contenido en el DOM

La mayor parte del riesgo del SEO para JavaScript depende de cómo se genera el HTML. En resumen, SSR, el renderizado estático o prerenderizado y la hidratación colocan el contenido en el DOM —o lo hacen con rapidez—, lo que reduce la dependencia de que el renderizador funcione correctamente. El renderizado íntegro del lado del cliente deja más elementos supeditados a que el proceso termine bien, a tiempo y en cada ocasión. El renderizado dinámico es una solución alternativa, no una opción equivalente: la guía de Google, actualizada por última vez en diciembre de 2025, lo describe como una medida provisional, no como una solución a largo plazo, y recomienda en su lugar el renderizado del lado del servidor, el renderizado estático o la hidratación. Como lo explico en mi guía de SEO para JavaScript, “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (traducción) «Cualquier configuración de SSR, renderizado estático o prerenderizado funcionará bien para los motores de búsqueda». El menú completo —CSR, SSR, SSG, hidratación, ISR, edge, streaming y renderizado dinámico—, con una tabla de ventajas y desventajas, está en la página sobre renderizado. Google también describe el renderizado del lado del servidor o el prerenderizado como una buena opción para los usuarios y los rastreadores. Evidencia de esta afirmación Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Alcance: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Cómo hacer las pruebas

La inspección de URLs de Search Console es la fuente de referencia: ejecuta una prueba en directo y examina el HTML renderizado, la captura de pantalla y los recursos de la página y mensajes de consola para saber qué se cargó y qué falló. La prueba de resultados enriquecidos ofrece una comprobación rápida del HTML renderizado. A escala, usa un rastreador que ejecute JavaScript —Ahrefs Site Audit o Screaming Frog en modo de renderizado de JS— para comparar el HTML inicial y el renderizado en todo el sitio.

JavaScript no es malo para el SEO ni es perjudicial por naturaleza. Simplemente es distinto de aquello a lo que muchos profesionales del SEO están acostumbrados. Trabaja con los desarrolladores, introduce el contenido importante en el DOM y deja que las herramientas de Google —no tus suposiciones— determinen qué se ha renderizado.

Adónde ir a continuación: el clúster SEO de JavaScript

Este artículo central es el mapa. Cada tema siguiente cuenta con su propia guía detallada:

Renderizado y arquitectura

• SEO para un CMS headless — cómo afectan las interfaces desacopladas al rastreo, el renderizado, los metadatos, los sitemaps y las etiquetas canonical; qué modo de renderizado elegir; y qué fallos específicos de una arquitectura headless debes conocer.

Guías específicas del marco

• SEO para React — por qué la prioridad de CSR en React crea riesgos de indexación, cómo renderiza Google las aplicaciones React, React Router y la History API, react-helmet-async para las etiquetas meta y cuándo conviene recurrir a Next.js.
• SEO para Angular — la configuración de SPA predeterminada, @angular/ssr —sucesor de Angular Universal—, los servicios Title y Meta integrados, el prerenderizado y la hidratación incremental de las versiones modernas de Angular.
• SEO para Next.js — Pages Router frente a App Router, la Metadata API, next/image y Core Web Vitals, la sincronización de ISR con Googlebot, los sitemaps y los errores de SEO más habituales en Next.js.
• SEO para Nuxt — SSR de forma predeterminada, useSeoMeta(), los modos de renderizado de Nuxt, el ecosistema de módulos @nuxtjs/seo y su comparación con Vue sin metaframework respecto a la indexabilidad.
• SEO para Vue — el CSR predeterminado de Vue 3 y sus consecuencias para los rastreadores, createWebHistory(), @unhead/vue, las opciones de prerenderizado sin metaframework y cuándo Nuxt es la decisión adecuada.
• SEO para Svelte — Svelte frente a SvelteKit, el SSR predeterminado de SvelteKit, <svelte:head>, la trampa de adapter-static + ssr: false, las opciones de adaptadores y las implicaciones para los rastreadores de IA.
• SEO para Astro — cero JavaScript de forma predeterminada, arquitectura de islas, @astrojs/sitemap, astro:assets, View Transitions y la History API, el comportamiento alternativo de Server Islands y las ventajas de Astro para Core Web Vitals.

Resumen de IA

Una versión condensada de la pestaña Avanzado:

• «¿Puede Google leer JS?» no es la pregunta correcta — Puede hacerlo. Los modos de fallo son la paridad (inicial frente a renderizado), la interacción (Google no se desplaza ni hace clic), el estado (renderizador sin estado) y el tiempo.
• No hay un retraso fijo de renderizado — Google pone en cola una página 200 y puede esperar «unos segundos» o más, sin un tiempo de espera publicado. Un estado distinto de 200 o un noindex inicial puede omitir la cola por completo.
• Los enlaces deben ser anclas <a href> reales — Un onclick en un <div> no es detectable como enlace. Inyectar enlaces con JS es válido si terminan como anclas, aunque se analizan después de ejecutar JS: son detectables, pero eso no garantiza su rastreo o indexación.
• Carga diferida según el viewport, no según una interacción — Google «no interactúa con tu página». Usa Intersection Observer o carga diferida nativa; no ocultes el contenido tras un desplazamiento o un clic.
• El desplazamiento infinito puede fusionar dos páginas — Googlebot puede usar un viewport más alto que un navegador habitual —no hay un tamaño exacto publicado; prueba tu configuración— y activar el cargador de la página siguiente. Solución: URL paginadas, enlaces <a href> reales y History API. Si un cargador ya fusiona páginas, bloquea su archivo JS.
• Soft 404 tras el enrutamiento del cliente — Devuelve un 404 real o usa noindex; no indexes carcasas vacías ni dependas de fragmentos de URL —el sistema de rastreo AJAX está obsoleto desde 2015—.
• No bloquees JS o CSS en robots.txt — Google no renderizará archivos bloqueados.
• noindex puede impedir su propia eliminación — Google puede omitir el renderizado al encontrar un noindex inicial, por lo que quizá nunca ejecute el JS destinado a eliminarlo.
• Paridad del DOM y orden de fases — Compara el HTML inicial y el renderizado, pero recuerda que un noindex inicial puede detener el renderizado. Aplica reglas de combinación solo a directivas procesadas y prueba por separado la paridad de canonical.
• El modo de renderizado cambia la dependencia, no garantiza el resultado — SSR, el renderizado estático o prerenderizado y la hidratación llevan antes el contenido al DOM; el CSR íntegro depende más del renderizador. Google considera el renderizado dinámico una solución provisional, no una opción equivalente. La página sobre renderizado contiene el desglose completo.
• Haz las pruebas con la inspección de URLs —HTML renderizado, captura y consola—, la prueba de resultados enriquecidos y un rastreador que renderice JavaScript.

Documentación oficial

Documentación de fuente primaria de los motores de búsqueda.

Google

• Conceptos básicos de SEO para JavaScript — las tres fases, los enlaces rastreables y las pruebas del HTML renderizado.
• Solucionar problemas de JavaScript relacionados con la Búsqueda — tratamiento de soft 404, History API y restricciones del renderizador.
• Corregir el contenido cargado de forma diferida — carga según el viewport, no una interacción, y desplazamiento infinito compatible con la búsqueda.
• Paginación de comercio electrónico y carga incremental de páginas — URL únicas, enlaces <a href> y por qué Google ignora los identificadores de fragmento.
• Guía detallada sobre cómo funciona la Búsqueda de Google — dónde encaja el renderizado en el proceso rastreo → indexación → publicación.

Bing / Microsoft

• Serie de Bingbot: JavaScript, renderizado dinámico y cloaking — la perspectiva de Bing sobre el renderizado de JS y el renderizado dinámico.

Citas de la fuente

Declaraciones oficiales de Google, además de algunas procedentes de mis propios textos. Cada enlace del motor de búsqueda lleva directamente al pasaje citado en la página de origen.

Google: renderizado y enlaces

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traducción) «Google procesa las aplicaciones web JavaScript en tres fases principales: 1. Rastreo, 2. Renderizado y 3. Indexación». Ir a la cita
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” (traducción) «Google solo puede descubrir tus enlaces si son elementos HTML «a» con un atributo href». Ir a la cita
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (traducción) «El renderizado es importante porque los sitios web suelen depender de JavaScript para incorporar contenido a la página y, sin él, es posible que Google no vea ese contenido». Ir a la cita
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (traducción) «La página puede permanecer en esta cola unos segundos, aunque también puede tardar más» — sobre el tiempo de la cola de renderizado; no se ha publicado un retraso fijo. Ir a la cita
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (traducción) «Cuando Google encuentra la etiqueta noindex, puede omitir el renderizado y la ejecución de JavaScript; por eso, usar JavaScript para cambiar o eliminar noindex de la etiqueta meta robots podría no funcionar como se espera». Ir a la cita

Google: interacción, carga diferida y desplazamiento infinito

• “Google Search does not interact with your page.” (traducción) «La Búsqueda de Google no interactúa con tu página». Ir a la cita
• “…loads all relevant content whenever it is visible in the viewport.” (traducción) «…carga todo el contenido pertinente cuando es visible en el viewport». Ir a la cita
• “Give each chunk its own persistent, unique URL.” (traducción) «Asigna a cada bloque su propia URL única y permanente» — para un desplazamiento infinito compatible con la búsqueda. Ir a la cita
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” (traducción) «No uses identificadores de fragmento de URL —el texto que aparece tras el signo de almohadilla— para los números de página de una colección. Google ignora los identificadores de fragmento». Ir a la cita

Google: soft-404 y enrutamiento

• “We recommend using the History API to load different views.” (traducción) «Recomendamos usar la History API para cargar vistas distintas». Ir a la cita

Patrick Stox (mi propio trabajo: JavaScript SEO: A Definitive Guide)

• Sobre las etiquetas meta robots: “With meta robots tags, Google is always going to take the most restrictive option it sees — no matter the location… Google will choose the most restrictive statements between HTML and the rendered version of a page.” (traducción) «Con las etiquetas meta robots, Google siempre aplicará la opción más restrictiva que encuentre, esté donde esté… Google elegirá las declaraciones más restrictivas entre el HTML y la versión renderizada de una página».
• “If you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (traducción) «Si tienes una configuración de desplazamiento infinito, sigo recomendando una versión paginada para que Google pueda rastrearla correctamente».
• Sobre la fusión: “occasionally, two pages get indexed as one” (traducción) «en ocasiones, dos páginas se indexan como una sola»; ocurre cuando “Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (traducción) «Google alargó el viewport… activó el desplazamiento infinito y cargó otro artículo mientras renderizaba». La solución: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (traducción) «bloquea el archivo JavaScript que gestiona el desplazamiento infinito para que la función no pueda activarse».

Lista de verificación de JavaScript-SEO

Una comprobación rápida para confirmar que Google puede renderizar e indexar el contenido que depende de JavaScript:

• El contenido importante aparece en el HTML renderizado —compruébalo en la inspección de URLs, no solo mediante Ver código fuente—.
• Los enlaces son anclas <a href> reales, no controladores onclick en <div> o <span>.
• Los archivos JavaScript y CSS no están bloqueados en robots.txt.
• Ningún contenido está condicionado a un clic, desplazamiento o paso del cursor —Google no interactúa—; la carga diferida responde al viewport mediante Intersection Observer o loading="lazy".
• El contenido situado en la parte visible al cargar la página no usa carga diferida.
• Las directivas de robots coinciden entre el HTML inicial y el renderizado —sin que JS inyecte noindex—; Google aplica la opción más restrictiva.
• Los cambios de ruta del lado del cliente que llevan a un recurso ausente devuelven un 404 real o noindex, sin carcasas de soft 404.
• El desplazamiento infinito tiene una versión paginada con URL <a href> únicas y actualizaciones mediante History API, y no fusiona páginas con un viewport alto.
• El contenido que deba posicionarse usa SSR, renderizado estático o prerenderizado, no CSR íntegro —consulta la página sobre renderizado—.
• Has comprobado la captura renderizada y los errores de consola en la prueba en directo de la inspección de URLs.

Los modelos mentales

1. «¿Puede Google ejecutar mi JS?» no es la pregunta correcta. Puede hacerlo. Las preguntas reales se refieren a la paridad, la interacción, el estado y el tiempo:

• Paridad — ¿El DOM renderizado contiene lo que crees?
• Interacción — ¿Hay algo que requiera un desplazamiento o un clic que Google no vaya a realizar?
• Estado — ¿Utilizas cookies o almacenamiento local que se elimina al iniciar cada sesión del renderizador?
• Tiempo — ¿El contenido crítico queda pospuesto detrás de JS lento o tardío?

2. Si no está en el DOM renderizado, no existe. Ver código fuente muestra el HTML inicial; la inspección de URLs muestra el DOM renderizado. Las decisiones de indexación se toman a partir del DOM renderizado, así que ese es el artefacto que debes comprobar siempre.

3. Enlaces reales o ningún enlace. El descubrimiento depende de anclas <a href>. Los controladores de clic, los botones y la navegación mediante JS que nunca genera un ancla son callejones sin salida para el rastreo.

4. Diseña para un bot que nunca toca la página. No se desplaza, no hace clic ni pasa el cursor. Si el contenido necesita una acción para aparecer, presupón que Google no lo verá; cárgalo según el viewport.

5. Prueba la trampa del viewport alto en el desplazamiento infinito. Googlebot puede renderizar con un viewport más alto que el de un navegador habitual —no hay un tamaño fijo publicado, así que no diseñes para una cifra concreta—. Por ello, un cargador que se active según el desplazamiento o la altura puede ejecutarse durante el renderizado y fusionar la página siguiente. Diseña URL paginadas con enlaces reales y History API; si ya se están fusionando, bloquea el JS del cargador.

6. Deja que las herramientas decidan. Tu navegador no es Googlebot. El HTML renderizado, la captura de pantalla y la consola de la inspección de URLs son la fuente de referencia, no «en mi equipo se ve bien».

Errores de JavaScript-SEO: hoja de referencia

¿Qué modo de renderizado? (dependencia de la renderización exitosa)

Esto no garantiza un resultado: SSR, SSG y la hidratación todavía deben renderizarse correctamente y superar todas las demás comprobaciones del artículo. Consulta el desglose completo —ISR, edge, streaming, renderizado dinámico y sus ventajas y desventajas— en la página sobre renderizado.

Mira lo que ve el robot de Google

Los errores de renderizado se esconden en la diferencia entre el HTML inicial —lo que envía el servidor— y el HTML renderizado —lo que existe después de ejecutar JS—. Estas comprobaciones rápidas de la línea de comandos pueden hacerse antes de recurrir a un rastreador completo.

Obtén el HTML inicial —lo que se devuelve antes de ejecutar cualquier JS—

MacOS/Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

Si el texto no aparece en raw.html pero sí en el navegador, JavaScript lo está añadiendo y, por tanto, depende del renderizado. Para obtener el HTML renderizado, usa «Ver página rastreada → HTML renderizado» en la inspección de URLs o un rastreador con Chrome sin interfaz gráfica; curl por sí solo no ejecuta JS.

Confirma que no bloqueas JS o CSS en robots.txt

MacOS/Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

Una regla Disallow que coincida con los archivos JavaScript o CSS impide que Google renderice correctamente la página y casi siempre es un error. La inspección de URLs también enumera los recursos bloqueados; la búsqueda de texto solo detecta con rapidez los casos más evidentes.

Herramientas para depurar JavaScript SEO

Compara el HTML inicial con lo que renderiza Google mediante Render Gap:

1. Pega la URL completa de la página que quieras probar; una plantilla con mucho JavaScript mostrará mejor las diferencias.
2. Supera la comprobación contra abusos y pulsa Probar página. La herramienta obtiene primero el HTML inicial y solo lo renderiza en Chrome sin interfaz gráfica cuando ese HTML parece una carcasa vacía.
3. Lee el veredicto codificado por colores y revisa la tabla HTML inicial frente a DOM renderizado para encontrar las filas marcadas como cambiadas.
4. Abre la pestaña Diferencia entre inicial y renderizado para ver, línea por línea, lo que JavaScript añadió o eliminó.

• Inspección de URLs de Google Search Console — La fuente de referencia. Ejecuta una prueba en directo y consulta el HTML renderizado, la captura de pantalla, los recursos de la página —cargados o bloqueados— y los mensajes de la consola de JavaScript.
• Prueba de resultados enriquecidos — Una forma rápida de comprobar el HTML renderizado y los datos estructurados de una URL sin verificar el sitio.
• Chrome DevTools — Compara Ver código fuente —HTML inicial— con el panel Elements —DOM renderizado—; la consola muestra errores de JS que pueden dejar el contenido en blanco.
• Rastreadores que renderizan JavaScript — Ahrefs Site Audit y Screaming Frog SEO Spider, en modo de renderizado de JS, ejecutan JavaScript y permiten comparar a escala el HTML inicial y el renderizado.
• Herramientas para ver el código fuente renderizado — Extensiones que muestran el DOM renderizado junto al HTML inicial para comprobaciones puntuales.
• Análisis de registros del servidor — Confirma que Googlebot obtiene realmente los recursos JS y CSS; consulta el análisis de archivos de registro.

Prompts de diagnóstico

Comparar el HTML inicial y el renderizado

Pega la respuesta inicial y el DOM renderizado de la misma URL. Elimina antes los datos de clientes y los tokens.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

Clasificar una muestra de rutas

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

Validar un cambio SEO de JavaScript

Demostrar que el contenido de la ruta existe antes de JavaScript

Prueba: Obtén rutas representativas con curl e inspecciona el cuerpo de la respuesta. Resultado esperado: Cada respuesta contiene un título único, el encabezado principal, el texto y enlaces rastreables. Interpretación del fallo: El despliegue todavía sirve una carcasa de aplicación compartida. Ventana de seguimiento: Inmediata. Condición de reversión: Una ruta antes visible en la respuesta del servidor pasa a depender del renderizado.

Demostrar que las directivas coinciden en todas las etapas de procesamiento

Prueba: Compara el HTML inicial con el HTML renderizado de la inspección de URLs para las etiquetas robots y canonical. Resultado esperado: Ambos contienen el mismo conjunto previsto de directivas, sin un valor más restrictivo en la carcasa inicial. Interpretación del fallo: JavaScript intenta sustituir demasiado tarde una señal de indexación. Ventana de seguimiento: Inmediata en el renderizado local y, tras un nuevo rastreo, en Search Console. Condición de reversión: Aparece noindex o un canonical incorrecto en cualquiera de las fases.

Demostrar que los enlaces siguen siendo rastreables

Prueba: Desactiva JavaScript e inspecciona la navegación hacia rutas representativas. Resultado esperado: Los destinos permanecen en atributos href de anclas reales. Interpretación del fallo: El descubrimiento depende de controladores del cliente y no de enlaces. Ventana de seguimiento: Inmediata. Condición de reversión: Las rutas importantes desaparecen del grafo de enlaces cuando fallan los scripts.

Recursos que valen la pena

Mis artículos relacionados

• JavaScript SEO: A Definitive Guide — Mi guía completa sobre renderizado, paridad del DOM, la regla de la directiva más restrictiva, desplazamiento infinito y el problema de dos páginas indexadas como una. Este artículo es la versión condensada y enlazada a sus fuentes.
• The Beginner’s Guide to Technical SEO — Dónde encaja el SEO para JavaScript en el contexto más amplio.

Mis charlas

• How Search Works (SlideShare) — Mi recorrido por el rastreo, el renderizado, la indexación y la clasificación. Se aplica mi advertencia habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Así entiendo estos sistemas… no será una explicación totalmente completa ni exacta».

De otras fuentes

• r/TechSEO — La comunidad para depurar problemas de renderizado e indexación.
• web.dev — Rendering on the Web — La explicación de referencia del equipo de Chrome sobre las ventajas y desventajas del renderizado.
• Google Search Central — JavaScript SEO — Documentación oficial y de fuente primaria sobre el proceso de tres fases, los enlaces rastreables y las pruebas del HTML renderizado.
• Onely — JavaScript SEO hub — Artículos técnicos detallados de una agencia especializada sobre renderizado, indexación en dos oleadas y auditorías de SEO para JavaScript.
• Lista de reproducción sobre SEO para JavaScript de Martin Splitt — Serie oficial de Google que explica cada concepto de SEO para JavaScript, producida por su equipo del ecosistema web.
• Search Engine Journal — JavaScript SEO — Noticias del sector y guías prácticas sobre los problemas de renderizado de JS que van apareciendo.

Pódcasts

• Search Off the Record (equipo de Google Search Relations) — Martin Splitt, John Mueller y Gary Illyes explican con frecuencia desde dentro el SEO para JavaScript y el renderizado. Escuchar

Vídeos

• Google Search Central (YouTube) — La serie JavaScript SEO de Martin Splitt es el mejor recorrido oficial en vídeo sobre cómo procesa Google el JavaScript. Canal

Estadísticas que vale la pena citar

• Marco oficial actual: no hay un retraso fijo. La documentación de Google, actualizada el 4 de marzo de 2026, dice que una página 200 rastreada “may stay on this queue for a few seconds, but it can take longer than that” (traducción) «puede permanecer en esta cola unos segundos, aunque también puede tardar más». No hay un retraso ni un tiempo de espera fijo publicado, y las páginas que devuelven un estado distinto de 200 o empiezan con noindex pueden omitir por completo el renderizado. Ir a la cita
• Dato histórico fechado: mediana de unos 5 segundos hasta el renderizado. En declaraciones anteriores en conferencias, personal de Google —Martin Splitt y Tom Greenaway— indicó que las páginas llegaban al renderizador con una mediana de unos 5 segundos y un percentil 90 de minutos, no las «semanas» que sugería el antiguo temor. Lo cito en mi guía de SEO para JavaScript. Debe tratarse como un dato histórico de aquella charla, no como una métrica actual: Google no lo ha vuelto a publicar como cifra continua y la cita anterior sobre la cola representa el marco oficial vigente.
• Las «dos oleadas de indexación» pierden importancia, según Martin Splitt en 2019. En una conversación con John Mueller en agosto de 2019, Splitt dijo que la indexación en dos oleadas “play[s] less and less of a role” (traducción) «tiene cada vez menos importancia» a medida que se abarata el renderizado y convergen el rastreo, el renderizado y la indexación, sin dar una fecha para su posible desaparición. Cobertura Es la caracterización de Splitt en esa conversación concreta, no una especificación vigente y fechada de Google; úsala como contexto orientativo, no como garantía.

Google procesa las aplicaciones JavaScript mediante el rastreo, el renderizado y la indexación. Evidencia de esta afirmación Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Alcance: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Por lo general, rastrea los enlaces cuando son anclas con atributos href. Evidencia de esta afirmación Google can reliably discover links only when they are HTML anchor elements with an href attribute. Alcance: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Make your links crawlable Google considera que el renderizado del lado del servidor o el prerenderizado son una buena opción para los usuarios y los rastreadores. Evidencia de esta afirmación Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Alcance: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confianza: alta · Verificado: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics La Búsqueda de Google tampoco interactúa con una página para activar el contenido.

Registro de cambios