Pourquoi le hit/miss des crawlers est important
Les crawlers de recherche et d'IA représentent désormais une part majeure du trafic qui décide si vous êtes indexé, classé et cité. Googlebot et Bingbot pilotent le SEO classique. Une nouvelle vague de crawlers GEO (Generative Engine Optimization) (GPTBot, ClaudeBot, PerplexityBot, Google-Extended et d'autres) décide si votre contenu entre dans les réponses des IA.
Le piège : quand ces crawlers tombent sur un cache froid, ils obtiennent une réponse lente depuis votre origine. Chez Google, un serveur lent réduit de façon mesurable le volume crawlé. Côté assistants IA, l'enjeu est plus immédiat : ChatGPT-User, Claude-User et Perplexity-User récupèrent votre page pendant que quelqu'un attend une réponse, et aucun de ces éditeurs ne documente combien de temps ils acceptent d'attendre. Nous avons détaillé ce qui est documenté, et ce qui ne l'est pas, dans Comment les crawlers IA gèrent les pages lentes et le cache froid.
Savoir quels crawlers touchent votre cache, et s'ils ont obtenu un HIT ou un MISS, fait toute la différence entre deviner et piloter.
Pourquoi votre taux de hit global ne suffit pas
La plupart des tableaux de bord affichent un seul taux de cache hit pour tout le trafic. Ce chiffre est dominé par les visiteurs humains, qui se concentrent sur vos pages populaires et reconstruisent le cache d'eux-mêmes quelques minutes après une purge.
Les crawlers se comportent autrement, de deux façons qui jouent contre vous :
- Ils vont en profondeur. Un crawler parcourt votre longue traîne : vieux articles, page 14 d'une catégorie, variantes produit que personne n'a vues cette semaine. Ce sont les pages les moins susceptibles d'être en cache.
- Ils arrivent à leur propre rythme. Vous ne décidez pas quand GPTBot ou Googlebot passe, donc une partie de leurs requêtes tombe forcément juste après un déploiement ou une purge, avant que le trafic organique n'ait réchauffé quoi que ce soit.
Résultat, un cas fréquent et invisible : un site peut afficher un taux de hit global sain de 92 % pendant que ses crawlers IA prennent un MISS sur la moitié de leurs requêtes. On ne le voit qu'en découpant le taux par crawler.
Ce que nous avons construit
CacheBoost dispose maintenant d'une page Crawlers sur chaque site. Voici ce qu'elle donne sur notre propre site, cache-boost.com, sur les 7 derniers jours :
Elle affiche :
- Les chiffres clés : taux de hit global, total des crawls et répartition SEO/GEO, chacun avec sa tendance.
- Les hits et miss du cache au fil du temps, des dernières 24 heures jusqu'à 6 mois, avec vos préchauffages matérialisés sur le graphique pour voir l'effet de chacun sur le taux de miss.
- Un détail par crawler : taux de hit et nombre de requêtes pour chaque bot, étiqueté SEO (Googlebot, Bingbot, Baiduspider…) ou GEO/IA (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Amazonbot…).
- Des filtres pour afficher tous les crawlers, le SEO seul ou le GEO/IA seul.
Même sur notre propre site, le détail est parlant : pour un taux de hit global de 83 %, GPTBot reçoit une page en cache dans 91,5 % des cas, ClaudeBot seulement dans 64,5 %. Même site, même cache, une expérience très différente selon le crawler.
Le tout unifie deux sources de données dans une seule vue.
Cloudflare : la source fiable
Si votre site est sur Cloudflare, vous connectez un token API en lecture seule (créé depuis un modèle de token avec les permissions Zone > Analytics > Read, Account > Account Analytics > Read et Zone > Zone > Read). CacheBoost interroge l'API GraphQL Analytics de Cloudflare toutes les heures et lit le statut de cache réel de chaque requête de crawler. C'est le signal hit/miss autoritatif, car Cloudflare voit les requêtes que votre origine ne voit jamais, celles servies directement depuis le cache.
Un ping de vérification en un clic est inclus : nous récupérons votre page d'accueil en tant que GPTBot et confirmons qu'elle remonte bien dans vos analytics.
WordPress : détection côté origine
Pas de Cloudflare ? Le plugin WordPress CacheBoost Warmer détecte les user-agents des crawlers au niveau de l'origine et les remonte à votre tableau de bord. Une réserve honnête : une requête qui atteint WordPress a, par définition, déjà raté votre cache de page, la source WordPress se lit donc comme « quels bots ont atteint mon origine », tandis que Cloudflare reste la référence pour le vrai taux de hit.
Cette vue côté origine reste utile à elle seule. Si le nombre de requêtes GPTBot qui atteignent WordPress bondit chaque nuit à 3 h, vous avez trouvé votre fenêtre froide (souvent une mise à jour automatique nocturne qui a purgé le cache) sans même avoir besoin d'un CDN.
Pourquoi classer par user-agent suffit ici
Un user-agent peut être usurpé, et pour tout ce qui suppose de faire confiance à l'identité d'un crawler (autoriser, bloquer, limiter le débit), il faut la vérifier contre les plages d'IP publiées par chaque éditeur. Pour mesurer un taux de hit, en revanche, le classement par user-agent est le bon outil : personne n'a intérêt à simuler un en-tête GPTBot pour fausser votre graphique, une requête mal attribuée n'est donc que du bruit, pas un risque. C'est le compromis retenu par la page Crawlers.
Comment lire les graphiques
Après quelques jours de données, cherchez ces quatre profils.
1. Un taux de hit GEO nettement inférieur au taux SEO. C'est le constat le plus fréquent. Googlebot crawle votre site depuis des années et revisite plutôt les pages populaires ; les crawlers IA sont plus récents, ratissent plus large et arrivent par vagues. Si l'écart est important, préchauffez les pages qu'ils demandent réellement, pas seulement votre top 100.
2. Des creux alignés sur les déploiements ou les purges. Un profil en dents de scie (le taux chute brutalement puis remonte en quelques heures) signifie que chaque purge ouvre une fenêtre froide dans laquelle tombent les crawlers. La solution : faire du préchauffage la dernière étape du déploiement, voir Le préchauffage de cache, dernière étape de votre pipeline de déploiement.
3. Un taux de hit bas partout, pour tous les crawlers, en permanence. Ce n'est pas un problème de préchauffage mais de cachabilité. Si les pages ne sont pas cachables au départ (un Set-Cookie sur chaque réponse, un Cache-Control: private, une règle Cloudflare qui contourne le cache pour le HTML), aucun préchauffage ne produira de HIT. Dans Cloudflare, un statut DYNAMIC ou BYPASS en est le signe. Corrigez d'abord les règles de cache, puis préchauffez.
4. Aucun crawler GEO. Soit votre robots.txt les bloque, soit votre WAF les challenge avant qu'ils n'atteignent le cache. Les deux peuvent être volontaires. Sinon, c'est un problème de visibilité plus grave que n'importe quel taux de hit.
Pour situer ces chiffres, les mêmes repères s'appliquent que pour le trafic global :
| Taux de hit des crawlers | Ce que cela signifie |
|---|---|
| > 90 % | Les crawlers reçoivent presque toujours une page en cache |
| 70–90 % | Quelques fenêtres froides ; regardez quand tombent les miss |
| 50–70 % | Les crawlers atteignent régulièrement l'origine ; le préchauffage sera vite rentable |
| < 50 % | Vérifiez la cachabilité avant tout |
Boucler la boucle : du graphique au préchauffage
Un graphique n'a d'intérêt que s'il fait changer quelque chose. Une fois que vous savez où les crawlers ratent le cache, le côté préchauffage est simple :
- Préchauffez la variante que reçoivent réellement les crawlers. Si votre clé de cache varie selon le user-agent (certaines configurations servent une variante dédiée aux bots), ajoutez un user-agent bot ou crawler IA aux variations de votre boost. Si elle ne varie pas, un seul préchauffage couvre tout le monde et les variantes en plus ne font que consommer des URLs.
- Préchauffez après chaque purge, pas seulement selon un planning. Déclenchez un boost depuis votre pipeline de déploiement ou laissez le plugin WordPress le faire sur les événements de purge, puis gardez une planification cron comme filet de sécurité pour l'expiration des TTL.
- Préchauffez depuis les régions d'où viennent vos crawlers. Cloudflare met en cache par emplacement. Des crawlers qui arrivent sur un edge américain ne profitent pas d'un cache préchauffé en Europe.
- Laissez passer le trafic de préchauffage. Si vous préchauffez avec des user-agents de bots, votre WAF peut challenger les requêtes qui se présentent comme GPTBot depuis une IP qui n'appartient pas à OpenAI. Autorisez d'abord le trafic CacheBoost, sinon le tableau de bord affiche un succès pendant que le cache reste froid.
Revenez ensuite sur la page Crawlers une semaine plus tard. Le taux de miss doit avoir baissé et les dents de scie s'être aplanies. Sinon, le graphique vous dit dans lequel des quatre profils vous êtes encore.
Confidentialité dès la conception
Nous ne stockons que des compteurs. Les user-agents sont classés en un nom de crawler connu puis jetés ; nous ne conservons jamais les user-agents bruts, les URLs ni les adresses IP. Les graphiques sont construits à partir d'agrégats horaires.
Comment l'activer
Le suivi des crawlers est inclus dans toutes les offres, y compris l'offre gratuite.
- Ouvrez un site validé et cliquez sur Analyse des crawlers.
- Connectez Cloudflare (collez votre token en lecture seule, choisissez la zone) ou activez le suivi des crawlers dans le plugin WordPress.
- Envoyez le ping de vérification et regardez les données arriver.
À lire aussi : Comment les crawlers IA gèrent les pages lentes et le cache froid, Pourquoi le préchauffage de cache est crucial pour le SEO et le GEO et Comment mesurer votre taux de cache hit.
