SEO para sites em JavaScript: como o Google processa e renderiza

O Google processa JavaScript em três fases: rastreamento, renderização e indexação. A documentação do Google Search Central, atualizada em 4 de março de 2026, lista o que ainda depende da configuração do site.

Rastreamento: URL bloqueada no robots.txt é descartada

A primeira checagem é o robots.txt. Se a URL estiver marcada como bloqueada, o Googlebot não faz a requisição e descarta o endereço.

A documentação afirma que o Google Search não renderiza JavaScript de arquivos bloqueados nem de páginas bloqueadas. Para evitar a descoberta de links, o documento indica o mecanismo nofollow.

Inserir links no DOM via JavaScript é aceitável, desde que siga as boas práticas para links rastreáveis (veja links rastreáveis e texto âncora).

Em sites clássicos ou com renderização no servidor, o HTML da resposta já traz todo o conteúdo. Em parte dos sites JavaScript, o modelo é o de app shell: o HTML inicial não tem o conteúdo real e o Google precisa executar o JavaScript para vê-lo.

Renderização: o status 200 coloca a página na fila

O Googlebot enfileira para renderização todas as páginas com código HTTP 200, tenham JavaScript ou não. A exceção fica para meta tag robots ou cabeçalho que indiquem que a página não deve ser indexada.

A espera pode durar alguns segundos, mas pode ser maior. Quando há recursos disponíveis, um Chromium headless renderiza a página e executa o JavaScript.

O Googlebot então analisa o HTML renderizado em busca de links e enfileira as URLs encontradas para rastreamento. Esse mesmo HTML é usado para indexar a página.

Códigos diferentes de 200, como erros 404, podem levar ao cancelamento da renderização. A documentação ressalta que o Googlebot enfileira páginas para rastreamento e para renderização sem deixar claro, de imediato, em qual das duas filas a página está esperando.

A recomendação da fonte é renderização no servidor ou pré-renderização. Isso deixa o site mais rápido para usuários e rastreadores, e nem todos os bots executam JavaScript.

Canônica: o melhor lugar é o HTML

Títulos únicos e descritivos, junto de meta descriptions, ajudam o usuário a identificar o melhor resultado. A documentação diz que é possível definir ou alterar a meta description e o elemento <title> com JavaScript.

A canônica deve ficar no HTML. Se for necessário usar JavaScript, o valor precisa ser o mesmo já indicado no HTML original. Não se deve usar JavaScript para trocar a canônica por outra URL.

Se a página não tem a canônica no HTML, é possível defini-la com JavaScript. A injeção deve resultar em apenas uma tag canônica na página.

Implementações erradas podem criar tags múltiplas ou alterar a existente, com resultados inesperados. O guia de tag canônica detalha a consolidação de URLs duplicadas.

Código compatível e códigos HTTP com significado

O Google tem limitações sobre quais APIs e recursos de JavaScript suporta; para checar compatibilidade, a documentação remete ao guia de solução de problemas.

A recomendação é usar differential serving e polyfills quando um recurso de navegador necessário não existir. A fonte pede verificar a documentação do polyfill, já que alguns recursos não podem ser preenchidos.

O Googlebot usa o código HTTP para saber se algo deu errado. A orientação é usar códigos com significado — 404 para página inexistente, 401 para conteúdo atrás de login — e indicar com eles quando uma página mudou de URL. O guia de códigos HTTP e erros de rede cobre o efeito de cada faixa no rastreamento.

Soft 404 em aplicações de página única

Em aplicações de página única com renderização e roteamento no cliente, usar códigos HTTP com significado pode ser impossível ou impraticável. Para evitar soft 404, a documentação oferece duas saídas.

• Redirecionar via JavaScript para uma URL em que o servidor responde 404, como /not-found.
• Incluir, via JavaScript, a tag <meta name="robots" content="noindex"> nas páginas de erro.

fetch(`/api/products/${productId}`)
  .then(response => response.json())
  .then(product => {
    if (product.exists) {
      showProductDetails(product);
    } else {
      window.location.href = '/not-found';
    }
  });

History API em vez de fragmentos

O Google só descobre links que sejam elementos <a> com atributo href. Em aplicações de página única com roteamento no cliente, a documentação recomenda implementar a navegação com a History API.

Nada de fragmentos como #/products para carregar conteúdo diferente. O Googlebot não resolve essas URLs de forma confiável. O exemplo correto da fonte usa window.history.pushState para atualizar a URL e o histórico do navegador.

Meta robots: o noindex pode pular a renderização

A tag <meta name="robots" content="noindex, nofollow"> impede a indexação e o seguimento de links. É possível adicionar ou alterar a tag com JavaScript, por exemplo para marcar como noindex uma página cuja API não retornou conteúdo.

Mas há um alerta: ao encontrar noindex, o Google pode pular a renderização e a execução de JavaScript. Uma alteração posterior via JavaScript pode não funcionar como esperado.

Se a página deve ser indexada, não use noindex no código original. A diferença entre noindex e bloqueio no robots.txt está neste comparativo.

Cache: fingerprint no nome do arquivo resolve

O Googlebot faz cache de forma agressiva para reduzir requisições. O WRS, serviço de renderização usado no rastreamento, pode ignorar cabeçalhos de cache, o que leva a usar versões desatualizadas de JavaScript ou CSS.

A saída indicada é o fingerprint de conteúdo no nome do arquivo, como main.2bb85551.js. Como o nome muda a cada alteração do arquivo, a versão nova é buscada.

Dados estruturados e componentes web

A documentação permite gerar o JSON-LD com JavaScript e injetá-lo na página, com teste da implementação. A introdução a dados estruturados explica o formato.

Componentes web são suportados. Ao renderizar, o Google achata o conteúdo de shadow DOM e light DOM. Só o que estiver visível no HTML renderizado pode ser indexado.

Para conferir, a fonte indica o teste de resultados avançados ou a ferramenta de inspeção de URL, olhando o HTML renderizado. Se o conteúdo não aparece ali, não será indexado.

O uso de um elemento slot é uma forma de exibir light DOM e shadow DOM juntos.

Imagens e carregamento tardio

Imagens pesam em banda e desempenho, e o carregamento tardio (lazy-loading) é uma estratégia indicada para carregá-las quando o usuário estiver perto de vê-las. A implementação precisa seguir as diretrizes de lazy-loading do Google para continuar amigável à Busca.