Votre canonical pointe vers une URL en noindex : le signal ignoré

Une balise canonical qui envoie vers une page bloquée en noindex, c’est le genre de détail qu’on découvre trois mois trop tard, quand les positions ont déjà glissé. Le pire, c’est que rien ne casse : le site s’affiche, les visiteurs arrivent, et Google reçoit un message contradictoire qu’il tranche dans son coin. Résultat, ce n’est pas la version que vous voulez voir ranker qui remonte, et vous produisez du contenu pour une page que le moteur a déjà écartée.

Le canonical n’est pas un ordre, c’est une suggestion

Première chose à intégrer, et c’est là que la plupart des guides passent à côté : la balise canonical est décrite comme un signal, pas comme une directive. Une redirection 301 impose le déplacement, le moteur n’a pas le choix. Pour le canonical, c’est différent.

Vous dites à Googlebot « à mon avis, la vraie page c’est celle-là », et il garde toute latitude pour vous contredire. Ce n’est pas un détail sémantique. C’est ce qui explique pourquoi un canonical mal posé reste sans effet pendant des mois. Pour creuser les signaux que le moteur accepte réellement de suivre, werankbox.fr détaille pas mal de cas tordus du même genre.

Quand les deux instructions se contredisent, Googlebot refuse de suivre des chaînes complexes, il ne va pas arbitrer entre votre canonical et votre noindex comme un humain le ferait. Alors il tranche seul, souvent en faveur de ce qui l’arrange. Il continue d’indexer la page qu’il avait déjà retenue, ou il abandonne les deux. Dans les deux cas, votre intention de départ est perdue, et vous ne le saurez probablement jamais.

Noindex : le coupe-circuit qu’on pose sans réfléchir

Qu’est-ce que la balise noindex, au fond ? Une instruction placée dans le code de la page qui demande au robot de ne pas l’inscrire dans l’index. Elle se glisse dans une balise meta ou dans un en-tête HTTP, et elle est binaire : la page est indexable, ou elle ne l’est pas. Celle-ci est plutôt bien respectée dans les cas simples.

Pourquoi inclure un noindex sur certaines pages ? Les raisons ne manquent pas, et elles sont souvent bonnes. Une page de remerciement après commande, un espace membre, une recherche interne, une page de test oubliée en production : tout ça n’a rien à faire dans les résultats.

Sans blocage, ces pages gaspillent du budget de crawl et diluent la popularité de vos vraies pages. Le problème ne vient donc presque jamais du noindex lui-même. Il vient de ce qu’on laisse traîner à côté, sans jamais y revenir.

Les situations où le conflit s’installe

Le scénario classique du site qu’on refait en plusieurs étapes. Une équipe met une page en noindex pour la sortir temporairement, quelqu’un d’autre pose un canonical vers cette même page depuis une variante, et les deux réglages restent en place après la mise en ligne. Personne ne les relit parce que le site fonctionne.

• Une page déclinée en deux versions linguistiques dont une seule porte le noindex, avec un canonical croisé vers la mauvaise.
• Le canonical en chemin relatif, mal résolu, que le crawler finit par ignorer purement et simplement.
• Faut-il s’inquiéter quand Search Console affiche « page crawlée, non indexée » sur une URL qu’on croyait en règle ?
• Un paramètre d’URL ajouté par un outil d’analytics ou de partage, qui génère une variante indexable à côté de l’originale.
• Le noindex hérité d’un template appliqué à tout un dossier, y compris à la page qu’on voulait justement mettre en avant.

Selon NOIISE, écrire un chemin relatif au lieu d’une URL absolue dans l’attribut href peut conduire le crawler à ignorer la balise quand le chemin se résout mal. Le robot calcule la cible depuis l’adresse de la page courante, et si le résultat ne tombe sur rien de propre, il laisse tomber. Une URL absolue ne laisse aucune place à l’interprétation.

Reste la règle de base qu’on oublie tout le temps : un canonical doit pointer vers une URL qui renvoie un code d’état HTTP 200. Pas une redirection. Pas une erreur. Pas une page noindex. Une cible qui répond correctement, rien d’autre. Quand vous envoyez le signal vers une page que vous avez vous-même fermée, vous demandez au moteur de consolider votre travail sur une adresse qu’il a déjà retirée de ses listes.

Ce que Search Console vous montre avant la chute

Le premier indicateur à surveiller porte un nom peu engageant : pages crawlées mais non indexées. Un volume qui grimpe doucement sur des URL que vous croyez indexables, c’est souvent le signe que Googlebot passe, lit le canonical, tombe sur un noindex, et repart sans rien garder. Le budget de crawl part dans le vide sur des adresses que vous ne voulez même pas voir dans les résultats. Sur ce point, voir aussi notre article sur ajax robots txt google.

Deuxième signal, plus visible : les fluctuations brutales des positions. Une page qui bouge de plusieurs crans d’un jour à l’autre, puis revient, puis repart, sans qu’aucune modification n’ait été faite. C’est la signature de la cannibalisation.

Deux pages se disputent le même mot-clé, et comme le canonical envoie vers une adresse bloquée, aucune des deux ne reçoit le signal nécessaire pour prendre l’avantage. Ni l’une ni l’autre n’atteint la première page, et le trafic se répartit entre deux adresses au lieu de se concentrer sur une seule.

Troisième chose à regarder : l’onglet de l’inspection d’URL. Collez votre adresse, ouvrez la section sur l’indexation, lisez la ligne qui parle du canonical déclaré par l’utilisateur et celle qui parle du canonical choisi par Google.

Quand les deux ne correspondent pas, vous avez la réponse en clair, sans avoir à interpréter quoi que ce soit. C’est le contrôle le plus rapide à faire, et celui que presque personne ne pense à lancer avant de chercher ailleurs.

Le canonical travaille sur trois tableaux en même temps. Le budget de crawl, parce qu’il indique au robot quelles adresses visitent un intérêt. La consolidation de la popularité, puisque les backlinks et les données d’engagement doivent se retrouver concentrés sur une seule URL pour peser. Le troisième tableau, je le laisse volontairement de côté ici : il touche à la façon dont le moteur reconstruit les regroupements de pages entre elles, et ça mérite un article à part.

Réparer, puis surveiller

Que faire si mon URL ne fonctionne pas, justement ? La marche à suivre tient en quelques gestes, à condition de sortir du code et d’aller vérifier en ligne. Chaque étape est simple, c’est l’enchaînement qui prend du temps.

• Récupérez l’adresse exacte vers laquelle le canonical pointe et testez-la dans un outil d’inspection d’URL.
• Ouvrez le code source de cette cible et cherchez la balise robots : si elle contient noindex, vous avez trouvé le conflit.
• Le canonical en chemin relatif, c’est un piège fréquent : réécrivez-le en URL absolue avant toute autre correction.
• Et si mon URL est invalide, à quel moment dois-je m’en alarmer ? Quand elle renvoie autre chose qu’un code 200.

Corrigez d’abord la cible. Si la page visée doit rester accessible, retirez son noindex, publiez et faites recrawler. Si elle doit rester fermée, changez le canonical pour qu’il pointe vers une adresse en 200. Dans le second cas, la page qui envoie le signal n’a pas besoin d’être modifiée, c’est sa destination qui change. Une fois la correction en ligne, demandez une nouvelle exploration et laissez passer quelques passages de robot avant de juger.

Le contrôle qui coûte le moins cher, c’est de vérifier en une fois toutes les balises canonical de votre site. Une extraction, un tri, et vous voyez immédiatement quelles cibles sont identiques d’une page à l’autre, ce qui est presque toujours le signe d’un template mal configuré. Ça se fait en une heure sur un site de taille moyenne, et ça évite de découvrir le problème six mois plus tard en regardant les courbes baisser.

Le silence est le vrai problème

Ce qui rend cette erreur pénible, ce n’est pas sa complexité, c’est son absence de bruit. Aucun message d’erreur, aucune alerte dans la console, aucun visiteur mécontent. Le site tourne, le contenu se publie, les positions s’effritent lentement et personne ne relie les deux.

Une inspection d’URL, une recherche de noindex sur la cible, deux minutes. La prochaine fois que vous poserez une balise canonical sur une page, irez-vous vraiment vérifier ce qu’il y a de l’autre côté du lien ?