Une page publiée n'est pas une page indexée, et une page indexée n'est pas une page classée. Entre le moment où une URL existe et celui où elle reçoit sa première visite depuis Google, il y a cinq étapes distinctes, séparées par des délais qui vont de quelques minutes à plusieurs mois. Chacune peut échouer, et chaque échec produit un symptôme différent qui appelle une correction différente.

Ce guide traite le parcours complet. Il est long parce que le sujet l'est : la plupart des erreurs de diagnostic viennent de ce qu'on applique le remède d'une étape au problème d'une autre. Ajouter des liens internes ne sert à rien si Google a déjà exploré la page et l'a jugée insuffisante ; réécrire un contenu ne sert à rien si le robot n'y accède pas.

Les cinq étapes, et pourquoi la distinction compte

Le parcours d'une URL suit toujours le même ordre :

  1. La découverte — Google apprend que l'URL existe.
  2. L'exploration — le robot télécharge son contenu.
  3. Le rendu — le JavaScript est exécuté, s'il y en a.
  4. L'indexation — Google décide de conserver la page, ou non.
  5. Le classement — la page est mise en concurrence sur des requêtes.

Ces étapes ne sont pas simultanées. Une URL peut rester découverte mais non explorée pendant des semaines. Une page explorée peut attendre son rendu plusieurs jours. Une page indexée peut n'apparaître sur aucune requête pendant des mois.

La conséquence pratique est qu'il faut toujours commencer par une question : à quelle étape le parcours s'interrompt-il ? Tout le reste en découle. Search Console répond à cette question, à condition de savoir lire ses libellés — et c'est précisément là que la plupart des diagnostics dérapent.

« Détectée, actuellement non indexée » et « Explorée, actuellement non indexée » sont deux libellés voisins qui décrivent des problèmes opposés. Le premier signale que Google n'a pas eu le temps. Le second signale qu'il a lu et refusé. Confondre les deux, c'est corriger un problème technique quand la cause est éditoriale.

Étape 1 — La découverte

Google ne devine pas l'existence d'une URL. Il l'apprend, par l'un de ces canaux :

Ces canaux ne se valent pas. Un lien depuis une page qui compte transmet une information supplémentaire : quelqu'un a jugé cette URL digne d'être citée. Un sitemap, lui, est une déclaration de l'éditeur sur son propre contenu — utile pour la découverte, sans aucun poids qualitatif.

Le sitemap ne remplace pas le maillage

C'est une confusion coûteuse. Un sitemap sert à faire connaître des URL ; il ne dit rien de leur importance et ne transmet aucune autorité. Une page listée dans un sitemap mais vers laquelle aucun lien interne ne pointe est une page orpheline, et Google le lit exactement comme ce que c'est : le site lui-même ne juge pas cette page assez utile pour y renvoyer.

La vérification est simple. Prenez la liste des URL de votre sitemap, celle des URL atteignables en suivant les liens depuis la page d'accueil, et faites la différence. Les URL présentes dans la première et absentes de la seconde sont orphelines. Sur un site géré par un CMS, elles se comptent souvent par centaines : pages d'archives, filtres, contenus dépubliés du menu mais toujours listés.

Ce que devrait contenir un sitemap

Un sitemap correct ne liste que des URL qui remplissent quatre conditions simultanées : elles répondent en 200, elles sont indexables (aucune directive contraire), elles sont canoniques (elles ne pointent pas vers une autre version), et elles ont une valeur propre.

Toute entrée qui échoue à l'une de ces conditions envoie un signal contradictoire : vous soumettez à l'indexation une page que vous excluez par ailleurs. Sur un site volumineux, ces contradictions se comptent par milliers et dégradent la confiance accordée au fichier entier.

# Vérifier la cohérence d'un sitemap : chaque URL doit répondre 200
curl -s https://exemple.fr/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | while read u; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$u")
      [ "$code" != "200" ] && echo "$code $u"
    done

Sur un site sain, cette commande ne produit aucune sortie. Toute ligne affichée est une incohérence à traiter.

Étape 2 — L'exploration

Google connaît l'URL ; reste à savoir quand il la téléchargera. C'est ici qu'intervient la notion la plus mal comprise du domaine.

Le budget de crawl, et à qui il s'applique

Le budget de crawl est le volume d'exploration que Google consacre à un site sur une période donnée. Il résulte de deux facteurs indépendants :

Point capital, et régulièrement passé sous silence : Google indique explicitement que cette notion ne concerne pas les sites de moins de quelques milliers d'URL. En dessous de ce seuil, un site correctement construit est exploré intégralement sans difficulté. Optimiser son budget de crawl sur un site de 300 pages revient à résoudre un problème qu'on n'a pas.

Si les pages d'un petit site ne sont pas explorées, la cause est ailleurs : maillage défaillant, blocage technique, ou site jugé sans intérêt suffisant pour justifier un passage fréquent.

Ce qui gaspille réellement du budget

Sur les sites où la question se pose, le gaspillage vient presque toujours des mêmes sources :

La correction se fait à la source. Bloquer les URL paramétrées dans le fichier robots empêche leur exploration ; l'important est de le faire avant qu'elles ne soient massivement découvertes, car une URL déjà indexée puis bloquée reste dans l'index sans pouvoir en sortir — j'y reviens plus bas.

Lire l'exploration dans les journaux serveur

Search Console n'expose que des échantillons. Les journaux du serveur contiennent l'intégralité des passages du robot, et c'est la seule source qui permette de répondre précisément à « qu'est-ce que Google explore réellement, et à quelle fréquence ».

# Répartition des codes de réponse servis à Googlebot
grep -i googlebot access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

# Les 20 URL les plus explorées — souvent une surprise
grep -i googlebot access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

La seconde commande est celle qui instruit le plus. Sur un site mal structuré, les URL les plus explorées ne sont presque jamais les pages importantes : ce sont des pages de filtres, des archives, des redirections. Le budget part dans des zones sans valeur pendant que les publications récentes attendent.

Un contrôle d'authenticité s'impose au passage : le user-agent est déclaratif et n'importe qui peut se prétendre Googlebot. Une résolution DNS inverse confirme l'identité réelle avant de tirer des conclusions.

Étape 3 — Le rendu

Si la page dépend de JavaScript pour afficher son contenu, une étape supplémentaire intervient. Google explore d'abord le HTML brut, puis place la page dans une file d'attente de rendu où le JavaScript sera exécuté — plus tard, avec un délai variable, et sans garantie que toutes les pages y passent.

Les conséquences concrètes

Trois effets méritent d'être connus :

Le dernier point est le plus pernicieux, parce que le site fonctionne parfaitement dans un navigateur. La seule façon de savoir ce que Google voit réellement est de le lui demander : l'inspection d'URL dans Search Console affiche le HTML rendu tel qu'il a été obtenu.

Une règle simple

Tout contenu qui doit être indexé devrait être présent dans le HTML initial. Le JavaScript peut enrichir, animer, personnaliser — mais le texte, les liens de navigation et les données structurées gagnent à ne pas en dépendre. Ce n'est pas une position dogmatique contre les applications côté client : c'est la reconnaissance qu'une étape supplémentaire est une étape supplémentaire qui peut échouer.

Étape 4 — L'indexation, le vrai filtre

La page a été téléchargée, rendue, analysée. Google décide maintenant s'il la conserve. C'est l'étape la plus sélective, et la seule dont l'échec ne se corrige pas techniquement.

Ce qui se joue à cette étape

Google évalue plusieurs dimensions simultanément : la page apporte-t-elle quelque chose qui n'existe pas déjà dans l'index ? Le domaine a-t-il une réputation qui justifie d'accorder le bénéfice du doute ? La page est-elle une variante d'une autre page déjà conservée ? Le contenu correspond-il à un besoin réel exprimé par des utilisateurs ?

Ces critères ne sont pas publiés sous forme de liste, mais leurs effets sont observables dans les motifs de Search Console. Trois d'entre eux méritent une lecture attentive.

« Explorée, actuellement non indexée »

C'est le motif le plus important du rapport, et le plus sous-estimé. Il signifie que Google a lu la page et a décidé de ne pas la conserver. C'est un verdict, pas une file d'attente.

Aucune action technique ne le renverse. Ni soumettre l'URL, ni l'ajouter au sitemap, ni ajouter des données structurées, ni améliorer la vitesse. La page a été jugée sur son contenu et n'a pas convaincu.

Les causes habituelles, par ordre de fréquence :

Ce dernier point est le plus lourd de conséquences, et il mérite d'être énoncé clairement : l'évaluation n'est pas strictement page par page. Un domaine où des centaines de milliers d'URL ont été jugées indignes de l'index voit ses nouvelles publications traitées avec méfiance. La qualité moyenne devient un facteur — c'est le mécanisme qui transforme une politique de publication laxiste en handicap durable.

« Détectée, actuellement non indexée »

Google connaît l'URL mais ne l'a pas téléchargée. Il n'a donc aucune opinion sur son contenu. C'est un problème de capacité ou de priorité, et les leviers sont techniques : améliorer le maillage, accélérer le serveur, réduire le volume d'URL générées.

Un volume modéré est normal sur un site qui publie. Un volume massif indique presque toujours que le site produit des URL plus vite qu'il ne justifie qu'on les explore.

Les motifs qui décrivent un choix, pas un problème

Plusieurs catégories sont neutres et les traiter comme des anomalies dégrade une configuration correcte :

Contrôler l'indexation : les trois outils et leurs pièges

Trois mécanismes permettent d'agir sur l'indexation. Ils sont couramment confondus alors qu'ils interviennent à des étapes différentes du parcours, ce qui explique la plupart des configurations qui produisent l'inverse de l'effet recherché.

robots.txt — agit sur l'exploration

Il empêche le robot de télécharger une URL. Il n'a aucun effet sur l'indexation : une URL bloquée peut apparaître dans les résultats, sans description, si des liens externes pointent vers elle.

Usage légitime : économiser du budget d'exploration sur des zones sans intérêt, protéger des ressources coûteuses. Usage fautif : tenter de désindexer.

noindex — agit sur l'indexation

Directive impérative, servie par balise meta ou en-tête HTTP. Google la respecte et retire la page de l'index. C'est le seul moyen fiable de désindexer tout en gardant la page accessible.

rel=canonical — agit sur le choix entre variantes

Indique quelle URL représente un groupe de pages équivalentes. C'est une indication, pas une directive : Google peut retenir une autre URL si les autres signaux du site la contredisent.

Le piège classique : noindex + robots.txt

C'est l'erreur qui revient le plus souvent, et sa mécanique mérite d'être comprise plutôt que mémorisée.

Vous voulez désindexer une section. Vous ajoutez noindex sur ses pages, et vous la bloquez aussi dans le fichier robots — par prudence, pour que Google « n'y aille plus du tout ».

Résultat : le blocage empêche l'exploration, donc Google ne lit jamais la directive noindex. Les pages restent indexées, et comme leur contenu ne peut plus être consulté, elles apparaissent sans description. Vous avez obtenu le pire des deux mondes, et la situation est verrouillée : tant que le blocage persiste, la directive ne sera jamais lue.

La séquence correcte est ordonnée :

  1. Servir noindex sur les pages concernées, en laissant l'exploration ouverte.
  2. Attendre que Google réexplore et retire effectivement les pages de l'index — plusieurs semaines sur un gros volume.
  3. Vérifier dans Search Console que les pages sont bien passées en « Exclue par la balise noindex ».
  4. Alors seulement, si l'économie de budget le justifie, ajouter le blocage dans le fichier robots.

Cette séquence prend des semaines. C'est normal, et vouloir l'accélérer est précisément ce qui produit le blocage.

Méthode de diagnostic en cinq temps

Face à une page qui n'apparaît pas dans les résultats, cette séquence identifie l'étape défaillante sans détour.

1. La page répond-elle correctement ?

curl -sSIL https://exemple.fr/ma-page | grep -iE '^HTTP|^location|^x-robots'

On cherche un unique 200, sans chaîne de redirection et sans en-tête X-Robots-Tag: noindex. Une chaîne de redirection est invisible dans un navigateur — qui la suit silencieusement — mais bien comptabilisée par le robot.

2. L'exploration est-elle autorisée ?

Vérifier le fichier robots et la présence d'une balise meta robots dans le HTML. Attention à l'en-tête HTTP X-Robots-Tag, souvent oublié parce qu'invisible dans le code source de la page.

3. Que voit Google exactement ?

L'inspection d'URL dans Search Console donne la réponse faisant autorité : date de dernière exploration, HTML effectivement rendu, canonique retenue par Google, et statut d'indexation. Si la canonique retenue diffère de celle que vous déclarez, le problème est identifié.

4. Quel motif Search Console indique-t-il ?

C'est le point de bascule du diagnostic :

5. La page est-elle réellement reliée ?

Combien de liens internes pointent vers elle, depuis quelles pages, avec quels textes d'ancre ? Une page sans lien entrant depuis une page qui compte elle-même n'a aucune raison d'être prioritaire.

Le cas particulier des sites volumineux

Au-delà de quelques milliers d'URL, les règles changent. Ce n'est plus la qualité de chaque page qui décide seule, mais la proportion de pages qui méritent d'exister.

Le mécanisme de la dégradation

Il suit toujours la même progression. Un site génère des pages par combinaison — villes, catégories, filtres. Elles s'indexent d'abord, parce qu'un domaine sain bénéficie d'un crédit initial. Puis Google mesure leur performance réelle : personne ne les visite, ou ceux qui les visitent repartent aussitôt.

L'évaluation se resserre alors progressivement. Les nouvelles pages du même type sont explorées mais plus indexées. Ensuite, les pages déjà indexées commencent à sortir. En dernier lieu, l'effet déborde sur le reste du site : les pages de qualité, minoritaires, héritent de la réputation dégradée du domaine.

Ce dernier stade est celui qui surprend. Un éditeur peut voir ses meilleures pages perdre en visibilité sans les avoir touchées, parce que le domaine porte des centaines de milliers d'URL jugées sans valeur.

Les quatre principes d'une mise à l'échelle saine

  1. Un seuil de valeur avant génération. Une page ne devrait exister que si elle contient une donnée réelle et spécifique. Une ville sans information propre ne mérite pas de page indexable.
  2. Le noindex sélectif. Les pages utiles à la navigation mais sans valeur de recherche peuvent exister en noindex, follow : crawlables, utiles aux visiteurs, absentes de l'index.
  3. Le sitemap en liste blanche. Ne soumettre que ce dont la valeur est confirmée. Le sitemap devient un filtre de qualité au lieu d'un inventaire.
  4. La consolidation. Dix pages faibles fusionnées en une page riche performent mieux que dix pages en concurrence les unes avec les autres.

Ces principes sont détaillés, avec des chiffres réels, dans notre étude de cas sur une désindexation de 372 000 pages — un incident survenu sur l'un de nos propres sites, et dont l'analyse a directement produit ce guide.

Les délais, et pourquoi la patience est méthodologique

Aucune correction d'indexation ne produit d'effet immédiat, et cette latence est la première cause de mauvaises décisions.

Le rapport de Search Console accuse plusieurs jours de retard. La réexploration d'une URL dépend de sa priorité. La réévaluation d'un domaine après une reprise en profondeur se compte en mois. Sur un gros volume, une désindexation volontaire par noindex demande plusieurs semaines pour se propager.

D'où une discipline qui paraît lente mais qui est la seule à produire de l'information exploitable :

L'erreur classique consiste à corriger, observer trop tôt qu'aucun chiffre n'a bougé, en conclure que la correction est inefficace, et la remplacer par une autre. Au bout de quelques cycles, plus personne ne sait quelle modification a produit quel effet — et le site a accumulé des configurations contradictoires.

Étape 5 — Le classement, et pourquoi indexé ne veut pas dire visible

Une page indexée est entrée dans la base. Elle n'est pas pour autant affichée : elle devient candidate, mise en concurrence à chaque requête avec toutes les autres pages jugées pertinentes. Beaucoup de sites s'arrêtent au constat « ma page est indexée » et s'étonnent de ne recevoir aucune visite. Ce sont deux problèmes distincts.

Le signal à surveiller : les impressions

Le rapport de performances distingue trois états qu'il faut savoir séparer.

Zéro impression. La page est dans l'index mais n'est jugée pertinente pour aucune requête, ou se classe si loin qu'elle n'est jamais affichée. Le problème est en amont : le contenu ne correspond à aucun besoin exprimé, ou il est écrasé par une concurrence bien mieux établie. Vérifier d'abord qu'une demande de recherche existe réellement — beaucoup de pages sont écrites pour des requêtes que personne ne formule.

Des impressions, aucun clic. La page est affichée mais ne convainc pas. Ici le levier est immédiat et entièrement sous contrôle : le titre et l'extrait affichés. Une position moyenne autour de 8-15 avec un taux de clic nul indique presque toujours un titre qui ne correspond pas à l'intention de la requête.

Des impressions et des clics, mais en baisse. La concurrence a progressé, ou l'affichage des résultats a changé. Comparer à la même période de l'année précédente, jamais à la période immédiatement antérieure : la saisonnalité produit des variations que l'on attribue à tort à une intervention.

Le croisement qui révèle le plus

Dans le rapport de performances, filtrer par page puis consulter les requêtes associées répond à une question précise : sur quoi cette page est-elle réellement positionnée ?

L'écart avec l'intention d'origine est souvent instructif. Une page écrite pour un sujet précis se retrouve fréquemment positionnée sur des requêtes périphériques, signe que le contenu principal ne convainc pas mais qu'un passage secondaire répond à un besoin réel. C'est une indication éditoriale directe : ce passage mérite peut-être sa propre page, ou le sujet principal mérite d'être réorienté.

Ce même croisement révèle la cannibalisation : deux pages du même site apparaissant en alternance sur la même requête, aucune ne s'installant durablement. La correction consiste à consolider ou à différencier explicitement les intentions.

Quatre situations concrètes, et leur diagnostic

La théorie prend son sens sur des cas réels. Voici quatre configurations fréquentes, avec le raisonnement qui mène à la cause.

« Mon site entier a disparu du jour au lendemain »

Une disparition totale et brutale n'est presque jamais une sanction éditoriale — celles-ci sont progressives. Elle est technique dans l'écrasante majorité des cas.

Vérifier dans cet ordre : un noindex déployé par erreur à l'échelle du site (classique lors d'une mise en production depuis un environnement de préproduction, où il est légitime) ; un fichier robots bloquant tout ; un certificat expiré rendant le site inaccessible ; une erreur serveur généralisée ; une modification DNS mal propagée.

La première hypothèse couvre à elle seule la majorité des cas. Une seule ligne servie sur toutes les pages suffit à vider un site de l'index en quelques semaines.

« Mes nouvelles pages ne s'indexent plus, les anciennes tiennent »

Symptôme typique d'une réputation de domaine en train de se dégrader. Google continue de faire confiance à ce qu'il a déjà validé, mais n'accorde plus le bénéfice du doute aux nouveautés.

Regarder l'évolution du motif « explorée non indexée » sur les six derniers mois. S'il croît régulièrement, la cause est éditoriale : le site publie plus vite qu'il ne produit de valeur. Ajouter du contenu au même rythme aggrave la situation ; réduire le volume et augmenter la densité est le seul chemin.

« Search Console affiche une canonique différente de la mienne »

Google a écarté votre déclaration. Cela signifie que les autres signaux du site désignent une autre URL : les liens internes pointent majoritairement ailleurs, le sitemap liste l'autre version, ou une redirection contredit la balise.

La correction n'est pas de renforcer la balise — elle n'est qu'une indication — mais d'aligner tous les signaux : liens internes, sitemap, redirections et balise doivent désigner la même URL. Une fois cohérents, Google suit généralement.

« Une page indexée depuis des mois est sortie de l'index »

Deux causes dominent. Soit la page a été jugée redondante avec une autre page du site publiée depuis — cas de cannibalisation, visible en comparant les requêtes des deux pages. Soit la concurrence sur le sujet s'est enrichie au point que la page ne justifie plus sa place.

Dans les deux cas, la réponse est éditoriale : consolider avec la page concurrente interne, ou approfondir substantiellement. Republier à l'identique en espérant un retour ne produit rien.

Liste de vérification pour une nouvelle page

Avant de publier, ces points couvrent les causes d'échec de chaque étape :

  1. Découverte — au moins un lien interne depuis une page qui reçoit elle-même du trafic. Présence dans le sitemap.
  2. Exploration — URL non bloquée, réponse en 200 sans chaîne de redirection.
  3. Rendu — texte, liens et données structurées présents dans le HTML initial.
  4. Indexation — la page apporte quelque chose qui n'existe pas déjà, sur le site comme ailleurs. Aucune autre page du site ne vise la même intention.
  5. Classement — une demande de recherche existe réellement ; le titre correspond à l'intention et tient dans la largeur affichable.

Le point 4 est le seul qui ne se vérifie pas avec un outil. C'est aussi celui qui décide.

Ce qu'il faut retenir

L'indexation n'est pas une formalité technique mais une décision éditoriale rendue par une machine. Les leviers techniques — sitemap, maillage, performance, balises — déterminent si Google peut lire une page. Ils ne déterminent pas s'il veut la conserver.

Cette distinction résume le guide entier. Devant une page non indexée, la première question n'est jamais « quelle balise ai-je oubliée » mais « Google a-t-il lu cette page ». Si la réponse est non, le problème est technique et se corrige en quelques jours. Si la réponse est oui, le problème est éditorial, et aucune balise ne le résoudra.

Pour approfondir un point précis, ces guides détaillent chacun un mécanisme évoqué ici : lire le rapport d'indexation, choisir entre noindex, canonical et robots.txt, construire un sitemap utile, structurer le maillage interne et éviter les pages doorway. Le vocabulaire employé est défini dans le glossaire de l'indexation.