Idiomas

Bloqueada devido a uma solicitação não autorizada (401)

O que significa o status “Bloqueada devido a uma solicitação não autorizada (401)” do relatório de indexação de páginas do Google Search Console, como ele difere de 403 na RFC 9110, as causas comuns, como diagnosticá-lo como um bot e a correção certa conforme o tipo de página — pública, privada, falso positivo de WAF ou paywall.

Publicado pela primeira vez: 23 de jun. de 2026 · Última atualização: 8 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
2 sinais de evidência nesta página

“Bloqueada devido a uma solicitação não autorizada (401)” é um status de indexação de páginas do Google Search Console que significa que o Googlebot recebeu um HTTP 401 (autenticação necessária) ao tentar rastrear a URL. O Google nunca fornece credenciais, então não consegue ver a página — ela não será indexada e uma URL antes indexada que retorna 401 acaba sendo removida. Pela RFC 9110, 401 significa que a solicitação não tem credenciais válidas (nenhuma foi enviada ou as enviadas foram recusadas); 403 significa que o servidor entendeu a solicitação e a recusou por razões que nem sempre têm relação com credenciais. O Google trata todos os 4xx, exceto 429, da mesma forma para indexação, então o resultado coincide, mas causa e correção dependem do que a página é: remova a exigência de autenticação em uma página pública bloqueada por acidente; permita o Googlebot verificado por IP/reverse-DNS (não por user-agent falsificável) em uma página pública bloqueada pela segurança de bots; mantenha a autenticação em conteúdo genuinamente privado ou de staging em vez de abri-lo para limpar o relatório; use os dados estruturados de paywall do Google em vez de um 401 genérico em conteúdo de assinatura indexável. "Loads fine in my browser" _(tradução)_ «Carrega no meu navegador» é uma armadilha — você está autenticado; o Googlebot não. Não use 401/403 para limitar o rastreamento. Diagnostique com o Teste ao vivo da Inspeção de URL e curl -I (um cabeçalho WWW-Authenticate ausente significa que a resposta está malformada, não que um WAF a produziu). Teste ao vivo e Validar correção confirmam acesso, não indexação — não há cadência publicada de novas tentativas.

TL;DR — “Bloqueada devido a uma solicitação não autorizada (401)” significa que o Googlebot recebeu um 401 (Unauthorized) HTTP — uma barreira de autenticação que ele não consegue atravessar. O Google nunca fornece credenciais, então o conteúdo nunca é visto: a página não será indexada, e uma URL antes indexada que passe a retornar 401 será removida com o tempo. 401 versus 403, com precisão (RFC 9110): 401 = a solicitação não tem credenciais válidas (nenhuma foi enviada ou as enviadas foram recusadas); 403 = o servidor entendeu a solicitação e a recusou, por razões que nem sempre têm relação com credenciais. O Google trata todos os 4xx, exceto 429, da mesma forma para indexação, então o resultado converge — mas causa e correção são diferentes, e a correção depende do que a página realmente é: remova a exigência de autenticação em uma página pública bloqueada por acidente; permita a passagem de um Googlebot verificado por IP/reverse-DNS (nunca por user-agent falsificável) quando uma página for bloqueada indevidamente pela segurança de bots; mantenha a autenticação em conteúdo genuinamente privado ou de staging; use os dados estruturados de paywall do Google, não um 401 genérico, em conteúdo de assinatura que deve ser indexável. “Carrega no meu navegador” é uma armadilha — você está autenticado; o Googlebot não. Diagnostique como um bot (teste ao vivo da Inspeção de URL, curl -I) — a ausência do cabeçalho WWW-Authenticate significa que a resposta está malformada, não que um WAF a causou. O teste ao vivo e Validar correção confirmam acesso, não indexação, e não existe uma cadência de novas tentativas publicada.

O que o Google está realmente informando

O rótulo de indexação de páginas informa a resposta observada pelo Google; ele não identifica qual regra de autenticação, CDN ou aplicação a produziu. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report O comportamento de indexação subjacente vem do tratamento documentado pelo 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: Google: HTTP status codes

O status vem diretamente do código de resposta do servidor. O Googlebot solicitou a URL e recebeu um HTTP 401, o status “Unauthorized” — a página está atrás de uma barreira de autenticação (HTTP Basic Auth, uma tela de login ou uma regra de controle de acesso). A definição do próprio Google no relatório de indexação de páginas diz que a página foi bloqueada para o Googlebot por uma solicitação de autorização e que, se você quiser indexá-la, deve remover a exigência de autorização ou deixar o Googlebot passar verificando sua identidade.

No meu texto Códigos de status HTTP e seu impacto em SEO, descrevo 401 como o cliente não ter se identificado ou verificado quando necessário — um modelo mental útil, mas não a definição completa do protocolo. A regra precisa, da RFC 9110, é que 401 significa que a solicitação não tem credenciais de autenticação válidas para o recurso; também pode ocorrer depois que o servidor recusa as credenciais. Portanto, 401 nem sempre significa que o Googlebot (ou o navegador) não enviou nada, apenas que o que foi apresentado não era válido. De qualquer forma, o resultado prático para o Googlebot é o mesmo: ele não tem credenciais para oferecer e nunca passa da barreira.

O que o Google faz com um 401

Nada de bom, se você queria a página indexada. A documentação do Google sobre status HTTP é explícita: todos os erros 4xx, exceto 429, são tratados da mesma forma — os rastreadores informam ao próximo sistema de processamento que o conteúdo não existe. Assim, um 401 efetivamente diz ao Google “não há nada aqui”. As consequências são:

  • A página não será indexada. O Google nunca viu o conteúdo, portanto não há nada para indexar.
  • Uma página antes indexada é removida. Isso não é exclusivo de 401 — é o comportamento da família 4xx. Como escrevi no texto da Ahrefs sobre códigos de status HTTP, 4xx fazem páginas saírem do índice. Um 401 que aparece em uma página já indexada pelo Google fará, após rastreamentos repetidos, a URL cair do índice.
  • Ele não limita o rastreamento. O Google diz claramente: não use códigos de status 401 e 403 para limitar a taxa de rastreamento. Um 4xx (exceto 429) não produz efeito na taxa de rastreamento, então você não pode usar 401 como alavanca de “diminua a velocidade” — para isso existem 503/429.

Uma coisa que não vou fornecer é uma cadência específica de novas tentativas. O Google volta a rastrear com o tempo, mas a documentação não publica um cronograma garantido do tipo “o Googlebot tenta um 401 novamente a cada N dias”, então não vou fingir que ele existe. Trate o novo rastreamento como “ele voltará em algum momento”, não como um cronômetro.

401 versus 403 versus outros 4xx — a parte que importa

Esta é a distinção que a maioria dos textos mistura e é onde está o valor real. Para indexação, o Google trata 401 e 403 de forma idêntica (a regra de 4xx exceto 429). Mas a causa e a correção são diferentes porque os códigos significam coisas diferentes:

  • 401 Unauthorized, pela definição da RFC 9110 — a solicitação não tem credenciais de autenticação válidas para o recurso de destino. Isso abrange dois casos: nenhuma credencial foi enviada, ou as credenciais foram enviadas e o servidor as recusou. Uma resposta 401 em conformidade deve trazer um cabeçalho WWW-Authenticate nomeando pelo menos um desafio. Minha versão compacta — “o cliente não se identificou ou verificou quando necessário” — é um resumo útil do caso comum, mas trate-a como modelo mental, não como a regra exaustiva.
  • 403 Forbidden, pela mesma RFC — o servidor entendeu a solicitação, mas se recusa a atendê-la. Credenciais são um motivo possível, mas a especificação explicita que uma solicitação “pode ser proibida por razões não relacionadas às credenciais”. Portanto, 403 não significa sempre “o cliente é conhecido/autenticado, mas não tem direitos” — esse é um padrão comum no mundo real, não uma garantia. Especificamente no relatório de indexação de páginas do Google, um 403 para o Googlebot (que nunca envia credenciais) normalmente significa que o servidor está retornando o erro de forma incorreta — muitas vezes por firewall, WAF ou regra de bot mal configurado. Existe um status irmão, Bloqueada devido a acesso proibido (403), para esse caso; o fluxo de diagnóstico se sobrepõe bastante.

O atalho mental prático ainda serve para a triagem: 401 ≈ “uma barreira de autenticação que esqueci de remover” (site de staging, autenticação HTTP esquecida), enquanto 403 ≈ “uma regra de segurança bloqueando o Googlebot por engano”. O resultado de indexação é o mesmo, mas a causa raiz é diferente — apenas não trate nenhum dos atalhos como o limite real do protocolo. A tabela de decisão está na aba Cheat Sheets.

Por que você está vendo isso — as causas comuns

Em uma página que você realmente quer indexar, um 401 quase sempre é uma destas situações:

  • Um site de staging ou desenvolvimento protegido por Basic Auth. Você protegeu o ambiente de staging com senha (o instinto correto), mas o Google descobriu a URL de alguma forma — um link interno, um sitemap ou uma referência vazada — e agora informa o 401. Se a URL de staging genuinamente não deve ser pública, isso é esperado (veja a seção sobre 401 intencional).
  • Autenticação HTTP acidental em uma seção pública. Uma regra .htpasswd, um plugin de “em breve” ou uma barreira de modo de manutenção ficou ativada em um diretório que deveria estar no ar.
  • Um WAF / CDN / allowlist de IP bloqueando o Googlebot. Este é o caso sorrateiro. Cloudflare, Akamai, Sucuri ou uma allowlist geográfica/de IP retorna 401 (ou 403) aos IPs do Googlebot enquanto atende as pessoas normalmente. A página “funciona para todos” porque todos que a testam estão vindo de um IP permitido.
  • Uma barreira de login em conteúdo de assinatura ou paywall que você realmente quer indexar. Um 401 genérico impede completamente a entrada do Googlebot — a correção não é enfraquecer a barreira, mas usar os dados estruturados de paywall compatíveis do Google (veja o quarto ramo abaixo).

Como diagnosticar — teste como um bot, não como um navegador

A maior armadilha aqui é “funciona para mim”. É claro que funciona — você está autenticado, seu IP está na allowlist ou seu navegador tem um cookie de sessão. O Googlebot não tem nada disso. Portanto, faça o diagnóstico como um bot:

  • Inspeção de URL → Teste ao vivo (GSC). É o mais próximo que você chegará de ver a resposta real que o Googlebot recebe. Execute-o na URL afetada; se ele não puder buscar por causa da autorização, você confirmou que o 401 é real e reproduzível.

  • curl -I em um contexto não autenticado. Solicite a URL sem cookies nem credenciais e leia a linha de status:

    curl -I https://www.example.com/page/
# Look for:  HTTP/1.1 401 Unauthorized
# and a WWW-Authenticate: header confirming an auth gate

Se curl (que não envia sessão nem autenticação) recebe 401 enquanto o navegador recebe 200, essa diferença é o problema — seu navegador está autenticado e o Googlebot não. A RFC 9110 exige que um 401 em conformidade traga um cabeçalho WWW-Authenticate; a presença dele confirma um desafio de autenticação real. Sua ausência, porém, não entrega a resposta: informa que a resposta está malformada ou incompleta, não qual camada a produziu. Não conclua imediatamente “deve ser o WAF” apenas pela ausência do cabeçalho.

  • Verifique se o bloqueio é específico de IP. Se curl na sua máquina retorna 200, mas o teste ao vivo do GSC falha, isso é um sinal real de que algo depende do IP de origem ou do roteamento da solicitação — mas confirme comparando logs da borda/CDN, do origin, da aplicação e de qualquer provedor de identidade antes de atribuir a causa ao WAF. Uma solicitação HEAD (que curl -I envia) também pode ser roteada ou armazenada em cache de modo diferente de uma solicitação GET, então confira também com um GET anônimo.

Como corrigir — quatro ramos, conforme o que a página realmente é

Não há uma única correção — há quatro, e escolher a errada ou expõe conteúdo que você pretendia proteger ou deixa uma página indexável bloqueada permanentemente. Classifique a URL em um destes ramos antes de tocar em qualquer configuração:

1. Conteúdo genuinamente privado ou de staging → mantenha a autenticação, não mexa nela. Se a URL realmente não deve ser pública, o 401 está funcionando como projetado — a autenticação do lado do servidor é uma forma legítima e recomendada pelo Google de manter conteúdo longe de todos, inclusive do Googlebot. John Mueller destacou isso para sites de staging: a forma correta de ocultar um site é a autenticação do lado do servidor, por IP, cookie ou autenticação normal do servidor, para que usuários normais — incluindo o Googlebot — sejam impedidos de ver o conteúdo. Não permita que o Googlebot atravesse uma barreira que protege conteúdo genuinamente privado apenas para limpar esta linha do relatório; isso derrota a finalidade da barreira. A correção aqui é higiene de descoberta, não acesso: confirme que a URL não está vinculada, incluída em sitemap ou enviada para esta propriedade do Search Console e mantenha a autenticação.

2. Uma página pública bloqueada por acidente → remova a exigência de autorização. Se a página deve ser indexada e a barreira ficou para trás — Basic Auth, tela de login ou plugin de modo de manutenção — desative-a para esse caminho. Este é o caso direto: quando uma solicitação anônima recebe 200, a página fica aberta ao Googlebot.

3. Uma página pública bloqueada indevidamente pela segurança de bots → admita o Googlebot verificado, não o user-agent literal. Quando um WAF, CDN ou allowlist de IP rejeita o Googlebot em uma página que você quer que seja pública, coloque em allowlist o Googlebot verificado por IP / reverse-DNS. O user-agent é trivialmente falsificável; qualquer pessoa pode alegar ser Googlebot. O caminho recomendado pelo Google é verificar o rastreador pelos intervalos de IP publicados ou por uma verificação de DNS reverso e direto e, então, deixar essas solicitações específicas atravessarem a barreira — você não remove a regra de segurança, apenas abre uma exceção verificada para ela. Para corrigir o falso positivo:

  • Identifique a regra que retorna 401/403 ao Googlebot (Cloudflare Firewall Events, logs do Akamai/Sucuri ou logs da borda/origin/aplicação).
  • Coloque em allowlist os intervalos de IP verificados do Google (ou a categoria de bot), em vez de desativar toda a proteção.
  • Teste novamente com o Teste ao vivo da Inspeção de URL até que o Google consiga buscar a página.

4. Conteúdo de assinatura ou paywall que você quer indexar → não use um 401 genérico. Se a página é protegida por cadastro ou assinatura, mas você quer que ela seja descoberta na busca, um 401 rígido é a ferramenta errada — o Googlebot ainda não consegue buscá-la. O Google documenta uma implementação de paywall compatível: sirva a página com os dados estruturados apropriados de conteúdo pago (isAccessibleForFree, hasPart e propriedades relacionadas) para que o Google possa indexar a parte de prévia gratuita sem que você precise abrir a página inteira.

Valide a correção e ajuste as expectativas

Depois de abrir genuinamente a página (e confirmar com ⟦curl⟧/Teste ao vivo que uma solicitação não autenticada agora retorna 200), seja preciso sobre o que cada etapa confirma:

  • O teste ao vivo confirma acesso, não indexação. A documentação do próprio Google para Inspeção de URL diz que o teste ao vivo apenas confirma se o Google-InspectionTool consegue atualmente acessar e analisar a página — não há teste que garanta que a página entrará no índice ou aparecerá na busca. Um Teste ao vivo aprovado significa que a barreira está aberta; não promete o que acontece depois.
  • Validar correção é opcional, não obrigatório. O Google atualiza a contagem do problema sempre que rastreia a página novamente, independentemente de você clicar em Validar correção. Use isso para acompanhar uma correção real — não valide uma URL que deveria permanecer privada e não trate a validação como algo que acelera a reindexação.
  • Não espere reindexação instantânea. Novo rastreamento e nova indexação levam tempo e — como observado acima — não há uma cadência publicada de novas tentativas que eu possa citar. Monitore o resultado realmente indexado e o desempenho na busca separadamente do status do relatório; nem o Teste ao vivo nem Validar correção garantem escolha de canonical ou aparição na busca.
  • Um mito para abandonar: um 401 no GSC não é uma penalidade nem uma ação manual. É um status de acesso de rastreamento. Ele não prejudica os rankings das suas outras páginas nem coloca seu site em uma “lista negra” — apenas mantém a página bloqueada fora do índice.

Onde isso se encaixa

Este é um dos status de status HTTP do relatório de indexação de páginas — os irmãos incluem Bloqueada devido a acesso proibido (403), os outros status 4xx e 404 e o status de erro de servidor 5xx. Para o relatório em si e como ler a tabela “Por que as páginas não estão indexadas”, consulte o hub do relatório de indexação de páginas. A mecânica subjacente — como o Googlebot busca e o que os códigos de status significam para ele — é coberta por rastreamento e indexação.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.