SEO técnico para sites JavaScript: rastreamento, renderização e indexação

Leitura executiva

Principais conclusões

• Conteúdo crítico deve estar disponível sem interação obrigatória.
• Links precisam de elemento a com href resolvível.
• Status, canonical e robots devem ser coerentes no HTML inicial.
• Teste origem, DOM renderizado e inspeção do mecanismo de busca.

Aplicações JavaScript podem aparecer em mecanismos de busca, mas o caminho entre URL e conteúdo tem mais pontos de falha. O crawler precisa acessar a página, receber uma resposta adequada, descobrir recursos, executar código quando necessário, construir o conteúdo e então avaliar a versão renderizada.

O guia oficial de JavaScript SEO do Google descreve três fases: crawling, rendering e indexing. O Google usa Chromium para renderizar, mas processamento pode entrar numa fila, recursos bloqueados podem impedir conteúdo e outros bots podem ter capacidade diferente.

Entenda o que chega no HTML inicial

Abra a resposta do documento sem executar JavaScript e procure:

• título e meta description;
• canonical;
• robots meta;
• h1 e conteúdo principal;
• links internos;
• dados estruturados;
• informações de produto ou artigo;
• estados de erro;
• hreflang quando aplicável.

Se o HTML contém apenas um contêiner vazio e scripts, toda a compreensão depende da renderização. Isso pode funcionar para o Google, mas aumenta complexidade, tempo e diferença entre crawlers.

Renderização no servidor, geração estática ou uma abordagem híbrida torna o conteúdo crítico disponível cedo para usuários e agentes.

Use URLs reais para cada conteúdo

Cada página que precisa ser descoberta deve ter uma URL estável e compartilhável. Filtros, abas e estados só precisam de URL própria quando representam conteúdo útil e indexável.

Evite carregar páginas distintas apenas por fragmentos como #/produto. Para roteamento no cliente, use a History API e mantenha o servidor capaz de responder diretamente à URL.

Teste acesso direto, atualização, compartilhamento e navegação sem depender de uma sessão anterior.

Faça links rastreáveis

O padrão mais confiável é:

<a href="/pt-br/blog/core-web-vitals-campo-laboratorio">Dados de campo e laboratório</a>

Um div com onClick, botão que altera rota ou link sem href pode funcionar para uma pessoa com JavaScript e ainda falhar na descoberta, navegação por teclado ou abertura em nova aba.

Use botão para ação e link para navegação. Garanta que o destino exista no HTML renderizado e que não dependa de rolagem ou clique para ser criado.

Retorne status HTTP significativos

Single-page applications às vezes retornam 200 para todas as rotas, inclusive produtos removidos e erros. Isso cria soft 404 e dificulta interpretação.

O servidor deve retornar:

• 200 para conteúdo disponível;
• 301 ou 308 para mudança permanente;
• 302 ou 307 para mudança temporária;
• 404 para recurso inexistente;
• 410 quando a remoção permanente e intencional precisa ser sinalizada;
• 401 ou 403 para acesso restrito conforme o caso;
• 5xx para falha real do servidor.

Uma mensagem “não encontrado” renderizada dentro de resposta 200 não substitui o status.

Defina metadata de forma estável

Title, description, canonical e robots precisam representar a URL atual. Em navegação cliente, confirme que a metadata muda corretamente e não herda valores da página anterior.

A canonical deve ser absoluta e coerente entre HTML inicial, renderizado, sitemap e links internos. Não use canonical como solução para toda paginação ou filtro sem analisar a intenção.

Evite começar com noindex e tentar removê-lo via JavaScript. A documentação do Google alerta que, ao encontrar noindex, o sistema pode pular renderização; a remoção posterior pode não funcionar como esperado.

Não esconda conteúdo atrás de interação

Google não rola ou clica como uma pessoa para revelar conteúdo. Lazy-loading precisa carregar quando o elemento entra no viewport, não apenas após um botão ou gesto.

Conteúdo principal, produtos de uma lista paginada e links de descoberta não devem depender exclusivamente de:

• scroll infinito sem URLs paginadas;
• clique em “carregar mais” sem links alternativos;
• hover;
• gesto de carrossel;
• seleção prévia no formulário;
• API chamada apenas depois de interação.

O guia de lazy-loading do Google recomenda implementações que não exijam ações do usuário para expor conteúdo relevante.

Trate renderização e performance juntas

Enviar todo o conteúdo via cliente aumenta trabalho de rede e CPU. Mesmo quando o crawler executa o código, usuários podem enfrentar LCP lento e INP alto.

Pergunte por componente:

• precisa ser interativo;
• pode renderizar no servidor;
• pode ser carregado depois;
• precisa hidratar;
• está no caminho crítico;
• aparece em todas as rotas;
• depende de um terceiro.

Server Components, ilhas de interatividade e geração estática são meios de reduzir JavaScript; a arquitetura deve seguir dados, personalização e experiência do produto.

Mantenha conteúdo consistente

O conteúdo apresentado ao crawler deve corresponder ao que o usuário recebe. Diferenças legítimas por dispositivo, localização ou login precisam manter a mesma intenção central.

Evite:

• conteúdo completo no servidor e texto vazio após hidratação;
• títulos divergentes;
• canonical trocada pelo cliente;
• erro de API que remove o conteúdo principal;
• skeleton permanente para crawlers;
• dados estruturados descrevendo informação ausente.

Problemas de hidratação podem deixar o HTML inicial correto e a interface final quebrada. Inspecione as duas camadas.

Teste origem e renderização

Use um roteiro repetível:

1. faça uma requisição direta e registre status e HTML;
2. abra a página com JavaScript desativado para diagnóstico, sem assumir que essa é a experiência final de todos os bots;
3. renderize em navegador limpo;
4. compare conteúdo, links, metadata e schema;
5. verifique console e rede;
6. teste mobile e desktop;
7. use a inspeção de URL e o HTML renderizado disponível na ferramenta do mecanismo;
8. valide páginas boas, vazias, removidas e com erro de API.

Uma captura visual não prova que links são rastreáveis. Um HTML correto não prova que a hidratação preservou o conteúdo.

Monitore deploys e regressões

Mudanças de framework, roteamento, middleware e consentimento podem afetar todo o site. Automatize verificações para templates críticos:

• status esperado;
• title e canonical;
• robots;
• presença do h1;
• conteúdo principal;
• links internos;
• schema válido;
• ausência de erro de hidratação;
• sitemap atualizado.

Integre a checklist de lançamento ao processo de deploy. Teste a URL publicada, não apenas o ambiente local.

Exemplo de achado e ação

Observação: páginas de categoria retornam HTML com shell vazio; produtos e links aparecem somente após uma API do cliente. Quando a API falha, a resposta continua 200 e sem conteúdo. Ação: renderizar título, descrição, primeira página de produtos e paginação no servidor; retornar erro adequado quando os dados não estiverem disponíveis. Aceite: conteúdo e links existem no HTML inicial, navegação cliente permanece funcional e estados de erro usam status coerente.

SEO para JavaScript não exige abandonar aplicações modernas. Exige reduzir dependências desnecessárias, usar padrões da plataforma e verificar o que cada agente realmente recebe em cada etapa.

Respostas diretas

Perguntas frequentes

O Google executa JavaScript?

Sim. A documentação do Google descreve fases de rastreamento, renderização e indexação com Chromium. Ainda existem filas, limitações e outros bots que podem não executar a aplicação.

SSR garante SEO?

Não. SSR melhora a disponibilidade inicial do conteúdo, mas URLs, canonical, status, links, conteúdo e qualidade continuam precisando de implementação correta.

Posso usar JavaScript para definir canonical?

O Google pode processar canonical inserida por JavaScript, mas recomenda manter consistência e prefere a definição no HTML quando possível.