Vous avez soumis un sitemap propre, vérifié les dernières URL une par une, et pourtant la Search Console affiche des pages « Explorée, actuellement non indexée » qui ne bougent plus depuis des semaines. Le réflexe consiste à croire à un caprice de l’algorithme ou à une pénalité. Dans la majorité des cas, le problème se trouve ailleurs : une règle technique oubliée quelque part sur le serveur, qui empêche Googlebot de lire la page, ou qui lui souffle qu’elle ne mérite pas sa place dans l’index.
Un sitemap à jour ne déclenche aucun crawl
Le sitemap ressemble à un plan de ville affiché à l’entrée : il indique où sont les rues, il ne force personne à les parcourir. Google le lit comme une suggestion, pas comme un ordre. Une URL déclarée dans un fichier XML peut rester des mois sans être visitée si le budget de crawl du domaine est saturé, si la page est jugée de faible intérêt, ou si le moteur a déjà une raison de l’écarter. Le fichier joue un rôle de découverte, jamais de priorisation.
Pour comprendre ce qui se joue vraiment, il faut se pencher sur les mécanismes de crawling que détaille mystpi.com. On y trouve l’idée centrale : un robot ne visite une page que s’il a une raison de le faire, et cette raison se construit par les liens internes, la fraîcheur du contenu et l’absence d’obstacles sur son chemin. Un sitemap sans maillage cohérent reste une liste morte.
Les chiffres donnent la mesure du phénomène. Selon IndexCheckr en 2024, sur 16 millions de pages analysées présentes sur des domaines connus de Google, près de 62 % ne sont jamais servies dans les résultats de recherche. Autrement dit, l’immense majorité des pages d’un site ne voit jamais la lumière des SERP, et ce n’est pas toujours un choix. Beaucoup sont simplement écartées, silencieusement, sans notification.
Lire le rapport d’indexation comme un diagnostic
La Search Console n’est pas qu’un tableau de bord de positions. Son rapport « Indexation des pages » sépare les URL présentes dans l’index de celles qui en sont exclues, et chaque statut d’exclusion raconte une histoire différente. Encore faut-il savoir la lire, parce que le nom du statut ne dit pas toujours la cause réelle du problème.
Ce que chaque mention signifie concrètement
Un statut n’est pas un verdict, c’est un indice. Il faut le recouper avec le type de page, son rôle dans l’arborescence et l’historique des modifications du site. C’est ce croisement qui fait apparaître la cause, souvent logée dans un fichier que personne n’a ouvert depuis la dernière migration.
- « Détectée, actuellement non indexée » veut dire que Google connaît l’adresse mais a repoussé son exploration, souvent par manque de budget de crawl.
- « Explorée, actuellement non indexée » : la page a bien été visitée, mais son contenu a été jugé trop proche d’une autre ou trop pauvre pour mériter sa propre entrée.
- Une canonique qui pointe vers la mauvaise adresse, ça vous parle ? C’est le cas classique de toutes les pages services renvoyées vers la home via rel= »canonical », et Google ne retient alors que la page d’accueil.
- « Soft 404 » signale une page qui répond correctement mais dont le contenu ressemble à une erreur.
- « Exclue par la balise noindex » ferme la porte volontairement, ce qui est parfois voulu et parfois hérité d’un ancien réglage.
Le statut « Détectée, actuellement non indexée » mérite une attention particulière, car il ne signale aucune faute technique. Google sait que l’URL existe, il a simplement décidé de ne pas s’y rendre pour l’instant. Sur un site jeune ou pauvre en liens entrants, ce report peut durer des mois et donner l’impression d’un blocage alors que le moteur attend juste son heure.
Le blocage invisible qui échappe à tout le monde
Tout le monde pense d’abord au robots.txt. C’est le réflexe logique : le fichier est public, lisible en tapant l’adresse du site suivi de /robots.txt, et il porte bien son nom. Une ligne Disallow: / oubliée après une migration suffit à faire cesser le crawl du site entier, et le diagnostic saute aux yeux dès qu’on ouvre le fichier. Sauf que le blocage le plus courant ne se trouve pas là.
Sur un site WordPress, deux fichiers peuvent bloquer un robot. Le robots.txt bloque de façon « polie », visible et documentée. Le .htaccess, lui, agit au niveau du serveur, avant même que la requête n’atteigne l’application, et son effet est tout autre.
Dans un cas rapporté par 3 Goats, une règle de filtrage par user-agent dans le .htaccess rejetait carrément Googlebot. Le moteur recevait un refus serveur, pas une page, et aucune alerte ne remontait dans la Search Console. Sur ce point, voir aussi notre article sur mesurer poids images.
Ce fichier caché à la racine du serveur est modifié lors des migrations, des changements d’hébergeur ou des mises à jour de plugins de sécurité. Il est rare qu’on le relise après coup, parce qu’il est technique, peu lisible pour un non-initié et qu’il fonctionne silencieusement. Pourtant, une règle deny mal placée, une restriction d’IP ou un blocage par user-agent suffisent à couper une partie du site du regard du moteur, sans que rien ne le signale explicitement dans les rapports.
Comment indiquer au moteur de ne pas référencer une page
La question inverse revient souvent, et la réponse tient au même mécanisme. Pour ne pas indexer un site ou une page, on dispose de la balise noindex, placée dans l’en-tête HTML, qui dit explicitement au robot de ne pas conserver l’adresse dans son index. On peut aussi passer par le fichier robots.txt avec un Disallow, ou envoyer un en-tête HTTP X-Robots-Tag, utile surtout pour les fichiers non HTML comme les PDF.
Le piège, c’est de mélanger les outils. Une page bloquée dans le robots.txt ne sera jamais explorée, donc son noindex ne sera jamais lu non plus : si vous voulez retirer une URL de l’index, laissez le robot y accéder et laissez la balise faire son travail. C’est une distinction que beaucoup de développeurs confondent, et qui explique certaines pages fantômes qui stagnent des mois avant de disparaître vraiment des résultats.
La logique vaut aussi pour Googlebot lui-même. Comprendre qui il est aide à comprendre ce qu’il voit : un robot qui explore le web en suivant des liens, qui respecte certaines conventions, et qui abandonne vite face à un obstacle répété. Si le serveur lui renvoie une erreur à chaque tentative, il finira par moins revenir, et les nouvelles URL mettront encore plus longtemps à être traitées.
Ce qu’un audit technique doit regarder en premier
Avant de refaire son maillage ou de réécrire ses contenus, un coup d’œil au .htaccess et à la canonique règle la majorité des cas. Ces deux vérifications prennent moins de temps qu’une refonte éditoriale et expliquent une part considérable des pages écartées. Le reste, budget de crawl insuffisant ou contenu trop pauvre, se traite ensuite, avec des liens internes et des pages qui apportent réellement quelque chose.
La Search Console reste l’outil de départ, à condition de la lire comme un diagnostic et non comme un bulletin de notes. Un statut d’exclusion est une piste, pas une fatalité, et chaque catégorie renvoie à une cause précise qu’il faut aller chercher sur le serveur ou dans le code. Il faut accepter de passer du temps sur des fichiers ennuyeux pour comprendre pourquoi le trafic ne décolle pas.
Le vrai coupable n’est pas toujours celui qu’on croit
Un sitemap propre rassure, il ne résout rien. Les pages disparaissent des résultats pour des raisons que la Search Console nomme, à condition qu’on prenne la peine de traduire ses statuts en actions concrètes. Le réflexe des débuts consiste à vouloir tout réécrire, alors qu’une ligne dans le .htaccess ou une canonique mal réglée suffit souvent à débloquer la situation. La prochaine fois que vous ouvrirez le rapport d’indexation, irez-vous d’abord voir le robots.txt ou le fichier que personne ne consulte ?