Canonicalisation et migration : pourquoi Google peut mettre du temps à réévaluer

Une balise rel="canonical" ne remplace pas immédiatement une URL dans les systèmes de Google. Elle exprime une préférence parmi plusieurs signaux. Google doit recrawler les pages, comparer leur contenu, reconstruire le cluster de doublons et réévaluer l’URL représentative. Une correction juste peut donc rester invisible pendant plusieurs jours.

Réponse en bref

Pour corriger un problème de canonicalisation, identifiez d’abord les URL que Google regroupe, puis rendez les signaux cohérents : contenu réellement distinct ou fusionné, redirection permanente lorsque l’ancienne URL disparaît, canonical absolu, sitemap limité aux URL souhaitées et liens internes dirigés vers la même destination. Google précise depuis le 10 juillet 2026 qu’une page peut rester dans un cluster de doublons jusqu’à deux semaines après correction. Suivez l’évolution dans Search Console au lieu de promettre un effet immédiat.

Ce que Google appelle canonicalisation

Lorsque plusieurs URL présentent un contenu identique ou très proche, Google choisit une URL représentative : la canonique. Les doublons peuvent venir de :

• paramètres de tri ou de suivi ;
• versions HTTP et HTTPS ;
• domaines avec et sans www ;
• pages mobiles séparées ;
• catégories qui exposent le même produit ;
• environnements de démonstration indexables ;
• migrations ou refontes incomplètes.

La duplication n’est pas automatiquement une infraction. Elle complique surtout le crawl, la mesure et le choix de l’URL à afficher.

Une préférence, pas une instruction absolue

Google peut prendre en compte plusieurs signaux :

• redirection permanente ;
• élément ou en-tête rel="canonical" ;
• présence dans le sitemap ;
• cohérence des liens internes ;
• protocole HTTPS ;
• contenu et utilité de la page.

Les redirections et rel="canonical" sont des signaux forts ; le sitemap est plus faible. Les signaux peuvent s’additionner, mais Google peut retenir une autre URL si elle paraît plus représentative.

Le journal CIBLE

CIBLE signifie cluster, intention, balises, liens, évaluation.

Étape	Question	Preuve
C : Cluster	quelles URL sont considérées comme proches ?	inspection, crawl, échantillons de contenu
I : Intention	faut-il conserver, différencier, fusionner ou supprimer ?	décision éditoriale URL par URL
B : Balises	les signaux techniques désignent-ils la même URL ?	redirect, canonical, robots, sitemap
L : Liens	le site pointe-t-il vers la destination souhaitée ?	maillage, navigation, hreflang
E : Évaluation	la correction est-elle retraitée dans le temps ?	Search Console et journal daté

Le journal empêche de changer plusieurs couches chaque jour et de perdre la cause de l’évolution observée.

C : Identifier le cluster réel

Dans l’outil d’inspection d’URL, comparez la canonique déclarée et la canonique sélectionnée par Google. Crawlez ensuite les variantes pour relever :

• statut final ;
• canonical HTML ou HTTP ;
• indexabilité ;
• titre et contenu principal ;
• langue ;
• présence dans le sitemap ;
• nombre de liens internes.

Ne concluez pas à partir d’une seule URL. Le problème se trouve souvent dans le groupe : trois pages déclarent trois canonicals différents, une redirection temporaire conserve l’ancienne page ou le sitemap référence encore les doublons.

I : Choisir une décision éditoriale

Quatre décisions principales existent.

Conserver les deux pages

Les pages doivent répondre à des besoins réellement différents. Renforcez la différence dans le contenu principal, le titre et le maillage. Une simple ville ou un mot remplacé ne crée pas nécessairement une nouvelle intention.

Fusionner

Regroupez les informations utiles sur une URL, redirigez les anciennes pages pertinentes et mettez à jour les liens. Évitez de rediriger des contenus sans rapport vers l’accueil : cela peut être interprété comme un soft 404.

Canonicaliser

Conservez plusieurs URL accessibles lorsque le produit en a besoin, mais déclarez une représentante cohérente. Le canonical doit être absolu, présent dans le <head> ou l’en-tête HTTP approprié et ne pas contredire les autres signaux.

Supprimer

Retournez un statut adapté lorsque le contenu n’a plus de remplaçant. Retirez l’URL des sitemaps et des liens internes.

B : Aligner les signaux techniques

Pour une URL souhaitée :

• utilisez un canonical vers elle-même lorsqu’il est pertinent ;
• placez uniquement cette version dans le sitemap ;
• redirigez les anciennes URL de façon permanente si elles disparaissent ;
• retirez les noindex temporaires de migration ;
• évitez de bloquer dans robots.txt les pages dont Google doit lire le canonical ;
• gardez hreflang cohérent avec une canonique de la même langue.

N’utilisez pas l’outil de suppression d’URL pour résoudre une canonicalisation. Il masque temporairement des résultats, sans consolider le cluster.

L : Corriger les liens internes

Les pages du site doivent pointer vers l’URL préférée. Vérifiez :

• menus et fil d’Ariane ;
• liens dans les articles ;
• pagination ;
• cartes produit ou service ;
• flux RSS ;
• liens générés par JavaScript ;
• canonicals injectés par le CMS.

Un site qui déclare /guide/ comme canonique mais lie partout vers /guide?source=menu envoie des signaux inutiles et complique la mesure.

E : Attendre et mesurer la réévaluation

La documentation Google mise à jour le 10 juillet 2026 précise que, même après correction du contenu, les pages peuvent rester dans un cluster de doublons jusqu’à deux semaines. Une différence claire et significative peut aider les pages à être séparées plus vite.

Après la correction :

1. enregistrez la date et les URL touchées ;
2. demandez une indexation uniquement pour les URL prioritaires, car l’outil est soumis à des quotas ;
3. contrôlez les statuts et canonicals rendus ;
4. suivez la canonique sélectionnée dans Search Console ;
5. observez indexation et performances sur plusieurs semaines ;
6. n’ajoutez pas une nouvelle correction sans preuve d’un problème restant.

La demande d’indexation sollicite une réévaluation. Elle n’impose ni délai, ni résultat.

Cas particulier d’une migration de domaine

Préparez une correspondance ancienne URL vers nouvelle URL, testez les redirections et actualisez canonical, robots, sitemaps et liens. Pour un changement d’adresse, la veille GEOAPP retient aussi la nécessité de couvrir les variantes vérifiées de l’ancien domaine, notamment www, sans www et sous-domaines concernés.

Après mise en ligne, surveillez les 404, les erreurs de crawl et la capacité serveur. Google peut explorer plus fortement l’ancien et le nouveau site pendant la transition. Gardez les redirections suffisamment longtemps pour le transfert des signaux et pour les utilisateurs qui suivent d’anciens liens.

Checklist avant de conclure

• la décision éditoriale est connue pour chaque URL ;
• les redirections mènent à une destination pertinente ;
• le canonical est absolu et non contradictoire ;
• le sitemap contient uniquement les URL souhaitées ;
• les liens internes utilisent la bonne version ;
• les blocages temporaires de migration ont été retirés ;
• Search Console montre la propriété correcte ;
• la date de correction est consignée ;
• le délai de réévaluation est annoncé sans promesse.

Limites

Google choisit la canonique à partir de ses propres systèmes et peut ne pas suivre la préférence déclarée. Le délai de deux semaines concerne la persistance possible d’un cluster après correction de contenu, pas une garantie de résolution. Les migrations complexes peuvent demander davantage de temps. CIBLE est une méthode de suivi, pas un contrôle du calendrier d’indexation.

Articles liés

• Google AI Overviews : rendre une page éligible
• Hreflang et traduction IA : construire un SEO international vérifiable
• Fraîcheur éditoriale et GEO
• Analyser les logs des crawlers IA

Prochaine étape

Exportez un échantillon de clusters dans Search Console, choisissez une décision par groupe et ouvrez un journal CIBLE avant de modifier les balises. Pour cadrer une migration ou une consolidation, décrire les domaines et les URL concernées.