Rapport d’indexation Search Console : comment interpréter les erreurs ?

Le rapport d’indexation des pages de Search Console affiche parfois quinze motifs différents sur un même site, et la plupart des propriétaires WordPress ne savent pas distinguer une erreur bloquante d’un simple avertissement. Ce guide décode chaque motif, la mécanique réelle du bouton « Valider la correction », et une règle peu documentée de Google qui explique pourquoi un incident réglé en une heure peut, sur le papier, s’étirer sur des mois.

Comment lire le rapport d’indexation des pages

Le rapport affiche deux chiffres en haut de page : le nombre d’URL indexées et le nombre d’URL non indexées, avec un graphique de leur évolution. Un site qui grossit doit voir sa courbe de pages indexées progresser en parallèle. Une stagnation ou une baisse pendant que le site publie du contenu est le premier signal à surveiller, avant même d’ouvrir le détail des motifs.

Les deux tableaux à ne pas confondre

Sous le graphique, Search Console sépare deux tableaux qui n’ont pas la même gravité. Le premier, « Pourquoi les pages ne sont pas indexées », liste les erreurs : elles empêchent l’indexation et méritent une correction. Le second, « Améliorer l’expérience sur la page », liste des avertissements non bloquants : la page est indexée quand même, mais un problème annexe subsiste (Core Web Vitals, HTTPS mal configuré). Traiter les deux tableaux avec la même urgence est une erreur de priorisation fréquente : commencez toujours par le premier.

La colonne Source : ce que vous pouvez corriger, ce que vous ne pouvez pas

Chaque ligne du rapport porte une colonne Source. « Site Web » signifie que le problème vient de votre configuration et que vous pouvez agir dessus. « Google » signifie que la décision (souvent un choix de canonique) a été prise du côté de l’algorithme : vous pouvez influencer la situation (balisage, maillage), mais pas la forcer par une simple correction technique. Beaucoup de temps est perdu à vouloir « réparer » des lignes marquées Google alors que le vrai levier est ailleurs, typiquement le renforcement du maillage interne vers la page concernée.

Les erreurs bloquantes, motif par motif

Voici les motifs qui reviennent le plus souvent sur un site WordPress, avec la cause réelle derrière chacun et l’angle spécifique au CMS quand il existe.

Erreurs serveur, autorisation et pages introuvables (5xx, 404, 401, 403)

Une erreur 5xx signale que votre serveur a renvoyé une erreur au moment où Googlebot a demandé la page : bug PHP, base de données saturée, hébergement mutualisé à bout de ressources. Sur WordPress, ce cas apparaît souvent après une mise à jour de plugin mal testée ou un pic de trafic que l’hébergement n’absorbe pas. Une 404 signifie qu’aucune page ne répond à cette URL : normal si le contenu a été supprimé volontairement, anormal si un permalien a changé sans redirection. Une 401 indique une demande d’authentification : fréquent sur un site en développement resté accessible en preview, ou un blocage IP trop large côté pare-feu. Une 403 (interdiction d’accès) ressemble à la 401 mais vient plus souvent d’une règle de sécurité serveur (Wordfence, règle .htaccess) trop agressive envers les robots.

Soft 404 et redirections mal configurées

Le soft 404 est le motif le plus mal compris : la page renvoie un code 200 (succès) mais son contenu ressemble, aux yeux de Google, à une page d’erreur ou à une coquille vide. Une page produit WooCommerce en rupture de stock permanente, un résultat de recherche interne sans résultat, ou une page catégorie vidée de ses articles sont des déclencheurs classiques. La correction n’est pas de renvoyer un vrai 404 par réflexe : si la page a vocation à recevoir du contenu plus tard, mieux vaut l’enrichir ou la rediriger vers une page parente pertinente. Côté redirections, distinguez une chaîne (plusieurs redirections successives avant d’atteindre la page finale, qui ralentit et dilue le signal) d’une boucle (redirection qui revient sur elle-même, qui bloque totalement l’accès). Sur WordPress, les chaînes de redirection s’accumulent typiquement après plusieurs changements de structure de permaliens sans nettoyage des anciennes règles.

Bloquée par robots.txt et marquée noindex : les pièges spécifiques à WordPress

Un blocage robots.txt peut être volontaire (zone d’administration, fichiers techniques) ou accidentel : un thème ou un plugin qui réécrit le fichier lors d’une mise à jour, un site migré de préproduction en production sans retirer la ligne Disallow: /. La balise noindex, elle, se pose plus silencieusement encore sur WordPress : la plupart des extensions SEO (Yoast, RankMath, SEOPress) l’appliquent automatiquement à certains types de contenu, notamment les pages d’archive auteur sur un site à rédacteur unique, pour éviter une duplication avec la page d’accueil ou les catégories. Ce n’est pas une anomalie, c’est un réglage par défaut voulu : vérifiez la case correspondante dans les réglages de l’extension avant de conclure à un bug.

Doublons : sans canonique, canonique différent, autre page canonique

Trois motifs de duplication cohabitent dans le rapport et se corrigent différemment. « Doublon, Google n’a pas choisi la même page canonique que l’utilisateur » signifie que vous avez posé une canonique, mais que Google lui préfère une autre URL : le contenu des deux pages est probablement trop proche pour justifier deux entrées distinctes. « Doublon sans canonique sélectionnée par l’utilisateur » signifie qu’aucune balise canonique explicite n’existe et que Google tranche seul, souvent en faveur de la version la plus liée en interne. « Autre page canonique » signale que la page est elle-même désignée comme variante d’une autre : c’est un état normal, pas une erreur à corriger, tant que le choix de canonique correspond à votre intention. Sur WordPress, ce trio apparaît fréquemment entre une fiche produit et ses variantes d’attributs, ou entre un article et sa version imprimable générée par certains plugins.

Détectée non indexée, explorée non indexée : deux diagnostics différents

Ces deux motifs se ressemblent dans leur intitulé et se traitent pourtant à l’opposé l’un de l’autre. « Détectée, actuellement non indexée » signifie que Google connaît l’existence de l’URL mais ne l’a pas encore explorée : c’est un problème de priorité de crawl, souvent lié à un budget de crawl consommé ailleurs sur le site ou à un maillage interne trop faible vers cette page. « Explorée, actuellement non indexée » signifie que Googlebot est passé, a lu la page, et a choisi de ne pas l’ajouter à l’index : c’est un problème de qualité perçue, pas d’accès. Face au premier cas, la réponse est structurelle (maillage, sitemap, budget de crawl). Face au second, la réponse est éditoriale (contenu insuffisant, trop proche d’une page existante, valeur ajoutée pas assez nette). Traiter une page « explorée non indexée » en la liant davantage sans retoucher son contenu ne résout généralement rien : Google l’a déjà lue et a tranché sur la qualité, pas sur l’accessibilité.

Le piège des 90 jours : ce qu’aucun guide ne dit sur la durée de vie d’un problème

Cette règle ne figure dans aucun des guides généralistes consultés pour cet article, y compris ceux qui détaillent pourtant longuement la taxonomie des erreurs. Elle a pourtant une conséquence concrète sur un site WordPress : un incident corrigé en quelques heures peut, si l’anomalie qui l’a causée se reproduit une seule fois dans les trois mois suivants, réapparaître dans le rapport avec une durée de vie qui remonte à la toute première occurrence, parfois plusieurs mois plus tôt.

Le déclencheur le plus courant sur WordPress est un changement d’extension SEO ou un mode maintenance mal désactivé. Migrer de Yoast vers RankMath ou SEOPress, par exemple, peut faire passer certaines pages en noindex pendant la fenêtre de transition si les réglages par défaut de la nouvelle extension ne correspondent pas exactement à ceux de l’ancienne. Un plugin de mode maintenance oublié actif après une intervention nocturne pose, le temps qu’il reste en ligne, un noindex global sur tout le site. Dans les deux cas, l’incident peut être réglé en une heure et pourtant, si Googlebot est passé pendant cette fenêtre, il aura enregistré une instance du problème. Si une instance similaire réapparaît dans les 90 jours (un nouveau test de la même extension, un second oubli de maintenance), le rapport affichera un problème « vieux » de plusieurs mois, alors que le temps réel d’exposition cumulé se compte en heures.

La conséquence pratique : ne jugez jamais la gravité d’un motif à sa durée affichée dans le rapport. Un problème « ouvert depuis 4 mois » peut correspondre à deux incidents de deux heures espacés de 80 jours, pas à une anomalie continue. Avant de mobiliser du temps d’audit sur un motif ancien, vérifiez le graphique temporel de la page de détail : un pic isolé suivi d’un plat, puis un second pic isolé, raconte une histoire très différente d’une ligne continue.

Utiliser « Valider la correction » sans perdre de temps

Le bouton « Valider la correction » ne relance pas une exploration immédiate : il enclenche un cycle de vérification progressif que Google documente lui-même comme prenant « généralement deux semaines environ, mais parfois beaucoup plus ». Cliquer une seconde fois pendant qu’un cycle est en cours ne l’accélère pas, cela relance simplement un nouveau cycle sur les mêmes URL en attente.

Le déroulé réel du cycle

Search Console vérifie d’abord immédiatement un échantillon de pages. Si le problème y est toujours présent, la validation échoue sans attendre deux semaines. Sinon, l’état passe à « Démarré » et Google analyse progressivement la liste complète des URL connues concernées, pas l’ensemble du site. Chaque URL bascule en « Conforme » si le problème a disparu, en « Échec » s’il persiste (ce qui arrête tout le cycle), ou en « Autre » si l’URL est devenue inaccessible entre-temps.

Accélérer via le filtre sitemap

Une demande de validation portant sur un sous-ensemble d’URL se traite plus rapidement qu’une demande portant sur l’intégralité du site. Concrètement : créez un sitemap ne contenant que les pages stratégiques concernées, filtrez le rapport par ce sitemap avant de cliquer sur « Valider la correction ». Sur un site WordPress avec plusieurs milliers d’URL, cette étape fait souvent la différence entre un cycle de deux semaines et un cycle qui traîne bien au-delà.

1. Isoler le motif exactOuvrez la ligne du tableau concerné, pas seulement le nombre global de pages non indexées.
2. Vérifier la colonne SourceUne ligne « Google » ne se corrige pas de la même façon qu’une ligne « Site Web ».
3. Corriger toutes les occurrences avant de cliquerUne seule instance manquée fait échouer la validation dès le premier échantillon vérifié.
4. Filtrer par sitemap si le volume est importantPriorisez les pages qui comptent réellement pour le trafic ou le business.
5. Cliquer une seule fois sur « Valider la correction »Un second clic pendant le cycle en cours ne l’accélère pas, il en relance un autre.
6. Patienter sans re-tester en boucleL’outil d’inspection d’URL permet un test ponctuel, il ne remplace pas le cycle de validation global.

Que faire quand le rapport ne colle pas à la réalité du site

Une baisse sans erreur correspondante dans le tableau

Si le nombre de pages indexées chute sans qu’aucune ligne d’erreur n’explique la baisse, la cause la plus fréquente est un blocage large et volontaire ailleurs : une règle robots.txt élargie par erreur, une case noindex cochée globalement dans les réglages de l’extension SEO, ou une authentification laissée active après une phase de test. Ces cas ne remontent pas toujours comme une « erreur » individuelle dans le rapport, ils apparaissent en creux, par la baisse du total indexé.

Plus de pages non indexées que de pages indexées

Sur un site WordPress qui utilise des filtres, des variantes de produits ou une pagination générant beaucoup de paramètres d’URL, il est normal que le nombre de pages non indexées dépasse le nombre de pages indexées : ce sont en grande partie des doublons que Google exclut volontairement, pas des erreurs à corriger une par une. L’objectif n’est pas d’atteindre 100 % de pages indexées, c’est un repère à abandonner dès le départ : l’objectif est que les URL canoniques, celles qui comptent réellement, soient bien dans l’index, et que les doublons en restent exclus.

Pour aller plus loin sur la configuration initiale, notre guide complet Search Console pour WordPress couvre la mise en place de la propriété et son paramétrage. Si l’outil n’est pas encore installé sur votre site, la procédure détaillée se trouve dans notre article sur l’installation de Search Console sur WordPress. Et si les motifs liés à l’indexation du sitemap reviennent souvent dans votre rapport, notre guide sur la soumission du sitemap WordPress à Google détaille les pièges de cache qui faussent parfois cette étape.

Quand le rapport reste difficile à interpréter malgré ces repères, ou que plusieurs motifs se cumulent sans qu’un ordre de priorité soit évident, un audit SEO WordPress croise ces données avec le crawl réel du site et le maillage interne pour établir un diagnostic complet plutôt qu’un traitement motif par motif.

En résumé

Le rapport d’indexation ne demande pas d’atteindre un score parfait, il demande de savoir lire ses colonnes : le motif exact, la source du problème, et la temporalité réelle derrière chaque ligne. Un site WordPress bien tenu affichera toujours quelques doublons volontaires et quelques pages en attente de crawl, sans que cela signale un problème. Ce qui mérite votre attention, c’est l’écart entre ce que le rapport affiche et ce que vous savez être vrai sur votre site : c’est cet écart, pas le nombre brut de lignes rouges, qui indique où creuser en priorité.