Objectif
Rediriger durablement un ancien domaine vers un nouveau site WordPress en conservant autant que possible chaque chemin d’URL, en évitant les chaînes/boucles, en maintenant HTTPS sur l’ancien domaine et en validant les pages stratégiques ainsi que les 404 avant d’abandonner l’ancien hébergement.
Prérequis
- Contrôle DNS et certificat TLS des deux domaines.
- Inventaire des URLs importantes : sitemap, Search Console, analytics, backlinks et pages métier.
- Table de correspondance lorsque la structure des URLs change.
- Accès Apache/Nginx/hébergeur pour créer une vraie redirection serveur.
- Sauvegarde WordPress et configuration de l’ancien hébergement.
Procédure pas à pas
Inventorier les URLs qui doivent survivre
Exportez les URLs indexées, les pages recevant du trafic et les backlinks importants. Classez-les en chemin identique, chemin changé, contenu fusionné ou contenu supprimé. Cette table devient la référence de test et évite de découvrir après migration que des pages stratégiques ont été envoyées vers une destination générique.
- Chaque URL importante possède une cible finale définie.
Préparer le nouveau site avant le changement
Vérifiez que les pages cibles existent, répondent en 200 et possèdent leurs propres canonical/sitemap. Si WordPress change aussi de domaine principal, mettez à jour home/siteurl et les références internes avec un outil compatible avec les données sérialisées. Testez le nouveau domaine avant de toucher à l’ancien.
wp option get home
wp option get siteurl
- Le nouveau domaine est autonome et les cibles répondent correctement.
Maintenir DNS et HTTPS de l’ancien domaine
Faites pointer l’ancien domaine vers le serveur qui exécutera les 301. Installez ou renouvelez son certificat TLS. Même si aucun contenu n’y sera hébergé, ce endpoint doit rester disponible pour les utilisateurs, robots et backlinks en https://.
openssl s_client -connect old.example.tld:443 -servername old.example.tld </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
- L’ancien domaine répond en HTTPS sans erreur certificat.
Créer la redirection globale lorsque les chemins sont identiques
Si l’arborescence est conservée, utilisez une règle serveur qui renvoie vers le nouveau host en gardant le path et la query string. Sur Apache, Redirect permanent peut suffire pour un mapping simple ; mod_rewrite convient aux règles conditionnelles. Placez les règles hors des blocs WordPress susceptibles d’être réécrits.
Redirect permanent / https://new.example.tld/
- /ancienne-page/ aboutit directement à /ancienne-page/ sur le nouveau domaine.
Ajouter les exceptions de mapping
Pour les pages renommées ou fusionnées, placez les règles spécifiques avant la règle générale. Une page supprimée sans équivalent peut rester 404/410 plutôt que d’être redirigée artificiellement vers l’accueil. Documentez la logique afin que les exceptions ne deviennent pas incompréhensibles.
- Les pages stratégiques renommées vont vers leur contenu équivalent.
Tester codes et chaînes avant annonce
Utilisez curl sur un échantillon puis sur la liste complète avec un script. Vérifiez 301 initial, Location, destination finale 200 et absence de boucle. Testez http, https, www/non-www selon les anciennes variantes réellement utilisées.
curl -I https://old.example.tld/ancienne-page/
curl -IL https://old.example.tld/ancienne-page/
- Chaque URL testée atteint sa cible finale avec le minimum de sauts.
Mettre à jour les liens que vous contrôlez
Modifiez menus, profils sociaux, campagnes, signatures, fiches d’établissement et principaux backlinks que vous pouvez gérer. Les 301 restent indispensables pour les liens externes historiques, mais réduire les redirections internes améliore performance et maintenance.
- Le nouveau site ne continue pas à créer volontairement du trafic vers l’ancien domaine.
Mettre à jour Search Console et sitemaps
Ajoutez et validez les propriétés du nouveau domaine, soumettez le sitemap final et utilisez les mécanismes de changement d’adresse lorsque le scénario le permet. Surveillez indexation, erreurs et anciennes URLs. Ne supprimez pas immédiatement l’ancien domaine de vos outils.
- Les moteurs découvrent le nouveau domaine et les redirections sont visibles dans le suivi.
Surveiller 404 et conserver les 301 durablement
Analysez les 404 du nouveau site et les hits sur l’ancien domaine pendant plusieurs semaines. Ajoutez des mappings manquants uniquement lorsqu’une destination pertinente existe. Conservez les redirections et le domaine suffisamment longtemps ; les anciens backlinks peuvent rester actifs pendant des années.
- Les 404 utiles diminuent et les anciennes URLs importantes continuent de transmettre les visiteurs.
Validation
La procédure est validée lorsque :
- Les anciennes URLs importantes renvoient en 301 vers une cible pertinente et finale en 200.
- L’ancien domaine reste accessible en HTTPS sans avertissement.
- Aucune boucle ou chaîne de redirection inutile n’est détectée sur l’échantillon complet.
- Le sitemap et les liens internes du nouveau site utilisent exclusivement le nouveau domaine.
Retour arrière
- Restaurer la configuration serveur précédente de l’ancien domaine si les règles provoquent des boucles.
- Revenir temporairement à l’ancien DNS uniquement si l’ancien site est encore intact et que la migration doit être annulée.
- Ne supprimez pas la table de correspondance ni les preuves de tests pendant le rollback.
- Corriger une règle spécifique plutôt que retirer toutes les redirections si seul un sous-ensemble échoue.
Dépannage / erreurs fréquentes
- Le navigateur n’atteint jamais la 301 en HTTPS : corriger d’abord le certificat de l’ancien domaine.
- Toutes les pages vont à l’accueil : remplacer la redirection globale destructive par conservation de chemin/mappings.
- Boucle old ↔ new : vérifier WordPress home/siteurl, reverse proxy
- 301 fonctionne en HTTP mais pas HTTPS : l’ancien vhost 443 n’applique pas la même règle.
- Les moteurs conservent certaines anciennes URLs : vérifier la cible, canonical, sitemap et laisser le temps aux crawls.