Bloqueado devido a outro problema 4xx

TL;DR — “Blocked due to other 4xx issue” (tradução) «Bloqueado devido a outro problema 4xx» no Google Search Console é a categoria residual do Google para erros de cliente que não aparecem separadamente 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 que entram aqui — sua primeira tarefa é descobrir qual código realmente ocorreu, porque a correção depende totalmente disso.

O que este status significa

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

Quando você abre o relatório Indexação de páginas no Search Console e vê “Blocked due to other 4xx issue” (tradução) «Bloqueado devido a outro problema 4xx», isso significa que o Googlebot tentou buscar a URL e o servidor respondeu com um erro de cliente 4xx — mas um que não corresponde às categorias específicas listadas pelo Google. 401 (login necessário), 403 (proibido) e 404 (não encontrado) têm suas próprias linhas. A formulação do Google para esta linha é simplesmente “um erro 4xx não coberto por nenhum outro tipo de problema”; não há um mapa exaustivo de todos os códigos que entram aqui. 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 investigar, não como uma garantia.

Como o Google recebeu um erro em vez da página, não consegue ler o conteúdo, então a página não será indexada — e, se já estava indexada, será removida.

O rótulo é uma categoria ampla — encontre o código real

Esta é a parte que confunde as pessoas. “Other 4xx” (tradução) «outro 4xx» é uma categoria, não um diagnóstico. Um 410 Gone (você excluiu uma página de propósito) e um 400 Bad Request (uma URL quebrada) podem aparecer na mesma linha, mas a resposta correta é oposta em cada caso. Antes de “corrigir” qualquer coisa, descubra o código de status real:

• No Search Console, use a Inspeção de URL e clique em Testar URL ao vivo para ver o que o Google está recebendo agora.
• Abra a página no navegador, em DevTools → aba Network, e observe o código de status; ou busque-a na 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, “other 4xx” está funcionando como pretendido. Um 410 Gone em uma página removida permanentemente é o comportamento correto — só é um problema se a página continua em um sitemap ou recebendo links quando não deveria. Mas, se uma página que você quer indexar retorna algum 4xx inesperado, há um erro real a corrigir na origem.

Uma palavra rápida sobre 429

Você pode ter lido que 429 (“too many requests” (tradução) «solicitações demais» — um limite de taxa) pertence a esta categoria. O Google trata 429 como sinal de sobrecarga do servidor, não como um erro de cliente comum, e o usa para desacelerar o rastreamento em vez de remover a página imediatamente. A documentação do Google não informa em qual linha do relatório de Indexação de páginas uma URL 429 aparece; portanto, não presuma que ela está excluída desta categoria. De qualquer forma, não desative a limitação de taxa para “corrigir” um status other-4xx — há mais detalhes na aba Avançado. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Quer o guia completo de correção por código, a nuance do 429, os detalhes de 410 versus 404 e a árvore de decisão de diagnóstico? Mude para a aba Avançado.

TL;DR — “Blocked due to other 4xx issue” (tradução) «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 foi separado como seu próprio tipo de problema (401/403/404). O Google não publica um mapa exaustivo de todos os códigos que entram nessa linha — 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 são caminhos de diagnóstico a verificar depois que você conhece o código real, não uma lista garantida. A regra do Google é: todos os 4xx, exceto 429, são tratados da mesma forma — o conteúdo é tratado como inexistente, a página não é indexada e não há efeito sobre a taxa de rastreamento. O rótulo informa quase nada; portanto, o primeiro passo é sempre identificar o código real (teste ao vivo da Inspeção de URL → Estatísticas de rastreamento → reproduzir o método original → logs correlacionados do servidor/CDN/WAF/aplicação), porque a correção de um 410 (remoção intencional) é oposta à correção de um 400 ou 429. O mito a eliminar: 429 não é um 4xx comum — o Google o trata como erro do servidor (sobrecarga) e desacelera o rastreamento, mas esse comportamento não prova em qual linha do relatório uma URL 429 aparece; trate a classificação como não confirmada. 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 Testar URL ao vivo → execute Validar correção, que torna a URL elegível para reindexação, mas não garante que ela será reindexada.

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. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report O comportamento HTTP é documentado separadamente da taxonomia do relatório. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

A documentação do relatório de Indexação de páginas do Google descreve este status de forma simples: o servidor encontrou um erro 4xx não coberto pelos outros tipos de problema que o relatório separa, e a recomendação é depurar a página usando a ferramenta de Inspeção de URL. Por definição, esta é a categoria do que sobrou — todo 4xx que não tem sua própria linha (401 não autorizado, 403 proibido, 404 não encontrado). O Google não publica uma tabela exaustiva que mapeie cada código restante para esta linha; trate qualquer lista de “códigos que aparecem aqui”, inclusive a lista abaixo, como candidatos observados com frequência, não como lista oficial completa. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

O comportamento vem da documentação separada do Google sobre códigos de status HTTP, e há uma regra central que governa quase tudo nesta página: todos os erros 4xx, exceto 429, são tratados da mesma forma — os rastreadores do Google informam ao próximo sistema de processamento que o conteúdo não existe. Para indexação, o resultado é igual ao de um 404: a página é tratada como inexistente e não será indexada (ou será removida se já estava). E, de forma importante, os códigos 4xx (novamente, exceto 429) não têm efeito sobre a taxa de rastreamento — não desaceleram o Googlebot; apenas tiram a página da consideração. A frequência de rastreamento de uma URL que falha continuamente pode diminuir naturalmente com o tempo, mas isso é diferente de limitar a taxa do site.

Quais códigos 4xx costumam aparecer aqui

A definição residual do Google não nomeia estes códigos individualmente — esta é a lista que aparece na prática depois que você confirma o código real. Veja o que investigar e a inferência errada mais comum em cada caso:

• 400 Bad Request — destino da solicitação, sintaxe ou enquadramento de Host/roteamento malformado (frequentemente uma URL quebrada ou mal codificada). Inferência errada: “o código da página está quebrado” — compare a solicitação exata recebida pelo servidor com o que sua aplicação pretendia gerar.
• 405 Method Not Allowed — o método HTTP usado não é permitido para a URL; a resposta deve trazer um cabeçalho Allow indicando o que é permitido. Inferência errada: uma falha de 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 a temporização na camada de conexão, proxy e origem.
• 410 Gone — o recurso foi removido permanentemente. Muitas vezes é intencional; veja a seção abaixo.
• 411 Length Required — o servidor exige um cabeçalho Content-Length em uma solicitação com corpo. É 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/cabeçalhos da solicitação recebida, não o tamanho da página.
• 414 URI Too Long — a URI da solicitação excede um limite de comprimento. Geralmente é um problema de parâmetros gerados ou cadeia de redirecionamento, não de 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. Como 411/413, são condições do conteúdo da solicitação e atípicas em um GET simples; não relaxe a validação sem evidência da solicitação rejeitada.
• 421 Misdirected Request — a conexão foi direcionada incorretamente; o Google também documenta 421 como forma intencional de retirar uma rota do rastreamento HTTP/2. Não presuma que a página está quebrada em todo protocolo — confirme se o Google tentou HTTP/1.1 e qual foi a resposta final.
• 451 Unavailable For Legal Reasons — bloqueio legal ou orientado por política. Encaminhe para quem é responsável pela revisão jurídica/política, em vez de tratá-lo como configuração comum de geo/WAF.
• 429 Too Many Requests — limite de taxa. Este é especial — veja abaixo.

A finalidade da lista não é decorá-la como um evangelho; é oferecer um conjunto inicial de caminhos de diagnóstico. Você ainda precisa consultar o código real e a camada que o produziu antes de escolher a correção.

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

Muitos textos de terceiros colocam 429 em “other 4xx”. Isso mistura três perguntas diferentes: o que o HTTP diz que 429 significa, como os rastreadores do Google realmente o tratam e em qual linha do relatório uma URL 429 é registrada. As duas primeiras respostas são documentadas; a terceira não. Os rastreadores do Google tratam o código de status 429 como sinal de que o servidor está sobrecarregado e o consideram um erro do servidor — não um erro normal do cliente. As consequências práticas são:

• Um 429 faz o Googlebot desacelerar, em vez de remover a página imediatamente.
• Como é tratado como erro do servidor, um 429 real pode ser reportado como problema de servidor/rastreamento, e não como “Blocked due to other 4xx issue” (tradução) «Bloqueado devido a outro problema 4xx» — mas a documentação do Google descreve o comportamento de processamento, não a taxonomia do relatório. Trate a classificação como não confirmada, sem presumir que a URL foi excluída desta categoria.
• O movimento errado é desativar a limitação de taxa legítima para “corrigir” um status other-4xx. Se o servidor está realmente sobrecarregado, mantenha o limite e envie um cabeçalho Retry-After — a RFC 6585 torna esse cabeçalho opcional em uma resposta 429. É uma boa prática HTTP para clientes bem-comportados, mas a documentação revisada do Google não diz que o Googlebot agenda o próximo rastreamento a partir desse valor. Envie-o como boa prática; não o trate como instrução garantida. Como escrevi no meu guia da Ahrefs sobre códigos de status HTTP, 429 é especial porque geralmente é tratado como erro do servidor e faz o Google desacelerar o rastreamento, mas o Google ainda pode remover essas páginas do índice depois.

410 vs. 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 se preocupam demais com 410 versus 404, mas a diferença prática é pequena. A documentação de rastreamento do Google coloca 410 entre os códigos 4xx que recebem o mesmo tratamento posterior de “o conteúdo não existe” que 404. Como escrevi no meu guia da Ahrefs sobre códigos de status HTTP, 404 e 410 têm tratamento semelhante: ambos removem 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 forma — ambos saem do índice. A presença de 410 na regra geral de 4xx não confirma por si só em qual linha do relatório uma URL 410 aparece. Se um 410 nesta categoria é intencional, está funcionando como projetado; só aja se a página deveria continuar no ar e confirme o status no Search Console.

Por que isso acontece

A maioria dos status “other 4xx” do mundo real vem de uma destas causas:

• Regras de WAF, proteção contra bots ou CDN retornando um 4xx incomum (muitas vezes diferente de um 403 claro) quando o padrão da solicitação do Googlebot aciona uma regra.
• Plugins de segurança (por exemplo, plugins de segurança do WordPress) bloqueando ou desafiando clientes que não parecem navegadores.
• Bloqueios de IP ou geográficos que capturam o Googlebot, que rastreia principalmente a partir dos EUA.
• Limitação de taxa agressiva que retorna 4xx depois de N solicitações (deveria retornar 429).
• 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 ainda não deveriam estar em um sitemap.

Uma fonte importante de problemas criados pelo próprio site é usar 4xx para limitar o Googlebot. O Google pediu que proprietários e CDNs parem de usar 404 e outros 4xx para tentar reduzir a taxa de rastreamento — isso não desacelera o rastreamento; apenas remove conteúdo da Busca. Se você precisa que o Googlebot recue, retorne 500, 503 ou 429, não um 4xx.

Como diagnosticar o código real

Trabalhe como uma árvore de decisão, de cima para baixo. Nenhuma ferramenta isolada garante expor a falha exata — encadeie-as:

1. Inspeção de URL → Testar URL ao vivo. Isso confirma a disponibilidade atual — o Google está recebendo um 4xx agora ou a linha do relatório está antiga? —, mas um teste ao vivo que falha nem sempre expõe os cabeçalhos brutos ou a linha de status. Use-o primeiro como verificação de disponibilidade, não como diagnóstico completo.
2. Relatório de Estatísticas de rastreamento. Traz exemplos representativos das solicitações reais do Google (código de resposta, tempo de resposta e tipo de arquivo), úteis para corroborar o que um rastreamento agendado viu, já que Testar URL 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, busque com o user-agent do Googlebot, idealmente fora da sua rede. Reproduza também o método: curl -I envia HEAD, que pode produzir resultado diferente do GET usado pelo Google (um 405 somente em HEAD não prova que GET falha). Os comandos estão na aba Scripts.
4. Leia logs correlacionados do servidor, CDN, WAF, proxy de autenticação e aplicação. Normalmente é o único lugar que mostra o status exato, a camada que negou e a regra ou condição que produziu a resposta — especialmente quando o teste ao vivo não expõe cabeçalhos brutos.
5. Verifique a identidade do solicitante separadamente da resposta. Uma string de user-agent não prova que a solicitação veio do Googlebot; confirme por DNS reverso + direto ou pelas faixas de IP publicadas pelo Google antes de decidir se o bloqueio atingiu um rastreador legítimo.
6. Associe o código à causa. 400/405/408/414 → problema de enquadramento, método, tempo limite ou URI. 411/413/415/422 → só diagnostique como problema do conteúdo da solicitação se houver evidência do método e do corpo reais. 410 → remoção intencional, confirme que deve desaparecer. 421 → confira se é a saída documentada do Google do HTTP/2 e o retorno do fallback HTTP/1.1. 4xx de uma camada de segurança → exceção restrita para o cliente e a rota verificados, não permissão ampla. Um possível 429 → limitação de taxa, trate como carga do servidor, não como 4xx. Evidence for this claim URL Inspection can confirm current availability and a failed Page fetch, but additional raw headers are only available for certain successful live-test states; exact failure-code diagnosis may require Crawl Stats request details plus CDN, WAF, origin, authentication-proxy, and application logs. Scope: site-level crawl requests Confidence: high · Verified: 2026-07-16 Crawl Stats report

Como corrigir, por código

• 400 / 405 / 408 / 414 (enquadramento da solicitação, método, temporização, comprimento da URI). Corrija a origem da solicitação malformada, da URL quebrada/longa demais, do método não permitido ou da conexão lenta/incompleta na camada que realmente a gera; compare a solicitação exata vista pelo servidor com o que a aplicação pretendia enviar.
• 411 / 413 / 415 / 422 (erros do conteúdo da solicitação). Esses códigos descrevem condições ligadas ao corpo, comprimento ou tipo de conteúdo da solicitação — incomuns em um GET normal de página. Antes de relaxar um limite ou regra de validação, confirme nos logs qual método e conteúdo acionaram o erro e qual camada o rejeitou; não afrouxe limites de segurança genericamente sem evidência.
• 410 — é intencional? Se a página deve desaparecer, o 410 está correto; remova-a dos sitemaps e links internos para que deixe de aparecer como “problema”. Se deveria estar no ar, o 410 é um erro a desfazer.
• 421 — confira se é uma saída intencional do HTTP/2. O Google documenta 421 como forma de retirar uma rota do rastreamento HTTP/2. Confirme se a solicitação caiu para HTTP/1.1 e qual foi a resposta final antes de tratar 421 como página quebrada.
• 429 — limite de taxa feito corretamente. Não desative 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 por esse valor) e lembre-se de que o Google lê 429 como “desacelere”, não como “desindexe”. Se uma regra gera 4xx no Googlebot apenas para limitar a velocidade, troque-a por 429 ou 503.
• 451 — confirme primeiro o contexto jurídico/político. Não trate como uma configuração comum de geo/WAF; encaminhe para quem cuida de decisões jurídicas ou de política de conteúdo antes de mudar a resposta.
• Bloqueios de WAF/CDN/plugin de segurança. Identifique primeiro a camada e a regra que negaram. Coloque o Googlebot verificado na lista de permissão por identidade DNS ou faixas de IP publicadas, não confiando na string de user-agent (que pode ser falsificada), e restrinja a exceção à rota e ao cliente pretendidos. Corrija a regra para a URL retornar 200.

Não use 4xx para desacelerar o Googlebot

Vale dizer isso isoladamente porque é uma causa frequente de “other 4xx” criado pelo próprio site: retornar códigos 4xx para limitar o Googlebot não funciona e remove conteúdo da Busca. Como resumo a regra no meu guia da Ahrefs sobre códigos de status HTTP, 4xx fazem páginas sair do índice. Se seu objetivo real é desacelerar o rastreamento, use 429 ou 503 — são os códigos que o Google interpreta como “volte depois”, e o efeito é temporário.

Depois de corrigir

Depois que a causa for resolvida (ou que você confirmar que o 410 é intencional e limpar o sitemap e os links):

1. Inspeção de URL → Testar URL ao vivo para confirmar que a resposta ao vivo agora é 200.
2. Solicite a indexação para URLs prioritárias e/ou clique em Validar correção na linha “Blocked due to other 4xx issue” (tradução) «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 possivelmente indexar novamente quando voltar a rastreá-la — não é garantia de indexação nem de prazo fixo. Não faça solicitações em massa antes de corrigir a causa raiz, ou você entrará na mesma categoria outra vez.

Isso prejudica o SEO?

Só se páginas que você realmente quer indexar estiverem retornando 4xx — elas saem do índice e perdem posições até a correção. Se o 4xx é intencional (um 410 em uma página excluída ou um bloqueio deliberado em um caminho administrativo que não deveria estar no sitemap), está funcionando como projetado e não causa dano.

Os status irmãos são “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» e “Blocked due to unauthorized request (401)” (tradução) «Bloqueado devido a solicitação não autorizada (401)», as linhas dedicadas a firewall e login; “Not found (404)” (tradução) «Não encontrado (404)» é outra categoria. Este status é todo o restante da família 4xx. Para o relatório e a forma 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 versão condensada do conteúdo Avançado:

• O que é. “Blocked due to other 4xx issue” (tradução) «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 foi separado como 401/403/404. O Google não publica uma lista exaustiva dos códigos que entram aqui — 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 são candidatos comuns para investigar, não uma lista garantida. A página não é indexada (e é removida se já era).
• A regra central. Todos os 4xx exceto 429 são tratados da mesma forma — o Google considera o conteúdo inexistente, como em um 404, sem efeito sobre a taxa de rastreamento.
• O rótulo é uma categoria ampla. Ele não informa a causa — encontre primeiro o código de status real (teste ao vivo da Inspeção de URL → Estatísticas de rastreamento → reproduza o método original → logs correlacionados do servidor/CDN/WAF; curl -I é HEAD, não GET, portanto teste os dois).
• 429 é a exceção e um mito comum. O Google trata 429 como erro do servidor (sobrecarga) e desacelera o rastreamento em vez de remover a página, mas esse comportamento não confirma em qual linha do relatório uma URL 429 aparece — trate a classificação como não confirmada. Mantenha a limitação legítima e envie Retry-After como boa prática (é opcional pela especificação HTTP; a documentação do Google não diz que o Googlebot agenda com base nele). Não desative a proteção para “corrigir” um status other-4xx.
• 410 versus 404. 410 (Gone) é o código intencional comum nesta categoria; o Google o agrupa no mesmo tratamento de “conteúdo inexistente” de 404, e a diferença prática de tempo é pequena. Se 410 é intencional, está funcionando como projetado — confirme a intenção antes de mexer.
• 421 também pode ser intencional. O Google documenta 421 como uma forma de retirar uma rota do rastreamento 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 de IP/país, regras de limitação de taxa, URLs malformadas ou longas demais (400/414), condições do conteúdo da solicitação (411/413/415/422 — exigem evidência do corpo real) e remoções intencionais (410).
• Não limite com 4xx. Usar 404/other-4xx para desacelerar o Googlebot remove conteúdo da Busca — use 429 ou 503.
• Corrija e valide. Identifique o código (não pare em um teste ao vivo falho — consulte Estatísticas de rastreamento e logs correlacionados) → corrija a causa raiz ou confirme que é intencional e limpe sitemaps/links → confirme 200 no Testar URL ao vivo → execute Validar correção. 200 torna a URL elegível para reindexação; não garante a reindexação nem um prazo específico.

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca.

Google

• Relatório de indexação de páginas — o relatório em si, incluindo a linha “Blocked due to other 4xx issue” (tradução) «Bloqueado devido a outro problema 4xx» (um 4xx não coberto por outro tipo de problema) e as linhas irmãs 401/403/404.
• Como códigos de status HTTP e erros de rede e DNS afetam a Pesquisa Google — a regra de que todos os 4xx, exceto 429, são tratados da mesma forma, que 429 é sinal de sobrecarga do servidor e que 4xx (exceto 429) não afeta a taxa de rastreamento.
• Don’t 404 my yum (blog Search Central, 2023) — o pedido do Google para que sites e CDNs parem de usar 404 e outros 4xx para limitar o Googlebot e usem 500/503/429.
• Verificação do Googlebot e de outros rastreadores — DNS reverso + direto e faixas de IP publicadas, para liberar o Googlebot real antes de mudar uma regra de WAF/firewall.

Bing / Microsoft

• Bing Webmaster Tools — Controle de rastreamento — o Bing não usa o rótulo exato “other 4xx” do Google, mas o princípio é o mesmo: um 4xx significa que o Bingbot não conseguiu buscar conteúdo utilizável, portanto a URL não será indexada. Use 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 da Ahrefs sobre códigos de status, que escrevi e posso apresentar como minhas próprias palavras. Cada link é profundo e salta para a passagem citada na página de origem.

Google — como 4xx (exceto 429) é tratado

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (tradução) «Todos os erros 4xx, exceto 429, são tratados da mesma forma: os rastreadores do Google informam ao próximo sistema de processamento que o conteúdo não existe.» — documentação do Google Search Central. Ir para a citação

Google — 429 é tratado como erro do servidor

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tradução) «Os rastreadores do Google tratam o código de status 429 como sinal de que o servidor está sobrecarregado, e ele é considerado um erro do servidor.» — documentação do Google Search Central. Ir para a citação

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

• “The 4xx status codes, except 429, have no effect on crawl rate.” (tradução) «Os códigos de status 4xx, exceto 429, não têm efeito sobre a taxa de rastreamento.» — documentação do Google Search Central. 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 — no máximo da ordem de alguns dias — e disse que, no médio e longo prazo, o Google trata 404 e 410 da mesma forma: ambos saem do índice. A observação foi relatada na cobertura do Search Engine Journal: Google Offers Advice on 404 and 410 Status Codes (SEJ). (Parafraseado aqui, não citado literalmente, enquanto aguarda uma verificação independente da formulação exata nesta rodada — confirme a fonte antes de citar diretamente.)

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

• “4xxs will cause pages to drop from the index.” (tradução) «4xx fazem páginas sair do índice.» — Patrick Stox, “HTTP Status Codes & Their SEO Impact”, Ahrefs. Ir para a citação
• “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (tradução) «404 e 410 têm tratamento semelhante. Ambos removem páginas do índice, mas 410 é um pouco mais rápido.» Ir para a citação
• “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (tradução) «429 é um pouco especial porque geralmente é tratado como erro do servidor e faz o Google desacelerar o rastreamento. Mas, eventualmente, 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 revisada para esta página não diz que o Googlebot usa esse valor como programação literal do próximo rastreamento — apresente-o como metadado opcional da resposta, não como instrução confirmada para o Googlebot.

Lista de verificação: diagnosticar → corrigir → validar outro-4xx

Use esta lista em qualquer URL que mostre “Blocked due to other 4xx issue” (tradução) «Bloqueado devido a outro problema 4xx»:

• Encontre primeiro o código real — Inspeção de URL → Testar URL ao vivo, Estatísticas de rastreamento para detalhes representativos, além da aba Network do DevTools/curl (HEAD e GET) e logs correlacionados do servidor/CDN/WAF. O rótulo da categoria não é o diagnóstico, e o Google não publica um mapa completo de código para linha.
• Confirme que está ao vivo, não antigo — Testar URL ao vivo mostra um 4xx atual, não um relatório antigo; um teste ao vivo falho pode não expor cabeçalhos brutos, então corrobore nos logs.
• Classifique o caso. Erro de enquadramento/temporização/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)? Saída possível do HTTP/2 (421)? Questão jurídica/política (451)? Bloqueio de camada de segurança? Possível 429 (limite de taxa)?
• Se for 410 (Gone): a página deveria ter desaparecido? Se sim, está correto — apenas remova-a dos sitemaps e links internos. Se não, restaure a página.
• Se for 421: confirme se é uma saída intencional do HTTP/2 e verifique o fallback HTTP/1.1 e a resposta final antes de tratá-lo como quebrado.
• Se for erro de solicitação/enquadramento: corrija a URL malformada ou longa demais, o método permitido ou o problema de tempo limite/conexão na origem; pare de vincular/listar a URL ruim.
• Se for erro de conteúdo da solicitação (411/413/415/422): confirme o método e o corpo reais nos logs antes de relaxar limite ou regra de validação.
• Se for bloqueio de segurança/WAF/CDN: verifique o Googlebot real (DNS reverso ou faixas de IP publicadas) e então libere de forma restrita por identidade/IP e rota — não por user-agent e não com permissão ampla.
• Se for limitação de taxa: não use 4xx — retorne 429 ou 503 e adicione Retry-After como boa prática. Mantenha a limitação legítima; não presuma que o próximo rastreamento do Googlebot será agendado por esse cabeçalho.
• Confirme 200 — Testar URL ao vivo agora retorna 200 para as páginas que você quer indexar.
• Valide — clique em Validar correção na linha other-4xx e/ou em Solicitar indexação para URLs prioritárias. Isso torna a URL elegível, não garante a indexação; não solicite em massa antes de corrigir a causa.

Os modelos mentais

1. O rótulo é uma categoria, não um diagnóstico. “Other 4xx” (tradução) «outro 4xx» é a linha residual do Google para qualquer 4xx que não tenha sido separado em seu próprio tipo de problema. O Google não publica a lista exata do que entra aqui, embora 400, 405, 408, 410, 411, 413, 414, 421, 422 e 451 sejam candidatos comuns. O primeiro passo nunca é “corrigir”; é perguntar “qual código ocorreu de verdade?” Todo o restante depende dessa resposta.

2. Para indexação, other-4xx = 404. O Google trata todos os 4xx, exceto 429, da mesma forma: o conteúdo é tratado como se não existisse. Portanto, qualquer que seja o código específico, o resultado de indexação é igual ao de 404 — não indexado e removido se já estava no índice. Isso também significa nenhum efeito sobre a taxa de rastreamento.

3. 429 é erro do servidor, não erro do cliente — e sua posição no relatório é uma pergunta separada e não confirmada. O Google interpreta 429 como “servidor sobrecarregado” e desacelera em vez de remover a página; isso é documentado. A documentação não confirma em qual linha específica do relatório uma URL 429 aparece, portanto não trate essa classificação como resolvida. Não desative a limitação para fazer o problema desaparecer; envie Retry-After como boa prática, sem presumir que o Googlebot o segue em um cronograma.

4. Intenção versus erro. Um 410 em uma página excluída ou um 421 que tira uma rota do HTTP/2 podem estar funcionando como projetados; um 400 em uma página que você quer indexar é um problema. Pergunte “esta URL deveria estar no ar e em qual protocolo?” antes de procurar uma correção — se ela não deveria estar no ar, pare de listá-la (sitemaps e links), em vez de transformá-la em 200.

5. 4xx é o limitador errado. Se seu objetivo é desacelerar o Googlebot, 4xx não faz isso — desindexa. Os códigos de “volte depois” são 429 e 5xx/503. Escolha o código que corresponde à intenção: “isto desapareceu” (4xx) versus “estou sobrecarregado, tente depois” (429/503).

Folha de consulta do other-4xx

Códigos que aparecem com frequência aqui — e a correção de cada um (O Google não publica uma lista exaustiva de pertencimento para esta linha; trate a tabela como caminhos de diagnóstico a verificar depois que você souber o código real, não como garantia.)

Os status irmãos em Indexação de páginas

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

Encontre o código de status real

O rótulo do GSC não informa com qual 4xx você está lidando — verifique diretamente. -I envia uma solicitação HEAD, não o GET que o Google realmente usa para buscar uma página; portanto, um resultado apenas de HEAD (por exemplo, 405) não prova o que o GET retorna — teste os dois métodos.

macOS / Linux

# HEAD only — read the status line (e.g. "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduces the method Google actually uses to fetch page content
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# If you suspect a bot-specific block, fetch as Googlebot's user-agent (GET)
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)

# GET request, matching what Google actually uses to fetch page content
$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 uma solicitação com o user-agent do Googlebot, você encontrou uma regra específica do método ou do bot. Um WAF sofisticado também pode usar IP, protocolo ou categoria do cliente, em vez de apenas o user-agent; para uma reprodução completa, teste de fora da sua própria rede e não presuma que uma correspondência de user-agent, sozinha, prove que a mesma regra se aplica ao Googlebot real.

Verifique se um bot é realmente o Googlebot (antes de colocá-lo na lista de permissões)

Se o 4xx vier de uma camada de segurança e você estiver prestes a liberar o rastreador, confirme primeiro que ele é realmente o Googlebot — o user-agent é trivialmente falsificável, e trocar apenas o user-agent em uma solicitação de teste não reproduz o IP de origem, a categoria do cliente, o protocolo nem o caminho da regra de borda reais do Google.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same 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 consulta reversa não terminar em um domínio do Google, ou se a consulta direta não corresponder ao IP original, não é o Googlebot — não o coloque na lista de permissões. Você também pode comparar o IP com as faixas publicadas pelo Google (googlebot.json). Faça a permissão por identidade/faixa de IP verificada, nunca apenas pela string do user-agent.

Envie Retry-After para um 429 (sem desativar a limitação de taxa)

Se uma URL estiver realmente limitada por taxa, retorne 429 com Retry-After como boa prática HTTP — em vez de desativar a proteção ou retornar um 4xx “real”. Retry-After é opcional pela RFC 6585, e a documentação do Google não confirma que o Googlebot agenda o próximo rastreamento a partir desse valor; trate-o como higiene razoável, não como correção comprovada. Os trechos abaixo são pontos de partida ilustrativos — revise-os contra sua configuração de servidor/CDN e sua política de segurança antes de implantar.

Apache (.htaccess / config)

# Example: return 429 with a 1-hour Retry-After for rate-limited responses
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx

# limit_req_status makes throttled requests return 429 instead of 503
limit_req_status 429;
# add a Retry-After hint on 429 responses
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

Recursos que valem seu tempo

Oficial

• Relatório de indexação de páginas (Google) — a entrada “outro 4xx” e as categorias irmãs 401/403/404.
• Como os códigos de status HTTP afetam a Pesquisa Google — a regra de que todos os 4xx, exceto 429, recebem o mesmo tratamento, a nuance de 429 como erro do servidor e a ausência de efeito sobre a taxa de rastreamento.
• Don’t 404 my yum (Google, 2023) — não use 404/outros 4xx para limitar o rastreamento do Googlebot.
• Verificação do Googlebot (Google) — DNS reverso e faixas de IP publicadas.

Meus textos relacionados

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

De outras fontes

• r/TechSEO — comunidade para depuração de rastreamento e indexação, incluindo discussões sobre “4xx estranho no GSC”.
• Google warns against using 403 or 404 for crawl-rate limiting (Search Engine Land) — cobertura da orientação de Gary Illyes, “Don’t 404 my yum”; use 500/503/429.
• Google: 404 vs 410 status codes — differences are minimal (Search Engine Roundtable) — comentário de Mueller sobre por que a diferença entre 410 e 404 é pequena na prática.
• Google Offers Advice on 404 and 410 Status Codes (Search Engine Journal) — fonte reportada das observações de Mueller sobre a velocidade relativa de 410 e 404; confirme a formulação exata na página ao vivo antes de citá-la diretamente.
• How to Fix Blocked due to other 4xx issue (Onely) — passo a passo dos códigos comuns, útil para auditorias de sitemap e links internos. Trate as afirmações específicas sobre pertencimento de códigos como a interpretação dessa fonte, não como taxonomia confirmada do Google.
• Blocked due to other 4xx issue (SEOTesting) — análise de logs do servidor e monitoramento preventivo; também menciona 422, 405, 413 e 414. Vale a mesma ressalva sobre a pertença dos códigos.

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

“Outro 4xx” é uma categoria abrangente, então o primeiro passo útil é identificar qual código está realmente sendo retornado — é isso que a seção de diagnóstico do artigo quer dizer com “trabalhe como uma árvore de decisão, de cima para baixo”. Confirme primeiro o código ao vivo; depois escolha o ramo da família correspondente antes de tocar em qualquer configuração.

Acompanhe a categoria “outro 4xx”, não apenas sua existência

O único número que vale acompanhar é quantas URLs ficam na linha “Bloqueado devido a outro problema 4xx” do relatório de Indexação de páginas ao longo do tempo — uma fotografia isolada não mostra se uma correção funcionou ou se novos códigos problemáticos estão surgindo, especialmente porque essa categoria mistura causas intencionais e acidentais.

Contagem da categoria outro-4xx ao longo do tempo

• Métrica — A contagem de URLs na linha “Bloqueado devido a outro problema 4xx” do relatório de Indexação de páginas do GSC, acompanhada semana a semana, de preferência separada pelo código de status real depois que ele for identificado em cada URL.
• O que ela informa — Se as correções de solicitação/validação (400/405/411/413/422) e a permissão em WAF/CDN estão realmente surtindo efeito. Para URLs cujo código real é um 410 intencional, a contagem dessas URLs deve ficar estável depois que você limpar sitemaps e links internos — uma alta normalmente significa que novas páginas removidas continuam sendo vinculadas ou incluídas em sitemaps por engano, não um erro novo.
• Como obter — Relatório de Indexação de páginas do GSC, filtrado pela linha “outro 4xx”; verifique algumas URLs individualmente com Inspeção de URL → Testar URL ao vivo para confirmar que o relatório não mostra uma fotografia antiga.
• Referência/intervalo realista — Não existe meta universal — isso depende inteiramente de quantas URLs você retorna intencionalmente com 410 (ou código semelhante). O parâmetro honesto é zero outros 4xx entre URLs que você quer indexar e uma contagem estável (não crescente) para URLs removidas de propósito. Estabeleça sua própria linha de base antes de julgar a direção da tendência.
• Periodicidade — Semanalmente logo após uma correção, até a contagem estabilizar; depois, mensalmente como verificação de regressão, sobretudo se você depende de um WAF/CDN cujas regras podem mudar independentemente dos seus deploys.

Runbook: identificar, corrigir e validar

O fluxo de trabalho para “outro 4xx” é o mesmo ciclo curto para cada URL dessa categoria, independentemente do código específico por trás dela — identifique primeiro o código real, porque a correção muda completamente a partir daí.

1. Confirme o código ao vivo. Execute Inspeção de URL → Testar URL ao vivo para confirmar que o Google está recebendo um 4xx agora e ver o que recebeu — a linha do relatório, sozinha, pode estar desatualizada, e um teste ao vivo com falha nem sempre expõe os cabeçalhos brutos. Cruze o resultado com o relatório de Estatísticas de rastreamento para obter exemplos representativos do que o rastreador programado realmente recebeu.

2. Reproduza o caso, correspondendo à solicitação original. Abra a URL na aba Network do DevTools ou use curl — teste o método GET, não apenas curl -I (que envia HEAD e pode produzir um resultado diferente). Se suspeitar de uma regra específica para bots, busque a URL com o user-agent do Googlebot e, idealmente, de fora da sua própria rede, para acionar a mesma regra que um rastreamento real atingiria — mas lembre-se de que trocar apenas o user-agent não reproduz o IP, o protocolo nem a categoria do cliente reais do Google.

3. Leia os logs. Verifique os logs do servidor, CDN, WAF e proxy de autenticação em busca do código exato e da regra ou condição que o produziu — isso costuma ser mais rápido do que adivinhar apenas pelo navegador e muitas vezes é a única forma de ver os dados brutos da resposta que o teste ao vivo não expõe.

4. Relacione o código à causa. 400/405/408/414 → problema de enquadramento da solicitação, método, tempo limite ou comprimento da URI. 411/413/415/422 → só diagnostique como problema do conteúdo da solicitação com evidência do método/corpo reais enviados pelo Google. 410 → remoção intencional (confirme que deve desaparecer). 421 → verifique se é a saída documentada pelo Google para HTTP/2 e qual resposta o fallback HTTP/1.1 retornou. 451 → revisão jurídica/política. 4xx de uma camada de segurança → bloqueio a ser liberado de forma restrita. Um possível 429 → limitação de taxa, tratada como carga do servidor — a posição no relatório não está confirmada em nenhum dos sentidos.

5. Corrija pela causa. Erros de enquadramento da solicitação → corrija a origem (URL incorreta ou longa demais, método errado, tempo limite) e pare de vincular/listar a URL ruim. Erros de conteúdo da solicitação → confirme a solicitação real nos logs antes de flexibilizar qualquer limite. 410 ou saída intencional 421 → deixe como está e apenas limpe sitemaps e links internos (410) ou confirme o fallback de protocolo (421). 451 → encaminhe para revisão jurídica/política. Bloqueio de camada de segurança → verifique o Googlebot real (DNS reverso ou faixas de IP publicadas) e libere de forma restrita por identidade e rota, nunca por user-agent ou regra ampla. 429/limitação de taxa → mantenha a limitação, adicione Retry-After como boa prática (opcional pela RFC 6585; não é um agendamento confirmado do Googlebot); se uma regra estiver retornando 4xx ao Googlebot apenas para limitá-lo, troque-a para 429 ou 503.

6. Valide e pare. Confirme que Testar URL ao vivo agora retorna 200 para as páginas que você quer indexar; depois clique em Validar correção na linha “outro 4xx” e/ou solicite a indexação das URLs prioritárias. Uma resposta 200 torna a URL elegível para o Google rastrear novamente e possivelmente reindexar — não é garantia nem tem prazo fixo —, portanto não faça solicitações em massa antes de corrigir a causa raiz, ou você apenas voltará à mesma categoria.

Prompts de IA prontos para usar

Prompts para copiar e colar, a fim de classificar qual código “outro 4xx” você está vendo e qual correção se aplica a partir de uma saída de diagnóstico bruta. Sempre confirme a conclusão na configuração real do seu servidor/WAF antes de alterar qualquer coisa.

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

I'm diagnosing a "Blocked due to other 4xx issue" status in Google Search
Console. Below is the raw output of GET and HEAD requests to the URL (note
that curl -I alone only tests HEAD, which can differ from what Google's GET
request receives). Tell me the exact status code, and classify the likely
cause as one of: (1) a request-framing/timeout/URI-length issue (400, 405,
408, 414), (2) a request-content condition needing body evidence (411, 413,
415, 422), (3) an intentional 410 Gone, (4) a possible HTTP/2 opt-out (421),
(5) a legal/policy block (451), (6) a WAF/CDN/security-plugin block, or (7) a
mislabeled 429 rate limit. Explain which detail in the output pointed you to
that answer, and flag anything you can't determine from this output alone.

CURL OUTPUT (GET and HEAD):
[paste]

Classifique uma linha de log do WAF/servidor

I'm investigating an "other 4xx" status Googlebot is hitting on a page I want
indexed. Below is a log line (or a few) from my server/CDN/WAF showing the
blocked request. Tell me whether this looks like a bot-identity rule
(user-agent or IP based), a rate-limit/challenge rule that should really be
returning 429, or a request/validation error, and what I'd need to change or
allowlist to fix it without disabling the underlying protection.

LOG LINE(S):
[paste]

Faça uma verificação de sanidade da correção antes de publicá-la

I'm about to change how a URL responds because it's currently returning
[status code] and showing as "Blocked due to other 4xx issue" in Search
Console. Here's what I'm about to change: [describe]. Point out anything I
might be missing — for example, whether this could accidentally expose or
re-index a page that's supposed to stay gone (a 410 I'm about to undo), or
whether I should allowlist verified Googlebot instead of loosening a security
rule for everyone.

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

Cinco perguntas sobre o significado da categoria “outro 4xx”, a exceção do 429 e como diagnosticar e corrigir o problema. Escolha uma resposta para cada pergunta e confira depois.

Ferramentas para diagnosticar e corrigir status “outro 4xx”

• HTTP Status Checker — cole a URL afetada (ou um lote) para confirmar o código de status real por trás do rótulo do GSC, ver a cadeia completa de respostas e detectar redirecionamentos que ocorrem antes do 4xx.
• Googlebot Verifier — verifique se um IP que afirma ser do Googlebot é genuíno (faixas de IP publicadas mais confirmação por DNS reverso) antes de colocá-lo na lista de permissões diante de um WAF, CDN ou plugin de segurança.
• Google Search Console — Inspeção de URL → Testar URL ao vivo — o mais próximo de ver a resposta exata que o Googlebot recebe agora, em vez de uma linha possivelmente desatualizada do relatório.
• curl -I — a maneira mais rápida de ler a linha de status bruta de uma URL e refazê-la com o user-agent do Googlebot se você suspeitar de uma regra específica para bots.
• Painel de logs do seu servidor/CDN/WAF (Cloudflare, Akamai, Sucuri, log próprio de plugin de segurança etc.) — encontre o código exato e a regra ou condição que o produziu.

Problemas comuns, por código

Cada código que cai em “outro 4xx” é uma situação independente de sintoma, causa e correção — a categoria não tem uma única causa raiz; trate estes itens como fichas de consulta separadas, não como uma sequência única.

400 Solicitação inválida

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

Causa(s) provável(is): Um destino de solicitação malformado ou codificado incorretamente, um problema de sintaxe ou um problema de enquadramento de Host/roteamento que o aplicativo ou a camada de borda rejeita imediatamente (parâmetros de consulta incorretos, caracteres inválidos ou roteamento inesperado).

Correção + verificação: Compare a solicitação exata recebida pelo servidor com a que você pretendia gerar; corrija a URL e pare de gerar ou vincular a versão quebrada. Verifique novamente com uma solicitação GET (não apenas curl -I, que testa HEAD) até retornar 200.

405 Método não permitido

Sintoma: A URL retorna 405 em algumas solicitações, embora a própria página pareça normal no navegador.

Causa(s) provável(is): O método HTTP usado não é permitido para essa rota — muitas vezes uma regra do servidor ou CDN permite apenas GET nesse caminho, mas algo envia HEAD ou outro método que ela rejeita. Confira o cabeçalho Allow da resposta para saber o que é permitido e não presuma que uma falha apenas de HEAD (como um curl -I simples) prove que o GET falha da mesma forma.

Correção + verificação: Permita o método correto para a rota. Teste novamente com HEAD e GET.

408 Tempo limite da solicitação

Sintoma: A URL retorna 408 de forma intermitente, ou a conexão simplesmente trava antes de devolver um status.

Causa(s) provável(is): A conexão ou a solicitação não foi concluída dentro da janela de tempo limite do servidor, proxy ou CDN — isso é um problema de temporização/conexão, não evidência de indisponibilidade geral do servidor.

Correção + verificação: Correlacione a temporização da conexão e da solicitação em toda a cadeia proxy/CDN/origem e no protocolo usado. Teste novamente depois de ajustar o tempo limite relevante ou corrigir o caminho lento na origem.

410 Desaparecida

Sintoma: A URL retorna 410, e a contagem de “outro 4xx” inclui páginas que você tem quase certeza de que excluiu de propósito.

Causa(s) provável(is): Remoção intencional — esse é o comportamento esperado para páginas que devem desaparecer. Se a página deveria estar disponível, o 410 é um erro.

Correção + verificação: Se for intencional, remova a URL de sitemaps e links internos para que ela deixe de aparecer como “problema”. Se não for, restaure a página.

411 Length Exigido

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

Causa(s) provável(is): O servidor exige um cabeçalho Content-Length em uma solicitação que carrega um corpo — algo incomum em um GET normal de página. Confirme nos logs que a solicitação realmente tinha conteúdo antes de presumir que se trata de um problema rotineiro de rastreamento.

Correção + verificação: Confirme primeiro o método e o corpo reais; corrija ou flexibilize a exigência no servidor, ou garanta que a solicitação inclua o cabeçalho. Em seguida, teste novamente com o mesmo método e conteúdo.

413 Carga útil grande demais

Sintoma: A URL retorna 413, normalmente em solicitações com corpo ou cabeçalhos/cookies grandes.

Causa(s) provável(is): O conteúdo da solicitação excede um limite de tamanho definido pelo servidor, CDN ou WAF — isso diz respeito à solicitação de entrada, não ao tamanho da resposta da própria página.

Correção + verificação: Confirme a solicitação de entrada nos logs antes de aumentar qualquer limite; corrija o que estiver gerando a solicitação grande demais, ou aumente o limite apenas se ele for realmente restritivo para uma solicitação legítima. Teste novamente para confirmar que uma solicitação de tamanho normal agora retorna 200.

414 URI Demais Long

Sintoma: A URL retorna 414, normalmente por causa de uma URL longa gerada ou parametrizada.

Causa(s) provável(is): A própria URI da solicitação excede um limite de comprimento — geralmente por erro na geração de parâmetros ou na cadeia de redirecionamentos, não por um problema no conteúdo da página.

Correção + verificação: Corrija a geração da URL ou dos redirecionamentos na origem, em vez de aumentar o limite às cegas, e limpe as entradas de sitemap e links internos que apontam para o padrão longo demais.

415 / 422 (Tipo de mídia não compatível / Entidade não processável)

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

Causa(s) provável(is): O servidor entendeu a solicitação, mas rejeitou seu tipo de conteúdo ou falhou em uma regra de validação do conteúdo/instruções — algo atípico em um GET simples de página. Confirme o conteúdo real da solicitação antes de presumir que é um problema genérico do conteúdo da página.

Correção + verificação: Confirme a solicitação nos logs; depois corrija a regra de validação ou o tratamento do tipo de conteúdo, ou corrija o que estiver gerando a solicitação rejeitada. Teste novamente até a resposta ser 200.

421 Solicitação direcionada incorretamente

Sintoma: A URL retorna 421, às vezes apenas por HTTP/2.

Causa(s) provável(is): A conexão foi direcionada incorretamente — mas o Google também documenta o retorno de 421 como uma forma intencional de retirar uma rota do rastreamento por HTTP/2; portanto, isso não significa automaticamente que a página está quebrada.

Correção + verificação: Confirme se a solicitação voltou para HTTP/1.1 e qual foi a resposta final. Se for uma saída intencional do HTTP/2, não há nada a corrigir; se não houver fallback e a página estiver inacessível em qualquer protocolo, corrija o roteamento da conexão e o tratamento de SNI/Host.

451 Indisponível por motivos legais

Sintoma: A URL retorna 451.

Causa(s) provável(is): Um bloqueio jurídico ou orientado por política, que pode muito bem ser intencional (por exemplo, conteúdo restrito em determinadas jurisdições) — não o trate como uma configuração incorreta comum de geolocalização/WAF.

Correção + verificação: Encaminhe o caso a quem é responsável pelas decisões jurídicas ou de política de conteúdo para confirmar que o bloqueio é intencional. Se for, está funcionando como projetado — limpe sitemaps e links que apontam para a URL. Se não for, remova o bloqueio.

429 confundido com “outro 4xx”

Sintoma: Você esperava encontrar aqui um 4xx normal, mas o código real acaba sendo 429.

Causa(s) provável(is): A limitação de taxa está sendo acionada pelas solicitações do Googlebot. O Google trata 429 como um sinal de sobrecarga do servidor, não como um erro de cliente igual aos demais códigos desta categoria; portanto, um 429 verdadeiro pode ser relatado como problema de rastreamento/servidor, em vez de continuar rotulado como “outro 4xx” — mas a documentação do Google descreve o comportamento de processamento, não a taxonomia do relatório; trate a posição exata no relatório como não confirmada.

Correção + verificação: Não desative uma limitação de taxa legítima — adicione um cabeçalho Retry-After como boa prática (ele é opcional pela RFC 6585; o Google não confirma que o Googlebot agenda o próximo rastreamento a partir dele). Se uma regra estiver retornando 4xx ao Googlebot apenas para limitá-lo, troque essa regra para 429 ou 503.

Prove que a correção realmente funcionou

Depois de corrigir o erro de solicitação/validação, limpar um 410 intencional, liberar o Googlebot verificado ou confirmar que uma limitação de taxa está sendo tratada corretamente, estes são os testes que separam “a configuração mudou” de “o Google agora consegue realmente alcançar a página”. Execute-os na ordem.

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

• Teste a executar — Execute curl com uma solicitação GET na URL afetada (correspondendo ao método que o Google realmente usa — curl -I testa apenas HEAD) ou verifique-a com o HTTP Status Checker.
• Resultado esperado — Para uma página que você quer indexar, a linha de status mostra HTTP/1.1 200 OK. Para uma página removida intencionalmente, tudo bem o status continuar 410 — o teste relevante nesse caso é o Teste 3.
• Interpretação da falha — O mesmo 4xx original significa que a correção não foi realmente aplicada àquela rota ou que você está testando a URL/ambiente errado. Um 4xx diferente do anterior (por exemplo, 400 virou 403) significa que você trocou um bloqueio por outro — confira a regra do WAF/CDN.
• Janela de monitoramento — Imediata — o servidor responde assim que a mudança está ativa.
• Gatilho de reversão — Se flexibilizar uma regra de validação ou tamanho abrir um comportamento que você não pretendia, restaure a regra original 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 agora consegue alcançar a página

• Teste a executar — Execute Inspeção de URL → Testar URL ao vivo no Google Search Console para a URL afetada.
• Resultado esperado — Para uma página que você quer indexar, o teste ao vivo é bem-sucedido e mostra 200 sem relatar 4xx.
• Interpretação da falha — Se o Testar URL ao vivo ainda relata um 4xx depois que o teste anônimo com curl passa, suspeite de uma regra especificamente aplicada às faixas de IP do Googlebot (um problema de lista de permissões do WAF/CDN), não de um problema geral da solicitação.
• Janela de monitoramento — Imediata a alguns minutos depois da correção.
• Gatilho de reversão — N/A — este é um teste somente de leitura; se ainda falhar, volte ao ramo de falha do Teste 1 em vez de reverter qualquer coisa.

Teste 3 — O status é removido (ou permanece estável de propósito) no relatório de Indexação de páginas

• Teste a executar — 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 da categoria nas semanas seguintes (consulte a aba Como medir).
• Resultado esperado — As URLs corrigidas ficam elegíveis para sair da categoria quando o Google rastrear novamente o 200 corrigido — isso não é garantia de reindexação nem de prazo específico, apenas elegibilidade. URLs com 410 intencional permanecem na categoria, mas sitemaps e links internos deixam de apontar para elas.
• Interpretação da falha — Não existe uma cadência de nova tentativa publicada; não interprete uma validação lenta como uma nova falha. Se a contagem não estiver caindo depois de algumas semanas para URLs realmente corrigidas, repita o Teste 1 para confirmar que a correção continua ativa (um novo deploy ou cache de CDN pode reintroduzir silenciosamente a regra antiga).
• Janela de monitoramento — De dias a algumas semanas, acompanhada pela contagem da categoria.
• Gatilho de reversão — Só revise a correção subjacente se o Teste 1 voltar a falhar — não persiga o tempo de atualização do relatório de Indexação de páginas.

Registro de alterações