Erros de rastreamento: como identificar e corrigir cada tipo

Um erro de rastreamento acontece quando o Googlebot (ou qualquer outro rastreador) tenta buscar uma URL do seu site e a busca falha: o servidor não responde, devolve um código de erro, ou a conexão não se completa. Isso é diferente de um problema de indexação, onde a página é buscada sem problema nenhum, mas o Google decide não colocá-la no índice por outros motivos, como conteúdo duplicado, qualidade baixa ou uma diretriz noindex. Confundir as duas coisas leva a diagnósticos errados: mexer no robots.txt ou nos redirecionamentos não resolve um problema que na verdade é de qualidade de conteúdo.

Este artigo cobre os erros de rastreamento: onde encontrá-los, os tipos que importam, como diagnosticar e corrigir cada um, e como priorizar uma lista de centenas de erros sem tentar zerá-la, porque zerar não é o objetivo e não é realista.

O que é (e o que não é) um erro de rastreamento

Rastreamento é a etapa em que o rastreador visita uma URL e tenta baixar o conteúdo. Um erro de rastreamento é qualquer coisa que impede essa etapa de terminar com sucesso: o servidor demora demais para responder, devolve um código 5xx, a URL não existe mais e devolve 404, o DNS não resolve, ou o rastreador é bloqueado antes de chegar ao conteúdo.

Indexação é a etapa seguinte, e só acontece depois que o rastreamento deu certo. Uma página pode ser rastreada perfeitamente — resposta 200, conteúdo completo, sem bloqueio nenhum — e mesmo assim não ser indexada, porque o Google considerou o conteúdo fino demais, duplicado de outra URL do mesmo site, ou porque uma tag noindex está presente. Isso não é um erro de rastreamento, é uma decisão de indexação, e a correção é outra: melhorar o conteúdo, consolidar duplicatas, remover a tag noindex, não mexer em servidor, DNS ou robots.txt.

• Erro de rastreamento: o rastreador não conseguiu buscar a página.
• Problema de indexação: a página foi buscada normalmente, mas não entrou no índice por decisão de qualidade ou diretiva.
• Os dois aparecem em relatórios parecidos no Search Console, mas pedem diagnósticos diferentes.

Onde ver os erros de rastreamento

O primeiro lugar é o relatório de indexação de páginas do Search Console, que lista URLs não indexadas e o motivo — vários desses motivos são efetivamente erros de rastreamento: erro de servidor, erro de redirecionamento, não encontrada, bloqueada por robots.txt. Cada linha pode ser expandida para ver URLs afetadas, e cada URL pode ser inspecionada pela ferramenta de inspeção de URL, que mostra a última tentativa de rastreamento e o código de resposta recebido.

O segundo lugar é o relatório de estatísticas de rastreamento, nas configurações do Search Console, que mostra o volume de requisições por dia, a distribuição de códigos de resposta e o tempo médio de resposta do servidor. É a melhor fonte para enxergar um padrão: um pico de erros de servidor num dia específico costuma coincidir com uma implantação, uma migração ou uma sobrecarga pontual.

O terceiro lugar, e o mais completo, são os logs do próprio servidor. O Search Console mostra uma amostra do que o Googlebot encontrou; o log mostra cada requisição de cada rastreador, com o user-agent, o código de resposta exato e o tempo de resposta — inclusive coisas que o Search Console não mostra, como um rastreador de IA batendo em milhares de URLs com parâmetro, ou um bot alegando ser o Googlebot que na verdade não é.

• Search Console, indexação de páginas: motivo por que cada URL não foi indexada.
• Search Console, estatísticas de rastreamento: volume e códigos de resposta ao longo do tempo.
• Logs de servidor: cada requisição, de cada rastreador, sem amostragem.

Erros de servidor (5xx)

Um código 5xx significa que o servidor recebeu a requisição e falhou ao processá-la. As causas mais comuns são timeout, quando o servidor demora demais e o rastreador desiste; esgotamento de recursos, como memória, conexões de banco de dados ou o limite de processos simultâneos do plano de hospedagem; e erros de aplicação, como uma exceção não tratada ou uma consulta ao banco que trava.

O diagnóstico começa pelos logs do servidor, correlacionando o horário dos erros com picos de tráfego, janelas de deploy ou tarefas agendadas. Se os erros são pontuais e coincidem com um evento identificável, o problema provavelmente já passou. Se são recorrentes ou crescentes, o servidor está no limite da capacidade ou há uma regressão de código que precisa ser corrigida.

Erros de servidor generalizados são o tipo mais urgente da lista: se o Googlebot recebe esses erros com frequência alta, ele reduz a taxa de rastreamento do site inteiro como medida de proteção, o que atrasa a descoberta de conteúdo novo e a atualização do que já existe.

Erros 404: quais importam e quais não importam

Um 404 significa que a URL não existe. Isso, por si só, não é um problema: é o comportamento correto para uma página que você removeu de propósito. Um produto que saiu de linha, uma categoria descontinuada, um post de teste que nunca deveria ter sido publicado — todos devem devolver 404, ou 410, que sinaliza remoção permanente com mais clareza, e não há nada a corrigir.

O 404 vira um problema quando a URL removida ainda tem valor: links internos apontando para ela, backlinks externos apontando para ela, ou histórico de tráfego orgânico relevante. Nesses casos, deixar como 404 custa a autoridade que esses links carregavam e frustra quem clicou vindo de outro site.

Para separar os dois casos, cruze a lista de páginas não encontradas do Search Console com dados de backlinks e com uma busca por links internos quebrados. Se a URL tem links de valor, a correção certa é um redirecionamento permanente para a página mais próxima em conteúdo, não necessariamente a página inicial. Se não tem, o 404 está certo do jeito que está.

• 404 sem links de valor apontando para ele: comportamento esperado, nada a fazer.
• 404 com backlinks externos ou links internos relevantes: redirecionar para a página equivalente mais próxima.
• Nunca redirecione páginas não encontradas em massa para a página inicial só para "limpar" o relatório: isso confunde o rastreador e dilui sinal.

Problemas de redirecionamento: cadeias e loops

Uma cadeia de redirecionamento acontece quando uma URL redireciona para outra, que redireciona para outra, antes de chegar ao destino final: a página A aponta para B, que aponta para C. Cada salto consome parte do orçamento de rastreamento e adiciona tempo de resposta; cadeias longas fazem o rastreador desistir antes de chegar ao conteúdo real, especialmente em sites grandes onde esse orçamento é finito.

Um loop de redirecionamento é o caso extremo: a página A aponta para B, que aponta de volta para A, sem destino final. O rastreador e o navegador do usuário ficam presos num ciclo e a página nunca carrega.

Cadeias costumam surgir depois de sucessivas migrações: um redirecionamento criado numa troca de domínio, outro criado meses depois numa reestruturação de URLs, sem que ninguém tenha atualizado o primeiro para apontar direto ao destino atual. A correção é sempre a mesma: identificar o destino final de verdade e fazer cada redirecionamento apontar direto para ele, em um único salto. Ferramentas de rastreamento de sites e a própria inspeção de URL do Search Console mostram a cadeia completa, salto a salto, o que facilita achar onde cortar.

Bloqueado por robots.txt

Esse erro aparece quando uma regra no arquivo robots.txt impede o rastreador de acessar a URL. Às vezes é intencional: você não quer que páginas de carrinho, de busca interna ou de área administrativa sejam rastreadas, e por isso as bloqueou de propósito. Nesse caso não há nada a corrigir.

O problema real é quando uma regra bloqueia algo que deveria estar acessível: uma regra ampla criada para bloquear um diretório de teste que sem querer também bloqueia um diretório de conteúdo, ou uma regra deixada de um ambiente de teste que foi copiada para produção sem revisão. O sintoma típico é uma queda de tráfego num conjunto inteiro de páginas de uma vez, todas sob o mesmo caminho de URL.

Para confirmar, use a ferramenta de inspeção de URL do Search Console, que indica se uma URL específica está bloqueada pelo robots.txt, e o relatório de robots.txt nas configurações para revisar as regras que o Google leu. A correção é ajustar a regra para ser mais específica, bloqueando só o caminho que realmente deveria estar de fora, e validar de novo antes de considerar resolvido.

Falhas de DNS e conectividade

Esse é o tipo menos comum, mas o mais sério quando acontece, porque significa que o rastreador não conseguiu nem chegar ao servidor: não é uma questão de código de resposta, é a conexão que falha antes disso. As causas típicas são um registro DNS mal configurado ou não propagado depois de uma troca de provedor, um certificado SSL expirado ou mal instalado, um firewall ou sistema de proteção contra bots bloqueando a faixa de IPs do rastreador por engano, ou o servidor fora do ar.

O diagnóstico passa por confirmar que o domínio resolve para o endereço esperado, que o certificado SSL está válido e corresponde ao domínio, e que nenhuma regra de firewall ou de um plugin de segurança está bloqueando o user-agent do rastreador — algo comum depois da instalação de um plugin de proteção contra bots mal configurado, que trata qualquer requisição em alto volume, inclusive a do Googlebot, como suspeita.

Enquanto essa falha persiste, nenhuma página do site é rastreada, então é o tipo de erro que exige ação imediata assim que detectado, não algo que espera a próxima rodada de priorização.

Soft 404: quando a página existe, mas não deveria

Um soft 404 é um caso híbrido. Tecnicamente, o rastreamento funciona: a URL responde com código 200, sem erro de servidor nem bloqueio. Mas o conteúdo sinaliza para o Google que ali não há nada de útil: uma página de produto sem estoque que só mostra "produto não encontrado" com resposta 200, um resultado de busca interna vazio, uma página esvaziada mas nunca removida de fato.

O Google interpreta esses sinais — texto curto, frases do tipo "não encontrado" ou "indisponível", ausência de conteúdo estruturado — e trata a URL como se fosse um 404, mesmo o código de resposta dizendo o contrário. Por isso ela aparece junto dos erros de rastreamento no Search Console, embora a causa seja de conteúdo, não de infraestrutura.

A correção depende da intenção real da página: se ela deveria mesmo deixar de existir, o certo é o servidor devolver um 404 ou 410 de verdade, em vez de 200 com texto de erro. Se ela deveria ter conteúdo, a correção é preencher a página de fato — por exemplo, sugerindo produtos similares em vez de deixar a busca vazia.

Como priorizar uma lista longa de erros

Sites com histórico têm centenas ou milhares de URLs listadas em algum relatório de erro, e tentar zerar essa lista é tempo mal gasto: parte dela é ruído esperado, como os 404s de conteúdo removido de propósito. A pergunta certa não é "como chego a zero", é "quais desses erros custam alguma coisa de verdade".

Comece pelo valor da URL afetada: uma página que recebe tráfego orgânico, tem backlinks externos ou faz parte do caminho de conversão pesa muito mais do que uma URL órfã sem histórico nenhum. Em seguida, olhe a escala: um erro que afeta um punhado de URLs antigas é diferente de um erro que afeta milhares de páginas de uma vez, porque o segundo caso costuma indicar uma causa sistêmica — um template quebrado, uma regra de robots.txt ampla demais, um problema de servidor — em vez de casos isolados.

Depois considere o tipo: erros de servidor generalizados e falhas de DNS pedem ação imediata porque afetam o site inteiro; bloqueios acidentais de robots.txt e cadeias de redirecionamento vêm em seguida; páginas não encontradas isoladas e sem valor ficam por último, porque corrigi-las não muda nada de relevante. Por fim, olhe a tendência: um número crescendo semana a semana merece atenção mesmo com volume absoluto pequeno, porque indica um problema novo e ativo, não um resíduo antigo já estabilizado.

• Valor da URL: tráfego, backlinks e papel na conversão.
• Escala: erro isolado ou padrão sistêmico afetando muitas URLs?
• Tipo: erros de servidor e falhas de DNS primeiro, depois robots.txt e redirecionamentos, páginas de baixo valor por último.
• Tendência: um número crescente pesa mais que um número estável, mesmo que menor.

Como confirmar que a correção funcionou

Depois de corrigir a causa, a tentação é olhar o relatório do Search Console no dia seguinte e esperar o número zerado. Isso raramente acontece, porque o relatório reflete rastreamentos passados e só se atualiza conforme o rastreador revisita as URLs, o que pode levar dias ou semanas dependendo da frequência de rastreamento daquele site.

O caminho mais rápido para uma verificação pontual é a ferramenta de inspeção de URL: peça um teste ao vivo da URL corrigida e confira o código de resposta atual diretamente, sem esperar o próximo rastreamento agendado. Se o código já está correto, é possível solicitar uma nova indexação pela mesma ferramenta, o que não garante um recrawl imediato, mas sinaliza prioridade.

Para confirmar em escala, depois de corrigir uma causa que afetava muitas URLs de uma vez, volte aos logs do servidor e observe se os códigos de resposta mudaram nos dias seguintes. Os logs mostram o resultado real de cada requisição do rastreador, sem esperar o Search Console consolidar o relatório, e são a forma mais confiável de saber se a correção pegou antes que o painel reflita isso.