JavaScript SEO y rendering: lo que los buscadores ven en tu app moderna

Una app web moderna hace una apuesta silenciosa. El HTML que sale del servidor es pequeño, casi vacío. La página real se construye en el navegador, con JavaScript que se ejecuta después de la carga. Para un usuario con una buena máquina y una buena red, funciona muy bien. Para los buscadores, a veces no funciona en absoluto.

Esta guía recorre cómo Google renderiza JavaScript hoy, el modelo en dos olas que explica por qué algunas páginas tardan más en indexarse, las cuatro estrategias de rendering habituales y cuándo encaja cada una, los patrones que rompen la indexación en sitios cargados de JavaScript, lo que hacen y no hacen los crawlers de IA, cómo probar lo que Google ve realmente, y un marco de decisión que convierte la elección de rendering en ingeniería en lugar de religión.

Rendering en 2026, en breve

Cuando se pide una página, algo tiene que convertir código y datos en HTML. Ese algo puede vivir en un servidor, ejecutarse durante el build o ejecutarse en el navegador del usuario. La elección moldea el rendimiento, la complejidad y la visibilidad en buscadores.

Hace cinco años el debate era entre dos bandos. Renderizado en servidor contra renderizado en cliente, con opiniones fuertes en ambos lados. La conversación maduró. La respuesta honesta en 2026 es que la pregunta misma está mal planteada. Distintas partes del mismo sitio necesitan estrategias distintas. Una landing de marketing no es un dashboard logueado. Una ficha de producto no es una página de resultados de búsqueda. La elección correcta depende de qué hace la página, quién la lee y con qué frecuencia cambian los datos detrás.

Para SEO en concreto hay tres restricciones. Los buscadores tienen que encontrar el contenido. Los motores de IA tienen que leer el contenido. Ambos lo hacen dentro de un presupuesto de paciencia más corto que el de un visitante humano. Una página que a una persona le parece completa a los tres segundos puede seguir siendo invisible para un crawler que se rindió al segundo.

El modelo de indexación en dos olas

La documentación pública de Google ha explicado durante años la indexación como un proceso en dos olas para páginas con mucho JavaScript.

En la primera ola, Googlebot pide el HTML crudo e indexa lo que encuentra. Si el HTML está casi vacío (un <div id="root"> con un script y poco más), la primera ola indexa muy poco.

En la segunda ola, la página entra a una cola de renderizado. El Web Rendering Service ejecuta el JavaScript, renderiza la página como lo haría un navegador real y produce el HTML final. Recién en ese momento se indexa el HTML resultante. Recién entonces el contenido construido por JavaScript se vuelve visible para la búsqueda.

La distancia entre las dos olas se medía antes en días o semanas. Hacia 2026 Google la comprimió para la mayoría de los dominios a minutos u horas, pero el modelo sigue ahí. Para páginas de baja prioridad en sitios pequeños, la segunda ola todavía puede tardar.

En la práctica, el contenido en JavaScript no es invisible para Google, pero está retrasado y presupuestado. Las páginas con contenido valioso ya en el HTML de la primera ola se indexan más rápido y rankean antes. Las páginas que dependen por completo de la segunda ola están en desventaja, sobre todo para contenido sensible al tiempo como noticias, precios e inventario.

La misma lógica aplica a otros buscadores y a los sistemas de IA basados en crawler, con una diferencia importante que viene después: los crawlers de IA ejecutan JavaScript de forma mucho menos confiable que Googlebot.

Cuatro estrategias de rendering

Los frameworks modernos exponen cuatro estrategias habituales. No son excluyentes. Un sitio real suele usar dos o tres para distintas partes de la misma app.

Client Side Rendering (CSR). El servidor manda una cáscara mínima de HTML. El navegador descarga JavaScript, pide los datos y arma la página. Ejemplos, una React o Vue clásica como SPA sin framework arriba.

Para SEO, CSR es la opción más arriesgada. El contenido depende por completo de la ejecución de JavaScript, lo que en Google requiere la segunda ola y en crawlers de IA y buscadores menores no es confiable. Usá CSR para páginas que no necesitan visibilidad en buscadores, como un dashboard logueado, un panel de configuración o una interfaz de herramienta detrás de autenticación.

Server Side Rendering (SSR). En cada request el servidor ejecuta el código de la app y devuelve HTML completamente renderizado. El navegador también recibe el bundle de JavaScript para que la página se vuelva interactiva tras la hidratación.

Para SEO, SSR es la opción más confiable. La primera ola ya tiene el contenido completo. Buscadores y crawlers de IA ven lo que necesitan sin ejecutar JavaScript. El costo es carga en servidor, cada request es un render, y la infraestructura tiene que escalar con el tráfico. Usá SSR para páginas cuyo contenido cambia por request y donde la frescura importa, como feeds personalizados, precios en tiempo real, páginas de resultados de búsqueda y contenido que depende de parámetros de request.

Static Site Generation (SSG). En tiempo de build cada página se renderiza una vez en HTML y se guarda. El sitio desplegado es una carpeta de archivos HTML estáticos servidos por un CDN. Ejemplos, Astro, Next.js con output: "export", Hugo, Jekyll.

Para SEO, SSG es la opción más rápida y confiable. El HTML existe antes de que cualquier usuario llegue, así que la indexación de la primera ola captura el contenido completo de inmediato. El costo es el crecimiento del tiempo de build; un sitio de 50.000 páginas puede tardar una hora. Usá SSG para páginas cuyo contenido cambia poco entre despliegues, como blogposts, documentación, páginas de marketing y catálogos de productos que se rebuilden por agenda.

Incremental Static Regeneration (ISR). Un híbrido. Las páginas se sirven como HTML estático, pero cada una tiene un intervalo de revalidación. Cuando expira el intervalo, el siguiente request dispara una regeneración en segundo plano y los siguientes ya reciben la versión nueva. Ejemplos, ISR de Next.js, endpoints de servidor en Astro con cabeceras de caché.

Para SEO, ISR alcanza la misma confianza de SSG en la primera ola y permite actualizar contenido sin un rebuild completo. El costo es complejidad operativa, estrategias de invalidación de caché y ventanas de contenido viejo. Usá ISR para sitios con demasiadas páginas para un rebuild completo viable, pero con contenido más fresco que el de un sitio de marketing, como catálogos de e commerce con miles de productos que actualizan precio varias veces al día.

Una tabla resumen:

Patrones que rompen la indexación en silencio

Las estrategias anteriores son limpias en teoría. En producción, ciertos patrones rompen la indexación incluso en sitios que querían hacer lo correcto.

Contenido renderizado tras una interacción del usuario. Una página carga con un teaser y el artículo completo aparece solo después de un clic en “Leer más”. Googlebot no hace clic. Lo que está detrás del clic es invisible para la búsqueda. La solución es renderizar el contenido completo en el HTML inicial y plegarlo visualmente con CSS o JavaScript para los usuarios.

Lazy loading disparado por scroll. Una página larga renderiza el primer viewport y nuevas secciones aparecen mientras el usuario hace scroll. Googlebot no hace scroll como un humano; renderiza la página con un viewport alto (cerca de 12.000 píxeles por defecto) e indexa lo visible. El contenido que requiere scroll real más allá de esa altura está en riesgo. La solución es usar el atributo loading="lazy" en imágenes e iframes (que Google entiende), no la carga por scroll en JavaScript para contenido.

Rutas que dependen solo de APIs del navegador. El contenido de una ruta pide datos a localStorage, sessionStorage, IndexedDB o cookies de sesión. El Web Rendering Service no preserva estado entre renders, así que cualquier contenido que dependa de almacenamiento del navegador aparece vacío. La solución es asegurarse de que el contenido SEO canónico se obtenga del servidor en el render, no del almacenamiento del navegador.

Contenido bloqueado por banners de cookies o muros de pago. Un banner de consentimiento cubre la página hasta que el usuario acepta. Si el contenido sigue en el DOM debajo, sin problema. Si el contenido se quita del DOM hasta el consentimiento, Google solo ve el banner. La solución es dejar el contenido SEO en el DOM antes del consentimiento, aunque esté visualmente oculto, o usar una puerta de consentimiento blanda que no remueva contenido.

Contenido crítico en <noscript>. Algunos equipos, sabiendo que el render de JavaScript puede fallar, replican su contenido en bloques <noscript>. Antes funcionaba. Las advertencias actuales de Google marcan el uso intensivo de <noscript> como señal de baja calidad porque ciertos abusos lo convirtieron en una marca de cloaking. Usá <noscript> para mensajes de respaldo (como “se necesita JavaScript”), no para contenido indexable.

Redirecciones por JavaScript. Una página devuelve 200 OK con <script>window.location = "/new-url"</script>. La primera ola ve una página vacía. La segunda ola detecta la redirección eventualmente, pero entre medio la URL original quedó indexada vacía. La solución son redirecciones HTTP 301 o 302 en el servidor, no navegación por JavaScript.

Meta tags dinámicas inyectadas tras el load. Una app React fija document.title y actualiza meta tags después de montar el componente de ruta. Googlebot ve el <title> original del HTML estático, que suele ser un nombre genérico del sitio. La página se indexa con título y descripción equivocados. La solución es una librería de gestión de head que inyecte tags durante el SSR, como next/head, react-helmet-async o soluciones específicas del framework.

Routing por hash. URLs como /products#electronics en lugar de /products/electronics. Google indexa el path e ignora el fragmento, así que todas las rutas hash colapsan en una única URL indexada. La solución es routing por la History API de HTML5 con paths reales.

Una prueba confiable, abrí el código fuente renderizado en el Mobile Friendly Test y buscá el contenido esperado. Si una frase de tu hero falta en el HTML renderizado, ese es un problema que conviene resolver antes de que el tráfico lo haga por vos. Una auditoría parecida se beneficia de pasar periódicamente la checklist de auditoría SEO técnica para detectar regresiones temprano.

Crawlers de IA y JavaScript

El paisaje de crawlers en 2026 ya no es solo Googlebot. Los sistemas de entrenamiento e inferencia de IA tienen sus propios crawlers, y se comportan distinto.

Las citas de ChatGPT, Claude, Perplexity y Gemini suelen apoyarse en crawlers que piden HTML y ejecutan poco o nada de JavaScript. Cuando un motor de IA cita una página, casi siempre cita lo que encontró en el HTML de la primera ola. Una página que necesita JavaScript para renderizar el cuerpo del artículo es invisible para la mayoría de los crawlers de entrenamiento de IA y solo parcialmente visible para los crawlers de inferencia (los que se usan para citas en vivo).

Bingbot corre un renderizador de JavaScript basado en Edge, similar en capacidad al Googlebot. Bing indexa contenido en JavaScript, con la misma lógica de retraso en dos olas.

Buscadores menores y herramientas SEO varían mucho. Muchos no ejecutan JavaScript en absoluto y solo ven el HTML crudo.

La conclusión es incómoda para sitios solo SPA. Aunque hoy Google indexe JavaScript con confianza, el ecosistema más amplio de motores de IA y buscadores menores no lo hace. Una página que depende de JavaScript para su contenido es una página que rankea en Google pero que ChatGPT no cita, que no aparece en resúmenes AI de Bing y que no se ve en las fuentes de Perplexity.

Para sitios donde el tráfico y las citas de IA importan (que en 2026 son la mayoría con estrategia de contenido), la respuesta práctica es mover las páginas indexables hacia SSR o SSG. El principio es, todo lo que querés que una máquina lea debe estar en el HTML de la primera ola.

Esto se conecta directamente con la optimización para motores generativos, que depende de que los crawlers de IA puedan leer el contenido. Contenido renderizado por JavaScript que Google ve, sigue siendo invisible para la mayoría de los motores de IA, lo que significa que optimizar para IA exige resolver el rendering.

Probar lo que los buscadores ven de verdad

Varias herramientas muestran lo que Google y otros crawlers ven cuando piden una página. Usalas antes de asumir que una página está bien indexada.

Inspección de URL en Google Search Console. La herramienta más importante. Para cualquier URL de una propiedad verificada, pedí “Live Test” y mirá el HTML renderizado, la captura y los errores de consola que Google encontró. Si falta el contenido principal en el HTML renderizado, la página se indexa vacía. Si la captura muestra una página en blanco, falló el renderer.

Mobile Friendly Test (search.google.com/test/mobile-friendly). Herramienta pública, sin verificación. Menos detallada que Search Console, útil para probar páginas en sitios que no son tuyos y para spot checks.

Rich Results Test (search.google.com/test/rich-results). Pensada para datos estructurados, también muestra el HTML renderizado. Sirve como segunda opinión cuando la inspección de URL deja dudas.

curl sin JavaScript. Corré curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yoursite.com/page y revisá la respuesta. Eso muestra lo que verán los crawlers de IA y cualquier fetcher sin JavaScript. Si tu hero falta, los motores de IA no pueden leerlo.

DevTools del navegador con JavaScript desactivado. En Chrome DevTools, Settings, Debugger, “Disable JavaScript”, recargar. Es lo más cercano a ver lo que experimenta un crawler que no renderiza. Si la página queda en blanco, hay un problema para cualquier crawler que no sea Google.

Un crawler SEO real con render de JavaScript. Herramientas como Seodisias crawlean el sitio como Googlebot, ejecutan el JavaScript y reportan qué contenido se extrajo. Es esencial para sitios con cientos o miles de páginas, donde los chequeos manuales no alcanzan.

El patrón es, no confíes en que el contenido en JavaScript “probablemente se indexa”. Verificalo, sobre una muestra de páginas por template, en cada release.

Un marco de decisión

Elegir una estrategia de rendering se vuelve más simple si la encuadrás en tres preguntas.

Pregunta uno, ¿esta página necesita rankear en buscadores?

Si no (un dashboard logueado, un panel admin, una herramienta interna), CSR alcanza y ahorra complejidad. Saltá a foco en experiencia y tamaño de bundle.

Si sí, seguí.

Pregunta dos, ¿con qué frecuencia cambia el contenido?

Si cambia poco (por despliegue o pocas veces al día en un sitio chico), SSG es la respuesta más limpia. Buildear, desplegar y dejar que el CDN trabaje.

Si cambia seguido pero de forma predecible (catálogos que actualizan precio cada hora, noticias que se publican a diario), ISR coincide con la cadencia. Poné la revalidación al menor intervalo en que el contenido viejo siga siendo aceptable.

Si cambia por request (feeds personalizados, precios en tiempo real, resultados de búsqueda), SSR es obligatorio.

Pregunta tres, ¿la página puede tolerar el riesgo de indexación parcial en motores de IA?

Si la página es solo para Google y aceptás perder citas de IA, CSR con render tras carga puede ser aceptable.

Si la página es parte de una estrategia de contenido que incluye visibilidad en motores de IA, la respuesta debe incluir SSR o SSG. Los crawlers de IA no ejecutan JavaScript de forma confiable, y eso es una restricción dura, no una preferencia.

Tabla resumen:

Un sitio moderno suele caer en la última fila. Marketing y blog como SSG. Catálogos de productos como ISR. Búsqueda y páginas personalizadas como SSR. Shell de app logueada como CSR. Cada parte del sitio usa lo que le sirve, y la superficie SEO se queda en el HTML de la primera ola.

Esta forma de decisión se cruza con la optimización del crawl budget, porque un sitio que mezcla estrategias de rendering con criterio quema menos crawl budget en renders lentos de JavaScript. Las páginas que cargan completas en la primera ola le ahorran a Googlebot un viaje de render, lo que significa que más páginas se crawlen con el mismo presupuesto.

Qué construir después

La elección de rendering no es la última decisión técnica de SEO de un sitio, pero es una de las primeras y moldea casi todo lo demás. Los enlaces internos entre páginas SSG son baratos. Los enlaces internos hacia un shell CSR rara vez registran. El schema markup en una página SSR lo lee cualquier crawler. El schema inyectado por JavaScript en una página CSR lo lee Google y pocos otros.

Si un sitio que mantenés sigue apoyado en CSR para páginas indexables, tratá la migración a SSR o SSG como movimiento de fundación. Las ganancias de visibilidad se acumulan, y cada otra mejora técnica de SEO (canonical, enlaces internos, schema, hreflang) aterriza en mejor terreno cuando el contenido está en el HTML de la primera ola.

Para una mirada más profunda a lo que hacen los crawlers cuando llegan a una página, la guía completa del crawler SEO explica cómo crawlean, renderizan e informan los crawlers en sitios cargados de JavaScript. Para un marco de auditoría que incluye verificaciones de rendering, la checklist de auditoría SEO técnica tiene una sección de JavaScript que vale la pena correr cada trimestre. Y para una herramienta que crawlea con motor de navegador real y reporta lo que se extrajo, Seodisias está hecho para hacer visible la brecha entre lo que produce tu código y lo que un crawler de búsqueda o IA ve en realidad.

El sitio que gana la próxima era de la búsqueda no es el de arquitectura más limpia. Es el sitio cuyo contenido aparece en el HTML de la primera ola, cada vez, para cada crawler que importa.