Publiez une page, et votre serveur peut y répondre à 8 adresses. Prenez example.com/guide et combinez http ou https, avec ou sans www, avec ou sans slash final : 2 × 2 × 2 font 8 URL qui peuvent renvoyer le même contenu, avant même d’ajouter un seul paramètre de suivi. Google traite ces copies comme des doublons et en choisit une à afficher, et ce n’est pas toujours celle que vous auriez retenue.
4 sources de doublons, et le bon outil pour chacune
La documentation de Google liste 4 causes de doublons. Le correctif dépend d’une seule question : un visiteur a-t-il jamais besoin du doublon ?
| Source | Exemple | Meilleur correctif | Pourquoi |
|---|---|---|---|
| Protocole | http://example.com/guide et https://example.com/guide | Redirection 301 vers https | Personne n’a besoin de la copie non sécurisée |
| Hôte | www.example.com et example.com | Redirection 301 de l’un vers l’autre | Personne n’a besoin des deux |
| Slash final | /guide et /guide/ | Redirection 301 vers la forme que vous utilisez partout | Même contenu, deux adresses |
| Paramètres | /shoes/?sort=price, ?utm_source=news, identifiants de session | rel="canonical" sur la variante, qui pointe vers l’URL propre | La variante doit rester accessible : on ne peut donc pas la rediriger |
Google classe les façons d’indiquer une préférence. Les redirections sont un signal fort, rel="canonical" en est un aussi et peut être envoyé en en-tête HTTP pour les fichiers sans <head> HTML, et lister une URL dans un sitemap est un signal faible. Prenez l’outil le plus fort qui convient : redirigez quand le visiteur n’a jamais besoin du doublon, utilisez canonical quand il en a besoin, et réservez le sitemap à la confirmation de ce que disent les 2 autres. Google déconseille aussi d’utiliser robots.txt pour canonicaliser : une page qu’il ne peut pas explorer est une page dont il ne lit jamais la balise canonical.
Rien de tout cela ne fonctionne sans cohérence. La cible de la redirection, la balise canonical, l’entrée du sitemap et vos liens internes doivent tous employer la même adresse absolue, avec le même protocole, le même hôte et le même style de slash. Chaque désaccord est un signal qui tire dans l’autre sens.
Rediriger ce dont les visiteurs n’ont jamais besoin
L’hôte, le protocole et les slashs se traitent tous mieux par des redirections, et l’objectif est d’aller de n’importe quelle variante à l’adresse finale en un seul saut. Voici la version nginx, avec 2 petits blocs server placés devant le vrai.
# Port 80 : n'importe quel hôte, un saut vers l'adresse HTTPS finale
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
# Port 443, www : un saut vers le domaine nu
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on; # nginx 1.25.1 ou plus récent
server_name www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
return 301 https://example.com$request_uri;
}$request_uri conserve le chemin et la chaîne de requête : les liens profonds survivent. Le bloc www a quand même besoin d’un certificat qui couvre www.example.com, sinon les visiteurs voient un avertissement du navigateur avant que la redirection ait lieu. Dans votre bloc server principal, un slash final manquant peut s’ajouter avec une seule ligne, qui conserve aussi la chaîne de requête :
# Chemins sans extension uniquement : /guide devient /guide/
rewrite ^([^.]*[^/])$ $1/ permanent;Gardez-la à l’écart des chemins d’API et testez avant de vous y fier. Vous n’en aurez peut-être pas besoin : sur un site statique servi avec try_files $uri $uri/ =404;, notre nginx répond à /seo-checker par une 301 vers /seo-checker/ sans aide. Si vous préférez les adresses sans slash, la règle miroir est rewrite ^/(.+)/$ /$1 permanent;. Les deux choix conviennent, tant que c’est le seul.
Sur Apache, mod_dir ajoute déjà le slash aux vrais répertoires, et la règle d’hôte et de protocole tient dans .htaccess ou dans l’hôte virtuel :
RewriteEngine On
# http ou www -> https://example.com en un saut
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Si un proxy ou un CDN termine le HTTPS en amont d’Apache, %{HTTPS} peut valoir off à chaque requête et vous envoyer dans une boucle. Testez plutôt l’en-tête X-Forwarded-Proto.
Écrire correctement la balise canonical
Quand une redirection n’est pas possible, indiquez quelle adresse est l’originale avec une balise dans le <head> de la page, écrite en URL absolue.
<head>
<link rel="canonical" href="https://example.com/shoes/">
</head>Sur https://example.com/shoes/, cette balise pointe vers la page elle-même, ce qui est le schéma recommandé : un canonical auto-référent sur la page propre, et la même balise sur chaque variante comme /shoes/?sort=price. Pour un fichier sans <head> HTML, comme la copie PDF d’une page, la même déclaration passe par un en-tête de réponse : Link: <https://example.com/shoes/>; rel="canonical". Ce même balisage se trompe de 4 façons courantes.
<!-- 1. URL relative -->
<link rel="canonical" href="/shoes/">
<!-- 2. Mauvais hôte, copié depuis la préproduction ou depuis un gabarit -->
<link rel="canonical" href="https://staging.example.com/shoes/">
<!-- 3. Canonical combiné à noindex -->
<meta name="robots" content="noindex">
<link rel="canonical" href="https://example.com/shoes/">
<!-- 4. Deux canonical en désaccord -->
<link rel="canonical" href="https://example.com/shoes/">
<link rel="canonical" href="https://www.example.com/shoes/">Une URL relative se résout par rapport à l’hôte qui a servi la page. Sur la copie en www, elle pointe donc vers la copie en www : le doublon se porte garant de lui-même, et Google demande des URL absolues. Un mauvais hôte dit à Google que votre page en ligne est la copie de celle d’un autre, et notre vérificateur AdSense fait échouer un canonical d’accueil situé sur un autre hôte pour cette raison. Canonical plus noindex envoie 2 messages opposés, l’un demandant à Google d’abandonner la page, l’autre la désignant comme préférée : il faut choisir. Noindex seul pour une page qui doit rester hors des résultats, une redirection ou un canonical pour un vrai doublon. Les canonical en double apparaissent d’ordinaire quand un thème et une extension SEO en impriment chacun un et divergent sur le www ou le slash. Affichez le code source et cherchez canonical pour les compter.
Une balise canonical ne remplace pas non plus un code d’état. Une page supprimée doit répondre 404 ou 410. La pointer vers l’accueil masque le problème au lieu de le résoudre, et les pages d’erreur qui répondent 200 sont les soft 404, traitées dans le guide sur les soft 404 et les codes HTTP.
Les traductions ne sont pas des doublons, et certains doublons se cachent bien
Une page en français n’est pas la copie de la page en anglais, et canonicaliser une langue vers l’autre dit à Google de n’indexer que celle-là. Chaque version doit se désigner elle-même comme canonical et lister toutes les versions, elle comprise, comme alternatives. Voici le balisage que porte notre propre page de guide en français :
<link rel="canonical" href="https://greenlightmysite.com/fr/guide/">
<link rel="alternate" hreflang="en" href="https://greenlightmysite.com/guide/">
<link rel="alternate" hreflang="fr" href="https://greenlightmysite.com/fr/guide/">
<link rel="alternate" hreflang="x-default" href="https://greenlightmysite.com/guide/">La page anglaise porte les 3 mêmes alternatives, avec sa propre adresse comme canonical. Les alternatives qui ne sont pas réciproques peuvent être ignorées : vérifiez donc les deux sens quand vous ajoutez une langue.
Certains doublons échappent au décompte à 4 sources. Dans une URL, les chemins sont sensibles à la casse : /Guide et /guide font donc 2 adresses dès que votre serveur répond aux deux, comme le font certains systèmes de gestion de contenu et routeurs d’application. /index.html peut répondre à côté de /, et un double slash dans //guide peut passer à travers une réécriture négligente. Redirigez chacun vers la forme que vous utilisez. Les paramètres de suivi méritent une règle à part : ne faites jamais de lien interne vers une URL qui contient des paramètres utm_, car chaque lien de ce genre donne à Google un doublon à trier. Pour repérer ceux que vous avez déjà, lancez le script de sitemap de notre guide pour trouver le contenu de faible valeur. Ses alertes duplicate-title et canonical-elsewhere désignent les pages qui méritent un second regard.
Vérifier ce que font vraiment votre serveur et Google
Ne vous fiez pas à la configuration, fiez-vous aux requêtes. Cette boucle suit chaque variante d’une page existante et affiche le nombre de redirections nécessaires et l’adresse où chacune aboutit. Remplacez host par votre propre domaine et path par une page qui existe, sans le slash final.
host=greenlightmysite.com
path=/seo-checker
for u in http://$host$path http://www.$host$path https://www.$host$path https://$host$path https://$host$path/; do
curl -sIL -o /dev/null -w "%{num_redirects} redirect(s) -> %{url_effective}\n" "$u"
doneLe 7 octobre 2026, cette boucle a affiché ceci pour notre propre site.
2 redirect(s) -> https://greenlightmysite.com/seo-checker/
3 redirect(s) -> https://greenlightmysite.com/seo-checker/
2 redirect(s) -> https://greenlightmysite.com/seo-checker/
1 redirect(s) -> https://greenlightmysite.com/seo-checker/
0 redirect(s) -> https://greenlightmysite.com/seo-checker/Les 5 variantes aboutissent à une seule adresse, ce qui est l’essentiel, et chaque saut est une 301. Le point faible est la deuxième ligne : notre serveur commence par passer http://www en https://www, puis retire le www, puis ajoute le slash. Google suit jusqu’à 10 sauts de redirection, donc rien ne casse, mais cela fait 3 redirections là où 2 suffiraient, et le bloc du port 80 ci-dessus en supprime une. Notre vérificateur AdSense accepte une chaîne de 0 ou 1 redirection sur l’accueil, avertit à 2 et échoue à partir de 3.
Deux autres vues complètent le tableau. Lancez le vérificateur SEO sur une page : il indique si le canonical existe et s’il pointe vers la page elle-même. Le vérificateur AdSense ajoute l’hôte du canonical de l’accueil, la concordance entre le www et le domaine nu, et la longueur de la chaîne de redirections. Ouvrez ensuite l’inspection d’URL de Search Console, qui montre le canonical que vous avez déclaré à côté de celui que Google a retenu. Quand ils diffèrent, l’un de vos signaux en contredit un autre : vérifiez d’abord que votre sitemap et vos liens internes emploient la variante que vous avez déclarée. Le versant certificat et HSTS de la même chaîne est traité dans le guide HTTPS sans erreur.
