Conflits d’indexabilité : Quand votre propre site dit à Google de partir

Chaque audit que nous réalisons pose une question directe sur les pages qu’un site déclare importantes — la page d’accueil plus les URLs listées dans son propre sitemap : les moteurs de recherche peuvent-elles les indexer comme déclaré? Entre mai 5 et August 15, 2026, 21 de 49 sites audités ont échoué à cette question. Cela représente 42.9% de l’échantillon qui indique aux crawlers de sauter des pages que quelqu’un a pris la peine de publier, lier et répertorier.

Les échecs partagent une signature : chacune de ces sites fonctionne parfaitement pour les humains. Les pages se rendent, les liens se résolvent, rien dans le navigateur ne suggère qu’une directive en dessous envoie les moteurs de recherche loin. Les conflits d’indexabilité sont la catégorie la plus auto‑inflictée dans nos données — aucun concurrent ne les a causés, aucune mise à jour d’algorithme ne les a déclenchés, et personne dans l’équipe ne peut les voir sans récupérer le site comme le fait un bot.

Le jeu de données

Méthodologie : instantané d'audit le plus récent par domaine à partir de notre jeu de vérifications actuel, mai 5 – August 15, 2026 — 49 sites audités, anonymisés. Les dénominateurs par vérification varient de 46 à 49 car une vérification ne s'exécute que lorsque ses entrées existent — un site sans sitemap accessible ne produit aucun verdict de page de sitemap. L'échantillon est auto-sélectionné — propriétaires ayant effectué un audit — et penche vers les petites à moyennes entreprises, donc considérez les taux comme indicatifs pour ce segment.

Redirections et canoniques entraînent plus d'échecs que noindex

L'écart entre les premières lignes 2 est la constatation. Une page ne peut pas être indexée comme déclaré pour l'une des 4 raisons suivantes : elle est bloquée par robots.txt, elle porte une directive noindex, elle redirige vers un autre URL, ou elle déclare un canonique pointant ailleurs. Seuls 7 sites avaient un problème de noindex — ce qui signifie que sur la plupart des 21 sites échoués, les pages non indexables ne portent pas du tout de noindex. Elles redirigent loin du URL que le sitemap promet, ou elles indiquent à Google que leur canonique se trouve à une adresse différente.

Cette répartition est importante car les équipes recherchent le mauvais coupable. Le mot que tout le monde connaît est noindex, donc c'est ce qui est recherché — et il revient propre. Le conflit réel est généralement structurel : un sitemap généré à partir de la base de données CMS alors que les URLs en direct ont migré vers un nouveau schéma de chemin, ou un tag canonique modélisé vers une variante URL que aucune page ne sert réellement.

Les cas bénins ne sont pas comptés : une redirection qui relève d'une infrastructure correcte, comme un domaine nu passant à sa variante www, et les pages utilitaires qui devraient porter noindex. Les 21 échecs sont ce qui reste une fois ceux-ci retirés.

Les motifs de conflit 4 dans les données

Le noindex de mise en scène qui a été expédié. Les sites 7 répertorient des pages dans leur sitemap qui portent une directive noindex — dans la balise meta robots ou l'en-tête de réponse X-Robots-Tag. C'est le classique vestige de lancement : la directive qui a correctement masqué l'environnement de mise en scène se retrouve en production dans un template, un réglage de plugin, ou un commutateur de plateforme. La case à cocher WordPress "Discourage search engines from indexing this site" est l'exemple canonique — un seul réglage, noindex sur tout le site, rien de visible différent.

robots.txt criant au-dessus de tout. Les sites 3 servent un robots.txt avec Disallow: / pour tous les bots — le signe de départ à l'échelle du site — et 5 échouent la vérification de cohérence plus large, où le blocage robots.txt ou un noindex sur la page d'accueil contredit l'intention évidente de se classer. Le piège subtil dans ce motif : robots.txt et noindex font des tâches opposées, et les combiner annule le plus fort. Une page bloquée par robots.txt ne peut pas être explorée, donc un noindex placé dessus n'est jamais lu — c'est ainsi que les URLs finissent dans l'état "Indexé, bien que bloqué par robots.txt", présent dans les résultats comme un lien vierge Google était interdit de récupérer.

Contradictions canonique. Un tag canonique pointant vers une cible qui porte elle-même noindex donne à Google 2 instructions qui ne peuvent pas toutes deux être honorées : consolider les signaux dans cette page, et exclure cette page de l'index. La cible doit donc être propre : un canonique qui aboutit sur une page en noindex, sur une redirection, ou sur une page qui désigne elle-même un autre canonique constitue une contradiction. La même contradiction apparaît au sein d'une seule page lorsqu'elle porte à la fois noindex et un canonique vers ailleurs — demandant à Google de transférer l'autorité à travers une page qu'on lui a dit d'oublier.

Le sitemap promouvant ce que les directives interdisent. Un sitemap est une revendication lisible par machine que chaque URL dans celui-ci mérite d'être indexé. Énumérer un URL que robots.txt bloque ou une directive noindexes fait que le site se dispute avec lui-même, et l’argument coûte le budget d’exploration à chaque cycle. Nous avons mesuré ce motif seul dans notre rapport d’hygiène de sitemap our sitemap hygiene report.

Résoudre les conflits dans cet ordre : intention, puis un seul mécanisme, puis preuve

Les conflits d’indexabilité persistent parce que les corrections sont appliquées signal par signal — quelqu’un corrige un noindex ici, édite robots.txt là — sans que quiconque décide à quoi sert réellement chaque classe de page. La correction durable fonctionne dans une seule direction.

1. Décider l’intention par classe de page. Contenu classable, variantes dupliquées, pages utilitaires privées et espaces de paramètres infinis obtiennent chacun une seule intention — avant que quiconque touche un fichier de configuration.

2. Exprimer chaque intention via un seul mécanisme.

• Classer : listé dans le sitemap, canonical pointant sur lui-même, sans directives robots du tout.
• Consolider les doublons : <link rel="canonical" href="https://example.com/primary/" /> sur la variante, qui reste crawlable et quitte le sitemap. Les canonicals sont un indice — la documentation propre à Google indique qu’elle peut choisir un canonical différent lorsque d’autres signaux sont contradictoires, ce qui explique exactement pourquoi la cible doit être propre : indexable, 200, auto-canonical.
• Éviter les résultats : une balise meta robots noindex dans la page, ou l’en-tête de réponse X-Robots-Tag: noindex pour les PDFs et autres réponses non-HTML. La page doit rester crawlable — une directive derrière un bloc robots.txt est une directive qui n’existe pas.
• Économiser le budget d’exploration : Disallow: /search/ sous User-agent: * dans robots.txt, réservé aux espaces avec des URLs illimitées. robots.txt contrôle le crawling, jamais l'indexation — il ne supprime rien qui est déjà indexé.

Par plateforme, l'intention noindex est une seule ligne : robots: { index: false } dans l'export de métadonnées d'une route Next.js, le basculement « Visibilité pour les moteurs de recherche » dans WordPress — coché délibérément par environnement, jamais hérité de staging — ou add_header X-Robots-Tag "noindex" always; limité à un bloc de localisation dans nginx.

3. Vérifiez en tant que bot, par classe de page. Le navigateur ne prouve rien ici ; récupérez comme le font les crawlers :

curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"
curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"

Un représentant URL par classe de page suffit, vérifié par rapport à l'intention que vous avez décidée à l'étape 1. L'inspection URL de Search Console donne l'opinion définitive, y compris quel canonique Google a réellement été choisi. Un diagnostic SEOReport payant exécute la boucle complète sur chaque rapport et répertorie chaque paire conflictuelle avec la page où elle a été trouvée.

Le taux d'échec de 42,9 % place les conflits d'indexabilité parmi les constatations sérieuses les plus fréquentes dans nos données, dans la même catégorie que les lacunes d'en-tête du ranking de nos vérifications les plus échouées — avec une conséquence plus sévère, car une page bloquée ne rapporte rien quel que soit son contenu. Les sites qui passent sont ceux où l'intention d'indexation a été décidée une fois, consignée dans un seul mécanisme par classe de page, et vérifiée comme le ferait un crawler. Tout ce qui concerne cette catégorie d'échec est sous le contrôle du propriétaire du site — c'est ce qui la rend la plus corrigible 42.9% dans le jeu de données.