Renderizado de JavaScript y SEO
Cómo Google realmente indexa JavaScript
DeepAudit AI es una auditoría SEO con navegador real y un escáner de SEO de JavaScript que reproduce el índice de dos pasadas de Google. Mira exactamente qué se indexa en la primera pasada, qué depende del presupuesto de renderizado y qué rutas están en riesgo antes de que Search Console las marque.
Gratis. Sin registro. 60 segundos por URL.
El SEO de JavaScript tiene su propia física
Internet ya no es una colección de archivos HTML estáticos. La mayoría de los sitios de producción creados en la última década funcionan sobre un framework de JavaScript — React, Vue, Angular, Svelte, Solid — y entregan parte o todo su contenido del lado del cliente.
Eso cambia la forma en que los motores de búsqueda indexan el contenido de maneras que las listas de verificación de SEO clásicas no captan. Un sitio puede pasar cada auditoría tradicional y aun así posicionarse mal porque su contenido real nunca llega al índice de Google.
Y Google es ahora el caso más indulgente. Los rastreadores detrás de ChatGPT, Claude y Perplexity descargan tu página pero no ejecutan JavaScript en absoluto, así que el contenido renderizado en el cliente es simplemente invisible para ellos. En nuestro Estudio de Visibilidad ante IA de 368 sitios de pequeñas empresas, 1 de cada 4 ocultaba contenido esencial a los rastreadores de IA que no renderizan. El renderizado de JavaScript ya no es solo un problema de Google.
El mecanismo es el índice de dos pasadas de Google. La primera pasada lee tu respuesta HTML inicial e indexa los metadatos y el contenido que encuentre.
La segunda pasada pone la página en cola para su renderizado completo y vuelve a indexar el DOM posterior a JavaScript. Ambas pasadas son reales, pero ocurren en cronologías distintas y bajo restricciones distintas.
La segunda pasada se ejecuta con un presupuesto de renderizado — una ventana de tiempo asignada dinámicamente que las páginas terminan dentro o no. Las páginas que no cumplen el presupuesto se posicionan solo con lo que contuviera el HTML de la primera pasada, que para la mayoría de las aplicaciones JavaScript es un cascarón vacío.
Diseñar para ambas pasadas es lo que separa el SEO de JavaScript del SEO clásico. SSR y SSG ponen contenido real en el índice de la primera pasada. La disciplina en el tamaño del bundle, los tiempos de hidratación y los límites de importación dinámica determinan si la segunda pasada termina dentro del presupuesto de renderizado.
La auditoría SEO con navegador real de DeepAudit AI mide ambas pasadas para cualquier URL y revela qué páginas están en riesgo antes de que Search Console reporte anomalías semanas más tarde.
Fundamentos del SEO de JavaScript
Seis conceptos que determinan si tu aplicación JS se posiciona
Estas son las ideas técnicas que todo ingeniero y responsable de SEO que trabaje en una aplicación JavaScript necesita interiorizar. El índice de dos pasadas es la base. El presupuesto de renderizado es la restricción. SSR, SSG, CSR y el renderizado híbrido son las decisiones de arquitectura que determinan de qué lado del presupuesto cae cada ruta.
El siguiente panel cubre cómo DeepAudit AI mide estos conceptos en la práctica — instrumentación del presupuesto de renderizado, detección de la estrategia de renderizado y los modos de fallo específicos a los que se asigna cada concepto.
El índice de dos pasadas, en detalle
La primera pasada se dispara en el momento en que Googlebot descarga tu URL. Lee la respuesta HTML en bruto, descubre los enlaces <a href> para expandir el rastreo e indexa los metadatos y el contenido que contenga la respuesta. La segunda pasada pone la página en cola para renderizarla — normalmente de minutos a días después — y ejecuta JavaScript en una instancia real de Chromium. El DOM renderizado se vuelve a indexar, reemplazando el contenido de la primera pasada si la segunda tuvo éxito. Si la segunda pasada falla o supera el presupuesto de renderizado, lo que se posiciona es el contenido de la primera pasada.
El presupuesto de renderizado es un objetivo móvil
Google no publica una cifra fija de presupuesto de renderizado. Es una función de la prioridad de rastreo, la autoridad del dominio, el éxito histórico de renderizado, la complejidad de la página y la carga general sobre el flujo de renderizado. En la práctica, las páginas modestas terminan de forma fiable en menos de dos o tres segundos; las páginas complejas con hidratación pesada, bundles grandes y peticiones de datos en tiempo de ejecución suelen superar el umbral. La auditoría mide tus páginas contra un presupuesto conservador para que sepas qué rutas están en riesgo antes de que Search Console reporte anomalías.
SSR es el movimiento SEO de mayor impacto para aplicaciones JS
El renderizado del lado del servidor produce HTML real en la primera pasada. El calendario de dos pasadas sigue ejecutándose, pero el contenido indexable está en el índice desde el momento en que se rastrea la página. No hay dependencia del presupuesto de renderizado para el contenido fundamental. SSR también tiende a mejorar el LCP (el contenido real se pinta más rápido que el contenido impulsado por JS) y le da a Google una caché estable de la página para futuros re-rastreos. Frameworks: Next.js, Nuxt, SvelteKit, Remix y Astro ofrecen todos SSR de primera clase.
SSG es más rápido y económico cuando el contenido es estable
La generación de sitios estáticos produce HTML en tiempo de compilación y lo sirve desde un CDN. El costo de renderizado por petición es cero. La indexabilidad es idéntica a SSR en la primera pasada. La contrapartida es la frescura: las actualizaciones de contenido requieren una recompilación y un nuevo despliegue. Para páginas de marketing, entradas de blog, documentación y catálogos de productos que cambian a diario o menos, SSG es notablemente mejor que SSR. ISR (regeneración estática incremental) es el híbrido de Next.js que obtiene la mayor parte de la velocidad de SSG con una frescura similar a SSR.
CSR es estructuralmente malo para las páginas de contenido SEO
El renderizado del lado del cliente significa que el servidor devuelve un cascarón vacío y el framework renderiza el contenido en el navegador. La indexación depende por completo de la segunda pasada y del presupuesto de renderizado. Las tasas de rastreo bajan, los retrasos de indexación se miden en semanas y cualquier error de hidratación o exceso del presupuesto de renderizado hace que lo que se posicione sea el contenido del cascarón vacío. CSR es apropiado solo para aplicaciones autenticadas donde el SEO no importa; para páginas de contenido, la migración a SSR o SSG es una de las inversiones de SEO con mayor ROI disponibles.
El renderizado híbrido es el estándar moderno
La mayoría de las aplicaciones JS de producción mezclan estrategias. Páginas de marketing y contenido de blog generados estáticamente. Páginas de producto con cambios frecuentes de inventario renderizadas en el servidor. Paneles autenticados renderizados en el cliente. Next.js, Astro y frameworks similares admiten decisiones de renderizado por ruta. La auditoría identifica qué rutas son SSR, SSG o CSR inspeccionando la respuesta HTML inicial por ruta y recomienda la estrategia correcta por página según la frescura del contenido, el tráfico y la importancia para el SEO.
Cómo funciona la detección
Instrumentación de dos pasadas en un navegador real
DeepAudit AI ejecuta cada auditoría a través de una instancia headless de Chromium — el mismo motor de navegador que usa Googlebot. La primera observación es la respuesta HTML en bruto de tu servidor, capturada antes de que se ejecute cualquier JavaScript. Esa instantánea representa lo que ve el índice de la primera pasada de Google: cada <title>, cada <meta>, cada <a href>, cada <script type="application/ld+json"> ya presente, además de todo el contenido del cuerpo que llegó como HTML.
La segunda observación es el DOM posterior a la hidratación, capturado después de que JavaScript se haya ejecutado y la red se haya estabilizado. Medimos la diferencia entre el first contentful paint y la estabilización del DOM para estimar el riesgo del presupuesto de renderizado.
Las rutas cuya hidratación se completa bien por debajo del presupuesto están a salvo; las rutas cuya hidratación termina tarde quedan marcadas.
También detectamos discrepancias de hidratación comparando estructuralmente el HTML inicial con el DOM posterior a la hidratación — cualquier divergencia importante es una señal de que el renderizado del servidor está siendo reemplazado por el renderizado del cliente, lo que tiene implicaciones de indexación porque Google puede haber almacenado en caché la versión del servidor.
La detección de la estrategia de renderizado compara la respuesta HTML inicial por ruta con el DOM posterior a la hidratación. Las rutas cuyo HTML inicial contiene el contenido real son SSR o SSG. Las rutas cuyo HTML inicial es un cascarón vacío son CSR. Las rutas que incluyen contenido de marcador de posición sustituido durante la hidratación se marcan como transitorias.
El escaneo profundo rastrea hasta cincuenta rutas de tu sitemap y te entrega un informe de estrategia de renderizado por ruta, para que puedas identificar las páginas específicas donde migrar de CSR a SSR o SSG desbloquearía la mayor ganancia de posicionamiento.
Cada auditoría también ejecuta la auditoría completa de Core Web Vitals.
LCP, CLS e INP se miden en condiciones que coinciden con los datos de campo de Google, prestando atención a las causas relacionadas con el renderizado — bundles grandes de JavaScript que inflan el LCP, el costo de hidratación que infla el INP, los desplazamientos de contenido dinámico que inflan el CLS. El validador de datos estructurados se ejecuta tanto sobre el HTML inicial como sobre el DOM posterior a la hidratación, de modo que el JSON-LD que solo existe tras la ejecución de JavaScript se marca como invisible en la primera pasada.
Mira cómo Google realmente indexa tu aplicación JavaScript
DeepAudit AI ejecuta la auditoría SEO completa con navegador real, el escáner de SEO de JavaScript y la auditoría de Core Web Vitals en una sola pasada. Diff de dos pasadas, medición del presupuesto de renderizado, detección de la estrategia de renderizado por ruta y un informe PDF descargable. Sin registro, 60 segundos.
Iniciar auditoría SEO gratuitaPreguntas frecuentes
Preguntas de SEO de JavaScript, respondidas
¿Qué es el índice de dos pasadas de Google?
Google indexa las aplicaciones JavaScript en dos pasadas. La primera pasada lee la respuesta HTML inicial del servidor y descubre enlaces y metadatos. La segunda pasada ejecuta JavaScript con un presupuesto de renderizado y vuelve a indexar lo que contenga el DOM renderizado. Las páginas que superan el presupuesto — JS lento, errores de hidratación, bundles grandes — nunca indexan su contenido de la segunda pasada y se posicionan solo con lo que contuviera el HTML de la primera pasada.
¿Qué es el presupuesto de renderizado y cómo lo mido?
El presupuesto de renderizado es el tiempo que Googlebot asigna a ejecutar JavaScript antes de darse por vencido con una página. No es una cifra fija pública; es una función de la prioridad de recursos, la salud del rastreo y el éxito histórico de renderizado. En la práctica, las páginas cuya hidratación termina en menos de dos o tres segundos se indexan de forma fiable; las que tardan más están en riesgo material. Nuestro escáner de SEO de JavaScript mide la diferencia entre el first contentful paint y la estabilización del DOM para marcar las rutas en riesgo.
¿El renderizado del lado del servidor siempre es mejor que el del lado del cliente para el SEO?
Para las páginas de contenido, sí. SSR o la generación estática produce HTML real en la primera pasada, así que Google indexa el contenido sin depender del presupuesto de renderizado. CSR funciona para aplicaciones autenticadas donde el SEO no importa — paneles, herramientas internas, portales de un solo cliente — pero es una desventaja estructural para cualquier página que deba posicionarse. La auditoría te dice qué rutas necesitan migrar a SSR o SSG con más urgencia.
¿Cuál es la diferencia entre SSR, SSG e ISR?
SSR (renderizado del lado del servidor) genera HTML por petición en el servidor, así que cada carga de página pasa por la ruta de renderizado del framework con datos frescos. SSG (generación de sitios estáticos) genera HTML en tiempo de compilación, así que las peticiones se sirven desde caché o CDN. ISR (regeneración estática incremental) es un híbrido de Next.js: las páginas se generan estáticamente pero se revalidan según un calendario. Las tres producen HTML real en la primera pasada. La elección correcta depende de las necesidades de frescura de datos y los patrones de tráfico.
¿Googlebot ejecuta todo el JavaScript?
Sí, pero en el calendario de la segunda pasada y con restricciones. Googlebot usa un Chromium reciente que admite características modernas de JavaScript. Las peticiones de red, las llamadas fetch y las importaciones dinámicas se ejecutan todas. Los inconvenientes son el tiempo — el presupuesto de renderizado puede cortar la ejecución — y ciertas APIs que no están disponibles o se comportan de forma distinta a una sesión de navegador estándar, incluidas algunas de reproducción automática, APIs condicionadas a un gesto del usuario y ciertas APIs de almacenamiento.
¿Qué es la hidratación y por qué afecta al SEO?
La hidratación es el proceso en el que un framework de JavaScript adjunta manejadores de eventos y estado al HTML renderizado en el servidor, convirtiendo una página estática en una aplicación interactiva. Importa para el SEO porque las discrepancias de hidratación — donde el HTML renderizado en el servidor difiere del renderizado en el cliente — pueden hacer que el framework reemplace la salida del servidor. Google quizás ya haya almacenado en caché la versión del servidor. El resultado: los fragmentos y el contenido indexado muestran valores de respaldo que ya no coinciden con la página en vivo.
¿Cómo sé si mi aplicación JavaScript se está indexando correctamente?
Tres señales. La herramienta de Inspección de URL de Search Console muestra la instantánea indexada — compárala con el DOM renderizado en vivo. El informe de Cobertura de Search Console marca las páginas descubiertas-no-indexadas y renderizadas-sin-contenido. La auditoría SEO con navegador real de DeepAudit AI reproduce ambas pasadas localmente y te da el diff en 60 segundos, incluyendo qué rutas están en riesgo por el presupuesto de renderizado y cuáles son solo CSR.
¿Qué pasa con los Core Web Vitals para las aplicaciones JavaScript?
Los Core Web Vitals están estrechamente ligados a la estrategia de renderizado. SSR y SSG ayudan al LCP porque el contenido real se pinta antes de que se ejecute JavaScript. El costo de hidratación perjudica el INP porque la página no responde mientras React, Vue o Angular se está montando. El CLS sufre cuando las imágenes se renderizan sin dimensiones explícitas y el contenido dinámico desplaza el diseño. Cada auditoría de Core Web Vitals que ejecuta DeepAudit AI captura estas señales en condiciones de campo.
Relacionados
Aplica los fundamentos a tu stack
El índice de dos pasadas es universal. La solución depende del framework que utilices.
El SEO técnico es una parte de nuestros servicios de marketing digital. Mira todos los servicios.
Auditoría SEO de React
Modos de fallo específicos de React: tiempos de react-helmet, metadatos definidos con useEffect, discrepancias de hidratación y las contrapartidas de Next.js / Vite que determinan de qué lado del presupuesto de renderizado cae cada ruta.
- Trampas de react-helmet
- Guía SSR vs SSG vs CSR
- Problemas de rastreo de React Router
Auditoría SEO de SPA
Detección agnóstica del framework en React, Vue, Angular, Svelte y Solid. El mismo motor de diff, la misma instrumentación del presupuesto de renderizado y una guía de solución específica del framework en el informe.
- Identificación del framework
- Detección de enrutamiento por hash
- Verificación de desviaciones del sitemap
Empieza ya
Diagnostica tu renderizado
Introduce cualquier URL. DeepAudit AI ejecuta la auditoría SEO con navegador real, el escáner de SEO de JavaScript y la auditoría de Core Web Vitals. Obtienes el diff de dos pasadas, la estrategia de renderizado por ruta, la evaluación de riesgo del presupuesto de renderizado y rutas de solución específicas del framework que impulsa tu aplicación.