Réduire le coût environnemental du crawl d’un site Web

Cet article historique a été publié à l’origine par Gautier Dorval en janvier 2019. Il a été réécrit en juillet 2026 afin de préserver sa prémisse utile tout en retirant les estimations carbone non démontrées.

L’idée initiale était simple : quand des crawlers demandent sans cesse des URL inutiles, le Web effectue un travail qui ne produit aucune valeur. Cette prémisse demeure valide. La conclusion défendable est toutefois plus étroite que l’affirmation selon laquelle chaque requête de robot représenterait une quantité fixe de dioxyde de carbone.

Une requête peut mobiliser du traitement serveur, du stockage, du transfert réseau, du rendu, des journaux et des caches. Réduire les requêtes évitables peut donc réduire un travail technique évitable. L’effet exact sur l’énergie ou les émissions dépend de l’infrastructure, de l’état du cache, de la charge utile, de l’emplacement, du réseau électrique et du périmètre de mesure. Un rapport de backlinks ou un journal serveur ne suffit pas à le calculer.

Ce qu’un propriétaire de site peut affirmer rigoureusement

Les lignes directrices du W3C sur la durabilité du Web traitent le transfert de données, le traitement, les caches et les choix d’infrastructure comme des dimensions liées. Elles rappellent aussi un point essentiel : la durabilité est multidimensionnelle, et ses mesures comme ses recommandations évoluent.

Pour la gouvernance du crawl, cela donne une règle utile :

Réduire d’abord le gaspillage démontré. Mesurer ensuite les effets opérationnels. Formuler une affirmation environnementale seulement lorsque son périmètre et sa méthode sont explicites.

Cette approche est moins spectaculaire que d’associer un chiffre carbone universel à chaque requête. Elle est aussi techniquement vérifiable.

Trouver le gaspillage de crawl avant de bloquer

Commencez par les journaux serveur et les outils des moteurs de recherche. Classez les requêtes par famille de chemins, crawler, code d’état, taille de réponse, latence et récurrence. Recherchez notamment :

• la navigation à facettes et les combinaisons de filtres qui créent des espaces d’URL presque infinis ;
• les résultats de recherche interne et les paramètres de suivi ;
• les doublons HTTP, HTTPS, www, sans www, avec barre oblique et sans barre oblique ;
• les entrées obsolètes des sitemaps XML ;
• les chaînes de redirections ;
• les fausses 404 qui répondent avec un code 200 ;
• les réponses 5xx persistantes ;
• les liens qui renvoient continuellement les crawlers vers des URL supprimées.

Google définit le budget de crawl comme la combinaison de la capacité de crawl et de la demande de crawl. Son guide actuel sur le budget de crawl vise surtout les sites volumineux ou très fréquemment mis à jour. Un petit site dont les pages importantes sont crawlées rapidement n’a pas besoin d’un projet complexe de budget de crawl.

Le cadrage environnemental ne change pas ce seuil. Il ne faut pas créer de complexité lorsque les journaux ne montrent aucun problème matériel.

Corriger l’inventaire d’URL avant les directives

La correction la plus forte se situe généralement dans l’architecture de routage et de découverte :

1. Utiliser dans les liens internes uniquement des pages canoniques et indexables qui répondent avec un code 200.
2. Limiter les sitemaps XML aux URL canoniques qui doivent être crawlées.
3. Consolider les doublons au moyen d’une URL canonique stable et de liens cohérents.
4. Éliminer les pièges de crawl à la source lorsque l’application peut cesser de les générer.
5. Normaliser l’hôte, le protocole et les variantes de barre oblique en une seule étape.

Le robots.txt peut empêcher un crawler conforme de récupérer un chemin correspondant, mais il ne répare pas un modèle d’URL défectueux. Si les gabarits continuent à générer des milliers d’URL inutiles, le défaut structurel demeure.

Retourner une réponse HTTP honnête

Les URL historiques exigent une décision sémantique, pas une redirection générale :

• restaurer la page avec une réponse 200 lorsque le contenu répond encore à une intention réelle ;
• employer une redirection permanente 301 lorsqu’un successeur clair et pertinent existe ;
• retourner 404 ou 410 lorsque la ressource a disparu sans équivalent ;
• ne pas rediriger des URL historiques sans rapport vers la page d’accueil.

Google décrit la redirection permanente comme un signal fort en faveur du traitement de la destination, tandis qu’une réponse 4xx indique que l’ancien contenu n’existe pas. Son guide sur les codes d’état HTTP met aussi en garde contre les fausses 404 et les longues chaînes de redirections.

Il s’agit à la fois d’une règle SEO et d’une règle d’efficacité. Une réponse directe et véridique donne aux personnes comme aux crawlers un résultat plus clair, avec moins d’interprétation répétée.

Utiliser robots.txt pour le crawl, pas comme remède universel

Selon le guide robots.txt de Google, le fichier sert principalement à gérer l’accès et le trafic des crawlers. Il ne constitue pas un mécanisme fiable pour retirer une page Web des résultats de recherche.

Utilisez-le avec prudence :

• bloquez un chemin seulement lorsque le crawler n’a pas besoin de le récupérer ;
• gardez accessibles le CSS, le JavaScript, les images et les autres ressources nécessaires à la compréhension d’une page ;
• ne bloquez pas une URL qui doit être crawlée pour que la directive noindex soit découverte ;
• rappelez-vous que la conformité dépend de chaque acteur et que le fichier ne peut pas la garantir.

Better Robots.txt aide les équipes WordPress à publier et à examiner ces directives de crawl. Il ne s’agit ni d’une calculatrice carbone, ni d’une garantie d’indexation, ni d’une frontière de sécurité, ni d’une preuve que tous les crawlers ont obéi.

Réduire le coût des réponses légitimes

Toutes les requêtes de crawler ne sont pas du gaspillage. Les pages importantes doivent encore être découvertes et actualisées. Réduisez le coût des requêtes valides :

• maintenez des temps de réponse serveur stables ;
• utilisez les caches HTTP et 304 Not Modified lorsque c’est pertinent ;
• compressez les ressources textuelles et évitez les charges utiles inutilement lourdes ;
• retirez les scripts inutilisés et les requêtes tierces superflues des pages publiques ;
• employez un CDN et une stratégie de cache adaptés au trafic réel et au rythme de mise à jour ;
• corrigez les erreurs 5xx et les limitations répétées au lieu de les masquer.

Ces changements peuvent réduire les transferts et le traitement. Ils ne démontrent pas, à eux seuls, une réduction précise des émissions.

Mesurer le résultat

Comparez des périodes équivalentes avant et après le changement. Tenez compte du rythme de publication, des campagnes, des migrations et de la saisonnalité. Mesurez :

• les requêtes de crawlers vers les familles de chemins corrigées ;
• la répartition des réponses 2xx, 3xx, 4xx et 5xx ;
• les octets transmis et la latence ;
• le comportement du cache lorsque les données sont disponibles ;
• les statistiques de crawl et les rapports d’indexation dans Google Search Console ;
• la découverte et le nouveau crawl des URL de destination canoniques.

Si un résultat environnemental doit être publié, définissez le périmètre du système, la source de données, le modèle d’estimation, les hypothèses géographiques et l’incertitude. Sinon, rapportez directement le résultat opérationnel : moins d’URL en double, moins de réponses inutiles, des chaînes de redirections plus courtes ou moins d’octets transférés.

Liste de contrôle pour un crawl plus efficace

• [ ] Les journaux de crawl démontrent un gaspillage réel.
• [ ] Les liens internes et les sitemaps utilisent des URL canoniques qui répondent avec un code 200.
• [ ] La génération d’URL en double est corrigée à la source.
• [ ] Chaque URL historique a une décision fondée sur le contenu : restaurer, rediriger ou retirer.
• [ ] Les redirections permanentes mènent directement à un successeur pertinent.
• [ ] Les ressources retirées retournent une vraie réponse 404 ou 410.
• [ ] Les règles robots.txt correspondent au crawler et à l’objectif visés.
• [ ] Les ressources importantes pour le rendu demeurent crawlables.
• [ ] Les changements de cache, de charge utile et de temps de réponse sont mesurés.
• [ ] Le langage environnemental précise sa méthode et ses limites.

Poursuivez avec l’explication du budget de crawl, le guide robots.txt, ou lancez l’audit gratuit Better Robots.txt.