Vous déclarez une URL canonique, Google en indexe une autre. Le scénario n’a rien d’exceptionnel et il rend fou quiconque passe ses après-midi dans Search Console. La balise canonique ressemble à un ordre clair, sauf que le moteur la lit comme un signal parmi d’autres, qu’il soupèsera avec le sitemap, les liens internes, les redirections et la qualité du contenu. Une balise mal posée, oubliée après une refonte ou pointée vers une adresse qui redirige, et c’est la version que vous vouliez cacher qui remonte. Encore faut-il comprendre comment Google choisit son URL avant de réécrire la ligne fatidique.
La balise canonique est un signal, pas une consigne
Une URL canonique, c’est l’adresse que Google considère comme la version principale d’un contenu. Cette définition, on la retrouve chez georgestron.fr, et elle dit déjà beaucoup : c’est Google qui décide, pas vous. Vous proposez, il arbitre, en croisant les signaux qu’il collecte sur l’ensemble du site. Le problème, c’est que tout le monde lit la documentation à l’envers et croit poser un ordre exécutable.
La logique interne du moteur est assez simple si on accepte l’idée qu’aucun signal isolé ne pèse assez lourd. Il regarde ce que votre canonical déclare, puis il vérifie si le contenu pointé tient la route : accessible, répondez, cohérent avec le reste.
Si la cible est en noindex, redirige en boucle ou n’existe plus, il jette votre déclaration et se débrouille avec le reste du contexte. Une canonical ne remplace jamais une redirection 301 ni une directive noindex, et c’est justement là que les configurations bancales se trahissent.
Le mécanisme de sélection d’URL fonctionne par élimination. Google part des adresses qu’il connaît, écarte celles qui renvoient une erreur ou un noindex, regroupe les doublons, puis retient la représentante du groupe. Votre balise pèse dans le regroupement, mais elle ne pèse pas dans l’élimination. Voilà pourquoi une page peut très bien se retrouver exclue de l’index alors que vous aviez tout déclaré comme il faut sur le papier.
Comment vérifier ce que Google a réellement indexé
Avant de toucher à quoi que ce soit, il faut savoir sur quelle URL vous êtes positionné. Tapez site: suivi du domaine dans Google, puis fouillez les résultats à la recherche de la variante gênante : celle avec un paramètre, la version http, le doublon avec un slash final. L’opérateur ne donne qu’un aperçu, il reste indicatif, mais il révèle vite les incohérences les plus visibles.
La commande info: ne sert plus à grand-chose depuis longtemps. Passez plutôt par l’inspection d’URL dans Search Console : collez l’adresse exacte, lisez le verdict. Si Google vous renvoie une autre URL comme version canonique déclarée par l’utilisateur, c’est votre balise qui parle. Si l’outil affiche « page avec redirection » ou « exclue par une balise noindex », la balise canonique n’a même pas eu voix au chapitre. Cette lecture croisée vaut mieux que n’importe quel audit automatique.
Pourquoi une page sort de l’index sans prévenir
La question « pourquoi je ne suis plus référencé » revient sans arrêt, et la réponse tient rarement à une sanction. Une page peut ne pas être indexée pour une raison parfaitement banale, et Google en documente une liste assez longue. Le statut « Explorée – Actuellement non indexée » en résume l’essentiel, et c’est probablement le message le plus mal compris de Search Console.
Il signifie une chose précise : Googlebot est passé, il a lu la page, puis il a décidé de ne pas la garder dans l’index. Ce n’est pas une erreur technique au sens strict, c’est un choix.
Le moteur juge le contenu trop proche d’une autre URL, ou trop pauvre pour mériter sa propre entrée. Une canonical pointant ailleurs produit exactement ce diagnostic, puisque votre page est déclarée comme doublon par vos propres soins. Admettre que le problème vient de chez vous change tout le raisonnement. Sur ce point, voir aussi notre article sur google ancienne version page.
La difficulté, c’est que ce statut est fourre-tout. Il peut cacher un contenu trop léger, une sélection d’URL qui a préféré une autre adresse, ou une balise canonique mal comprise. Le diagnostic ne vous dit pas laquelle des causes s’applique, il faut la reconstituer en regardant l’URL déclarée, les liens internes qui pointent vers la page et ce que le sitemap annonce. Sans cette lecture croisée, on corrige au hasard.
Les erreurs qui cassent une chaîne de canonical
Une configuration propre tient sur peu de lignes, mais il suffit d’un maillon faible pour que tout se disloque. Le plus fréquent, c’est la balise unique qui devient multiple après un copier-coller entre gabarits. Google en trouve plusieurs, il ne sait plus laquelle croire, et il tranche sans vous. Un cas classique recensé chez Adelantee, et qui passe inaperçu pendant des mois puisque la page s’affiche normalement.
D’autres situations produisent le même effet de bord, et la liste suivante reprend celles qu’on croise le plus souvent en audit. Chaque item est une erreur, pas une recommandation.
- Une adresse relative ou truffée de paramètres dans le href, qui pointe vers une variante redirigée.
- Canonical posée vers une page passée en noindex lors d’une mise à jour, alors que la balise n’a pas suivi.
- La balise pointe vers une version traduite sans que le hreflang ait été aligné, et les deux se contredisent.
- Pourquoi le sitemap déclare-t-il encore d’anciennes adresses disparues ?
- Plusieurs balises canoniques coexistent dans le head, souvent héritées d’un plugin et d’un thème qui s’ignorent.
Reconstruire une chaîne technique cohérente
La bonne pratique tient en une phrase : une seule balise, auto-référente, cohérente avec le sitemap. Chaque page déclare sa propre URL absolue, y compris celles qui n’ont aucun doublon, et le sitemap reprend exactement les mêmes adresses. C’est bête, c’est fastidieux, c’est ce qui fonctionne. Adelantee cite cette auto-référence comme un réflexe de base, et franchement, elle évite la moitié des dégâts.
Le reste est une affaire d’alignement. Si vous utilisez des redirections 301, elles doivent mener vers l’URL canonique, pas vers une intermédiaire qui redirige encore. Si vous gérez du multilingue, le hreflang et la canonical doivent désigner la même version dans chaque langue. Un conflit entre les deux signaux, et Google se rabat sur son propre jugement. La chaîne ne tient que si chaque maillon dit la même chose.
Il reste l’ordre des opérations, souvent négligé. On corrige la balise, puis on oublie de changer les liens internes et le sitemap, et le moteur continue de recevoir des messages contradictoires pendant des semaines. Renvoyez le sitemap après correction, vérifiez que le maillage interne pointe vers la bonne version, puis redemandez l’exploration des pages concernées. Un changement de canonical non propagé partout, c’est un signal fort noyé dans du bruit.
Comptez du temps, aussi. Google ne réévalue pas une page à la seconde, et un recrawl peut prendre plusieurs passages avant que la nouvelle URL s’installe. Surveillez le rapport sur les pages dans Search Console : le nombre de pages « explorées, actuellement non indexées » doit refluer si votre correction est bonne. S’il ne bouge pas, c’est que la cause est ailleurs dans la chaîne, et il faut reprendre le diagnostic depuis le début.
Récupérer la main sur l’URL indexée
Une canonical mal placée ne se contente pas de rater sa cible, elle envoie un message que Google exploite contre vous. Le moteur arbitre avec l’ensemble des signaux, et votre balise n’en est qu’un. La seule parade reste la cohérence de bout en bout : URL auto-référente partout, redirections propres, sitemap à jour, hreflang aligné.
Quand tous ces éléments racontent la même histoire, Google n’a plus de raison de choisir seul. La prochaine fois que vous verrez une drôle d’URL apparaître dans les résultats, irez-vous d’abord inspecter la balise, ou l’ensemble du dispositif qui la porte ?
0 commentaire