Voici l’article corrigé :
Une refonte change les URL, les menus, parfois le CMS entier. Le jour où Search Console affiche « page en double, Google n’a pas retenu la même URL canonique que l’utilisateur », la réaction immédiate consiste à ouvrir le code source et à corriger la balise fautive. Sauf que le problème est rarement là. Une canonical contradictoire raconte autre chose : le site envoie plusieurs versions de la même histoire à Google, et l’algorithme choisit celle qui lui paraît la plus crédible. Comprendre ce mécanisme évite des heures perdues.
Pourquoi Google se moque d’une balise pourtant bien écrite
La balise canonical est un indice et non une directive. C’est écrit noir sur blanc dans la documentation officielle, et pourtant on continue de la traiter comme un ordre impératif. Concrètement, Google peut parfaitement ignorer une canonical déclarée, même propre, même absolue, même pointant vers une page qui répond en 200.
Le message Search Console « page en double, Google n’a pas retenu la même URL canonique que l’utilisateur » n’est pas un avertissement technique, c’est un désaveu : l’algorithme a lu votre signal, l’a pesé, et a conclu qu’un autre signal était plus fort. Pour comprendre ce mécanisme d’arbitrage, mobitex.fr détaille les signaux que Google croise avant de trancher.
Le vrai sujet, c’est la hiérarchie des preuves. Une canonical posée dans le d’une page arrive après une dizaine d’autres informations que le robot a déjà collectées : les liens internes qui pointent vers cette page, le sitemap XML, l’en-tête HTTP, les redirections rencontrées en chemin. Si ces éléments racontent une histoire différente de la balise, Google arbitre. Il ne se trompe pas. Il constate une incohérence et prend la décision la plus probable.
Après une refonte, cette incohérence devient la norme plutôt que l’exception. Les anciennes URL sont encore présentes quelque part, le sitemap a été régénéré, mais les liens internes du menu pointent parfois vers l’ancienne structure. Résultat : trois sources, trois réponses différentes, et une canonical qui crie dans le vide, sans que personne ne s’en aperçoive pendant des semaines.
Les signaux qui pèsent plus lourd que la balise
Un robot explore une page avec un contexte. Il sait d’où il vient, il sait par quel lien il est arrivé, il sait si l’URL finale résulte d’une redirection. Ce contexte forme un faisceau d’indices qui pèse bien davantage qu’une ligne de code isolée. Quand l’en-tête HTTP dit une chose, que le sitemap en dit une autre et que la balise HTML en dit une troisième, la balise HTML perd presque toujours. L’arbitrage est impitoyable.
Prenons un cas classique de refonte mal digérée. Le nouveau site sert la fiche produit à l’adresse /produit/chaussure-rando. L’ancienne adresse /boutique/chaussure-rando.html redirige vers la nouvelle. Jusque-là, tout va bien. Mais le menu principal, lui, a été recollé à la va-vite et pointe encore vers l’ancienne URL, qui redirige.
Et la balise canonical de la nouvelle page désigne parfois encore l’ancienne adresse, restée dans le template. Google voit une page qui déclare canonique une URL qui redirige vers elle-même. Le signal est absurde. Il l’ignore.
Les liens internes pèsent particulièrement lourd dans cette balance. Si l’ensemble du site pointe massivement vers une URL, que le maillage éditorial la renforce, que le sitemap la déclare, et que la canonical en désigne une autre, le doute s’installe. Google n’a aucune raison de croire une balise isolée contre vingt liens convergents. C’est mécanique.
Il y a aussi la question des URL relatives. Écrire /categorie/produit/ au lieu de l’adresse complète semble anodin, et c’est pourtant une erreur fréquente. Un robot peut interpréter une URL relative différemment selon le contexte dans lequel il la rencontre, qu’il s’agisse d’un sous-domaine, d’un CDN ou d’un passage du HTTP au HTTPS. La même chaîne de caractères ne produit pas la même destination. Google doit alors deviner, et quand il devine, il devine souvent mal. Sur ce point, voir aussi notre article sur comment booster la vitesse de votre site web ?.
Ce qu’une refonte casse sans qu’on s’en aperçoive
Les erreurs relevées après une migration se ressemblent toutes. Elles ne sont jamais isolées, elles forment un système cohérent. Voici celles qui reviennent le plus souvent, et ce qu’elles signalent vraiment sur l’état du site.
- La canonical pointe vers un mauvais protocole ou un ancien domaine, souvent parce que le template a été dupliqué d’un environnement de préproduction.
- Certaines pages n’ont aucune canonical du tout. En e-commerce, c’est fréquent : un même produit reste accessible via plusieurs URL (couleur, taille, filtre), et personne n’a tranché laquelle devait gagner.
- Vous avez vérifié la balise HTML, mais pas l’en-tête HTTP ? Une canonical envoyée dans les headers peut contredire celle du , et Google lira les deux.
- Le sitemap déclare-t-il encore des URL qui redirigent ? C’est un signal d’incohérence de plus, et il arrive très haut dans la pile des preuves.
Ce qui frappe, c’est que chacune de ces erreurs est indétectable à l’œil nu sur la page. Il faut ouvrir les outils de développeur, vérifier les en-têtes, comparer le sitemap, tracer les redirections. Un audit sérieux prend une demi-journée. Une correction au hasard prend un mois et ne règle rien du tout.
La règle qui tient en une phrase
Une page, une URL canonique, le même signal partout. Cette formule résume tout, et c’est probablement la seule chose à retenir de cet article. Elle implique que la canonical n’est jamais le point de départ d’un diagnostic, mais le point d’arrivée. On ne corrige pas une balise, on aligne un système.
Le test est simple à formuler, moins simple à mener. Pour chaque URL importante du site, il faut lister tout ce qui la désigne : les liens internes qui pointent vers elle, l’entrée du sitemap, l’en-tête HTTP, la balise canonical du , les éventuelles redirections en amont. Si les cinq réponses ne sont pas identiques, au caractère près, il y a une incohérence à traiter. Pas une balise à changer.
L’ordre des corrections compte énormément. On commence par les redirections : une canonical doit pointer vers une URL qui répond en 200, pas vers une adresse qui redirige. Googlebot refuse de suivre des chaînes d’instructions complexes vers une URL en 404, et il a raison de le faire. Ensuite, on aligne les liens internes : tout ce qui pointe vers une ancienne adresse passe en dur vers la nouvelle. Puis vient le sitemap. Enfin, et seulement enfin, la balise.
Dans les cas les plus tordus, la bonne décision consiste à abandonner une URL plutôt qu’à la défendre. Une page produit accessible via cinq paramètres différents n’a pas besoin de cinq canonicals bien réglées : elle a besoin d’une seule adresse propre, les autres redirigeant vers elle. C’est plus brutal, mais ça fonctionne.
Arrêter de bricoler une balise, aligner tout le reste
Chercher la canonical parfaite après une refonte revient à repeindre une porte pendant que les murs bougent. Ce que Google sanctionne, ce n’est pas une balise mal orthographiée, c’est un site qui ne sait plus quelle adresse il défend. La correction réelle prend plus de temps, elle traverse les redirections, le maillage, le sitemap, les en-têtes. Mais elle règle le problème au lieu de le déplacer.
Avant de toucher au code de la page, une question simple s’impose : combien de signaux internes désignent réellement l’adresse que vous voulez voir gagner ? La réponse oriente tout le reste du chantier technique à mener.