SEO con JavaScript

**TL;DR—JavaScript SEO se trata de una pregunta:¿Pueden los motores de búsqueda ver tu contenido?**Los sitios modernos crean gran parte de la página en el navegador con JavaScript. si Tu texto y enlaces importantes solo aparecendespuésSe ejecutan los scripts, es necesario confirmar Google todavía puede llegar a ellos. Generalmente Google puede hacerlo; el problema está en los detalles.

Qué es JavaScript SEO

Muchos sitios crean parte (o la totalidad) de la página en su navegador con JavaScript. el El servidor envía algo de HTML y luego se ejecutan scripts para completar el contenido, cargar más elementos o intercambiar vistas sin tener que recargar la página completa.JavaScriptSEOes la práctica de hacer Asegúrese de que los motores de búsqueda aún puedan rastrear, representar e indexar ese contenido.

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

1. Gatear— Google descarga el HTML sin formato de su URL.
2. Prestar— Google ejecuta el JavaScript de la página en un navegador para crear el archivo terminado. página (larepresentaciónpaso).
3. Índice- Google lee esa página terminada y la archiva.

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

Si su contenido sólo aparece después de ejecutar JavaScript, Google debeprestarla pagina exitosamente antes de que pueda verlo. La mayoría de las veces lo hace. Cuando no es así, tu El contenido puede desaparecer silenciosamente de la búsqueda.

Las buenas noticias primero

JavaScript no es malo para el SEO. Google ejecuta una versión actualizada de Chrome y puede Ejecute el mismo JavaScript que hacen sus visitantes. El viejo miedo: “Google no puede leer JavaScript” — simplemente ya no es cierto.

Quépodersalir mal es más específico:

• Tu contenido necesita unhaga clic o desplácesepara cargar y Google no hace clic o desplazarse. 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
• Sus enlaces no son enlaces reales (son botones o controladores de clics), por lo que Google no puede síguelos. 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
• tu accidentalmentebloqueó su JavaScript o CSSarchivos enrobots.txt, entonces Google no puede representar la página correctamente.
• La página se ve bien en su navegador, pero el contenido nunca aparece en Google prestadovista.

La lista de verificación simple

• Compara tuHTML sin formato(haga clic derecho → Ver código fuente) con elHTML renderizado(Herramienta de inspección de URL de Google Search Console). Si falta contenido importante la vista renderizada, ese es tu problema.
• Asegúrate de que los enlaces sean reales<a href>enlaces, no controladores de clic en un<div>.
• No bloquees tus archivos JavaScript o CSS enrobots.txt.
• Si una función necesita hacer clic o desplazarse para cargar contenido, asegúrese de que el contenido esté tambiénaccesible de otra manera.
• Para contenido que absolutamente debe clasificarse, prefierarenderizado del lado del servidoro un estático/prerenderizadobuild, donde el contenido ya está en HTML sin formato. 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

¿Quiere la versión más profunda: los modos de falla reales, la trampa de desplazamiento infinito que se pone? ¿Dos páginas indexadas como una y cómo probar el HTML renderizado? Cambiar a laAvanzadopestaña. Para saber cómo funciona el renderizador de Google y qué configuración de renderizado elegir, consulte elrepresentaciónpágina.

TL;DR—Google puede ejecutar JavaScript, entonces “¿puede Google leer JS?” esta mal pregunta. Los modos de falla sonparidad(DOM sin formato versus renderizado),interacción(Google no se desplaza ni hace clic),estado(el renderizador no tiene estado), y> momento. Mantenga los enlaces tan reales<a href>anclajes, no bloquee JS/CSS, realice carga diferida ventana gráfica, no interacción, devuelve estados reales para 404 del lado del cliente y recuerda un crudonoindexpuede impedir la representación antes de que JavaScript pueda eliminarla. combinar directivas que realmente se procesaron, pero que no asumen un ganador universal sin procesar/renderizado. Observe especialmente el desplazamiento infinito: una ventana gráfica de renderizado alta puede activar el cargador y fusionar dos URL en una página indexada. Para las partes internas del renderizador y qué renderizado modo para elegir, verrepresentación.

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

Google procesa aplicaciones JavaScript en tres fases:“Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.”La fase media ejecuta su JS en un Chrome permanente y sin cabeza para construir el DOM que se indexa.”Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.”

Entonces Googlepoderejecuta tu JavaScript. Las preguntas útiles son más específicas:

• Paridad— ¿El DOM renderizado realmente contiene lo que crees que contiene?
• Interacción— ¿Hay algo que requiera un desplazamiento o un clic que Google no realice?
• Estado- ¿Confías en las cookies/almacenamiento local que borra el renderizador sin estado?
• Momento– ¿El contenido crítico se pospone detrás de JavaScript lento o tardío?

Específicamente en el momento: Google pone en cola una página rastreada (una que devolvió un200) para renderizado, y*“the page may stay on this queue for a few seconds, but it can take longer than that.”*No hay retrasos ni tiempos de espera fijos publicados, y una página que devuelve un estado distinto de 200, o que comienza con unnoindexdirectiva, puede saltarse la renderice la cola en lugar de esperar a que JavaScript la cambie.

la mecanica decómoGoogle renderiza: el servicio de renderizado web, apatridia, almacenamiento en caché, el mito de las “dos olas”: vive en elrepresentaciónpágina. Aquí me centraré en el problemas prácticos y soluciones.

Los enlaces deben ser reales.<a href>anclas

Este es el error de JS-SEO más común.”Google can only discover your links if they are <a> HTML elements with an href attribute.”Un clicable<div>con unonclickEl controlador es invisible para Google como enlace: no será seguido y las páginas que dependen de él para su descubrimiento pueden no ser rastreados. Está perfectamente bieninyectarenlaces con JavaScript, siempre y cuando terminen siendo reales<a href>anclajes en el DOM renderizado. Esas anclas renderizadas se analizandespuésSin embargo, se ejecuta JavaScript: aterrizar en el DOM renderizado hace que un enlace sea reconocible, no es una promesa de que el La URL se rastrea, indexa o trata de la misma manera que un enlace presente en el HTML sin formato.

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.”*Sin desplazarse, sin hacer clic, sin desplazarse. Entonces, cualquier contenido que solo No se verán cargas en uno de esos eventos.

Guía de Google: cargue contenido cuando ingrese a la ventana gráfica, no cuando el usuario actúe.*“make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,“y”don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.”*Utilice IntersectionObserver o nativoloading="lazy"para imágenes, nunca un controlador de desplazamiento o clic, por lo que el El contenido se carga durante un renderizado normal.

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

Éste es el que casi nadie explica y merece la pena toda la sección.

El robot de Google puede renderizar en una ventana gráfica considerablemente más alta que una ventana de navegador típica. Google no publica un tamaño exacto de la ventana gráfica de renderizado (y puede cambiar), así que no lo hagas. diseñar contra un número específico; En su lugar, pruebe su propia implementación. lo que importa es el mecanismo: si su cargador de desplazamiento infinito se activa según la posición de desplazamiento o altura de la ventana gráfica, una ventana gráfica de renderizado más alta de lo esperado puedeactivar el cargador durante el renderizado- y elpróximoEl contenido de la página del artículo o producto se obtiene. agregado en el mismo DOM. Ahora el contenido de dos URL distintas se ha renderizado juntos, y Google puede indexarlos comounopágina. En mi propia experiencia,“occasionally, two pages get indexed as one”— Me han reportado páginas como “no indexadas” que estaban realmente indexado como parte deotropágina (generalmente la publicación anterior en el feed), porque*“when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.”*Confirma si el tuyo La configuración hace esto comprobando el HTML renderizado de URL Inspection para encontrar una página que esperaría ver. Detente en seco: no asumas un tamaño y no asumas que estás a salvo.

Hay dos capas para hacer esto bien.

**En primer lugar, haga que la búsqueda con desplazamiento infinito sea fácil de usar.Soporte de carga paginada debajo del pergamino infinito. Cada trozo debe tener”its own persistent, unique URL,“El contenido de cada URL debe permanecer igual cada vez que se carga. Evite parámetros relativos como?date=yesterday, debería”link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set,“y cuando se carga un nuevo fragmento en el desplazamiento, deberías”update the displayed URL using the History API.”usar reales<a href>enlaces de paginación y URL únicas:“don’t use URL fragment identifiers”(la parte después de un#) para los números de página, porque Google ignora ellos. Como digo en miGuía de SEO de JavaScript, “Si tienes una configuración de desplazamiento infinito, sigo recomendando una versión de página paginada para que Google pueda rastrearla correctamente.”

**Si un cargador con errores está fusionando páginas activamente,**la solución más rápida es contundente:*“block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.”*Si el cargador no puede ejecutarse durante el renderizado, no puede agregar la página siguiente. contenido, y cada URL se representa nuevamente como sí misma.

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

Las aplicaciones de una sola página pueden intercambiar contenido sin cambiar el código de estado HTTP, por lo que una La vista “no encontrada” aún puede regresar200. Google puede clasificar esa respuesta como una soft 404 después de evaluar el contenido devuelto, pero una recuperación estática por sí sola no puede probar que Google ha hecho esa clasificación. Dos correcciones: navegue con la API de historial y, para un estado genuino de no encontrado, entréguelo a un URL que devuelve un valor real404estado o agregar unnoindexetiqueta. Y no te apoyes en la URL fragmentos para enrutamiento -“the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.”

Una redirección del lado del cliente tiene el mismo problema de evidencia: la respuesta inicial puede permanecer200hasta que se ejecute JavaScript. Googleadmite redirecciones de JavaScript solo como alternativacuando las redirecciones del lado del servidor o de meta-actualización no son posibles. Informar el estado estático y la navegación prestada observada por separado; no reescriba el estado HTTP en el audite o llame a cada URL representada, cambie una redirección.

No bloquees JavaScript o CSS en robots.txt

Googleno renderizará JavaScript desde archivos bloqueados o en páginas bloqueadas. Arobots.txtregla que no permite su paquete (o el/_next/, /static/, /assets/directorio en el que se encuentra) puede interrumpir el procesamiento por completo: Google busca el shell, no puede ejecuta los scripts e indexa una página vacía. Verifique la inspección de URLrecursos de la páginapor cualquier cosa bloqueada.

Directivas de paridad DOM y robots conscientes de la etapa

Compara tuHTML sin formato(Ver código fuente) contra elHTML renderizado(Inspección de URL). El contenido que solo existe en el HTML renderizado aún se indexa:sise rinde. Contenido en ninguno de los dos no existe para Google.

Hay un riesgo de orden de etapa que Google documenta directamente:*“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.”*Si su HTML sin formato incluye una inicialnoindexquerías intercambiar con JavaScript, Google puede actuar sobre esa basenoindexy nunca ejecutar el script que lo han eliminado.

No convierta esto en una regla universal de “victorias renderizadas”. La conciliación es específica del campo:

Esa matriz es la razón por la cual un auditor debe mantener la fuente, la entrega, el encabezado de respuesta y estado de búsqueda observado distinto en lugar de colapsarlos en un valor “efectivo”.

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

La mayor parte del riesgo JS-SEO se reduce acómose produce el HTML. La versión corta: SSR, estática/prerenderización e hidratación colocan contenido en (o rápidamente en) el DOM, lo que reduce cuánto depende su visibilidad del éxito del renderizador; lado del cliente completo El renderizado deja más en juego para que el renderizado se complete correctamente, a tiempo y en todo momento. El renderizado dinámico es una solución alternativa, no una opción de pares, según la última guía de Google actualizado en diciembre de 2025, describe el renderizado dinámico como una solución alternativa en lugar de una solución a largo plazo y recomienda renderizado del lado del servidor, renderizado estático o hidratación en su lugar. Como lo puse en miGuía de SEO de JavaScript, *“any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.”*El menú completo: CSR, SSR, SSG, hidratación, ISR, borde, streaming y renderizado dinámico, con una tabla de compensaciones esta en elrepresentaciónpágina. Google por separado describe la renderización del lado del servidor o la renderización previa como una buena idea para los usuarios y 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

como probar

La inspección de URL en Search Console es la fuente de la verdad: ejecute una prueba en vivo y luego mire elHTML renderizado, elcaptura de pantalla, y elrecursos de página/consola mensajespara ver qué se cargó y qué falló. La prueba de resultados enriquecidos ofrece una rápida verificación de HTML renderizado. A escala, utilice un rastreador que ejecute JavaScript (Sitio Ahrefs Audit, Screaming Frog en modo de renderizado JS) para diferenciar el formato sin procesar del renderizado en todo el sitio.

JavaScript no es malo para el SEO y no es malo. es solodiferentede lo que muchos Los SEO están acostumbrados. Trabaje con sus desarrolladores, introduzca su contenido importante en el DOM, y deje que las propias herramientas de Google, no sus suposiciones, sean el árbitro de lo que se genera.

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

Este centro es el mapa. Cada tema a continuación es su propia inmersión profunda:

Renderizado y arquitectura

• SEO para un CMS headless— cómo las interfaces desacopladas afectan el rastreo, el renderizado, los metadatos, los mapas de sitio y las etiquetas canónicas; qué modo de renderizado elegir; y los modos de falla específicos sin cabeza que necesita conocer.

Guías específicas del marco

• Reaccionar SEO- por qué React, que es primero en CSR, crea riesgo de indexación, cómo Google representa las aplicaciones React, React Router y History API, react-helmet-async para metaetiquetas y cuándo recurrir a Next.js.
• SEO angulares- Valores predeterminados de SPA de Angular,@angular/ssr(sucesor de Angular Universal), los servicios de título y meta integrados, renderizado previo e hidratación incremental en Angular moderno.
• Siguiente.js SEO- Pages Router vs App Router, la API de metadatos,next/imagey CWV, sincronización ISR y Googlebot, mapas de sitio y los errores de SEO más comunes de Next.js.
• SEO— SSR por defecto,useSeoMeta(), los modos de renderizado de Nuxt, el@nuxtjs/seoecosistema de módulos y cómo se compara Nuxt con Vue simple en cuanto a indexabilidad.
• Vista SEO- CSR predeterminado de Vue 3 y lo que eso significa para los rastreadores,createWebHistory(), @unhead/vue, opciones de renderizado previo sin un metamarco, y cuando Nuxt es la decisión correcta.
• SEO esbelto— Svelte vs SvelteKit, SSR por defecto en SvelteKit,<svelte:head>, eladapter-static + ssr: falsetrampa, opciones de adaptadores e implicaciones del rastreador de IA.
• AstroSEO— zero-JS por defecto, arquitectura de islas,@astrojs/sitemap, astro:assets, Ver API de historial y transiciones, comportamiento de respaldo de las islas de servidores y ventajas de Core Web Vitals de Astro.

Resumen de IA

Una versión condensada de la versión avanzada:

• “¿Puede Google leer JS?” es la pregunta equivocada- puede. Los modos de falla son paridad(en bruto versus renderizado),interacción(Google no se desplaza ni hace clic), estado(renderizador sin estado), ymomento.
• El tiempo no tiene un retraso fijo.— Google pone en cola un200página para renderizado y mayo espere “unos segundos” o más, sin tiempo de espera publicado; un estado no 200 o un inicialnoindexPuede omitir la cola de procesamiento por completo.
• Los enlaces deben ser reales.<a href>anclas — onclicken un<div>es invisible como un enlace. Inyectar enlaces con JS está bien si terminan como anclajes, pero renderizados los anclajes se analizan después de ejecutar JS: detectables, no una garantía de rastreo/índice.
• Carga diferida en la ventana gráfica, no interacción— Google “no interactúa con su página.” Utilice IntersectionObserver/carga diferida nativa; no bloquee el contenido detrás del desplazamiento o haga clic.
• El desplazamiento infinito puede fusionar dos páginas en una— El robot de Google puede renderizar a una altura más alta. ventana gráfica que un navegador típico (sin tamaño publicado exacto; pruebe su propia configuración), y esa brecha puede activar el cargador y agregar el contenido de la página siguiente. Arreglar: URL paginadas + reales<a href>enlaces + Historial API; si un cargador está fusionando páginas, bloquear su archivo JS.
• Soft-404 después del enrutamiento del lado del cliente- devolver un real404onoindex; no lo hagas indexar conchas vacías; no confíe en fragmentos de URL (rastreo AJAX obsoleto en 2015).
• No bloquear JS/CSS en robots.txt— Google no procesará archivos bloqueados.
• noindexpuede bloquear su propia eliminación— Google puede omitir el renderizado cuando ve un inicialnoindex, por lo que es posible que JS destinado a eliminarlo nunca se ejecute.
• Paridad DOM + orden de etapas (metaetiquetas de robots)— diferencia entre crudo y renderizado, pero recuerda una prima inicialnoindexpuede dejar de renderizar. Aplicar reglas de combinación sólo a directivas efectivamente tramitadas; probar la paridad canónica bajo sus propias reglas.
• El modo de renderizado cambia la dependencia, no el resultado— SSR/estático/prerenderizado/hidratación poner contenido en el DOM antes, reduciendo la dependencia del renderizado; La RSE total depende de ello. la mayoría; La representación dinámica es una solución anticuada de Google, no una opción de pares. completo desglose en la página de renderizado.
• Prueba conInspección de URL (HTML renderizado + captura de pantalla + consola), resultados enriquecidos Prueba y un rastreador de renderizado JS.

Documentación oficial

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

Google

• Comprender los conceptos básicos de SEO de JavaScript– las tres fases, enlaces rastreables y pruebas de HTML renderizado.
• Solucionar problemas de JavaScript relacionados con la búsqueda– manejo de soft-404, API de historial y restricciones de renderizado.
• Arreglar contenido cargado de forma diferida- carga en la ventana gráfica (no en interacción) y desplazamiento infinito compatible con búsquedas.
• Paginación de comercio electrónico y carga incremental de páginas.- URL únicas,<a href>enlaces y por qué Google ignora los identificadores de fragmentos.
• Guía detallada sobre cómo funciona la búsqueda de Google- donde se encuentra la representación en rastreo → índice → servir.

Bing/Microsoft

• Serie bingbot: JavaScript, renderizado dinámico y encubrimiento. ¡Dios mío!— La visión de Bing sobre el renderizado JS y el renderizado dinámico.

Citas de la fuente

Declaraciones oficiales de Google (más algunas de mis propios escritos). cada uno El enlace del motor de búsqueda es un enlace profundo que lleva 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.” Saltar a cotización
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” Saltar a cotización
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” Saltar a cotización
• “The page may stay on this queue for a few seconds, but it can take longer than that.”– en el tiempo de la cola de renderizado, no se publica ningún retraso fijo. Saltar a cotización
• “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.” Saltar a cotización

Google: interacción, carga diferida y desplazamiento infinito

• “Google Search does not interact with your page.” Saltar a cotización
• “…loads all relevant content whenever it is visible in the viewport.” Saltar a cotización
• “Give each chunk its own persistent, unique URL.”— desplazamiento infinito fácil de buscar. Saltar a cotización
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” Saltar a cotización

Google: soft-404 y enrutamiento

• “We recommend using the History API to load different views.” Saltar a cotización

Patricio Stox (mi propio trabajo -SEO en JavaScript: una guía definitiva)

• En etiquetas meta robots específicamente:“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.”
• “Si tienes una configuración de desplazamiento infinito, sigo recomendando una versión de página paginada para que Google pueda rastrearla correctamente.”
• Sobre la fusión:“occasionally, two pages get indexed as one”- causado cuando*“Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.”La solución:“block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.”*

Lista de verificación de JavaScript-SEO

Un pase rápido para confirmar que Google puede procesar e indexar su contenido dependiente de JS:

• El contenido importante aparece en elHTML renderizado(verifique la inspección de URL, no solo ver código fuente).
• Los enlaces son reales.<a href>anclas - noonclickmanejadores en<div>/<span>.
• [] Los archivos JavaScript y CSS sonnobloqueado enrobots.txt.
• [] Ningún contenido está cerrado detrás de unhaga clic, desplácese o coloque el cursor sobre(Google no interactuar); carga diferida en la ventana gráfica a través de IntersectionObserver oloading="lazy".
• [] El contenido de la mitad superior de la página esnocargado de forma diferida.
• [] Las directivas de robots coinciden entre HTML sin formato y renderizado (sin inyección de JS). noindex) — Google toma lamás restrictivo.
• [] Los cambios de ruta del lado del cliente que afectan a un recurso faltante devuelven un valor real404o noindex(sin proyectiles blandos-404).
• [] El desplazamiento infinito tiene unversión paginadacon unico<a href>URL y El historial de API se actualiza y no fusiona páginas en una ventana gráfica alta.
• Contenido que debe clasificar los usosSSR/estático/prerenderizado, no RSE completa (ver la página de renderizado).
• [] Has verificado el renderizadocaptura de pantallayerrores de consolaen URL Prueba en vivo de la inspección.

Los modelos mentales

1. “¿Puede Google ejecutar mi JS?” es la pregunta equivocada.Puede. Las verdaderas preguntas son sobreparidad, interacción, estado y sincronización:

• Paridad— ¿El DOM renderizado contiene lo que crees que contiene?
• Interacción— ¿Hay algo que requiera un desplazamiento o un clic que Google no realice?
• Estado- ¿Confías en las cookies/almacenamiento local que borra el renderizador sin estado?
• Momento— ¿El contenido crítico se pospone 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 sin formato; La inspección de URL muestra el DOM renderizado. Decisiones de índice se crean en el DOM renderizado, por lo que ese es el artefacto que se debe verificar cada vez.

**3. Enlaces reales o sin enlaces.**El descubrimiento continúa<a href>anclas. Controladores de clic, botones y navegación JS que nunca produce un ancla son callejones sin salida para gatear.

**4. Diseño para un bot que nunca toque la página.**Sin desplazamiento, sin clic, sin desplazamiento. Si el contenido necesita una acción para aparecer, asuma que Google no lo verá; cárguelo en la ventana gráfica.

**5. Pruebe la trampa de ventana gráfica alta en desplazamiento infinito.**El robot de Google puede renderizar en una ventana gráfica más alta que la de un navegador típico (no se requiere un tamaño fijo). publicado, así que no diseñes con un número específico), por lo que un desplazamiento/altura activada El cargador puede activarse durante el renderizado y fusionar la página siguiente. Diseño para ello: paginado. URL + enlaces reales + API de historial; si se está fusionando activamente, bloquee el JS del cargador.

**6. Deje que las herramientas arbitren.**Tu navegador no es el robot de Google. HTML renderizado, captura de pantalla y consola de URL Inspection son la fuente de la verdad, no “se ve bien en mi máquina”.

Errores de JavaScript-SEO: hoja de referencia

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

Esto no es una garantía de resultado: SSR/SSG/hidratación aún deben procesarse correctamente y pase todas las demás comprobaciones de este artículo. Desglose completo (ISR, edge, streaming, renderizado dinámico y las compensaciones) en elrepresentaciónpágina.

Mira lo que ve el robot de Google

Los errores de renderizado se esconden en el espacio entre losHTML sin formato(lo que envía el servidor) y elHTML renderizado(lo que existe después de que se ejecuta JS). Algunas comprobaciones rápidas de la línea de comandos antes buscas un rastreador completo.

Obtenga el HTML sin formato (lo que aparece antes de que se ejecute 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 falta el textoraw.htmlpero visible en su navegador, se está agregando por JavaScript, por lo que depende de la representación. (Para elprestadoHTML, use URL “Ver página rastreada → HTML renderizado” de Inspection o un rastreador de Chrome sin cabeza: un llanuracurlno puedo ejecutar JS.)

Confirma que no estás bloqueando JS/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)"

ADisallowque coincida con su JavaScript o CSS significa que Google no puede representar la página correctamente, casi siempre es un error. (La inspección de URL también enumera los recursos de páginas bloqueadas; el grep simplemente detecta rápidamente los obvios).

Herramientas para depurar JavaScript SEO

Vea la diferencia entre HTML sin formato y lo que Google renderizaBrecha de renderizado:

1. Pegue la URL completa de la página que desea probar; una página de plantilla con mucho JavaScript es la que muestra más.
2. Borre la verificación anti-abuso y presionePágina de prueba; primero recupera el HTML sin formato y solo lo representa en Chrome sin cabeza cuando ese HTML parece un shell vacío.
3. Lea el veredicto codificado por colores y luego escanee elHTML inicial vs DOM renderizadotabla para filas marcadascambió.
4. Cambiar a laDiferencia cruda vs renderizadapestaña para ver línea por línea lo que JavaScript agregó o eliminó.

• Inspección de URL (Google Search Console)- la fuente de la verdad. ejecutar unvivir prueba, luego vea elHTML renderizado, elcaptura de pantalla, elrecursos de la página(lo que se cargó frente a lo que se bloqueó), yMensajes de la consola JavaScript.
• Prueba de resultados enriquecidos— una forma rápida de verificar HTML renderizado y datos estructurados para una URL sin verificar el sitio.
• Herramientas de desarrollo de Chrome- compararVer código fuente(HTML sin formato) con elElementospanel (DOM renderizado); La consola muestra errores JS que pueden borrar el contenido.
• Rastreadores de renderizado de JavaScript — Auditoría del sitio de AhrefsySEO de la rana gritadora araña(modo de renderizado JS) ejecute JS para que pueda diferenciar el formato sin procesar del renderizado a escala.
• Ver herramientas de fuente renderizada— extensiones del navegador que muestran el DOM renderizado lado a lado con HTML sin formato para verificaciones rápidas al azar.
• Análisis de registros del servidor— confirma que Googlebot realmente está recuperando tu JS/CSS recursos (veraná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úa como revisor de SEO técnico. Compara RAW_HTML y RENDERED_HTML. Informa solo de
diferencias relevantes en title, meta robots, canonical, encabezados, texto, datos
estructurados y enlaces <a href>. Para cada diferencia, indica el posible impacto,
muestra los fragmentos exactos y da un paso de verificación. No inventes contenido.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

Clasificar una muestra de rutas

Revisa este CSV con URL, HTTP_STATUS, RAW_TITLE, RENDERED_TITLE, RAW_CANONICAL,
RENDERED_CANONICAL, RAW_WORDS y RENDERED_WORDS. Agrupa fallos en carcasa compartida,
directivas restrictivas, soft 404 y posibles timeouts. Ordena por URL afectadas y
devuelve las filas que sustentan cada conclusión junto con una prueba de confirmación.

[paste CSV]

Validar un cambio SEO de JavaScript

Demostrar que el contenido de la ruta existe antes de JavaScript

**Prueba para ejecutar:**Obtener rutas representativas concurle inspeccionar la respuesta cuerpo.**Resultado esperado:**Cada respuesta contiene su título único, encabezado principal, copiar y enlaces rastreables.**Interpretación de fallas:**El despliegue todavía sirve para shell de aplicación compartida.**Ventana de seguimiento:**Inmediato.**Activador de reversión:**un antes La ruta visible del servidor pasa a depender de la representación.

Demostrar que las directivas coinciden en todas las etapas de procesamiento

**Prueba para ejecutar:**Compare el HTML sin formato con el HTML renderizado de URL Inspection pararobotsy etiquetas canónicas.**Resultado esperado:**En ambos aparece un conjunto de directivas previsto, con no hay ningún valor más restrictivo en el shell sin formato.**Interpretación de fallas:**JavaScript es Intentando sobrescribir una señal de indexación demasiado tarde.**Ventana de seguimiento:**Inmediato en representación local; después de volver a rastrear en Search Console.Activador de reversión: noindexo en cualquier etapa aparece un canónico incorrecto.

Demostrar que los enlaces siguen siendo rastreables

**Prueba para ejecutar:**Deshabilite JavaScript e inspeccione la navegación a rutas representativas.**Resultado esperado:**Los destinos siguen estando realmente ancladoshrefatributos.**fracaso interpretación:**Controladores de clientes, no enlaces, descubrimiento propio.**Ventana de seguimiento:**Inmediato.**Activador de reversión:**Las rutas importantes desaparecen del gráfico de enlaces cuando los guiones fallan.

Recursos que valen la pena

mis escritos relacionados

• SEO en JavaScript: una guía definitiva- mi guía completa sobre renderizado, paridad DOM, la regla directiva más restrictiva, desplazamiento infinito y el problema de dos páginas como una. Este artículo es la versión condensada vinculada a la fuente.
• La guía para principiantes de SEO técnico– donde JavaScript SEO encaja en el panorama más amplio.

mi hablar

• Cómo funciona la búsqueda(SlideShare): mi tutorial sobre rastreo, renderizado, indexación y clasificación. (Se aplica mi descargo de responsabilidad permanente: “Esta es mi comprensión de los sistemas… no será 100% completa ni precisa”).

De otros

• r/TecnologíaSEO— la comunidad para depurar problemas de renderizado/índice.
• web.dev — Representación en la Web- el explicador canónico de las compensaciones de renderizado del equipo de Chrome.
• Centro de búsqueda de Google: SEO con JavaScript– documentos oficiales de fuente primaria sobre el proceso de tres fases, enlaces rastreables y pruebas de HTML renderizado.
• Onely: centro de SEO de JavaScript– publicaciones técnicas profundas sobre renderizado, indexación de dos ondas y auditoría JS SEO de una agencia especializada.
• Lista de reproducción SEO de JavaScript de Martin Splitt— la serie de vídeos oficiales de Google que explica cada concepto de JS SEO, producida por el equipo del ecosistema web de Google.
• Search Engine Journal: cobertura de SEO de JavaScript— noticias de la industria y guías para profesionales sobre problemas de renderizado JS a medida que surgen.

Pódcasts

• Buscar fuera del registro(Relaciones de búsqueda de Google) - Martin Splitt, John Mueller, y Gary Illyes cubren periódicamente el SEO y el renderizado de JavaScript desde dentro. Escuchar

Vídeos

• Centro de búsqueda de Google(YouTube) - Martin SplittJavaScriptSEOla serie es el mejor video tutorial oficial sobre cómo Google maneja su JS. Canal

Estadísticas que vale la pena citar

• **Encuadre oficial actual: sin retraso fijo.Documentación propia de Google (actualizada 2026-03-04) dice un rastreo200página”may stay on this queue for a few seconds, but it can take longer than that”— no hay ningún retraso o tiempo de espera fijo publicado, y páginas que devuelven un estado distinto de 200 o comienzan connoindexpuede saltar renderizado por completo. Saltar a cotización
• **Punto de datos históricos (con fecha): retraso medio de renderizado de ~5 segundos.**En antes comentarios de la conferencia, el personal de Google (Martin Splitt y Tom Greenaway) describió las páginas alcanzando el renderizador en una media de ~5 segundos, con el percentil 90 en minutos, no las “semanas” que implicaba el viejo miedo. Cito esto en mi Guía de SEO de JavaScript. Trátelo como un punto de datos histórico de esa charla, no una métrica publicada actual - Google no lo ha vuelto a publicar como una cifra continua, y la cita anterior sobre el tiempo de cola es la encuadre oficial actual.
• **Las “dos oleadas de indexación” se están desvaneciendo, según Martin Splitt (comentarios de 2019).*en un Conversación de agosto de 2019 con John Mueller, Splitt dijo indexación de dos ondas”play[s] less and less of a role”*a medida que el renderizado se vuelve más barato y el rastreo, el renderizado y La indexación converge, sin establecer un cronograma sobre cuándo podría detenerse por completo. Coberturaesto es La caracterización de Splitt de esa conversación específica, no fechada ni citable. Especificaciones de Google: utilícelas como contexto direccional, no como garantía actual de ninguna manera.

Google procesa aplicaciones JavaScript mediante rastreo, renderizado e 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 Generalmente rastrea enlaces cuando son anclas conhrefatributos. 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 describe el renderizado previo o del lado del servidor como una buena idea para los usuarios y 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 Búsqueda de Google también no interactúa con una página para activar el contenido. 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

Registro de cambios