Une mise en ligne ajoute douze mille pages et le sitemap passe de 400 000 à 412 000 URL. Deux semaines plus tard, Search Console affiche un nombre agrégé de pages découvertes, mais personne ne sait quelles URL appartenaient au lancement ni quand leur premier crawl a eu lieu. Cette perte de traçabilité est une douleur opérationnelle : elle bloque le diagnostic, fait perdre une fenêtre de correction et expose la release à des décisions aveugles.
La méthode conserve un manifeste immuable de la cohorte, publie seulement les URL canoniques et indexables dans un sitemap opérationnel, puis rapproche dates de publication, soumission, premier hit Googlebot vérifié et état d’indexation. Elle mesure une distribution par gabarit sans transformer le sitemap en garantie.
Le vrai enjeu est la traçabilité d’une release. En réalité, ce n’est pas « créer davantage de sitemaps », c’est préserver l’appartenance de chaque URL à une vague. Contre-intuitivement, un sitemap historique ne doit pas rester éternellement soumis : le manifeste peut conserver la cohorte alors que le sitemap courant reste propre et utile.
Concrètement, l’offre Tech SEO et performance web relie pipeline de publication, XML, journaux et GSC. Le contrôle croise sitemap XML, maillage interne, canonicale, hreflang, robots.txt, noindex, redirection 301, code HTTP, cache, données structurées, logs serveur, Googlebot, budget de crawl, Search Console et indexation sans confondre leurs causalités.
Séparer déclaration et garantie
Nommer ce que prouve un sitemap
Un sitemap signale des URL que le site souhaite voir explorées et indique des informations associées. Google le présente comme un indice, pas une garantie de crawl ou d’indexation. La présence prouve une déclaration du site à une date, jamais un traitement effectif.
Le rapport Sitemaps peut afficher des pages découvertes après lecture du fichier. Ce nombre ne prouve ni récupération ni indexation. Si l’équipe veut dater le premier crawl, alors elle consulte les logs vérifiés ; en revanche, GSC apporte les états et tendances rapportés.
Écrire l’objectif. La cohorte répond à une question de livraison : quelle proportion de cette vague a été déclarée, découverte, crawlée et rapportée indexée après trois, sept, quatorze ou vingt-huit jours ? Elle n’est pas conçue pour revendiquer un classement ou une conversion.
Figer un manifeste de lancement
Créer l’identité avant publication
Le manifeste porte cohort_id, URL canonique attendue, gabarit, locale, date de publication, version, statut métier et empreinte. Il est généré avant la release et stocké en lecture seule. Une URL retirée ensuite reste dans l’historique avec son événement de sortie.
Les corrections ne réécrivent pas le passé. Une canonicale modifiée crée un événement daté et une nouvelle cible, tandis que l’URL initiale reste observable. Cette chronologie permet d’expliquer une perte plutôt que de faire disparaître la ligne gênante.
Contrôler les membres. La CI refuse doublons, URL hors host, fragments, 3xx attendus, non-indexables et identifiants absents. Vingt lignes par gabarit sont revues manuellement. Une strate « inconnue » bloque la livraison si elle dépasse 1 % de la cohorte.
Garder le sitemap courant propre
Publier uniquement des URL défendables
Le XML courant contient des URL absolues, canoniques, indexables et servies en 200. Il exclut redirections, 404, pages noindex et variantes. Le contrôle respecte 50 000 URL ou 50 Mo non compressés par fichier et utilise un index pour les volumes supérieurs.
Lorsqu’une page sort du périmètre, elle quitte le sitemap courant sans quitter le manifeste historique. Le signal opérationnel reste cohérent ; l’analyse de cohorte garde pourtant son dénominateur d’origine et son motif de sortie.
Versionner sans multiplier les fichiers. Un nom de sitemap peut rester stable tandis que son contenu porte hash, date et version dans le registre. Créer un fichier permanent par jour augmente la dette. Le manifeste, plutôt que le répertoire XML, assume l’histoire.
Distinguer quatre horloges
Publication, inclusion, crawl, état
La publication correspond à la première réponse publique 200 ; l’inclusion à l’ajout de l’URL dans un sitemap accessible ; le premier crawl au premier hit Googlebot vérifié ; l’état GSC à l’observation rapportée. La soumission du sitemap constitue un événement séparé lorsque le site indique effectivement le fichier à Google par Search Console, API ou robots.txt. Ces dates viennent de sources différentes et ne sont jamais remplacées par la même valeur.
Le délai publication→crawl mesure la découverte et la demande dans le système réel. Crawl→état observé inclut traitement et latence de reporting. Une page peut être récupérée sans être indexée ; la distinction protège le diagnostic.
Employer des fenêtres. Le rapport présente parts crawlées à J+1, J+3, J+7, J+14 et J+28, plus médiane et p90. Une seule moyenne cache les URL jamais crawlées. Les fenêtres s’adaptent à la cadence passée et au rôle de la page.
Rapprocher sitemap, logs et GSC
Attribuer une question à chaque source
Le manifeste définit la population ; le sitemap prouve la déclaration ; le crawl interne mesure les liens ; les logs prouvent les requêtes ; GSC rapporte des états. Aucune source ne remplace les autres. Le rapprochement utilise URL normalisée tout en gardant les formes brutes.
L’identité Googlebot est validée avant calcul. Les exemples GSC ne sont pas exhaustifs et l’Inspection d’URL décrit la version indexée, pas un test live. Les limites figurent dans chaque graphique.
Conserver les inconnues. Absence de log, quota API, erreur de collecte et URL sans état restent des classes distinctes. Une inconnue n’est ni « non crawlée » ni « non indexée ». Le taux de couverture accompagne tout pourcentage.
Segmenter sans créer de confusion
Choisir des mécanismes comparables
Gabarit, locale, profondeur, source de lien et état métier expliquent souvent les différences. Le rapport conserve des groupes assez grands et évite de croiser toutes les dimensions. Une petite famille critique peut faire l’objet d’un recensement.
Les résultats bruts et pondérés restent séparés. Suréchantillonner un template rare améliore son diagnostic, mais ne doit pas gonfler artificiellement sa part dans le taux global.
Comparer des vagues compatibles. Deux releases ne sont comparées que si type, saison, volume et pipeline sont proches. Plutôt que d’opposer un lancement produit à une mise à jour éditoriale, l’équipe construit un témoin historique ou simultané comparable.
Utiliser lastmod avec cohérence
Représenter un changement significatif
L’attribut lastmod correspond à la dernière modification importante de la page, pas à la génération du sitemap, au déploiement ou au copyright. Une date identique sur tout le catalogue à chaque build rend le signal non défendable.
Le pipeline produit la date depuis un registre de changements métier : texte principal, prix, disponibilité, données structurées ou liens importants. Une modification cosmétique n’actualise pas automatiquement l’ensemble.
Ne pas confondre cache et XML. La date du sitemap et l’en-tête HTTP Last-Modified ont des contrats distincts. Le second participe à la validation de cache. Ils peuvent partager une source fiable sans être forcés à l’égalité.
Arbitrer deux scénarios simulés
Douze mille pages en une release
Scénario simulé. Une plateforme publie 12 000 fiches, réparties sur trois gabarits. À J+7, 82 % ont reçu un hit, mais le gabarit C atteint seulement 31 %. Il se trouve à profondeur six et n’a aucun lien depuis les catégories.
Le canari ajoute des liens HTML à 400 fiches C, avec 400 témoins. Il s’étend si 80 % sont crawlées sous sept jours, si les 5xx restent sous 0,2 % et si aucune URL non canonique n’entre dans le sitemap.
Le sitemap mélange les vagues
Deuxième scénario simulé. Un fichier de 900 000 URL est reconstruit chaque nuit et toutes reçoivent la date du build. Le total découvert augmente, mais impossible de suivre les 8 000 nouveautés. Le correctif crée un manifeste, restaure les dates significatives et segmente les mesures par publication.
À J+14, la cohorte affiche 91 % de premier crawl contre 63 % sur une vague témoin antérieure. L’équipe présente une association soutenue par la correction du graphe, pas une promesse d’indexation. Les volumes restent fictifs.
Transformer les courbes en décisions
Associer le retard à une cause
- Absence de soumission : corriger le pipeline XML.
- Soumise mais sans liens : réparer le graphe et la profondeur.
- Hits avec 5xx ou 429 : traiter capacité et stabilité.
- Crawl réussi sans indexation : auditer canonicale, unicité, qualité et état métier.
Si le premier hit manque, alors enrichir le contenu ne répond pas encore au signal observé. En revanche, si le crawl est confirmé et l’état reste défavorable, l’analyse passe à la canonicalisation ou à la valeur.
Borner l’alerte. Une alerte exige un volume minimal, une fenêtre et une comparaison. Par exemple : plus de 500 URL, moins de 60 % crawlées à J+7 et écart supérieur à vingt points au témoin. Elle ouvre une enquête, pas un verdict.
Implémenter manifeste et collecte
Dans la chaîne de publication
Le job valide statut, canonicale et robots, génère cohort_id, écrit le manifeste immuable puis publie sitemap et contenu de façon ordonnée. Les champs published_at, sitemap_version et content_fingerprint relient base, XML et réponse.
Le collecteur de logs conserve IP fiable, host, chemin, statut, octets et temps amont ; une tâche valide les bots et calcule le premier hit. L’API GSC rejoint ensuite URL, propriété et date sans écraser la preuve HTTP.
Tester et rejouer. La CI refuse doublons, 3xx, 4xx, noindex, canonicale externe ou limite XML dépassée. Des fixtures simulent publication partielle, retard de sitemap et rollback. Relancer la même version reproduit le manifeste.
Relier endpoint, cron et rollback
L’endpoint manifeste définit l’entrée et la sortie. La responsabilité développement couvre le contrat XML ; SRE possède l’instrumentation, le monitoring et le seuil. La QA compare canonicals, JavaScript et SSR avant l’extension.
La journalisation de release assure la traçabilité. Un retry idempotent traite la file ; le runbook précise rollback et repli vers l’index précédent. Si l’écart dépasse 0,1 % ou si les 5xx franchissent 0,2 %, le canari est retiré.
Piloter un canari de publication
Préparer traité et témoin
Les groupes partagent gabarit, profondeur, locale et âge. Les seuils sont écrits avant livraison. Le déploiement reste à 5 % tant que réponses, liens et XML ne sont pas conformes sur deux contrôles consécutifs.
Le rollback retire le composant ou restaure l’ancien sitemap sans supprimer le manifeste. Le canari s’arrête si 0,5 % des URL changent de canonicale, si les 5xx dépassent 0,2 % ou si le parcours utilisateur recule de 3 %.
Lire sans sur-attribuer. Une hausse de crawl après correction du maillage soutient le mécanisme, mais saisonnalité et autres releases restent documentées. Deux cohortes concordantes renforcent la décision plutôt qu’une capture favorable.
Attribuer les responsabilités
Partager le contrat
Produit ferme la liste publiée ; développement génère manifeste et XML ; SEO définit indexabilité et strates ; SRE garantit réponses et logs ; data calcule les délais. Un responsable de release accepte l’extension selon les seuils.
Le dossier garde versions, exclusions, faits, interprétations et hypothèses. Les accès GSC et logs suivent le besoin. Une exception possède propriétaire et expiration.
Fermer la mesure. La cohorte reste archivée, mais les appels quotidiens cessent après la fenêtre de décision. Mesurer sans fin une vague stabilisée consomme quotas et attention sans produire d’action.
Éviter les erreurs fréquentes
Modifier silencieusement la cohorte. Retirer les échecs embellit le taux. Les sorties restent dans le manifeste avec motif et date.
Interpréter « découvert » comme « indexé ». Le rapport Sitemaps confirme un traitement du fichier, pas le crawl unitaire. Logs et inspection portent les autres horloges.
Promettre un classement. Le XML aide à la découverte ; il ne garantit ni inclusion ni position. Le succès du chantier reste une mesure technique bornée.
Plan d’action : instrumenter trois semaines
Semaine 1 : définir
- Fermer la population, les gabarits, l’unité et les fenêtres.
- Créer manifeste, identifiants et tests d’indexabilité.
- Valider sitemaps, source de
lastmodet logs bots. - Écrire seuils d’extension, arrêt et rollback.
La sortie contient manifeste test, XML canari, dictionnaire et contrôle manuel. Si plus de 1 % des URL sont inconnues ou si une seule répond autrement qu’en 200 attendu, la publication attend.
Semaines 2 et 3 : observer et décider
L’équipe publie 5 %, confirme liens et réponses, puis calcule soumission→crawl à J+1, J+3 et J+7. Elle joint GSC selon quota, inspecte extrêmes et compare le témoin. L’extension progresse par paliers après deux contrôles conformes.
Le bilan à J+14 ou J+28 présente numérateurs, inconnues, quantiles, incidents, mécanisme et limites. Il décide extension, correction ou arrêt. Une autre équipe reçoit requêtes, versions et propriétaire pour reproduire la preuve.
Décider avec des actions explicites
- Choisir l’extension : si deux fenêtres respectent couverture, statuts et premier crawl, alors publier le palier suivant.
- Corriger le pipeline : si le sitemap contient une URL non canonique ou absente, alors arrêter la soumission et réparer le manifeste.
- Refuser l’interprétation : si les logs ne couvrent pas 95 % de la fenêtre, alors ne pas conclure à une absence de crawl.
- Choisir le rollback : si les 5xx dépassent 0,2 % ou si 1 % des pages restent indisponibles, restaurer l’index précédent.
Cette liste est jointe au ticket de release avec propriétaire, commande, endpoint, seuil et date. Le comité ne laisse aucune sortie « à surveiller » sans condition de réouverture.
Préparer les contrôles de mise en production
Avant la bascule, une sonde extérieure récupère l’index de sitemap, le fichier opérationnel et vingt URL de chaque gabarit. Elle vérifie code 200, type XML, encodage, destination canonique et absence de directive d’exclusion. Le manifeste fournit les valeurs attendues ; le test ne dépend donc pas de chaînes écrites à la main dans la CI.
La livraison publie d’abord les pages, confirme leur accessibilité, puis expose le sitemap. Si le XML arrive avant les routes, Googlebot peut rencontrer des 404 transitoires. Un identifiant de release apparaît dans les logs, le registre de sitemap et le manifeste pour relier ces événements.
Traiter les sorties et les reprises
Une page retirée pendant le canari conserve son identifiant et reçoit un motif : erreur de données, décision produit, duplication ou panne. Le dénominateur initial ne change pas ; le rapport ajoute un taux de sortie. Lors d’une reprise, une nouvelle version corrige la page sans remplacer la chronologie précédente.
Si plus de 2 % de la cohorte sort pour erreur technique, alors l’extension s’arrête et le pipeline est corrigé. En revanche, une sortie métier prévue reste analysée séparément. Plutôt que d’additionner tous les retraits, la revue distingue qualité de livraison et évolution normale.
Rendre le bilan exploitable
Le compte rendu présente la distribution du temps avant premier crawl, des tables par gabarit et une liste de cas contradictoires. Il documente dates, couverture des logs, validation des bots et quota GSC. Les décideurs voient simultanément volume, confiance et action attendue.
Le succès ne se résume pas à davantage d’URL indexées. Une diminution du délai avant premier crawl montre que cette horloge s’est améliorée ; si le mécanisme corrigé et le témoin concordent, elle soutient l’hypothèse d’une meilleure découverte. L’indexation demande une analyse supplémentaire. À l’inverse, un sitemap propre peut réduire la dette même si la demande de crawl reste identique. Chaque bénéfice est nommé avec son niveau de preuve.
Pour qui adapter la méthode au volume
Catalogues et médias. La méthode complète convient aux lancements massifs et fréquents. Elle sépare des templates que le total de domaine rend invisibles.
Petits sites. Un simple fichier versionné avec publication, sitemap et premier hit suffit. Plutôt que de bâtir une plateforme, l’équipe conserve le contrat et la chronologie.
Gérer une publication partielle
Une release peut réussir sur deux gabarits et échouer sur le troisième. Le manifeste conserve les membres prévus, tandis qu’un état de publication indique lesquels répondent réellement en 200. Le sitemap n’inclut que les pages disponibles ; les autres ne disparaissent pas de l’analyse et gardent un motif d’attente, une version applicative et un propriétaire.
Si plus de 1 % du lot prévu reste indisponible après quinze minutes, alors la soumission XML est suspendue. En revanche, les gabarits conformes peuvent poursuivre si leur indépendance est prouvée. Cette décision évite de publier des URL mortes tout en refusant qu’un total agrégé cache une release incomplète.
Séparer recrawl et première découverte
Une cohorte peut mélanger nouvelles URL et pages modifiées. Les premières n’ont aucun hit antérieur ; les secondes possèdent une cadence historique. Le rapport sépare premier crawl depuis publication et première revisite après changement significatif. Comparer ces délais dans la même moyenne ferait paraître les anciennes pages artificiellement rapides.
Le manifeste porte donc release_action avec création, mise à jour, déplacement ou retrait. Si une mise à jour reçoit un 304 alors que son empreinte a changé, l’équipe contrôle ETag et Last-Modified. Si une création n’a aucun hit, elle revient au graphe, au sitemap et à la capacité.
Recetter les sitemaps imbriqués
Sur un grand catalogue, l’index pointe vers plusieurs fichiers par gabarit ou locale. Le test parcourt chaque enfant, calcule son hash, compte les URL et vérifie qu’aucune n’apparaît dans deux cohortes opérationnelles incompatibles. Il suit les redirections du fichier lui-même et exige une réponse finale 200 avec un contenu XML valide.
Le contrôle d’intégrité compare total de l’index, total des fichiers et total du manifeste publié. Un écart supérieur à dix URL ou 0,1 % bloque la release selon le plus strict. Cette double borne détecte aussi bien une petite omission critique qu’une dérive massive sur un lot de plusieurs millions.
Décider la fin de surveillance
La collecte intensive cesse lorsque deux fenêtres consécutives respectent le seuil de premier crawl, que les statuts publics sont stables et qu’aucun incident de cohorte n’est ouvert. Le manifeste demeure archivé, mais les inspections API quotidiennes s’arrêtent. Une revue mensuelle suffit ensuite pour détecter une dérive de gabarit.
À l’inverse, une cohorte qui n’atteint pas le seuil n’est pas surveillée indéfiniment. À J+28, le responsable choisit correction supplémentaire, acceptation documentée ou retrait. L’acceptation mentionne volume, risque, raison et condition de réouverture. La mesure conserve ainsi une fin opérationnelle et ne devient pas un tableau sans décision.
Vérifier sources et prolongements
Doctrine officielle. Google décrit la construction des sitemaps, leurs limites, leurs modes de soumission et leur statut d’indice. L’aide du rapport Sitemaps et celle de l’indexation bornent l’interprétation.
Garde-fous internes. Hors limites officielles de 50 000 URL et 50 Mo non compressés, les pourcentages, délais et paliers de ce protocole sont des exemples à calibrer sur le site ; ils ne constituent pas des règles Google.
Prolongements. L’échantillonnage GSC, la fiabilité de lastmod, la latence de découverte et le sitemap à grande échelle complètent le protocole.
Contrôler le contrat XML
La sonde récupère index et fichiers enfants depuis le réseau public, valide type MIME, schéma, encodage et limites, puis compare chaque URL au manifeste. Elle conserve hash, statut et heure afin que l’équipe puisse expliquer une différence entre fichier généré et fichier réellement servi.
Le lot est conforme si les totaux coïncident, si toutes les URL répondent en 200 et si aucune canonicale ne diverge. Une différence supérieure à dix URL ou 0,1 % arrête l’extension et ouvre une correction du générateur.
Auditer le premier hit
Le calcul utilise uniquement des IP Googlebot validées, le host public et l’horodatage du premier 200 après publication. Il distingue 304, redirection, 4xx et 5xx afin que la première requête ne soit pas confondue avec une récupération correcte du nouveau contenu.
Vingt chronologies par gabarit sont relues : publication, sitemap, lien, hit et état GSC. Si le p90 dépasse la fenêtre mais que les URL sans lien concentrent l’écart, la décision porte sur le graphe plutôt que sur le fichier XML.
Qualifier les retraits
Chaque sortie reçoit un motif métier ou technique, une date, un propriétaire et la réponse publique attendue. Le manifeste d’origine reste immuable ; une table d’événements permet de recalculer le taux actif sans réécrire le dénominateur historique.
Une sortie technique au-delà de 2 % bloque la release. Une sortie métier prévue reste présentée séparément. Cette distinction empêche un nettoyage du catalogue d’être interprété comme un échec d’indexation ou comme une amélioration artificielle.
Comparer le témoin
Le témoin partage gabarit, profondeur, locale et calendrier. Il n’est exposé à aucun changement de sitemap ou de maillage pendant la fenêtre. Les incidents globaux, saisonnalité et déploiements concurrents sont inscrits dans le registre de comparaison.
Une différence n’est retenue que si le mécanisme, la temporalité et deux fenêtres concordent. Si les distributions se chevauchent largement, l’équipe prolonge l’observation ou accepte l’absence d’effet plutôt que de sélectionner une date favorable.
Fermer la vague
La vague se ferme lorsque les seuils de statut, couverture et premier crawl sont atteints, que les incidents sont résolus et que le propriétaire accepte le bilan. Le cron intensif s’arrête, les quotas GSC sont libérés et le manifeste passe en archive immuable.
La surveillance mensuelle garde un échantillon réduit. Une dérive de dix points, cinq cents URL nouvelles sans hit ou une modification de template rouvre le protocole. L’arrêt devient ainsi réversible et fondé sur une condition mesurable.
Conclusion : conserver la cohorte
Le sitemap déclare des URL ; il ne garantit ni crawl ni indexation. Le manifeste préserve la population d’une release.
Publication, soumission, premier hit et état GSC restent quatre horloges. Leur rapprochement révèle le mécanisme sans confondre les preuves.
Un canari par gabarit et des seuils écrits rendent la correction réversible. Le sitemap courant reste propre pendant que l’histoire demeure auditable.
Pour instrumenter publication et suivre chaque vague, l’accompagnement Tech SEO et performance web de Dawap relie XML, logs, GSC et production.
