Bloqueado devido a acesso proibido (403)

TL;DR — “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» no Google Search Console significa que o Googlebot tentou ler sua página e o servidor respondeu “não, você não tem permissão” (HTTP 403). A página não será indexada. Se ela deveria ser pública, há um problema a corrigir — geralmente uma regra de firewall, CDN ou plugin de segurança bloqueou o Googlebot por engano; por isso a página pode abrir normalmente no seu navegador, mas ser bloqueada para o Google. Se a página deve continuar privada, o 403 pode estar funcionando exatamente como deveria, e a correção é outra.

O que este status significa

Este rótulo do relatório significa que o Google recebeu uma resposta HTTP 403 ao solicitar a URL. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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 persistentes, exceto 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 for indexing. 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 access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)», a mensagem é simples: o Googlebot solicitou sua página e o servidor recusou a solicitação com um erro 403 Forbidden.

Como o Google recebeu um 403, não consegue ler o conteúdo da página, então ela não será indexada — e, se já estava no Google, será removida dos resultados.

Você realmente precisa corrigir isso?

Antes de procurar uma regra, decida o que a URL deve fazer:

• Deve ser pública e indexada — o 403 é um problema não intencional. Continue lendo; o restante desta página descreve a correção.
• Deve ser pública, mas não indexada — não use robots.txt para isso; um Disallow do robots.txt é uma barreira de rastreamento separada, com seu próprio motivo no relatório, e não produz por si só um HTTP 403. Sirva a resposta normal 200 e use uma diretiva noindex (ou um redirecionamento/remoção correto).
• Deve permanecer privada — o 403 pode ser um controle de acesso correto e funcional. A correção não é abrir a regra do firewall; é garantir que a URL não esteja em seu sitemap ou em links internos, onde o Google continua encontrando-a.

Por que a página abre para você, mas não para o Google

Esta é a parte confusa do caso em que a página deveria ser pública. Você clica na URL no navegador e ela carrega perfeitamente — então como o Google está sendo bloqueado?

Seu navegador envia sinais que um rastreador normalmente não envia: cookies, um user-agent de navegador “normal” e, no caso de desafios de JavaScript ou CAPTCHA, a capacidade de concluir o desafio. A solicitação do Googlebot costuma ser diferente: sem cookies e com user-agent de rastreador. Isso pode bastar para acionar uma regra contra bots, enquanto visitantes reais passam normalmente. A página geralmente não está quebrada; uma regra está bloqueando o visitante errado. A aba Avançado mostra como confirmar a diferença exata, em vez de adivinhar.

Firewall ou CDN: uma causa frequentemente relatada

Para URLs que deveriam ser públicas, um firewall, CDN ou ferramenta de segurança (por exemplo, Cloudflare, um WAF ou um plugin de segurança do WordPress) que bloqueia o Googlebot por engano é uma das causas mais relatadas — embora não exista uma estatística independente verificada sobre a frequência exata. Outras causas incluem regras por user-agent ou país, proteção contra hotlink e conteúdo atrás de login que deveria ser público.

Como começar a corrigir

• No Search Console, use a Inspeção de URL em uma URL afetada e clique em Testar URL ao vivo para confirmar que o Google realmente recebe um 403.
• Verifique as configurações e os logs da CDN, do firewall e do plugin de segurança em busca de algo que esteja bloqueando o Googlebot ou suas faixas de IP.
• Confirme que é realmente o Googlebot antes de liberá-lo e mantenha a exceção restrita — permita apenas a rota e a regra específicas, não tudo. Muitos bots falsificam o nome Googlebot. As abas Avançado e Scripts mostram como verificar.
• Depois de corrigir a regra, a página deve retornar 200. Use Validar correção no relatório — o rastreamento novamente acontece quando o Google encontrar a resposta 200, mas não há prazo garantido.

Um status irmão é “Blocked due to unauthorized request (401)” (tradução) «Bloqueado devido a solicitação não autorizada (401)»: a ideia é a mesma, mas para páginas atrás de uma barreira de login. O mecanismo é diferente, o resultado e grande parte da correção são semelhantes.

Quer o ciclo completo de diagnóstico e correção, os detalhes de WAF e os comandos para verificar o Googlebot? Mude para a aba Avançado.

TL;DR — Um 403 no relatório de Indexação de páginas significa que o Googlebot recebeu HTTP 403 na URL, portanto o Google não a indexará (e a removerá se ela já estava indexada). A ajuda de Indexação de páginas do Google descreve 403 como credenciais fornecidas, mas acesso negado — essa é a formulação do relatório, não a definição completa de HTTP; a RFC 9110 define 403 de forma mais ampla como “entendeu, mas recusou”, com ou sem credenciais. Trate a formulação do Google como uma heurística, não como prova de configuração incorreta. Primeiro decida se a URL deve ser pública e indexável. Em URLs públicas, um firewall/CDN/WAF que bloqueia o Googlebot sem intenção é uma causa frequentemente relatada; em uma URL que deve permanecer privada, o 403 pode estar funcionando como pretendido. O Google trata 401 e 403 da mesma forma para indexação e diz explicitamente para não usá-los para limitar a taxa de rastreamento — use 429 (ou 503). Verifique o Googlebot real (DNS reverso, faixas de IP publicadas e categoria correta do cliente) antes de colocá-lo na lista de permissão, restrinja a exceção à rota e à regra específicas e confirme 200 no Testar URL ao vivo antes de executar Validar correção.

O que o Google realmente diz sobre 403 — e o que o HTTP realmente diz

O rótulo informa a resposta observada, não a WAF, CDN ou regra de acesso específica que a causou. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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 A consequência para a indexação segue o tratamento geral do Google para respostas 4xx. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. 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 o caso assim: um HTTP 403 significa que o user-agent forneceu credenciais, mas não recebeu acesso — porém o Googlebot nunca fornece credenciais. Por isso, nas palavras do Google, o servidor está retornando o erro incorretamente. A página não será indexada. Se você quer indexá-la, a correção indicada pelo Google é permitir usuários não autenticados ou liberar explicitamente as solicitações do Googlebot sem autenticação.

Essa é a formulação da Ajuda do Google, mas não a definição HTTP completa. A RFC 9110, especificação atual de semântica HTTP, define 403 de modo mais amplo: o servidor entendeu a solicitação, mas se recusa a atendê-la. Credenciais podem fazer parte do caso, mas a RFC é explícita: uma solicitação pode ser proibida por motivos totalmente alheios a credenciais — política, regra de controle de acesso, decisão de segurança na borda ou qualquer outra decisão do proprietário do servidor. Portanto, a conclusão útil não é “um 403 para o Googlebot sempre significa uma regra quebrada”; é: descubra se a URL deveria estar acessível e depois encontre a regra exata que retornou 403. Para uma página que deveria ser pública e indexada, um 403 ao Googlebot quase sempre merece correção. Para uma página deliberadamente privada ou proibida, o 403 pode ser uma decisão de acesso válida e funcional; o problema costuma ser o Google ter descoberto a URL, não o firewall estar errado.

Qualquer que seja o caso, a documentação separada do Google sobre códigos de status HTTP é direta quanto à consequência para indexação: ela não usa o conteúdo de URLs que retornam códigos 4xx; todos os erros 4xx, exceto 429, são tratados da mesma forma (o rastreador informa ao próximo sistema que o conteúdo não existe), e o pipeline de indexação remove a URL do índice se ela já estava indexada. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. 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

Decida o que a URL deve fazer antes de corrigir qualquer coisa

Nem toda linha deste relatório precisa da mesma correção. Primeiro classifique a URL em uma de quatro categorias:

1. Pública e destinada à indexação. O 403 não é intencional — siga o ciclo diagnosticar → corrigir → validar abaixo.
2. Pública, mas não destinada à indexação. Não recorra ao robots.txt para isso — um Disallow do robots.txt é uma barreira de rastreamento separada, com seu próprio motivo em Indexação de páginas (“blocked by robots.txt” (tradução) «bloqueado pelo robots.txt»); ele não produz por si só o HTTP 403 deste status. Entregue 200 normalmente e use uma diretiva noindex (ou um redirecionamento/remoção correto).
3. Deliberadamente privada ou proibida. O 403 pode ser o resultado correto e pretendido para um recurso que o solicitante não deve acessar. Se ele aparece neste relatório, o problema acionável costuma ser a URL estar sendo descoberta — no sitemap, em links internos ou em outro lugar — e não a regra de acesso estar errada. Limpe o sinal de descoberta em vez de abrir a porta.
4. Uma URL que não deveria existir, ou cuja existência você não quer confirmar. Escolha a resposta conforme a política de segurança da aplicação, não como atalho de SEO — 403 (ou 404, se você não quer confirmar que a URL existe) pode ser legítimo nos dois casos. Evidence for this claim A robots.txt disallow is a separate crawl gate and Page indexing reason; it does not itself generate the HTTP 403 response required for the Blocked due to access forbidden (403) reason. Scope: verified Search Console properties Confidence: high · Verified: 2026-07-16 Page indexing report

Tudo daqui em diante presume o caso 1: uma URL que você realmente quer que seja rastreada e indexada.

403 vs. 401 — como diferenciá-los

Os dois são status irmãos no relatório, e a maioria dos textos os reduz a uma regra prática (“403 = não pediu credenciais, 401 = barreira de login”) que não é confiável sozinha — uma camada de autenticação mal configurada também pode retornar 403 e continuar nesta linha. A própria resposta é o sinal real:

• 401 (não autorizado) — pela RFC 9110, 401 significa especificamente que faltam credenciais de autenticação válidas, e a resposta deve trazer um cabeçalho de desafio WWW-Authenticate (autenticação HTTP ou barreira de login). O Google recebeu a indicação de que precisava autenticar, mas não conseguiu.
• 403 (acesso proibido) — é uma recusa mais ampla. A RFC 9110 define-o como “o servidor entendeu a solicitação, mas se recusa a atendê-la”, com ou sem credenciais. Na prática, esta linha costuma resultar de bloqueio por firewall/CDN/WAF ou regra de segurança, mas também pode vir da aplicação por uma verificação de autenticação quebrada, de um limitador de taxa ou de uma decisão deliberada de controle de acesso. Evidence for this claim A 401 response means valid authentication credentials are missing and must include a WWW-Authenticate challenge; a 403 is a refusal that can occur with or without credentials. Scope: 401 and 403 responses Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

Para diferenciá-los em uma URL específica, confira o status e os cabeçalhos retornados — a resposta traz um cabeçalho WWW-Authenticate? — em vez de presumir o mecanismo apenas pelo rótulo do relatório. Eles compartilham o resultado (não indexado) e muitas vezes a correção (liberar o Googlebot verificado ou abrir o conteúdo para usuários anônimos); depois de identificar o status, o mesmo ciclo de diagnóstico abaixo se aplica a ambas as linhas.

O que um 403 faz com a indexação

Três coisas acontecem quando o Googlebot recebe um 403:

1. O conteúdo é ignorado. O Google não usa o conteúdo de URLs 4xx, então nada na página pode ser indexado.
2. A URL é removida se estava indexada. Um 403 pode desindexar uma página que antes aparecia nos resultados — não é apenas um problema de “não entrar”; é também um problema de “sair do índice”.
3. A frequência de rastreamento diminui. Com o tempo, o Google rastreia URLs 4xx menos vezes, portanto um 403 persistente recebe menos visitas e pode se recuperar mais devagar depois da correção.

Por que o Googlebot recebe 403 quando o navegador não recebe

Esta é a pergunta que deixa as pessoas dando voltas. A página abre no navegador, então o conteúdo parece estar perfeitamente bem — mas o Google informa 403. A explicação provável é que o navegador e o Googlebot enviam solicitações com aparências muito diferentes; uma regra de gerenciamento de bots criada para impedir scrapers pode disparar para o rastreador e atender humanos normalmente. Trate isso como uma hipótese a confirmar, não como conclusão automática: o atributo que realmente importa varia de site para site:

• O navegador envia cookies, um user-agent de navegador real e pode resolver um desafio de JavaScript ou CAPTCHA; a solicitação do Googlebot normalmente não tem nada disso — não tem cookies, usa user-agent de rastreador e não resolve um desafio interativo. (O Google-InspectionTool renderiza JavaScript e informa a saída renderizada, portanto dizer que “o Googlebot não tem JavaScript” não é correto em todas as situações.)
• Além das diferenças no cliente, as solicitações podem divergir na categoria/IP de origem, geografia, método, referer, estado do cache e regra que disparou — qualquer um desses fatores pode ser o gatilho real.

Não adivinhe qual atributo causou o bloqueio. Compare os logs exatos da borda e da origem para uma solicitação realmente bloqueada com os logs de uma visita normal — mesmo ID de regra, cabeçalhos de resposta, método, user-agent, IP de origem e categoria verificada, região, cookies, referer, estado do cache e resultado do desafio. Mude um atributo de cada vez até descobrir o que altera a resposta. Assim você confirma que o 403 é seletivo, em vez de apenas presumir.

Causas comuns

• Gerenciamento de bots na CDN/WAF. Cloudflare (Bot Fight Mode, Super Bot Fight Mode, Browser Integrity Check e Managed Challenge), Akamai, Imperva/Incapsula, Sucuri e AWS WAF podem desafiar ou retornar 403 para clientes que não parecem navegadores, inclusive o Googlebot. Em URLs que deveriam ser públicas, esta é uma das causas mais relatadas — embora não exista uma estatística independente verificada sobre sua participação.
• Firewall do servidor ou regras de segurança. mod_security/OWASP CRS, fail2ban ou firewalls no host podem interpretar o padrão do Googlebot como abusivo.
• Regras de user-agent, referer ou hotlink. Regras que retornam 403 para toda solicitação sem um user-agent ou referer semelhante ao de um navegador.
• Bloqueio geográfico ou de IP. Excluir as faixas de IP usadas pelo Googlebot (que rastreia principalmente a partir dos EUA) pode fazer um bloqueio de país capturá-lo silenciosamente.
• Barreiras de login ou credenciais. Exigir cookies ou login para ver conteúdo que deveria ser público; este caso se sobrepõe ao 401.
• Regras de limitação que retornam 403 depois de N solicitações. Não faça isso — veja abaixo.

Não use 403 para limitar o Googlebot

Este é o anti-padrão que vale chamar pelo nome. Pessoas (e algumas CDNs) retornam 403 ou 404 para desacelerar o Googlebot e reduzir a carga do servidor. O Google é explícito: não use códigos de status 401 e 403 para limitar a taxa de rastreamento. Eles não têm efeito sobre a taxa; apenas desindexam a página. Se você realmente precisa que o Googlebot recue, retorne 429 (ou um 5xx como 503); são os códigos que o Google interpreta como “desacelere”, e o efeito é temporário, não permanente.

Como diagnosticar

1. Inspeção de URL → Testar URL ao vivo. Execute uma URL afetada no Search Console e use Testar URL ao vivo para confirmar que o Google recebe um 403 agora, não um relatório antigo. Lembre-se de que o teste usa o Google-InspectionTool, um cliente específico: um teste aprovado prova que o InspectionTool passou naquele momento, não que o Googlebot agendado seguirá exatamente o mesmo caminho de WAF, região, cache ou limitação na próxima visita.
2. Reproduza como Googlebot. Não teste pelo navegador normal; busque a URL com o user-agent do Googlebot, de preferência fora da sua rede e em mais de uma região. O Google rastreia principalmente a partir dos EUA, mas pode mudar de país se as solicitações dos EUA forem bloqueadas; uma aprovação em uma região não prova acesso global. Os comandos estão na aba Scripts.
3. Leia os logs da CDN, WAF e firewall. Encontre a regra exata acionada pela solicitação do Googlebot e compare cabeçalhos, ID da regra e gatilho (user-agent, IP, desafio ou limite de taxa) com o log de uma visita normal, em vez de presumir qual atributo causou o bloqueio.
4. Verifique o Googlebot real e sua categoria. Antes de liberar qualquer coisa, confirme por DNS reverso + direto ou pelas faixas de IP publicadas pelo Google que as solicitações são realmente do Googlebot. Confira também qual cliente do Google fez a solicitação: Googlebot comum, rastreadores especiais e buscadores acionados pelo usuário, como o Google-InspectionTool, usam máscaras de host e listas de IP diferentes.

Como corrigir

• Crie uma exceção restrita para o Googlebot verificado no WAF ou firewall — por identidade verificada (DNS reverso + direto, correspondente à categoria correta do cliente) ou pelas faixas de IP publicadas pelo Google, nunca apenas confiando na string do user-agent. Mantenha a exceção estreita: somente as rotas e a regra específicas que precisam dela, não uma autorização ampla para todo Google. Preserve os demais controles de segurança, limites de taxa e logs e defina uma data de expiração/revisão. Peça ao provedor da CDN/firewall para confirmar que o Googlebot está permitido e automatize a verificação das regras contra as sub-redes publicadas pelo Google.
• Abra o conteúdo público para usuários anônimos. Se o 403 vem de uma exigência de login ou cookie em conteúdo que deveria ser público, remova essa exigência; esta também é a correção compartilhada com o 401.
• Troque limites que retornam 403 por 429. Se uma regra retorna 403 depois de certo número de solicitações, altere-a para retornar 429 (ou 503), para que o Googlebot interprete a resposta como “desacelere”, não como “vá embora”.

Valide a correção e reindexe

Depois de corrigir a regra, a URL deve retornar 200. Então:

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 access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» do relatório de Indexação de páginas.
3. A reindexação acontece automaticamente quando o Google rastrear novamente uma resposta 200; não há garantia oficial de velocidade exata, e a URL ainda precisa passar pelo rastreamento normal antes de reaparecer. Você não precisa disparar nada além de remover o bloqueio, confirmar a resposta saudável e dar tempo para o Google rastrear novamente.

Para entender o quadro maior — quais motivos de não indexação aparecem aqui e como o relatório os agrupa — consulte a visão geral do relatório de Indexação de páginas. Para o status irmão, “Blocked due to unauthorized request (401)” (tradução) «Bloqueado devido a solicitação não autorizada (401)» é a versão 401 deste mesmo problema.

Resumo de IA

Uma versão condensada do conteúdo Avançado:

• O que é. “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» no relatório de Indexação de páginas do GSC significa que o Googlebot rastreou a URL e o servidor retornou HTTP 403. O Google não a indexará e a removerá se ela já estava indexada.
• Formulação do Google versus HTTP. A Ajuda do Google descreve 403 como credenciais fornecidas, mas acesso negado — é a formulação do relatório, não a definição HTTP completa. A RFC 9110 define 403 de modo mais amplo: uma recusa que o servidor pode emitir com ou sem credenciais, por qualquer motivo.
• Decida a intenção da URL primeiro. Pública e destinada à indexação → corrija o 403. Pública, mas não destinada à indexação → use noindex, não robots.txt (que é uma barreira separada e não produz 403 por si só). Deliberadamente privada → o 403 pode estar correto; limpe a forma como o Google descobre a URL.
• Causa frequentemente relatada em URLs públicas. Firewall/CDN/WAF (Cloudflare, Akamai, Imperva/Incapsula, Sucuri ou AWS WAF) ou plugin de segurança bloqueando o Googlebot, geralmente sem intenção — embora não exista uma estatística verificada sobre a frequência exata.
• Por que abre para você, mas não para o Google. Seu navegador costuma carregar cookies, user-agent real e capacidade de resolver desafios; a solicitação do Googlebot não — mas confirme o gatilho comparando logs.
• 401 versus 403. Confira a resposta: 401 exige um desafio WWW-Authenticate; 403 é uma recusa mais ampla, que pode ocorrer com ou sem credenciais. O Google trata ambos da mesma forma para indexação, e as correções muitas vezes se sobrepõem.
• Não limite com 403. Não use 401/403 para limitar o rastreamento — eles apenas desindexam. Use 429 (ou 503) para “desacelerar”.
• Diagnóstico. Inspeção de URL → Testar URL ao vivo (confirma acesso do Google-InspectionTool naquele momento, não o caminho exato do Googlebot agendado); reproduza como Googlebot em mais de uma região; compare linha a linha os logs de WAF/firewall; verifique o Googlebot real e sua categoria antes de liberá-lo.
• Correção e validação. Restrinja a exceção ao Googlebot verificado (ou abra o conteúdo); troque limites 403 por 429; confirme 200 no Testar URL ao vivo; execute Validar correção. A reindexação ocorre quando o Google rastrear novamente um 200, sem prazo garantido.

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 as linhas “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)», e o que cada uma significa.
• Como códigos de status HTTP e erros de rede e DNS afetam a Pesquisa Google — como o Google trata 4xx (conteúdo ignorado, URL removida do índice) e a regra contra usar 401/403 para limitar o rastreamento.
• Como verificar o Googlebot e outros rastreadores do Google — DNS reverso + direto e faixas de IP publicadas, para liberar o Googlebot real, não um falsificador.
• Visão geral dos rastreadores e buscadores do Google — os user-agents do Google e os arquivos JSON de faixas de IP para comparação.
• Don’t 404 my yum (blog Search Central, 2023) — o pedido do Google para que sites e CDNs parem de usar 403/404 para limitar o Googlebot e usem os códigos apropriados.

Bing / Microsoft

• Bing Webmaster Tools — Controle de rastreamento — assim como o Googlebot, o Bingbot não consegue indexar uma página que recebe 403; verifique se regras do firewall/CDN não estão bloqueando o Bingbot (os hostnames resolvem para *.search.msn.com) e use Controle de rastreamento para gerenciar a velocidade em vez de bloquear.

Padrão HTTP

• RFC 9110 — Semântica HTTP, §15.5.2 (401) e §15.5.4 (403) — as definições do protocolo usadas nesta página para corrigir a formulação mais estreita e baseada em credenciais da Ajuda do Google: 401 exige um desafio WWW-Authenticate, enquanto 403 é uma recusa mais ampla que pode ocorrer com ou sem credenciais.

Citações da fonte

Declarações registradas do Google. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google — o que 403 significa para a indexação (relatório de Indexação de páginas)

• “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (tradução) «HTTP 403 significa que o user-agent forneceu credenciais, mas não recebeu acesso. No entanto, o Googlebot nunca fornece credenciais, portanto o servidor está retornando esse erro incorretamente. A página não será indexada.» — Ajuda do Google Search Console, “Page Indexing report” (tradução) «Relatório de indexação de páginas». Ir para a citação

Google — como 4xx (incluindo 403) é tratado

• “Google doesn’t use the content from URLs that return 4xx status codes.” (tradução) «O Google não usa o conteúdo de URLs que retornam códigos de status 4xx.» — documentação do Google Search Central. Ir para a citação
• “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.» Ir para a citação

Google — não use 401/403 para limitar a taxa de rastreamento

• “Don’t use 401 and 403 status codes for limiting the crawl rate.” (tradução) «Não use os códigos de status 401 e 403 para limitar a taxa de rastreamento.» — documentação do Google Search Central. Ir para a citação

Lista de verificação: diagnosticar → corrigir → validar um 403

Use esta lista em qualquer URL que mostre “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)»:

• Decida a intenção da URL — pública/indexável, pública/não indexável, deliberadamente privada ou não deveria ser descoberta. Só o caso pública e indexável precisa do restante desta lista.
• Confirme que está ao vivo, não antigo — Inspeção de URL → Testar URL ao vivo mostra um 403 atual (isso confirma acesso do Google-InspectionTool, não necessariamente o caminho exato do Googlebot agendado).
• Reproduza como Googlebot — busque a URL com o user-agent do Googlebot, de fora da sua rede e, idealmente, em mais de uma região; não use apenas o navegador normal.
• Encontre a regra — compare os logs da CDN/WAF/firewall/plugin da solicitação bloqueada com uma visita normal (ID da regra e gatilho: user-agent, IP, desafio ou limite de taxa), em vez de presumir a causa.
• Verifique o Googlebot real e sua categoria — DNS reverso + direto (o host termina em googlebot.com, google.com ou googleusercontent.com) ou comparação com a lista de faixas de IP da categoria correta, antes de liberar qualquer coisa.
• Restrinja a exceção ao Googlebot verificado — rotas e regra específicas, por identidade/faixa de IP, com logs e data de expiração/revisão; nunca uma permissão ampla e nunca apenas por confiar no user-agent.
• Abra o conteúdo público — se o 403 vem de login/cookie em conteúdo que deveria ser público, remova a exigência.
• Troque qualquer limite 403 por 429 (ou 503) — nunca use 401/403 para desacelerar o rastreamento.
• Confirme 200 — Inspeção de URL → Testar URL ao vivo agora retorna 200.
• Valide — clique em Validar correção na linha 403 e/ou Solicitar indexação para URLs prioritárias; a reindexação acontece no rastreamento seguinte.
• Prepare o futuro — automatize a verificação das regras contra as sub-redes de IP publicadas pelo Google para que uma atualização de faixa não bloqueie você silenciosamente de novo.

Os modelos mentais

1. Pergunte “deveria ser público?” antes de perguntar “quem está configurado incorretamente?” A formulação da Ajuda do Google apresenta 403 como credenciais enviadas e recusadas, mas a RFC 9110 define-o de modo mais amplo: uma solicitação que o servidor entendeu e recusou, com ou sem credenciais. Em uma página que deveria ser pública e indexada, 403 ao Googlebot quase sempre significa que uma regra atingiu o visitante errado — trate-o como “encontre a regra”, não como julgamento da página. Em uma página deliberadamente privada, o 403 pode estar cumprindo sua função; nesse caso, remova a URL do caminho de descoberta do Google, não abra o firewall.

2. Mesma regra, visitante com aparência diferente — confirme qual diferença importa. A página pode abrir para você e retornar 403 para o Google porque seu navegador carrega cookies, user-agent real e capacidade de resolver desafios que a solicitação do Googlebot não tem. Não presuma qual atributo acionou a regra: compare os logs e mude um atributo de cada vez. Depure fazendo a solicitação do Googlebot, não a sua, e deixe os logs dizerem o motivo.

3. Verifique a identidade e só então restrinja a exceção. Qualquer pessoa pode falsificar o user-agent do Googlebot. A ordem é sempre: confirmar identidade e categoria do cliente (DNS reverso ou lista de faixas de IP correspondente) → só então liberar — e mesmo assim restringir a exceção à rota e à regra específicas, com logs e data de expiração/revisão. Liberar apenas pelo user-agent, ou de forma ampla demais, abre uma brecha para scrapers que fingem ser o Google.

4. 403 é o limitador errado. Se o objetivo é desacelerar o Googlebot, 401/403 não fazem isso — eles desindexam. Os códigos de “desacelere” são 429 e 5xx/503. Escolha o código que corresponde à intenção: “vá embora para sempre” (desindexar) ou “volte depois” (limitar temporariamente).

5. 403 e 401 são primos próximos, diferenciados pela resposta. 401 exige um desafio WWW-Authenticate — uma barreira real de autorização. 403 é uma recusa mais ampla, que pode ocorrer com ou sem credenciais; não deduza o mecanismo apenas pelo rótulo, confira a resposta real. Depois de identificar o status, ambos compartilham o resultado (não indexado) e muitas vezes a correção (admitir Googlebot verificado ou abrir o conteúdo); diagnostique-os com o mesmo ciclo.

Folha de consulta do 403

Status irmãos em Indexação de páginas

Códigos de status e rastreamento — escolha o correto

O que 403 faz com uma página que deveria ser indexada

• Conteúdo ignorado (o Google não usa conteúdo 4xx).
• URL removida do índice se já estava indexada.
• A frequência de rastreamento diminui enquanto o 403 persiste.

Referência rápida para verificar o Googlebot

• Faça DNS reverso do IP → o host deve terminar em googlebot.com, google.com ou googleusercontent.com.
• Faça DNS direto desse host → ele deve resolver de volta para o mesmo IP.
• Ou compare o IP com os arquivos JSON de faixas de IP de rastreadores publicados atualmente pelo Google para a categoria correta — Googlebot comum, rastreadores especiais e buscadores acionados pelo usuário, como o Google-InspectionTool, têm listas separadas.

Reproduza o 403 como Googlebot

Não teste pelo navegador normal — ele pode não acionar a regra de bots. Busque a URL com o user-agent do Googlebot para ver o que o Google vê.

macOS / Linux

# Fetch headers only, as Googlebot's user-agent — look at the status line
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -I https://www.example.com/page/
# A "HTTP/1.1 403 Forbidden" here reproduces what Googlebot is getting.

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 403 instead of throwing
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Se isso retornar 403, mas uma solicitação de navegador normal retornar 200, você confirmou um bloqueio específico para bots. Observação: uma WAF sofisticada também pode usar o IP como critério; para uma reprodução completa, teste de fora da sua própria rede.

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

Muitas solicitações fingem ser do Googlebot. Confirme a identidade com uma verificação de DNS reverso + direto antes de liberar um IP no firewall.

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 é Googlebot — não o coloque na lista de permissão. Você também pode comparar o IP com as faixas publicadas pelo Google (googlebot.json). Observe que googlebot.json cobre apenas o Googlebot comum; rastreadores especiais e buscadores acionados pelo usuário, como o Google-InspectionTool, publicam arquivos de faixas separados. Compare com a lista do cliente que você está tentando verificar. Confirme a identidade primeiro e depois restrinja a exceção à rota e à regra específicas; nunca libere apenas pela string do user-agent nem abra uma exceção ampla.

Diagnóstico de um 403: bloqueio de WAF, barreira de login ou uso incorreto de limite de taxa?

A primeira bifurcação verifica a própria resposta — um 403 sem cabeçalho WWW-Authenticate ou sem solicitação de login aponta para longe do status irmão 401 e em direção a uma recusa por regra de segurança ou controle de acesso. A partir daí, os ramos seguem o ciclo diagnosticar e depois corrigir já descrito na aba Avançado; trate cada resultado como uma hipótese a confirmar nos logs, não como certeza. Clique para percorrer o fluxo.

Acompanhe a categoria 403, não apenas sua existência

O número que vale acompanhar é a quantidade de URLs na linha “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» do relatório de Indexação de páginas ao longo do tempo, não apenas se a linha existe — uma fotografia isolada não diz se uma correção funcionou ou se novos 403 estão se acumulando.

Contagem da categoria 403 ao longo do tempo

• Métrica — Contagem de URLs na linha “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» do relatório de Indexação de páginas do GSC, acompanhada semana a semana.
• O que isso informa — Se uma correção de lista de permissão ou regra de firewall funcionou e se novos 403 estão surgindo. Depois de liberar o Googlebot verificado ou abrir um caminho público, a contagem deve cair em direção a zero para as URLs corrigidas. Se permanecer estável, isso só é normal quando você decidiu deliberadamente que essas URLs nunca devem ser rastreadas; uma contagem crescente geralmente significa que uma regra de WAF/CDN ou atualização de faixa de IP começou a capturar o Googlebot.
• Como obter — Relatório de Indexação de páginas do GSC, filtrado pela linha 403; faça verificações pontuais com Inspeção de URL → Testar URL ao vivo para confirmar que não é uma fotografia antiga.
• Referência/intervalo realista — Não existe uma meta universal — depende de quantas URLs você realmente quer indexar. O parâmetro honesto é zero 403 entre as URLs que você quer indexar e uma contagem estável (não crescente) no restante. Estabeleça sua própria linha de base antes de julgar a tendência.
• Periodicidade — Semanalmente logo depois de uma correção, até a contagem estabilizar; depois, mensalmente como verificação de regressão, pois uma atualização da CDN ou das faixas de IP do Googlebot pode reintroduzir o bloqueio sem aviso.

Runbook: diagnosticar, corrigir, validar

O fluxo de trabalho do 403 é curto e ordenado — não pule para a lista de permissão antes de reproduzir o bloqueio como Googlebot e confirmar a identidade do que você está prestes a liberar.

1. Confirme que está ao vivo, não antigo. Execute Inspeção de URL → Testar URL ao vivo no GSC para a URL afetada e confirme que o Google recebe 403 agora, não um relatório armazenado em cache.

2. Reproduza como Googlebot, não como você. Busque a URL com o user-agent do Googlebot, de preferência fora da sua rede e em mais de uma região — seu navegador normal envia cookies, user-agent real e pode passar desafios de JavaScript/CAPTCHA que a solicitação do Googlebot normalmente não consegue, portanto pode não acionar a mesma regra. Compare os logs resultantes lado a lado, em vez de presumir qual diferença causou o bloqueio.

3. Encontre a regra. Leia os logs da CDN/WAF/firewall em busca da regra exata acionada pela solicitação do Googlebot — o ID da regra e o gatilho (user-agent, IP, desafio ou limite de taxa) informam o que mudar.

4. Verifique o Googlebot real e sua categoria antes de liberá-lo. Confirme por DNS reverso + direto ou pela lista de faixas de IP correspondente à categoria do cliente (Googlebot comum, rastreadores especiais e buscadores acionados pelo usuário têm listas separadas) que as solicitações que você vai permitir são realmente do Googlebot; do contrário, você abre uma brecha para falsificadores ou verifica a lista errada.

5. Corrija pela causa. Regra de WAF/CDN → restrinja uma exceção ao Googlebot verificado, à rota e à regra específicas, por identidade/faixa de IP. Exigência de login/cookie em conteúdo público → remova-a. Regra de limite de taxa que retorna 403 → troque-a por 429 (ou 503).

6. Valide. Confirme que Inspeção de URL → Testar URL ao vivo agora retorna 200, clique em Validar correção na linha 403 e/ou em Solicitar indexação para URLs prioritárias. A reindexação acontece automaticamente quando o Google rastrear novamente um 200; se a contagem da categoria 403 não estiver caindo depois de algumas semanas, volte à etapa 2 e reproduza novamente em vez de adivinhar uma nova causa.

Prompts de IA prontos para uso

Prompts para copiar e colar e classificar um 403 a partir de uma saída de diagnóstico bruta. Eles ajudam a fazer a triagem da causa provável rapidamente — confirme sempre a conclusão na configuração real do servidor/firewall antes de mudar qualquer coisa.

Classifique a causa provável a partir da saída do curl

I'm diagnosing a "Blocked due to access forbidden (403)" status in Google
Search Console. Below is the raw output of a request made with Googlebot's
user-agent (curl -A "...Googlebot..." -I). Based on this output alone,
classify the most likely cause as one of: (1) CDN/WAF bot-management
challenging or blocking non-browser clients, (2) server firewall / mod_security
rule flagging the crawl pattern as abuse, (3) user-agent or referrer/hotlink
rule, (4) geo/IP blocking excluding Googlebot's IP ranges, (5) a login/cookie
requirement on content that should be public, (6) a rate-limit rule misusing
403 instead of 429. Explain which specific header or detail in the output
pointed you to that answer, and tell me what's missing if you can't tell for
sure.

CURL OUTPUT:
[paste]

Classifique a causa a partir de uma linha de log do WAF/firewall

I'm investigating why Googlebot is getting a 403 on a page I want indexed.
Below is a log line (or a few) from my WAF/CDN showing a blocked request. Tell
me whether this looks like a bot-identity rule (blocking by user-agent or IP
range), a challenge/CAPTCHA rule, or a rate-limit rule misusing 403, and what
I'd need to allowlist — by IP range or reverse-DNS — to let verified Googlebot
through without disabling the rule entirely.

LOG LINE(S):
[paste]

Faça uma verificação de sanidade da correção antes de colocá-la em produção

I'm about to allowlist a set of IPs as "Googlebot" in my WAF, because a page
I want indexed is currently returning 403 to the crawler. Here's the evidence
I have that these requests are genuinely Googlebot: [describe reverse-DNS or
IP-range check]. Point out anything I might be missing — e.g. whether I should
verify by both reverse and forward DNS, whether I should match Google's
published IP-range JSON instead, or whether allowlisting by user-agent alone
would leave a hole for spoofers.

Teste seus conhecimentos: “Blocked due to access forbidden (403)”

Cinco perguntas sobre o significado de 403, sua diferença em relação a 401 e como diagnosticar e corrigir o problema. Escolha uma resposta para cada pergunta e confira depois.

Ferramentas para diagnosticar e corrigir um 403

• HTTP Status Checker — cole a URL afetada (ou um lote) para confirmar o código de status 403, ver a cadeia completa de respostas e identificar qualquer redirecionamento antes do bloqueio.
• Googlebot Verifier — verifique se um IP que afirma ser Googlebot é genuíno (faixas de IP publicadas + confirmação por DNS reverso) antes de liberá-lo em uma regra de WAF ou firewall.
• Google Search Console — Inspeção de URL → Testar URL ao vivo — o mais próximo que você chegará de ver a resposta exata que o Googlebot recebe agora.
• curl -A "...Googlebot..." — a maneira mais rápida de buscar uma URL com o user-agent do Googlebot e ler a linha de status bruta.
• Log de eventos do firewall da WAF/CDN (Cloudflare, Akamai, Sucuri etc.) — encontre a regra específica que retorna 403 para as faixas de IP do Googlebot.

Prove que a correção realmente funcionou

Depois de liberar o Googlebot verificado, abrir o conteúdo público ou trocar uma regra de limite de taxa por 429, estas são as verificações que distinguem “a configuração mudou” de “o Google agora consegue realmente acessar a página”. Execute-as na ordem.

Teste 1 — Uma solicitação com user-agent do Googlebot agora retorna 200

• Teste a executar — Busque a URL afetada com o user-agent do Googlebot (ou confira-a no HTTP Status Checker).
• Resultado esperado — A linha de status lê HTTP/1.1 200 OK.
• Interpretação de falha — Continuar em 403 significa que a regra do firewall/WAF não foi atualizada de fato ou que você liberou a faixa de IP errada. Um 401 em vez de 403 significa que você trocou um bloqueio por uma barreira de autenticação; verifique esse caminho separadamente.
• Janela de monitoramento — Imediata: o servidor responde assim que a alteração da regra entra em vigor.
• Gatilho de reversão — Se abrir o caminho expõe conteúdo que deveria continuar restrito, restaure o bloqueio e, em vez disso, libere o Googlebot verificado por IP/DNS reverso em uma regra mais estreita.

Teste 2 — O Google confirma que 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 — O teste ao vivo é bem-sucedido e mostra o conteúdo da página, sem informar erro de acesso proibido.
• Interpretação de falha — Se Testar URL ao vivo ainda informa 403 depois que a busca com user-agent do Googlebot passa, suspeite de uma regra limitada especificamente às faixas de IP publicadas pelo Google, e não à string do user-agent; confira o log do firewall em busca de uma segunda regra.
• 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 alguma coisa.

Teste 3 — O status 403 desaparece do relatório de Indexação de páginas

• Teste a executar — Use Validar correção no problema “Blocked due to access forbidden (403)” (tradução) «Bloqueado devido a acesso proibido (403)» no relatório de Indexação de páginas e acompanhe a contagem da categoria nas semanas seguintes (veja a aba Como medir).
• Resultado esperado — A URL sai da categoria 403 e, se já estava indexada, volta ao índice ao longo do tempo conforme o Google rastreia novamente a página que agora retorna 200.
• Interpretação de falha — A reindexação é automática, mas não imediata; não interprete uma validação lenta como uma nova falha. Se a contagem da categoria 403 não estiver caindo depois de algumas semanas, repita o Teste 1 para confirmar que a correção continua ativa — um cache da CDN ou uma atualização de faixa de IP do Googlebot pode reintroduzir o bloqueio silenciosamente.
• Janela de monitoramento — Dias a algumas semanas, acompanhados pela contagem da categoria 403.
• Gatilho de reversão — Só volte à regra se o Teste 1 começar a falhar de novo; não persiga o tempo de processamento do relatório de Indexação de páginas.

Recursos que valem seu tempo

Oficiais

• Relatório de indexação de páginas — as linhas 403 e 401, na formulação original.
• Como os códigos de status HTTP afetam a Pesquisa Google — como 4xx é tratado e a regra de não usar 401/403 para limitar a taxa.
• Verificação do Googlebot — DNS reverso + faixas de IP publicadas.
• Don’t 404 my yum (2023) — não use 403/404 para limitar o Googlebot.

Meus textos relacionados

• Guia para iniciantes de SEO técnico — onde problemas de acesso de rastreamento como este se encaixam no quadro maior.
• Robots.txt e SEO: tudo o que você precisa saber — a outra forma comum de páginas serem bloqueadas do rastreamento sem intenção.

De outras fontes

• r/TechSEO — comunidade para depuração de rastreamento/indexação, incluindo discussões sobre Googlebot bloqueado por CDN.
• Google warns against using 403 or 404 status codes for Googlebot crawl-rate limiting (Search Engine Land) — cobertura da orientação de Gary Illyes em “Don’t 404 my yum” e do que usar no lugar (429/503).
• Google: Don’t use 403/400 error responses for rate-limiting Googlebot (Search Engine Journal) — relato do mesmo texto de Illyes, com contexto adicional.
• Most common reason for blocking Googlebot is firewalls/CDNs (Search Engine Roundtable) — explicação do Google Search Relations de que a grande maioria dos bloqueios do Googlebot vem de regras não intencionais de CDN/firewall.
• Bots that impersonate Googlebot (johnmu.com) — John Mueller sobre verificar o Googlebot por DNS reverso antes de liberá-lo, em vez de confiar apenas no user-agent.
• How to fix “Blocked due to access forbidden (403)” (Onely) — guia prático sobre WAF/CDN e o ciclo diagnosticar → corrigir.

Registro de alterações