Correction du contenu dupliqué WordPress : Canonique, slash final et WWW sans cannibalisation

octobre 30, 2025 • février 3, 2026 • Lecture : 27 min • Views: 10

Cet article vous a aidé ?

Certaines sites WordPress n’ont pas un problème SEO. Ils ont une crise d’identité d’URL.

Si votre contenu est accessible via quatre URLs différentes (HTTP/HTTPS × www/non-www, plus le slash final optionnel), Google ne « choisit pas la meilleure » comme on l’espère. Il teste, prend des précautions, et parfois répartit les signaux. Pendant ce temps vos propres pages se concurrencent entre elles comme des collègues qui « collaborent » en créant des feuilles de calcul parallèles.

Pourquoi le désordre des URL dupliquées se produit sur WordPress

Le contenu dupliqué sur WordPress n’est généralement pas « quelqu’un a copié mon article ». C’est votre propre site qui génère plusieurs URLs valides pour les mêmes octets. D’un point de vue fiabilité, ce n’est pas seulement du « SEO ». C’est un routage incohérent et une identité incohérente. Les systèmes détestent ça.

Ce que « contenu dupliqué » signifie réellement ici

Les moteurs de recherche n’indexent pas des « pages ». Ils indexent des URLs. Si le même contenu apparaît sur plusieurs URLs, vous avez :

Dilution des signaux : les backlinks et les liens internes se répartissent entre les variantes.
Gonflement de l’index : le budget de crawl est gaspillé sur des doublons au lieu de nouveau contenu.
Cannibalisation : des pages similaires (ou des duplicata) s’échangent les positions de classement, surtout sur les requêtes principales.
Enfer du débogage : vous ne pouvez pas dire quelle URL est « la » URL parce que le site lui‑même n’agit pas comme s’il le savait.

Les suspects habituels : protocole, hôte, slash et plugins « utiles »

Motifs courants d’URL dupliquées sous WordPress :

HTTP vs HTTPS (souvent dû à une migration partielle ou une redirection d’edge mal configurée).
www vs non-www (aucune contrainte d’hôte canonique).
Slash final vs pas de slash (le serveur et les permaliens WordPress ne sont pas d’accord).
Fichiers index : / vs /index.php vs /index.html restes.
Chaînes de requête : paramètres UTM, tri, pagination, identifiants de session, IDs de clics publicitaires.
Archives : archives d’auteurs, par date, par tag qui reproduisent des extraits d’articles ou le contenu complet.
Pages de pièce jointe : URLs des médias WordPress qui dupliquent l’image mais créent des pages peu informatives.

La canonicalisation n’est pas un « ajustement SEO ». C’est un contrat de routage. Décidez ce que doit être le canonique, faites‑le respecter à la périphérie, et faites en sorte que WordPress génère des liens internes cohérents. Faites ces trois choses et le reste devient ennuyeux, ce qui est exactement l’objectif.

Faits intéressants et contexte historique (pourquoi cela se répète)

Les premiers serveurs web traitaient « /dir » et « /dir/ » différemment parce que l’un ressemblait à un fichier et l’autre à un répertoire. Cet héritage s’infiltre encore dans les stacks modernes.
La balise canonical de Google est sortie en 2009 après des années pendant lesquelles les sites combattaient les URLs dupliquées issues des paramètres de suivi et de la syndication.
WWW n’est pas obligatoire ; c’est une convention de nom d’hôte. Mais les CDN et la gestion des cookies dans les années 2000 ont rendu « www » populaire pour des raisons opérationnelles.
Les permaliens WordPress ont tout changé en permettant des « pretty URLs », mais cela a aussi facilité le fait de servir accidentellement le même article depuis plusieurs chemins quand les règles de réécriture dérivent.
Le slash final est devenu une religion en partie parce que le comportement d’Apache avec les répertoires (et plus tard la redirection canonique de WordPress) créait des schémas prévisibles que les SEO ont standardisés.
Les migrations HTTP→HTTPS causaient historiquement d’énormes duplications parce que des gens ajoutaient TLS mais oubliaient d’imposer la redirection et de mettre à jour les liens internes, laissant les deux protocoles vivants pendant des mois.
« Duplicate, Google chose different canonical » dans Search Console est une version moderne d’une vieille histoire : si vous ne choisissez pas une URL unique, Google en choisira une. Parfois, il choisit celle que vous détestez.
Les balises canonical sont des indices, pas des ordres — elles fonctionnent mieux lorsqu’elles sont soutenues par des redirections cohérentes et des liens internes.
Les CDN ont ajouté un nouveau mode d’échec : vous pouvez avoir des redirections d’origine parfaites, mais le edge met en cache la mauvaise variante ou contourne la logique de redirection « pour la performance ».

Plan de diagnostic rapide (vérifiez ceci en premier)

Si vous êtes en astreinte pour « le SEO a chuté » ou « Google indexe des URLs étranges », ne traînez pas dans l’administration WordPress en cliquant partout. Traitez cela comme un triage d’incident : identifiez la politique canonique, testez l’application, puis nettoyez les restes (sitemaps, liens internes, caches).

Vérifiez le comportement de la page d’accueil sur les variantes.
- Test : http vs https, www vs non-www, slash vs sans slash.
- Objectif : chaque variante non canonique doit 301 vers une URL canonique en un seul saut.
Vérifiez une URL d’article représentative et une URL de catégorie/tag représentative.
- Les articles se comportent souvent bien, les archives souvent non.
- Recherchez des réponses 200 sur plusieurs variantes ou des chaînes de redirections.
Vérifiez les balises canonical et les en-têtes sur l’URL canonique.
- Objectif : <link rel="canonical" ...> correspond à l’URL finale après redirections.
- Pas de contradictions : pas de canonical pointant vers un hôte/protocole/slash non canonique.
Vérifiez que les liens internes sont cohérents.
- Si votre HTML interne pointe vers des URLs non canoniques, vous votez contre vous‑même.
Vérifiez les sitemaps et les flux.
- Les URLs du sitemap doivent être canoniques. Si votre sitemap liste des URLs non canoniques, vous soumettez littéralement des duplicata.
Vérifiez le comportement de la couche edge (CDN/WAF/load balancer).
- Assurez‑vous que les redirections se produisent avant la mise en cache, et que la clé de cache ne se sépare pas par hôte/protocole de façon inattendue.

Idée paraphrasée de Werner Vogels : Tout échoue, tout le temps ; concevez en supposant l’échec. La canonicalisation, c’est exactement ça — supposez que quelqu’un atteindra la mauvaise URL et faites en sorte que le système se corrige lui‑même.

Balises canonical vs redirections vs liens internes (qui prime)

Vous entendrez « ajoutez juste une balise canonical ». C’est comme dire « ajoutez juste de la supervision » pendant que la base de données brûle. Les balises canonical comptent, mais elles ne font pas respecter. L’application, ce sont les redirections et les liens internes cohérents.

Redirections : le policier du trafic

Une redirection 301 dit : « cette URL n’est pas la bonne ; allez ici. » Les moteurs consolident généralement les signaux via les 301 avec le temps. Cela empêche aussi les utilisateurs de mettre en favori des variantes indésirables.

Préférence opérationnelle : la normalisation de l’hôte/protocole/slash canonique doit se faire à la périphérie (nginx/Apache/CDN), avant que WordPress n’exécute PHP. C’est plus rapide, moins cher et moins fragile.

Balises canonical : le bulletin de vote

L’élément link rel= »canonical » est un indice intégré au HTML. Il aide quand vous ne pouvez pas rediriger (par exemple, pour des variations de paramètres que vous voulez garder accessibles). Il aide aussi les moteurs à consolider des duplicata qui existent encore.

Règle : les balises canonical doivent correspondre à l’URL finale redirigée. Si vous canonicalisez vers une URL qui elle‑même redirige, vous envoyez des signaux contradictoires.

Liens internes : la culture de l’entreprise

Les liens internes sont ce que votre système « croit ». Si votre menu, vos fil d’Ariane et vos liens inline pointent vers des variantes mélangées, vous continuerez à générer des chemins de crawl vers des duplicata même si des redirections existent. Vous voulez des liens internes propres pour que les crawlers consacrent leur temps aux vraies pages.

Lequel est le plus important ?

Pour l’hôte/protocole/slash : redirections d’abord, puis cohérence des liens internes, puis balises canonical. Les balises canonical sont utiles, mais elles sont les moins autoritaires des trois.

Blague n°1 : La canonicalisation, c’est comme les conventions de nommage — tout le monde est d’accord qu’elles comptent, jusqu’au moment où il faut renommer quelque chose.

Choisir votre politique « une seule URL vraie »

Vous ne pouvez pas corriger les duplications tant que vous ne décidez pas ce qui est « correct ». Choisissez une politique et consignez‑la par écrit. C’est la partie que la plupart des équipes sautent, puis se demandent pourquoi la correction se défait sans cesse.

Politique par défaut recommandée

HTTPS partout (sans exception).
Choisissez un nom d’hôte : soit www, soit non-www. Peu importe lequel. Ce qui compte, c’est que ce soit appliqué.
Cohérence du slash final :
- Pour les « pretty permalinks » de WordPress, le choix courant est le slash pour les URLs de type répertoire (articles/pages) : /post-name/.
- Quoi que vous choisissiez, assurez‑vous que le serveur web et WordPress sont d’accord.
Pas de fichiers index : normalisez /index.php vers /.
Paramètres : autorisez les paramètres marketing pour l’analytics, mais ne les laissez pas créer des duplicata indexables.

Comment cela affecte la cannibalisation

Lorsque des duplicata existent, Google peut classer différentes variantes à différents moments. Cela ressemble à de la « cannibalisation », car votre propre site continue d’alterner quelle URL est éligible. Une fois consolidé en une URL canonique, vous cessez de vous battre vous‑même et commencez à concurrencer tout le monde. Bien plus sain.

Tâches pratiques avec commandes : prouver le problème, puis le corriger

Ci‑dessous des tâches pratiques que vous pouvez exécuter depuis un shell. Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie, et la décision à prendre.

Hypothèses : vous pouvez exécuter des commandes depuis une station de travail ou un bastion. Remplacez example.com par votre domaine.

Tâche 1 : Vérifier le comportement des redirections sur les variantes protocole/hôte

cr0x@server:~$ for u in http://example.com https://example.com http://www.example.com https://www.example.com; do echo "== $u =="; curl -sI "$u" | egrep -i 'HTTP/|location:|canonical'; done
== http://example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://example.com ==
HTTP/2 301
location: https://www.example.com/
== http://www.example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://www.example.com ==
HTTP/2 200

Ce que cela signifie : Idéal : trois variantes redirigent en 301 vers le canonique, le canonique retourne 200. Pas de boucles, pas de 200 sur une non‑canonique.

Décision : Si une non‑canonique retourne 200, vous avez besoin de redirections à la périphérie. Si vous voyez 302, changez en 301 sauf si c’est une migration temporaire.

Tâche 2 : Détecter les chaînes de redirections (un seul saut)

cr0x@server:~$ curl -sIL http://example.com | awk 'BEGIN{c=0} /^HTTP/{c++; print "Hop " c ": " $0} /^location:/{print "  " $0}'
Hop 1: HTTP/1.1 301 Moved Permanently
  location: https://example.com/
Hop 2: HTTP/2 301
  location: https://www.example.com/
Hop 3: HTTP/2 200

Ce que cela signifie : Trois sauts. Ce n’est pas catastrophique, mais c’est négligent et lent à grande échelle.

Décision : Réduisez en une seule redirection : HTTP+non-www doit aller directement vers HTTPS+www (ou votre canonique choisi).

Tâche 3 : Vérifier que la balise canonical correspond à l’URL finale

cr0x@server:~$ curl -s https://www.example.com/some-post/ | grep -i '<link rel="canonical"' | head -n 1
<link rel="canonical" href="https://example.com/some-post/" />

Ce que cela signifie : La page est servie sur www mais le canonical pointe vers le non-www. C’est une contradiction.

Décision : Corrigez les réglages « Adresse du site (URL) » de WordPress et/ou les paramètres du plugin SEO pour que le canonical utilise l’hôte canonique. Assurez‑vous aussi que les URLs codées en dur dans le thème sont corrigées.

Tâche 4 : Vérifier le comportement du slash final sur un article

cr0x@server:~$ curl -sI https://www.example.com/some-post | egrep -i 'HTTP/|location:'
HTTP/2 301
location: https://www.example.com/some-post/

Ce que cela signifie : Pas de slash redirige vers slash. Bien (si le slash est votre politique).

Décision : Assurez‑vous que ce comportement est cohérent sur articles, pages et catégories. L’incohérence engendre des duplicata.

Tâche 5 : Vérifier le comportement du slash final sur une catégorie

cr0x@server:~$ curl -sI https://www.example.com/category/widgets | egrep -i 'HTTP/|location:'
HTTP/2 200

Ce que cela signifie : La catégorie sans slash retourne 200. Si /category/widgets/ retourne aussi 200, vous avez des duplicata.

Décision : Décidez d’une règle et appliquez‑la (typiquement le slash). Configurez les règles de réécriture nginx/Apache et vérifiez la structure des permaliens WordPress.

Tâche 6 : Repérer les duplicata `index.php`

cr0x@server:~$ curl -sI https://www.example.com/index.php | egrep -i 'HTTP/|location:'
HTTP/2 200

Ce que cela signifie : Votre page d’accueil est accessible via /index.php. C’est un duplicata classique.

Décision : Ajoutez une redirection 301 de /index.php vers / au niveau du serveur web (ou la redirection canonique de WordPress, mais le niveau serveur est plus propre).

Tâche 7 : Vérifier les en-têtes pour le cache des redirections (pièges CDN)

cr0x@server:~$ curl -sI http://example.com/some-post/ | egrep -i 'HTTP/|location:|cache-control:|age:|via:'
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/some-post/
cache-control: max-age=3600
age: 3540
via: 1.1 varnish

Ce que cela signifie : La redirection est mise en cache pour une heure et a déjà un âge. Ça va si c’est correct ; dangereux si c’est faux car ça persiste.

Décision : Si vous changez activement les règles canoniques, réduisez le TTL de cache des redirections temporairement ou purgez les caches edge après les modifications.

Tâche 8 : Vérifier les URLs du sitemap pour l’hôte/protocole canonique

cr0x@server:~$ curl -s https://www.example.com/sitemap_index.xml | head -n 20
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>http://example.com/post-sitemap.xml</loc>
    <lastmod>2025-12-01T12:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Ce que cela signifie : Le sitemap annonce des URLs http://example.com. C’est une blessure auto‑infligée.

Décision : Corrigez les URLs du site WordPress, les paramètres du plugin SEO, et assurez‑vous que le générateur de sitemap utilise HTTPS+hôte canonique.

Tâche 9 : Crawler pour liens internes non canoniques (rapide et sale)

cr0x@server:~$ curl -s https://www.example.com/ | grep -Eo 'href="https?://[^"]+"' | head
href="http://example.com/about/"
href="https://example.com/contact/"
href="https://www.example.com/blog/"

Ce que cela signifie : La page d’accueil contient des liens internes absolus mélangés (http et non‑www). Cela continue à générer des duplicata.

Décision : Mettez à jour l’URL du site WordPress, corrigez les templates du thème, et lancez un search/replace dans la base pour les URLs absolues legacy.

Tâche 10 : Auditer les URLs configurées dans WordPress via WP-CLI

cr0x@server:~$ wp option get siteurl && wp option get home
https://example.com
https://example.com

Ce que cela signifie : WordPress pense que le canonique est le non‑www.

Décision : Si votre canonique choisi est www, définissez les deux options sur https://www.example.com, puis assurez‑vous que les redirections sont alignées.

Tâche 11 : Corriger home/siteurl de WordPress en toute sécurité (et savoir ce que vous venez de changer)

cr0x@server:~$ wp option update home 'https://www.example.com' && wp option update siteurl 'https://www.example.com'
Success: Updated 'home' option.
Success: Updated 'siteurl' option.

Ce que cela signifie : WordPress va générer les URLs canoniques et les liens internes en utilisant www (si les thèmes/plugins s’y conforment).

Décision : Retestez immédiatement les balises canonical et la sortie du sitemap. Puis purgez les caches (cache de page + CDN) pour que de vieux HTML n’ait plus de hosts mélangeants.

Tâche 12 : Trouver des URLs de contenu mixtes / ancien hôte dans la base (vérification ponctuelle)

cr0x@server:~$ wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://example.com/%' LIMIT 5;"
+----+-----------------------------+
| ID | post_title                  |
+----+-----------------------------+
| 12 | About Us                    |
| 87 | How to Choose a Widget      |
| 91 | Pricing                     |
+----+-----------------------------+

Ce que cela signifie : Des liens en dur legacy existent dans le contenu des posts. Les redirections attraperont les utilisateurs, mais les crawlers découvriront toujours des URLs non canoniques.

Décision : Lancez un search/replace prudent (avec prise en charge de la sérialisation). Préférez le search-replace de WP-CLI et testez d’abord sur une sauvegarde.

Tâche 13 : Effectuer un search/replace sûr pour la sérialisation sur hôte/protocole

cr0x@server:~$ wp search-replace 'http://example.com' 'https://www.example.com' --all-tables --dry-run
Success: Made 128 replacements.

Ce que cela signifie : Le mode dry run montre combien de remplacements seraient effectués, sans modifier les données.

Décision : Si les remplacements semblent raisonnables, relancez sans --dry-run. Si le nombre fait peur, restreignez la portée et inspectez des échantillons d’abord.

Tâche 14 : Valider que les directives robots ne vous combattent pas

cr0x@server:~$ curl -sI https://www.example.com/some-post/ | egrep -i 'x-robots-tag:|HTTP/'
HTTP/2 200

Ce que cela signifie : Pas d’en-tête X-Robots-Tag. OK.

Décision : Si vous voyez X-Robots-Tag: noindex sur des pages canoniques, arrêtez et corrigez cela avant toute autre chose. Vous ne pouvez pas canonicaliser pour sortir d’un « on a dit à Google de ne pas indexer ».

Tâche 15 : Vérifier la config du serveur pour les redirections canoniques (nginx)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'server_name|return 301|rewrite' | head -n 30
42:    server_name example.com;
47:    return 301 https://www.example.com$request_uri;
88:    server_name www.example.com;

Ce que cela signifie : Il y a un bloc serveur dédié redirigeant le non‑www vers www.

Décision : Confirmez que la redirection s’applique aux vhosts HTTP et HTTPS. Assurez‑vous aussi qu’elle ne cause pas un second saut (voir Tâche 2).

Tâche 16 : Confirmer qu’Apache n’effectue pas la négociation MultiViews « utile »

cr0x@server:~$ apachectl -M 2>/dev/null | grep -i negotiation
negotiation_module (shared)

Ce que cela signifie : La négociation de contenu est activée ; si MultiViews est activé, Apache peut mapper plusieurs URLs vers la même ressource de façon surprenante.

Décision : Dans les vhosts WordPress, désactivez MultiViews sauf si vous avez une raison spécifique. Ça cause un routage dupliqué bizarre et un débogage pénible.

Paramètres WordPress qui sabotent discrètement la canonicalisation

1) Désaccord « Adresse WordPress » vs « Adresse du site »

Dans Réglages → Général, WordPress a deux champs URL :

WordPress Address (URL) (siteurl) : où se trouvent les fichiers core de WordPress.
Site Address (URL) (home) : ce que les visiteurs doivent taper.

Ils devraient généralement correspondre. S’ils ne correspondent pas, vous pouvez déclencher des balises canonical mélangées, des liens internes mélangés et des redirections étranges.

2) Structure des permaliens et slash final

WordPress s’attend généralement à des slashes finaux pour les permaliens « pretty ». Mais votre serveur web pourrait ne pas. Si nginx est configuré pour traiter /post et /post/ comme séparés, vous pouvez finir avec les deux retournant 200 selon les règles de réécriture.

Faites ceci : choisissez une politique de slash final et forcez‑la au niveau serveur. Puis vérifiez que les redirections canoniques de WordPress ne la contrecarrent pas.

3) Plugins SEO : puissants, et parfois fautifs

Yoast, Rank Math et consorts gèrent généralement bien les balises canonical. Les échecs viennent souvent de :

L’URL du site changée mais le plugin a mis en cache l’ancienne base canonical.
Du code personnalisé qui filtre la sortie canonical de façon incorrecte.
Le plugin génère des canonicals pour des pages paginées, des archives ou des types de contenu personnalisés d’une façon qui entre en conflit avec votre plan d’indexation.

4) Archives qui dupliquent du contenu

Les archives ne sont pas intrinsèquement mauvaises. Mais elles deviennent souvent des duplicata quand :

Le thème affiche le contenu complet des posts sur les pages catégorie/tag (pas des extraits).
Les archives auteur/date reproduisent la liste du blog et n’offrent aucune valeur unique.
Les pages de pièce jointe sont peu fournies, avec le même titre et sans contexte.

Conseil personnel : si votre site n’est pas une publication avec des pages d’archives réellement utiles, définissez les archives auteur/date en noindex et redirigez les URLs de pièces jointes vers le fichier média ou le post parent.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Les versions www et non-www apparaissent dans les résultats Google

Cause racine : pas de contrainte d’hôte canonique à la périphérie ; liens internes ou sitemap fuient d’anciennes hostnames.

Correction : imposez un seul nom d’hôte avec 301 aux vhosts HTTP et HTTPS ; mettez à jour home/siteurl de WordPress ; régénérez le sitemap ; purgez les caches.

2) Symptom : « Duplicate, Google chose different canonical » dans Search Console

Cause racine : balises canonical qui contredisent les redirections, ou plusieurs variantes retournant 200 (slash/no-slash, index.php, paramètres).

Correction : rendez les redirections déterministes ; assurez‑vous que la balise canonical pointe vers l’URL finale ; supprimez les 200 duplicata ; normalisez les liens internes.

3) Symptom : Les classements fluctuent quotidiennement pour la même page

Cause racine : cannibalisation entre variantes d’URL ou pages d’archives presque dupliquées. Google change la variante en qui il a confiance.

Correction : consolidez les variantes avec des 301 ; envisagez noindex pour les archives à faible valeur ; assurez‑vous que le sitemap contient uniquement des URLs canoniques.

4) Symptom : Boucle de redirection entre http et https

Cause racine : mismatch de terminaison SSL : le CDN force HTTPS vers l’origine alors que l’origine force HTTP, ou WordPress pense être en HTTP derrière un proxy.

Correction : configurez correctement les en-têtes proxy (X-Forwarded-Proto), paramétrez WordPress pour les respecter, et implémentez les redirections au bon niveau (préférez la périphérie).

5) Symptom : Chaîne de redirections de 2–4 sauts sur chaque requête

Cause racine : règles séparées pour HTTP→HTTPS, non-www→www, et normalisation du slash appliquées en série entre CDN et origine.

Correction : regroupez en une seule redirection de canonicalisation. Faites en sorte que le premier point de contact (CDN ou LB) l’exécute en un seul saut.

6) Symptom : Le sitemap contient des URLs HTTP après une migration HTTPS

Cause racine : home/siteurl de WordPress non mis à jour, ou plugin ayant mis en cache la base URL, ou reverse proxy ne transférant pas correctement le schéma.

Correction : corrigez home/siteurl, videz les caches du plugin, vérifiez X-Forwarded-Proto et la détection SSL de WordPress.

7) Symptom : Les pages de catégorie surpassent les articles de façon inattendue

Cause racine : archives de catégorie indexables avec des titres/contenus similaires ; les liens internes et les fil d’Ariane boostent l’archive ; signaux canonicals faibles.

Correction : investissez dans les pages de catégorie en tant que vraies landing pages (contenu unique, curation), ou mettez‑les en noindex et focalisez‑vous sur les articles.

8) Symptom : Les pages de pièce jointe apparaissent comme résultats peu pertinents

Cause racine : les pages de pièce jointe de WordPress sont indexables par défaut sur certaines configurations ; le canonical peut pointer vers lui‑même.

Correction : redirigez les pages de pièce jointe vers le post parent ou le fichier média ; mettez‑les en noindex via un plugin SEO si nécessaire.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait « standardisé » sur HTTPS il y a des années. Tout le monde supposait que le site était HTTPS-only parce que le navigateur affichait un cadenas et que l’équipe marketing partageait uniquement des liens HTTPS. Couverture confortable classique.

Puis une nouvelle équipe sécurité a déployé un WAF en périphérie. Lors du déploiement, ils ont ajouté une règle pour contourner les redirections pour les « health checks » et le « bot traffic » afin de réduire la charge sur l’origine. Ce n’était pas malveillant. C’était juste une règle copiée-collée avec un wildcard user-agent qui a attrapé plus que prévu.

Résultat : les crawlers ont commencé à obtenir des réponses 200 sur HTTP pour de larges parties du site. Le HTML contenait toujours des liens HTTPS, donc les humains ne l’ont jamais remarqué. Google l’a remarqué immédiatement. Quelques semaines plus tard, Search Console s’est enflammé avec des duplicata et des mismatches de canonical. Les classements ont dérivé, pas chuté — pire, car on avait l’impression que le contenu « avait juste cessé de performer ».

La correction n’était pas un paramètre SEO magique. Il a fallu supprimer le contournement, imposer HTTP→HTTPS à la périphérie sans condition, et purger les caches. Leçon : ne supposez jamais que « nous avons migré vers HTTPS » signifie que le système applique actuellement HTTPS. Les hypothèses ne redirigent pas le trafic ; la configuration le fait.

Mini-récit 2 : L’optimisation qui a mal tourné

Un ingénieur orienté performance a vu des sauts de redirection et a décidé de « gagner du temps ». Il a modifié les règles nginx pour que les versions slash et sans‑slash retournent 200 afin d’éviter les redirections. Le temps de chargement a gagné quelques millisecondes, tout le monde s’est senti malin.

Deux mois plus tard, le trafic organique est devenu erratique. Certains articles apparaissaient, puis tombaient, puis réapparaissaient sous des URLs légèrement différentes. L’équipe a d’abord incriminé des mises à jour Google, puis la qualité du contenu, puis l’agence SEO. Personne n’a suspecté l’« optimisation ».

Quand nous avons enfin comparé les logs, nous avons trouvé Googlebot crawlant lourdement les deux variantes : /post et /post/. Les liens internes n’étaient pas cohérents non plus — certains générés par WordPress, d’autres codés en dur dans des templates, et ils n’étaient pas d’accord sur les slashes. L’index s’est rempli de duplicata, et l’équité des liens s’est scindée entre les variantes.

Nous avons rétabli une politique canonique unique, réintroduit la normalisation 301, et nettoyé les liens internes. La performance est restée correcte car l’edge prenait en charge les redirections ; l’origine n’a pas brûlé CPU à gérer des redirects. Morale : n’optimisez pas au point de supprimer les redirections qui préservent l’identité. Vous économisez une milliseconde et vous coûtez un trimestre de classements.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation faisait tourner WordPress derrière un CDN et un load balancer. Ils avaient une règle simple et ennuyeuse : un « test de normalisation d’URL » devait passer dans le CI avant de déployer toute configuration touchant l’edge ou les vhosts.

Le test n’était pas fancy. Il exécutait curl -I contre une douzaine d’URLs représentatives et vérifiait : un saut vers le canonique, codes d’état corrects, balise canonical correspondant à l’URL finale, et les URLs du sitemap commençant par la base canonique. C’est tout.

Un jour, un fournisseur a proposé d’activer une fonctionnalité « Automatic HTTPS Rewrites » plus un réglage séparé « Forwarding URL » pour forcer www. La combinaison a créé une chaîne et, dans un cas particulier, une boucle pour les archives paginées. Le test CI l’a détecté avant le déploiement.

Pas d’incident. Pas de salle de crise. Pas de « pourquoi Google indexe le staging ». Juste un check échoué et une correction rapide. L’ennui gagne. Le travail SEO le plus fiable ressemble à une bonne hygiène ops.

Listes de contrôle / plan étape par étape

Étape 1 : Déclarez la politique canonique (consignez‑la)

Protocole canonique : HTTPS
Hôte canonique : www ou non-www
Slash final : oui ou non (soyez cohérent)
Fichiers index : jamais canoniques
Politique des paramètres : quels paramètres autorisés, quels ignorés, quels bloqués/noindexés

Étape 2 : Implémentez des redirections en un seul saut à la périphérie/origine

Faites‑le le plus proche possible de l’utilisateur (CDN/LB), mais assurez‑vous que c’est déterministe et testable. Si vous ne pouvez pas le faire à la périphérie, faites‑le en nginx/Apache.

Exemple de pattern nginx (conceptuel)

Restez simple : un bloc serveur pour l’hôte non canonique renvoie 301 vers le canonique. Un autre pour le canonique sert le contenu. Puis appliquez les règles de slash soigneusement pour ne pas créer de 200 duplicata.

Étape 3 : Faire en sorte que WordPress génère des URLs canoniques de façon cohérente

Définissez home et siteurl sur la base canonique.
Vérifiez que les balises canonical correspondent à la base canonique.
Corrigez les liens absolus codés en dur dans le thème.
Search/replace des URLs legacy dans le contenu (avec précaution).

Étape 4 : Corriger les sitemaps et les flux

L’index sitemap et les sitemaps enfants doivent lister uniquement des URLs canoniques.
Si vous avez changé la base URL, régénérez les sitemaps et purgez les caches.
Vérifiez les flux RSS/Atom pour d’anciennes hostnames si vous en dépendez.

Étape 5 : Contrôler l’indexabilité des archives pour réduire la cannibalisation

Si les pages catégorie/tag sont des pages d’atterrissage stratégiques, investissez dans un contenu unique et une structure
Si elles ne le sont pas, mettez‑les en noindex et concentrez le crawl sur articles/pages
Désactivez ou noindexez les archives auteur/date sauf si elles apportent une valeur unique
Redirigez ou noindexez les pages de pièces jointes

Étape 6 : Re-tester et surveiller

Relancez les Tâches 1–9 après les changements.
Surveillez les logs pour des réponses 200 sur des variantes non canoniques.
Suivez Search Console pour voir les rapports de duplication diminuer sur des semaines (pas des heures).

Blague n°2 : Si votre site a cinq URLs canoniques, félicitations — vous avez inventé un système distribué. Malheureusement, c’est votre site marketing.

FAQ

1) Dois‑je choisir www ou non‑www pour WordPress ?

Les deux conviennent. Choisissez‑en un et appliquez‑le avec des redirections 301 et des liens internes cohérents. Opérationnellement, www peut être pratique pour les CDN et la gestion des cookies, mais ce n’est pas obligatoire.

2) Les balises canonical suffisent‑elles pour résoudre le contenu dupliqué ?

Non. Les balises canonical sont des indices. Pour les problèmes protocole/hôte/slash, utilisez des redirections 301 plus des liens internes cohérents. Les canonicals aident à régler les cas limites comme les paramètres et la syndication.

3) Pourquoi je vois encore des duplicata après avoir corrigé les redirections ?

Parce que les chemins de découverte persistent : liens internes, sitemaps, backlinks externes, pages mises en cache et anciennes données de crawl. Corrigez les sources (liens internes et sitemaps) et laissez le temps faire son effet. Vérifiez aussi que les variantes non canoniques retournent bien 301 et pas 200.

4) Dois‑je forcer les slashes finaux ?

Si vous utilisez les permaliens pretty de WordPress, oui : forcer une cohérence de slash final est généralement plus simple. L’essentiel est la cohérence et les redirections en un seul saut. Ne servez pas les deux.

5) Les paramètres UTM créent‑ils du contenu dupliqué ?

Ils peuvent créer des URLs dupliquées. Typiquement, vous les autorisez pour l’analytics mais assurez‑vous que le canonical pointe vers l’URL propre, et évitez l’indexation des variantes de paramètres. Ne bloquez pas les UTMs par redirection à moins de bien comprendre vos besoins de suivi de campagne.

6) En quoi les CDN aggravent‑ils le problème ?

Les CDN peuvent mettre en cache des redirections, séparer la clé de cache par hôte/protocole, ou appliquer des réécritures « utiles » qui entrent en conflit avec le comportement d’origine. La solution est de rendre explicites les règles de canonicalisation et de les tester à la périphérie et à l’origine.

7) Pourquoi WordPress redirige‑t‑il parfois de façon inattendue ?

WordPress a sa propre logique de redirection canonique qui tente de deviner le permalink correct. Si vos règles de réécriture serveur ou vos paramètres d’URL du site sont incohérents, WordPress peut ajouter des sauts ou rediriger vers le mauvais hôte. Corrigez d’abord la politique URL sous‑jacente.

8) Dois‑je mettre en noindex les archives tag/catégorie pour éviter la cannibalisation ?

Si ces pages n’apportent pas de valeur unique, oui : le noindex est souvent la solution la plus propre. Si elles sont des pages importantes, laissez‑les indexables mais rendez‑les vraiment distinctes (contenu unique, curation, bons titres).

9) Quel code de statut dois‑je utiliser : 301 ou 308 ?

301 est largement supporté et compris. 308 est acceptable aussi (redirection permanente préservant la méthode), mais 301 reste le choix conservateur pour la compatibilité étendue, surtout avec des outils anciens.

10) Puis‑je corriger cela uniquement dans WordPress sans toucher la config serveur ?

Vous pouvez améliorer les balises canonical et les liens internes dans WordPress, mais la normalisation hôte/protocole doit se faire au serveur ou à la périphérie. Le faire en PHP marche jusqu’à ce que la mise en cache, les proxies ou les plugins changent le comportement sous charge.

Conclusion : prochaines étapes qui font vraiment la différence

Si vous ne faites rien d’autre cette semaine, faites ces trois choses :

Choisissez et documentez une politique d’URL canonique (HTTPS + hôte choisi + style de slash final choisi).
Appliquez‑la avec des redirections 301 en un seul saut à la périphérie ou au serveur web, pour les écouteurs HTTP et HTTPS.
Empêchez WordPress de fuiter des liens non canoniques : définissez home/siteurl, corrigez les balises canonical, régénérez les sitemaps, et nettoyez les liens internes absolus.

Puis relancez les commandes des tâches, en particulier celles qui détectent les 200 sur les variantes et les mismatches de balise canonical. Quand votre site a une identité unique, les classements arrêtent de jouer aux chaises musicales. Et votre futur vous aura moins de tickets « pourquoi Google indexe les deux versions », ce qui est le luxe discret de bien faire les choses.