Tenho um arquivo robots.txt que se parece com isto:
User-agent: *
Disallow: /account/
Disallow: /captcha/
Disallow: /checkout/
User-agent: DataForSeoBot
Disallow: /p-
User-agent: UptimeRobot
Disallow: /p-
Tenho dezenas de arquivos e pastas na minha regra de proibição de curinga. Então, quero bloquear adicionalmente o acesso a URLs que começam com /p- para rastreadores específicos como o DataForSeoBot. Antes de adicionar a regra específica para o DataForSeo, ele estava vendo a longa lista de URLs na minha regra de curinga. Depois que adicionei essa regra específica adicional pelo nome do bot, a ÚNICA regra de proibição que o DataForSeoBot agora vê é a /p-. Eles estão lendo o arquivo robots.txt incorretamente ou eu não o escrevi incorretamente? Espero não ter que repetir a primeira regra inteira para cada rastreador que também quero proibir /p-, pois há cerca de uma dúzia deles. Também tentei mover a regra específica por nome para o topo antes da regra de curinga, mas não fez diferença.
Estou testando usando o recurso no site deles para ver como eles estão lendo o arquivo robots.txt.
Ambiguidade no padrão
O Padrão Proposto RFC 9309: Protocolo de Exclusão de Robôs afirma na seção 2.2.1 que:
Isso define que as regras para correspondência de agentes de usuário
*(todos os agentes de usuário) seriam combinadas para todos os agentes de usuário, apesar de haver umauser-agentlinha com uma correspondência mais específica.No entanto, acho isso ambíguo, pois continua:
Isso sugere que o
user-agent: *poderia ter algum significado especial que não se enquadrava no "DEVE ser combinado" afinal. Por que a frase estaria lá em primeiro lugar, se*já corresponde a todos os user-agents e todos os user-agents correspondentes teriam que ser combinados? Além disso, os exemplos na seção 5.1 são escritos de uma forma que suporta essa interpretação.Também pode sempre haver interpretações errôneas em implementações. Por exemplo, deve-se ter muito cuidado com a correspondência mais longa na seção 5.2 ; é um requisito para correspondência de URLs e somente URLs. O requisito para combinar user-agents correspondentes é bem o oposto.
Uma solução prática
Se quiser ter certeza de que a maioria das implementações obterá o resultado esperado, você pode sempre ser mais explícito do que o protocolo exige e listar todos os caminhos comuns não permitidos novamente para cada grupo correspondente.