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

Chaque audit que nous effectuons 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 n’ont pas répondu à 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.

Les redirections et les canoniques entraînent plus d’échecs que le noindex

L’écart entre les premières lignes 2 est la découverte. La vérification d’indexabilité échoue une page pour l’une des 4 raisons : bloquée par robots.txt, portant une directive noindex, redirigeant vers un autre URL, ou déclarant un canonique pointant ailleurs. La vérification spécifique au noindex a échoué sur 7 sites — ce qui signifie que sur la plupart des 21 sites échoués, les pages non indexables ne portent aucun noindex du tout. 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 migrent vers un nouveau schéma de chemin, ou un tag canonique modélisé vers une variante URL que aucune page ne sert réellement. La vérification fait attention à ce qui compte. Elle excuse la redirection qui est une infrastructure correcte — un domaine nu passant à sa variante www — et elle ignore les chemins utilitaires comme /login et /signup qui devraient porter noindex. Les échecs 21 sont ce qui reste après que les cas bénins ont été 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 « Discourager les moteurs de recherche d’indexer ce site » de WordPress est l’exemple canonique — réglage 1, noindex à l’échelle du 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 signal de retrait à 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 la plus forte. 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 Google interdit d’être récupéré. 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. Notre moteur résout chaque cible canonique et échoue l'audit lorsque la cible est noindexed, redirige ou refuse de se déclarer canonique. La même contradiction apparaît sous forme de 1-page lorsqu'une page porte à la fois noindex et une canonique vers un autre endroit — 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é. Lister un URL que robots.txt bloque ou une directive noindex fait argumenter le site contre lui‑même, et l’argument coûte le budget d’exploration à chaque cycle. Nous avons mesuré ce modèle de façon indépendante dans notre rapport d’hygiène de sitemap [/articles/xml-sitemap-hygiene-audit-data].

Résoudre les conflits dans cet ordre : intention, puis mécanisme 1, 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 la direction 1.

Contenu classable, variantes dupliquées, pages utilitaires privées et espaces de paramètres infinis obtiennent chacun l’intention 1 — avant que quiconque touche un fichier de configuration. 1. Décider l’intention par classe de page. 2. Exprimer chaque intention via exactement le mécanisme 1.

• Classement : listé dans le sitemap, canonical pointant vers 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 canoniques sont un indice — la documentation propre à Google indique qu’il 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.
• Enregistrer le budget de crawl: 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é.

1 Par plateforme, l'intention noindex est d'une ligne : robots: { index: false } dans l'exportation de métadonnées d'une route Next.js, le bascule « Visibilité des moteurs de recherche » dans WordPress — vérifié 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. Le navigateur ne prouve rien ici; récupérez comme le font les crawlers: 3. Vérifiez en tant que bot, par classe de page.

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"

1 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 secondaire autoritaire, incluant quel canonique Google a réellement été choisi. Notre audit exécute la boucle complète sur chaque rapport — robots.txt contre adhésion au sitemap, directives contre canoniques, cibles canoniques résolues et vérifiées — et le rapport gratuit liste chaque paire conflictuelle avec la page où elle a été trouvée. Le taux d'échec 42.9% place les conflits d'indexabilité parmi les constatations sérieuses les plus courantes dans nos données, dans la même catégorie que les lacunes d'en-tête des meilleures vérifications échouées — avec une conséquence plus sévère, car une page bloquée ne rapporte rien quel que soit son bon état. Les sites qui passent sont ceux où l'intention d'indexation a été décidée une fois, écrite dans le mécanisme 1 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.