Page en double sans URL canonique sélectionnée par l'utilisateur : causes, solutions et correction (Search Console)
Vous ouvrez le rapport d'indexation de Google Search Console, et là, dans la colonne "Non indexées", vous tombez sur ça : "Page en double sans URL canonique sélectionnée par l'utilisateur". Des dizaines, parfois des centaines d'URLs listées.
Première réaction : panique. Deuxième réaction : confusion, parce que vous ne voyez pas pourquoi ces pages seraient en double.
C'est l'une des erreurs GSC les moins bien comprises — pas parce qu'elle est complexe, mais parce que son nom masque ce qui se passe vraiment.
Ce que signifie vraiment cette erreur
Quand Google crawle votre site, il compare les pages entre elles. Si deux URLs lui semblent suffisamment similaires — même contenu, même structure, différence minime dans l'URL — il les considère comme des doublons. Il doit donc décider laquelle indexer.
Normalement, c'est vous qui lui dites quelle version est la "bonne" : c'est le rôle de la balise rel="canonical". Mais si vous n'en avez pas ajouté une, Google fait son propre choix. Et c'est exactement ce que le message vous dit : vous n'avez pas exprimé de préférence, donc Google a choisi lui-même.
Ce n'est pas nécessairement une catastrophe. Google choisit souvent la bonne URL. Mais parfois il se trompe — et même quand il a raison, vous perdez la maîtrise de votre indexation.
L'erreur à ne pas confondre
Il existe dans la GSC une autre erreur au nom très proche : "Page en double : Google n'a pas choisi la même URL canonique que l'utilisateur". La distinction est importante.
| Erreur | Ce qui se passe |
|---|---|
| Page en double sans URL canonique sélectionnée par l'utilisateur | Vous n'avez déclaré aucune canonical. Google a choisi lui-même. |
| Page en double : Google n'a pas choisi la même URL canonique que l'utilisateur | Vous avez déclaré une canonical, mais Google l'a ignorée et a indexé une autre version. |
La première se corrige en ajoutant une balise canonical. La seconde indique un problème plus profond : Google pense que votre canonical est incorrecte, et il a ses raisons. Les deux méritent une attention différente — et beaucoup d'articles les traitent comme si c'était la même chose, ce qui crée de la confusion.
Comment Google repère des pages en double
Google ne compare pas les URLs entre elles mot à mot. Il analyse le contenu de chaque page et construit une empreinte sémantique. Deux pages avec des URLs différentes mais un contenu identique (ou quasi identique) seront traitées comme des doublons.
Les signaux qu'il prend en compte :
- Le contenu textuel : le principal indicateur. Si deux pages ont le même texte principal, les mêmes titres, les mêmes descriptions produits, Google les regroupe.
- Les liens internes : si votre site pointe vers
/produit/et/produit(sans slash) de manière indifférenciée, c'est un signal de doublon. - Le sitemap : si les deux versions d'une URL apparaissent dans votre sitemap.xml, vous signalez vous-même qu'elles existent toutes les deux.
- Les redirections absentes : une page accessible en HTTP et en HTTPS sans redirection de l'une vers l'autre crée deux versions indexables du même contenu.
Ce que Google fait ensuite : il regroupe ces URLs dans un "cluster" de doublons et choisit une URL canonique parmi elles. Celle qu'il choisit est indexée. Les autres apparaissent dans la GSC sous l'erreur qui nous intéresse.
Les 6 causes les plus fréquentes
Cette erreur apparaît quand Google détecte deux URLs avec le même contenu et qu'aucune balise canonical ne lui indique laquelle retenir. Dans la grande majorité des cas, c'est un problème technique de configuration — slash final, HTTP/HTTPS, www, paramètres d'URL — pas un vrai doublon de contenu intentionnel. Parfois plusieurs causes coexistent sur le même site.
1. Le slash final : /page/ vs /page
C'est probablement la cause numéro un sur les sites WordPress. /about/ et /about sont deux URLs techniquement distinctes. Si votre serveur répond à toutes les deux sans redirection de l'une vers l'autre, Google voit deux pages avec le même contenu.
Le fix : choisissez une convention (avec ou sans slash), redirigez systématiquement l'autre version, et assurez-vous que vos liens internes sont cohérents.
2. HTTP vs HTTPS
Si votre site est accessible en HTTPS mais que la version HTTP répond encore (même avec un code 200), Google peut crawler les deux. Une redirection 301 de tout HTTP vers HTTPS devrait exister, et si vous avez migré récemment, il peut y avoir des résidus.
Pour vérifier : tapez http://votresite.com dans un navigateur. Si vous n'êtes pas immédiatement redirigé vers HTTPS, c'est à corriger.
3. www vs non-www
Même problème, même logique. www.votresite.com et votresite.com sont deux domaines différents aux yeux de Google. L'un doit rediriger vers l'autre — et cette règle doit être appliquée avant tout autre traitement dans votre configuration serveur ou votre CDN.
4. Paramètres d'URL
C'est là que ça se complique. Les paramètres UTM (?utm_source=newsletter), les paramètres de session (?sessionid=abc123), les paramètres de tri et filtrage (?sort=price&order=asc) — tous créent des URLs uniques avec le même contenu.
Un site e-commerce avec 500 produits et 10 combinaisons de filtres peut générer 5 000 URLs distinctes qui pointent toutes vers les mêmes pages. Google va crawler une bonne partie de ces URLs avant de réaliser qu'elles sont identiques.
Les canonicals pointant vers l'URL propre (sans paramètres) sont la solution standard. Sur certains CMS, vous pouvez aussi configurer ces paramètres directement dans la GSC via les "Paramètres d'URL" — mais cette fonctionnalité a été dépréciée et ne s'applique qu'aux anciens comptes.
5. La pagination
/blog/page/2/, /blog/?page=2, /blog/2/ : trois façons courantes de paginer selon les CMS et les thèmes. Si votre site a changé de structure à un moment, ou si vous avez plusieurs plugins de pagination actifs, vous pouvez vous retrouver avec les deux formats accessibles simultanément.
La pagination est aussi un cas particulier parce que ces pages ne doivent pas nécessairement pointer vers la page 1 comme canonical — c'est une erreur courante. Chaque page de pagination est une page distincte avec son propre contenu. Ce qui doit exister, c'est une cohérence dans l'URL utilisée pour les atteindre.
6. Variantes de tracking et de session
Les paramètres de session sont particulièrement problématiques sur les vieux sites e-commerce : ?PHPSESSID=... ou ?sid=... ajoutés automatiquement à chaque URL pour les utilisateurs non connectés. Chaque session crée une URL unique. Google peut indexer des milliers de ces variantes avant que vous vous en rendiez compte.
Identifier toutes les URLs affectées — pas une par une
C'est là que GSC montre ses limites. Le rapport d'indexation vous dit que des pages ont ce statut, mais vous ne pouvez pas facilement en extraire une liste complète, ni savoir quelle URL Google a choisie comme canonique à la place de chaque doublon.
Pour ça, vous avez deux options.
L'API URL Inspection de Google vous permet d'interroger le statut d'indexation d'une URL précise — ce que Google a indexé, quelle canonical il a retenue, quand il a crawlé la page. C'est l'outil le plus fiable parce qu'il renvoie les mêmes données que ce que vous voyez dans la GSC en tapant une URL à la main. Le problème : la limite est de 2 000 requêtes par jour et par propriété GSC. Sur un site de 50 000 URLs, c'est 25 jours d'analyse.
IndexProbe résout ce problème de quota. Il se connecte à votre propriété GSC, distribue les requêtes automatiquement sur plusieurs jours, et vous donne pour chaque URL : le statut d'indexation, la canonical retenue par Google, la date du dernier crawl. Vous pouvez filtrer par statut et exporter toutes les "pages en double sans URL canonique" en une fois, puis les traiter par lot.
Vue IndexProbe — onglet URLs, filtre appliqué sur le statut "Page en double sans URL canonique". La colonne "Balise Canonical Utilisateur" est vide (aucune canonical déclarée côté site), tandis que "Canonical pour Google" montre l'URL que Googlebot a choisie lui-même.
Si vous n'avez qu'une poignée d'URLs à vérifier, l'inspecteur d'URL de GSC suffit. Dès que vous êtes sur un site de taille moyenne, l'inspection manuelle URL par URL n'est pas une stratégie viable.
Quelle correction choisir ?
La correction dépend de la nature du doublon. Si l'URL doublon n'a pas lieu d'exister (version HTTP d'un site HTTPS, URL avec paramètre de session), optez pour une redirection 301. Si les deux URLs sont légitimes mais que l'une est préférée, utilisez une balise canonical. Si la page ne doit pas être indexée mais doit rester accessible, utilisez noindex — jamais les deux en même temps.
Le tableau ci-dessous résume les situations courantes :
| Situation | Solution recommandée |
|---|---|
| Deux URLs identiques, l'une est la "vraie", l'autre est un artefact technique | Redirection 301 de l'artefact vers la vraie |
Deux formats d'URL pour la même page paginée (ex : /page/2/ vs /?page=2) |
Redirection 301 vers le format retenu, ou canonical auto-référente vers ce format — jamais vers la page 1 |
| Page que vous ne voulez pas indexer, mais qui doit rester accessible | Attribut noindex |
| Deux pages avec contenu quasi identique, toutes deux peu importantes | Consolidation : fusionner le contenu, rediriger l'une vers l'autre |
| Paramètres d'URL qui varient sans changer le contenu | Canonical sur la version sans paramètres |
Option 1 — La balise rel="canonical"
C'est la solution recommandée par Google dans la majorité des cas. Elle s'ajoute dans le <head> de chaque page qui est un doublon :
<link rel="canonical" href="https://www.votresite.com/la-vraie-url/" />
Quelques règles à respecter :
- Toujours en URL absolue (pas relative)
- Une seule balise canonical par page
- Elle doit pointer vers une URL qui répond en 200 (pas une redirection, pas une page 404)
- Elle doit être dans le
<head>, pas dans le<body>
La balise canonical est un signal, pas une directive. Google peut choisir de l'ignorer s'il estime qu'elle est incorrecte ou contradictoire avec d'autres signaux. Si Google ignore la vôtre, c'est souvent parce que vous avez d'autres signaux contradictoires (liens internes vers les deux versions, les deux dans le sitemap, etc.).
Option 2 — La redirection 301
Quand l'URL doublon n'a vraiment pas lieu d'exister — une version HTTP d'une page qui n'est accessible qu'en HTTPS, ou une URL avec paramètre de session — la redirection 301 est plus propre. Elle consolide le PageRank, elle élimine définitivement le doublon, et Google n'a plus à "choisir".
L'inconvénient : si des liens externes pointent vers la version redirigée, vous perdrez un minuscule pourcentage de la valeur transmise à chaque saut. En pratique, pour des redirections en chaîne simple (A → B), c'est négligeable.
Option 3 — L'attribut noindex
À utiliser avec parcimonie. noindex empêche Google d'indexer la page, mais Googlebot continue à la crawler pour découvrir les liens qu'elle contient. C'est pertinent pour des pages de filtrage ou de tri que vous voulez garder accessibles aux utilisateurs sans qu'elles apparaissent dans les résultats de recherche.
Attention : noindex et canonical ne font pas la même chose. Une page avec noindex ne sera pas indexée. Une page avec une canonical qui pointe vers une autre URL sera traitée comme un doublon de celle-ci. Mettez les deux sur la même page et vous envoyez des signaux contradictoires — voir la section pièges.
Option 4 — La consolidation de contenu
Parfois la bonne réponse est de fusionner deux pages en une. Si vous avez deux articles sur des sujets très proches, ou deux pages produits pour des variantes très similaires, les regrouper en une seule page plus complète est souvent meilleur pour le SEO et pour l'expérience utilisateur.
Quand NE PAS ajouter de canonical
C'est le cas que personne ne mentionne jamais. Si vous avez une page de résultats de recherche interne, une page de panier, ou une page de confirmation de commande qui remonte dans ce rapport — n'ajoutez pas de canonical. Ces pages doivent simplement avoir un noindex. Ajouter une canonical vers la page d'accueil par exemple ne fait que créer de la confusion.
De même, sur une page d'accueil de version multilingue, pointer la canonical de /fr/ vers / parce que c'est "la vraie" peut être contre-productif si vous gérez correctement l'hreflang. Les deux doivent coexister.
Les pièges à éviter lors de la correction
Canonical pointant vers une redirection
C'est l'erreur la plus courante après une migration. Vous avez déclaré une canonical vers http://votresite.com/page/, mais cette URL redirige maintenant vers https://www.votresite.com/page/. Google suit la redirection et voit la bonne page, mais votre signal est dilué. Mettez toujours à jour vos canonicals pour pointer vers l'URL finale, pas une URL intermédiaire.
La chaîne de canonicals
Page A déclare une canonical vers Page B. Page B déclare une canonical vers Page C. Google suit la chaîne, mais avec moins de confiance. Si vous trouvez des chaînes de canonicals en auditant votre site, raccourcissez-les : A doit pointer directement vers C.
noindex + canonical sur la même page
Ces deux directives se contredisent. La canonical dit "cette page est un doublon de X, indexe X". Le noindex dit "n'indexe pas cette page". Google doit choisir — et il choisit généralement d'honorer le noindex. Résultat : ni votre page, ni la cible de la canonical ne sera forcément indexée comme vous le souhaitez. Choisissez l'un ou l'autre.
La balise canonical dans le <body>
Elle sera ignorée par Google. Elle doit impérativement se trouver dans la section <head>. Sur certains CMS ou constructeurs de page, vérifiez que votre plugin ou thème ne déplace pas les balises dans le mauvais endroit lors du rendu.
L'URL relative à la place de l'URL absolue
<!-- À éviter -->
<link rel="canonical" href="/page/" />
<!-- Correct -->
<link rel="canonical" href="https://www.votresite.com/page/" />
L'URL relative peut être interprétée différemment selon le contexte. Utilisez toujours l'URL complète, avec protocole et domaine.
Cas spéciaux
E-commerce : filtres, tri et facettes
C'est le scénario le plus complexe. Un site avec des filtres de catégorie peut générer des milliers d'URLs distinctes pour les mêmes produits : /chaussures/?couleur=noir&taille=42&marque=nike. Chaque combinaison est une URL unique.
La stratégie standard : chaque page filtrée déclare une canonical pointant vers l'URL de catégorie propre (/chaussures/). Pour que ce soit efficace, il faut s'assurer que ces pages filtrées ne sont pas non plus dans le sitemap et que les liens de pagination sur les pages filtrées ne sont pas suivis.
Sur Shopify, la plateforme ajoute automatiquement des canonicals sur les pages de collection filtrées — mais les paramètres UTM ajoutés par vos campagnes marketing ne sont pas couverts par ce mécanisme. Sur WooCommerce, c'est à vous de configurer votre plugin SEO pour gérer ces cas.
Sites multilingues : canonical et hreflang ne font pas la même chose
Beaucoup de gens confondent les deux, et c'est compréhensible. L'hreflang dit à Google quelles sont les versions linguistiques de votre page. La canonical lui dit laquelle indexer parmi des doublons.
Sur un site multilingue, chaque version linguistique doit se déclarer elle-même comme canonical (/fr/page/ → canonical /fr/page/), tout en renseignant les hreflang vers les autres langues. Si vous pointez la canonical de /fr/page/ vers /en/page/, vous informez Google que votre page française est un doublon de la page anglaise — et il ne la montrera plus aux internautes francophones.
Next.js et les frameworks headless
Sur Next.js (App Router), la canonical se gère via la fonction generateMetadata ou directement dans l'objet metadata d'une page :
export const metadata: Metadata = {
alternates: {
canonical: 'https://www.votresite.com/page/',
},
}
L'avantage des frameworks modernes : vous pouvez générer la canonical dynamiquement à partir de l'URL de la page, ce qui élimine les erreurs manuelles. L'inconvénient : si votre application génère des URLs avec des query strings pour des raisons internes (tri, filtres, état d'interface), ces paramètres peuvent se retrouver dans la canonical si vous ne les filtrez pas explicitement.
Vérifiez aussi que votre next.config.js ne génère pas de versions _next/ ou de préfixes de langue qui créent des doublons inattendus.
WordPress
Avec Yoast SEO ou Rank Math, la canonical est générée automatiquement pour chaque page — en général correctement. Les problèmes arrivent quand :
- Vous avez plusieurs plugins SEO actifs en même temps (ils peuvent générer chacun une balise canonical)
- Votre thème ajoute manuellement une balise canonical dans son template
- Vous avez changé la structure de permaliens sans rediriger les anciennes URLs
Pour vérifier ce que votre page envoie réellement à Google, utilisez "Afficher le code source" et cherchez rel="canonical". Si vous en trouvez plusieurs, c'est un problème.
Combien de temps avant que Google retraite la correction ?
C'est la question que tout le monde se pose et que personne ne répond dans les articles sur ce sujet. La réponse honnête : ça dépend.
Pour un site bien crawlé (domaine établi, beaucoup de liens, XML sitemap à jour) : les corrections apparaissent généralement dans la GSC entre 1 et 4 semaines après implémentation. Google recrawle les pages concernées, met à jour son index, et le rapport d'indexation reflète les changements.
Pour un site peu crawlé (site récent, peu de liens, fréquence de crawl faible) : comptez 4 à 8 semaines, parfois plus. Vous pouvez accélérer le processus en soumettant les URLs corrigées via l'outil d'inspection d'URL dans la GSC ("Demander l'indexation").
Ce à quoi ne pas s'attendre : que les erreurs disparaissent du rapport en quelques jours. GSC a un délai d'affichage propre, et même après que Google a recrawlé et mis à jour son index, le rapport peut mettre quelques jours supplémentaires à refléter la situation réelle.
Comment vérifier que ça a fonctionné :
- Dans GSC, allez dans "Inspection d'URL" et entrez l'URL que vous avez corrigée
- Regardez "URL canonique déclarée par l'utilisateur" et "URL canonique Google" — elles doivent correspondre
- Si elles ne correspondent pas encore, ce n'est pas forcément un problème si le crawl date d'avant votre correction
Si après 6 semaines Google ignore toujours votre canonical, c'est un signal qu'il y a d'autres facteurs contradictoires à investiguer.
Questions fréquentes
Qu'est-ce qu'une URL canonique ?
La balise rel="canonical" est un élément HTML que vous placez dans le <head> d'une page pour dire à Google quelle version indexer parmi plusieurs URLs au contenu similaire. Exemple : /produit/, /produit et /produit?ref=newsletter sont trois URLs distinctes pour le même contenu — la canonical désigne laquelle est "la bonne" et concentre la valeur SEO sur elle. Sans canonical, Google tranche lui-même. C'est ce que signale l'erreur qui nous intéresse.
Cette erreur pénalise-t-elle directement mon classement ?
Pas directement. Ce n'est pas une pénalité manuelle. L'impact réel est indirect : Google index une version de votre page qui n'est peut-être pas celle que vous souhaitez, et si vous avez des liens qui pointent vers plusieurs versions de la même URL, leur valeur est diluée entre ces versions. Sur un site où vous avez des dizaines d'URLs affectées, l'effet cumulé peut être significatif.
Faut-il tout corriger en même temps ?
Non. Priorisez les pages importantes : les pages qui génèrent du trafic, les pages cibles de vos campagnes, les pages avec des liens externes. Les pages de faible valeur (pages de tags, archives de dates, variantes de paramètres UTM) peuvent attendre ou être traitées en groupe via une règle de redirection ou de canonical programmatique.
Google peut-il ignorer ma balise canonical ?
Oui. Google traite la canonical comme un signal fort, mais pas comme une directive absolue (contrairement à noindex). S'il juge que votre canonical est incorrecte — parce qu'elle pointe vers une page redirigée, ou parce que le contenu des deux pages est trop différent pour être des doublons — il peut choisir d'ignorer votre suggestion. C'est ce que signifie l'erreur "Page en double : Google n'a pas choisi la même URL canonique que l'utilisateur".
Y a-t-il un nombre "normal" de pages avec ce statut ?
Sur un site bien géré, vous devriez tendre vers zéro pour les pages importantes. Quelques URLs avec ce statut sur des pages secondaires n'est pas forcément alarmant. En revanche, si 20 % ou plus de votre site remonte dans ce rapport, c'est un problème structurel à résoudre.
Vérifier l'indexation de toutes vos URLs, pas seulement une
Le vrai problème avec cette erreur, c'est que GSC vous la signale sans vous dire exactement quelles URLs sont touchées ni quelle canonical Google a choisie à leur place. Vous pouvez passer des heures à inspecter les URLs une par une — l'outil intégré est excellent, mais il n'est pas fait pour ça à grande échelle.
C'est le problème qu'IndexProbe règle. Il se connecte à votre propriété Google Search Console et interroge l'API URL Inspection pour chacune de vos URLs — en distribuant automatiquement les requêtes sur plusieurs jours pour rester dans le quota de 2 000 URLs inspectées/jour/propriété GSC. Résultat : pour chaque URL de votre site, vous obtenez le statut d'indexation réel, le motif de non-indexation si c'est le cas, la canonical que Google a retenue, et la date du dernier crawl. Les mêmes données que dans l'inspecteur d'URL de la GSC, mais sur tout votre site d'un coup.
Vous pouvez ensuite filtrer par statut pour isoler toutes vos "pages en double sans URL canonique", les exporter, les traiter par lot, et suivre l'évolution après vos corrections.