Détectée, actuellement non indexée : débloquer l'exploration

« Détectée, actuellement non indexée » est un motif du rapport Indexation des pages de Google Search Console qui signifie une chose précise : Google connaît l'existence de l'URL, par un sitemap, un lien interne, un lien externe ou une redirection, mais n'a pas encore choisi de l'explorer. Aucun contenu n'a été lu à ce stade, donc aucun jugement de qualité n'a été porté sur la page. C'est une décision d'exploration qui n'a pas encore été prise, pas une décision d'indexation qui aurait été refusée.

C'est un point de confusion fréquent, parce qu'un statut voisin porte un nom presque identique : « Explorée, actuellement non indexée ». Celui-là concerne une page que Googlebot a bien lue, mais que l'algorithme a jugée insuffisante pour l'index, pour des raisons de qualité ou de duplication. « Détectée, actuellement non indexée » se situe une étape avant : le problème n'est pas ce que contient la page, c'est que Google n'a pas encore pris la décision de venir la lire. Réagir aux deux statuts avec la même réponse, à savoir améliorer le contenu, ne résout rien dans ce cas précis, puisque le contenu n'a jamais été examiné.

Pourquoi Google retarde l'exploration d'une URL

Google n'explore pas une URL simplement parce qu'elle existe et figure dans un sitemap. Chaque exploration a un coût réel côté Google : bande passante, temps de calcul, et parfois rendu JavaScript complet de la page. Pour arbitrer ce coût, Google attribue à chaque site ce qu'il appelle une demande d'exploration, qui dépend principalement de trois signaux : la popularité perçue de l'URL, mesurée par les liens internes et externes qui y pointent ; la fraîcheur attendue du contenu, une page qui change souvent étant revisitée plus souvent ; et l'importance relative de cette URL comparée aux autres pages du même site.

Une URL neuve, publiée hier, sans lien entrant, sur un site qui compte déjà des dizaines de milliers de pages, se retrouve mécaniquement en bas de cette file d'attente. Ce n'est pas une pénalité, c'est un calcul de priorité. Google explore en premier ce qu'il estime devoir explorer en premier, et une page isolée, invisible depuis le reste du site, n'a simplement pas assez de signaux pour remonter dans la file avant les autres candidats.

Ce délai peut durer de quelques jours à plusieurs semaines selon la taille et l'autorité du site. Un site neuf, sans historique de crawl établi auprès de Google, met généralement plus de temps à voir ses nouvelles URLs explorées qu'un site déjà indexé depuis des années, dont le taux d'exploration quotidien est élevé et stable.

Pour visualiser l'ordre de grandeur : un blog qui publie cinq articles par mois, avec un historique de dix ans et un maillage soigné, voit généralement ses nouveaux articles explorés en quelques heures à quelques jours, parce que Google a appris à revenir souvent sur ce domaine. Un site qui publie brutalement mille pages en une semaine, sans historique comparable de volume, ne bénéficie pas du même traitement : Google n'a aucune raison, à ce stade, de croire que ce rythme va se maintenir, et il explore prudemment plutôt que d'engager immédiatement des ressources sur l'ensemble du lot.

Le rôle de la capacité de votre serveur

Indépendamment de la demande d'exploration, Google applique aussi une limite de vitesse d'exploration fondée sur ce que votre serveur peut absorber sans dégradation. Si le serveur répond lentement, ou renvoie une proportion croissante d'erreurs 5xx ou de délais d'attente, Googlebot ralentit volontairement son rythme de requêtes pour ne pas aggraver la situation. Résultat concret : même si la demande d'exploration pour vos pages est élevée, le nombre d'URLs effectivement récupérées chaque jour reste plafonné par cette limite.

C'est un point qui échappe souvent à un diagnostic purement éditorial. Un hébergement partagé avec un temps de première réponse (TTFB) élevé, ou un pare-feu applicatif qui impose un défi ou un ralentissement aux user-agents non reconnus comme des visiteurs humains classiques, peut freiner Googlebot sans que personne ne s'en aperçoive dans les outils d'analytics habituels, puisque ces outils ne comptent presque jamais le trafic des robots.

Le rapport à consulter est celui des statistiques sur l'exploration, accessible depuis les réglages de Search Console. Il montre le nombre de requêtes par jour, le temps de réponse moyen du serveur, et la répartition des réponses par code de statut hôte. Si le temps de réponse moyen dépasse largement une seconde, ou si la part d'erreurs serveur progresse dans le temps, c'est le premier levier à actionner, avant même de toucher au contenu ou aux liens.

Trop d'URLs à faible valeur diluent le budget

Un budget d'exploration ne se répartit pas équitablement entre toutes les pages d'un site : il se répartit entre toutes les URLs que Google connaît, qu'elles aient de la valeur ou non. Si un site génère un nombre d'URLs à faible valeur nettement supérieur au nombre de pages réellement utiles, Google passe une partie significative de son budget disponible à revisiter ce volume à faible valeur, et les quelques pages que vous voulez réellement voir indexées attendent leur tour derrière elles.

Ce phénomène est particulièrement fréquent sur les sites e-commerce et les sites avec beaucoup de contenu généré automatiquement, où le nombre de combinaisons possibles d'URLs dépasse de très loin le nombre de pages qu'un humain jugerait uniques.

Un exemple concret : une boutique avec 200 produits, chacun disponible en 4 couleurs et 5 tailles, avec un filtre de tri par prix et par popularité, peut techniquement générer plusieurs dizaines de milliers d'URLs distinctes si chaque combinaison de filtre produit sa propre adresse explorable. Le catalogue réel ne contient que 200 fiches produits utiles ; le reste n'apporte rien qu'une variation de tri ou de facette sur un contenu déjà présent ailleurs. Si toutes ces combinaisons sont explorables, Google passe l'essentiel de son budget d'exploration à revisiter des variations plutôt que les 200 pages qui comptent réellement pour le chiffre d'affaires.

• Pages de résultats de recherche interne, quand elles sont explorables et indexables
• Combinaisons de filtres à facettes qui créent une URL par croisement de critères
• Pagination profonde sur des listes sans contenu additionnel réellement unique
• Archives générées automatiquement par date, par auteur ou par étiquette
• Paramètres de suivi ou de session qui dupliquent une même page sous plusieurs URLs

Un maillage interne faible signale une faible priorité

Les liens internes sont le principal signal que Google utilise pour évaluer l'importance relative d'une page à l'intérieur d'un site. Une page accessible depuis la navigation principale, depuis la page d'accueil, ou depuis plusieurs pages déjà bien explorées, reçoit un signal de priorité implicite. Une page enfouie à cinq ou six clics de profondeur, ou reliée uniquement depuis une page d'archive à faible trafic, envoie le signal inverse, même si cette page figure bien dans le sitemap XML.

C'est la différence entre une page techniquement présente dans le sitemap et une page réellement intégrée à la structure du site. La présence dans un sitemap est un signal faible comparé à un lien éditorial placé sur une page que Google explore déjà fréquemment. Une page peut être orpheline dans les faits, même si elle n'est pas orpheline au sens strict du terme, dès qu'aucun lien de navigation ou de contenu ne mène naturellement jusqu'à elle.

La correction la plus efficace consiste souvent à ajouter un lien contextuel vers la page concernée depuis une page à forte fréquence de crawl : une page catégorie, un article récemment mis à jour, ou la page d'accueil si le sujet le justifie. Un seul lien placé sur une page que Googlebot revisite quotidiennement produit souvent plus d'effet que dix soumissions successives du sitemap.

Diagnostiquer avec Search Console, dans l'ordre

Avant de corriger quoi que ce soit, il faut confirmer précisément la cause, car les symptômes de ces quatre facteurs se ressemblent dans le rapport Indexation des pages mais appellent des corrections différentes. La démarche suivante permet de les distinguer sans deviner.

• Ouvrir le rapport Pages et vérifier que le statut exact est bien « Détectée, actuellement non indexée », et non un statut voisin comme « Explorée, actuellement non indexée »
• Utiliser l'outil d'inspection d'URL sur l'adresse concernée : dans ce statut précis, il n'affichera aucune date de dernière exploration, ce qui confirme qu'aucun crawl n'a encore eu lieu
• Consulter le rapport Sitemaps pour vérifier que l'URL y figure bien et que le sitemap a été traité récemment sans erreur
• Ouvrir Réglages puis Statistiques sur l'exploration pour lire le volume quotidien de requêtes, le temps de réponse moyen et la répartition des codes de statut hôte
• Comparer le nombre total d'URLs connues du site, cumulé dans le rapport Pages, au volume de requêtes d'exploration quotidiennes : un déséquilibre marqué confirme un problème de budget plutôt qu'un simple cas isolé

Que corriger en premier

Ces quatre causes ne se corrigent pas dans n'importe quel ordre. Certaines conditionnent l'effet des autres, donc les traiter dans le désordre revient souvent à ne rien changer du tout au résultat final.

• D'abord la santé du serveur : si les statistiques d'exploration montrent un temps de réponse élevé ou un taux d'erreur significatif, corriger ce point avant tout le reste, puisqu'il plafonne le volume d'exploration quotidien quel que soit le reste
• Ensuite la réduction de la surface d'URLs à faible valeur : canonicaliser, passer en noindex ou bloquer via robots.txt les facettes et pages autogénérées sans valeur unique, pour que le budget restant se concentre sur les pages qui comptent
• Puis le renforcement du maillage interne vers la ou les pages concernées, depuis des pages déjà explorées fréquemment
• Enfin, et seulement en dernier recours pour un petit nombre de pages vraiment prioritaires, utiliser la demande d'indexation manuelle dans l'outil d'inspection d'URL : elle force une tentative d'exploration ponctuelle, mais Google limite elle-même l'effet utile de ces demandes au-delà d'un certain volume, donc ce n'est pas une solution qui s'applique à des centaines d'URLs

Erreurs à éviter

Certaines réactions, bien qu'intuitives, aggravent le problème ou font simplement perdre du temps sans rien résoudre.

Bloquer l'URL via robots.txt après qu'elle a été détectée ne corrige rien : cela indique seulement à Google de ne pas l'explorer du tout, ce qui la fait basculer vers un statut différent, mais toujours hors de l'index. De même, multiplier les demandes d'indexation manuelles en espérant accélérer les choses n'a pas d'effet proportionnel : au-delà d'un certain volume par jour, ces demandes sont ignorées ou mises en file sans traitement prioritaire supplémentaire.

Réécrire le contenu de la page en pensant résoudre un problème de qualité est également hors sujet ici : il n'y a pas encore eu de lecture par Google, donc pas de jugement de qualité à corriger. Enfin, attendre passivement pendant des mois sur un grand nombre de pages sans agir sur le budget d'exploration global ne résout rien par lui-même : le statut ne se dissipe pas seul si la cause structurelle, serveur, surface d'URLs ou maillage, reste inchangée.

Quand ce statut doit inquiéter davantage

Pour une poignée de pages neuves sur un site par ailleurs sain, ce statut est parfaitement normal et se résout en quelques jours à quelques semaines sans intervention particulière. Il devient un signal d'alerte plus sérieux dans deux cas précis : lorsqu'il persiste plusieurs mois sur des pages commerciales centrales du site, celles qui génèrent le chiffre d'affaires ou les leads, ou lorsqu'il touche une part croissante du total des URLs connues à chaque nouvel audit, plutôt qu'une part stable ou décroissante.

Dans ces deux cas, il ne s'agit plus d'une simple file d'attente qui se vide progressivement, mais d'un problème structurel de budget d'exploration qui s'aggrave. Une analyse plus fine des fichiers de logs serveur, qui montre exactement ce que Googlebot explore réellement jour par jour plutôt que ce que Search Console échantillonne, devient alors le complément naturel de ce diagnostic pour confirmer où va concrètement le budget disponible.