Comment une page est découverte et explorée à nouveau

Il y a ici trois questions distinctes, qui ont trois réponses différentes : comment un robot d’exploration trouve une page, à quelle vitesse il apprend que la page a changé, et ce que vous pouvez voir du résultat. Cette page répond aux trois questions avec les minuteries réelles.

Comment un robot d’exploration trouve-t-il une page, au juste ?#

Deux voies automatiques basées sur des requêtes :

1. Le plan du site. Chaque propriétaire reçoit un sitemap.xml répertoriant chaque page de chaque dépôt indexé, ainsi qu’une entrée par langue réellement traduite. Il est diffusé sur l’hôte propre au site et reconstruit au plus une fois par heure.
2. robots.txt le nomme. Chaque hôte hébergé par Docsbook fournit un robots.txt avec une ligne Sitemap: pointant vers le plan du site correspondant à cet hôte. Le domaine racine en comporte plusieurs : le sien, un par site de documentation produit et un par site vitrine public dont le SEO est activé — car ces sites ne sont accessibles que depuis le domaine racine, de sorte que rien d’autre n’indiquerait leur emplacement à un robot d’exploration.

En outre, la barre latérale est rendue sous forme de véritables liens HTML sur chaque page, de sorte que chaque exploration d’une page constitue également une exploration du plan de votre contenu.

À quelle vitesse une modification atteint-elle un moteur ?#

Push. Lorsqu’une modification est publiée via Docsbook — l’éditeur, un agent, les outils MCP, une modification des paramètres de l’espace de travail — Docsbook invalide immédiatement ses propres caches pour ce site et, pour les sites hébergés sur l’apex docsbook.io, envoie également une notification IndexNow indiquant la racine du site et son sitemap. Cet appel est exécuté sans attendre : il indique deux URL plutôt que les pages modifiées (à ce stade, seule l’information « ce site a changé » est connue, et le sitemap permet à un moteur participant de déterminer les détails), il ne bloque ni n’échoue jamais lors de la publication, et une interruption d’IndexNow est journalisée plutôt que signalée.

Pull. Tout le reste attend qu’un robot d’exploration revienne consulter à nouveau le sitemap.

Et voici la partie honnête : Docsbook n’a pas de webhook GitHub. Un commit envoyé directement vers votre dépôt, en contournant Docsbook, ne déclenche ni invalidation ni envoi IndexNow. Il est pris en compte par des minuteries :

Ainsi, une page modifiée dans Docsbook est à jour pour le prochain robot d’exploration en quelques secondes ; une page envoyée directement vers GitHub peut être servie depuis le cache pendant 24 heures au maximum. Cette fenêtre de 24 heures est un compromis délibéré : les explorations de robots qui réaffichaient chaque page toutes les heures représentaient de loin le plus gros poste de la facture d’hébergement, et les pages de documentation sont consultées bien plus souvent qu’elles ne sont modifiées.

Que se passe-t-il lorsqu’une page est renommée ?#

Un déplacement effectué via Docsbook écrit l’ancien chemin de page → le nouveau chemin de page dans un .docsbook/redirects.json fichier lors du même commit que le déplacement, et l’ancienne URL renvoie alors une redirection permanente 308 vers la nouvelle. Permanente, et non temporaire, car une redirection temporaire indique aux moteurs de recherche de conserver l’URL obsolète comme URL canonique — ce qui fait perdre précisément le classement que la redirection est censée préserver. La correspondance contient jusqu’à 500 entrées, les plus anciennes étant supprimées en premier, et elle n’est consultée que pour les requêtes qui se dirigeaient déjà vers une erreur 404.

Un renommage effectué en déplaçant vous-même le fichier dans git n’obtient aucune redirection : rien n’a écrit la correspondance. Vous pouvez ajouter l’entrée manuellement — il s’agit d’un fichier texte dans votre dépôt, et les deux côtés sont des chemins de page, c’est-à-dire ce qui apparaît dans une URL.

Que fait réellement l’intégration de Search Console ?#

Elle lit. Les données circulent dans un seul sens, de Google vers Docsbook, via l’étendue Search Analytics en lecture seule. Docsbook n’envoie pas d’URL, ne demande pas d’indexation et n’écrit rien dans votre compte Search Console. Vous n’avez rien à connecter : Docsbook lit une propriété de domaine Search Console sur docsbook.io, qui, selon la définition de Google, « regroupe les données de tous les sous-domaines, protocoles et sous-chemins », puis filtre les lignes pour ne conserver que les URL appartenant à votre site.

Ce qui apparaît dans le panneau d’administration : la position moyenne, les impressions, les clics, les requêtes sur lesquelles vos pages sont classées, une tendance quotidienne et un ensemble de requêtes « à améliorer » — celles qui se situent entre les positions 5 et 20, déjà visibles, mais qui ne sont pas encore gagnantes. Les périodes disponibles sont de 7, 28 et 30 jours ; 7 jours est la valeur par défaut, car seules 30 journées d’historique sont conservées. C’est donc la seule période disposant d’une durée équivalente à comparer en amont.

Trois contraintes sont affichées plutôt que masquées. Les données de Google accusent environ deux jours de retard, c’est pourquoi une date « données disponibles jusqu’au » est toujours visible. Un actualisation est autorisée toutes les 24 heures, car Google actualise lui-même les données quotidiennement et une seconde récupération consommerait du quota pour renvoyer des chiffres identiques. Les totaux principaux sont agrégés au niveau de la page, et non calculés en additionnant les lignes de requêtes : Google masque les requêtes à faible volume pour des raisons de confidentialité, de sorte que la ventilation par requête ne couvre qu’une fraction du trafic réel. Notre propre mesure, effectuée sur la propriété de documentation de Docsbook : 91 impressions en totalisant par requête, contre 413 en totalisant par page. Il s’agit d’un seul site sur une seule journée ; ce chiffre est cité pour montrer l’orientation de l’écart, et non son ampleur sur votre site.

Pourquoi ces mécanismes (preuves)#

Limites et questions ouvertes#

• IndexNow n'est pas envoyé pour les sites clients aujourd'hui. Le protocole exige que chaque URL d'une soumission partage un même hôte et qu'un fichier de clé se trouve à la racine de cet hôte. Docsbook héberge cette clé uniquement sur le domaine apex docsbook.io, de sorte que les envois sont effectués pour la propre documentation de Docsbook et pour les sites de démonstration sur le domaine apex — mais pas pour les sites <owner>.docsbook.io et pas pour les domaines personnalisés. L'hébergement d'une clé par locataire est une tâche distincte qui n'est pas encore mise en œuvre.
• Question en suspens : à quelle vitesse IndexNow fonctionne-t-il réellement ? Le commentaire du code de Docsbook indique « en quelques minutes au lieu d'attendre leur prochaine exploration planifiée ». La FAQ d'IndexNow elle-même se contente d'indiquer que cela « augmente la probabilité que les changements importants soient découverts et explorés plus rapidement », sans donner de délai. Considérez les quelques minutes comme un espoir, et non comme une mesure — nous n'en avons publié aucune.
• Google ne participe pas à IndexNow. indexnow.org indique que la prise en charge provient de « Microsoft Bing, Naver, Seznam.cz, Yandex, Yep » — cinq moteurs, et Google n'en fait pas partie, ni sur cette page ni dans la documentation du protocole. La découverte par Google repose toujours sur le sitemap et sur l'exploration habituelle.
• Question en suspens : à quel point la clé IndexNow est-elle secrète ? Docsbook considère la clé comme un identifiant public — elle est codée en dur et exposée, et le fichier de clé est servi sans authentification à la racine du domaine apex, ce que la FAQ exige (« aucune connexion requise », afin qu'un moteur de recherche puisse « confirmer la propriété du domaine »). Ce qui contredit l'interprétation selon laquelle « ce n'est pas un secret », c'est la propre page du protocole IndexNow, qui indique « Vous seul et les moteurs de recherche devriez connaître la clé et l'emplacement du fichier de clé ». Les deux affirmations ne peuvent pas être entièrement vraies pour un fichier que n'importe quel client peut récupérer. Les capacités de la clé en cas de copie sont limitées — elle indique seulement que « cet hôte a changé », rien de plus — mais considérez « public par construction » comme notre interprétation d'un protocole qui ne l'affirme pas.
• La couverture de Search Console s'arrête aux hôtes hébergés par Docsbook. La propriété de domaine couvre docsbook.io et ses sous-domaines. Un site sur votre propre domaine personnalisé n'est pas inclus dans cette propriété, et aucune position n'y est donc relevée. La fourniture de ces chiffres nécessite un processus d'autorisation Google par client, qui n'existe pas encore — utilisez votre propre compte Search Console pour un domaine personnalisé en attendant.
• L'historique de Search Console est ici limité à 30 jours. Google en conserve considérablement davantage ; Docsbook stocke une fenêtre glissante de 30 jours par site, raison pour laquelle la vue sur 30 jours ne comporte aucune période de comparaison.
• Rien ici ne permet à une page d'obtenir un meilleur classement. La découverte et la nouvelle exploration sont les parties que Docsbook peut automatiser. Le classement d'une page explorée relève de la décision de Google concernant votre contenu, et aucun minuteur sur cette page ne le modifiera.

Articles connexes#

• SEO — ce que Docsbook fait pour la visibilité dans les moteurs de recherche
• Comment Docsbook construit l’en-tête d’une page
• Analyses
• GEO — être cité par les assistants IA
• Traductions par IA