O sintoma costuma aparecer semanas depois da publicação: o site está no ar, funciona perfeitamente, e o conteúdo não aparece em busca. Ou aparece com título e descrição errados, iguais em todas as páginas.

Um sintoma parecido acontece ao compartilhar um link em uma rede social: em vez do título e da imagem da página, aparece uma prévia genérica — ou nenhuma.

Nos dois casos, a causa costuma ser a mesma, e ela decorre de uma decisão de arquitetura tomada no início do projeto: onde o HTML é montado. Este guia explica por que isso afeta indexação, o que muda em cada estratégia de renderização e como verificar na prática o que está acontecendo.

O problema em uma frase

Quando o conteúdo de uma página só existe depois que o JavaScript executa, quem lê a página sem executar JavaScript não encontra conteúdo nenhum.

Isso vale para dois públicos diferentes, com consequências diferentes.

Buscadores conseguem executar JavaScript, mas isso acontece em uma etapa separada e posterior ao rastreamento inicial. Na prática, o conteúdo pode demorar mais para ser indexado, ser indexado parcialmente, ou — dependendo de quanto tempo e recurso o processamento exige — não ser processado.

Redes sociais e aplicativos de mensagem, que geram as prévias de compartilhamento, geralmente não executam JavaScript. Eles leem apenas o HTML inicial. Se o título e a imagem são definidos por JavaScript depois do carregamento, a prévia mostra o que estava no HTML original — que costuma ser o mesmo para todas as páginas.

Esse segundo caso é o mais frequente e o mais visível: é por isso que compartilhar qualquer página de uma aplicação de página única mostra sempre o mesmo título.

O que muda em cada arquitetura

As três formas de montar o HTML têm comportamentos bem diferentes aqui. A explicação de cada uma está no artigo sobre onde hospedar uma aplicação React — aqui, o foco é a consequência.

Arquitetura	HTML na primeira resposta	Indexação	Prévia de compartilhamento
Página única	Mínimo, sem conteúdo	Depende de processamento posterior	Genérica ou ausente
Geração estática	Completo	Direta	Correta
Renderização no servidor	Completo	Direta	Correta

A leitura é direta: se o conteúdo precisa ser encontrado em busca ou compartilhado com prévia correta, o HTML precisa vir pronto na primeira resposta.

Isso não significa que uma aplicação de página única esteja errada — significa que ela é inadequada para conteúdo que depende de descoberta. Um painel administrativo, um sistema interno ou uma área logada não precisam ser indexados, e a arquitetura serve perfeitamente.

O teste de cinco segundos

Antes de qualquer diagnóstico elaborado, uma verificação simples resolve a maior parte das dúvidas.

Desabilite o JavaScript no navegador e recarregue a página.

• Se o conteúdo aparece, o HTML veio pronto. Indexação e compartilhamento funcionam.
• Se a tela fica em branco, o conteúdo depende de JavaScript. É a origem do problema.

Uma variação útil: veja o código-fonte da página — a versão original enviada pelo servidor, não o que aparece nas ferramentas de inspeção depois de tudo carregado. Se o texto da página não estiver ali, ele não estava na resposta inicial.

Essa distinção confunde muita gente: as ferramentas de inspeção do navegador mostram o resultado depois do JavaScript executar. Ver o conteúdo ali não significa que ele estava no HTML original.

Metadados por página

O problema mais visível e o mais fácil de corrigir parcialmente.

Cada página precisa do próprio título, da própria descrição e da própria imagem de compartilhamento. Em uma aplicação de página única, esses valores costumam estar no HTML base — iguais para todas as rotas — e são alterados por JavaScript quando a rota muda.

Isso funciona para o visitante e para buscadores que processam JavaScript. Não funciona para as prévias de compartilhamento, que leem o HTML inicial e vão embora.

As saídas:

• Gerar as páginas com o HTML pronto, o que resolve tudo de uma vez.
• Pré-renderizar apenas as rotas públicas, mantendo o restante como aplicação de página única. É um meio-termo comum e eficaz quando só parte do site precisa ser encontrada.
• Usar um serviço que entrega HTML processado para robôs identificados — solução que funciona, mas adiciona uma dependência e um ponto de falha.

A segunda opção merece atenção porque cobre o caso mais comum: um produto com páginas públicas de conteúdo e uma aplicação logada. As públicas precisam ser encontradas; a aplicação, não.

Os outros elementos que precisam existir

Além do conteúdo em si, alguns itens estruturais são frequentemente esquecidos em aplicações React:

1. URLs reais para cada conteúdo. Cada página precisa de um endereço próprio, acessível diretamente — o que exige a regra de reescrita no servidor tratada no artigo de hospedagem.
2. Um endereço canônico por página, evitando que variações da mesma URL sejam tratadas como conteúdo diferente.
3. Um mapa do site, que ajuda o buscador a descobrir as páginas sem depender de navegação por JavaScript.
4. Links reais entre as páginas. Navegação implementada apenas com eventos de clique, sem endereços reais no HTML, não é seguida por robôs.
5. Códigos de resposta corretos. Uma página inexistente deve retornar o código de erro apropriado, e não uma página aparentemente normal com uma mensagem de erro dentro.
6. Redirecionamentos no servidor, e não apenas no código do navegador.

O item 4 é sutil e comum: um menu construído com elementos que não são links, respondendo a cliques por JavaScript, funciona perfeitamente para o visitante e é invisível para quem rastreia a página.

O item 5 também merece nota: uma rota inexistente que devolve a página principal com aparência normal cria conteúdo duplicado — o buscador vê a mesma resposta para infinitos endereços diferentes.

Velocidade também conta

Um ângulo que se soma ao da indexação.

As métricas de experiência de página que os buscadores consideram medem o que o visitante percebe. Aplicações React costumam ter um desafio específico aqui: o pacote de JavaScript precisa ser baixado, interpretado e executado antes de a interface aparecer — e isso pesa especialmente em celulares e conexões modestas.

O que mais afeta:

• Tamanho do pacote, que se reduz dividindo o código por rota e carregando sob demanda.
• Dependências pesadas importadas por inteiro para usar uma função.
• Imagens sem otimização, o problema mais comum e mais fácil de resolver.
• Scripts de terceiros acumulados.
• Deslocamento de conteúdo durante o carregamento, quando elementos aparecem e empurram o restante da página.

O último item é característico de aplicações que carregam dados após a renderização inicial: o espaço reservado precisa existir antes, ou a página se reorganiza na frente do visitante. Os limites atuais dessas métricas estão no artigo sobre por que o WordPress fica lento, e valem igualmente aqui.

Como verificar de verdade

Um roteiro que vai além do teste inicial:

1. Veja o código-fonte de algumas páginas e confirme que o conteúdo e os metadados estão lá.
2. Compartilhe um link em uma rede social ou aplicativo de mensagem e confira a prévia. É o teste mais rápido para metadados.
3. Use as ferramentas de inspeção de URL oferecidas pelos buscadores, que mostram como a página é vista por eles.
4. Verifique quantas páginas estão indexadas e compare com quantas deveriam estar.
5. Teste as rotas diretamente, acessando endereços internos sem passar pela navegação — é assim que um visitante vindo de busca chega.
6. Confira o comportamento de páginas inexistentes, garantindo que retornam o código correto.

O passo 2 é o mais barato e o mais revelador: se a prévia de compartilhamento está genérica, os metadados não estão no HTML inicial — e isso responde metade das perguntas.

Quando isso não é um problema

Vale delimitar, porque nem toda aplicação precisa se preocupar com isso.

Aplicações internas e sistemas de uso corporativo não precisam ser encontrados em busca.

Áreas logadas não devem ser indexadas — e, nesse caso, o comportamento padrão de uma aplicação de página única é até conveniente.

Painéis administrativos, pelo mesmo motivo.

Produtos cuja aquisição não depende de busca orgânica, quando todo o tráfego vem de campanhas pagas ou indicação — embora valha considerar que isso limita um canal.

Nesses casos, a arquitetura de página única é adequada e a discussão de indexação não se aplica. O erro é assumir isso por padrão em um produto que tem páginas públicas de conteúdo.

Conclusão

Aplicações React não têm um problema inerente de SEO. Elas têm uma decisão de arquitetura que determina se o conteúdo existe no HTML da primeira resposta — e é isso que define se ele pode ser encontrado.

Se o conteúdo precisa ser descoberto em busca ou compartilhado com prévia correta, o HTML precisa vir pronto: por geração estática ou por renderização no servidor. Para produtos com parte pública e parte logada, pré-renderizar apenas as rotas públicas costuma ser o meio-termo mais eficiente.

E o diagnóstico mais rápido continua sendo o mais simples: desabilite o JavaScript e recarregue. Se a tela fica em branco, você já sabe o que está acontecendo. Se a sua aplicação precisa de renderização no servidor, o ambiente precisa executar um processo permanente — conheça o Cloud Server para React da TBF Host e avalie a configuração adequada ao projeto.

Perguntas frequentes

Aplicações React têm problema de SEO?

Não inerentemente. O que determina a indexação é onde o HTML é montado. Se o conteúdo só existe depois que o JavaScript executa, quem lê a página sem executar JavaScript não encontra nada. Geração estática e renderização no servidor entregam o HTML pronto e não têm essa limitação.

Por que o compartilhamento do meu site mostra sempre o mesmo título?

Porque redes sociais e aplicativos de mensagem geralmente não executam JavaScript ao gerar a prévia — eles leem apenas o HTML inicial. Se título, descrição e imagem são alterados por JavaScript depois do carregamento, a prévia mostra o que estava no HTML original, igual para todas as rotas.

Como saber se meu site React é indexável?

Desabilite o JavaScript no navegador e recarregue a página. Se o conteúdo aparece, o HTML veio pronto. Se a tela fica em branco, o conteúdo depende de JavaScript. Também vale ver o código-fonte original da página, e não as ferramentas de inspeção, que mostram o resultado após a execução.

O Google não executa JavaScript?

Executa, mas em uma etapa separada e posterior ao rastreamento inicial. Na prática, isso significa que o conteúdo pode demorar mais para ser indexado ou ser indexado parcialmente. Redes sociais e aplicativos de mensagem, que geram prévias de compartilhamento, geralmente não executam.

Preciso migrar toda a aplicação para renderização no servidor?

Nem sempre. Um meio-termo comum é pré-renderizar apenas as rotas públicas, que precisam ser encontradas, mantendo o restante como aplicação de página única. Isso cobre bem o caso mais frequente: um produto com páginas públicas de conteúdo e uma área logada que não precisa ser indexada.

Que outros elementos afetam o SEO de uma aplicação React?

URLs reais e acessíveis diretamente para cada conteúdo, endereço canônico por página, mapa do site, links reais no HTML em vez de navegação apenas por eventos de clique, códigos de resposta corretos para páginas inexistentes e redirecionamentos feitos no servidor.

Por que uma rota inexistente que abre a página principal é um problema?

Porque cria conteúdo duplicado: o buscador recebe a mesma resposta para infinitos endereços diferentes. Uma página inexistente deve retornar o código de erro apropriado, e não uma página aparentemente normal com uma mensagem de erro dentro dela.

Velocidade afeta o SEO de uma aplicação React?

Sim, pelas métricas de experiência de página. Aplicações React têm um desafio específico: o pacote de JavaScript precisa ser baixado, interpretado e executado antes de a interface aparecer, o que pesa em celulares e conexões modestas. Dividir o código por rota e otimizar imagens são as medidas de maior efeito.