JavaScript SEO: renderizacao, hydration e indexacao

Em janeiro de 2025, um e-commerce de moda nos procurou em panico: 18 mil URLs de PDP indexadas como 'soft 404'. O HTML servido continha tres linhas dentro de , e o conteudo real so aparecia depois que o React montava no cliente. O Googlebot rodava o JS, sim, mas com um delay medio de 9 dias na fila de renderizacao. Resultado: catalogo invisivel durante quase duas semanas a cada deploy. Esse e o tipo de problema que nao aparece em auditoria de copy ou backlinks. Antes de qualquer coisa, vale revisitar Como auditar SEO on-page sem cair em achismos para entender onde JS rendering entra no diagnostico.

A confusao comeca com a terminologia. CSR (Client-Side Rendering) entrega um HTML quase vazio e delega tudo ao navegador. SSR (Server-Side Rendering) gera o HTML na requisicao, por usuario. SSG (Static Site Generation) gera tudo no build e serve arquivos prontos. ISR (Incremental Static Regeneration), popularizado pelo Next.js, e um hibrido: gera estatico, mas revalida sob demanda. Cada um tem trade-offs claros de TTFB, complexidade de cache e custo de servidor. Para SEO, a pergunta certa nao e 'qual e melhor', e sim 'em qual destes meus templates o conteudo critico precisa estar no HTML inicial'.

Hydration e o ponto onde mais times escorregam. Voce serve um HTML perfeito via SSR, o Google indexa, mas o JavaScript que 'hydratar' a pagina pesa 800 KB e bloqueia a interatividade por 4 segundos no 4G. O conteudo rankeia, mas o LCP destroi o ranking depois. Frameworks como Astro, Qwik e o React Server Components atacam exatamente isso, com partial hydration e resumability. Antes de migrar stack, meca: quanto do JS atual e necessario above-the-fold? A maioria descobre que 70% pode virar HTML estatico. Quem ja faz esse trabalho costuma colher ganho duplo em Core Web Vitals: alem do LCP, o que move o ponteiro e em indexacao.

O mito de que 'o Google ja roda JavaScript' precisa morrer com nuance. Sim, o Web Rendering Service usa Chromium headless atualizado. Mas existem duas filas: a de crawl (HTML cru) e a de render (com JS). Em sites grandes, a fila de render pode atrasar dias. Pior: links descobertos apenas no DOM pos-JS so entram na fila de crawl depois do render. Isso significa que arquitetura SPA pura penaliza a descoberta de URLs novas. Combine com problemas de Crawl budget: quando se preocupar e como medir e voce tem catalogos onde 30% das paginas nunca chegam a ser indexadas, mesmo estando no sitemap.

Como decidir na pratica? Use uma matriz simples por template. Para landing pages institucionais com baixa frequencia de mudanca: SSG, sem discussao. Para PLPs de e-commerce com filtros: SSR com cache de borda (Vercel Edge, Cloudflare Workers) por chave de filtro mais usada, fallback SSR puro. Para PDPs: SSG com ISR de 1 hora resolve 90% dos casos. Para area logada (dashboards, checkout): CSR esta otimo, porque nao precisa indexar mesmo. O erro classico e adotar a mesma estrategia para o site inteiro porque o framework 'recomenda'. Esse mapeamento se conecta diretamente com decisoes de On-page para e-commerce: PLP vs PDP sem canibalizar.

Ferramentas para validar antes de subir: URL Inspection no Search Console mostra exatamente o HTML renderizado que o Google viu, com timestamp. O Rich Results Test usa o mesmo renderizador. Para auditoria em escala, Screaming Frog em modo 'JavaScript rendering' compara HTML cru vs renderizado e expoe conteudo que so existe pos-JS. Logs de servidor sao o ground truth: filtre por user-agent Googlebot e veja a proporcao real entre Googlebot Smartphone e Googlebot. Quem nunca olhou logs costuma se assustar com Log file analysis: o que o Googlebot esta realmente fazendo no primeiro mes.

Tres armadilhas que ainda vejo em 2026: lazy-load com IntersectionObserver em conteudo principal (Googlebot nao scrolla, entao nada carrega), roteamento client-side sem History API correto (URLs com hash # nao indexam), e meta tags injetadas via JS apos o load (titles e canonicals trocados no DOM podem ou nao ser respeitados, depende do timing). Para o terceiro caso, vale revisitar Canonical tags: erros comuns que sangram trafego organico porque o problema raramente e o canonical em si, e sim quando ele aparece no documento.

Takeaway pratico: rode hoje uma auditoria de 10 URLs estrategicas. Compare 'view-source' com 'Inspect Element' no Chrome. Se o conteudo critico, links de navegacao e meta tags nao estao no view-source, voce tem um problema de renderizacao, nao de conteudo. Documente o gap por template, priorize SSR ou SSG nos templates que geram receita organica, e deixe CSR onde nao importa. Stack moderna nao e desculpa para HTML vazio em pagina que precisa rankear.