Como verificar se um site tem robots.txt
Como verificar se um site tem um ficheiro robots.txt
Um ficheiro robots.txt é um pequeno ficheiro de texto que fornece instruções de rastreamento aos bots que optam por segui-las. Consultá-lo pode ajudar a perceber que caminhos um site pede a determinados rastreadores que visitem ou evitem. Não revela todas as configurações do site nem funciona como barreira de segurança.
Se quer saber como verificar se um site tem um ficheiro robots.txt, comece pela origem exata do site e, em seguida, consulte a resposta do servidor e o conteúdo do ficheiro. Estes detalhes são importantes: um ficheiro num subdomínio pode não ter qualquer relação com outro, e um erro no navegador nem sempre significa que o ficheiro não existe.
1. Saiba o que o robots.txt pode — e não pode — revelar
O robots.txt contém regras para rastreadores automatizados. Uma regra pode pedir a um bot de pesquisa que respeite as instruções para não rastrear um caminho como /private/. Trata-se de um pedido, não de um mecanismo de controlo de acesso: um visitante ainda pode abrir esse URL, e um bot pode ignorar o pedido.
Também não garante que uma página bloqueada fique fora dos resultados de pesquisa. Um motor de busca pode descobrir um URL através de ligações noutros locais e apresentá-lo nos resultados sem rastrear o respetivo conteúdo. Se uma página tiver de permanecer privada, use um mecanismo de controlo de acesso real, como a autenticação, em vez de confiar no robots.txt.
Pense neste ficheiro como um conjunto público de indicações. Pode ajudar a explicar o comportamento de rastreamento, mas não confirma se uma página está acessível, é privada ou está indexada. Verifique essas questões separadamente.
2. Encontre o ficheiro robots.txt do site na origem correta
Num site em https://example.com, a localização habitual é https://example.com/robots.txt. Para saber onde encontrar o ficheiro robots.txt de um site, mantenha o protocolo e o nome do anfitrião que aparecem na barra de endereço e inclua uma porta não predefinida, caso o site utilize uma. O caminho fica na raiz dessa origem, não dentro de uma pasta como /blog/.
Alterar o protocolo ou o nome do anfitrião pode levar a resultados diferentes. Por exemplo, http://example.com/robots.txt и https://example.com/robots.txt são pedidos distintos, mesmo que um redirecione para o outro. Da mesma forma, www.example.com и example.com podem estar configurados separadamente.
Os subdomínios têm origens próprias. Um ficheiro em https://shop.example.com/robots.txt não se aplica automaticamente a https://example.com/ ou https://help.example.com/. Verifique o anfitrião que lhe interessa, sobretudo quando uma empresa mantém a loja, a área de apoio e o site principal em subdomínios separados.
Comece pela barra de endereço: introduza o URL completo do robots.txt e veja o que é carregado. É comum aparecer uma página de texto simples, mas também é perfeitamente normal o navegador apresentar o conteúdo formatado. O importante é saber que URL pediu e o que o servidor devolveu.
3. Verifique a resposta, não apenas a página do navegador
Uma resposta bem-sucedida significa, geralmente, que o servidor devolveu conteúdo para esse URL. Muitos sites devolvem um código de estado HTTP como 200, embora o texto apresentado possa conter um conjunto de regras, estar em branco ou até mostrar uma página inesperada. Analise o conteúdo juntamente com o código de estado, em vez de considerar qualquer página carregada como prova de que existe um ficheiro robots.txt válido.
Uma resposta de página não encontrada, muitas vezes 404, indica que o caminho pedido não existe nessa origem naquele momento. É uma indicação útil, mas verifique primeiro o nome do anfitrião e os redirecionamentos. Um erro de escrita ou um subdomínio diferente pode produzir o mesmo resultado.
Os redirecionamentos exigem alguma atenção. O URL pedido pode redirecionar para outro anfitrião ou caminho, e o destino pode devolver conteúdo pertencente a uma origem diferente. Registe o URL original e o destino final antes de decidir as instruções de que site consultou.
Os erros de acesso e as falhas do servidor não significam o mesmo que a ausência de um ficheiro. Uma resposta como 403 pode indicar que o servidor recusou o pedido; uma resposta 5xx pode assinalar um problema temporário no servidor. Um tempo limite da rede ou um erro de ligação do navegador também pode impedir a verificação. Tente novamente mais tarde ou use um segundo método antes de chegar a uma conclusão definitiva.
Para uma tarefa relacionada com a auditoria de sites, também pode ler como verificar se um site publica uma declaração de afiliação; essa verificação diz respeito a uma política visível, não às instruções para rastreadores.
4. Verifique as diretivas do robots.txt para o rastreador que lhe interessa
Para perceber como interpretar as regras do robots.txt, leia cada grupo no respetivo contexto. Uma linha User-agent identifica um rastreador, enquanto as linhas Disallow e Allow indicam os caminhos que esse rastreador é aconselhado a não rastrear ou que pode rastrear. A interpretação exata pode variar consoante o rastreador; quando isso for importante, consulte a documentação respetiva.
Por exemplo, um grupo que começa com User-agent: ExampleBotpode aplicar-se apenas ao rastreador identificado. Um grupo separado com User-agent: * destina-se aos rastreadores sem um grupo mais específico. Não assuma que uma regra para um bot se aplica a todos os motores de busca ou a outros serviços automatizados.
Os caminhos também são importantes. Uma regra para /images/ não é igual a uma regra para /, e uma regra para /drafts/ não abrange necessariamente um caminho com nome semelhante noutro local. Antes de aplicar uma regra a um URL, leia o caminho completo e o grupo em que aparece.
Considere um ficheiro que inclui Disallow: /private/num grupo de agentes de utilizador geral. Essa instrução pede aos rastreadores abrangidos que evitem rastrear os caminhos dentro desse diretório. Não impede que alguém abra um URL conhecido nem prova que todos os bots vão cumprir a instrução.
Alguns ficheiros incluem comentários, linhas em branco ou regras dirigidas a serviços específicos. Concentre-se no grupo de agentes de utilizador relevante para a sua questão e, em seguida, consulte as regras publicadas pelo rastreador para saber como lida com diretivas sobrepostas ou invulgares. Se estiver a verificar um motor de busca específico, a documentação desse serviço é a referência adequada para interpretar o seu comportamento.
5. Distinga um ficheiro vazio, inexistente ou inválido
Uma resposta vazia e um ficheiro inexistente são situações diferentes. Se o servidor devolver uma resposta bem-sucedida sem texto visível, o ficheiro pode existir, mas não conter diretivas. Se o servidor devolver um código de estado de página não encontrada, não encontrou um ficheiro no URL pedido. Registe o código de estado e o conteúdo para não confundir estes casos.
Se o conteúdo for inesperado, vale a pena voltar a verificá-lo. Uma página com uma mensagem de erro geral do site, um ecrã de início de sessão ou código HTML pode indicar que o pedido chegou a uma página de recurso, em vez de a um ficheiro robots.txt normal. O URL pode carregar com êxito e, ainda assim, devolver conteúdo que não serve como instruções para rastreadores.
Não tente adivinhar o significado de linhas malformadas ou desconhecidas. Guarde a resposta exata e compare-a com a documentação do rastreador que está a verificar. Se o ficheiro mudar entre verificações, registe a hora; uma resposta posterior pode corresponder a uma versão corrigida, e não ao mesmo conteúdo.
6. Confirme os resultados com um segundo método
Se o resultado no navegador não for claro, faça um pedido através da linha de comandos. Por exemplo, curl -i https://example.com/robots.txt pode mostrar os cabeçalhos da resposta e o conteúdo devolvido num único pedido. Substitua o endereço de exemplo pela origem exata que está a verificar, incluindo o subdomínio e a porta corretos, se necessário.
As ferramentas de programador do navegador são outra opção. Abra o painel Rede, carregue o URL do robots.txt e selecione o pedido para consultar o respetivo estado, os cabeçalhos e o conteúdo da resposta. Isto é útil quando o navegador apresenta um redirecionamento ou uma página formatada sem deixar claro qual é o destino final.
Se os métodos não coincidirem, compare o URL exato, a hora, o estado, os redirecionamentos e o conteúdo. Um pedido pela linha de comandos e outro pelo navegador podem seguir comportamentos de redirecionamento diferentes ou deparar-se com um problema temporário no servidor. Se estiver a usar um proxy empresarial, uma VPN ou uma extensão do navegador, faça o teste sem esses recursos, se for adequado; uma resposta diferente pode apontar para um intermediário, e não para o próprio site.
Outro exemplo de verificação de sites é como verificar se um siteapresenta um aviso de direitos de autor. Não confunda essa verificação com o robots.txt: um é um aviso do site destinado aos leitores, enquanto o outro é um ficheiro dirigido aos rastreadores.
7. Registe o âmbito e os limites da verificação
Anote o URL exato do robots.txt, a data e a hora do pedido, o código de estado HTTP, o destino de qualquer redirecionamento e o conteúdo apresentado. Se estiver a interpretar um grupo específico de diretivas, registe também o contexto do rastreador ou do agente de utilizador. Assim, será possível repetir a verificação se o site mudar.
Mantenha a conclusão limitada ao que verificou. Uma resposta bem-sucedida mostra o que o servidor devolveu para uma origem específica num dado momento; não prova que uma página está indexada, acessível a todos os visitantes ou bloqueada para todos os rastreadores. Uma resposta de ficheiro inexistente aplica-se ao URL pedido, não automaticamente a todos os subdomínios ou versões do protocolo.
O robots.txt pode mudar sem aviso. Se uma decisão depender das regras atuais, volte a verificar a origem exata e guarde a nova resposta, em vez de confiar numa cópia antiga.
