URL bloqueado pelo arquivo robots.txt: quando é certo e quando custa caro

"URL bloqueado pelo arquivo robots.txt" significa que o Google não rastreou o URL porque uma regra do seu arquivo robots.txt o proíbe, e o URL não está no índice. Na maioria dos sites, o status está correto: áreas de administração, carrinhos, busca interna e URLs com parâmetros são bloqueados de propósito. Ele só custa caro quando a regra pega uma página que você quer na pesquisa, e o trabalho é encontrar essas páginas no meio das intencionais.

Até 2022, o Relatório de cobertura do índice do Search Console usava 2 rótulos para isso: "URL enviado bloqueado pelo arquivo robots.txt" para URLs listados num sitemap enviado por você e "Bloqueada pelo robots.txt" para os demais. No Search Console em inglês, o status atual aparece como "URL blocked by robots.txt". Se o seu relatório mostra "Página indexada, mas bloqueada pelo robots.txt", o URL está no índice apesar do bloqueio, e esse status tem um guia próprio.

O que o Google diz sobre este status

A documentação do Google sobre o Relatório de indexação de páginas (consultada em outubro de 2026) lista "URL bloqueado pelo arquivo robots.txt" no grupo "Não indexadas" e diz que a página foi bloqueada pelo arquivo robots.txt do seu site. A mesma documentação apresenta o grupo "Não indexadas" inteiro dizendo que essas páginas não estão indexadas, mas não necessariamente por causa de um erro.

O bloqueio tem 2 consequências para a sua decisão:

• O bloqueio impede o rastreamento, não a indexação. A documentação do Google acrescenta que um bloqueio não garante que a página fique fora do índice. Se o Google encontrar informações sobre a página sem carregá-la, por exemplo links de outras páginas, há uma pequena chance de ela ser indexada mesmo assim e passar para "Página indexada, mas bloqueada pelo robots.txt".
• O Google nunca vê a página. Nem title, nem conteúdo, nem os links dela, nem canonical, nem noindex. O que a página diz sobre si mesma fica invisível enquanto a regra existir.

É um problema? Separe os bloqueios intencionais dos acidentais

Comece pelo filtro no topo do Relatório de indexação de páginas. Troque-o de "Todas as páginas conhecidas" para "Todas as páginas enviadas". URLs bloqueados que aparecem em "Todas as páginas enviadas" estão listados num sitemap que você enviou: você está pedindo ao Google que os indexe enquanto o robots.txt proíbe o rastreamento. Essa contradição é quase sempre um erro, seja qual for a intenção da regra.

Em 29 sites externos enviados para auditoria do SEOReport cujos sitemaps buscamos entre maio e outubro de 2026, 2 (7%) listavam no sitemap URLs que o próprio robots.txt bloqueava. Não é o problema de sitemap mais comum, mas é o que bloqueia páginas que o site já declarou importantes.

Os padrões acidentais, com antes e depois

Cada padrão abaixo é uma regra que funcionou exatamente como foi escrita e bloqueou mais do que se pretendia.

1. O arquivo de homologação que foi para o ar. Um site de desenvolvimento é totalmente bloqueado, e o arquivo vai para a produção junto com o resto do build.

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. Um prefixo curto demais. O Google compara a regra a partir do início do caminho do URL, então Disallow: /search bloqueia /search?q=shoes e também /search-engine-basics/, um artigo real.

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. Um curinga que pega landing pages. O * corresponde a qualquer sequência de caracteres, e a correspondência do Google inclui a query string. Disallow: /*? bloqueia todo URL com parâmetro, inclusive páginas de categoria paginadas como /shoes/?page=2, que você talvez queira rastreadas para que os produtos nelas sejam encontrados.

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

A mesma armadilha vale para extensões de arquivo. Num site cujas páginas terminam em .php, Disallow: /*.php bloqueia o catálogo inteiro.

4. Um grupo do Googlebot esquecido. A especificação de robots.txt do Google diz que um rastreador segue apenas o grupo mais específico que o menciona, e que grupos específicos e o grupo * não se combinam. Um grupo User-agent: Googlebot escrito para uma migração anos atrás continua valendo para o Googlebot, enquanto a equipe edita só o grupo * e não consegue explicar o bloqueio.

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

A correção é apagar o grupo antigo ou copiar as regras atuais para ele. A mesma regra explica um efeito colateral comum das políticas para rastreadores de IA: um site que adiciona grupos nomeados para bots específicos precisa repetir cada regra compartilhada em todos eles. Nossa tabela de decisão para robots.txt e rastreadores de IA mostra padrões que mantêm separadas as regras de pesquisa e de IA.

5. Recursos de renderização bloqueados. Disallow: /assets/ ou Disallow: /static/ bloqueia o CSS e o JavaScript que as suas páginas carregam. A introdução do Google ao robots.txt diz que você pode bloquear recursos sem importância, mas não aqueles cuja ausência dificulta o entendimento da página pelo Google. Arquivos bloqueados assim raramente aparecem como páginas no Relatório de indexação de páginas, então procure-os pelo lado da página: rode um teste ao vivo na Inspeção de URL e abra "Ver página testada" e depois "Mais informações" para ver os recursos da página que o Google carregou. Verifique também o host dos arquivos: o robots.txt vale por host, protocolo e porta, então arquivos servidos por cdn.example.com seguem o robots.txt desse host. Um script bloqueado que monta o conteúdo da página pesa mais em sites que renderizam no navegador, assunto do nosso guia de renderização de JavaScript.

Como testar uma regra do robots.txt contra um URL

Você não precisa de ferramenta para prever a decisão do Google. A especificação do Google resolve em 4 passos.

flowchart TD
    A["URL a testar"] --> B["Abra o robots.txt no mesmo host e protocolo"]
    B --> C{"Existe um grupo para o Googlebot?"}
    C -->|sim| D["Use só esse grupo"]
    C -->|não| E["Use o grupo *"]
    D --> F["Liste todo Allow e Disallow que corresponde ao caminho"]
    E --> F
    F --> G{"Alguma correspondência?"}
    G -->|não| H["Permitido"]
    G -->|sim| I["Vence o caminho de regra mais longo"]
    I --> J{"Allow e Disallow do mesmo tamanho?"}
    J -->|sim| H
    J -->|não| K["Aplique a regra mais longa"]

1. Escolha o arquivo. Abra o /robots.txt no host e protocolo exatos do URL. https://www.example.com/robots.txt não governa https://shop.example.com/.
2. Escolha o grupo. Use o grupo User-agent mais específico que corresponda ao Googlebot. Os nomes de user agent não diferenciam maiúsculas de minúsculas.
3. Encontre as regras que correspondem. Uma regra corresponde se o caminho dela bate com o início do caminho e da query do URL. O * corresponde a quaisquer caracteres, o $ marca o fim do URL, e os caminhos diferenciam maiúsculas de minúsculas: /Shop/ não corresponde a /shop/.
4. Escolha a vencedora. Vence a regra com o caminho mais longo. Se um Allow e um Disallow empatam, o Google usa o menos restritivo, o Allow.

Veja o método aplicado ao arquivo "depois" do padrão 3, mais Disallow: /search:

Para conferir a leitura do próprio Google, e não a sua, rode a Inspeção de URL no URL. Nos detalhes de rastreamento, "Rastreamento permitido?" mostra se uma regra do robots.txt bloqueia o Google, e um teste ao vivo aplica o arquivo que o Google consegue buscar naquele momento. O Google também publica o parser de robots.txt dele como biblioteca de código aberto, que desenvolvedores podem rodar contra um arquivo em rascunho antes de publicá-lo.

Corrija a regra e depois verifique

Altere o arquivo para que as páginas que você quer rastreadas deixem de corresponder. Restrinja um Disallow amplo, adicione um Allow mais longo para a exceção ou remova um grupo esquecido. Depois:

1. Busque o arquivo no ar para confirmar que o servidor entrega a sua edição, e não uma cópia em cache ou gerada no build: curl -s https://www.example.com/robots.txt.
2. Peça um novo rastreamento do robots.txt no relatório de robots.txt do Search Console. Em geral, o Google mantém o arquivo em cache por até 24 horas, e a ajuda do relatório cita o desbloqueio de URLs importantes como motivo para pedir um novo rastreamento. O relatório mostra quando o Google buscou o arquivo pela última vez e quaisquer erros ou avisos; uma linha com erro é ignorada.
3. Rode um teste ao vivo na Inspeção de URL em 2 ou 3 URLs afetados. "Rastreamento permitido?" agora deve dizer sim. Use "Solicitar indexação" nas páginas mais importantes; a ajuda do Google diz que a indexação pode levar até uma ou duas semanas.
4. Clique em "Validar correção" no problema, dentro do Relatório de indexação de páginas, quando a regra estiver corrigida. A documentação do Google diz que a validação costuma levar até cerca de 2 semanas e pode demorar muito mais.

A ajuda do Google sobre novo rastreamento diz que ele pode levar de alguns dias a algumas semanas, então espere que a contagem caia aos poucos. Os URLs que continuarem no relatório depois disso devem ser os que você quis bloquear.

Antes de desbloquear uma página que ficou escondida por meses, olhe para ela como um rastreador vai olhar: código de status, metatag robots e canonical. Uma página que ninguém conseguia rastrear pode carregar um noindex esquecido, o que a levaria direto para "URL marcado como 'noindex'". Nossa análise de conflitos de indexabilidade explica como esses sinais interagem.

O Search Console diz quais URLs estão bloqueados. Um diagnóstico completo do SEOReport compara as páginas listadas no seu sitemap com as regras do seu robots.txt e aponta as que você pede aos buscadores que encontrem enquanto os proíbe de rastrear. Ele também sinaliza um Disallow no site inteiro e a ausência de robots.txt. Ele lê as regras escritas para todos os rastreadores, então um grupo exclusivo do Googlebot ainda precisa ser confirmado na Inspeção de URL.

Perguntas frequentes

Um grande número de URLs bloqueados prejudica o meu site?

Não, não por si só. Milhares de URLs de parâmetros ou de busca bloqueados são sinal de que o robots.txt está fazendo o trabalho dele. Conte os URLs bloqueados que o seu sitemap lista e as páginas bloqueadas que você quer posicionar; só esses custam caro.

O que acontece se o meu robots.txt não existir ou retornar erro?

A especificação do Google trata uma resposta 404 ou outro 4xx (exceto 429) como se não houvesse robots.txt, então nada é bloqueado. Um erro 5xx é diferente: o Google para de rastrear o site nas primeiras 12 horas e depois usa a última cópia válida que tiver por até 30 dias. O Google trata timeouts e erros de DNS no arquivo do mesmo jeito, então um robots.txt que dá timeout pode pausar o rastreamento de um site que não tem regra de bloqueio nenhuma.

Devo tirar os URLs bloqueados do meu sitemap?

Sim. O sitemap lista os URLs que você quer indexados, então não deve conter nenhum URL bloqueado pelo robots.txt. Tire do sitemap os bloqueios intencionais e desbloqueie os acidentais. Nosso guia de sitemaps XML explica o que mais deve estar no arquivo.

Posso usar o robots.txt para tirar uma página do Google?

Não. O robots.txt controla o rastreamento, e o Google ainda pode indexar um URL bloqueado que recebe links de outras páginas. Para manter uma página fora da pesquisa, deixe o Google rastreá-la e adicione noindex. O guia de robots.txt e acesso de rastreamento explica qual ferramenta faz qual trabalho.

Um robots.txt num subdomínio ou em HTTP afeta o meu site principal?

Não. Cada combinação de host, protocolo e porta tem o seu próprio arquivo, e o Google não lê arquivos robots.txt colocados em subdiretórios. Um arquivo que bloqueia em staging.example.com não consegue bloquear www.example.com, mas o robots.txt do host de arquivos ou da CDN decide, sim, se o Google consegue buscar os arquivos que as suas páginas carregam.