Le calcul du budget d’exploration
Google publie le cadre : budget d’exploration = capacité d’exploration × demande d’exploration. La capacité, c’est ce que votre serveur encaisse ; la demande, c’est ce que Google a envie de récupérer. Les deux sont dynamiques et se travaillent.
Sur un site de 1 000 pages, la fréquence d’exploration est largement suffisante et le budget n’est jamais le goulot d’étranglement. Sur un site de 100 000 pages, Googlebot récupère peut-être 30 000 URL par jour en pointe, soit un tiers du site rafraîchi quotidiennement. Sur un site de 10 millions de pages, cette fraction tombe à quelques pour cent.
Quand le budget d’exploration compte vraiment
- Sites de plus de 10 000 URL mises à jour souvent : e-commerce, presse, petites annonces.
- Sites à fort renouvellement : offres d’emploi, immobilier, billetterie.
- Sites à contenu généré : navigation à facettes, pages de résultats internes, défilement infini.
- Sites qui ont changé de structure et traînent des chaînes de redirections.
- Sites sur un hébergement mutualisé lent, qui fait ralentir Googlebot.
Diagnostiquer : les statistiques d’exploration
Ouvrez Search Console → Paramètres → Statistiques sur l’exploration. Trois courbes : nombre de requêtes, volume téléchargé, temps de réponse moyen. Les signes de bonne santé :
- Un nombre de requêtes stable ou en hausse : Google explore autant ou davantage.
- Un temps de réponse moyen sous 200 ms : assez rapide pour que Googlebot continue d’augmenter sa cadence.
- Peu d’erreurs 5xx : le serveur n’est pas saturé.
- Peu d’erreurs 4xx sur des URL indexables : aucun budget gaspillé sur des adresses mortes.
Les quatre gaspillages classiques
1. La navigation à facettes
Une adresse du type /produits?couleur=rouge&taille=l&tri=prix-croissant engendre des milliers de combinaisons, presque toutes quasi identiques. Chacune consomme du budget d’exploration et dilue les signaux de classement.
Correctif : renvoyez les URL à facettes vers la version sans facette par une canonique. Pour les facettes à réelle valeur commerciale, créez des URL statiques correctement maillées. Bloquez les combinaisons sans valeur au robots.txt.
2. Les paramètres d’URL
Les paramètres de suivi (?utm_source, ?ref, ?sessionId) créent une infinité de variantes de la même page. Traitez-les par canonique et cessez d’émettre des URL tracées dans vos propres liens internes.
3. Les doublons internes
Versions imprimables, adresses de préproduction laissées accessibles, archives paginées dont chaque page est trop maigre pour exister seule. Canonique vers la version principale, blocage du reste, ou regroupement.
4. Les longues chaînes de redirections
Chaque saut d’une chaîne est une requête distincte. /a → /b → /c → /d consomme quatre unités de budget pour une seule destination. Aplatissez les chaînes en un saut unique.
Optimiser la capacité serveur
La capacité d’exploration suit la vitesse du serveur. Les gains accessibles en une semaine :
- Un CDN pour les ressources statiques, qui allège la charge de l’origine.
- Une mise en cache du HTML pour les visiteurs anonymes, avec une durée de vie de cinq minutes.
- Un audit des requêtes de base de données lentes, tout ce qui dépasse 100 ms côté serveur.
- Le passage à HTTP/2 ou HTTP/3 si ce n’est pas déjà fait.
- Un objectif de temps de réponse initial sous 200 ms sur l’ensemble du site.
Segmenter le sitemap
Un sitemap unique de 50 000 URL ne donne à Google aucune indication de priorité. Découpez-le et déclarez un index de sitemaps :
Chaque segment porte sa propre date lastmod, que Google utilise pour décider quoi réexplorer en premier.
Signaler les URL prioritaires
La bonne manœuvre sur un grand site n’est pas d’essayer de faire explorer tout le site plus vite. C’est de choisir les URL à plus forte valeur et de les signaler directement. Par exemple :
- Les lancements de produits.
- Les contenus liés à l’actualité, dont la fenêtre d’intérêt est courte.
- Les pages piliers venant d’être substantiellement enrichies.
- Les pages qui viennent de recevoir un lien entrant, pour que Google repasse et voie le signal.
C’est là que l’envoi groupé prend tout son sens en environnement complexe : 500 URL par requête, un branchement sur l’événement de publication du CMS, et vos pages prioritaires cessent de dépendre du budget d’exploration général.
Surveiller dans la durée
Mettez en place un suivi hebdomadaire sur :
- Le temps de réponse moyen des statistiques d’exploration, avec une alerte au-delà de 500 ms.
- Le nombre d’erreurs 5xx, avec une alerte sur tout pic.
- Le rapport entre pages indexées et URL totales : un écart de 30 % reste normal, au-delà de 70 % il y a un problème.
- Le taux de succès de vos soumissions : des échecs répétés désignent une cause systémique, pas un incident.