SEO para sites em JavaScript é o trabalho de fazer com que buscadores e sistemas de IA consigam ler o conteúdo, os links e os metadados de um site feito com React, Vue, Angular ou frameworks parecidos. O Google renderiza JavaScript, mas em uma etapa separada do rastreamento, e vários rastreadores de IA não executam JavaScript nenhum. Por isso, eu recomendo que o conteúdo principal, os links e as tags de SEO cheguem prontos no HTML enviado pelo servidor, com SSR ou geração estática.
Em empresas de SaaS, o site institucional muitas vezes nasce no mesmo repositório do produto, feito pelo time de engenharia com a mesma stack. Faz sentido do ponto de vista de quem desenvolve. O problema aparece meses depois, quando o marketing pergunta por que as páginas novas não aparecem no Google ou por que a IA descreve a empresa com informações velhas.
Neste guia eu explico como o Google processa JavaScript segundo a própria documentação, a diferença entre CSR, SSR, SSG e ISR, por que sites em React sofrem, o que muda com Next.js, como diagnosticar e o que os rastreadores de IA enxergam.
A documentação de fundamentos de SEO para JavaScript do Google descreve três fases: rastreamento, renderização e indexação. O Googlebot busca a URL, confere o robots.txt e lê o HTML que o servidor entregou. Depois, as páginas com status 200 entram numa fila de renderização, onde um Chromium sem interface executa o JavaScript. Só então o Google analisa o HTML renderizado para extrair conteúdo e novos links.
Segundo o Google, a página pode ficar alguns segundos nessa fila, e às vezes mais. Na prática, isso significa que tudo o que depende de JavaScript chega ao índice depois do que já estava no HTML inicial. Para um blog com poucas páginas, a diferença pode ser pequena. Para um site com centenas de páginas de integração ou de casos de uso, cada etapa extra pesa na descoberta.
Alguns detalhes da documentação que eu vejo causarem problema com frequência:
O mesmo documento diz que renderizar no servidor ou pré-renderizar continua sendo uma boa ideia, porque deixa o site mais rápido para usuários e rastreadores e porque nem todo robô executa JavaScript. Essa frase resume a minha recomendação de SEO para sites em JavaScript que existem para gerar demanda.
As siglas confundem, mas a pergunta que eu faço é sempre a mesma: quando o rastreador pede a URL, o HTML que volta já tem o texto, os links e as tags de SEO? O artigo do web.dev sobre renderização na web define cada abordagem, e eu resumo pensando em SEO.
O servidor entrega um HTML quase vazio e um pacote de JavaScript. O navegador executa o código, busca os dados e monta a página. Para o rastreador que não executa JavaScript, a página é praticamente uma tela em branco. Para o Google, funciona depois da renderização, mas o web.dev observa que esse modelo costuma exigir mais teste e mais cuidado.
O servidor monta o HTML completo a cada requisição e envia pronto. O JavaScript depois "hidrata" a página para deixá-la interativa. Para SEO, resolve o problema central, porque o conteúdo está no primeiro HTML. O custo é processamento no servidor e, às vezes, um tempo de resposta maior.
O HTML de cada URL é gerado no momento do build e servido como arquivo estático. É a opção mais simples e rápida para páginas que mudam pouco, como a maioria das páginas de um site institucional de SaaS. A limitação aparece quando há muitas páginas ou conteúdo que muda com frequência, porque cada mudança exige novo build.
É um recurso do Next.js que combina as duas coisas. A documentação de ISR do Next.js explica que as páginas são geradas como estáticas e atualizadas em segundo plano depois de um intervalo definido, ou sob demanda quando o conteúdo muda no CMS. Para blogs e diretórios de integração grandes, é o modelo que eu mais recomendo: HTML pronto para o rastreador, sem rebuild do site inteiro a cada post.
Durante anos, a saída para sites em CSR foi servir uma versão pré-renderizada só para robôs. O próprio Google hoje descreve a renderização dinâmica como uma solução paliativa e não recomendada, e aponta SSR, renderização estática ou hidratação como caminhos melhores. Eu só uso como ponte temporária enquanto a migração para SSR não sai.
O que eu vejo dar errado com React é usar a configuração padrão de uma aplicação de página única para páginas que precisam ser encontradas em busca. No que vejo em projetos de SaaS, os sintomas se repetem:
Outro ponto comum: o site de marketing e o aplicativo logado dividem o mesmo domínio e a mesma base de código. Aí qualquer decisão de arquitetura do produto afeta o SEO das páginas públicas. Quando possível, eu separo o site público do app, com stack e deploy próprios. Falo mais dessa decisão no guia sobre site para SaaS.
O Next.js resolve boa parte dos problemas acima porque oferece SSR, SSG e ISR por rota. No App Router, os componentes são de servidor por padrão, o que significa que o HTML inicial já sai com conteúdo, a menos que o time marque tudo como componente de cliente. Ainda assim, só adotar o framework não resolve o SEO. Os erros que eu encontro em sites feitos com ele:
Para um site de marketing em Next.js, o meu padrão é SSG ou ISR para páginas institucionais, posts e integrações, e SSR só onde o conteúdo realmente precisa ser montado a cada requisição.
O Google tem um guia para corrigir problemas de JavaScript na Busca, e eu sigo uma versão prática dele. São quatro testes que qualquer pessoa do time de marketing consegue fazer.
Abra a página no navegador, use "exibir código-fonte" e procure o título principal e um parágrafo do meio do texto. Se não estiverem lá, o conteúdo depende de JavaScript. O código-fonte é o que um rastreador sem JavaScript recebe.
Na Inspeção de URL, o teste ao vivo mostra o HTML renderizado pelo Google, uma captura de tela, os recursos que não carregaram e as mensagens do console JavaScript. Eu confiro se o texto completo, os links e as tags de title, canonical e robots aparecem no HTML renderizado. O Teste de pesquisa aprimorada mostra a mesma visão para quem não tem acesso ao Search Console.
No HTML renderizado, procure os links do menu, do rodapé e do corpo. Todos precisam ser elementos a com href apontando para URLs reais. Se a navegação depende de clique em elementos sem href, o Google pode não descobrir as páginas de destino.
Acesse uma URL inventada e veja o código de status na aba de rede do navegador. Precisa ser 404. Se for 200, o site está gerando soft 404.
Depois desses testes, olho o relatório de indexação de páginas no Search Console. Muitas URLs em "Rastreada, mas não indexada" ou "Descoberta, mas não indexada" num site em JavaScript costumam apontar para problema de renderização ou de links. Esse diagnóstico faz parte de qualquer projeto de SEO técnico que eu conduzo em empresas de software.
Aqui a situação é diferente do Google. Em dezembro de 2024, a Vercel publicou com a MERJ uma análise de tráfego de rastreadores de IA na rede da Vercel e concluiu que nenhum dos principais rastreadores de IA observados renderizava JavaScript. Entre eles estavam os robôs da OpenAI (GPTBot, OAI-SearchBot e ChatGPT-User), o ClaudeBot da Anthropic e o PerplexityBot. Alguns até baixavam arquivos JavaScript, sem executá-los. Na mesma análise, o Gemini aparece com renderização completa por usar a infraestrutura do Googlebot.
Eu trato esse dado com cautela. É um retrato de dezembro de 2024, feito a partir do tráfego de uma plataforma específica, e as empresas de IA não publicam documentação detalhada sobre como seus robôs lidam com renderização. Mesmo assim, a conclusão prática é segura: se o conteúdo só existe depois do JavaScript, há um risco real de os sistemas de IA lerem uma página vazia ou incompleta.
Isso afeta diretamente o trabalho de GEO. Se a página de produto de um SaaS em CSR não entrega texto no HTML, a IA tende a se apoiar em fontes externas, que podem estar desatualizadas, para descrever a empresa. A recomendação da própria Vercel vai na mesma linha da minha: renderizar no servidor o conteúdo principal, os metadados e a navegação, e deixar no cliente só o que é interação.
Quando um cliente me pede ajuda com SEO para sites em JavaScript, a correção depende da stack e do tamanho do site. Este é o caminho que eu costumo propor, em ordem:
O prazo varia muito. Correções de links e metadados costumam levar poucas semanas. Mudar o modelo de renderização de um site inteiro é um projeto de engenharia, e o efeito na indexação aparece aos poucos, conforme o Google rastreia de novo as páginas.
Sim, o Google renderiza JavaScript com um Chromium e pode indexar sites em React. Mas a renderização acontece numa etapa separada, depois do rastreamento, e problemas como links sem href, noindex no HTML inicial ou conteúdo atrás de clique continuam atrapalhando. Por isso eu prefiro que o conteúdo já venha no HTML do servidor.
Para páginas que precisam aparecer em busca, SSR ou geração estática. Os dois entregam o conteúdo no HTML inicial, que qualquer rastreador lê. CSR funciona para o Google depois da renderização, mas exige mais teste e deixa de fora os rastreadores que não executam JavaScript.
Não. O framework oferece SSR, SSG e ISR, mas a configuração pode anular essas vantagens. Página inteira marcada como componente de cliente, dados buscados no navegador e metadados genéricos são comuns. É preciso conferir o HTML que cada rota entrega.
Segundo a análise da Vercel publicada em dezembro de 2024, os rastreadores da OpenAI observados não executavam JavaScript. Isso indica risco de leitura incompleta quando o conteúdo depende de renderização no navegador. Como esses robôs mudam e não há documentação detalhada, eu recomendo entregar o conteúdo principal no HTML do servidor.
Compare o código-fonte da página com o HTML renderizado na Inspeção de URL do Search Console. Se o texto principal, os links ou as tags de SEO só aparecem no renderizado, existe dependência de JavaScript. Confira também se rotas inexistentes devolvem status 404.
Se o seu site foi feito pelo time de produto em React ou Next.js e o marketing não sabe o que o Google e as IAs estão enxergando, o primeiro passo é testar um template de cada tipo e mapear onde o conteúdo depende de JavaScript. A Pipa faz esse diagnóstico dentro do trabalho de SEO técnico para empresas de tecnologia e conecta as correções à estratégia de SEO para SaaS. Se quiser uma primeira leitura do seu site, peça o diagnóstico gratuito.
