SEO para React: Como Fazer sua Aplicação Ranquear

Fazer SEO para React não começa em meta tag. Uma aplicação React bem escrita pode estar perdendo posição no Google antes mesmo de competir por palavra-chave. O motivo não é conteúdo fraco. É técnico: o crawler lê o HTML que chega primeiro, e uma SPA pura entrega um HTML quase vazio, com o conteúdo real montado depois, via JavaScript.

SEO para React exige tratar esse problema na raiz, não maquiar com meta tags. Este artigo cobre o que muda na prática: onde renderizar, como estruturar metadados por rota e por que Core Web Vitals entra na mesma conta.

O que é SEO para React e por que a abordagem padrão falha

SEO para React é o conjunto de ajustes que garante que o conteúdo de uma aplicação React chegue pronto para o crawler, com metadados corretos e performance dentro do esperado. A abordagem padrão de uma SPA client side rendered falha porque inverte a ordem: primeiro entrega o esqueleto, depois busca dados e renderiza.

O Googlebot consegue executar JavaScript, isso já não é segredo. O problema é o orçamento de renderização: cada página entra numa fila para ser processada em uma segunda passada, que pode levar dias, e nem todo o JavaScript necessariamente roda até o fim nessa passada. Outros buscadores e assistentes de IA, que citam trechos de página para responder perguntas, têm suporte a JavaScript ainda mais limitado. Se o conteúdo só existe depois do fetch no cliente, boa parte desse tráfego nunca vê a página completa.

Por que renderização no cliente esconde conteúdo do crawler

Renderização no cliente, ou CSR, monta a árvore de componentes inteira no navegador do usuário depois que o JavaScript baixa e executa. Isso funciona bem para quem já está com o site aberto. É ruim para quem está tentando descobrir o site.

Suponha uma página de produto que busca nome, preço e descrição via useEffect após o carregamento inicial. No primeiro HTML enviado pelo servidor, existe apenas um <div id="root"></div> vazio. Um crawler que não espera a segunda passada de renderização, ou que trunca a espera, indexa exatamente isso: nada.

A correção não é escrever mais texto ou adicionar mais meta tags. É mudar onde a renderização acontece.

SSR, SSG e ISR: qual escolher para cada rota

Server side rendering, static generation e incremental static regeneration resolvem o mesmo problema de formas diferentes, e a escolha certa depende de quão frequentemente o conteúdo muda.

Static generation, ou SSG, gera o HTML completo em tempo de build. É a opção mais rápida para servir e a mais amigável para SEO, porque o HTML final já existe antes de qualquer requisição. Serve bem para páginas institucionais, artigos de blog e landing pages, conteúdo que não muda a cada visita.

Server side rendering, ou SSR, gera o HTML a cada requisição, no servidor. Faz sentido para páginas com dado que muda com frequência, como um catálogo com preço e estoque em tempo real, onde servir uma versão desatualizada custa mais do que o tempo extra de renderizar por requisição.

Incremental static regeneration fica no meio: gera estático, mas revalida em intervalos definidos ou sob demanda. Um catálogo de produtos que muda algumas vezes por dia, não a cada segundo, geralmente se encaixa melhor aqui do que em SSR puro.

Em um projeto Next.js, essa escolha é feita rota por rota, não para a aplicação inteira. Uma página de blog pode ser estática, o dashboard logado do mesmo projeto pode ser client side, e isso é esperado.

Como implementar SEO técnico em uma aplicação React

1. Migre as rotas públicas voltadas para busca (blog, produto, landing page) para SSR ou SSG. Rotas atrás de login, que nunca precisam ser indexadas, podem continuar client side.
2. Defina title e description únicos por rota, gerados a partir do dado real da página, nunca um valor fixo repetido em todas as páginas.
3. Adicione dados estruturados JSON-LD do tipo apropriado à rota (Article, Product, BreadcrumbList), com os campos que o conteúdo realmente tem.
4. Gere um sitemap.xml dinâmico que liste toda rota pública e um robots.txt que aponte para ele.
5. Rode o Google Search Console e peça a inspeção de uma URL específica para confirmar que o HTML indexado bate com o conteúdo esperado, não com um esqueleto vazio.

Esse ciclo de gerar e depois inspecionar é o que evita descobrir, meses depois, que uma seção inteira do site nunca foi indexada.

Metadados dinâmicos e dados estruturados por rota

Metadado genérico, repetido em toda página, é lido pelo buscador como sinal de conteúdo duplicado, mesmo quando o conteúdo visível é diferente entre as rotas. Cada página pública precisa gerar seu próprio title e description a partir dos dados que ela mostra, não herdar um valor fixo do layout.

Em Next.js com App Router, isso se resolve com a função generateMetadata em cada rota dinâmica, lendo o dado real (nome do produto, título do artigo) para montar o metadado daquela página específica. O mesmo vale para dados estruturados: um artigo de blog ganha BlogPosting com headline, datePublished e author, uma página de produto ganha Product com preço e disponibilidade. Reaproveitar o mesmo bloco JSON-LD genérico em rotas diferentes tem o mesmo efeito do metadado repetido: sinal de duplicidade, não de precisão.

Core Web Vitals fazem parte do mesmo problema

SEO para React não termina quando o HTML sai correto do servidor. Google usa Core Web Vitals, métricas de carregamento, interatividade e estabilidade visual, como fator direto de ranqueamento. Uma página bem renderizada no servidor mas lenta para se tornar interativa ainda perde posição.

Isso é especialmente relevante em React porque hidratação, o processo de anexar os event listeners do JavaScript ao HTML já renderizado, tem custo. Uma árvore de componentes grande demora mais para hidratar, e nesse intervalo a página parece pronta mas não responde a clique. Se esse for o gargalo do seu projeto, vale ler como otimizar o LCP do seu site, que cobre o outro lado da mesma métrica.

O que priorizar primeiro

Antes de ajustar meta tags, confirme onde cada rota pública é renderizada. Se o conteúdo principal só existe depois de um fetch no cliente, nenhum ajuste de palavra-chave resolve o problema de fundo. Corrija a renderização, depois trate metadado e dados estruturados por rota, e só então otimize Core Web Vitals como camada final.

Se sua aplicação React precisa desse diagnóstico técnico completo, fale com a gente.