Indexation Google
Contrôle d’indexation : rechercher pourquoi vos pages sont absentes de Google
Vos pages sont publiées, mais certaines ne se retrouvent pas dans Google. Gloria recoupe les informations de Search Console et le fonctionnement du site pour identifier les causes vérifiables et proposer les corrections utiles.
Votre projet, concrètement
Exemple de dossier — une prestation absente
- Page concernée
- Une prestation active, distincte des autres offres et toujours disponible.
- Accès
- Vérifier la réponse de la page et les liens qui permettent de la découvrir.
- Consignes et cohérence
- Examiner les instructions d’indexation et l’adresse canonique déclarée.
- Contenu comparable
- Vérifier si une autre page répond déjà au même besoin sans différence utile.
- Suivi
- Consigner la correction éventuelle puis observer les données disponibles, sans promettre une date d’indexation.
Le bénéfice pour votre activité
Trier les exclusions, repérer leurs causes et contrôler les corrections
Différencier page bloquée, doublon, redirection et contenu non retenu
Page bloquée, doublon, redirection ou contenu non retenu : chaque motif appelle un examen différent.
Rechercher les causes d’exclusion des pages importantes pour votre offre
Nous partons des pages importantes pour votre offre, puis recherchons les réglages ou structures qui expliquent le problème.
Contrôler les corrections sur le site et suivre leur prise en compte
Les actions sont documentées et contrôlées sur le site, puis suivies dans les données disponibles.
En pratique
Examiner les exclusions Search Console ou les pages après une refonte
Trier les exclusions normales et les pages à corriger dans Search Console
Nous trions les motifs et les pages concernées pour séparer les situations normales des problèmes à traiter.
Vérifier les URL, les redirections et l’indexation après une refonte
Adresses, réglages d’indexation et redirections sont examinés en tenant compte de la transition.
Le contrôle de l'indexation rapproche trois sources : ce que votre site publie réellement, ce que vos réglages demandent aux robots, et ce que Google déclare connaître de vos URL. L'écart se lit page par page, pas en moyenne. Cette page décrit ce que contient la prestation, comment se déroule une mission, ce que vous recevez à la fin, ce dont j'ai besoin de votre côté, et ce que je ne promets pas.
La prestation en détail
Contrôle d’indexation : inventaire des URL, diagnostic et réglages à vérifier
Ouvrez les rubriques pour consulter le périmètre, les livrables et les éléments à préparer.
Le problème : un rapport qui alerte sans dire quoi faire
La Search Console range vos URL sous des libellés courts : « Explorée, actuellement non indexée », « Détectée, actuellement non indexée », « Autre page avec balise canonique correcte », « Page en double sans URL canonique sélectionnée par l'utilisateur », « URL bloquée par le fichier robots.txt », « URL marquée "noindex" ». Ces libellés décrivent un état constaté, pas une cause, et encore moins une action.
L'aide officielle du rapport d'indexation des pages est explicite : « Ne vous attendez pas à ce que toutes les URL de votre site soient indexées », et une URL non indexée n'est pas nécessairement un problème quand l'exclusion est voulue — page dupliquée, variante de filtre, page retirée volontairement (aide Search Console, consultée le 11 septembre 2026). Le travail utile consiste à séparer le bruit normal des vrais blocages, puis à traiter ces derniers dans le bon ordre.
C'est le cas typique d'un site de TPE ou de PME qui a vécu : une refonte, un changement d'extension SEO, une préproduction restée en ligne, un sitemap qui liste des URL redirigées. Chaque épisode laisse une trace dans l'index. En amont d'une mission, j'ai détaillé les statuts et leurs causes dans page non indexée par Google : comprendre le statut, et la mécanique de découverte des URL dans comment Google découvre, indexe et actualise les pages.
Ce que contient le contrôle de l'indexation
Comparer les pages que vous publiez et celles que Google connaît
L'analyse part d'un inventaire : les contenus présents dans le CMS et les URL réellement accessibles. Cet inventaire est rapproché du sitemap, du maillage interne et des rapports disponibles dans la Search Console. Le périmètre distingue les pages à vocation commerciale, les ressources, les archives et les variantes d'URL : paramètres, pagination, filtres, versions imprimables.
L'utilité d'un contenu se juge avec votre activité et vos engagements, pas uniquement avec son trafic des trois derniers mois. Une page peut servir un client existant ou répondre à une question précise sans générer de clics depuis Google.
Vérifier l’accès, les directives, les canoniques et le contenu des pages
- Accès : page indisponible, redirection, chaîne de redirections, obstacle à l'exploration.
- Directives : instruction de non-indexation, ou incohérence entre plusieurs réglages qui se contredisent.
- Canonique : autre URL indiquée par le site, ou autre URL retenue par Google comme version de référence.
- Découverte et traitement : URL connue, explorée, ou encore en attente de décision.
- Contenu : rôle de la page, informations réellement disponibles, proximité avec d'autres pages du site.
Chaque cause retenue est vérifiée sur des exemples concrets : code de réponse HTTP servi, en-têtes, HTML reçu, présence effective de la directive. Un libellé de rapport ne suffit jamais à conclure.
robots.txt, noindex, canonique et redirection : des effets différents
Quatre mécanismes sont régulièrement confondus. Ils ne répondent pas au même besoin, et les employer l'un pour l'autre crée précisément ce type de situation.
| Mécanisme | Ce qu'il fait | Ce qu'il ne fait pas |
|---|---|---|
| robots.txt | Organise l'accès des robots aux URL du site. | Ne retire pas une page déjà indexée ; empêche même la lecture d'un noindex. |
| Directive noindex | Demande la non-indexation d'une page accessible. | N'empêche pas l'exploration et reste sans effet si la page est bloquée. |
| Balise canonique | Indique la version de référence parmi des pages proches. | Ne bloque rien et ne s'impose pas : Google peut retenir une autre URL. |
| Redirection | Envoie la requête vers une autre adresse. | Ne remplace pas une décision éditoriale sur le sort du contenu. |
Le premier piège est documenté par Google : pour que la règle noindex soit efficace, la page ne doit pas être bloquée par le fichier robots.txt, sinon « la règle noindex n'est pas détectée par le robot d'exploration » et la page peut continuer à s'afficher dans les résultats (documentation Google, mise à jour le 31 décembre 2025). Bloquer et désindexer sont deux intentions opposées dans la mise en œuvre.
Le second piège tient aux limites du fichier : Google applique une limite de 500 kibioctets au robots.txt et ignore ce qui dépasse, met généralement son contenu en cache 24 heures, et en cas d'erreur serveur persistante s'appuie pendant 30 jours sur la dernière version récupérée (documentation Google, mise à jour le 11 septembre 2026). Une correction n'y produit donc pas un effet immédiat.
Côté sitemap, la limite est de 50 Mo non compressés ou 50 000 URL par fichier ; au-delà, il faut le scinder et déclarer un index de sitemaps (documentation Google, consultée le 11 septembre 2026). Le problème courant n'est pourtant pas le volume mais le contenu : un sitemap qui liste des URL redirigées, bloquées ou en noindex envoie des signaux contradictoires. Le sujet est traité pour WordPress dans à quoi sert le sitemap et comment le soumettre, et les versions proches dans balise canonical et contenu dupliqué.
Vérifier qu’un exemple de balise noindex ne bloque pas réellement la page
Une balise <meta name="robots" content="noindex"> copiée dans un article d'explication peut devenir une instruction réelle si elle n'est pas échappée. C'est une cause de désindexation discrète, invisible dans l'éditeur et bien visible pour Google. Le contrôle porte sur la page reçue par le navigateur, ce qui permet de distinguer le texte affiché du code interprété.
Comment se déroule une mission
- Cadrage. Vous décrivez les URL concernées et les messages observés. Nous fixons le périmètre : familles de pages, volume d'analyse, contrôles de suivi. Ces éléments figurent dans le devis.
- Relevé. Inventaire des URL, lecture des réponses servies, des directives et des rapports de la Search Console. Aucune modification à ce stade.
- Diagnostic. Chaque problème retenu est relié à ses URL, à une cause étayée et à un traitement proposé. Les statuts normaux sont identifiés comme tels, pour éviter de corriger ce qui fonctionne.
- Décision. Vous validez ce qui est appliqué. Toute modification d'URL, de lien ou de statut d'indexation est décidée explicitement, jamais par défaut.
- Mise en œuvre et contrôle. Les modifications sont réalisées selon le périmètre convenu, puis vérifiées sur la version publique du site.
- Suivi. Un test en direct confirme que Google accède à la page et qu'aucun blocage d'indexabilité n'est détecté. Une demande d'indexation place l'URL dans un processus de traitement ; elle ne prouve pas son indexation.
Ce que vous recevez
- Un inventaire des URL du périmètre, avec leur statut côté site et côté Google.
- Une liste de problèmes classés par cause, chacun rattaché à ses URL et à un traitement proposé, priorisé.
- La distinction explicite entre ce qui est une anomalie et ce qui est une exclusion normale.
- Les modifications effectuées, si la mise en œuvre entre dans le périmètre convenu.
- Les contrôles de vérification réalisés après correction, avec leur date et ce qu'ils établissent.
Le livrable est écrit pour être lisible par un dirigeant et exploitable par un développeur. Quand une correction dépasse mon périmètre, elle est décrite précisément pour que votre prestataire technique puisse l'appliquer.
Ce dont j'ai besoin de votre côté
Un accès en lecture à la propriété Search Console du site, ou son ouverture si elle n'existe pas encore. Un accès à l'administration du CMS, en lecture pour le diagnostic, avec droits d'écriture uniquement si la mise en œuvre m'est confiée. Et la liste des URL qui vous préoccupent, avec les messages exacts que vous avez vus.
Utile aussi : l'historique récent du site — refonte, migration, changement d'extension SEO, incident serveur — et les pages que vous ne voulez pas voir modifiées.
Si le site présente par ailleurs des problèmes structurels plus larges — performances, architecture, erreurs serveur récurrentes — le contrôle d'indexation les signale mais ne les traite pas : c'est le périmètre d'un audit technique SEO.
Ce que cette prestation ne promet pas
Aucune garantie d'indexation, ni de délai. Les corrections peuvent lever un obstacle identifié. La décision d'indexer une URL et le moment où elle intervient appartiennent à Google. L'outil d'inspection d'URL l'indique lui-même : « L'envoi d'une demande ne garantit pas que la page apparaîtra dans l'index Google » (aide Search Console, consultée le 11 septembre 2026).
Aucune garantie de position ni de trafic. Être indexé signifie être éligible à l'affichage, pas être bien classé. Le positionnement dépend de facteurs qui sortent de ce périmètre : contenu, concurrence sur la requête, notoriété du domaine, évolutions de l'algorithme.
Pas de suppression automatique des pages peu visitées. L'absence de clics ne suffit pas à justifier une désindexation. Le rôle du contenu, la période observée, les autres sources de visites et les engagements attachés à sa publication sont examinés avant toute décision, qui vous revient.
Pas de volume d'analyse illimité. Le périmètre est fixé au devis. Sur un très grand site, l'analyse porte sur des familles de pages représentatives plutôt que sur l'exhaustivité.
Pas d'optimisation de budget d'exploration là où elle n'a pas d'objet. Google indique que le rapport « Statistiques sur l'exploration » n'est probablement d'aucune utilité pour un site de moins de 1 000 pages (aide Search Console, consultée le 11 septembre 2026). Sur un site de TPE, les causes d'exclusion sont presque toujours des directives ou des doublons.
Repères pratiques
Distinguer les pages à indexer des anciennes URL et des doublons
Le nombre d’adresses exclues ne dit pas, à lui seul, si votre site rencontre un problème. Commencez par un inventaire des pages qui doivent réellement être trouvées : prestations actives, catégories utiles, produits disponibles ou contenus de référence. Comparez cet ensemble aux adresses techniques, anciennes ou redondantes que le site peut également produire.
Faites défiler le tableau horizontalement pour lire toutes les colonnes.
| Type d’adresse | Question à poser | Suite à envisager |
|---|---|---|
| Prestation active absente | La page est-elle accessible et suffisamment distincte ? | Examiner ses signaux et sa place dans le site |
| Variante redondante | Quelle page doit représenter cette information ? | Vérifier la cohérence des indications |
| Ancienne offre supprimée | Existe-t-il une réponse réellement équivalente ? | Choisir un traitement adapté, sans renvoi automatique à l’accueil |
L’objectif n’est pas de faire indexer chaque adresse produite par le site. Il est de comprendre pourquoi les pages utiles sont absentes et de conserver une organisation lisible pour les visiteurs comme pour les moteurs.
Repères pratiques
Exemple illustratif : trier un petit lot d’adresses après une refonte
Imaginons dix anciennes adresses signalées dans Search Console. Quatre correspondent à des pages déplacées, trois à des offres arrêtées sans équivalent et trois à des prestations toujours actives. Les traiter avec une règle unique ferait disparaître les différences entre ces situations.
Décider pour chaque URL : conserver, rediriger, supprimer ou corriger
Pour les pages déplacées, on vérifie la destination retenue et la continuité de la réponse. Pour les offres arrêtées, une vraie page d’erreur peut être cohérente : elle doit annoncer l’indisponibilité et aider le visiteur à poursuivre, tout en renvoyant le statut approprié. Pour les prestations actives, on recherche ce qui empêche ou décourage leur prise en compte.
Une page affichée correctement dans le navigateur n’est pas nécessairement indexée. Inversement, une ancienne erreur peut rester visible un temps dans un rapport après correction. Ce scénario est fictif : les nombres servent à montrer un tri. Le registre conserve la date, la décision et le contrôle réalisé, sans promettre un délai de réapparition.
Repères pratiques
Vérifier d’abord le site, puis la prise en compte des changements par Google
La première vérification porte sur le site : l’adresse répond-elle comme prévu, affiche-t-elle le contenu attendu et présente-t-elle des indications cohérentes ? La seconde porte sur la prise en compte par Google, qui dépend de ses propres traitements. Une demande d’examen ne permet pas d’imposer cette prise en compte.
Les réglages doivent être choisis selon le besoin. Bloquer l’exploration et demander de ne pas indexer ne sont pas des actions interchangeables. Avant de modifier ces règles à grande échelle, il faut identifier les familles d’adresses concernées et tester le résultat sur des exemples représentatifs. Les principes sont décrits dans la documentation Google sur la désindexation.
- Définir le groupe de pages utiles et l’état attendu pour chacune.
- Conserver les observations initiales et les dates de modification.
- Retester après publication, sans modifier simultanément des réglages sans rapport avec le problème.
- Suivre les pages prioritaires et distinguer correction confirmée, traitement encore en attente et hypothèse non résolue.
Le coût dépend du nombre de situations différentes, des accès et des corrections nécessaires. Un diagnostic sur un petit ensemble bien choisi peut précéder un traitement plus large du site.
Questions sur les pages explorées, l’indexation et les accès nécessaires
Une page explorée doit-elle forcément être indexée ?
Non. L'exploration et l'indexation sont deux étapes distinctes : Google peut télécharger une page puis décider de ne pas la retenir dans son index. Le statut « Explorée, actuellement non indexée » décrit précisément cette situation, et il ne signale pas toujours une erreur technique.
Quels accès faut-il donner pour démarrer ?
Un accès en lecture à la propriété Search Console du site et un accès à l'administration du CMS suffisent pour le diagnostic. Des droits d'écriture ne sont nécessaires que si la mise en œuvre des corrections est confiée au prestataire. Si aucune propriété Search Console n'existe, son ouverture fait partie des premières étapes.
Bloquer une page dans le robots.txt suffit-il à la désindexer ?
Non, et c'est souvent l'inverse qui se produit. Une page bloquée dans le robots.txt ne peut plus être lue par le robot, qui ne voit donc pas la directive noindex qu'elle contient éventuellement. Pour retirer une page de l'index, elle doit rester accessible et porter une instruction de non-indexation.
Faut-il supprimer les pages sans clics ?
L'absence de clics ne suffit pas à décider. Il faut examiner le rôle du contenu, la période observée, les autres sources de visites et les engagements attachés à sa publication. Une page peut servir des lecteurs ou des clients existants sans apparaître dans les statistiques de recherche.
Peut-on garantir une indexation rapide après correction ?
Non. Une correction peut lever un obstacle identifié, mais la décision d'indexer et son délai appartiennent à Google. Une demande d'indexation dans la Search Console place l'URL dans une file de traitement sans garantir le résultat, et le nombre de demandes quotidiennes est limité.
La mise en œuvre des corrections est-elle comprise dans la prestation ?
Cela dépend du périmètre convenu au devis. Le diagnostic et les préconisations sont toujours fournis ; l'application des corrections peut être confiée au prestataire ou rester chez votre équipe technique. Dans le second cas, chaque correction est décrite assez précisément pour être appliquée sans échange supplémentaire.
Indiquez les URL exclues et les messages de Search Console
Indiquez les URL concernées et les messages observés dans la Search Console : nous verrons ensemble si un contrôle d'indexation répond à votre besoin.
Décrire votre situation