Bloqueado devido a outro problema 4xx

TL;DR — “Bloqueado devido a outro problema 4xx” no Google Search Console é a categoria residual do Google para erros do cliente que não aparecem separados como 401, 403 ou 404. O Googlebot solicitou sua página e recebeu algum outro erro 4xx (como 400, 410 ou 451), por isso a página não pode ser indexada. O Google não publica uma lista exata dos códigos incluídos nessa categoria. Sua primeira tarefa é descobrir qual código está sendo retornado, pois a correção depende disso.

O que esse status significa

Essa categoria do Search Console abrange uma resposta 4xx que não é representada pelos tipos de problema mais específicos do relatório. Evidência desta afirmação The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Escopo: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confiança: alta · Verificado: 2026-07-14 Google: Page indexing report O Google trata respostas 4xx diferentes de 429 como conteúdo indisponível para indexação. Evidência desta afirmação Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Escopo: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confiança: alta · Verificado: 2026-07-14 Google: HTTP status codes

Quando você abre o relatório de Indexação de páginas no Search Console e vê “Bloqueado devido a outro problema 4xx”, isso significa que o Googlebot tentou buscar a URL e seu servidor respondeu com um erro 4xx do cliente, mas não com um dos códigos que o Google já separa em categorias próprias. O relatório tem linhas específicas para 401 (autenticação necessária), 403 (proibido) e 404 (não encontrado). A descrição do Google para esta linha é simplesmente “um erro 4xx não coberto por nenhum outro tipo de problema”; não existe um mapeamento exaustivo de todos os demais códigos. Na prática, 400, 405, 408, 410 Gone, 411, 413, 414, 421, 422 e 451 aparecem com frequência, mas trate-os como candidatos prováveis para investigação, não como uma lista garantida.

Como o Google recebeu um erro em vez da página, ele não consegue ler o conteúdo. Assim, a página não será indexada e, se já estivesse no índice, poderá ser removida.

O rótulo reúne casos diferentes — descubra o código real

É aqui que muita gente se confunde. “Outro 4xx” é uma categoria, não um diagnóstico. Um 410 Gone (você excluiu uma página deliberadamente) e um 400 Bad Request (uma URL inválida) podem aparecer na mesma linha, mas exigem ações opostas. Portanto, antes de “corrigir” qualquer coisa, descubra o código de status real:

• No Search Console, abra a Inspeção de URL e clique em Testar URL publicada para conferir o que o Google recebe agora.
• Abra a página na aba Network do DevTools e veja o código de status, ou busque-a pela linha de comando com curl -I.
• Consulte os logs do servidor para saber qual código o Googlebot realmente recebeu.

Isso é realmente um problema?

Às vezes, “outro 4xx” está funcionando como deveria. Um 410 Gone em uma página removida permanentemente é a resposta correta; só há algo a limpar se a URL ainda estiver em um sitemap ou continuar recebendo links internos. Porém, se uma página que você quer indexada retorna um 4xx inesperado, há um erro real a corrigir na origem.

Uma observação rápida sobre 429

Talvez você tenha lido que 429 (“solicitações demais”, ou seja, limitação de taxa) pertence a esta categoria. O Google trata 429 como um sinal de sobrecarga do servidor, não como um erro normal do cliente, e o utiliza para reduzir o ritmo de rastreamento em vez de remover imediatamente a página. A documentação do Google não informa em qual linha do relatório de Indexação de páginas uma URL com 429 aparece; portanto, também não presuma que ela esteja fora desta categoria. De todo modo, não desative uma limitação de taxa legítima para “corrigir” um status de outro 4xx — há mais detalhes na aba Avançado.

Quer o guia de correção código por código, a nuance do 429, a diferença entre 410 e 404 e a árvore de decisão de diagnóstico? Abra a aba Avançado.

TL;DR — “Bloqueado devido a outro problema 4xx” é a linha residual do relatório de Indexação de páginas: um 4xx recebido pelo Googlebot que não aparece separado como tipo próprio (401/403/404). O Google não publica um mapeamento exaustivo dos demais códigos para essa linha — 400, 405, 408, 410, 411, 413, 414, 421, 422, 451 etc. são ramificações de diagnóstico a verificar depois de conhecer o código real, não uma lista garantida. A regra do Google é que todos os 4xx, exceto 429, recebem o mesmo tratamento: o conteúdo é considerado inexistente, a página não é indexada e isso não afeta a taxa de rastreamento. O rótulo diz muito pouco, então o primeiro passo sempre é identificar o código real (teste ao vivo da Inspeção de URL → Estatísticas de rastreamento → reprodução do método original → correlação dos logs de servidor/CDN/WAF/aplicação), porque a resposta adequada a um 410 intencional é o oposto da resposta a um 400 ou 429. O mito a eliminar: 429 não é um 4xx normal — o Google o trata como erro do servidor (sobrecarga) e reduz o rastreamento, mas esse comportamento não prova qual rótulo do relatório a URL receberá. Não use 4xx para limitar o Googlebot; use 429 ou 503. Identifique → corrija a causa raiz (ou confirme que é intencional) → confirme um 200 no Teste ao vivo → clique em Validar correção. Isso torna a URL elegível para nova indexação, mas não garante que ela será indexada.

O que o Google realmente diz

O rótulo do relatório é uma categoria; inspecione a URL para determinar o código de status e a causa reais. Evidência desta afirmação The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Escopo: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confiança: alta · Verificado: 2026-07-14 Google: Page indexing report O comportamento HTTP é documentado separadamente da taxonomia do relatório. Evidência desta afirmação Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Escopo: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confiança: alta · Verificado: 2026-07-14 Google: HTTP status codes

A documentação do relatório de Indexação de páginas descreve esse status de forma direta: o servidor encontrou um erro 4xx não coberto por nenhum dos outros tipos de problema que o relatório separa, e a recomendação é depurar a página com a ferramenta de Inspeção de URL. Portanto, esta é, por definição, a categoria dos casos restantes: todo 4xx que não aparece em linha própria (401 Unauthorized, 403 Forbidden ou 404 Not Found). O Google não publica uma tabela exaustiva que associe os outros códigos 4xx a essa linha. Qualquer lista de “códigos que aparecem aqui”, inclusive a seguir, deve ser tratada como uma lista de candidatos observados com frequência, e não como uma classificação oficial e completa. Evidência desta afirmação The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Escopo: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confiança: alta · Verificado: 2026-07-14 Google: Page indexing report

O comportamento subjacente vem da documentação separada do Google sobre códigos de status HTTP. Uma regra governa quase toda esta página: todos os erros 4xx, exceto 429, recebem o mesmo tratamento. Os rastreadores do Google informam ao sistema de processamento seguinte que o conteúdo não existe. Para indexação, o resultado é o mesmo de um 404: a página é considerada inexistente e não será indexada (ou será removida, se já estiver no índice). E, o que é importante, códigos 4xx — novamente, exceto 429 — não afetam a taxa de rastreamento. Eles não fazem o Googlebot desacelerar; apenas retiram a página de consideração. A frequência de rastreamento de uma URL que falha continuamente pode cair naturalmente com o tempo, pois o Google continua sem encontrar conteúdo nela.

Quais códigos 4xx costumam aparecer aqui

A definição residual do Google não cita esses códigos individualmente. Estes são os casos encontrados na prática depois de confirmar o código real, com o que inspecionar e a inferência incorreta mais comum em cada um:

• 400 Bad Request — destino, sintaxe ou enquadramento de Host/roteamento da solicitação está malformado (muitas vezes, uma URL inválida ou codificada incorretamente). Inferência errada: “o código da página está quebrado”. Compare a solicitação exata que o servidor recebeu com a que deveria ter sido gerada.
• 405 Method Not Allowed — o método HTTP usado não é permitido nessa URL; a resposta deve incluir um cabeçalho Allow que informe os métodos permitidos. Inferência errada: uma falha em curl -I (HEAD) prova que o GET do Googlebot também falhou. Teste os dois métodos separadamente.
• 408 Request Timeout — a conexão ou solicitação não terminou a tempo. Inferência errada: “indisponibilidade genérica do servidor”. Correlacione os horários nas camadas de conexão, proxy e origem.
• 410 Gone — o recurso foi removido permanentemente. Muitas vezes é intencional; veja a seção específica abaixo.
• 411 Length Required — o servidor exige um cabeçalho Content-Length em uma solicitação que contém corpo. Isso é incomum em uma busca normal de página; confirme se a solicitação realmente tinha conteúdo e qual camada a rejeitou antes de alterar uma regra.
• 413 Payload Too Large — o conteúdo da solicitação excede um limite de tamanho. Confirme o corpo e os cabeçalhos recebidos, não o tamanho da própria página.
• 414 URI Too Long — a URI da solicitação excede um limite de comprimento. Geralmente é um problema na geração de parâmetros ou na cadeia de redirecionamentos, não no conteúdo da página.
• 415 / 422 (Unsupported Media Type / Unprocessable Entity) — o tipo de conteúdo ou as instruções da solicitação foram rejeitados. Assim como 411/413, esses códigos descrevem condições do conteúdo da solicitação e são atípicos em um GET simples de página. Não afrouxe a validação genericamente sem evidências da solicitação rejeitada.
• 421 Misdirected Request — a conexão foi direcionada de forma incorreta; o Google também documenta o retorno de 421 como uma maneira intencional de retirar uma rota do rastreamento por HTTP/2. Não presuma que a página está quebrada em todos os protocolos: confirme se o Google tentou novamente por HTTP/1.1 e qual foi a resposta final.
• 451 Unavailable For Legal Reasons — bloqueio por motivo jurídico ou de política. Encaminhe o caso ao responsável por essa análise, em vez de tratá-lo como uma configuração incorreta rotineira de localização geográfica ou WAF.
• 429 Too Many Requests — limitação de taxa. Este caso é especial; veja abaixo.

O objetivo desta lista não é decorá-la como verdade absoluta, mas oferecer um ponto de partida para o diagnóstico. Ainda é necessário consultar o código real e a camada que o produziu antes de escolher uma correção.

429 é a exceção — separe a semântica HTTP do rótulo do relatório

Muitos artigos de terceiros incluem 429 em “outro 4xx”. Isso mistura três perguntas diferentes: o que 429 significa em HTTP, como os rastreadores do Google o tratam e em qual linha do relatório de Indexação de páginas a URL aparece. As duas primeiras têm documentação; a terceira, não. Os rastreadores do Google tratam o código 429 como sinal de sobrecarga do servidor e o consideram um erro do servidor, não um erro normal do cliente. Na prática:

• Um 429 faz o Googlebot desacelerar em vez de remover imediatamente a página.
• Como ele é processado como erro do servidor, é plausível que um 429 apareça como problema de servidor/rastreamento em vez de “Bloqueado devido a outro problema 4xx”. Porém, a documentação descreve o processamento, não a taxonomia do relatório; portanto, considere a classificação não confirmada em vez de presumir que 429 não pode aparecer aqui.
• A ação errada é desativar uma limitação de taxa legítima para “corrigir” o status. Se o servidor está realmente sob carga, mantenha a limitação e envie um cabeçalho Retry-After. A RFC 6585 torna esse cabeçalho opcional em uma resposta 429. É uma boa prática HTTP, mas a documentação do Google analisada não afirma que o Googlebot agenda a próxima busca com base nesse valor. Envie-o mesmo assim, mas não o trate como uma instrução garantida. Como escrevi no meu guia de códigos de status HTTP da Ahrefs, “os 429 são um pouco especiais porque geralmente são tratados como erros do servidor e fazem o Google desacelerar o rastreamento. No entanto, com o tempo, o Google também removerá essas páginas do índice.” Portanto, 429 compra tempo; não mantém uma página indexada para sempre.

410 versus 404 — normalmente não é um problema

Um 410 Gone é o código intencional mais comum nesta categoria: você removeu uma página e quer que ela desapareça. As pessoas dão importância excessiva à diferença entre 410 e 404, mas ela é pequena na prática. A documentação de rastreamento do Google inclui 410 entre os códigos 4xx que recebem o mesmo tratamento de “conteúdo inexistente” aplicado a 404. Como escrevi no meu guia de códigos de status HTTP da Ahrefs, “404 e 410 recebem tratamento parecido. Ambos retiram páginas do índice, mas 410 é um pouco mais rápido.” John Mueller disse que a diferença é de poucos dias, no máximo, e que no médio e longo prazo o Google trata 404 e 410 da mesma maneira: ambos saem do índice. O fato de o Google listar 410 no tratamento geral dos 4xx não confirma, por si só, em qual linha do relatório ele será exibido. Se um 410 aparecer aqui, isso é coerente com o esperado, mas não uma certeza documentada. Se o 410 for intencional, ele está funcionando como planejado. Só intervenha se a página deveria estar disponível e confirme o status no Search Console em vez de inferi-lo apenas pelo código.

Por que isso acontece

A maioria dos casos reais de “outro 4xx” vem de uma destas causas:

• Regras de WAF, proteção contra bots ou CDN que retornam um 4xx incomum quando o padrão de solicitação do Googlebot aciona uma regra.
• Plugins de segurança (por exemplo, plugins de segurança do WordPress) que bloqueiam ou desafiam clientes que não parecem navegadores.
• Bloqueios por IP ou localização geográfica que atingem o Googlebot, cujo rastreamento parte principalmente de IPs dos Estados Unidos.
• Limitação de taxa agressiva que retorna um 4xx depois de N solicitações (nesse caso, a resposta deveria ser 429; veja abaixo).
• URLs malformadas (400), limites de tamanho da solicitação (413) ou falhas de validação (422) acionados pela forma como uma URL foi gerada ou vinculada.
• Remoções intencionais (410) que simplesmente não deveriam continuar no sitemap.

Uma causa frequente criada pelo próprio site é usar 4xx para limitar o Googlebot. O Google pediu a proprietários de sites e CDNs que parem de usar 404 e outros códigos 4xx para tentar reduzir a taxa de rastreamento. Isso não reduz o rastreamento; apenas remove conteúdo da Pesquisa. Para pedir que o Googlebot desacelere, retorne 500, 503 ou 429, não outro 4xx.

Como diagnosticar o código real

Siga esta sequência como uma árvore de decisão. Nenhuma ferramenta isolada garante que mostrará a falha exata; combine-as:

1. Inspeção de URL → Testar URL publicada. Confirma a disponibilidade atual: o Google recebe um 4xx agora ou a linha do relatório está desatualizada? Um teste ao vivo com falha nem sempre mostra os cabeçalhos brutos ou a linha de status; trate-o primeiro como verificação de disponibilidade, não como diagnóstico completo.
2. Relatório de Estatísticas de rastreamento. Mostra exemplos representativos das solicitações reais do Google (código de resposta, tempo de resposta e tipo de arquivo). Isso ajuda a confirmar o que um rastreamento agendado recebeu, pois o teste ao vivo usa o Google-InspectionTool, não o rastreador comum.
3. Reproduza a solicitação original. Abra a URL na aba Network do DevTools ou use curl. Se suspeitar de uma regra para bots, faça a solicitação com o user-agent do Googlebot e, de preferência, de fora da sua rede. Reproduza também o método: curl -I envia HEAD, que pode produzir resultado diferente do GET realmente usado pelo Google. Um 405 apenas em HEAD, por exemplo, não prova que GET falhou. Os comandos estão na aba Scripts.
4. Correlacione os logs do servidor, CDN, WAF, proxy de autenticação e aplicação. Normalmente, esse é o único lugar onde você encontrará o status exato, a camada que negou a solicitação e a regra ou condição acionada — principalmente quando o teste ao vivo não exibe cabeçalhos brutos.
5. Verifique a identidade do solicitante, separadamente da resposta. Um user-agent sozinho não prova que o Googlebot fez a solicitação. Confirme por DNS reverso e direto ou pelas faixas de IP publicadas pelo Google antes de decidir que o bloqueio está (ou não está) afetando um rastreador legítimo.
6. Associe o código à causa. 400/405/408/414 → problema de enquadramento, tempo ou URI. 411/413/415/422 → só diagnostique como problema de conteúdo da solicitação se houver evidências do método e corpo reais enviados pelo Google; esses códigos são incomuns em uma busca normal de página. 410 → remoção intencional (confirme que a URL deve sumir). 421 → verifique se é a saída de HTTP/2 documentada pelo Google e qual resposta veio no fallback HTTP/1.1. Um 4xx da camada de segurança → crie uma exceção apenas para o cliente e a rota verificados, nunca uma liberação ampla. Um possível 429 → limitação de taxa, tratada como carga do servidor, não como outro 4xx comum.

Como corrigir, código por código

• 400 / 405 / 408 / 414 (enquadramento, método, tempo ou comprimento da URI). Corrija a origem da solicitação malformada, URL inválida ou longa demais, método não permitido ou conexão lenta/incompleta na camada que realmente gera o problema. Compare a solicitação exata recebida pelo servidor com a que sua aplicação pretendia enviar.
• 411 / 413 / 415 / 422 (erros no conteúdo da solicitação). Esses códigos descrevem condições ligadas ao corpo, comprimento ou tipo de conteúdo da solicitação e são atípicos em um GET normal de página. Antes de afrouxar um limite ou regra de validação, confirme nos logs qual método e conteúdo acionaram a falha e qual camada os rejeitou. Não reduza limites de segurança de forma genérica sem essas evidências.
• 410 — é intencional? Se a página deveria ter desaparecido, o 410 está correto. Apenas remova a URL dos sitemaps e links internos para que deixe de aparecer como “problema”. Se a página deveria estar disponível, desfaça o 410.
• 421 — verifique se é uma saída intencional de HTTP/2. O Google documenta 421 como uma maneira de retirar uma rota do rastreamento por HTTP/2. Antes de tratar a página como quebrada, confirme se a solicitação voltou para HTTP/1.1 e qual foi a resposta final.
• 429 — limitação de taxa feita corretamente. Não elimine uma limitação legítima. Mantenha-a, adicione Retry-After como boa prática (é opcional pela especificação HTTP, e a documentação do Google não confirma que o Googlebot agenda o próximo rastreamento a partir dele) e lembre que o Google lê 429 como “desacelere”, não “remova do índice”. Se uma regra retorna outro 4xx apenas para limitar o Googlebot, troque-o por 429 ou 503.
• 451 — confirme primeiro o contexto jurídico ou de política. Encaminhe o caso ao responsável por decisões jurídicas ou de política de conteúdo antes de mudar a resposta.
• Bloqueios de WAF, CDN ou plugin de segurança. Identifique a camada e a regra que negam a solicitação. Crie uma exceção restrita para o Googlebot verificado — por DNS reverso ou faixas de IP publicadas, não por confiar no user-agent, que pode ser falsificado. Limite a exceção à rota e ao cliente pretendidos; não libere todas as solicitações de origem Google nem desative toda a regra de segurança. Corrija-a para que a URL retorne 200.

Não use 4xx para desacelerar o Googlebot

Vale repetir, pois essa é uma das principais causas de “outro 4xx” criadas pelo próprio site: retornar 4xx para limitar o Googlebot não funciona e remove conteúdo da Pesquisa. Como resumo no meu guia de códigos de status HTTP da Ahrefs, “erros 4xx fazem as páginas saírem do índice.” Se seu objetivo é reduzir o rastreamento, use 429 ou 503. Esses são os códigos que o Google interpreta como “volte mais tarde”, e o efeito é temporário.

Depois de corrigir

Depois de resolver a causa subjacente (ou confirmar que o 410 é intencional e limpar sitemaps e links):

1. Use Inspeção de URL → Testar URL publicada para confirmar que a resposta agora é 200.
2. Solicite a indexação das URLs prioritárias e/ou clique em Validar correção na linha “Bloqueado devido a outro problema 4xx” do relatório de Indexação de páginas.
3. Uma resposta 200 torna a URL elegível para o Google rastrear, processar e talvez indexar novamente depois de uma nova busca. Isso não garante a indexação nem um prazo. Não solicite indexação em massa antes de corrigir a causa raiz; você apenas colocaria as URLs de volta na mesma categoria.

Isso prejudica o SEO?

Somente quando páginas que você quer indexadas retornam 4xx. Elas saem do índice e perdem posições até que o problema seja corrigido. Se o 4xx for intencional — como um 410 em uma página excluída ou um bloqueio deliberado em uma área administrativa que não deveria estar no sitemap — ele funciona como planejado e não prejudica nada.

Os status relacionados que você deve conhecer são “Bloqueada devido a acesso proibido (403)” e “Bloqueada devido a solicitação não autorizada (401)”, que têm linhas específicas para firewall e autenticação, e “Não encontrada (404)”, que também tem sua própria categoria. Este status reúne os demais códigos da família 4xx. Para entender o relatório e como ele agrupa motivos de não indexação, consulte a visão geral do relatório de Indexação de páginas.

Resumo de IA

Uma síntese da versão Avançado:

• O que é. “Bloqueado devido a outro problema 4xx” no relatório de Indexação de páginas do GSC significa que o Googlebot recebeu um 4xx que não aparece separado como 401/403/404. O Google não publica uma lista exaustiva: 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 são candidatos comuns, não integrantes garantidos. A página não é indexada e pode ser removida se já estiver no índice.
• A regra principal. Todos os 4xx exceto 429 recebem o mesmo tratamento. O Google considera o conteúdo inexistente, como em um 404, e isso não afeta a taxa de rastreamento.
• O rótulo reúne casos diferentes. Ele não informa a causa. Descubra primeiro o código real: teste ao vivo da Inspeção de URL → Estatísticas de rastreamento → reprodução do método original → logs correlacionados de servidor/CDN/WAF. curl -I envia HEAD, não GET; portanto, teste ambos.
• 429 é a exceção e alimenta um mito comum. O Google trata 429 como erro do servidor (sobrecarga) e reduz o rastreamento em vez de remover imediatamente a página. Isso não confirma em qual linha do relatório a URL aparecerá. Mantenha limitações de taxa legítimas e envie Retry-After como boa prática — ele é opcional na especificação HTTP, e a documentação do Google não diz que o Googlebot agenda a próxima busca a partir do valor.
• 410 versus 404. 410 Gone é o código intencional comum neste conjunto. O Google o inclui no tratamento de “conteúdo inexistente” aplicado a 404, e a diferença prática de tempo é pequena. Se o 410 for intencional, ele funciona como planejado; confirme a intenção.
• 421 também pode ser intencional. O Google documenta 421 como forma de retirar uma rota do rastreamento por HTTP/2. Verifique o fallback HTTP/1.1 e a resposta final antes de presumir que a página está quebrada.
• Por que acontece. Bloqueios de WAF/CDN/plugin de segurança, bloqueios por IP/localização, regras de limitação, URLs malformadas ou longas demais (400/414), condições ligadas ao conteúdo da solicitação (411/413/415/422, que exigem evidência do corpo) ou remoções 410.
• Não limite com 4xx. Usar 404 ou outro 4xx para desacelerar o Googlebot remove conteúdo da Pesquisa. Use 429 ou 503.
• Corrija e valide. Identifique o código → corrija a causa raiz (ou confirme que é intencional e limpe sitemaps/links) → confirme 200 no Teste ao vivo → clique em Validar correção. Um 200 torna a URL elegível para nova indexação, mas não garante o resultado nem um prazo.

Documentação oficial

Documentação primária dos mecanismos de pesquisa.

Google

• Relatório de Indexação de páginas — o próprio relatório, incluindo a entrada “Bloqueado devido a outro problema 4xx” (um 4xx não coberto por nenhum outro tipo de problema) e as categorias relacionadas 401/403/404.
• Como os códigos de status HTTP e os erros de rede e DNS afetam a Pesquisa Google — a regra de que todos os 4xx, exceto 429, recebem o mesmo tratamento; que 429 é processado como sinal de sobrecarga do servidor; e que os demais 4xx não afetam a taxa de rastreamento.
• Don’t 404 my yum (blog da Central da Pesquisa, 2023) — o pedido do Google para que proprietários de sites e CDNs parem de usar 404 e outros 4xx para limitar o Googlebot, além dos códigos corretos para isso (500/503/429).
• Como confirmar se o Googlebot e outros rastreadores do Google são legítimos — DNS reverso e direto, além das faixas de IP publicadas, para liberar o Googlebot verdadeiro antes de alterar uma regra de WAF ou firewall.

Bing / Microsoft

• Bing Webmaster Tools — Controle de rastreamento — o Bing não usa o mesmo rótulo “outro 4xx” do Google, mas o princípio é igual: um 4xx significa que o Bingbot não conseguiu buscar conteúdo utilizável, então a URL não será indexada. Use o Controle de rastreamento para gerenciar a velocidade do Bingbot em vez de bloqueá-lo com códigos de erro.

Citações da fonte

Declarações registradas do Google e do meu próprio guia de códigos de status da Ahrefs, que escrevi e cujas palavras posso atribuir diretamente a mim. Cada link leva ao trecho citado na página de origem.

Google — como códigos 4xx (exceto 429) são tratados

• “Todos os erros 4xx, exceto 429, recebem o mesmo tratamento: os rastreadores do Google informam ao próximo sistema de processamento que o conteúdo não existe.” — documentação da Central da Pesquisa Google. Ir para a citação

Google — 429 é tratado como erro do servidor

• “Os rastreadores do Google tratam o código de status 429 como um sinal de que o servidor está sobrecarregado, e ele é considerado um erro do servidor.” — documentação da Central da Pesquisa Google. Ir para a citação

Google — não use 4xx para limitar a taxa de rastreamento

• “Os códigos de status 4xx, exceto 429, não afetam a taxa de rastreamento.” — documentação da Central da Pesquisa Google. Ir para a citação

John Mueller, Google — 410 versus 404 (paráfrase)

• John Mueller, do Google, descreveu a diferença entre 410 e 404 como pequena — poucos dias, no máximo — e disse que, no médio e longo prazo, o Google trata 404 e 410 da mesma forma: ambos saem do índice. A declaração foi noticiada pelo Search Engine Journal em Google Offers Advice on 404 and 410 Status Codes. (O texto está parafraseado enquanto aguarda uma verificação independente das palavras exatas; confirme a redação na fonte antes de citá-la literalmente.)

Patrick Stox (eu) — do meu guia de códigos de status na Ahrefs

• “Erros 4xx fazem as páginas saírem do índice.” — Patrick Stox, “HTTP Status Codes & Their SEO Impact”, Ahrefs. Ir para a citação
• “404 e 410 recebem tratamento parecido. Ambos retiram páginas do índice, mas 410 é um pouco mais rápido.” Ir para a citação
• “Os 429 são um pouco especiais porque geralmente são tratados como erros do servidor e fazem o Google desacelerar o rastreamento. No entanto, com o tempo, o Google também removerá essas páginas do índice.” Ir para a citação

Observação sobre Retry-After: a RFC 6585 permite, mas não exige, que uma resposta 429 inclua um cabeçalho Retry-After. Enviá-lo é uma prática razoável para qualquer cliente bem-comportado, mas a documentação do Google analisada para esta página não afirma que o Googlebot use esse valor como horário literal da próxima busca. Apresente-o como metadado opcional da resposta, não como instrução confirmada ao Googlebot.

Checklist para diagnosticar → corrigir → validar outro 4xx

Use esta lista em qualquer URL com “Bloqueado devido a outro problema 4xx”:

• Descubra primeiro o código real — Inspeção de URL → Testar URL publicada, Estatísticas de rastreamento para detalhes representativos da solicitação, aba Network do DevTools / curl (HEAD e GET) e logs correlacionados de servidor, CDN e WAF. O rótulo da categoria não é o diagnóstico, e o Google não publica um mapeamento completo de códigos para linhas do relatório.
• Confirme que o erro ainda está ativo — Testar URL publicada mostra um 4xx atual, não um registro antigo. Um teste ao vivo com falha pode não exibir os cabeçalhos brutos; confirme nos logs quando necessário.
• Classifique o caso. Erro de enquadramento, tempo ou URI (400/405/408/414)? Condição do conteúdo da solicitação que exige evidência do corpo (411/413/415/422)? Remoção intencional (410)? Possível saída de HTTP/2 (421)? Motivo jurídico ou de política (451)? Bloqueio de segurança? Um possível 429 (limitação de taxa)?
• Se for 410 Gone: a página deveria ter desaparecido? Se sim, está correto; apenas remova-a de sitemaps e links internos. Se não, restaure-a.
• Se for 421: confirme se é uma saída intencional de HTTP/2 e verifique o fallback HTTP/1.1 e a resposta final antes de tratá-lo como falha.
• Se for um erro de solicitação/enquadramento: corrija na origem a URL malformada ou longa demais, o método permitido ou o problema de conexão/tempo; pare de vincular ou listar a URL incorreta.
• Se for um erro de conteúdo da solicitação (411/413/415/422): confirme nos logs o método e o corpo reais antes de reduzir qualquer limite ou validação.
• Se for bloqueio de segurança/WAF/CDN: verifique o Googlebot real (DNS reverso ou faixas de IP publicadas) e crie uma exceção restrita por identidade/IP e rota, nunca apenas por user-agent nem como liberação ampla.
• Se a intenção for limitar o rastreamento: não use 4xx; retorne 429 ou 503 e adicione Retry-After como boa prática. Mantenha a limitação legítima e não presuma que esse cabeçalho agenda a próxima busca do Googlebot.
• Confirme um 200 — Testar URL publicada agora retorna 200 para as páginas que você quer indexadas.
• Valide — clique em Validar correção na linha de outro 4xx e/ou Solicitar indexação para URLs prioritárias. Isso torna a URL elegível para nova indexação, mas não a garante. Não faça solicitações em massa antes de corrigir a causa.

Modelos mentais

1. O rótulo é uma categoria, não um diagnóstico. “Outro 4xx” é a linha residual do Google para qualquer 4xx sem tipo próprio. O Google não publica a lista exata, embora 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 sejam candidatos comuns. O primeiro passo nunca é “corrigir”, mas perguntar “qual é o código real?” Tudo o que vem depois depende da resposta.

2. Para indexação, outro 4xx equivale a 404. O Google trata todos os 4xx, exceto 429, da mesma forma: considera que o conteúdo não existe. Seja qual for o código específico, o resultado é igual ao de um 404: a página não é indexada e é removida se já estivesse no índice. Isso também significa que o código não afeta a taxa de rastreamento.

3. 429 é erro do servidor, não do cliente — e sua posição no relatório é outra pergunta, ainda sem resposta confirmada. O Google interpreta 429 como “servidor sobrecarregado” e reduz o rastreamento em vez de remover imediatamente a página; isso está documentado. Não está documentado se uma URL com 429 aparece nesta linha específica. Não desative a limitação de taxa para fazê-la sumir: envie Retry-After como boa prática, sem presumir que o Googlebot o seguirá em um cronograma.

4. Intencional ou erro. Um 410 em uma página excluída ou um 421 usado para retirar a rota de HTTP/2 pode estar funcionando como planejado; um 400 em uma página que deveria ser indexada é uma falha. Pergunte “esta URL deveria estar disponível, e por qual protocolo?” antes de escolher uma correção. Se não deveria estar ativa, a solução é parar de listá-la em sitemaps e links, não fazê-la retornar 200.

5. 4xx é a forma errada de limitar. Se você quer desacelerar o Googlebot, 4xx não faz isso: ele remove a página do índice. Os códigos para “volte mais tarde” são 429 e 5xx/503. Escolha o código coerente com a intenção: “isto não existe” (4xx) ou “estou sobrecarregado, tente depois” (429/503).

Guia rápido de outros 4xx

Códigos que aparecem com frequência e a correção de cada um (O Google não publica uma lista exaustiva para esta linha. Use a tabela como ramificações de diagnóstico depois de descobrir o código real, não como uma garantia.)

Status relacionados no relatório de Indexação de páginas

Escolha o código certo para sua intenção

Descubra o código de status real

O rótulo do GSC não informa qual 4xx está ocorrendo; consulte-o diretamente. -I envia uma solicitação HEAD, não o GET que o Google usa para buscar uma página. Por isso, um resultado exclusivo de HEAD (por exemplo, 405) não prova qual é a resposta ao GET. Teste ambos.

macOS / Linux

# Somente HEAD — leia a linha de status (por exemplo, "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduz o método usado pelo Google para buscar o conteúdo da página
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# Se suspeitar de bloqueio específico para bots, faça um GET com o user-agent do Googlebot
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

Windows (PowerShell)

# Solicitação GET, igual ao método usado pelo Google para buscar o conteúdo da página
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Get `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Se o código for diferente entre HEAD e GET, ou entre uma solicitação normal e outra com user-agent do Googlebot, você encontrou uma regra específica para método ou bot. Um WAF mais sofisticado também pode avaliar IP, protocolo ou categoria do cliente, e não apenas o user-agent. Para reproduzir integralmente, teste de fora da sua rede e não presuma que trocar apenas o user-agent aciona a mesma regra aplicada ao tráfego real do Googlebot.

Confirme que um bot é realmente o Googlebot antes de liberá-lo

Se o 4xx vem de uma camada de segurança e você pretende liberar o rastreador, primeiro confirme que ele é o Googlebot. O user-agent é fácil de falsificar, e mudar somente essa string em um teste não reproduz o IP, a categoria de cliente, o protocolo nem o caminho pelas regras de borda usados pelo Google.

macOS / Linux

# 1) Faça o DNS reverso do IP dos logs — deve terminar em googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Resolva o hostname diretamente — ele deve voltar ao mesmo IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Se a resolução reversa não terminar em um domínio do Google ou a resolução direta não retornar o IP original, não é o Googlebot; não crie a exceção. Você também pode comparar o IP com as faixas publicadas pelo Google. Libere por identidade ou faixa de IP verificada, nunca somente pela string do user-agent.

Envie Retry-After em um 429 sem eliminar a limitação de taxa

Se uma URL realmente está sujeita à limitação de taxa, retorne 429 com Retry-After como boa prática HTTP, em vez de desativar a proteção ou retornar um 4xx comum. Retry-After é opcional pela RFC 6585, e a documentação do Google não confirma que o Googlebot agenda a próxima busca com base nesse valor. Trate os exemplos abaixo como pontos de partida e revise-os conforme a configuração e a política de segurança do seu servidor ou CDN.

Apache (.htaccess / configuração)

# Exemplo: em respostas limitadas, retorne 429 com Retry-After de uma hora
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx

# limit_req_status faz solicitações limitadas retornarem 429 em vez de 503
limit_req_status 429;
# adiciona a indicação Retry-After às respostas 429
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

Recursos que merecem seu tempo

Oficiais

• Relatório de Indexação de páginas (Google) — a entrada de outro 4xx e as categorias relacionadas 401/403/404.
• Como códigos de status HTTP afetam a Pesquisa Google — a regra para todos os 4xx exceto 429, a nuance de 429 como erro do servidor e o fato de que os demais 4xx não afetam a taxa de rastreamento.
• Don’t 404 my yum (Google, 2023) — não use 404 ou outro 4xx para limitar o Googlebot.
• Como confirmar o Googlebot (Google) — DNS reverso e faixas de IP publicadas.

Outros textos meus

• HTTP Status Codes & Their SEO Impact — meu guia completo sobre o significado de cada código para SEO, incluindo 4xx, 410 versus 404 e 429.
• The Beginner’s Guide to Technical SEO — onde erros de rastreamento e indexação como este se encaixam no contexto mais amplo.

De outras fontes

• r/TechSEO — comunidade para depurar rastreamento e indexação, inclusive casos de 4xx incomuns no GSC.
• Google warns against using 403 or 404 for crawl-rate limiting (Search Engine Land) — cobertura da orientação de Gary Illyes em “Don’t 404 my yum”; use 500/503/429.
• Google: 404 vs 410 status codes — differences are minimal (Search Engine Roundtable) — Mueller explica por que a diferença entre 410 e 404 é irrelevante na prática.
• Google Offers Advice on 404 and 410 Status Codes (Search Engine Journal) — fonte noticiada das declarações de Mueller sobre a velocidade de 410 e 404; confirme a redação na página antes de citá-la literalmente.
• How to Fix Blocked due to other 4xx issue (Onely) — roteiro passo a passo dos códigos comuns, além da auditoria de sitemap e links internos. Trate as afirmações sobre quais códigos pertencem à categoria como interpretação da fonte, não como taxonomia confirmada pelo Google.
• Blocked due to other 4xx issue (SEOTesting) — aborda análise de logs e monitoramento preventivo e também cita 422, 405, 413 e 414. Vale a mesma ressalva sobre a lista de códigos.

Como descobrir o código real por trás de “outro 4xx”

“Outro 4xx” reúne situações diferentes. O único primeiro passo útil é identificar qual código realmente está sendo retornado — é isso que significa seguir o diagnóstico como uma árvore de decisão. Confirme primeiro o código ao vivo e só então escolha o ramo da família correspondente, antes de alterar qualquer configuração.

Acompanhe o tamanho da categoria de outro 4xx, não apenas sua existência

O número que vale acompanhar é a quantidade de URLs na linha “Bloqueado devido a outro problema 4xx” do relatório de Indexação de páginas ao longo do tempo. Uma única captura não mostra se a correção funcionou nem se novos códigos problemáticos estão surgindo, principalmente porque a categoria mistura causas intencionais e acidentais.

Quantidade de URLs na categoria de outro 4xx ao longo do tempo

• Métrica — Quantidade de URLs em “Bloqueado devido a outro problema 4xx” no relatório de Indexação de páginas do GSC, acompanhada semanalmente e, de preferência, separada pelo código real depois de identificá-lo para cada URL.
• O que ela mostra — Se correções de solicitação ou validação (400/405/411/413/422) e exceções no WAF/CDN estão funcionando. Quando o código real é um 410 intencional, a contagem dessas URLs deve se estabilizar depois da remoção de sitemaps e links internos. Se continuar aumentando, provavelmente novas páginas removidas ainda estão recebendo links ou entrando em sitemaps por engano, e não surgiu um erro novo.
• Como obter — Relatório de Indexação de páginas do GSC filtrado para a linha de outro 4xx; confira algumas URLs com Inspeção de URL → Testar URL publicada para garantir que o relatório não mostra apenas uma captura desatualizada.
• Referência ou faixa realista — Não existe meta universal; ela depende de quantas URLs retornam 410 ou código semelhante intencionalmente. A referência honesta é zero outro 4xx entre URLs que deveriam ser indexadas e uma quantidade estável, sem crescimento, entre URLs removidas de propósito. Registre sua linha de base antes de julgar a tendência.
• Frequência — Semanal após uma correção, até a contagem estabilizar; depois, mensal como verificação de regressão, sobretudo se você usa um WAF/CDN cujas regras mudam independentemente dos seus deploys.

Runbook: identificar, corrigir e validar

O fluxo de trabalho de outro 4xx é o mesmo ciclo curto para cada URL desta categoria, independentemente do código específico. Comece sempre identificando o código real, pois os caminhos de correção divergem bastante a partir daí.

1. Confirme o código ao vivo. Execute Inspeção de URL → Testar URL publicada para confirmar que o Google recebe um 4xx agora e descobrir o que foi retornado. A linha do relatório pode estar desatualizada, e um teste ao vivo com falha nem sempre exibe cabeçalhos brutos. Compare com o relatório de Estatísticas de rastreamento para ver exemplos representativos do que o rastreador agendado recebeu.

2. Reproduza a solicitação original. Abra a URL na aba Network do DevTools ou use curl. Teste GET, não apenas curl -I, que envia HEAD e pode ter resultado diferente. Se suspeitar de regra específica para bots, busque com o user-agent do Googlebot e, idealmente, de fora da sua rede. Lembre-se de que trocar apenas o user-agent não reproduz o IP, protocolo ou categoria de cliente do Google.

3. Leia os logs. Consulte logs de servidor, CDN, WAF e proxy de autenticação para encontrar o código exato e a regra ou condição que o gerou. Geralmente isso é mais rápido do que adivinhar pelo navegador e pode ser a única forma de ver os dados brutos que o teste ao vivo não mostra.

4. Associe o código à causa. 400/405/408/414 → problema de enquadramento, método, tempo ou comprimento da URI. 411/413/415/422 → só diagnostique como conteúdo da solicitação quando houver evidência do método e corpo reais enviados pelo Google. 410 → remoção intencional; confirme que deveria sumir. 421 → verifique se é a saída de HTTP/2 documentada e o que o fallback HTTP/1.1 retornou. 451 → análise jurídica ou de política. 4xx da camada de segurança → bloqueio que deve receber exceção restrita. Possível 429 → limitação de taxa tratada como carga do servidor; sua classificação no relatório não está confirmada.

5. Corrija conforme a causa. Em erros de enquadramento, corrija na origem a URL inválida ou longa, o método errado ou o timeout e pare de listar a URL incorreta. Em erros de conteúdo da solicitação, confirme os dados nos logs antes de reduzir limites. Em 410 intencional ou saída 421, mantenha a resposta e apenas limpe sitemaps/links (410) ou confirme o fallback de protocolo (421). Encaminhe 451 para análise jurídica/de política. Em bloqueio de segurança, verifique o Googlebot real por DNS reverso ou faixas de IP e crie uma exceção restrita por identidade e rota, nunca por user-agent ou regra ampla. Em 429, mantenha a limitação e adicione Retry-After como boa prática — ele é opcional pela RFC 6585 e não constitui um cronograma confirmado do Googlebot. Se uma regra usa outro 4xx apenas para limitar, troque-o por 429 ou 503.

6. Valide e pare. Confirme que Testar URL publicada retorna 200 para páginas que devem ser indexadas. Depois clique em Validar correção na linha de outro 4xx e/ou solicite a indexação de URLs prioritárias. Um 200 torna a URL elegível para novo rastreamento e possível indexação; não garante o resultado nem um prazo. Não faça solicitações em massa antes de corrigir a causa, ou as URLs voltarão para a mesma categoria.

Prompts de IA prontos para usar

Copie estes prompts para classificar o código de outro 4xx e a correção apropriada a partir da saída bruta do diagnóstico. Sempre confirme a conclusão na configuração real do servidor ou WAF antes de mudar qualquer coisa.

Classifique o código e a causa pela saída do curl

Estou diagnosticando o status "Bloqueado devido a outro problema 4xx" no Google
Search Console. Abaixo está a saída bruta de solicitações GET e HEAD para a URL
(observe que curl -I testa apenas HEAD, que pode ser diferente do GET recebido pelo
Google). Informe o código exato e classifique a causa provável como: (1) problema
de enquadramento/timeout/comprimento da URI (400, 405, 408, 414); (2) condição do
conteúdo da solicitação que exige evidência do corpo (411, 413, 415, 422); (3) 410
Gone intencional; (4) possível saída de HTTP/2 (421); (5) bloqueio jurídico/de
política (451); (6) bloqueio de WAF/CDN/plugin de segurança; ou (7) limitação de
taxa 429 mal classificada. Explique qual detalhe da saída sustenta sua conclusão
e sinalize o que não pode ser determinado somente por esses dados.

SAÍDA DO CURL (GET e HEAD):
[cole aqui]

Classifique uma linha de log do WAF ou servidor

Estou investigando um status "outro 4xx" que o Googlebot recebe em uma página que
quero indexada. Abaixo estão uma ou mais linhas de log do servidor/CDN/WAF que
mostram a solicitação bloqueada. Diga se o caso parece uma regra de identidade do
bot (baseada em user-agent ou IP), uma limitação/desafio que deveria retornar 429,
ou um erro de solicitação/validação. Explique o que preciso alterar ou liberar para
corrigir sem desativar a proteção subjacente.

LINHAS DE LOG:
[cole aqui]

Revise uma correção antes do deploy

Estou prestes a mudar a resposta de uma URL porque ela retorna [código de status]
e aparece como "Bloqueado devido a outro problema 4xx" no Search Console. Esta é
a alteração planejada: [descreva]. Aponte qualquer risco ignorado — por exemplo,
se a mudança pode expor ou reindexar uma página que deveria continuar removida
(um 410 que estou prestes a desfazer), ou se devo liberar somente o Googlebot
verificado em vez de reduzir uma regra de segurança para todos.

Teste seus conhecimentos: “Bloqueado devido a outro problema 4xx”

Cinco perguntas sobre o significado da categoria de outro 4xx, a exceção 429 e como diagnosticar e corrigir o problema. Escolha uma resposta em cada uma e confira o resultado.

Ferramentas para diagnosticar e corrigir status de outro 4xx

• Verificador de status e redirecionamentos HTTP — cole a URL afetada, ou um lote, para confirmar o código real por trás do rótulo do GSC, ver toda a cadeia de respostas e encontrar redirecionamentos anteriores ao 4xx.
• Verificador do Googlebot — confira se um IP que se apresenta como Googlebot é legítimo, pelas faixas publicadas e pela confirmação de DNS reverso, antes de liberá-lo no WAF, CDN ou plugin de segurança.
• Google Search Console — Inspeção de URL → Testar URL publicada — a melhor forma de observar a resposta que o Google recebe agora, em vez de confiar apenas em uma linha possivelmente desatualizada do relatório.
• curl -I — a maneira mais rápida de ler a linha bruta de status de uma URL e buscá-la novamente com o user-agent do Googlebot se você suspeitar de regra específica para bots. Lembre-se de que a opção -I usa HEAD; também teste GET.
• Painel de logs do seu servidor, CDN ou WAF (Cloudflare, Akamai, Sucuri, log do plugin de segurança etc.) — encontre o código exato e a regra ou condição que o gerou.

Problemas comuns, por código

Cada código que aparece em outro 4xx representa uma combinação independente de sintoma, causa e correção. A categoria não tem uma única causa raiz; use os itens abaixo como cartões separados de consulta, não como uma sequência.

400 Bad Request

Sintoma: a URL afetada retorna 400 a uma solicitação.

Causas prováveis: destino ou sintaxe malformados, codificação incorreta ou problema no enquadramento de Host/roteamento que a aplicação ou borda rejeita imediatamente — por exemplo, parâmetros inválidos, caracteres incorretos ou rota inesperada.

Correção e verificação: compare a solicitação exata recebida pelo servidor com a que deveria ter sido gerada. Corrija a URL e pare de gerar ou vincular a versão inválida. Teste novamente com GET, e não apenas curl -I, que usa HEAD, até receber 200.

405 Method Not Allowed

Sintoma: a URL retorna 405 a algumas solicitações, embora pareça funcionar no navegador.

Causas prováveis: o método HTTP não é permitido para a rota. Pode haver uma regra no servidor ou CDN que aceita GET, mas rejeita HEAD ou outro método. Confira o cabeçalho Allow da resposta e não presuma que uma falha apenas em HEAD, como curl -I, prova que GET também falha.

Correção e verificação: permita o método correto para a rota e teste HEAD e GET.

408 Request Timeout

Sintoma: a URL retorna 408 de forma intermitente ou a conexão fica pendente antes de apresentar um status.

Causas prováveis: a conexão ou solicitação não terminou dentro do limite do servidor, proxy ou CDN. Isso indica problema de tempo ou conexão, não indisponibilidade genérica.

Correção e verificação: correlacione os tempos de conexão e solicitação entre proxy, CDN e origem e considere o protocolo usado. Teste novamente depois de ajustar o timeout relevante ou corrigir o caminho lento na origem.

410 Gone

Sintoma: a URL retorna 410, e a contagem de outro 4xx inclui páginas que provavelmente foram excluídas de propósito.

Causas prováveis: remoção intencional. Isso funciona como esperado para páginas que devem desaparecer. Se a página deveria estar ativa, o 410 é um erro.

Correção e verificação: se for intencional, remova a URL de sitemaps e links internos para que deixe de aparecer como “problema”. Caso contrário, restaure a página.

411 Length Required

Sintoma: a URL retorna 411 em determinadas solicitações.

Causas prováveis: o servidor exige Content-Length em uma solicitação que carrega corpo, algo incomum em um GET normal de página. Confirme nos logs que havia conteúdo antes de tratar o caso como falha rotineira de rastreamento.

Correção e verificação: confirme primeiro o método e o corpo reais. Corrija ou reduza a exigência no servidor, ou garanta que a solicitação contenha o cabeçalho. Depois, repita o teste com o mesmo método e conteúdo.

413 Payload Too Large

Sintoma: a URL retorna 413, geralmente em solicitações com corpo ou cabeçalhos e cookies grandes.

Causas prováveis: o conteúdo da solicitação excede um limite do servidor, CDN ou WAF. O problema está na solicitação recebida, não no tamanho da resposta da página.

Correção e verificação: confirme a solicitação nos logs antes de aumentar limites. Corrija o gerador da solicitação excessiva ou aumente o limite apenas se ele realmente for baixo demais para uma solicitação legítima. Confirme que uma solicitação normal retorna 200.

414 URI Too Long

Sintoma: a URL retorna 414, normalmente em uma URL gerada ou parametrizada muito longa.

Causas prováveis: a URI excede um limite, muitas vezes por erro na geração de parâmetros ou na cadeia de redirecionamentos, e não por causa do conteúdo da página.

Correção e verificação: corrija a geração da URL ou do redirecionamento na origem em vez de simplesmente aumentar o limite. Limpe sitemaps e links internos que apontem para o padrão excessivamente longo.

415 / 422 (tipo de mídia incompatível / entidade não processável)

Sintoma: a URL retorna 415 ou 422, embora a solicitação pareça bem formada no navegador.

Causas prováveis: o servidor entendeu a solicitação, mas rejeitou seu tipo de conteúdo ou uma regra de validação aplicada ao conteúdo ou às instruções. Isso é atípico em um GET simples; confirme o conteúdo real antes de concluir que há um problema genérico na página.

Correção e verificação: consulte a solicitação nos logs e então corrija a validação ou o tratamento do tipo de conteúdo, ou o sistema que gera a solicitação rejeitada. Teste novamente até receber 200.

421 Misdirected Request

Sintoma: a URL retorna 421, às vezes somente por HTTP/2.

Causas prováveis: a conexão foi direcionada de forma incorreta. O Google também documenta 421 como maneira intencional de retirar uma rota do rastreamento por HTTP/2; portanto, o código não significa automaticamente que a página está quebrada.

Correção e verificação: confirme se houve fallback para HTTP/1.1 e qual foi a resposta final. Uma saída deliberada de HTTP/2 não exige correção. Se não houver fallback e a página estiver inacessível por todos os protocolos, corrija o roteamento da conexão e o tratamento de SNI ou Host.

451 Unavailable For Legal Reasons

Sintoma: a URL retorna 451.

Causas prováveis: bloqueio jurídico ou de política, possivelmente intencional — por exemplo, conteúdo restrito em certas jurisdições. Não o trate como erro rotineiro de localização geográfica ou WAF.

Correção e verificação: encaminhe ao responsável pelas decisões jurídicas ou de política para confirmar a intenção. Se o bloqueio estiver correto, limpe sitemaps e links que apontam para a URL. Caso contrário, retire o bloqueio.

429 confundido com “outro 4xx”

Sintoma: você esperava um 4xx normal, mas o código real é 429.

Causas prováveis: limitação de taxa acionada pelas solicitações do Googlebot. O Google trata 429 como sinal de sobrecarga do servidor, não como erro do cliente. É plausível que o código apareça como problema de servidor/rastreamento em vez de permanecer rotulado como outro 4xx, mas a documentação cobre o processamento, não a taxonomia do relatório; portanto, a classificação exata continua sem confirmação.

Correção e verificação: não desative uma limitação legítima. Adicione Retry-After como boa prática — ele é opcional pela RFC 6585 e o Google não confirma que o Googlebot agenda a próxima busca a partir dele. Se uma regra retorna outro 4xx somente para limitar o Googlebot, troque-a por 429 ou 503.

Comprove que a correção realmente funcionou

Depois de corrigir o erro de solicitação ou validação, limpar um 410 intencional, liberar o Googlebot verificado ou confirmar que a limitação de taxa está correta, execute estes testes em ordem. Eles separam “a configuração mudou” de “o Google consegue acessar a página”.

Teste 1 — Uma nova solicitação retorna o status esperado

• Teste — Execute curl com uma solicitação GET na URL afetada, reproduzindo o método usado pelo Google. curl -I sozinho testa apenas HEAD. Você também pode usar o Verificador de status e redirecionamentos HTTP.
• Resultado esperado — Em uma página que deve ser indexada, a linha de status mostra HTTP/1.1 200 OK. Em uma página removida intencionalmente, manter 410 é aceitável; nesse caso, o teste decisivo é o Teste 3.
• Interpretação da falha — Se o 4xx original permanece, a correção não foi aplicada à rota ou você testa a URL/ambiente errado. Se outro 4xx apareceu — por exemplo, 400 virou 403 — você trocou um bloqueio por outro; confira a regra no WAF/CDN.
• Janela de monitoramento — Imediata; o servidor responde assim que a alteração entra no ar.
• Gatilho de rollback — Se reduzir uma regra de validação ou tamanho permitir um comportamento indesejado, restaure a regra e corrija a causa raiz de outra forma — por exemplo, corrija a solicitação em vez de aumentar o limite.

Teste 2 — O Google confirma que consegue acessar a página

• Teste — Execute Inspeção de URL → Testar URL publicada no Google Search Console.
• Resultado esperado — Para uma página que deve ser indexada, o teste ao vivo funciona e mostra 200, sem 4xx.
• Interpretação da falha — Se o teste ao vivo ainda apresenta 4xx depois que um curl anônimo funciona, suspeite de regra específica para faixas de IP do Googlebot — um problema de exceção no WAF/CDN — e não de falha geral da solicitação.
• Janela de monitoramento — Imediata ou poucos minutos depois da correção.
• Gatilho de rollback — Não se aplica; este é um teste somente leitura. Se falhar, volte ao ramo de falha do Teste 1 em vez de desfazer mudanças automaticamente.

Teste 3 — O status desaparece ou permanece estável de forma intencional no relatório

• Teste — Use Validar correção na linha “Bloqueado devido a outro problema 4xx” do relatório de Indexação de páginas e acompanhe a contagem nas semanas seguintes. Consulte também a aba Como medir.
• Resultado esperado — URLs corrigidas ficam elegíveis para sair da categoria depois que o Google rastrear novamente o 200. Isso não garante nova indexação nem um prazo. URLs com 410 intencional podem continuar na categoria, mas sitemaps e links internos deixam de apontar para elas.
• Interpretação da falha — Não existe frequência de nova tentativa publicada. Não interprete uma validação lenta como nova falha. Se a contagem de URLs corrigidas não cair após algumas semanas, repita o Teste 1 para confirmar que o ajuste ainda está ativo; um novo deploy ou cache de CDN pode reintroduzir silenciosamente a regra anterior.
• Janela de monitoramento — De alguns dias a poucas semanas, acompanhando a contagem.
• Gatilho de rollback — Só reavalie a correção subjacente se o Teste 1 voltar a falhar. Não persiga o ritmo de atualização do relatório de Indexação de páginas.

Registro de alterações