SEO con JavaScript: Cómo Google renderiza JS y dónde falla

Busca “JavaScript SEO” y los resultados se dividen en dos géneros desfasados: el pánico de la era 2018 (“¿Google realmente renderiza JavaScript?”) y el entusiasmo por los frameworks (“Next.js es amigable con SEO, envíalo”). Ambos pierden de vista dónde ocurre realmente el daño ahora. Google renderiza JavaScript — ese debate terminó. La pregunta actual es más estrecha y mucho más costosa: ¿la página que Google indexó es la misma que publicaste? El contenido solo en cliente, las fallas de hidratación y los redirects con JavaScript todos producen sitios que se ven perfectos en el navegador y llegan incompletos al índice — y como la página “funciona”, nadie lo nota hasta que el informe de tráfico lo hace.

Esta guía cubre cómo Google realmente rastrea e indexa JavaScript, las trampas de indexación que persisten en la era de renderización, y por qué un redirect con JavaScript filtra equity que un 301 del servidor no. El método en todo esto es primero el repositorio: en un sitio moderno con framework, todas estas fallas son visibles en un puñado de archivos fuente — next.config, middleware.ts, los límites de componentes cliente — antes de que se ejecute cualquier crawler. Esta es la capa JavaScript de nuestro pilar de SEO agentico, y sigue la misma regla que la auditoría técnica de SEO: ninguna corrección se realiza hasta que Search Console diga que el número se movió.

Cómo Google realmente rastrea e indexa JavaScript

Google procesa una página de JavaScript en fases, y la brecha entre ellas es donde vive JavaScript SEO. Primero, Googlebot obtiene el HTML sin procesar — lo que sea que el servidor devuelva antes de que se ejecute un único script. Los enlaces y contenido encontrados allí entran en procesamiento inmediatamente. Todo lo que solo existe después de que se ejecuta JavaScript espera la segunda fase: la página entra en una cola de renderización, y cuando los recursos lo permiten, el Web Rendering Service de Google la carga en un Chromium headless y siempre actualizado — al día con Chrome estable desde la actualización de Googlebot de 2019 de Google — ejecuta los scripts, e indexa el resultado renderizado.

Dos propiedades de ese pipeline importan más que el pipeline en sí. La cola es generalmente rápida — Martin Splitt de Google ha establecido la espera de renderización mediana en alrededor de cinco segundos, con la cola larga en minutos — así que “Google tarda semanas en renderizar JS” es principalmente folklore muerto. Pero la renderización es de mejor esfuerzo: los scripts que generan error, los recursos bloqueados por reglas robots, las llamadas API que agotan el tiempo o requieren credenciales, y el contenido que solo aparece después de un clic o desplazamiento todos fallan silenciosamente. Googlebot no hace clic en botones, no completa formularios y no se desplaza de la manera que lo hace un usuario — la propia documentación de JavaScript SEO de Google dice que el contenido cargado en la interacción no será indexado. Lo que se renderiza es lo que se indexa. Lo que falla se renderiza como ausencia, y la ausencia no produce ningún mensaje de error.

Las trampas de indexación que persisten en la era de renderización

Debido a que la renderización mayormente funciona, las fallas que permanecen son del tipo silencioso: páginas que pasan cada prueba visual y aún se indexan incompletas. Tres patrones representan la mayoría de ellas, y los tres son diagnosticables desde el código fuente antes de que se ejecute cualquier crawler.

Contenido solo en cliente: la página que llega vacía

El patrón clásico de aplicación de página única — servir un shell, obtener el contenido real con JavaScript del lado cliente después de la carga — pone tu contenido principal en el lado incorrecto de la brecha de renderización. Si la obtención es rápida, pública y libre de errores, Google generalmente la consigue. Cada “si” en esa oración es un modo de falla. En un sitio que auditamos, las páginas de productos se veían completas en cada navegador mientras la copia del cuerpo se cargaba desde una llamada API que falló bajo las condiciones de Googlebot — la versión indexada era una plantilla: navegación, boilerplate, sin producto. El sitio no fue penalizado. Simplemente se indexó como la cosa vacía que sirvió. En el repositorio, este es un diagnóstico de un archivo: el contenido obtenido en un useEffect o detrás de un límite ’use client’ es solo en cliente; el contenido obtenido en un componente del servidor se envía en el HTML y nunca entra en la cola de renderización.

Fallas de hidratación: enviado dos veces, indexado una vez

Los frameworks modernos renderan el HTML del servidor y luego lo hidratan — el JavaScript del cliente toma el markup estático e lo hace interactivo. Cuando el markup del servidor y el render del cliente no coinciden, los frameworks resuelven la discrepancia descartando la versión del servidor y re-renderizando en el cliente — lo que silenciosamente convierte tu página renderizada del servidor en una renderizada del cliente, brecha de renderización y todo. Peor aún son los errores adyacentes a la hidratación que borran subárboles de componentes completos: una excepción no controlada en un componente y todo debajo de él desaparece del DOM renderizado. La página aún devuelve 200. Nada en un informe de rastreo lo señala. La pista está en Search Console: la herramienta de inspección de URL del HTML renderizado es la verdad de referencia para lo que Google realmente construyó — compáralo con tu propio DOM y los subárboles faltantes se anuncian a sí mismos.

Enlaces y metadatos que solo existen después de renderizar

El descubrimiento se ejecuta primero en el HTML sin procesar. La navegación renderizada puramente del lado cliente, los manejadores onClick haciendo deber como enlaces, y la paginación que muta el estado en lugar de apuntar a URLs ocultan tu gráfico de enlaces internos de la primera fase, la más barata del rastreo — y un enlace que Google no puede ver es equity de enlace que nunca fluye. Lo mismo aplica a los metadatos: títulos, canónicos y directivas robots establecidas por JavaScript del lado cliente llegan tarde, y un canónico o noindex que cambia entre HTML crudo e HTML renderizado es una ambigüedad que le entregaste a Google para resolver. La regla de primero-el-repositorio es contundente: elementos <a href> reales para cada ruta de rastreo, y metadatos emitidos del lado del servidor — en términos de Next.js, generateMetadata, nunca document.title.

JavaScript redirects vs 301s: la fuga lenta

Los redirects son donde JavaScript SEO deja de ser sutil. Un 301 del servidor ocurre en la capa HTTP: el crawler solicita la URL antigua, el servidor responde “movido permanentemente, aquí está dónde” en el estado de la respuesta, y Google consolida señales a la nueva URL — sin renderización, sin interpretación, sin cola. Un redirect con JavaScript — window.location en un script — es invisible en esa capa. La URL antigua devuelve 200 con una página adjunta. Para incluso descubrir que existe un redirect, Google tiene que rastrear la página, ponerla en cola, renderizarla, ejecutar el script e inferir el movimiento. La documentación de redirect del propio Google es inequívoca sobre la jerarquía: los redirects permanentes del lado del servidor son el método preferido, y los redirects con JavaScript son el último recurso, para cuando nada más está disponible para ti.

“Último recurso” subestima el costo, porque Google ya no es el único lector que importa. Cada consumidor de tus URLs que no ejecuta JavaScript — raspadores de redes sociales que construyen vistas previas de enlaces, la mayoría de herramientas de SEO que mapean tus redirects, y, de manera decisiva, los crawlers de IA — ve un redirect con JavaScript como una página 200 en vivo que nunca se movió. La URL antigua sigue acumulando referencias. La nueva comienza con menos de lo que debería. Esa es la fuga: no una penalización, solo consolidación de señales que llega tarde para Google y nunca para todos los demás.

El repositorio hace esta auditoría casi vergonzosamente rápida. En una base de código de Next.js, los redirects legítimos viven en exactamente tres lugares — redirects() en next.config, NextResponse.redirect en middleware, y llamadas redirect() en código del servidor — todas las cuales emiten códigos de estado HTTP reales. Todo lo demás es una fuga: grep en los paquetes de cliente por asignaciones window.location y llamadas router.replace que se interponen en movimientos que deberían ser del servidor, y has encontrado en minutos lo que una auditoría de redirect basada en crawl reconstituye en días.

El punto ciego: los crawlers de IA no renderizan

Aquí está el giro de la era de renderización que la mayoría de guías de JavaScript SEO no han atrapado: los lectores más nuevos de tu sitio se comportan como los más antiguos. Un análisis de 2024 del tráfico de crawlers de IA por Vercel y MERJ encontró que los crawlers de IA principales — GPTBot de OpenAI, ClaudeBot de Anthropic, PerplexityBot — obtienen HTML pero no ejecutan JavaScript. Gemini es la excepción solo porque se monta en la infraestructura de renderización de Googlebot. Para todos los demás, tu sitio es exactamente lo que devuelve el servidor: el contenido solo en cliente no existe, los redirects con JavaScript nunca sucedieron, y una página renderizada del cliente es un shell vacío con un 200.

Esto significa que la brecha de renderización que cerraste para Google en 2019 se ha reabierto silenciosamente para los sistemas que deciden qué se cita en respuestas de IA. Si una proporción creciente de tu descubrimiento se ejecuta a través de motores que leen HTML sin procesar — el cambio que nuestro pilar de búsqueda de IA cubre completamente — entonces renderizar del lado del servidor tu contenido principal deja de ser una ventaja de rendimiento y se convierte en la diferencia entre ser citado y ser invisible. La regla práctica colapsa en una oración: cualquier cosa que quieras que cualquier máquina lea debe estar en el HTML que envía el servidor. Ser renderizado es table stakes para Google; ser legible sin renderización es la barra para todo después de Google.

Google pasó cinco años aprendiendo a ejecutar tu JavaScript — y luego llegaron los crawlers de IA leyendo HTML sin procesar como si fuera 2015 de nuevo. La página que gana ambas eras es la que nunca necesitó renderizar.

La lista de verificación de JavaScript SEO de primero el repositorio

La auditoría de JavaScript basada en crawl significa renderizar tu propio sitio página por página e ingeniería inversa de causas desde síntomas. Primero el repositorio lo invierte: el comportamiento de renderización de cada página está determinado por un pequeño conjunto de archivos de código fuente, y un defecto en un layout o config compartido es un defecto en cada página que toca — conocible desde una lectura de archivo. Aquí es donde vive cada pregunta en un repositorio de Next.js, y la métrica de Search Console que juzgará la corrección.

Luego confirma la intención contra la realidad una vez: la inspección de URL en Search Console muestra el HTML renderizado que Google realmente construyó — la herramienta de JavaScript SEO más subutilizada, y gratuita. Si un bloque de contenido está en tu DOM y falta de la copia renderizada de Google, tienes un hallazgo de brecha de renderización con la evidencia adjunta. La versión de cinco capas más amplia de esta pasada — rastreo, indexación, canónicos, schema, Core Web Vitals — es la auditoría técnica de SEO; esta lista de verificación es la capa que JavaScript específicamente pone en riesgo.

Ninguna corrección se realiza hasta que Search Console diga que sí

Las correcciones de JavaScript SEO son inusualmente fáciles de declarar como victoria, porque el síntoma visible desaparece instantáneamente: el contenido está en view-source, el redirect devuelve 301, el elemento de auditoría se vuelve verde. Nada de eso es el resultado. El resultado es que Google rastrea nuevamente, renderiza nuevamente e indexa nuevamente las URLs afectadas — y el único lugar que se vuelve visible es Search Console, semanas después. Así que cada hallazgo de la lista de verificación anterior se envía con su contrato de prueba adjunto antes de que lo haga la corrección: el impacto esperado, la métrica que lo juzgará (impresiones para contenido que entró en el índice, posición e impresiones para redirects consolidados, CTR para metadatos), y el objetivo que cuenta como éxito. Aproximadamente tres semanas después de que la corrección aterriza, la métrica se re-lee y el veredicto se registra: confirmado, regresado o inconclusivo.

Esta disciplina paga el doble en trabajo de JavaScript, porque las correcciones de brecha de renderización están entre las más verificables en todo SEO: el contenido que estaba ausente del índice comienza a ganar impresiones o no. Una migración re-enviada como 301s se consolida en los datos de posición o no. Ejecuta el bucle honestamente y también aprendes cuáles de las correcciones de JavaScript en tu sitio valen el tiempo de ingeniería — y cuáles fueron higiene que nunca movió un número, que también es un resultado.

Si quieres que la mitad del hallazgo se ejecute contra tus propios datos, el informe de SEO gratuito conecta tu Search Console y expone los síntomas que este artículo describe — páginas mostradas mucho menos que sus hermanas, URLs que deberían haberse consolidado y no. Y si prefieres que todo el bucle se ejecute como un sistema — archivos de código fuente leídos, correcciones enviadas como pull requests, veredictos leídos de GSC tres semanas después — reserva una llamada y te mostraremos cómo se ve en tu stack.