Page en double sans URL canonique sélectionnée par l'utilisateur : corriger

« Page en double sans URL canonique sélectionnée par l'utilisateur » signifie que Google a jugé qu'une URL était la copie d'une autre page, n'y a trouvé aucune URL canonique déclarée et a choisi lui-même la version à afficher dans la recherche. Lorsque l'URL signalée est une variante sur laquelle personne ne devrait arriver, comme une copie avec paramètre de suivi ou en HTTP, et que Google a choisi votre page préférée, c'est le résultat voulu et aucune action n'est nécessaire. Il faut corriger lorsque Google a choisi une URL que vous ne voulez pas voir dans les résultats, ou lorsque l'URL signalée est justement la page que vous vouliez positionner.

Ce que signifie cet état selon Google

Cet état figure dans le Rapport sur l'indexation des pages, parmi les raisons pour lesquelles les pages ne sont pas indexées. La documentation de Google sur ce rapport (consultée en octobre 2026) indique que la page « est une copie d'une autre page, mais n'indique pas de page canonique préférée ». La même entrée précise que Google ne diffusera pas l'URL signalée dans la recherche, présente ce comportement comme normal et non comme une erreur, et propose 2 solutions : indiquer explicitement l'URL canonique si Google a choisi la mauvaise URL, ou rendre le contenu nettement différent si la page n'est pas réellement un doublon.

« En double » est le jugement de Google après qu'il a regroupé des pages similaires dans un même ensemble. « Sans URL canonique sélectionnée par l'utilisateur » signifie que l'URL signalée n'a fourni à Google aucune URL canonique lisible, ce qui distingue cet état de ses 2 voisins :

La documentation de Google sur la canonicalisation ajoute qu'une URL canonique déclarée est « une indication, pas une règle » : Google tient encore compte des redirections, des entrées de sitemap et du HTTPS avant de décider.

D'où viennent les URL en double

Presque chaque URL signalée correspond à une même page accessible à plusieurs adresses. La documentation de Google sur la structure des URL indique que son traitement des URL est sensible à la casse, et un article du blog Google Search Central sur la barre oblique finale (avril 2010) précise que Google traite /shoes et /shoes/ comme 2 URL distinctes (la racine du site faisant exception). Chaque différence ci-dessous crée une nouvelle URL pour le même contenu.

• Aucune balise canonique sur la page préférée. Si votre page ne déclare aucune URL canonique, aucune de ses variantes n'en porte non plus, et chaque copie que trouve Google atterrit ici. Le cœur de WordPress, par exemple, n'affiche une balise canonique que sur les articles et pages individuels ; les archives, catégories, tags et la page d'accueil du blog n'en ont pas, sauf si un thème ou une extension en ajoute une.
• Variantes de protocole et d'hôte. http:// et https://, ou www et le domaine nu, qui répondent tous avec un code 200 au lieu de rediriger vers une seule adresse.
• Barre oblique finale et casse. /shoes, /shoes/ et /Shoes/ qui servent la même page.
• Paramètres et vues alternatives. Balises de suivi comme ?utm_source=, options de tri et de filtre, identifiants de session, versions imprimables ou vues en grille du même contenu.
• Copies involontaires. Une version de démonstration du site laissée ouverte aux robots d'exploration, que la documentation de Google cite comme cause, un hôte de préproduction, ou un ancien domaine qui sert toujours les mêmes pages.
• Une balise canonique que Google ne peut pas lire. Google n'accepte rel="canonical" que dans le <head>, et sa documentation sur les métadonnées de page indique qu'un élément non valide à cet endroit, comme un iframe ou un img, fait croire à Google que le head est terminé et l'amène à ignorer la suite. Une balise canonique placée après un tel élément est de fait absente.
• Des pages que vous jugez distinctes. Des déclinaisons de couleur d'un produit aux descriptions identiques, ou des pages d'établissement qui partagent toutes leurs phrases sauf le nom de la ville.

Sur 45 sites externes audités par SEOReport entre mai et octobre 2026, 14 (31 %) servaient une page d'accueil sans balise canonique dans le HTML renvoyé par le serveur, et 1 en servait plusieurs. Dans le même échantillon, 2 sites sur 45 (4 %) ne redirigeaient pas le HTTP vers le HTTPS.

Est-ce un problème ? Corriger, laisser ou surveiller

Le verdict dépend de l'URL choisie par Google et de votre souhait de voir ou non l'URL signalée dans la recherche.

flowchart TD
    A["URL signalée : Page en double sans URL canonique sélectionnée par l'utilisateur"] --> B["Inspection d'URL : lire l'URL canonique sélectionnée par Google"]
    B --> C{"Le choix de Google est-il l'URL voulue dans la recherche ?"}
    C -->|oui| D{"Vos liens ou votre sitemap pointent-ils vers l'URL signalée ?"}
    D -->|non| E["Laisser : la copie est filtrée comme prévu"]
    D -->|oui| F["Faire pointer liens et sitemap vers l'URL préférée"]
    C -->|non| G{"Le contenu est-il vraiment identique ?"}
    G -->|non| H["Rendre les pages nettement différentes"]
    G -->|oui| I["Déclarer l'URL préférée : canonique, redirections, liens, sitemap"]
    F --> J["Tester l'URL en ligne, puis Valider la correction"]
    H --> J
    I --> J

Comment confirmer la cause en jeu

1. Regroupez les exemples par type. Le tableau d'exemples affiche au maximum 1 000 lignes et peut ne pas lister toutes les URL concernées : cherchez donc des schémas (tout en http://, tout en ?utm_, tout en majuscules) plutôt que de compter.
2. Inspectez une URL signalée. Dans l'outil d'inspection d'URL, comparez « URL canonique déclarée par l'utilisateur » et « URL canonique sélectionnée par Google ». Pour cet état, le résultat indexé affiche généralement « Aucune » comme URL canonique déclarée par l'utilisateur. Si « Tester l'URL en ligne » y affiche désormais une URL canonique, elle a été ajoutée après la dernière exploration de cette URL par Google.
3. Comparez les 2 URL caractère par caractère. Protocole, hôte, casse, barre oblique finale et paramètres. La différence désigne la cause.
4. Trouvez où Google a rencontré la variante. Dans le résultat de l'inspection, « Page de provenance » montre une page que Google a pu utiliser pour découvrir l'URL, et « Sitemaps » liste tout sitemap qui la mentionne.
5. Récupérez les variantes comme le ferait un robot d'exploration. Un navigateur masque les redirections ; la réponse brute, non.

# Status code and redirect target for each variant of one page
for u in http://example.com/shoes/ https://example.com/shoes/ \
         https://www.example.com/shoes https://www.example.com/Shoes/ \
         "https://www.example.com/shoes/?utm_source=newsletter"; do
  curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}  $u\n" "$u"
done

# The canonical tag in the HTML the server returns, before any JavaScript runs
curl -s https://www.example.com/shoes/ | grep -io '<link[^>]*canonical[^>]*>'

Chaque variante doit répondre par une redirection 301 vers l'URL préférée, ou par un code 200 avec une balise canonique qui la désigne. Une variante qui répond 200 sans balise canonique peut continuer à atterrir dans cet état.

Comment corriger chaque cause

Balise canonique absente. Dotez chaque page indexable d'une balise canonique autoréférente avec une URL absolue, placée tôt dans le <head> du HTML envoyé par le serveur. La documentation de Google recommande à la fois la forme autoréférente et les URL absolues.

<head>
  <meta charset="utf-8">
  <link rel="canonical" href="https://www.example.com/shoes/">
  <title>Trail running shoes</title>
</head>

Construisez la balise canonique à partir de l'adresse préférée de la page, jamais à partir de l'URL demandée. Un template qui recopie la requête fait de /shoes/?utm_source=newsletter sa propre URL canonique, et les variantes risquent alors de passer dans « Page en double : Google a choisi une autre URL canonique que l'utilisateur » au lieu d'être regroupées.

Variantes de protocole et d'hôte. Redirigez chaque variante par une seule redirection 301 qui conserve le chemin et la chaîne de requête. Sur nginx, le côté HTTP ressemble à ceci ; ajoutez la même ligne return au bloc server HTTPS du domaine nu.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Google préfère les pages HTTPS comme URL canoniques, sauf conflit, par exemple un certificat non valide ou une redirection du HTTPS vers le HTTP. Envoyez chaque variante vers l'adresse finale en une seule étape ; notre guide des chaînes de redirections montre comment les règles de protocole, d'hôte et de barre oblique s'empilent en chaînes lorsqu'on les ajoute séparément.

Barre oblique finale et casse. Choisissez un style, redirigez l'autre vers lui en 301, et faites générer les liens dans ce style par le CMS. Les recommandations de Google sur les URL préconisent une casse unique.

Paramètres et vues alternatives. Une balise canonique autoréférente correcte sur l'URL propre couvre les paramètres de suivi, puisque chaque copie balisée désigne alors la page propre. Cessez de créer des liens internes vers des URL à paramètres, déplacez les identifiants de session dans des cookies, et dotez les versions imprimables et les vues alternatives d'une balise canonique vers la page principale. N'utilisez pas robots.txt pour masquer les doublons : Google indique qu'une URL bloquée peut tout de même être indexée sans son contenu, et Google ne peut pas lire la balise canonique d'une page qu'il n'a pas le droit de récupérer. Google déconseille aussi noindex pour choisir une URL canonique au sein d'un site, et l'outil de suppression d'URL masque toutes les versions d'une URL.

Copies involontaires. Placez les hôtes de préproduction derrière une authentification ; redirigez les anciens domaines page par page.

Des pages qui ne sont pas des doublons. Donnez à chaque page un contenu que les autres n'ont pas : caractéristiques techniques, disponibilité, informations locales. La documentation de dépannage de Google indique que des pages peuvent rester dans un groupe de doublons jusqu'à 2 semaines après la modification.

Alignez tous les signaux. Ne listez que les URL préférées dans votre sitemap XML, et faites pointer vos liens internes vers l'URL que désigne votre balise canonique. Google met en garde contre le fait d'indiquer une URL dans un sitemap et une autre dans rel="canonical". Notre analyse des sitemaps en désaccord avec leurs pages et le guide des balises canoniques traitent les autres conflits.

Comment vérifier la correction

1. Lancez « Tester l'URL en ligne » sur une URL signalée et sur sa page préférée. Le test en ligne montre l'URL canonique déclarée par l'utilisateur ; selon Google, il ne peut pas prédire quelle URL Google choisira.
2. Utilisez « Demander une indexation » pour quelques pages préférées importantes ; une limite quotidienne s'applique.
3. Cliquez sur « Valider la correction » pour l'état une fois toutes les occurrences du schéma corrigées. La documentation de Google indique que la validation prend généralement jusqu'à 2 semaines environ, parfois beaucoup plus, et qu'elle s'arrête si Google trouve une occurrence restante.
4. Attendez-vous à ce que les URL changent d'état plutôt qu'à ce qu'elles disparaissent. Les variantes qui redirigent désormais apparaissent en « Page avec redirection » ; celles dont Google accepte la balise canonique figurent généralement en « Autre page avec balise canonique correcte ». Ce sont deux états normaux pour une copie.
5. Après quelques semaines, inspectez à nouveau vos pages préférées et vérifiez que l'« URL canonique sélectionnée par Google » correspond à l'URL que vous avez déclarée.

Search Console vous dit quelles URL Google a classées comme copies, pas quel réglage global du site continue de les produire. Un diagnostic SEOReport complet vérifie ces sources globales depuis l'extérieur : www et le domaine nu qui servent tous deux le site, un HTTP qui ne redirige pas vers le HTTPS, un style de barre oblique finale incohérent entre les URL du sitemap, des balises canoniques et des hreflang, et une page d'accueil sans balise canonique ou avec plusieurs. Il signale aussi les articles quasi dupliqués. Les copies à paramètres et les pages internes sans balise canonique nécessitent toujours l'outil d'inspection d'URL et les vérifications ci-dessus. Vérifier les variantes de chaque template est un travail à l'échelle du site, et c'est pourquoi une seule session de chat avec une IA en vient rarement à bout.

Questions fréquentes

Cet état nuit-il à mon positionnement ?

Google le présente comme un fonctionnement normal, et une part de contenu en double est habituelle. Le coût apparaît lorsque Google choisit une URL que vous ne voulez pas dans les résultats, ou lorsque le temps d'exploration part dans des copies. Google précise que la page canonique est explorée le plus régulièrement, et les doublons moins souvent.

Pourquoi le rapport liste-t-il des URL vers lesquelles mon site ne fait aucun lien ?

Google découvre des URL par des liens externes, des campagnes balisées, d'anciens sitemaps et des versions antérieures de votre site. Une balise canonique correcte sur l'URL propre règle le cas de ces copies, quelle que soit leur origine.

Les URL en double doivent-elles disparaître de Search Console après la correction ?

En général, elles restent listées sous un autre état, comme le décrivent les étapes de vérification. Une URL non indexée ne pose problème que si vous la voulez dans la recherche, le même critère que pour Explorée, actuellement non indexée.

Comment cet état s'appelle-t-il dans les autres langues de Search Console ?

Les pages d'aide localisées de Google (consultées en octobre 2026) donnent « Duplikat – vom Nutzer nicht als kanonisch festgelegt » en allemand, « Duplicada: el usuario no ha indicado ninguna versión canónica » en espagnol et « Page en double sans URL canonique sélectionnée par l'utilisateur » en français ; en anglais, l'état s'intitule « Duplicate without user-selected canonical ». Le sens et les corrections sont identiques dans toutes les langues.