Indexation
« Explorée, actuellement non indexée » : comprendre le statut et le corriger
Ce statut du rapport d’indexation n’est pas une erreur au sens strict : Google a exploré la page et choisi de ne pas la garder, pour l’instant. Tout l’enjeu est de distinguer les exclusions normales des vrais blocages, puis de décider gabarit par gabarit.
« Explorée, actuellement non indexée » : que faire quand ce statut grossit semaine après semaine dans la Search Console ? Le réflexe courant consiste à demander l’indexation de chaque URL, une par une. C’est rarement utile. Ce statut décrit une décision de Google, pas une panne : il a récupéré la page, l’a évaluée, et ne l’a pas retenue dans son index, du moins pas encore.
La bonne réponse dépend donc de la raison de cette décision. Certaines URL n’ont rien à faire dans l’index, et leur exclusion est saine. D’autres sont des pages utiles, freinées par un problème technique ou structurel que l’on peut corriger. Cette note propose une méthode de tri en quatre temps : comprendre le statut, constituer un échantillon, chercher la cause, puis décider avec un tableau simple.
Explorée, actuellement non indexée : ce que signifie vraiment ce statut
Dans le rapport Indexation des pages, ce motif apparaît dans la liste des raisons pour lesquelles des pages ne sont pas indexées. La documentation de Google le résume ainsi : la page a été explorée, mais pas indexée ; elle pourra l’être ou non à l’avenir, et il n’est pas nécessaire de la soumettre à nouveau.
Trois précisions évitent les contresens :
- ce n’est pas une pénalité : aucune action manuelle n’est en jeu, il s’agit d’une sélection, comme celle que Google opère sur toutes les URL qu’il découvre ;
- le statut évolue : une URL peut y entrer, en sortir et y revenir au fil des réexplorations ;
- le rapport est un échantillon daté : les données arrivent avec quelques jours de décalage, et l’interface ne liste qu’un millier d’exemples au plus par motif. Sur un grand catalogue, ce que l’on voit n’est qu’une partie de ce qui existe.
En creux, Google a jugé que la page ne valait pas, pour l’instant, une place dans son index : un jugement sur l’URL, parfois sur son gabarit, quelquefois sur la qualité perçue du site entier.
« Explorée » ou « Détectée » : deux statuts, deux diagnostics
Le motif voisin, « Détectée, actuellement non indexée », raconte une tout autre histoire : Google connaît l’URL, mais ne l’a pas encore explorée. Sa documentation cite notamment le cas d’une exploration reportée parce qu’elle risquait de surcharger le serveur.
| Critère | Détectée, non indexée | Explorée, non indexée |
|---|---|---|
| Ce que Google a fait | découvert l’URL, sans l’explorer | exploré la page, sans l’indexer |
| Question posée | Google peut-il et veut-il explorer ? | la page mérite-t-elle l’index ? |
| Causes typiques | serveur lent ou en erreur, URL générées en masse | contenu faible ou dupliqué, rendu incomplet, signaux contradictoires |
| Où regarder | logs serveur, statistiques d’exploration | inspection d’URL, HTML rendu, maillage |
Le premier relève du budget de crawl, le second de l’indexation. Les confondre conduit à optimiser le serveur pour des pages dont le problème est le contenu, ou l’inverse.
Constituer un échantillon d’URL représentatif
On ne diagnostique pas un statut, on diagnostique des URL. La première étape consiste à exporter la liste depuis le rapport, puis à la classer.
- Segmenter par gabarit : fiches produits, catégories, pages filtrées, articles, pages de tag, résultats de recherche interne. La structure des URL suffit souvent à les reconnaître.
- Croiser avec la valeur : pour chaque gabarit, quelles URL ont une demande de recherche, du trafic passé, des liens externes, un rôle commercial ?
- Tirer un échantillon par gabarit : une vingtaine d’URL par type de page suffit en général à faire apparaître un motif, en mêlant pages récentes et anciennes.
- Inspecter chaque URL : date de dernière exploration, robot utilisé, canonique déclarée et retenue, puis test en direct pour voir le HTML rendu et la capture d’écran.
Pour les gros volumes, l’API d’inspection d’URL automatise ce contrôle, dans la limite de son quota quotidien. Autre astuce : déclarer un sitemap XML par gabarit. Le rapport d’indexation se filtre par sitemap, et chaque type de page obtient ses propres chiffres.
# un tirage par gabarit, reconnu au premier segment de l'URL
import csv, random
from collections import defaultdict
par_gabarit = defaultdict(list)
for row in csv.DictReader(open("exploree-non-indexee.csv")):
segment = row["URL"].split("/")[3] or "accueil"
par_gabarit[segment].append(row["URL"])
for gabarit, urls in par_gabarit.items():
tirage = random.sample(urls, min(20, len(urls)))
print(gabarit, len(urls), "URL, dont", len(tirage), "à inspecter")Conseil
Tenez l’échantillon dans un tableur : une ligne par URL, une colonne par signal (statut, dernière exploration, canonique retenue, mots visibles après rendu, liens internes entrants). Les causes se lisent en colonne bien plus vite qu’en ouvrant les pages au hasard.
Les causes côté contenu : pages faibles, quasi doublons, gabarits vides
Très souvent, la cause est éditoriale. Google explore, compare, et estime que la page n’apporte pas assez par rapport à ce qu’il connaît déjà.
- Pages faibles : quelques lignes de texte générique, une fiche produit reprise du fournisseur, un article qui répond moins bien que d’autres à la même question.
- Quasi doublons : déclinaisons de couleur ou de taille sur des URL distinctes, pages de villes qui ne changent que le nom, archives par date qui reprennent les mêmes extraits.
- Gabarits vides : catégories d’un ou deux produits, pages de tag créées pour un seul article, résultats de recherche interne indexables, filtres sans résultat.
- Contenu dominé par le gabarit : quand le menu, le pied de page et les blocs répétés pèsent plus que le contenu propre, toutes les pages se ressemblent.
Le bon test est simple : la page répond-elle à une intention de recherche distincte, mieux ou autrement que les pages déjà indexées, y compris celles de votre propre site ? Si la réponse est non, la question n’est plus « comment la faire indexer », mais « doit-elle exister ».
Les causes techniques et structurelles
Rendu, canonical et signaux contradictoires
- Rendu incomplet : le contenu principal arrive par JavaScript après un appel d’API lent ou bloqué, et le HTML rendu que voit Google est presque vide. L’inspection d’URL le montre immédiatement.
- Canonical contradictoire : la page déclare une canonique vers une autre URL, alors que le sitemap, le maillage interne et les hreflang la désignent elle-même. Google reçoit des messages opposés et tranche seul.
- Variantes d’URL : la même page accessible avec et sans barre oblique finale, en http et en https, avec des paramètres de suivi. Chaque variante dilue les autres.
- Pagination mal traitée : pages 2, 3 et suivantes canonicalisées vers la page 1, dont le contenu diffère ; les produits profonds deviennent difficiles à atteindre.
Profondeur, maillage et pages orphelines
Le maillage interne est l’un des signaux les plus nets de l’importance qu’un site accorde à une page. Une URL à six clics de l’accueil, liée depuis une seule page de pagination, ou présente uniquement dans le sitemap XML, envoie le message inverse.
Trois sources croisées font apparaître ces cas : un crawl complet (profondeur, liens entrants), les sitemaps (ce que vous déclarez) et les logs serveur (ce que Googlebot visite). Les pages orphelines, dans le sitemap mais absentes du crawl, sont des candidates naturelles à ce statut.
Erreur fréquente
Ajouter un noindex sur toutes les pages du statut pour « nettoyer le rapport ». Elles changent de motif, mais rien n’est réglé si des pages utiles étaient concernées. Le noindex est une décision éditoriale, pas un correctif de rapport.
Que faire d’une page explorée, actuellement non indexée : le tableau de décision
Une fois la cause identifiée pour chaque gabarit, la décision se prend entre quatre options.
| Décision | Quand la choisir | Action concrète |
|---|---|---|
| Améliorer | la page vise une intention réelle, mais son contenu ou son rendu est insuffisant | enrichir le contenu propre, corriger le rendu, ajouter des liens internes depuis des pages fortes |
| Fusionner | plusieurs pages se partagent la même intention | regrouper le contenu sur l’URL la plus solide, rediriger les autres en 301, mettre à jour liens et sitemap |
| Désindexer | la page sert la navigation, pas la recherche (filtres, tris, recherche interne) | meta robots noindex et retrait du sitemap ; supprimer (404 ou 410) une page sans valeur ni lien |
| Attendre | page récente, site jeune, gabarit en cours de réexploration après correctif | surveiller le statut et les logs, sans autre action |
Deux règles complètent le tableau. On décide par gabarit, pas URL par URL : corriger le modèle d’une fiche corrige toutes les fiches. Et l’on traite d’abord les gabarits qui portent de la valeur, avant de faire le ménage dans ceux qui n’en portent pas. Un dernier piège : le noindex n’est lu que si la page reste explorable. Ne bloquez une section dans le robots.txt qu’une fois sa désindexation constatée.
Valider les correctifs et suivre l’évolution du rapport
Un correctif n’est terminé que lorsque son effet est observé. Pour ce statut, l’effet se lit à plusieurs endroits, et rarement tout de suite.
- Les logs serveur montrent quand Googlebot repasse sur les pages corrigées : sans nouvelle exploration, rien ne peut changer.
- L’inspection d’URL de l’échantillon de départ confirme que le HTML rendu, la canonique et le maillage sont conformes, puis que le statut évolue.
- Le rapport filtré par sitemap donne la tendance par gabarit, semaine après semaine.
- La demande d’indexation peut accélérer la réexploration de quelques URL stratégiques une fois corrigées. Elle est limitée en nombre et ne remplace pas un maillage solide.
Le délai dépend de la fréquence d’exploration des pages et de l’ampleur des changements. Aucun outil ne force l’indexation : on crée les conditions, on mesure, on ajuste.
Questions fréquentes
« Explorée, actuellement non indexée » est-il une pénalité ?
Non. C’est une décision de sélection : Google a exploré la page et ne l’a pas retenue dans son index pour le moment. Aucune action manuelle n’est en cause ; la Search Console les signale dans un rapport distinct. Le statut peut évoluer à chaque nouvelle exploration, dans un sens comme dans l’autre, selon la page et la qualité perçue du site.
Faut-il demander l’indexation de toutes les URL concernées ?
Non. Google indique qu’il n’est pas nécessaire de soumettre à nouveau ces URL, et une demande ne change rien si la cause demeure. La demande d’indexation se réserve à quelques pages stratégiques, après correction. Pour le reste, le levier est structurel : améliorer, fusionner ou désindexer par gabarit, renforcer le maillage interne, puis laisser Googlebot repasser.
Combien de pages dans ce statut est-il normal d’avoir ?
Il n’existe pas de seuil universel. Un site e-commerce à facettes ou un média riche en pages de tag aura mécaniquement beaucoup d’URL concernées, sans que ce soit un problème. Ce qui compte, c’est la nature des pages : si des fiches, des catégories ou des articles stratégiques figurent dans l’échantillon, il faut agir ; s’il s’agit de filtres et de variantes, l’exclusion est plutôt saine.
Quelle différence avec une page exclue par la balise noindex ?
Avec une balise noindex, c’est vous qui demandez l’exclusion, et le rapport l’affiche sous un motif dédié. Avec « Explorée, actuellement non indexée », c’est Google qui choisit de ne pas indexer une page que vous lui permettez d’indexer. Le premier cas se vérifie dans le code de la page ; le second se diagnostique par l’échantillonnage, le rendu et le maillage.
Conclusion : un tri, pas une alerte
Face à « Explorée, actuellement non indexée », la question utile n’est pas « comment faire disparaître ce chiffre », mais « quelles pages méritent d’être indexées, et pourquoi ne le sont-elles pas ». Le statut ne distingue pas une page de filtre légitimement écartée d’une fiche stratégique freinée par un rendu défaillant. Le tri par gabarit, l’échantillon inspecté et le tableau de décision font cette distinction à sa place.
Deux contrôles prolongent ce diagnostic : vérifier que les visites de Googlebot dans vos logs sont authentiques, et tester ce que Google voit réellement d’une page rendue en JavaScript.
Julien Jimenez
expert SEO indépendant · SEO technique
Julien Jimenez est un expert SEO français indépendant. Il pratique le référencement depuis 2009 et l’a appris en autodidacte, en créant ses propres sites et des dizaines de sites de test. Spécialiste de Google Discover, créateur de la formation « Disco », il intervient sur le SEO technique des sites à fort volume de pages : crawl, logs serveur, indexation, rendu JavaScript et données structurées, avec les équipes en place, partout en France et dans l’espace francophone.