Como testar o robots.txt depois do fim do testador do Google

Para confirmar se uma regra do robots.txt bloqueia ou libera de fato a página que você espera, hoje o caminho passa por três ferramentas diferentes: o relatório de robots.txt no Search Console, a Inspeção de URL para testar uma página específica em tempo real e um parser local para validar as regras antes de publicar. O antigo testador de robots.txt — a tela única onde bastava colar uma URL, escolher um user-agent e ver "permitido" ou "bloqueado" na hora — foi desativado pelo Google, sem um substituto com a mesma interface direta.

As ferramentas atuais cobrem o mesmo território, só que espalhado, cada uma respondendo a uma pergunta diferente. Este texto mostra onde cada uma entra e, principalmente, onde as próprias regras de correspondência do robots.txt — curingas, precedência, maiúsculas e minúsculas, barra final — fazem um teste que parecia óbvio dar um resultado errado.

O relatório de robots.txt no Search Console

O ponto de partida hoje é o relatório de robots.txt, dentro das configurações da propriedade no Search Console. Ele lista os arquivos que o Google encontrou para os hosts associados à propriedade — relevante porque um mesmo site costuma responder em mais de um host: com e sem "www", em http e https, ou num subdomínio separado para o blog.

Para cada host, o relatório mostra a data da última busca, se ela teve sucesso ou terminou em erro — 404, 500, tempo limite — e, quando existe, um aviso sobre alguma linha que não pôde ser interpretada. Esse aviso de sintaxe costuma apontar coisas simples: uma diretiva sem os dois-pontos, um valor vazio depois de "Disallow:", ou uma linha com algum caractere que o parser não reconhece. Nenhum desses erros impede o arquivo de ser servido — ele continua retornando código 200 — mas a linha quebrada é ignorada na hora de decidir o que é permitido, o que pode deixar uma regra que você escreveu simplesmente sem efeito, sem nenhum sinal de erro visível para quem só abre o arquivo no navegador.

Há também a opção de solicitar uma nova busca do arquivo, o que vale usar depois de corrigir um erro — sem isso, o Google segue com a cópia que já tinha até decidir, por conta própria, buscar de novo.

• Data e status da última busca de cada host
• Avisos de sintaxe apontando a linha problemática
• Botão para solicitar uma nova busca após uma correção

Por que o relatório não basta: testar uma página com a Inspeção de URL

O relatório de robots.txt responde sobre o arquivo como um todo: o Google conseguiu buscá-lo, e ele tem alguma linha quebrada? Ele não diz se uma URL específica está bloqueada — para isso, a ferramenta certa é a Inspeção de URL.

Colando a URL exata e rodando o teste em tempo real, não o resultado já indexado, você vê se o rastreamento dessa página está permitido pelo robots.txt vigente agora. É a forma mais direta de confirmar "esta regra bloqueia a página X" sem depender de ler o arquivo e imaginar como o Google vai interpretá-lo.

Um detalhe gera confusão: o Google costuma manter uma cópia em cache do robots.txt por um tempo antes de buscar a versão nova. Testar minutos depois de publicar uma alteração pode ainda refletir a regra antiga — a explicação mais comum não é a regra estar errada, é o cache. Solicitar uma nova busca no relatório antes de repetir o teste resolve a dúvida.

Um ponto que passa despercebido: o teste em tempo real da Inspeção de URL simula o rastreador principal do Google, não necessariamente qualquer user-agent que o seu robots.txt trate de forma diferente. Se o arquivo tem um grupo de regras específico para Googlebot-Image, para um bot de anúncios ou para um rastreador de outra empresa, essa ferramenta não confirma o comportamento desse grupo — ela só mostra o que acontece com o rastreador para o qual foi construída.

• Use a URL completa, com protocolo e barra final exatamente como no site
• Rode o teste em tempo real, não o resultado da última indexação
• Teste também uma página vizinha que não deveria ser bloqueada

Testar antes de publicar: parsers locais

Testar só depois de publicar tem um custo: qualquer erro fica ao vivo até alguém notar. A alternativa é validar as regras antes, contra uma lista de URLs que representem as seções do site, usando um parser que implemente o mesmo algoritmo de correspondência dos rastreadores.

O Google publicou em código aberto a biblioteca C++ que implementa esse algoritmo, com portes em outras linguagens disponíveis. Rodar as regras contra um parser assim, localmente, equivale a um teste automatizado: entra o conteúdo do arquivo e uma lista de caminhos, sai permitido ou bloqueado para cada um, sem publicar nada.

Rodar um parser localmente também é a forma prática de testar um grupo de regras escrito para um user-agent diferente do rastreador principal do Google — basta informar ao parser qual token de user-agent simular, algo que a Inspeção de URL não oferece.

A lista de URLs é o trabalho que importa. Inclua caminhos com parâmetros de consulta, subpastas profundas, extensões diferentes (PDF, imagens, feeds) e qualquer URL que já causou confusão. Guarde e reaproveite essa lista a cada alteração — é o que transforma um teste pontual numa rotina.

Vale também confirmar, com curl ou o navegador, que o arquivo é servido na raiz do host, com código 200 e sem redirecionamento inesperado; um robots.txt que retorna 404 é tratado como inexistente, o que libera o rastreamento, enquanto um erro de servidor (5xx) leva o Google a suspender temporariamente o rastreamento do site.

Vale ainda ficar de olho no tamanho do arquivo. Rastreadores costumam impor um limite ao que estão dispostos a processar, e o conteúdo que passa desse limite é simplesmente ignorado — na prática, como se aquelas linhas nem existissem. Um robots.txt gerado dinamicamente, com centenas de padrões de URL empilhados por algum plugin ou script, é o caso mais comum de bater nesse limite sem que ninguém perceba, porque o arquivo continua parecendo íntegro para quem só olha o começo dele.

A pegadinha da precedência: a regra mais específica vence

Um erro comum é assumir que a primeira regra que combina com um caminho é a que vale, como se o arquivo fosse lido de cima para baixo. Não é assim: entre regras que combinam, vence a mais específica — a de trecho de caminho mais longo — não a que aparece primeiro.

Exemplo: um arquivo com "Disallow: /admin/" e, mais abaixo, "Allow: /admin/publico/". Para /admin/publico/pagina.html, as duas combinam, mas "Allow: /admin/publico/" é mais longa, então vence, e a página é liberada mesmo dentro da pasta que a regra geral bloqueia.

Reorganizar as linhas não muda esse resultado, e confiar na leitura visual do arquivo é arriscado quando regras se sobrepõem. Quando duas regras de comprimento parecido colidem, o próprio guia do Google diz que, em caso de conflito entre regras equivalentes, vale a menos restritiva — exatamente o tipo de caso que vale testar com um parser, não decidir por leitura.

Curingas, fim de string e strings de consulta

O asterisco (*) representa qualquer sequência de caracteres, e o cifrão ($) marca o fim da string comparada. Juntos permitem regras como "Disallow: /*.php$", pensada para bloquear qualquer caminho terminado em .php.

A pegadinha: a comparação roda contra a URL completa, incluindo a string de consulta quando existe. Uma URL como /pagina.php?ref=boletim não termina em ".php" depois da consulta — termina em um número. A regra que parecia bloquear todo arquivo PHP deixa passar qualquer versão dessa URL com algo depois do "?".

Testar só caminhos limpos, sem parâmetros, dá falsa sensação de segurança. Ao testar uma regra com curinga e cifrão, inclua deliberadamente variações com string de consulta — é onde esse tipo de regra costuma falhar sem que ninguém note.

Maiúsculas, minúsculas e barra final: três deslizes comuns

O caminho de uma regra é comparado com sensibilidade a maiúsculas e minúsculas: "/Promocao" e "/promocao" são caminhos diferentes para o algoritmo, mesmo sendo a mesma página para uma pessoa. Se a URL usa letras maiúsculas — comum em identificadores gerados automaticamente — uma regra só em minúsculas não combina.

Já os nomes das diretivas e o token do user-agent não seguem essa regra: "User-agent", "user-agent" e "USER-AGENT" são interpretados igual. Essa mistura — sensível num lugar, insensível no outro — é fonte comum de confiança errada.

A barra final é o terceiro deslize. "Disallow: /pasta" bloqueia qualquer caminho que comece com esses caracteres — /pasta, /pasta.html, /pasta-antiga — porque a comparação é por prefixo. "Disallow: /pasta/" só bloqueia o que está dentro dessa pasta como diretório. Uma única barra muda o alcance da regra.

Por fim, robots.txt vale por combinação exata de esquema, host e porta — http e https contam como hosts diferentes, assim como com e sem "www". Testar no ambiente de homologação não garante nada sobre a produção; cada host precisa da própria verificação.

Um detalhe que aparece mais em sites em português: se a URL real tem acento ou é servida com caracteres codificados — "%C3%A9" em vez de "é", por exemplo — a regra precisa usar a mesma forma que o rastreador de fato recebe na requisição. Escrever a regra com o acento quando o servidor entrega a versão codificada, ou o contrário, faz a comparação falhar silenciosamente, sem nenhum erro visível em lugar nenhum — o teste simplesmente devolve um resultado diferente do que a leitura do arquivo sugeria.

O limite do teste: bloquear rastreamento não é remover do índice

Vale o limite: robots.txt controla se um rastreador pode buscar uma URL, não se ela está ou vai ficar fora do índice de busca. Um teste que confirma "esta página está bloqueada" garante só que o Google não vai (re)buscar o conteúdo a partir de agora.

Se a página já estava indexada antes do bloqueio, bloquear o rastreamento não remove essa entrada — o Google perde a capacidade de revisitar a página e notar qualquer instrução de remoção dentro do próprio HTML, como uma meta tag de noindex. O bloqueio pode até atrapalhar essa remoção, porque impede o rastreador de ver a instrução. Testar o robots.txt confirma comportamento de rastreamento; confirmar o que está indexado é outra verificação.

Uma rotina de teste antes e depois de publicar

Juntando as peças, uma rotina razoável trata o robots.txt com o mesmo cuidado que qualquer arquivo capaz de quebrar algo em produção se estiver errado.

Nenhuma etapa substitui as outras. O relatório diz se o Google lê o arquivo; a Inspeção de URL diz o que uma página específica sofre agora; o parser local diz o que vai acontecer antes de qualquer coisa ir ao ar. Juntas, cobrem o que o antigo testador cobria numa tela só — em três lugares, testando contra o comportamento real dos rastreadores.

• Antes de publicar: rode a nova versão contra a lista de URLs de teste num parser local, incluindo maiúsculas, barra final e strings de consulta
• Antes de publicar: releia a diferença entre versões linha por linha, com atenção a regras com curinga ou cifrão
• Depois de publicar: busque o arquivo ao vivo (curl) e confirme código 200 e conteúdo correto
• Depois de publicar: confira o relatório de robots.txt no Search Console e solicite nova busca se a versão ainda parecer antiga
• Depois de publicar: rode a Inspeção de URL em tempo real para duas ou três páginas críticas
• Se um resultado parecer o antigo pouco depois da publicação, repita o teste mais tarde antes de concluir que a regra está errada
• Guarde uma cópia de cada versão publicada, com a data — se um resultado mudar sem que você tenha editado nada, comparar contra a versão anterior é o primeiro passo antes de suspeitar de outra causa