JavaScript SEO: renderizado, hydration e indexacion

En enero de 2025, un e-commerce de moda nos llamo en panico: 18 mil URLs de PDP indexadas como 'soft 404'. El HTML servido tenia tres lineas dentro de , y el contenido real solo aparecia despues de que React montaba en el cliente. Googlebot ejecutaba el JS, si, pero con un retraso medio de 9 dias en la cola de renderizado. Resultado: catalogo invisible durante casi dos semanas en cada deploy. Es el tipo de problema que no aparece en auditorias de copy ni backlinks. Antes de cualquier cosa, conviene revisar Como auditar SEO on-page sin caer en conjeturas para entender donde entra el JS rendering en el diagnostico.

La confusion empieza con la terminologia. CSR (Client-Side Rendering) entrega un HTML casi vacio y delega todo al navegador. SSR (Server-Side Rendering) genera el HTML en la peticion, por usuario. SSG (Static Site Generation) genera todo en el build y sirve archivos listos. ISR (Incremental Static Regeneration), popularizado por Next.js, es hibrido: genera estatico pero revalida bajo demanda. Cada uno tiene trade-offs claros de TTFB, complejidad de cache y costo de servidor. Para SEO, la pregunta correcta no es 'cual es mejor', sino 'en cual de mis templates el contenido critico debe estar en el HTML inicial'.

Hydration es donde mas equipos resbalan. Sirves un HTML perfecto via SSR, Google indexa, pero el JavaScript que 'hidrata' la pagina pesa 800 KB y bloquea la interactividad durante 4 segundos en 4G. El contenido rankea, pero el LCP destruye el ranking despues. Frameworks como Astro, Qwik y los React Server Components atacan exactamente eso, con partial hydration y resumability. Antes de migrar stack, mide: cuanto del JS actual es necesario above-the-fold? La mayoria descubre que el 70% puede ser HTML estatico. Quien hace ese trabajo cosecha ganancia doble en Core Web Vitals: mas alla del LCP, lo que mueve la aguja e indexacion.

El mito de que 'Google ya ejecuta JavaScript' debe morir con matiz. Si, el Web Rendering Service usa Chromium headless actualizado. Pero existen dos colas: la de crawl (HTML crudo) y la de render (con JS). En sitios grandes, la cola de render puede atrasarse dias. Peor: los enlaces descubiertos solo en el DOM post-JS solo entran en la cola de crawl despues del render. Esto significa que una arquitectura SPA pura penaliza el descubrimiento de URLs nuevas. Combina esto con problemas de Crawl budget: cuando preocuparse y como medirlo y tienes catalogos donde el 30% de las paginas nunca llega a indexarse, aun estando en el sitemap.

Como decidir en la practica? Usa una matriz simple por template. Para landing pages institucionales con baja frecuencia de cambio: SSG, sin discusion. Para PLPs de e-commerce con filtros: SSR con cache en el borde (Vercel Edge, Cloudflare Workers) por clave de filtro mas usada, fallback SSR puro. Para PDPs: SSG con ISR de 1 hora resuelve el 90% de los casos. Para area logueada (dashboards, checkout): CSR esta perfecto, porque no necesita indexarse. El error clasico es adoptar la misma estrategia para todo el sitio porque el framework 'lo recomienda'. Ese mapeo conecta directamente con decisiones de On-page para e-commerce: PLP vs PDP sin canibalizar.

Herramientas para validar antes de desplegar: URL Inspection en Search Console muestra exactamente el HTML renderizado que Google vio, con timestamp. El Rich Results Test usa el mismo renderizador. Para auditoria a escala, Screaming Frog en modo 'JavaScript rendering' compara HTML crudo vs renderizado y expone contenido que solo existe post-JS. Los logs de servidor son la verdad de campo: filtra por user-agent Googlebot y observa la proporcion real entre Googlebot Smartphone y Googlebot. Quien nunca miro logs suele asustarse con Log file analysis: que esta haciendo realmente Googlebot en el primer mes.

Tres trampas que aun veo en 2026: lazy-load con IntersectionObserver en contenido principal (Googlebot no scrollea, entonces nada carga), enrutamiento client-side sin History API correcto (URLs con hash # no se indexan), y meta tags inyectadas via JS despues del load (titles y canonicals cambiados en el DOM pueden o no ser respetados, depende del timing). Para el tercer caso, conviene revisitar Canonical tags: errores comunes que sangran trafico organico porque el problema raramente es el canonical en si, sino cuando aparece en el documento.

Takeaway practico: corre hoy una auditoria de 10 URLs estrategicas. Compara 'view-source' con 'Inspect Element' en Chrome. Si el contenido critico, los enlaces de navegacion y las meta tags no estan en el view-source, tienes un problema de renderizado, no de contenido. Documenta el gap por template, prioriza SSR o SSG en los templates que generan ingresos organicos, y deja CSR donde no importa. Stack moderno no es excusa para HTML vacio en una pagina que necesita rankear.