Une migration site web mal préparée se repère immédiatement: pages en 404, formulaires qui n’envoient plus rien, positions SEO qui décrochent et parfois même des soucis d’e-mails. Sur WordPress, je traite ce sujet comme un chantier de précision: copier proprement, changer l’infrastructure au bon moment, puis vérifier chaque point sensible après la bascule. Cet article vous montre comment déplacer un site sans perdre le trafic ni transformer la mise en ligne en réparation d’urgence.
L’essentiel à retenir avant de déplacer un site
- Deux scénarios ne se traitent pas pareil : changer d’hébergement sans changer d’URL, ou migrer vers un nouveau domaine avec des redirections.
- Une sauvegarde complète et un environnement de test évitent la plupart des incidents évitables.
- Sur WordPress, un plugin suffit souvent pour un petit site, mais une boutique, un multisite ou un site sur mesure demandent plus de contrôle.
- Le SEO se protège avec des redirections 301, un sitemap mis à jour et un contrôle des pages qui répondent encore en 404.
- Les 72 premières heures après la bascule servent à vérifier le cache, le SSL, les formulaires, les médias et les e-mails.
Ce que vous migrez vraiment quand le site change d’hébergement
Quand je parle de migration, je ne pense jamais seulement aux fichiers. Je pense aussi à la base de données, aux médias, aux réglages du thème, aux extensions, aux tâches planifiées, aux formulaires, aux webhooks, au cache, au CDN et parfois aux boîtes mail si le domaine bouge en même temps. Le handbook WordPress distingue d’ailleurs clairement le simple changement de répertoire d’une vraie modification d’URL, et ce n’est pas un détail technique: chaque cas implique des actions différentes.
Le plus utile, à ce stade, est de séparer trois situations très différentes:
| Scénario | Ce qui change réellement | Risque principal |
|---|---|---|
| Même domaine, nouvel hébergeur | Serveur, DNS, versions PHP/MySQL, cache | Propagation DNS, incompatibilité serveur, performance dégradée |
| Nouveau domaine ou nouvelle structure d’URL | Adresses publiques, liens internes, indexation | Chute SEO si les redirections sont incomplètes |
| Changement de CMS ou de plateforme | Modèle de contenu, export/import, design, données techniques | Perte de champs, de mises en page ou de données sérialisées |
En pratique, c’est la première question que je pose avant d’ouvrir un outil: est-ce qu’on déplace seulement l’infrastructure, ou est-ce qu’on change aussi l’adresse et la manière dont le site est reconstruit? Une fois ce point tranché, le reste devient beaucoup plus rationnel.
Choisir la bonne méthode selon le contexte du site
Je ne recommande pas la même approche à un blog WordPress de 30 pages, à une boutique WooCommerce ou à un site avec beaucoup de personnalisations. Le bon choix dépend surtout du volume de données, du niveau de risque acceptable et de votre capacité à revenir en arrière si quelque chose casse.| Méthode | Pour quel cas | Atout principal | Limite à connaître | Budget indicatif |
|---|---|---|---|---|
| Plugin de migration | Petit ou moyen site WordPress | Rapide, accessible, copie fichiers + base | Limites de taille, options payantes, cas complexes | 0 à 150 € |
| Migration manuelle | Site technique, configuration spécifique, gros volume | Contrôle total | Plus longue, plus sensible aux erreurs humaines | Temps interne ou 300 à 1 200 € en freelance |
| Migration gérée par l’hébergeur | Changement de serveur sans équipe technique | Moins d’effort, parfois incluse dans l’offre | Dépend du support et du cadre imposé | Souvent inclus ou 50 à 300 € |
| Freelance ou agence | Site critique, e-commerce, multisite, changement de domaine | Audit, tests, plan de repli, suivi | Coût plus élevé | 800 à 5 000 € et plus selon la complexité |
Ma règle est simple: plus le site gagne de l’argent ou capte du trafic, plus je privilégie une méthode encadrée. Un plugin fait gagner du temps, mais il ne remplace ni les vérifications ni le diagnostic d’un site qui a déjà beaucoup d’historique. C’est précisément pour cela qu’il faut préparer la copie avant le jour J.
Préparer la copie et l’environnement de test
La préparation est la phase la moins visible, mais c’est elle qui évite les appels en urgence. Avant de toucher à la production, je fais toujours la même série d’actions, parce qu’elles réduisent la majorité des incidents post-migration.
- Inventorier ce qui doit suivre : contenus, pages, articles, produits, médias, formulaires, codes promo, menus, modèles, redirections, abonnements, tâches cron et intégrations externes.
- Créer une sauvegarde complète : fichiers, base de données, exports de la boutique si besoin, et idéalement une copie récupérable hors du serveur principal.
- Cloner le site sur un environnement de préproduction : un sous-domaine temporaire ou une URL de test permet de vérifier le rendu sans exposer la copie au public.
- Bloquer l’indexation de la copie : `noindex`, `robots.txt` adapté ou protection par mot de passe, pour éviter qu’un site de test se retrouve dans Google.
- Réduire le TTL DNS avant la bascule : quelques heures de TTL facilitent la propagation plus rapide au moment du changement.
- Vérifier la compatibilité serveur : version PHP, base de données, extensions, SSL, cache, mémoire disponible et éventuels prérequis de thèmes ou plugins.
Je teste ensuite les points critiques sur la copie: page d’accueil, formulaires, connexion, recherche interne, panier, checkout, médias, permaliens et pages 404. C’est aussi le bon moment pour détecter les problèmes de contenu sérialisé, ces données encodées par WordPress qui peuvent se casser si on fait un remplacement brut des URL.
Quand cette préproduction est propre, la bascule devient une opération maîtrisée plutôt qu’un saut dans le vide.
Le jour du basculement et les 72 heures suivantes
Le jour du passage en ligne, je choisis si possible une fenêtre de faible trafic. Sur un site éditorial, cela peut être une heure creuse; sur une boutique, je préfère un créneau où l’activité commerciale est plus basse, avec un plan clair pour les commandes en cours. Si le site reçoit des transactions, je mets parfois la production en pause courte pour éviter les données perdues.
Pour une migration avec changement d’URL, je m’aligne sur la logique de Google Search Central : les anciennes adresses doivent pointer vers les nouvelles avec des redirections 301, les URLs importantes doivent être testées, et le sitemap mis à jour doit être resoumis. Si vous passez simplement de HTTP à HTTPS, l’outil de changement d’adresse n’est pas nécessaire; en revanche, les redirections et la vérification du nouvel environnement restent indispensables.
Je garde aussi trois réflexes pendant les 72 premières heures:
- surveiller la propagation DNS et le trafic servi par l’ancien et le nouveau serveur;
- tester les formulaires de contact, les paniers, les emails transactionnels et les confirmations automatiques;
- contrôler les logs, les erreurs 404 et les pages qui chargent encore des ressources en HTTP ou depuis un ancien domaine.
Je n’éteins jamais l’ancien serveur trop vite. Tant que les logs n’indiquent pas un trafic stable et que les tests ne sont pas propres, l’ancien environnement reste un filet de sécurité. C’est aussi pour cela que les redirections doivent rester en place longtemps: Google recommande de les conserver au moins un an quand les URL changent, et côté utilisateur je préfère souvent les garder encore plus longtemps si le coût de maintenance reste raisonnable.
Les erreurs que je vois le plus souvent
La majorité des migrations ratées ne viennent pas d’un “gros bug”, mais d’une accumulation de petites omissions. Le tableau ci-dessous résume les erreurs que je retrouve le plus souvent, avec leur effet concret et la manière de les éviter.
| Erreur fréquente | Conséquence visible | Correction pragmatique |
|---|---|---|
| Remplacer les URL au hasard dans la base | Widgets cassés, options corrompues, pages mal reliées | Utiliser un outil compatible avec les données sérialisées ou WP-CLI |
| Oublier les enregistrements e-mail | Messages perdus, formulaires silencieux, authentification dégradée | Vérifier MX, SPF, DKIM, SMTP et les boîtes liées au domaine |
| Laisser `noindex` ou le mode maintenance actif | Site invisible pour les moteurs ou pour les visiteurs | Intégrer un contrôle de sortie dans la checklist de mise en ligne |
| Supprimer l’ancien site trop tôt | Impossible de revenir en arrière en cas de problème | Conserver l’ancien environnement le temps d’une vraie période de surveillance |
| Changer en même temps d’hébergeur, de thème et d’URL | Difficile d’identifier l’origine d’un dysfonctionnement | Découper le projet en étapes et valider chaque changement séparément |
J’ajoute un piège qui est souvent sous-estimé: le cache et le CDN. Un site peut sembler “cassé” alors qu’il affiche simplement une version figée. Avant de paniquer, je purge toujours les caches applicatifs, serveur et CDN, puis je reviens vérifier les pages sur plusieurs navigateurs et appareils.
Quand ces erreurs sont anticipées, on évite la plupart des régressions qui donnent mauvaise réputation à une migration.
Combien prévoir de temps et de budget
Le temps et le budget dépendent surtout du volume de contenu, du nombre d’intégrations et du niveau de dépendance SEO. Un petit site vitrine se migre souvent en quelques heures; une boutique ou un multisite peut facilement mobiliser une journée entière, parfois davantage si la structure doit être nettoyée.
| Type de site | Temps réaliste | Budget si vous déléguez | Niveau de vigilance |
|---|---|---|---|
| Petit site vitrine WordPress | 2 à 4 heures | 300 à 700 € | Moyen |
| Site vitrine avec blog, formulaires et quelques intégrations | Une demi-journée à une journée | 500 à 1 200 € | Élevé |
| Boutique WooCommerce ou espace membre | 1 à 2 jours | 900 à 3 000 € et plus | Très élevé |
| Multisite, refonte technique ou changement de plateforme | Plusieurs jours | 1 500 à 5 000 € et plus | Critique |
Le budget grimpe vite quand il faut réconcilier plusieurs contraintes à la fois: SEO historique, contenus multilingues, code sur mesure, données e-commerce, boîtes mail, DNS, sécurité et reprise de performance. Si vous faites appel à un freelance WordPress, je considère souvent qu’un budget de 300 à 1 200 € couvre déjà une migration simple à intermédiaire; pour un site stratégique, une agence ou un expert spécialisé est plus cohérent que de chercher le moins cher.
Autrement dit, le coût ne se mesure pas seulement au temps passé: il se mesure aussi au risque évité.
La première semaine qui confirme si tout tient
Je considère qu’une migration n’est vraiment terminée que quand la première semaine de surveillance est propre. À ce stade, je vérifie en priorité les éléments qui ont le plus d’impact sur le trafic et sur l’activité réelle du site.
- Les pages qui génèrent le plus de visites et les URLs qui possèdent des backlinks.
- Les erreurs 404, les redirections en chaîne et les URLs qui renvoient encore vers l’ancien domaine.
- Les formulaires de contact, les paiements, les confirmations automatiques et les notifications par e-mail.
- L’affichage mobile, les temps de chargement et les éventuels problèmes de CSS ou de JS liés au cache.
- La couverture d’indexation dans la Search Console et les éventuelles pages exclues par inadvertance.
- Les ressources mixtes, surtout quand un site passe à HTTPS sans nettoyage complet des liens internes.
Si je devais résumer la logique en une phrase, ce serait celle-ci: migrez d’abord la technique, sécurisez ensuite les URL, puis surveillez les signaux du terrain. C’est ce trio qui fait la différence entre un simple déplacement de fichiers et une migration vraiment maîtrisée.
