Redirections 301 : migration de domaine, refonte URL, HTTPS/www

Une migration mal redirigée, c'est des mois (parfois des années) de travail SEO qui partent à la poubelle en un week-end. Cette page rassemble les recettes éprouvées pour une bascule propre sur nos hébergements Plesk + Apache : forcer HTTPS, unifier www et apex, changer de domaine, refondre une arborescence. Avec les pièges à éviter, les commandes de test, et ce qu'il faut faire côté Google Search Console après coup.

301, 302, 307, 308 : lequel choisir ?

Quatre codes de redirection, des comportements subtilement différents. Pour le SEO, la réponse courte tient en un mot : 301.

• 301 Moved Permanently : redirection définitive. Transfère le jus SEO vers la nouvelle URL, mise en cache agressive par les navigateurs et les moteurs. Méthode par défaut pour toute migration.
• 302 Found, redirection temporaire. Google finit par transférer le ranking après quelques semaines s'il constate qu'elle reste en place, mais c'est du temps perdu. À réserver aux vraies redirections temporaires (maintenance, AB testing).
• 307 Temporary Redirect — variante stricte de la 302 : impose de conserver la méthode HTTP (un POST reste un POST). Usage API plutôt que SEO.
• 308 Permanent Redirect : équivalent strict de la 301 (conserve la méthode HTTP). Peu utilisé en pratique sur les sites web, bien supporté mais la 301 reste le standard de fait.

Forcer HTTPS

Règle à placer tout en haut du .htaccess, avant toute autre RewriteRule :

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Sur Plesk, la case Hosting Settings > Permanent SEO-safe 301 redirect from HTTP to HTTPS fait la même chose sans toucher au .htaccess. Choisissez l'un ou l'autre, pas les deux (risque de double redirection ou de boucle).

RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

www vers apex (ou l'inverse)

Le moteur voit www.exemple.fr et exemple.fr comme deux hôtes différents. Il faut en choisir un, canonique, et rediriger l'autre.

Méthode Plesk

Websites & Domains > Hosting Settings > Preferred domain. Trois options : www.domain.tld, domain.tld sans www, ou pas de redirection. Plesk applique la 301 automatiquement.

Méthode htaccess

# www vers apex (exemple.fr canonique)
RewriteCond %{HTTP_HOST} ^www\.exemple\.fr$ [NC]
RewriteRule ^(.*)$ https://exemple.fr/$1 [L,R=301]

# Apex vers www (si vous préférez l'inverse)
RewriteCond %{HTTP_HOST} ^exemple\.fr$ [NC]
RewriteRule ^(.*)$ https://www.exemple.fr/$1 [L,R=301]

Pensez à ajouter le sous-domaine non-canonique dans votre certificat SSL (Let's Encrypt côté Plesk couvre les deux par défaut si vous cochez Include www).

Changement de domaine complet

Cas classique : rebranding, rachat, fusion. ancien.fr doit rediriger vers nouveau.fr en conservant chaque URL.

Méthode Plesk (recommandée)

1. Créez nouveau.fr comme domaine principal (voir doc « Ajouter un domaine dans Plesk »).
2. Ajoutez ancien.fr en Domain Alias pointant vers nouveau.fr, puis cochez Redirect with HTTP 301 dans les options de l'alias.
3. Plesk route automatiquement chaque URL de l'ancien domaine vers la même URL sur le nouveau, en 301.

Méthode htaccess

Si vous gardez les deux comme domaines séparés (par exemple parce que chacun a son certificat propre), placez sur l'ancien :

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^(.*)$ https://nouveau.fr/$1 [R=301,L]
</IfModule>

Une seule ligne, et chaque chemin est préservé : ancien.fr/blog/article-x part vers nouveau.fr/blog/article-x.

Refonte d'URL : table de correspondance

La vraie difficulté : l'arborescence change. /produit/123 devient /p/slug-produit, /blog/ devient /actualites/, etc. Il faut une table de correspondance ancien → nouveau.

Peu d'URLs (moins de 50)

Directement dans le .htaccess, une ligne par URL :

Redirect 301 /ancienne-page.html /nouvelle-page
Redirect 301 /produits/vieux-slug /p/nouveau-slug
Redirect 301 /contact.php /contact

Beaucoup d'URLs

• WordPress : plugin Redirection (gratuit, maintenu par John Godley). Import CSV, logs des 404, regex. C'est l'outil de référence.
• Autre CMS ou sites custom : une map Nginx côté reverse proxy est plus rapide qu'Apache pour des milliers de règles. Ouvrez un ticket Datacampus pour qu'on l'ajoute à la config du vhost.
• Patterns réguliers : RedirectMatch avec regex évite d'écrire une ligne par URL.

Wildcards avec RedirectMatch

# Tout /blog/xxx devient /actualites/xxx
RedirectMatch 301 ^/blog/(.*)$ /actualites/$1

# Tout ce qui finit en .html perd son extension
RedirectMatch 301 ^/(.+)\.html$ /$1

Conserver les paramètres GET

Piège subtil : par défaut, RewriteRule perd la query string si la nouvelle URL contient déjà un ?. Pour préserver ?utm_source=xxx et autres paramètres :

# Le ? final + le flag NE (No Escape) conservent la query string
RewriteRule ^old/?$ /new? [R=301,L,NE]

# Pour ajouter une règle qui injecte en plus un paramètre
RewriteRule ^old/?$ /new?ref=migration [R=301,L,QSA]

Le flag QSA (Query String Append) concatène les paramètres d'origine aux nouveaux. Le NE empêche Apache de réencoder les caractères spéciaux.

Piège : les chaînes de redirections

Le cas typique en production : http://www.exemple.fr/old redirige vers https://www.exemple.fr/old, qui redirige vers https://exemple.fr/old, qui redirige vers https://exemple.fr/new. Quatre sauts pour une seule URL. Les navigateurs tolèrent, Google pénalise au-delà de trois sauts, et chaque étape ajoute de la latence.

Règle d'or : chaque redirection doit pointer directement vers l'URL finale (HTTPS + domaine canonique + nouvelle arbo), jamais vers une URL intermédiaire qui va à son tour rediriger.

Tester avec curl

Avant d'annoncer une migration à Google, vérifiez chaque URL clé en ligne de commande. Pas de cache navigateur qui fausse le résultat :

# Vérifier une redirection simple
curl -I https://exemple.fr/ancienne-url
# Doit répondre :
# HTTP/2 301
# location: https://exemple.fr/nouvelle-url

# Suivre la chaîne complète (détecter les sauts en trop)
curl -IL https://exemple.fr/ancienne-url

# Tester sans suivre le cache DNS (pratique sur une migration récente)
curl -I --resolve exemple.fr:443:10.0.20.99 https://exemple.fr/

Automatisez le test en passant un fichier d'URLs à curl en boucle pour valider les 100 URLs les plus importantes du site en une commande.

Après la migration : indispensables

1. Google Search Console : pour un changement de domaine complet, utilisez l'outil Change of Address (Paramètres > Modification de l'adresse). Google accélère le transfert du ranking vers le nouveau domaine. Vérifiez les deux propriétés (ancien + nouveau) au préalable.
2. Sitemap XML, soumettez le nouveau sitemap, gardez l'ancien en 301 pendant plusieurs mois pour que Googlebot recrawl les anciennes URLs.
3. Liens externes importants — mettez à jour ce que vous contrôlez : signatures emails, profils réseaux sociaux, Google Business Profile, fiches partenaires, backlinks stratégiques. Les autres finiront par passer via la 301, mais autant leur éviter un hop.
4. Durée de vie des redirections : gardez-les en place au minimum un an, idéalement permanent. Google continue de crawler d'anciennes URLs pendant des années, et les liens externes non corrigés vivent eux aussi longtemps.
5. Monitoring 404, surveillez les logs pendant les premières semaines. Une URL oubliée dans la table de correspondance se révèle en quelques jours de trafic.

Redirections côté CDN (Cloudflare)

Si Cloudflare est devant votre Plesk (voir doc Cloudflare devant Plesk), les redirections peuvent être servies directement en edge, avant de toucher l'origine. Plus rapide, plus scalable :

• Page Rules : idéal pour une dizaine de redirections ponctuelles (forcer HTTPS, www vers apex, quelques 301 critiques).
• Bulk Redirects, conçu pour les grosses tables : import CSV jusqu'à 100 000 règles par compte, matching exact ou préfixe. Parfait pour les migrations WordPress massives.
• Redirect Rules — regex et variables dynamiques, équivalent d'un RewriteRule mais servi en edge.

Règle pratique : redirections structurelles (HTTPS, canonique) côté Cloudflare, redirections applicatives (refonte, contenus spécifiques) côté CMS ou .htaccess. Évitez de dupliquer entre les deux.

Checklist de migration

• Crawl Screaming Frog de l'ancien site, export de toutes les URLs indexées.
• Table de correspondance ancien → nouveau, validée par un humain, une ligne par URL critique.
• Règles de redirection écrites en R=302, testées avec curl -IL.
• Bascule en R=301.
• Sitemap XML mis à jour, soumis dans la Search Console.
• Outil Change of Address activé (si changement de domaine complet).
• Liens internes du site pointant directement vers les nouvelles URLs (pas via 301).
• Monitoring des 404 en place pour les 3 premiers mois.
• Redirections conservées au moins un an.

Une migration réussie, c'est une migration que personne ne remarque : le trafic organique reste stable, les classements bougent de manière marginale, et l'équipe support ne reçoit aucun mail « je ne trouve plus votre page ». Ça se joue sur la préparation, pas sur la bascule elle-même.