Ir para o conteúdo principal

Guias / Como verificar um site: os guias práticos

Como verificar o robots.txt em busca de páginas bloqueadas

Abra https://seudominio.com/robots.txt em um navegador: o que quer que seja servido ali é o seu robots.txt, e ele controla o que os rastreadores têm permissão para buscar. Ele não controla o que é indexado, que é a coisa mais importante de entender sobre o arquivo antes de editá-lo.

Onde o robots.txt precisa viver

Ele precisa ficar na raiz do host, como /robots.txt, em texto UTF-8 puro. Ele se aplica a exatamente um esquema, host e porta, então https://example.com/robots.txt não governa nada em https://shop.example.com e nada na versão http do mesmo host. Todo subdomínio que você quer controlar precisa do próprio arquivo.

O código de status que o arquivo devolve importa tanto quanto o conteúdo dele. Um 404 é lido como "sem restrições, rastreie tudo", que é um estado perfeitamente válido. Um 5xx repetido é lido como uma falha temporária e o Google pode pausar o rastreamento do host em vez de presumir que tem permissão para continuar. Um 403 se comporta como um erro de servidor para esse propósito. Se o robots.txt é não confiável, o rastreamento fica não confiável junto com ele.

A sintaxe, em cinco linhas

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent abre um grupo. Disallow bloqueia um prefixo de caminho, Allow abre uma exceção dentro de um bloqueio, * combina com qualquer sequência de caracteres e $ ancora o fim de uma URL. Sitemap é independente de qualquer grupo e recebe uma URL absoluta. O formato é padronizado como RFC 9309, então o comportamento descrito aqui não é específico de fornecedor.

Duas regras de resolução decidem o que de fato acontece. Um rastreador usa só o grupo mais específico que o nomeia, e ignora o grupo * por completo assim que um grupo o nomeia diretamente. Dentro daquele grupo, a regra de correspondência mais longa vence, e um empate vai para Allow.

Os erros que bloqueiam um site inteiro

  • Disallow: / deixado de uma implantação de staging. Um caractere, o site inteiro bloqueado. Isso acontece exatamente da mesma forma que um noindex de staging acontece: um arquivo de configuração promovido junto com um release.
  • Bloquear CSS e JavaScript. O Google renderiza páginas, então um diretório de recursos bloqueado pode fazer uma página parecer quebrada para o rastreador enquanto parece bem para você.
  • Esperar que o robots.txt remova uma página da busca. Ele não consegue. Uma URL bloqueada ainda pode ser listada a partir de links externos, geralmente sem um trecho, e como o rastreador não consegue buscá-la, um noindex naquela página nunca é visto. Para remover uma página, permita o rastreamento e sirva o noindex.
  • Usar noindex: como uma diretiva dentro do robots.txt. Isso nunca fez parte do padrão e o Google parou de respeitar em 1º de setembro de 2019. Hoje é silenciosamente ignorado.
  • Adicionar um grupo para um bot nomeado e esperar que as regras de curinga ainda se apliquem. Elas não se aplicam. Assim que User-agent: Googlebot existe, o Googlebot lê aquele grupo e mais nada, então toda regra compartilhada precisa ser repetida nele.
  • Uma linha em branco dentro de um grupo. Uma linha em branco encerra o grupo, então as regras depois dela não pertencem a nada até a próxima linha User-agent.
  • Listar caminhos privados. O arquivo é público. Nomear /internal-admin/ nele publica a localização da coisa que você está tentando esconder.

Como testar um único caminho

Busque o arquivo e leia primeiro o grupo que se aplica a você:

curl -s https://example.com/robots.txt

Depois aplique manualmente a regra de correspondência mais longa ao caminho em questão. Com Disallow: /blog/ e Allow: /blog/public/, a URL /blog/public/post é permitida porque a regra Allow correspondente é mais longa. Para uma propriedade que você possui, o relatório de robots.txt no Search Console mostra o arquivo buscado, quando foi obtido pela última vez e qualquer erro de interpretação, que é o jeito mais rápido de confirmar que o rastreador está lendo o que você acha que está lendo.

Confirme que está acessível de todo lugar

Um robots.txt que carrega da sua mesa ainda pode falhar para um rastreador. Regras de proteção contra bots, limites de taxa e bloqueios geográficos rotineiramente devolvem 403 para faixas de endereço de data center enquanto servem visitantes residenciais normalmente, e o resultado é um host que o Google desacelera ou para de rastrear por motivos que nada nos seus logs chama de erro.

O jeito de ver isso é solicitar o arquivo de algum lugar que não seja o seu escritório. Aponte a ferramenta gratuita de verificação HTTP para https://example.com/robots.txt e leia o código de status devolvido a partir de pontos de verificação em países diferentes. Um 200 em todo lugar é a resposta saudável; um 200 em casa e um 403 de três regiões é a descoberta. Para testar se as regras bloqueiam uma página específica, o testador gratuito de robots.txt verifica uma URL contra o grupo para todos os rastreadores e reporta se ela está listada no sitemap. O robots.txt vive fora da página, então a opção Indexability em um monitor HTTP da HostTracker não o lê: ela observa as tags noindex e canônica na própria página, enquanto o rastreamento agendado, em beta, verifica cruzadamente cada página rastreada contra o robots.txt. O monitoramento de SEO explica o que cada um cobre.

Verificar agora

Faça a verificação gratuita no seu próprio site, sem precisar de conta.

Robots.txt tester

Monitorar permanentemente

Seja avisado no momento em que algo quebrar: o HostTracker verifica de mais de 300 localidades e notifica você por e-mail, SMS, Slack, Telegram e mais.

Recursos do HostTracker

Mais nesta seção: Como verificar um site: os guias práticos