Le rapport d’indexation de Search Console montre quelques centaines d’exemples sous un état en hausse. L’équipe ouvre les premières URL, reconnaît des filtres ou des fiches pauvres et généralise leur cause à tout le catalogue. Le raccourci est séduisant, mais il ignore les familles absentes de l’interface et la sélection des exemples.
La méthode construit la population depuis le CMS, les sitemaps, le crawl et les routes, puis la découpe par gabarit, âge, découverte et enjeu. Un tirage aléatoire reproductible alimente ensuite Search Console et l’API d’inspection, avec des dénominateurs, des poids et des inconnues visibles.
Le vrai enjeu est une estimation capable de déclencher une correction de template. En réalité, ce n’est pas « inspecter mille URL », c’est savoir quelle population chaque observation représente. Contre-intuitivement, une petite strate critique mérite parfois un recensement complet, tandis qu’un immense catalogue homogène peut être diagnostiqué avec un tirage borné.
Concrètement, l’accompagnement Tech SEO et performance web relie inventaire interne, états GSC et réponses publiques. Il transforme une liste d’exemples en décision reproductible, sans présenter une hypothèse d’indexation comme un fait.
Ne pas confondre exemples et population
Donner le bon rôle à l’interface
Search Console fournit tendances et URL exemples pour diagnostiquer. Sa documentation indique que la liste n’est pas exhaustive et qu’elle est limitée. Une ligne prouve un état rapporté à une date ; elle ne mesure pas la proportion de son gabarit et ne documente aucun tirage aléatoire.
Les exemples restent excellents pour reproduire un défaut, comparer des canonicales ou ouvrir les logs. Si l’objectif est un taux, alors le cadre vient du site. En revanche, si l’objectif est un cas technique, quelques exemples suffisent. Le protocole dépend de la question.
Séparer fait et généralisation. « Cette URL est rapportée non indexée » est un fait horodaté. « Tout le template est faible » est une interprétation. « Enrichir augmentera le trafic » est une hypothèse. Le rapport garde ces niveaux distincts afin que la conclusion ne dépasse jamais la couverture réelle.
Construire le cadre depuis le site
Réconcilier quatre inventaires
Le CMS connaît contenus actifs et états métier ; les sitemaps montrent les URL déclarées ; le crawl révèle le graphe ; les logs prouvent les demandes publiques. Leur union forme un manifeste daté. Les écarts — page active sans lien, URL retirée encore demandée — deviennent des signaux à qualifier.
Chaque ligne garde URL brute, canonicale calculée, type, locale, publication, changement significatif, statut HTTP, robots, canonicale HTML, liens, profondeur et sitemap. Une version fige la population pendant le tirage, même si le catalogue continue d’évoluer.
Définir l’unité. L’unité peut être URL, contenu canonique ou paire URL-locale. Pour auditer les variantes, elles restent distinctes ; pour mesurer des produits, elles peuvent être regroupées avec leur cardinalité. Les exclusions et la strate « non classée » restent publiées plutôt que supprimées silencieusement.
Stratifier par mécanisme et enjeu
Commencer par le gabarit
Produit, catégorie, marque, ville, profil et éditorial portent des liens, canonicales et données structurées différents. L’âge sépare lancement et stock ancien ; l’état métier distingue actif, indisponible et retiré ; la découverte ajoute sitemap, profondeur et premier hit. Une classe business priorise l’effort sans devenir un signal attribué à Google.
Les dimensions ne sont croisées que lorsqu’elles soutiennent une hypothèse. Dix axes créeraient des cellules vides. Une strate de quarante pages critiques peut être recensée, tandis qu’une famille de 800 000 produits reçoit un échantillon.
Pondérer le suréchantillonnage. Les petites familles sont volontairement surreprésentées pour rester visibles. Le rapport montre leurs résultats bruts puis une estimation globale pondérée selon la population. Plutôt que d’écraser un défaut rare dans une moyenne, il conserve l’action propre à chaque mécanisme.
Dimensionner sans fausse précision
Relier taille et décision
Trente à cinquante URL par strate peuvent détecter un défaut massif ; une migration irréversible exige davantage. La taille dépend de la proportion attendue, de la marge d’incertitude, de la population finie et du taux de non-réponse. Le rapport publie ces hypothèses plutôt qu’un nombre magique.
Si une correction devient rentable dès que 20 % du template est atteint, alors une précision de deux points n’est pas nécessaire. En revanche, comparer deux variantes proches demande plus de données. L’échantillon sert l’arbitrage, pas une précision décorative.
Intégrer les quotas. La documentation actuelle de l’API indique 2 000 requêtes quotidiennes par site et 600 par minute. Six mille inspections demandent au moins trois jours, hors reprises. Quota, autorisation et timeout sont planifiés comme des non-réponses, jamais traduits en « non indexée ».
Tirer un échantillon reproductible
Figer manifeste, graine et quotas
Le tirage part d’un identifiant stable, d’une graine enregistrée et d’un quota par strate. Un ordre pseudo-aléatoire déterministe rend le résultat identique sur le même manifeste. Une autre équipe peut donc reproduire la sélection et vérifier qu’aucune URL commode n’a été choisie à la main.
Les remplacements concernent seulement les URL réellement inaccessibles et restent journalisés. Écarter un cas compliqué parce qu’il contredit l’hypothèse introduit un biais. La raison, la strate et le taux de remplacement figurent dans le bilan.
Combiner panel fixe et renouvellement. Une partie des URL reste fixe pour mesurer l’évolution ; une autre est renouvelée pour couvrir le stock actuel. Ce panel hybride sépare changement réel et bruit de tirage. Une sortie métier du panel est conservée comme événement, sans remplacement rétroactif.
Utiliser Inspection d’URL selon ses limites
Distinguer version indexée et test public
L’API renvoie des informations sur la version présente dans l’index, pas un test live de la page. Le pipeline collecte séparément statut public, destination, robots, canonicale et empreinte. Les deux preuves portent une date et peuvent légitimement diverger pendant un traitement.
Les demandes manuelles ne servent pas à forcer chaque URL. Google précise qu’elles ne garantissent ni inclusion ni traitement immédiat. Sitemap, liens, qualité, statut et mécanisme commun restent les leviers ; l’inspection mesure un état.
Conserver toutes les erreurs. Réponse valide, absence, quota, timeout, hors propriété et autorisation sont des classes séparées. Si le taux inconnu dépasse 10 % dans une strate critique, alors la collecte continue. En revanche, aucune erreur de transport ne rejoint le dénominateur des URL non indexées.
Conserver preuves et inconnues
Rendre chaque ligne auditable
URL, strate, date, version du manifeste, réponse brute, preuve HTTP, parseur et annotation sont stockés. La vue normalisée peut évoluer sans écraser la source. Les champs manifest_version, stratum_id et draw_seed relient population, tirage et mesure.
Le rapport écrit « 72 réponses indexées sur 100 valides, avec 8 inconnues sur 108 tirées » plutôt que « 72 % ». Numérateur, dénominateur et couverture préviennent la fausse précision.
Montrer les extrêmes. Quantiles et taux sont accompagnés de cas ordinaires, contradictoires et extrêmes. Une moyenne peut sembler saine tandis qu’un template entier échoue. L’analyse revient aux réponses et au graphe avant d’attribuer une cause.
Arbitrer deux scénarios simulés
Le gabarit rare invisible
Cas concret simulé. Par exemple, une marketplace compte 900 000 produits, 80 000 catégories, 12 000 profils et 600 villes. Un tirage simple de 500 URL ne contient aucune ville, dont le template perd pourtant sa canonicale. La moyenne globale masque entièrement le défaut.
Le plan inspecte 120 villes et 120 URL de chaque autre type. Il trouve 94 % de divergences sur les villes contre moins de 3 % ailleurs. Un seuil de 15 % déclenche un canari de cinquante pages plutôt qu’une refonte globale.
Le stock saisonnier
Deuxième scénario simulé. Un catalogue de 240 000 pages mélange 40 000 offres publiées depuis dix jours et 200 000 pages stables. Le taux brut vaut 61 % ; par âge, le nouveau stock atteint 28 % et l’ancien 88 %. La décision audite publication et découverte, pas le contenu entier.
Le pilote s’étend si 85 % de la cohorte reçoit un premier crawl sous sept jours et si les 5xx restent sous 0,2 %. Ces volumes illustrent la méthode et ne décrivent aucun résultat client.
Transformer les taux en décisions
- Comparer Search Console et logs serveur pour distinguer crawl, Googlebot et état d’indexation observé.
- Contrôler sitemap XML, maillage interne, canonicale et hreflang dans chaque gabarit de l’échantillon.
- Vérifier robots.txt, noindex, redirection 301 et code HTTP avant de classer une URL non conforme.
- Rapprocher cache, Core Web Vitals, données structurées et budget de crawl sans fusionner leurs causalités.
Associer chaque signal à un levier
- Défaut de template : corriger liens, canonicale, robots ou données structurées sur un canari.
- Défaut de nouveauté : contrôler publication, sitemap, profondeur et premier hit.
- Défaut métier : revoir statut, disponibilité, doublons et retraits avec produit.
- Résultat incertain : augmenter tirage ou couverture avant une mutation large.
Si les intervalles se recouvrent largement, alors l’équipe collecte davantage plutôt que de déclarer une différence. En revanche, un défaut présent sur 45 cas sur 50 avec une preuve publique concordante justifie un test immédiat.
Refuser le score sans mécanisme. Une priorité combine volume touché, risque, confiance et coût de correction, mais conserve chaque composante. Elle ordonne les enquêtes ; elle ne remplace ni la réponse publique ni la causalité.
Implémenter le pipeline de collecte
Assembler les tâches
L’endpoint expose les champs du cadre. La responsabilité data couvre l’entrée et la sortie du tirage ; SEO possède le contrat, l’instrumentation et le monitoring des quotas. La QA compare canonicals, rendu JavaScript, SSR et hydratation dans chaque strate de gabarit.
La journalisation de manifeste, graine et parseur assure la traçabilité. Un retry idempotent traite la file et protège la dépendance GSC. Si les inconnues dépassent 10 %, alors le rollback restaure le mapping, le repli lit les réponses brutes et le runbook interdit tout remplacement.
Séparer collecte brute et interprétation
Une tâche extrait CMS, sitemap et crawl ; une seconde calcule strate, poids et ordre ; une file appelle l’API avec quota et reprise exponentielle. Le collecteur HTTP enregistre statut, destination, robots, canonicale et empreinte au même instant. Réponse brute, vue normalisée et annotation restent séparées.
La CI vérifie unicité, somme des quotas, stabilité avec la même graine, absence de strate critique vide et déterminisme. Des fixtures simulent 429, timeout, hors propriété et canonicale divergente. Une inconnue ne devient jamais zéro.
Borner la qualité. Le rapport est refusé si plus de 10 % du cadre reste non classé, si 5 % des appels sont ininterprétables ou si une strate critique manque. Ces seuils internes qualifient la collecte ; ils ne prétendent pas décrire une règle Google.
Canarier une correction de template
Créer traité et témoin comparables
Les URL partagent gabarit, âge et profondeur. Le manifeste est figé avant livraison. L’équipe suit réponse, liens, sitemap, premier crawl et état sur une fenêtre compatible avec la cadence passée, plutôt que deux captures globales prises à des dates différentes.
Le pilote s’arrête si 0,5 % renvoient un statut inattendu, si une canonicale sort du host, si les inconnues dépassent 10 % ou si le parcours recule. Le rollback restaure le composant sans supprimer les preuves.
Attribuer avec prudence. Une amélioration parallèle reste une association tant que temporalité, mécanisme et témoin ne concordent pas. En revanche, la correction d’un défaut vérifié sur le HTML et sa disparition dans deux cohortes renforcent la conclusion.
Répartir quotas et responsabilités
Nommer les propriétaires
Data possède manifeste et tirage ; SEO définit strates et interprétation ; produit confirme les états ; SRE garantit preuves publiques et quotas. Un responsable accepte l’extension selon des seuils écrits. Les accès GSC sont limités et les exports sensibles ont une durée de conservation.
La revue mensuelle recalcule la population ; un lancement suit un rythme plus court. L’automatisation s’arrête si elle n’influence plus aucune décision. Accumuler des inspections sans question consomme quota et attention.
Versionner les définitions. Tout changement de strate, d’unité ou de parseur porte une version. Les comparaisons anciennes sont recalculées ou explicitement signalées comme non comparables, plutôt que mélangées dans une série continue.
Éviter les biais fréquents
Prendre mille exemples pour mille tirages. La limite d’affichage ne définit pas un plan aléatoire. Les exemples reproduisent ; le manifeste et la graine estiment.
Inspecter seulement les pages importantes. Ce choix mesure un risque business, pas la santé globale. Ces pages forment une strate dédiée avec un tirage des autres mécanismes.
Masquer les non-réponses. Les retirer sans les afficher embellit le taux. Quota, timeout et absence restent comptés, expliqués et relancés selon une règle stable.
Plan d’action : livrer en quinze jours
Fermer le cadre en six jours
- Jours 1 à 3 : définir la décision, réconcilier les inventaires, choisir l’unité et mesurer les non-classées.
- Jours 4 à 6 : construire les strates, fixer quotas, précision et graine, puis relire vingt lignes critiques.
- Jours 7 à 11 : tirer, appeler l’API, collecter les réponses publiques et conserver chaque erreur.
- Jours 12 à 15 : pondérer, présenter incertitudes, choisir un mécanisme et préparer traité, témoin et rollback.
Le livrable comprend manifeste, dictionnaire, requête de tirage, journal et dossier de décision. Il précise propriétaire, fenêtre, seuils, exclusions et reprise. Une autre équipe peut le rejouer sans explication orale.
Décider de poursuivre ou d’agir. Si la couverture reste sous 90 % dans une strate critique, la collecte continue. Si un défaut de template dépasse 30 % avec preuves concordantes, le canari démarre plutôt que d’inspecter indéfiniment.
Préparer la restitution de décision
La restitution commence par la population, pas par le taux. Elle montre combien d’URL existent dans chaque strate, combien ont été tirées, combien ont répondu et quel poids leur est attribué. Une annexe fournit des cas ordinaires, extrêmes et contradictoires afin que produit et développement puissent contester l’interprétation. Le responsable SEO énonce ensuite le mécanisme présumé et la preuve qui manque encore.
Le comité choisit entre quatre sorties : corriger un composant, augmenter la collecte, accepter le risque pour une période ou retirer une famille devenue sans objet. Chaque choix porte une échéance et un propriétaire. Une décision « surveiller » sans seuil de réouverture est refusée, car elle transforme une incertitude mesurée en dette permanente.
Transmettre les contrôles à la production
Le ticket référence la version du manifeste, le hash du tirage, les URL du canari, le témoin, les métriques et les commandes de retour arrière. Développement sait quel template modifier ; SRE sait quels statuts observer ; SEO sait quand relancer la mesure. Version, strate et graine relient ainsi analyse, livraison et contrôle.
Après déploiement, l’équipe ne remplace pas les membres défavorables. Elle ajoute une observation datée à la même ligne, puis renouvelle seulement la fraction prévue du panel. Cette continuité distingue une correction réelle d’un changement d’échantillon et rend le bilan comparable à la situation initiale.
Adapter l’effort à la population
Grands catalogues. Marketplaces, médias et catalogues multilingues bénéficient du pipeline complet, car un taux global masque leurs mécanismes. Les petites strates critiques restent visibles.
Sites plus petits. Quelques centaines de pages peuvent être recensées entièrement. Plutôt que d’industrialiser un tirage inutile, l’équipe garde la même discipline de population, preuve, date et décision.
Recetter une migration de taxonomie
Un changement de catégorie, de locale ou de modèle peut déplacer une URL entre strates sans modifier son état Google. Le manifeste conserve ancienne classe, nouvelle classe, date et règle de mapping. Les résultats avant/après sont recalculés selon une taxonomie commune ou présentés séparément ; ils ne sont jamais raccordés par une simple étiquette identique.
Le contrôle sélectionne cinquante URL déplacées, vérifie leur gabarit public, leur canonicale et leur poids. Si plus de 2 % reçoivent une classe incompatible ou si un poids devient nul, alors la vague statistique est suspendue. En revanche, un changement métier confirmé devient un événement normal et ne doit pas être corrigé artificiellement.
Traiter les propriétés et locales multiples
Une URL doit être inspectée dans la propriété Search Console qui la couvre exactement. Le pipeline associe host, protocole, préfixe et locale à un identifiant de propriété, puis refuse les correspondances ambiguës. Il garde également les balises de langue, la canonicale et le statut de chaque variante afin de ne pas transformer une absence de propriété en absence d’indexation.
Les quotas et taux sont calculés par propriété, puis agrégés avec les poids de population. Si une locale représente 4 % du stock mais 35 % des erreurs, elle reste visible. Plutôt que de noyer ce défaut dans la langue principale, l’équipe vérifie sitemap, hreflang, liens et parité de contenu sur un canari dédié.
Contrôler les changements de population
Entre extraction et inspection, des pages peuvent être publiées, retirées ou redirigées. Le protocole ne reconstruit pas silencieusement le dénominateur. Il marque l’état public au moment de l’appel et conserve l’état attendu du manifeste. Le taux de dérive mesure ainsi la stabilité opérationnelle de la population autant que son indexation.
Si la dérive dépasse 5 % pendant la fenêtre, le tirage reste exploitable pour les URL stables mais aucune estimation globale n’est publiée sans correction. Une nouvelle vague repart d’un manifeste daté. Ce seuil interne empêche une campagne commerciale très mouvante de produire une précision que ses propres données ne soutiennent pas.
Documenter une décision négative
Une analyse rigoureuse peut conclure qu’aucune correction n’est justifiée. Les taux sont comparables, les intervalles se recouvrent, les réponses publiques sont cohérentes et le coût d’une refonte dépasse le risque. Le dossier conserve cette conclusion, les conditions observées et la date de prochaine revue afin d’éviter que la même alerte ne relance immédiatement le chantier.
La décision négative possède néanmoins un seuil de réouverture : hausse de dix points des non-indexées sur deux mesures, plus de 500 URL nouvelles sans premier crawl ou changement de template. Elle devient ainsi un arbitrage surveillé plutôt qu’un abandon. Cette possibilité protège l’équipe contre l’obligation de « trouver un problème » dans chaque échantillon.
Vérifier les sources primaires
Google Search Console. L’aide officielle décrit le rapport d’indexation. La référence de l’API Inspection d’URL et ses quotas bornent la collecte.
Échantillonnage. Le NIST explique l’échantillonnage stratifié. Les seuils simulés restent des choix internes. Les prolongements sur les sitemaps par cohorte, la découverte sans crawl, l’exploration sans indexation et l’inspection en volume approfondissent ces décisions.
Conclusion : mesurer depuis le site
Les exemples GSC rendent un défaut tangible mais ne définissent pas la population. Le manifeste interne fournit le cadre.
Strates, graine, poids et inconnues rendent l’estimation reproductible. L’API enrichit chaque ligne sans remplacer la réponse publique.
La décision porte sur un mécanisme, puis se vérifie sur traité et témoin. Cette discipline évite les refontes fondées sur quelques URL commodes.
- Conserver le manifeste, la graine et les poids de chaque tirage.
- Publier les inconnues avec leur dénominateur au lieu de les convertir en zéros.
- Comparer traité et témoin avant toute correction étendue du gabarit.
Pour construire le cadre et sécuriser la correction, l’accompagnement Tech SEO et performance web de Dawap relie mesure, livraison et contrôle.
