Qu’est-ce que le crawl budget et pourquoi ça compte
Le crawl budget désigne le nombre de pages que Googlebot est prêt à crawler sur votre site dans un laps de temps donné. Sur les petits sites bien optimisés, ce n’est généralement pas une préoccupation — Google crawle l’ensemble du site sans difficulté. Mais sur les sites WordPress de taille importante — plusieurs milliers de pages, nombreuses URLs paramétriques, sites e-commerce avec des filtres dynamiques — le crawl budget devient un enjeu SEO réel. Si Googlebot « gaspille » son crawl budget sur des URLs de faible valeur (pages de pagination, URLs avec paramètres, pages en doublon), les pages importantes peuvent être crawlées moins fréquemment ou pas du tout. Les fichiers de logs serveur sont le seul outil qui permet de voir exactement quelles URLs Googlebot a crawlées, à quelle fréquence et avec quels codes de réponse.
Localiser et accéder aux fichiers de logs
Sur un serveur Apache, les logs d’accès sont généralement dans /var/log/apache2/access.log ou dans le dossier de logs du virtual host. Sur Nginx, ils se trouvent dans /var/log/nginx/access.log. Sur un hébergement mutualisé, les logs sont souvent accessibles via le panneau de contrôle (cPanel, Plesk) ou sur demande à l’hébergeur. Chaque ligne de log contient : l’IP du robot, la date et l’heure, la méthode HTTP, l’URL crawlée, le code de réponse HTTP, et le user agent — c’est ce dernier qui permet d’identifier Googlebot (Googlebot/2.1).
Analyser les logs : outils et méthodes
Screaming Frog Log File Analyser est l’outil le plus accessible pour l’analyse de logs SEO — il parse les fichiers de logs et produit des rapports structurés sur les URLs crawlées par chaque bot. Pour les volumes importants, des solutions comme ELK Stack (Elasticsearch, Logstash, Kibana) ou GoAccess offrent des capacités d’analyse plus puissantes. Pour une analyse ponctuelle sur un fichier de log de taille raisonnable, un simple grep en ligne de commande peut suffire :
grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50
Cette commande extrait les 50 URLs les plus crawlées par Googlebot sur la période couverte par le fichier de log.
Ce que révèle l’analyse des logs sur WordPress
Sur un site WordPress typique, l’analyse des logs révèle généralement plusieurs catégories d’URLs que Googlebot crawle sans que cela soit souhaitable.
Les URLs paramétriques inutiles
Les URLs de type /?s= (résultats de recherche), /?page_id=, ou les filtres WooCommerce comme ?orderby=price&min_price=10 génèrent souvent des milliers d’URLs uniques que Googlebot tente de crawler. Ces pages ont rarement de la valeur SEO et gaspillent le crawl budget. La solution est de les bloquer via robots.txt pour les URLs paramétriques sans valeur, et via la balise meta robots noindex pour les pages de faible valeur qui doivent rester accessibles aux utilisateurs.
Les ressources statiques
Googlebot crawle parfois les fichiers CSS, JS et images — une pratique normale mais qui peut représenter un volume significatif. Vérifier que ces ressources ne sont pas bloquées dans robots.txt (ce qui empêcherait Google de les analyser pour le rendu) mais qu’elles sont correctement cachées côté serveur pour minimiser leur impact.
Optimiser le crawl budget sur WordPress
Les actions concrètes pour optimiser le crawl budget d’un site WordPress sont bien documentées : configurer correctement le fichier robots.txt pour bloquer les URLs sans valeur SEO, implémenter des canonical tags sur les pages en doublon, utiliser la pagination rel= »next/prev » ou Infinite Scroll selon l’architecture choisie, réduire les codes 404 et les redirections en chaîne qui consomment du budget pour rien, et s’assurer que le sitemap XML ne contient que des URLs canoniques indexables. La Google Search Console, section « Indexation », donne une vision complémentaire des URLs découvertes et de leur statut d’indexation — à croiser avec les données de logs pour un diagnostic complet.
