Un proxy mandataire applique-t-il robots.txt pour un crawler ?

Donner un proxy HTTP à un crawler change la façon dont ses requêtes atteignent le site. Cela ne fait pas récupérer robots.txt par le proxy, ne fait pas choisir le groupe de règles du crawler et ne planifie pas ses requêtes avec courtoisie.

Le Robots Exclusion Protocol décrit des règles pour les crawlers. Il couvre la correspondance, les échecs de récupération, les redirections et le comportement du cache. Un proxy qui se contente de relayer le document demandé n'a pas mis en œuvre cette politique au nom du crawler.

Gardez la décision sur les règles près de la file de requêtes du crawler. C'est là que l'identité prévue, l'URI cible et l'état de planification sont disponibles avant l'envoi du travail.

Pourquoi un filtre côté proxy est plus difficile qu'il n'y paraît

En HTTP simple, un filtre construit sur mesure peut voir le chemin cible et le User-Agent. Il lui faut encore une véritable implémentation des règles et une politique définie pour récupérer, mettre en cache et mettre à jour le fichier robots applicable. Transformer quelques lignes Disallow en blocages statiques d'adresses n'est pas le protocole complet.

En HTTPS via un CONNECT ordinaire, le proxy de transfert voit la destination du tunnel, pas le chemin de chaque page chiffrée ni le User-Agent interne. Il lui manque les informations nécessaires aux décisions robots au niveau du chemin, sauf si un autre dispositif délibéré les fournit.

Changer l'adresse de sortie ne transforme pas non plus un chemin interdit en chemin autorisé. Coordonnez le rythme entre les workers qui partagent l'activité du crawler ; la rotation des routes ne remplace pas cette politique.

Enfin, les règles robots ne sont pas une autorisation d'accès. Un chemin autorisé ne dispense ni de l'authentification ni des autres exigences d'accès du site, et un fichier robots public ne protège pas un contenu privé.