Pendant la nuit

À 3 h du matin, heure du Pacifique, mon site de production traite plus de requêtes qu’à n’importe quel moment de la journée. Pas pour des utilisateurs. Pour des robots.

Googlebot explore 21 000 pages. Bingbot en explore 10 000. Ma vérification nocturne complète passe au crible 15 000 articles de blog et pages d’entreprises. Un préchauffage alimente le cache edge de Cloudflare pour le trafic du lendemain. Au total, les processus nocturnes touchent plus de pages que l’ensemble des visiteurs humains réunis.

Le site que je construis pendant la journée n’est pas celui qui compte le plus. Celui qui compte le plus, c’est celui que les robots d’indexation voient à 3 h du matin.

Le recensement d’exploration

Chaque jour, je lance un recensement d’exploration qui comptabilise ce que les robots ont vu au cours des dernières 24 heures. Ce recensement utilise l’API d’analytique de Cloudflare, filtrée par user agent. Les chiffres racontent ce que les moteurs de recherche valorisent :

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

Les offres d’emploi consomment la moitié du budget d’exploration. Googlebot explore 10 654 pages d’emploi par jour. Le sitemap d’emplois n’a pas de plafond. Chaque offre éligible y figure. La répartition du budget d’exploration m’indique ce que Google considère comme le contenu de plus haute valeur sur le site.

Les articles de blog reçoivent 298 explorations par jour alors qu’ils constituent le contenu de la plus haute qualité. Le ratio d’investissement en exploration (les emplois 50 fois plus que le blog) ne correspond pas à l’investissement en contenu (le blog demande 100 fois plus d’effort par page que les emplois). Les moteurs de recherche explorent ce qu’ils peuvent indexer à grande échelle, pas ce qui a demandé le plus d’effort à produire.

Les entreprises reçoivent 14 explorations par jour malgré plus de 7 000 pages dans le sitemap. C’est un problème de famine du budget d’exploration : les pages d’emploi consomment tellement de budget que les pages d’entreprises sont à peine découvertes. Les données nocturnes ont révélé ce problème. Sans le recensement, je n’aurais jamais su que 7 000 pages d’entreprises sont essentiellement invisibles pour les robots d’indexation.

Ce que le code 410 révèle

Le recensement suit les codes de statut HTTP. Le plus intéressant est le 410 : Gone.

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

Plus d’un tiers de toutes les requêtes des robots d’indexation tombent sur des pages d’emploi expirées qui renvoient un 410. Ce sont des offres qui existaient lorsque le robot les a découvertes pour la première fois, qui ont été indexées, puis supprimées depuis. Le 410 signifie au robot : « cette page a existé mais a définitivement disparu, cessez de la demander. »

Le taux de 410 diminue. La semaine dernière, il était de 8 858 pour Google. Cette semaine, il est de 7 614. Les robots apprennent. Chaque jour, le nombre de requêtes fantômes baisse à mesure que les moteurs de recherche mettent à jour leurs index. Mais l’apprentissage est lent. Le taux de 410 de Bing (42,3 %) est plus élevé que celui de Google (35,5 %) parce que Bing traite plus lentement les signaux de suppression.

La tendance des 410 est le signal nocturne le plus parlant. Elle m’indique la vitesse à laquelle les moteurs de recherche convergent vers l’état actuel du site. Un taux de 410 en hausse signifie que je supprime du contenu plus vite que les robots ne peuvent s’adapter. Un taux en baisse signifie que l’index rattrape son retard. L’équilibre, c’est zéro 410 — ce qui signifie que chaque page demandée par le robot existe encore.

Le problème des 524

Cloudflare renvoie un 524 lorsque le serveur d’origine ne répond pas dans le délai imparti. Lors d’une journée de déploiement intense (87 commits), le recensement a montré :

Google 524s:  68  (0.3%)
Bing 524s:    0

Soixante-huit dépassements de délai d’origine en 24 heures. Chacun signifie que Googlebot a demandé une page, Cloudflare a transmis la requête à Railway, et Railway n’a pas répondu à temps. La cause la plus probable : les redémarrages des workers Railway lors de déploiements fréquents. Chaque déploiement redémarre l’application, créant une brève fenêtre où les requêtes expirent.

Pour 0,3 % des explorations, Google a vu un site en panne. Les erreurs 524 n’apparaissaient dans aucun journal applicatif parce que l’application ne tournait pas au moment où elles se produisaient. L’erreur n’existait que dans l’espace entre Cloudflare et Railway, visible uniquement à travers le recensement d’exploration.

Le lendemain matin, le compteur de 524 est retombé à zéro. Les déploiements avaient cessé. Les workers étaient stables. Les données nocturnes ont confirmé que le problème était un churn transitoire de déploiement, pas un défaut structurel.

Le préchauffage du cache

Avant l’arrivée des robots, le préchauffage s’exécute. Il récupère chaque article de blog, chaque variante locale et 50 pages d’entreprises via le cache edge de Cloudflare. L’objectif : s’assurer que lorsque Googlebot atteint une page, il obtient une réponse mise en cache plutôt que d’attendre un rendu depuis l’origine.

La différence est significative. Un article de blog en cache répond en 80 ms. Un article non mis en cache prend 1,5 seconde depuis l’origine. Googlebot dispose d’un budget de taux d’exploration mesuré en requêtes par seconde. Des réponses plus rapides signifient plus de pages explorées dans la même fenêtre. Un cache préchauffé double la couverture effective d’exploration.

Le préchauffage est invisible pour les utilisateurs. Aucun visiteur humain ne bénéficie d’un article de blog mis en cache à 2 h du matin. Néanmoins, le préchauffage détermine si Googlebot découvre 300 ou 600 articles de blog dans sa fenêtre nocturne. L’impact SEO est réel même si aucun humain ne voit le mécanisme.

Ce que la nuit révèle

Chaque matin, je lis les journaux de la nuit. Le schéma est toujours le même : essentiellement du vert, quelques anomalies, une ou deux choses à examiner. Le rythme est ennuyeux. La valeur réside dans ce rythme ennuyeux.

Une nuit ennuyeuse signifie que les déploiements n’ont rien cassé, les robots ont trouvé ce qu’ils attendaient, le cache fonctionne et le site est prêt pour le trafic du lendemain. Une nuit intéressante signifie que quelque chose a changé : un nouveau schéma d’erreur, une règle de cache qui ne fonctionne plus, un changement de budget d’exploration qui indique une modification des signaux de classement.

Le recensement d’exploration m’a montré que 7 000 pages d’entreprises sont invisibles pour Google. Aucune métrique diurne ne l’aurait révélé. Les analytics utilisateur montrent zéro trafic sur les pages d’entreprises, ce que j’attribuais à une faible demande. Le recensement a montré zéro exploration de ces pages, ce qui signifie que Google n’a même pas évalué ces pages. Le problème n’est pas la demande. Le problème, c’est la découvrabilité.

L’analyse des 524 m’a montré que les déploiements Railway créent des fenêtres de dépassement de délai d’origine que Googlebot rencontre. Aucun monitoring applicatif ne l’aurait révélé parce que l’application ne tourne pas pendant le dépassement de délai. Le problème réside dans le fossé d’infrastructure entre le déploiement et la disponibilité.

La tendance des 410 m’a montré que Bing traite les signaux de suppression 20 % plus lentement que Google. Cela compte pour le SEO : les pages d’emploi expirées restent plus longtemps dans l’index de Bing, servant potentiellement des résultats obsolètes aux utilisateurs qui effectuent des recherches sur les plateformes propulsées par Bing (DuckDuckGo, Yahoo).

Chacune de ces découvertes provient des données nocturnes. La journée vous dit ce que font les utilisateurs. La nuit vous dit ce que fait l’infrastructure quand vous ne regardez pas. Les deux comptent. La nuit compte davantage pour le SEO.

FAQ

Comment exécutez-vous le recensement d’exploration ?

Le recensement utilise l’API GraphQL d’analytique de Cloudflare (httpRequestsAdaptiveGroups) filtrée par patterns de user agent (%Googlebot% et %bingbot%). Il catégorise les pages par préfixe de chemin URL et agrège les codes de statut. Le script s’exécute en 30 secondes et produit une comparaison côte à côte du comportement d’exploration de Google et de Bing.

Pourquoi ne pas utiliser Google Search Console pour les données d’exploration ?

Google Search Console rapporte les statistiques d’exploration avec un délai de 2 à 3 jours et une granularité limitée. Le recensement Cloudflare est en temps réel (dernières 24 heures) et inclut les codes de statut, les catégories de contenu et l’état du cache que GSC ne rapporte pas. GSC est utile pour les tendances. Le recensement est utile pour les décisions opérationnelles.

Le préchauffage augmente-t-il les coûts Cloudflare ?

Non. Les caches Cloudflare sont alimentés par n’importe quelle requête, quelle que soit la source. Le préchauffage utilise des requêtes HTTP standard qui comptent dans le quota normal de requêtes. Avec l’offre gratuite, il n’y a pas de limite de requêtes pour les réponses en cache. Les requêtes d’origine pendant le préchauffage comptent dans la bande passante de Railway, mais avec 15 000 pages d’environ 50 Ko chacune, le total est d’environ 750 Mo par préchauffage.

Que se passe-t-il si les robots changent de comportement ?

Le recensement capture tout ce que font les robots, indépendamment des changements. Un changement de schéma d’exploration (plus de pages d’emploi, moins de pages de blog) apparaît immédiatement dans le prochain recensement. Les données de tendance sur plusieurs jours révèlent si le changement est une anomalie ponctuelle ou une évolution durable.

Sources

Cet article s’appuie sur les données quotidiennes du recensement d’exploration collectées via l’API GraphQL de Cloudflare depuis mars 2026. Outil de recensement : ~/Projects/Utility/crawl_census.py. Outil de vérification nocturne : ~/.claude/skills/nightcheck/.