Une équipe ouvre le rapport d’indexation et trouve 48 000 URL dans « Découverte, actuellement non indexée ». Le symptôme déclenche aussitôt trois corrections incompatibles : enrichir tous les textes, augmenter le serveur et demander une indexation manuelle. Aucune ne part pourtant d’une preuve que Google a réellement exploré les pages concernées.
Pour les responsables SEO, plateformes éditoriales, équipes catalogue et SRE, le vrai enjeu consiste à séparer retard de reporting, faiblesse de découverte, capacité de crawl et faible priorité attendue. Ce n’est pas un verdict de qualité posé sur le contenu, c’est un état de parcours qui doit être rapproché de cohortes et de logs.
En réalité, une URL indiquée comme découverte peut ne présenter aucune dernière exploration dans le rapport. Concrètement, on ne peut pas attribuer au moteur une évaluation détaillée d’un document qu’aucun hit vérifié ne prouve. Contre-intuitivement, la première action utile est souvent de figer le lot et d’améliorer l’observation avant de modifier les pages.
Une mission Tech SEO et performance web relie Search Console, liens HTML, sitemaps, journaux serveur et capacité de production. La méthode ci-dessous transforme une catégorie agrégée en branches testables, puis associe chaque branche à une action réversible.
Lire le statut sans lui faire dire davantage
S’en tenir au fait rapporté
Le rapport d’indexation indique que Google connaît l’URL mais qu’elle n’est actuellement pas indexée, et que l’exploration peut ne pas encore avoir eu lieu. Cette formulation constitue le fait disponible. Elle ne révèle ni l’instant précis de découverte, ni une note de qualité, ni la prochaine date de visite.
Le volume est agrégé et les données peuvent être retardées. Une URL corrigée aujourd’hui peut rester quelque temps dans son ancienne catégorie. L’analyse enregistre donc date d’export, dernière mise à jour visible et fenêtre d’observation plutôt que de traiter le tableau comme un état transactionnel en temps réel.
Refuser les diagnostics implicites
« Google juge le contenu trop faible » n’est pas un fait démontré par ce statut. Avant une exploration prouvée, cette phrase confond la priorité attendue du moteur avec une lecture du document. La faible valeur peut être une hypothèse sur une famille générée, jamais une citation du rapport.
« Le budget de crawl est insuffisant » reste également une hypothèse tant que les logs, la capacité serveur et le volume de surface ne la soutiennent pas. Le diagnostic commence par lister faits, interprétations et inconnues dans trois colonnes distinctes.
Séparer découverte et exploration prouvée
Ne pas franchir la frontière avec le statut exploré
« Explorée, actuellement non indexée » décrit une autre étape : Google indique avoir exploré l’URL avant de ne pas l’indexer actuellement. Ce second statut autorise à examiner le document reçu, les duplications, la canonicale et sa proposition de valeur. Le présent diagnostic s’arrête avant ce verdict tant que le hit n’est pas établi.
Une URL peut changer de catégorie entre deux exports. L’équipe conserve l’historique par URL et date au lieu d’additionner des volumes transversaux. Une migration de « découverte » vers « explorée » n’est pas encore une indexation, mais elle confirme que la branche de diagnostic a changé.
Utiliser l’inspection comme observation, pas comme oracle
L’inspection d’URL fournit l’état indexé connu et certaines informations de crawl. Son test en direct vérifie l’accessibilité actuelle, mais Google précise qu’il ne permet pas de tester les statuts « Découverte actuellement non indexée » ou « Explorée actuellement non indexée ». Il ne prédit pas non plus l’indexation.
Une URL accessible en direct peut donc rester dans la cohorte. Le test élimine un blocage technique immédiat ; il ne prouve ni demande de crawl passée, ni priorité future. La canonicale retenue peut également être déterminée plus tard lors de l’indexation.
Construire des cohortes comparables
Segmenter avant de compter
Le total global mélange souvent nouvelles fiches, anciennes facettes, pages éditoriales et URL qui ne devraient plus exister. La cohorte associe template, date de publication interne, shard sitemap, profondeur, nombre de liens entrants, priorité business, statut HTTP attendu et source de création.
Une segmentation utile sépare au minimum les URL publiées depuis moins de sept jours, celles âgées de sept à vingt-huit jours et celles au-delà. Elle isole aussi nouveautés, stock actif, pages sans offre et combinaisons générées. Les taux deviennent comparables seulement à l’intérieur d’une intention homogène.
Garder un témoin et une population figée
Avant correction, l’équipe fige un échantillon stratifié et conserve une cohorte témoin. Les URL nouvelles continuent d’arriver dans un lot distinct. Sinon, le dénominateur change chaque jour et une amélioration apparente peut seulement refléter une baisse de création.
L’échantillon contient succès et échecs attendus : pages fortement liées, pages profondes, URL de sitemap seules et surfaces générées. Il est assez petit pour être inspecté, assez large pour couvrir les templates et versionné pour être rejoué par une autre personne.
Définir des horloges internes défendables
Nommer ce que le site sait vraiment
Le site connaît sa date de publication, son premier lien HTML, son ajout au sitemap et sa première réponse à un Googlebot vérifié. Il ne connaît pas nécessairement la date où Google a découvert l’URL. Les colonnes portent donc des noms explicites comme first_linked_at, first_sitemap_at et first_verified_googlebot_hit_at.
Un champ first_seen_by_pipeline peut tracer l’apparition dans l’inventaire interne, mais ne doit pas devenir « date de découverte Google ». Cette prudence empêche d’attribuer au moteur une horloge calculée par le site.
Aligner événements et fenêtres
Les timestamps sont normalisés en UTC, reliés à une version de publication et conservés avec leur source. Une page mise en ligne avant d’être liée possède deux événements distincts. Le délai vers le premier hit part de la première découverte que le site a réellement rendue possible, pas de la création en base.
Si sitemap et lien apparaissent à des dates différentes, l’analyse garde les deux. Elle peut ensuite comparer les familles « sitemap d’abord », « lien d’abord » et « simultané » sans inventer une causalité à partir d’un seul point.
Prouver ou exclure un hit Googlebot
Valider l’identité du robot
Les journaux serveur constituent la preuve directe d’une requête reçue. L’identité Googlebot se valide avec reverse DNS puis résolution directe, ou avec les plages IP officielles selon le dispositif. Une chaîne user-agent seule ne suffit pas, car elle peut être copiée.
Le pipeline conserve URL normalisée, timestamp, IP validée ou classe, user-agent, statut, octets, temps de réponse, cache et upstream. Il rapproche variantes et redirections de l’URL canonique afin qu’un hit sur une ancienne forme ne soit pas perdu.
Interpréter absence et présence avec prudence
Aucun hit dans une conservation de sept jours ne prouve pas qu’il n’y en a jamais eu. La conclusion doit mentionner rétention, pertes et périmètre des logs. En revanche, un système complet sur vingt-huit jours peut établir qu’aucune requête vérifiée n’a été observée pendant cette fenêtre.
Un hit prouvé change la branche : on examine la réponse reçue et la possible transition de reporting. Si Search Console conserve temporairement l’ancien statut, le décalage est documenté. Si plusieurs hits existent depuis longtemps, alors l’équipe vérifie normalisation d’URL, couverture des exports et frontière avec l’article sur les URL explorées non indexées.
Auditer la force réelle de la découverte
Compter les liens HTML explorables
Un lien utile est un élément <a href> présent dans le HTML ou rendu de façon fiable, pointant vers l’URL canonique accessible. Un bouton JavaScript sans destination, une recherche interne ou un lien ajouté uniquement après interaction ne porte pas la même force de découverte.
Le crawl interne mesure nombre de liens entrants uniques, profondeur minimale, hubs sources, statut des pages sources et présence dans le rendu initial. Il distingue un lien de footer sur tout le site d’un lien éditorial contextualisé. Le volume brut ne remplace pas la structure.
Détecter orphelins et impasses
Une URL présente uniquement dans un sitemap n’est pas totalement inconnue, mais son intégration au graphe est faible. Les nouveautés doivent rejoindre des hubs, catégories ou listes datées qui restent accessibles assez longtemps. Une page chassée du hub après quelques heures peut perdre son chemin avant le passage du robot.
Si les pages non indexées se concentrent au-delà de cinq clics ou sans lien entrant interne, alors la branche découverte devient prioritaire. En revanche, si elles reçoivent plusieurs liens stables depuis des pages explorées, le diagnostic se déplace vers capacité, surface ou retard de reporting.
Contrôler sitemap et fraîcheur sans surinterpréter
Vérifier inclusion et cohérence
Le sitemap doit contenir l’URL canonique absolue, répondre correctement, rester dans les limites du protocole et être référencé par un index soumis. L’audit contrôle date de première inclusion interne, disponibilité publique, cache CDN, shard, éventuelle suppression et lastmod défendable.
L’inclusion aide à signaler les URL, mais ne garantit ni crawl ni indexation. Soumettre plusieurs fois le même fichier ne change pas cette limite. La donnée utile est la continuité d’une inclusion exacte, pas le nombre de clics sur « Envoyer ».
Ne pas simuler la fraîcheur
Réinitialiser toutes les dates à aujourd’hui brouille le signal et empêche de relier une visite à un changement réel. Le lastmod reflète la dernière modification significative de la page. Si sa provenance est inconnue, son omission est préférable à un timestamp de génération.
Les cohortes de sitemap restent utiles pour observer une mise en ligne. Elles ne doivent pas dupliquer une URL dans plusieurs shards actifs ni changer arbitrairement son identité. L’équipe sépare l’organisation du suivi et la vérité de la page.
Mesurer capacité et santé du serveur
Chercher les freins observables au crawl
Le rapport entre demandes Googlebot et réponses examine 5xx, 429, délais, timeouts, chaînes de redirections et variation du TTFB. Une origine saturée ou une protection qui limite le robot peut réduire la capacité pratique. Les analyses sont segmentées par host et type de ressource.
Un site de taille modeste, rapide et stable n’a pas toujours besoin d’un grand chantier de budget de crawl. Google réserve surtout cette analyse aux sites très vastes ou à mise à jour rapide. La capacité devient une branche justifiée par le volume et les symptômes, pas un diagnostic par défaut.
Distinguer capacité et demande de crawl
La capacité décrit ce que le serveur peut accepter et ce que Google peut demander sans le dégrader. La demande dépend notamment de la perception d’utilité et de fraîcheur des URL. Un serveur sain n’oblige donc pas Google à explorer chaque combinaison disponible.
Si les 5xx et 429 montent en même temps que le délai du premier hit, alors la capacité constitue une hypothèse forte. Si le serveur est stable mais que seules des facettes profondes stagnent, la forme du graphe et la surface générée deviennent plus plausibles.
Évaluer la surface générée et sa priorité attendue
Comparer création d’URL et capacité d’observation
Une plateforme peut produire plus d’URL qu’elle ne peut en relier, maintenir et mesurer. Le tableau suit nouveaux canoniques par jour, part possédant un lien interne stable, profondeur, présence sitemap et priorité business. Une croissance incontrôlée des paramètres ou combinaisons est traitée comme une dette de produit.
La faible priorité attendue est une interprétation fondée sur des signaux internes : absence de demande identifiée, quasi-duplication, inventaire vide, aucun lien et création automatisée. Elle ne devient jamais « Google a lu et jugé la page faible » sans crawl prouvé.
Décider si l’URL doit vraiment exister
Toute URL découverte n’a pas vocation à être indexée. Certaines facettes, résultats internes ou états éphémères ne devraient pas constituer des documents publics. Avant de renforcer leur découverte, le produit tranche leur identité, leur valeur et leur destination HTTP.
Si l’URL doit exister, elle reçoit contenu assumé, liens et suivi. Sinon, le générateur est fermé, les liens retirés et l’état HTTP aligné. En revanche, placer un noindex sur une surface infinie sans retirer sa génération laisse la dette de crawl et de gouvernance ouverte.
Décider avec un arbre de diagnostic
Commencer par reporting et preuve de hit
Branche A : la page est récente et l’export retardé ; l’équipe attend la fenêtre définie sans intervention de masse. Branche B : un hit Googlebot vérifié existe après la date de statut ; elle traite le décalage ou reclasse l’URL vers le diagnostic post-crawl. Branche C : aucun hit n’est observé sur une fenêtre fiable ; elle continue vers découverte et capacité.
Chaque branche possède une condition de sortie. L’absence de décision est interdite : la ligne porte « attendre jusqu’à », « analyser la réponse explorée », ou « tester la découverte ». Ce format empêche que toutes les équipes modifient simultanément le contenu, les liens et le serveur.
Arbitrer découverte, capacité et surface
Si les URL ont peu de liens ou une profondeur forte, alors un hub canari teste la découverte. Si les erreurs serveur dépassent le seuil et touchent plusieurs templates, alors la santé devient prioritaire. Si liens et serveur sont sains mais que la surface automatisée explose, alors l’équipe réduit la génération et recentre les URL assumées.
Plusieurs causes peuvent coexister, mais elles sont testées séquentiellement par cohorte. Plutôt que de lancer un chantier global, l’équipe choisit la branche dotée de la meilleure preuve et du changement le plus réversible.
Choisir les métriques et fenêtres utiles
Mesurer progression technique par cohorte
Les indicateurs principaux sont part sans hit Googlebot vérifié, délai entre premier lien ou sitemap et premier hit, profondeur, liens entrants, continuité sitemap, 5xx, 429, TTFB et taux de création d’URL. Les transitions de statut Search Console sont conservées avec date d’export.
Le percentile 50 montre le parcours courant ; le percentile 90 révèle la longue traîne. Les mesures sont comparées à une cohorte témoin du même template et de la même période. Une moyenne de tout le site masque précisément les familles en impasse.
Relier priorité business sans faux signal
Une URL non indexée n’a généralement pas de performance organique propre exploitable dans le rapport de résultats. La demande est donc approchée avec recherches internes, ventes de la catégorie, requêtes voisines et potentiel éditorial, clairement étiquetés comme proxys.
Les pages à forte marge ou à disponibilité urgente peuvent recevoir une priorité de diagnostic supérieure, sans prétendre que cette priorité interne oblige Google. L’objectif est d’investir les efforts de liens, contenu et stabilité là où une découverte réussie a une valeur business plausible.
Arbitrer deux scénarios simulés
Tester un défaut de maillage
Scénario 1 entièrement simulé. Sur 12 000 nouveautés, 68 % des URL au statut étudié n’ont aucun hit Googlebot vérifié en vingt-huit jours. Elles sont présentes dans un sitemap, mais 81 % n’ont aucun lien HTML et sortent du hub après six heures. Un canari conserve 500 pages dans un hub paginé pendant quatorze jours.
Seuil 1 simulé : la part sans hit à J+14 doit baisser d’au moins 25 points face au témoin, sans hausse de 5xx ni de profondeur moyenne. Si elle ne baisse pas, alors l’équipe refuse de généraliser le hub et revient vers capacité ou surface.
Traiter une surface générée trop vite
Scénario 2 entièrement simulé. Un moteur de facettes crée 90 000 nouvelles URL par semaine, dont 72 % sans produit et sans lien durable. Le serveur répond correctement, tandis que les catégories éditoriales liées reçoivent un premier hit médian sous trois jours. Le produit ferme les combinaisons vides et maintient 4 000 intentions prouvées.
Seuil 2 simulé : moins de 5 % d’URL nouvelles sans lien interne stable et moins de 1 % de 5xx ou 429 sur Googlebot pendant le canari. Ces valeurs illustrent le mécanisme de décision ; elles ne constituent ni une norme Google ni une promesse d’indexation.
Agir selon la branche prouvée
Renforcer une découverte faible
La correction crée des hubs HTML stables, rapproche les pages importantes, maintient une pagination parcourable et émet directement les URL canoniques. Elle aligne sitemap et liens. Un test de crawl interne confirme que chaque URL de la cohorte est atteignable sans formulaire ni clic JavaScript obligatoire.
Ajouter un lien sitewide vers toutes les URL n’est pas une solution proportionnée. Le maillage exprime une hiérarchie et une priorité éditoriale. Les pages nouvelles restent visibles assez longtemps pour être découvertes, puis rejoignent une archive paginée durable.
Corriger capacité ou réduire la surface
La branche serveur traite timeouts, 5xx, 429, cache et goulots d’origine, avec un SLO et une alerte. La branche surface ferme la création non assumée, retire les liens inutiles et décide le statut des URL existantes. Ces actions peuvent avancer en parallèle sur des cohortes distinctes.
Une demande d’indexation manuelle reste un outil d’inspection ponctuel, pas un pipeline de masse. Elle ne remplace ni découverte systémique, ni capacité, ni identité des URL. Le succès se vérifie dans les logs et les cohortes, pas dans le nombre de demandes envoyées.
Recetter liens, crawl et reporting
Tester la chaîne de découverte
La recette part d’un hub public, extrait les href, suit statuts et redirections, vérifie canonicale, robots, rendu serveur, sitemap et date d’inclusion. Elle rejoue avec JavaScript désactivé et contrôle que l’URL ne dépend pas d’une session ou d’une recherche interne.
Un corpus négatif couvre lien cassé, canonicale différente, 404 intermittent, URL de paramètre, page retirée trop tôt et shard en cache. Chaque échec indique la couche responsable. Une correction manuelle dans Search Console ne valide aucun de ces mécanismes.
Par exemple, une route valide dans le navigateur peut être absente du HTML SSR et n’apparaître qu’après interaction. La QA doit alors corriger le lien source, rejouer l’invalidation du cache et vérifier le chemin avant d’attribuer l’absence de hit à une faible priorité.
- Découverte : href canonique, page source indexable et profondeur mesurée.
- Réponse : route directe, statut, rendu SSR et canonicale cohérente.
- Diffusion : sitemap disponible, cache invalidé et horodatage interne conservé.
- Observation : logs Googlebot vérifiés, TTFB et export Search Console daté.
Industrialiser logs et décisions
L’implémentation reçoit comme entrées URL, template, date de premier lien, date sitemap et export GSC ; ses sorties portent hit vérifié, branche, action et échéance. La journalisation conserve la preuve, le monitoring suit les seuils et chaque alerte nomme l’owner.
Le runbook explique validation Googlebot, extraction de cohorte, contrôles de capacité, décision et rollback. Une personne extérieure au chantier doit reproduire le verdict. Si elle dépend d’une explication orale, la recette est incomplète.
Déployer par cohorte avec contrôle
Modifier une variable principale à la fois
Le canari de maillage conserve serveur et génération stables ; le canari capacité conserve le graphe ; le canari surface compare des familles équivalentes. Cette discipline n’isole pas parfaitement le monde réel, mais elle rend l’interprétation plus solide qu’une refonte simultanée.
La cohorte possède date de début, témoin, seuil de succès, seuil d’arrêt et durée. Si une régression de navigation ou de conversion apparaît, alors le rollback fonctionnel s’exécute sans effacer les observations déjà acquises.
Lire les résultats à plusieurs horizons
À J+1, l’équipe valide liens, sitemaps, erreurs et journaux. À J+7, elle lit les premiers hits. À J+14 et J+28, elle compare transitions Search Console et longue traîne. Les fenêtres sont adaptées au volume, mais décidées avant le résultat.
Une amélioration du premier hit valide surtout la découverte ou la capacité. Elle ne prouve pas encore l’indexation ni le trafic. Si les URL passent vers « Explorée actuellement non indexée », le chantier est transmis au diagnostic de contenu et de consolidation approprié.
Éviter les remèdes de masse trompeurs
Réécrire toutes les pages avant un hit prouvé
Enrichir une page peut être utile au produit, mais le statut étudié ne prouve pas que Google a lu sa version actuelle. Une campagne de réécriture massive mélange ainsi amélioration éditoriale et correction de découverte. Elle rend impossible l’attribution du résultat.
Plutôt que d’attendre une qualité abstraite, l’équipe choisit une cohorte business où l’enrichissement est justifié indépendamment du statut. Pour le reste, elle prouve d’abord lien, sitemap, serveur et hit.
Forcer indexation, lastmod ou liens universels
Envoyer des milliers de demandes, changer toutes les dates et ajouter toutes les URL au footer créent des signaux artificiels sans résoudre leur identité. Ils peuvent aussi surcharger l’observation ou dégrader le site. Aucun de ces gestes ne garantit l’indexation.
Bloquer immédiatement les URL dans robots.txt peut empêcher le moteur de lire leur état final. La fermeture d’une surface suit une politique HTTP, de liens et de canonicales cohérente, avec vérification des anciennes formes et des redirections.
Plan d’action : fermer le diagnostic en deux semaines
Semaine 1 : figer, relier et qualifier
Le premier jour exporte le statut avec sa date et fige les cohortes par template, ancienneté et priorité. Le deuxième rapproche publication, premier lien et première inclusion sitemap. Le troisième valide Googlebot et cherche le premier hit dans la fenêtre disponible. Le quatrième crawl le graphe interne, mesure profondeur et liens entrants. Le cinquième confronte ces données aux 5xx, 429, TTFB et volumes de nouvelles URL.
Chaque URL reçoit une branche : retard probable, crawl prouvé, découverte faible, capacité dégradée, surface non assumée ou inconnue. Les inconnues ne sont pas forcées dans une catégorie. La revue choisit deux cohortes canari et une cohorte témoin, puis fixe les seuils avant toute modification publique.
Semaine 2 : corriger, observer et transmettre
Le sixième jour stabilise les hubs ou corrige la cause serveur selon la branche retenue. Le septième ferme la génération sans valeur et aligne ses statuts. Le huitième recrawl les liens, vérifie les sitemaps et rejoue les cas négatifs. Le neuvième active instrumentation et alertes. Le dixième ouvre le canari avec rollback testé. Les jours suivants observent hits, erreurs et transitions sans changer la population.
Les entrées, sorties, seuils, journalisation, monitoring, owner et runbook sont archivés avec la cohorte. Au quatorzième jour, l’équipe étend, corrige ou replie. Les résultats différés restent programmés à J+28, et les URL désormais explorées passent vers le diagnostic post-crawl plutôt que d’être déclarées résolues.
- D’abord, conserver une cohorte figée et ses horloges avant de comparer les volumes.
- Ensuite, contrôler le hit Googlebot, les liens, le sitemap et la santé serveur.
- Puis, décider l’action correspondant à la branche la mieux étayée et tester son rollback.
- Élargir après canari, seuils stables et runbook rejoué.
Relier découverte, audit et indexabilité
Construire la vue d’ensemble
L’audit d’indexation à grande échelle assemble sitemap, Search Console, crawl et logs. Le présent diagnostic utilise cette base pour isoler une étape précise et éviter qu’un score global masque l’absence de hit.
Les cohortes de publication, découverte et crawl fournissent la structure temporelle. Elles séparent les événements que le site contrôle de ceux que Google rapporte.
Prouver les préconditions de l’URL
Le système de preuve d’indexabilité vérifie découvrabilité, rendu, canonicale et autorisation. Il complète l’arbre sans transformer ces préconditions en garantie d’indexation.
Lorsque le premier hit est enfin observé, l’analyse change de question. Elle examine la réponse réellement servie et, si nécessaire, rejoint le dossier « Explorée actuellement non indexée » au lieu de continuer à corriger le maillage.
Consulter les sources primaires
Lire les limites des rapports Google
L’aide Google décrit le rapport d’indexation des pages et ses raisons d’exclusion. La documentation de l’outil d’inspection d’URL précise les limites du test en direct et rappelle qu’un résultat valide ne garantit pas l’indexation.
Ces documents soutiennent les faits de reporting. Les hypothèses de priorité, de demande ou de valeur viennent de l’analyse des cohortes ; elles doivent rester présentées comme telles.
Vérifier crawl, liens et sitemaps
Google publie une documentation sur la gestion du budget de crawl pour les grands sites et décrit les liens explorables. Ces références cadrent capacité, demande et forme des liens.
La documentation sur les sitemaps rappelle qu’ils aident à signaler les URL sans garantir leur exploration ou leur indexation. Le diagnostic combine ces sources au lieu d’isoler une seule interface.
Conclusion : prouver le blocage avant de corriger
« Découverte actuellement non indexée » décrit une étape rapportée, pas une note attribuée au contenu. L’équipe gagne en précision dès qu’elle refuse de franchir cette frontière sans hit prouvé.
Les cohortes figent la population, les horloges internes séparent les événements, les logs valident le robot et le crawl interne mesure la force des chemins. L’état agrégé devient alors un arbre de décisions reproductible.
Maillage, capacité et réduction de surface ont chacun leur place, mais pas comme remèdes simultanés et aveugles. Un canari, un témoin et des seuils permettent de vérifier la branche avant extension.
Pour relier Search Console, logs, sitemaps et architecture de liens sans confondre hypothèse et preuve, l’accompagnement Tech SEO et performance web de Dawap transforme le volume exclu en décisions techniques et business traçables.
