Comment migrer son site WordPress sans perdre son référencement ?
Migrer un site WordPress sans perdre son référencement consiste à reproduire le site à l’identique sur sa nouvelle destination (hébergeur, domaine ou structure d’URL), à valider cette copie sur un environnement de staging, puis à basculer le DNS en mettant en place des redirections 301 vers chaque URL déplacée — l’étape la plus souvent négligée.
Migrer WordPress sans perdre son référencement, c’est valider une copie exacte du site sur un environnement de staging avant tout basculement, puis rediriger en 301 chaque URL qui change réellement d’adresse.
Que préparer avant de migrer son site WordPress ?
Une migration WordPress recouvre plusieurs situations différentes : changer d’hébergeur en gardant le même domaine, changer de nom de domaine, ou modifier la structure des URL lors d’une refonte. Le niveau de risque SEO n’est pas le même selon le cas : changer d’hébergeur seul est la migration la moins risquée, car aucune URL ne change ; changer de domaine ou de structure d’URL impose des redirections sur l’intégralité du site.
Exportée depuis le sitemap XML ou la Search Console avant tout changement.
Fichiers et base de données, voir notre guide dédié.
Programmer la bascule DNS en dehors des pics d’activité du site.
Pourquoi sauvegarder avant toute migration ?
Une migration reste l’une des opérations qui comporte le plus de risques de casse totale du site : erreur d’import de base de données, fichier de configuration mal transféré, ou plugin incompatible avec le nouvel hébergement. Disposer d’une sauvegarde complète du site d’origine avant de commencer permet de revenir instantanément à la version fonctionnelle en cas de problème, plutôt que de tenter une réparation en urgence pendant que le site réel est hors ligne.
Comment tester la migration sur un environnement de staging ?
La règle centrale d’une migration réussie : ne jamais basculer le trafic réel avant d’avoir validé une copie complète du site sur sa nouvelle destination. Un environnement de staging permet de vérifier, avant toute bascule, que le site fonctionne à l’identique une fois transféré.
- 1. Copier le site vers la nouvelle destination sans le rendre publicAccessible uniquement par une URL temporaire ou protégée par mot de passe.
- 2. Vérifier l’affichage de toutes les pages principalesAccueil, pages clés, articles récents et formulaires de contact.
- 3. Tester les fonctionnalités dynamiquesFormulaires, boutique en ligne si présente, espace membre.
- 4. Contrôler les temps de chargementUne migration est aussi l’occasion de vérifier que le cache est bien reconfiguré sur la nouvelle destination.
Comment gérer le changement de DNS sans coupure ?
Le DNS est ce qui indique aux navigateurs où trouver le site : le modifier est l’étape qui rend la migration visible publiquement, et elle ne se fait pas instantanément dans le monde entier.
| Étape | Action |
|---|---|
| Avant la bascule | Réduire le TTL (durée de vie) des enregistrements DNS à 300 secondes, plusieurs heures à l’avance |
| Pendant la bascule | Mettre à jour l’enregistrement pointant vers la nouvelle destination |
| Après la bascule | Vérifier la propagation avec un outil de contrôle DNS, puis remettre un TTL standard |
La propagation DNS peut prendre de quelques minutes à 48 heures selon les fournisseurs d’accès : c’est pour cette raison qu’il faut garder l’ancienne destination active et fonctionnelle pendant cette période, plutôt que de la désactiver immédiatement après la bascule.
Comment mettre en place les redirections 301 ?
La redirection 301 (redirection permanente) indique à Google et aux visiteurs qu’une page a changé d’adresse de façon définitive, en transférant l’essentiel de sa valeur de référencement vers la nouvelle URL. C’est l’étape qui protège le classement acquis par chaque page.
- 1. Ne rediriger que les URL qui changent réellementUne migration d’hébergeur seule, sans changement de domaine ni de structure, ne nécessite généralement aucune redirection.
- 2. Créer une redirection 301 pour chaque ancienne URL vers son équivalent exactJamais une redirection en masse de tout le site vers la page d’accueil, qui fait perdre la totalité du référencement acquis page par page.
- 3. Mettre à jour le sitemap XML avec les nouvelles URLPuis le soumettre à nouveau dans Google Search Console.
- 4. Conserver les redirections actives durablementPlusieurs mois au minimum, le temps que Google réindexe l’ensemble des nouvelles adresses.
La redirection 302 (temporaire) ne transfère pas le référencement de la page d’origine : utiliser une 302 pour une migration définitive est une des causes les plus fréquentes de perte de classement après un changement d’adresse.
Que vérifier juste après la migration ?
Purger le cache
Un cache non vidé peut continuer à afficher l’ancienne version du site après une migration pourtant réussie.
Vérifier le certificat SSL
Le certificat SSL doit être actif sur la nouvelle destination avant la bascule pour éviter un avertissement de sécurité.
Contrôler robots.txt
Un fichier robots.txt copié depuis un environnement de test peut bloquer l’indexation de tout le site en production.
Suivre la Search Console
Surveiller les erreurs d’exploration et le nombre de pages indexées pendant les semaines suivant la migration.
Quelles erreurs font perdre du référencement lors d’une migration ?
Bonnes pratiques
- Redirection 301 individuelle pour chaque URL déplacée.
- Copie testée en staging avant toute bascule réelle.
- Ancienne destination conservée active plusieurs jours.
Erreurs fréquentes
- Redirection en masse de tout le site vers la page d’accueil.
- Fichier robots.txt de test laissé actif en production.
- Contenu HTTP mixte (images ou scripts) après passage en HTTPS.
À ne pas confondre avec une refonte complète du site : la migration change l’infrastructure sans toucher au design ni au contenu, tandis qu’une refonte modifie souvent la structure des URLs elle-même, ce qui suit une méthode différente.
Ce que nous observons chez les projets que nous accompagnons
Voici un exemple représentatif de notre pratique, sans donnée client ni chiffre inventé.
Le robots.txt de staging, l’erreur silencieuse la plus coûteuse
Chez Amari Agency, l’incident le plus difficile à repérer après une migration n’est pas une page cassée visible à l’œil nu, mais un fichier robots.txt copié depuis l’environnement de staging qui bloque l’exploration de Google sur le site pourtant en ligne et fonctionnel. Le site reste accessible aux visiteurs, mais son trafic organique s’effondre en quelques semaines sans erreur apparente. C’est pourquoi ce fichier fait partie de notre liste de vérification systématique juste après chaque bascule, avant même de considérer la migration comme terminée.
Quels contenus lire ensuite ?
Ces ressources complètent ce guide sans cibler la même requête :
Questions fréquentes sur la migration WordPress
Combien de temps met Google à traiter les redirections 301 ?
Généralement quelques jours à quelques semaines pour les pages les plus visitées, davantage pour les pages profondes du site ; c’est pourquoi les redirections doivent rester actives plusieurs mois.
Faut-il rediriger les URL si seul l’hébergeur change ?
Non, tant que le nom de domaine et la structure des URL restent identiques, aucune redirection n’est nécessaire : seule la destination technique du DNS change.
Peut-on migrer un site sans coupure de service ?
Oui, en gardant l’ancienne destination active jusqu’à la propagation complète du DNS, et en ne coupant l’ancien hébergement qu’après avoir confirmé que tout le trafic passe bien par la nouvelle destination.
Que faire si le trafic chute après une migration ?
Vérifier en priorité le fichier robots.txt, la présence effective des redirections 301 et l’absence de blocage d’indexation dans les réglages de visibilité de WordPress (Réglages → Lecture).
Faut-il resoumettre le sitemap après une migration ?
Oui, systématiquement dans Google Search Console, même si l’adresse du sitemap n’a pas changé, pour accélérer la réexploration des pages concernées.