Um URL que devolve um código de erro HTTP nem sempre indica o mesmo problema. Entre um pedido malformado (400), uma página eliminada (404) e um servidor sobrecarregado (503), a causa, o impacto na indexação e os passos a seguir são radicalmente diferentes. Avaliar as diferenças entre estes códigos permite dar prioridade às correções e limitar os danos para o SEO.
Códigos de erro HTTP: diferenças de impacto entre as famílias 4xx e 5xx
O primeiro algarismo do código de estado determina de que lado está o problema. As famílias 4xx e 5xx têm impactos muito diferentes na exploração de um site pelos robôs do Google.
| Código | Família | Origem do problema | Consequência na indexação |
|---|---|---|---|
| 400 | 4xx (cliente) | URL malformado, caracteres não codificados, parâmetro em falta | Página tratada como inexistente e removida do índice após algumas tentativas |
| 403 | 4xx (cliente) | Acesso recusado pelo servidor (permissões, .htaccess) | Página não indexada enquanto o acesso continuar bloqueado |
| 404 | 4xx (cliente) | Página eliminada, URL alterado sem redirecionamento, ligação quebrada | Página removida gradualmente do índice |
| 500 | 5xx (servidor) | Erro interno: script com falhas, configuração danificada | Redução da exploração de todo o site |
| 502 | 5xx (servidor) | Resposta inválida recebida pelo proxy ou gateway | Idem ao 500: exploração mais lenta |
| 503 | 5xx (servidor) | Servidor indisponível (manutenção, sobrecarga) | Exploração suspensa; as páginas indexadas podem ser removidas se o erro persistir |
O essencial a reter: um erro 5xx persistente pode levar à remoção de páginas já indexadas. Já um 404 isolado não tem consequências reais para o resto do site.
O Google esclarece que as respostas 5xx e 429 abrandam temporariamente os seus robôs de exploração. Se o problema persistir, o impacto estende-se aos outros URL do anfitrião. Um guia detalhado explica como corrigir um URL de servidor inválido, distinguindo com precisão cada família de códigos.
Erro em robots.txt: o caso que bloqueia a exploração completa de um site
Os concorrentes raramente abordam este cenário, embora seja o que pode causar os danos mais abrangentes. Uma resposta 5xx no ficheiro robots.txt suspende a exploração de todo o anfitrião. O Google tenta obter este ficheiro antes de cada sessão de rastreamento. Se receber um erro do servidor, prefere não explorar nada a correr o risco de aceder a páginas proibidas.
Por isso, o diagnóstico começa por este ficheiro. Verificar se está acessível demora apenas alguns segundos: basta fazer um pedido direto no navegador (votredomaine.com/robots.txt). Se a página devolver o código 200 e apresentar conteúdo legível, o problema está noutro local.
Quando o proxy oculta a verdadeira causa
Um erro 502 ou 504 em robots.txt pode ter origem num intermediário (reverse proxy, CDN), e não no servidor da aplicação. Para identificar a origem, é necessário analisar a comunicação entre o proxy e o servidor de origem. Os registos do proxy (Nginx, Varnish, Cloudflare) indicam se o pedido chegou ao servidor de origem ou se expirou pelo caminho.
Confundir um timeout do proxy com uma falha da aplicação leva a correções desnecessárias no código, quando o problema está na configuração da rede.
Detetar URL inválidos: métodos e ferramentas a combinar
Uma única ferramenta não é suficiente. Cada fonte cobre uma perspetiva diferente da deteção, e cruzar os dados ajuda a evitar pontos cegos.
- O relatório “Estatísticas de rastreamento” do Google Search Console mostra a frequência dos erros encontrados pelo Googlebot, o respetivo tipo (5xx, 404, timeout de DNS) e a sua evolução ao longo do tempo. É a perspetiva do motor de pesquisa.
- Os registos do servidor (access.log, error.log) fornecem os dados em bruto: endereço IP do cliente, URL pedido, código devolvido e hora exata. Permitem identificar picos de erros associados a uma implementação ou a uma sobrecarga.
- Um crawler como o Screaming Frog ou o Sitebulb percorre o site seguindo as ligações internas e assinala qualquer URL que devolva um código anómalo. Também deteta ligações quebradas na estrutura de links internos, invisíveis no Search Console.
Cruzar os dados do Search Console com os registos do servidor continua a ser o método mais fiável. O Search Console assinala os URL a que o Google não conseguiu aceder; os registos revelam porquê e quando o servidor devolveu o erro.
Erro de DNS ou timeout: como distinguir falsos positivos
Um problema de DNS não significa que o servidor esteja avariado. O servidor DNS pode estar temporariamente inacessível, mesmo que o site funcione normalmente. O Google assinala estes casos no Search Console como “Erro de DNS”. Antes de alterar qualquer elemento da aplicação, verificar a resolução de DNS com uma ferramenta como dig ou nslookup permite excluir esta hipótese.
Corrigir erros do servidor: definir prioridades de acordo com o código e a duração
Nem todos os erros exigem o mesmo nível de urgência. Um 503 temporário com um cabeçalho Retry-After é menos grave do que um 500 permanente numa página com muito tráfego orgânico.
Manutenção programada e cabeçalho Retry-After
A norma HTTP prevê que um servidor possa responder com 503 e incluir um cabeçalho Retry-After para indicar aos robôs quando devem voltar. Sem este cabeçalho, o Google trata o 503 como um incidente normal e abranda a exploração sem saber quando deve tentar novamente. Adicionar este cabeçalho durante uma manutenção programada limita as consequências para a indexação.
Redirecionamentos 301 para erros 404 recorrentes
Uma página eliminada que recebia ligações externas perde todo o seu valor de SEO se continuar a devolver 404. Um redirecionamento 301 para a página mais relevante transfere a maior parte dos sinais. Por outro lado, redirecionar todos os 404 para a página inicial é contraproducente: o Google acaba por ignorar estes redirecionamentos genéricos.
A seleção deve basear-se no cruzamento de dois dados: o número de ligações externas para o URL com erro (através do Search Console ou do Ahrefs) e o volume de tráfego que gerava antes de ser eliminado. Os URL sem ligações nem tráfego podem continuar a devolver 404 sem consequências.
A principal conclusão é esta: os erros 5xx persistentes afetam a exploração global do site, enquanto os erros 4xx se limitam à página em causa. Verificar a acessibilidade de robots.txt e cruzar os relatórios do Search Console com os registos do servidor são as duas verificações prioritárias a realizar perante qualquer incidente.
