← Voltar ao blog

Renderização no Next.js: SSR, SSG, ISR e o que escolher para SEO

por Respawn LabPublicado em 15 de mai. de 2026Atualizado em 21 de mai. de 202610 min de leitura

A pergunta que decide se o Google enxerga o seu conteúdo não é "qual framework usar" — é "como renderizar". Em aplicações React, a estratégia de renderização determina o que chega no HTML inicial, quão rápido a página carrega e se o crawler vê o texto ou uma casca vazia. Escolher errado é a causa silenciosa de muitos sites bonitos que simplesmente não ranqueiam.

O Next.js oferece quatro modelos de renderização, e a maior parte da confusão vem de tratá-los como se fossem a mesma coisa. Vamos separar cada um, mostrar o impacto em SEO e dar um guia prático de quando usar qual — com foco no App Router, o padrão atual.

Os quatro modelos de renderização

CSR — Client-Side Rendering

No CSR, o servidor manda um HTML quase vazio e o JavaScript monta a página inteira no navegador. É o modelo de um app React "puro" (Create React App, Vite SPA).

Para SEO, é o pior cenário. O HTML inicial não tem conteúdo; o Google precisa baixar o bundle, executá-lo e esperar a renderização para ver qualquer coisa. Ele faz isso, mas com fila, atraso e sem garantia. Conteúdo que depende de um fetch no cliente pode nunca ser indexado. Use CSR apenas em telas atrás de login, dashboards e áreas que não precisam ranquear.

SSR — Server-Side Rendering

No SSR, o servidor renderiza o HTML completo a cada requisição e o envia pronto. O usuário (e o crawler) recebem o conteúdo no primeiro byte; o JavaScript depois "hidrata" a página para torná-la interativa.

Para SEO, é excelente: o conteúdo está no HTML inicial, sempre atualizado. O custo é desempenho e infraestrutura — renderizar a cada requisição consome CPU no servidor e adiciona latência (TTFB) se a renderização for pesada ou os dados, lentos. Use SSR quando o conteúdo é dinâmico e precisa estar sempre fresco: resultados de busca, páginas personalizadas por usuário, dados que mudam a cada minuto.

SSG — Static Site Generation

No SSG, as páginas são renderizadas uma vez, no build, e servidas como HTML estático. É o modelo mais rápido possível: o servidor (ou a CDN) só entrega um arquivo pronto, com TTFB mínimo.

Para SEO, é ideal quando o conteúdo não muda a cada requisição: páginas institucionais, landing pages, artigos de blog, documentação. Conteúdo no HTML, velocidade máxima, custo de servidor quase zero. A limitação é a frescura — para atualizar, é preciso buildar de novo. É exatamente o modelo deste blog: cada artigo é gerado no build e servido estático.

ISR — Incremental Static Regeneration

O ISR é o meio-termo entre SSG e SSR: as páginas são estáticas, mas o Next as regenera em segundo plano após um intervalo (ou sob demanda). O primeiro visitante depois da expiração recebe a versão antiga; em paralelo, uma nova é gerada e passa a ser servida.

Para SEO, junta o melhor dos dois mundos: velocidade de estático com frescura periódica, sem rebuild manual. Use ISR em catálogos de e-commerce, listagens que mudam algumas vezes por dia, ou qualquer conteúdo onde "atualizado a cada hora" é suficiente.

O modelo do App Router

No App Router do Next.js, a escolha não é mais "exportar uma função especial por página" — é a composição de Server e Client Components, e a estratégia de cache dos dados.

Server Components são o padrão. Eles rodam só no servidor, não enviam JavaScript para o cliente e podem buscar dados diretamente. Todo conteúdo que não precisa de interatividade deveria ser um Server Component — é o que coloca o texto no HTML inicial de graça, sem peso no bundle.

Client Components ('use client') são a exceção. Use-os apenas onde há estado, eventos ou APIs do navegador: um formulário, um menu que abre, um carrossel. Eles adicionam JavaScript e custo de hidratação, então mantenha-os pequenos e nas folhas da árvore.

O cache dos dados define o modelo efetivo. Um Server Component que busca dados cacheáveis e roda no build vira SSG. Se usa uma API de tempo de requisição (cookies, headers) ou dados não cacheados, vira dinâmico (SSR). Com revalidação por tempo, vira ISR. Em outras palavras: você não "liga o SSG" — você escreve o componente e o Next decide o modelo com base em como os dados são consumidos.

Streaming com Suspense. O App Router pode enviar o HTML em pedaços: o conteúdo pronto chega primeiro, e as partes lentas (atrás de <Suspense>) chegam depois. Isso melhora o tempo até o primeiro byte e o LCP sem sacrificar o conteúdo indexável.

Como escolher: um guia prático

A decisão cabe em poucas perguntas:

  1. A página precisa ranquear? Se não (dashboard, área logada), CSR resolve e simplifica.
  2. O conteúdo é igual para todos os usuários? Se sim, é candidato a estático (SSG/ISR).
  3. Com que frequência muda? Nunca/raramente → SSG. Algumas vezes por dia → ISR. A cada requisição → SSR.
  4. Depende de dados do usuário ou do request? (cookies, geolocalização, sessão) → SSR/dinâmico.

Na prática, um produto bem estruturado mistura tudo: landing e blog em SSG, catálogo em ISR, busca e conta do usuário em SSR, e o painel interno em CSR. O erro é aplicar um único modelo a tudo — geralmente CSR, por inércia de SPA, justamente nas páginas que mais precisariam ranquear.

Quando o conteúdo é dinâmico mas precisa ranquear

O caso mais difícil — e mais comum em e-commerce e marketplaces — é o conteúdo que muda com frequência e precisa aparecer no Google: catálogos, listagens, páginas de categoria. Aqui a escolha de renderização se mistura com decisões de arquitetura:

  • Catálogos e categorias → ISR. Páginas de produto e de categoria raramente mudam a cada segundo, mas precisam estar frescas. Gerá-las estaticamente com revalidação (por tempo ou sob demanda, quando o produto muda) entrega velocidade de estático com frescura — o melhor cenário para ranquear listagens grandes.
  • Paginação → cada página indexável e autossuficiente. /categoria?pagina=2 deve ter o próprio canonical (apontando para si mesma, não para a página 1), conteúdo único e links para as páginas vizinhas. Tratar a paginação como duplicata da página 1 é um erro que esconde metade do catálogo do Google.
  • Filtros e facetas → controle a explosão de URLs. Combinações como ?cor=azul&tamanho=m&ordem=preco geram URLs quase infinitas que torram o orçamento de rastreamento e enchem o índice de páginas finas. Decida quais facetas têm valor de busca (essas podem ser indexáveis e estáticas) e quais não têm (essas recebem canonical para a versão limpa ou noindex).
  • Busca interna → normalmente noindex. Páginas de resultado de busca (?q=...) costumam ser conteúdo fino e infinito; o padrão é mantê-las fora do índice e investir em páginas de categoria bem estruturadas no lugar.

A regra que une tudo: renderize de forma estática (ISR) o que tem valor de busca e é estável o suficiente, e mantenha fora do índice o que é infinito ou fino. A renderização resolve a velocidade; a arquitetura de URLs resolve o que merece existir para o Google.

Erros comuns que custam indexação

  • Renderizar conteúdo crítico só no cliente. Texto que aparece depois de um useEffect ou um fetch no navegador não é confiável para o Google. Se a página precisa ranquear, o conteúdo vem do servidor.
  • Gerar metadados no cliente. Título, descrição e dados estruturados precisam estar no HTML inicial. Use a API de metadata do framework, não document.title depois da hidratação.
  • Abusar de 'use client'. Marcar um componente grande inteiro como client arrasta tudo o que ele importa para o bundle e para a hidratação, piorando o INP. Isole a interatividade.
  • Forçar tudo dinâmico sem querer. Ler cookies() ou headers() no lugar errado opta a rota inteira para dinâmico, perdendo o estático. Saiba o que torna uma rota dinâmica.
  • Confiar no "Google renderiza JS". Ele renderiza, mas com atraso e limites. Depender disso é apostar o seu tráfego numa fila que você não controla.

Cache, revalidação e a frescura do conteúdo

No App Router, "estático vs. dinâmico" é, na prática, uma questão de cache de dados. Entender as três alavancas evita a maior fonte de surpresas:

  • fetch com cache (padrão). Por padrão, o Next pode cachear o resultado de um fetch e tornar a rota estática. É o caminho do SSG.
  • Revalidação por tempo (revalidate). Você diz "esse dado vale por N segundos"; depois disso, a próxima visita dispara uma regeneração em segundo plano. É o ISR — estático com frescura periódica.
  • Revalidação sob demanda. Em vez de esperar o tempo, você invalida o cache de uma página (ou de uma tag) quando o conteúdo muda de fato — por exemplo, quando um post é publicado no CMS. É o melhor dos mundos: estático, mas sempre correto.
// Regenera no máximo a cada hora (ISR)
export const revalidate = 3600

export default async function Page() {
  const data = await fetch('https://api.exemplo.com/catalogo').then((r) => r.json())
  return <Catalogo data={data} />
}

A armadilha mais comum é tornar uma rota dinâmica sem querer: basta usar cookies(), headers() ou searchParams no lugar errado para o Next desistir do estático e renderizar a cada requisição. Isso não é um bug — é o comportamento esperado —, mas pega muita gente de surpresa quando o site "ficou lento depois de uma mudança pequena". Saiba exatamente o que opta a sua rota para dinâmico.

Como migrar uma página de CSR para SSR

Se você tem uma página importante renderizando só no cliente, a migração costuma seguir este caminho:

  1. Identifique o que precisa de interatividade e o que é só apresentação. Só o primeiro grupo precisa ser Client Component.
  2. Mova a busca de dados para o servidor. Em vez de um useEffect + fetch no cliente, busque os dados direto no Server Component (que pode ser async).
  3. Renderize o conteúdo no servidor e passe só o necessário para os Client Components nas folhas.
  4. Confirme no código-fonte (Ctrl+U) que o conteúdo agora está no HTML inicial.

O ganho é duplo: o Google passa a ver o conteúdo imediatamente, e o LCP melhora porque o usuário não espera o bundle. Em produtos que fizemos essa transição, é comum ver páginas que não indexavam começarem a ranquear em semanas — não porque o conteúdo mudou, mas porque o crawler finalmente conseguiu lê-lo.

Como verificar o que o Google vê

Não confie na aparência no navegador — confie no HTML.

  • Ctrl+U (ver código-fonte) mostra o HTML inicial, exatamente o que chega antes do JavaScript. Procure o seu texto principal e os links ali.
  • Search Console → Inspeção de URL → HTML renderizado mostra o que o Googlebot vê depois de renderizar.
  • Desligue o JavaScript no DevTools e recarregue. Se a página fica vazia, o crawler tem o mesmo problema.

Se o conteúdo está no código-fonte, você está no caminho certo. Se só aparece com JS ligado, é hora de mover essa página para SSR ou SSG.

Conclusão

Renderização não é detalhe de implementação — é a decisão que determina se o seu conteúdo existe para o Google. CSR para o que não precisa ranquear; SSG para conteúdo estável (e é o mais rápido); ISR para conteúdo que muda algumas vezes por dia; SSR para o que é dinâmico e personalizado. No App Router, isso se traduz em Server Components por padrão, Client Components só nas folhas, e uma estratégia de cache consciente. Escolha por página, não para o site inteiro.

Pronto para o respawn?

Se você não tem certeza de que o Google está vendo o seu conteúdo, é exatamente o tipo de coisa que uma auditoria revela em minutos. Peça uma auditoria gratuita — em até 7 dias você recebe um diagnóstico priorizado por impacto e esforço, sem compromisso.