Page détectée, actuellement non indexée : quelles solutions sur WordPress ?

« Détectée, actuellement non indexée » n’est pas un blocage : c’est Google qui reconnaît avoir vu vos URL sans encore prendre le temps de les explorer. Le rapport ne donne aucune date de dernier passage, et c’est précisément le signe distinctif de ce statut. Voici pourquoi Google le déclenche sur WordPress, comment le distinguer d’un vrai problème, et une cause technique qui échappe à la quasi-totalité des audits. Ce guide complète notre guide complet de Google Search Console pour WordPress pour ce statut précis.

Ce que « détectée, actuellement non indexée » veut dire

Soyons précis : ce statut n’a rien à voir avec un blocage technique. Google le formule ainsi dans sa documentation officielle : « la page a été détectée, mais l’exploration a été reportée car votre site risquait d’être surchargé ». Autrement dit, Googlebot connaît l’existence de l’URL, généralement via un lien interne ou un sitemap, mais n’a pas encore programmé sa visite.

C’est ce qui le distingue d’« explorée, actuellement non indexée », où Google a bien lu la page avant de choisir de ne pas l’indexer. Les deux statuts se confondent souvent dans un diagnostic rapide, alors qu’ils pointent vers deux problèmes opposés : ici, un souci de priorisation du crawl ; là, un jugement sur la qualité du contenu. Notre guide sur le statut « explorée, non indexée » traite ce second cas en détail, ne le confondez pas avec celui-ci.

Faut-il s’inquiéter ? Le seuil qui change tout

Non par défaut. Un lot d’URL en « détectée, non indexée » représentant moins de 10 % de votre site n’appelle aucune action. C’est le comportement normal d’un moteur qui arbitre ses ressources sur des milliards de pages : Google explore ce qui lui paraît prioritaire en premier, le reste patiente.

Le signal d’alerte apparaît quand la proportion grimpe, ou quand des pages stratégiques (celles qui doivent convertir ou qui portent votre trafic) restent bloquées plusieurs semaines dans cet état. Dans ce cas, le report d’exploration n’est plus un simple arbitrage de priorité, il révèle un vrai problème sous-jacent.

Les causes réelles sur un site WordPress

La documentation Google reste volontairement vague sur la « surcharge ». En pratique, sur WordPress, cinq causes reviennent régulièrement.

1. Un hébergement qui répond trop lentement

Google adapte sa fréquence de crawl à la vitesse de réponse de votre serveur. Un hébergement mutualisé qui met plus d’une seconde à répondre, ou qui renvoie ponctuellement des erreurs 5xx sous la charge, incite Googlebot à ralentir de lui-même plutôt qu’à insister.

2. Un contenu jugé faible ou dupliqué

Pages quasi vides, fiches produit qui ne changent que le prix, contenu généré par IA sans retouche : Google peut choisir de ne pas explorer en priorité des URL qui ressemblent, dès l’aperçu de leurs signaux, à du contenu à faible valeur. Sur un site YMYL (santé, finance, droit), cette exigence est plus stricte encore.

3. Un maillage interne insuffisant

Une page atteignable seulement depuis un sitemap, sans aucun lien interne pointant vers elle, envoie un signal de priorité faible. Le maillage reste le moyen le plus direct de dire à Google qu’une page compte.

4. Un thème ou une extension qui complique le rendu

Un contenu chargé en JavaScript côté client, sans rendu serveur, oblige Google à un second passage de rendu, plus coûteux et donc plus tardif. Sur un site WordPress classique le problème reste rare, mais il apparaît sur les thèmes qui injectent le contenu principal via un framework JS.

5. Un site jeune, sans autorité externe

Un nom de domaine récent, sans backlinks, part avec un budget de crawl naturellement plus restreint. Ce n’est pas une pénalité, seulement la conséquence d’un capital confiance encore à construire.

Le piège invisible : WP-Cron et la fausse surcharge

C’est le point que les guides génériques, y compris les plus complets sur ce statut, ne relient jamais à WordPress : par défaut, WordPress n’utilise pas de vraie tâche planifiée système. Il simule un cron via le fichier wp-cron.php, déclenché à CHAQUE chargement de page, y compris ceux de Googlebot lui-même.

Concrètement : si des extensions de sauvegarde, de cache ou de statistiques ont programmé des tâches lourdes (régénération de miniatures, appel à une API externe, purge de cache), une partie de ces tâches peut s’exécuter en tâche de fond au moment précis où Googlebot charge une page, allongeant son temps de réponse sans que rien n’apparaisse dans vos outils d’analytics classiques, puisque ce ralentissement touche une requête de robot, pas un visiteur humain suivi par un tag JavaScript.

Sur un hébergement mutualisé aux ressources limitées, cette latence ajoutée peut suffire à faire percevoir à Google un risque de surcharge, même sur un site à trafic humain faible. Le symptôme se lit dans Search Console, rubrique Paramètres puis Statistiques sur l’exploration, sous l’indicateur Temps de réponse moyen du serveur : des pics récurrents et non expliqués par un trafic visiteur élevé pointent vers cette hypothèse.

La correction est simple et rarement appliquée : désactiver le pseudo-cron dans wp-config.php avec define('DISABLE_WP_CRON', true);, puis déclencher les tâches planifiées par un vrai cron système (via l’espace hébergeur) qui appelle wp-cron.php à intervalle fixe, par exemple toutes les 15 minutes, en dehors des pics de trafic. Les tâches WordPress s’exécutent alors sur un rythme prévisible, plutôt qu’au hasard des visites, humaines ou robots.

Diagnostiquer avec Search Console

Avant de corriger, encore faut-il savoir précisément où se situe le problème. Sur un site avec plusieurs dizaines de pages concernées, un passage isolé dans Search Console ne suffit pas toujours à hiérarchiser les causes : c’est le rôle d’un audit SEO WordPress complet de croiser indexation, maillage et temps de réponse serveur plutôt que de traiter chaque symptôme séparément.

1. Ouvrir le rapport Indexation des pagesRepérez la ligne « Détectée, actuellement non indexée » et notez le nombre d’URL concernées ainsi que leur part sur l’ensemble du site.
2. Inspecter quelques URL représentativesCollez chaque URL dans l’outil d’inspection, en haut de Search Console, pour voir si Google confirme le même statut en temps réel.
3. Vérifier l’état de l’hôteDans Paramètres puis Statistiques sur l’exploration, contrôlez que l’indicateur d’état du serveur reste vert et que le temps de réponse moyen ne présente pas de pics inexpliqués.
4. Croiser avec le maillage interneVérifiez, via un crawl Screaming Frog ou l’inspection d’URL, que chaque page concernée reçoit au moins un lien interne suivi depuis une page déjà indexée.
5. Comparer au reste du rapport d’indexationUn pic isolé sur ce statut, alors que le reste du rapport est stable, oriente vers une cause ponctuelle (publication en masse, import) plutôt qu’un problème structurel. Notre guide pour interpréter le rapport d’indexation détaille chaque statut ligne par ligne.

Les solutions, dans l’ordre

Inutile de tout tenter en même temps. Voici l’ordre qui produit le plus d’effet pour le moins d’effort.

Renforcer le maillage avant de demander une indexation manuelle

La fonction « Demander une indexation » de l’outil d’inspection peut sembler la solution la plus rapide. En réalité, elle traite le symptôme sans corriger la cause : si la page reste orpheline ou trop lente à charger, elle repassera dans le même statut quelques semaines plus tard. Réservez-la aux cas ponctuels (page tout juste publiée), pas comme correctif systématique sur un lot entier.

Nettoyer le budget de crawl

Passez en noindex ou bloquez via robots.txt les pages à faible valeur qui consomment du budget de crawl sans intérêt SEO : résultats de recherche interne, archives d’étiquettes vides, pages de pagination profonde. Attention à ne jamais cumuler noindex ET blocage robots.txt sur la même URL : le blocage empêche Google de lire la balise noindex, rendant l’instruction inopérante. Pendant que vous y êtes, vérifiez aussi l’absence de chaînes de redirection : Google suit un nombre limité de sauts avant d’abandonner, et chaque redirection intermédiaire consomme du budget de crawl pour rien.

Vérifier l’hébergement et le temps de réponse serveur

Un passage sous la seconde de temps de réponse serveur, mesuré hors cache, change souvent la donne à lui seul. Sur WordPress, cela passe par un cache de page correctement configuré, la correction du pseudo-cron vue plus haut, et un hébergement dimensionné pour le trafic réel du site.

Muscler le contenu et le maillage des pages concernées

Ajoutez du contenu réellement différenciant, reliez la page depuis au moins deux ou trois pages déjà indexées avec une ancre descriptive, et assurez-vous qu’elle figure dans un sitemap WordPress à jour et correctement soumis.

Construire des liens entrants si le site est jeune

Sur un nom de domaine récent, quelques liens externes de qualité accélèrent la confiance accordée par Google au domaine dans son ensemble, ce qui profite indirectement à la vitesse d’exploration de toutes ses pages.

Combien de temps avant que ça se résorbe

Google ne communique aucun délai garanti. En pratique, sur un site à l’autorité déjà installée et sans problème structurel, un lot corrigé (maillage renforcé, budget de crawl nettoyé) évolue généralement en quelques jours à quelques semaines. Sur un site jeune ou sans backlinks, comptez plutôt en mois : le budget de crawl limité qui lui est accordé ralentit tout le processus, corrections comprises.

Un point de vigilance : ne jugez jamais sur deux ou trois jours d’observation. Les variations du rapport d’indexation sont bruitées au jour le jour, la tendance ne devient lisible qu’sur deux à trois semaines de recul.

Questions fréquentes

Prioriser plutôt que subir

Un lot de pages « détectées, non indexées » n’est ni une urgence automatique, ni un non-événement à ignorer sans vérification. La bonne question n’est pas « comment forcer l’indexation », mais « pourquoi Google juge-t-il ces pages moins prioritaires que les autres ». Une fois cette cause isolée, qu’il s’agisse de maillage, de temps de réponse serveur ou d’un pseudo-cron mal réglé, la correction est généralement rapide à mettre en œuvre.