JavaScript SEO: CSR vs SSR vs SSG vs ISR — Qual Escolher em 2026

JavaScript SEO: CSR vs SSR vs SSG vs ISR — Qual Escolher em 2026

Guia técnico definitivo sobre rendering para SEO. Entenda CSR, SSR, SSG e ISR com exemplos em React/Next.js, impacto no Core Web Vitals e indexação.

Categoria: SEO Técnico · Por Equipe Domain Hunter · Publicado em 12/05/2026 · 13 min de leitura

## Por que rendering é o tópico mais negligenciado de SEO técnico Você pode ter o melhor conteúdo, backlinks de autoridade e UX impecável — mas se o **Googlebot não conseguir renderizar** seu HTML, nada disso importa. Em 2026, com SPAs explodindo (React, Vue, Svelte), entender rendering é **obrigatório** para qualquer SEO sério. A boa notícia: o Google renderiza JavaScript desde 2019. A má: ele faz isso em **fila de processamento**, com atraso de horas a semanas, e nem sempre executa scripts complexos. Confiar em CSR puro é apostar contra a casa. ## Os 4 modelos explicados em 30 segundos | Modelo | Quando o HTML é gerado | Bom para SEO? | |---|---|---| | **CSR** (Client-Side Rendering) | No navegador do usuário | Ruim | | **SSR** (Server-Side Rendering) | A cada request, no servidor | Excelente | | **SSG** (Static Site Generation) | No build, antes do deploy | Excelente | | **ISR** (Incremental Static Regeneration) | Híbrido SSG + revalidação | Excelente | ## CSR — quando NÃO usar CSR (React puro com `create-react-app`, Vue SPA) entrega ao crawler um HTML quase vazio: ```html
``` O Googlebot precisa **baixar, parsear e executar** o bundle para ver o conteúdo. Resultado: - Indexação atrasada (dias a semanas) - LCP horrível (impacto direto em Core Web Vitals) - Dynamic rendering descontinuado pelo Google (ver [anúncio oficial](https://developers.google.com/search/blog/2022/02/dynamic-rendering-not-recommended)) **Use CSR só para:** dashboards autenticados, ferramentas internas, áreas que não precisam ranquear. ## SSR — o curinga universal A página é renderizada **no servidor a cada request**. O crawler recebe HTML completo. Ideal para: - Conteúdo dinâmico que muda por usuário ou contexto (preço, estoque, localização) - E-commerce de catálogo gigante - Plataformas com feeds personalizados Frameworks: **Next.js (`getServerSideProps`)**, Remix, Nuxt, SvelteKit. Tradeoff: **TTFB maior**. Cache via CDN (Vercel, Cloudflare) é essencial. ## SSG — performance máxima HTML gerado **no momento do build**. Servido como arquivo estático, direto da CDN. Latência mínima, LCP excelente. Ideal para: - Blogs (como este) - Documentação - Landing pages - Sites institucionais Em Next.js: `getStaticProps` + `getStaticPaths`. Em Astro/11ty/Hugo: padrão. Limitação: rebuild a cada mudança de conteúdo. Se você tem 100.000 páginas, o build leva horas. ## ISR — o melhor dos dois mundos ISR (Incremental Static Regeneration), criado pelo Next.js, gera páginas estáticas **sob demanda** e revalida em background a cada N segundos. ```javascript export async function getStaticProps() { const post = await fetchPost(); return { props: { post }, revalidate: 3600, // regenera a cada hora }; } ``` Use ISR para: blogs grandes, e-commerce, marketplaces, qualquer conteúdo que muda às vezes mas não a cada request. ## Comparativo de Core Web Vitals | Modelo | LCP típico | TTFB | INP | |---|---|---|---| | CSR | 4–8s | Baixo | Médio | | SSR | 1–3s | Médio | Bom | | SSG | <1s | Baixíssimo | Excelente | | ISR | <1s (cache hit) | Baixíssimo | Excelente | Para entender as métricas em profundidade, leia nosso [guia de Core Web Vitals 2026](/blog/core-web-vitals-2026-otimizar-lcp-inp-cls). ## Tutorial: migre de CSR para SSR/SSG em Next.js ### Passo 1 — Audite suas páginas Use o [URL Inspection Tool](https://search.google.com/search-console) do Search Console. Veja "HTML renderizado" — se aparece vazio ou só com loaders, você tem problema. ### Passo 2 — Identifique o tipo de conteúdo - Mudou raramente? → SSG - Muda algumas vezes por dia? → ISR - Muda por request? → SSR - Privado/autenticado? → CSR ### Passo 3 — Migre rota por rota Em Next.js App Router, **server components são SSR por padrão**. Marque com `'use client'` apenas componentes interativos. ```jsx // app/blog/[slug]/page.tsx export const revalidate = 3600; export default async function Post({ params }) { const post = await getPost(params.slug); return
{post.content}
; } ``` ### Passo 4 — Verifique a indexação Após deploy, force re-crawl no Search Console e acompanhe **Páginas > Indexadas** por 7 dias. ## Vídeo recomendado No YouTube, busque por "Vercel Next.js App Router rendering" e assista aos vídeos oficiais da Vercel — é o conteúdo mais atualizado sobre rendering moderno. ## Frameworks recomendados em 2026 - **Next.js 15+** — padrão de fato para React + SEO - **Astro** — campeão de performance para sites de conteúdo - **Remix** — excelente para apps com muito SSR - **SvelteKit** — leveza imbatível - **Nuxt 3** — para o ecossistema Vue Evite: SPAs sem framework de rendering (CRA, Vite + React puro) para qualquer site público. ## Conclusão Em 2026, **a regra é simples**: tudo que precisa ranquear deve ser SSR, SSG ou ISR. CSR só sobrevive em áreas autenticadas. Se você está construindo um SaaS, separe **marketing site (SSG/ISR)** do **app (CSR/SSR)** — é a arquitetura que escala. Próximo passo: leia nosso [checklist de SEO Técnico 2026](/blog/seo-tecnico-checklist-2026) para garantir que tudo está coberto. ## Perguntas frequentes **O Google realmente não consegue indexar sites em CSR puro?** Ele consegue, mas com atraso. O Googlebot processa JavaScript em uma fila separada, que pode levar de horas a semanas, e nem sempre executa scripts complexos corretamente. **Dynamic rendering ainda é uma solução válida para SEO em SPAs?** Não — o Google descontinuou oficialmente essa recomendação em 2022. A solução correta hoje é migrar para SSR, SSG ou ISR, não servir uma versão diferente para bots. **ISR é sempre melhor que SSG?** Não sempre. SSG é mais simples e igualmente rápido para conteúdo que muda raramente. ISR vale a pena quando o volume de páginas é grande demais para rebuild completo a cada mudança. **Um SaaS deve usar o mesmo modelo de rendering para o app e o site de marketing?** Não é recomendado. O ideal é separar: site de marketing em SSG/ISR (para ranquear bem) e a aplicação autenticada em CSR/SSR (onde SEO não importa).

Tags: javascript seo, ssr, ssg, next.js, react, rendering

Ver todos os artigos · DomainHunter Pro