Une migration WordPress ne se juge pas au nombre de fichiers copiés, mais aux positions conservées une fois la poussière retombée. Une migration WordPress réussie ne se mesure pas au volume de données transférées, mais au trafic qui continue d’arriver après la bascule.
Par Geoffrey Medina, fondateur de PandiWeb, développeur web fullstack depuis 2015
La majorité des tutoriels que nous croisons décrivent comment dupliquer un site : exporter, importer, changer les DNS, terminé. Très peu expliquent comment déplacer un site sans perdre son référencement. Nous prenons donc le problème dans l’autre sens. La procédure technique reste, mais chaque étape est pilotée par une seule question : qu’est-ce qui peut faire chuter le référencement ?
Migrer un site WordPress, c’est déplacer trois choses en même temps : les fichiers, la base de données et le signal envoyé à Google. Les deux premières sont mécaniques. La troisième est celle qu’on oublie, et c’est précisément celle qui met des semaines à se reconstruire. Un site qui répond en 200 après la migration peut avoir perdu la moitié de ses URL indexées sans que personne ne s’en aperçoive avant le bilan mensuel.
Sur le terrain, les migrations qui posent problème échouent presque toujours sur les mêmes points : une URL modifiée sans redirection, un noindex oublié, une base réécrite à la main. Nous ne racontons pas d’histoires de clients ici, seulement ce que ces dossiers ont en commun. Cet article en fait une checklist utilisable, du premier export jusqu’aux contrôles Search Console, avec les versions de PHP et de WordPress qui comptent en cette fin 2026.
En bref : les 8 étapes d'une migration WordPress sans casse
La migration se prépare avant la copie des fichiers et se termine bien après la bascule DNS. Voici l’enchaînement que nous suivons, et qui structure tout le reste de l’article.
Sauvegarde complète du site d’origine, fichiers et base, avec un test de restauration réel avant de toucher à quoi que ce soit.
Environnement de test sur le nouvel hébergement, identique à la production et fermé aux moteurs de recherche.
Vérification avant bascule de tout ce qui peut casser : version de PHP, extensions, formulaires, panier, tâches planifiées, certificat.
Transfert des fichiers (thèmes, extensions, médias, wp-config adapté à la nouvelle machine).
Transfert de la base de données, avec un remplacement des URL qui ne casse pas les données sérialisées.
Bascule DNS préparée, TTL réduit à l’avance, enregistrements vérifiés, certificat posé avant le pointage.
Redirections 301 et conservation des URL indexées, avec une correspondance une pour une et aucune chaîne de redirections.
Contrôles post-migration dans Search Console et Analytics, à J+7 puis à J+28, avant de considérer l’opération terminée.
Comptez une fenêtre de surveillance de 180 jours, pas de 48 heures. Google recommande de conserver les redirections 301 au moins 180 jours, et plus longtemps si les anciennes URL reçoivent encore du trafic de recherche. L’outil Change of Address de Search Console reste actif 180 jours lui aussi. Une migration n’est pas finie quand le site s’affiche : elle est finie quand les signaux ont été transmis et vérifiés.
Plugin, migration manuelle ou prestataire : comment choisir avant de toucher au site
Le choix de la méthode dépend du site, pas d’une préférence d’agence. Un blog de cinquante articles et une boutique de plusieurs milliers de références ne se déplacent pas avec les mêmes outils, et ce n’est pas une question de goût technique.
Les plugins de migration
Les plugins de migration conviennent aux sites simples, quand la fenêtre de bascule reste courte. Duplicator et All-in-One WP Migration sont tous deux maintenus et mis à jour régulièrement. Duplicator sauvegarde sans limite de taille, chiffre les archives et propose une restauration en un clic. All-in-One WP Migration n’impose pas de plafond d’import fixe : la limite réelle est celle de la taille d’upload autorisée par l’hébergeur, affichée sur l’écran d’import. En revanche, la restauration en un clic et l’usage de son WP-CLI nécessitent l’extension payante. Leur avantage est la simplicité : pas de SSH, pas de requête SQL, une interface. Leur limite est le contrôle : peu de visibilité sur ce qui est réécrit dans la base, une dépendance à l’extension pendant toute la durée de l’opération, et un export qui peut être bloqué par les limites du serveur d’origine.
La migration manuelle
La migration manuelle, fichiers plus base, donne le contrôle total, à condition de maîtriser le remplacement des URL. On exporte la base, on copie wp-content par SFTP, on adapte wp-config, on importe, on remplace les URL proprement. On voit exactement ce qui passe et ce qui ne passe pas, on peut exclure un dossier de cache volumineux, on garde la main sur les permissions. La contrepartie est ailleurs : un fichier oublié, un wp-config écrasé, une requête SQL brute sur les options, et le site se réveille avec des widgets vides ou une page blanche.
WP-CLI
WP-CLI est l’outil en ligne de commande officiel de WordPress, et c’est la méthode la plus reproductible quand le serveur autorise le SSH. wp db export génère un export de la base, wp db import applique un fichier SQL sur la base déclarée dans wp-config. wp search-replace remplace les URL sans casser les données sérialisées, avec un mode simulation pour vérifier avant d’écrire. On enchaîne aussi les vérifications de cœur, d’extensions et de réécriture. Les limites sont concrètes : il faut un accès SSH, une aisance minimale en ligne de commande, et wp db import ne crée pas la base, il faut qu’elle existe déjà. Une commande mal ciblée s’exécute sans confirmation, d’où la sauvegarde préalable.
Déléguer a du sens quand le site porte du chiffre d’affaires, un catalogue ou plusieurs années de contenus. Un formulaire de contact cassé se voit tout de suite. Un plan de redirections incomplet ou une propriété Search Console non transférée ne se voient que des semaines plus tard, quand les positions ont glissé.
Nous choisissons la méthode selon le site : poids des médias, nombre d’extensions et leurs licences, accès SSH disponible, version de PHP de la cible, structure des URL, dépendance au e-commerce, tolérance à une coupure. Sur un site vitrine léger avec un accès serveur correct, la ligne de commande est souvent la plus propre. Sur un site sans SSH chez un hébergeur fermé, un plugin bien préparé fait le travail. Sur une boutique avec des milliers de commandes et un historique de redirections, nous préférons une intervention encadrée. Avant d’arbitrer, un état des lieux aide : notre audit WordPress gratuit permet de lister les dépendances réelles du site avant de décider.
Étapes 1 à 3 : sauvegarde complète, environnement de test, vérification avant bascule
Ces trois étapes décident de la réussite du reste : mal préparée, une migration se rattrape en production, ce qui coûte toujours plus cher. Elles se font toutes avant d’avoir touché au DNS du site en ligne.
La sauvegarde complète, fichiers et base, avec un test de restauration réel, est la seule assurance de la migration. Pas une copie dont on suppose qu’elle est bonne : une copie qu’on a déjà restaurée ailleurs et dont on a ouvert la page d’accueil et l’administration. Nous exportons la base, nous archivons le répertoire complet, nous vérifions la taille des médias, et nous conservons cette archive hors du serveur, dans un espace qui ne dépend ni de l’ancien hébergeur ni du nouveau. Notre page sur la sauvegarde et la restauration WordPress détaille ce qui doit figurer dans une archive utilisable.
L’environnement de test doit être identique à la production et fermé aux moteurs de recherche. Même version de WordPress, même version de PHP que la cible visée, mêmes extensions aux mêmes versions. Et surtout : un noindex explicite, un robots.txt en Disallow, et une protection par mot de passe. Un site de test indexable est une fuite de contenu dupliqué, et c’est aussi la source d’une erreur classique : la bascule se fait, le noindex reste, et le site de production disparaît des résultats sans le moindre message d’erreur.
On vérifie tout ce qui peut casser avant de toucher au DNS, pas après. La liste que nous parcourons est courte mais non négociable : version de PHP réellement active, extensions chargées et compatibles, structure des permaliens, formulaires et envoi d’e-mails, tunnel de commande et paiement pour un site e-commerce, tâches planifiées, certificat SSL, sitemap, balises canoniques, hreflang si le site est multilingue, cache et CDN. Un site qui fonctionne en test se bascule en confiance ; un site qui fonctionne « à peu près » en test se bascule en priant.
Étapes 4 à 6 : fichiers, base de données et DNS sans interruption de service
Fichiers, base et DNS se déplacent dans cet ordre, jamais en même temps. Cette discipline évite de chercher une erreur dans trois directions à la fois quand quelque chose ne s’affiche pas.
Le transfert des fichiers concerne surtout wp-content : thèmes, extensions, médias et fichiers générés. Le cœur de WordPress se réinstalle proprement plutôt que de se copier, ce qui garantit une version saine sur la cible. Le wp-config se réécrit pour la nouvelle machine : identifiants de base, sels d’authentification, éventuelles constantes WP_HOME et WP_SITEURL si elles sont utilisées, chemins absolus s’il y en a. On vérifie ensuite les permissions des dossiers et des fichiers, et on s’assure que la taille des médias a bien suivi, un uploads tronqué étant une cause fréquente d’images cassées après migration.
Le transfert de la base est l’endroit exact où les migrations abîment un site. On importe l’export, puis on remplace les anciennes URL par les nouvelles avec wp search-replace, ou avec un outil dédié qui gère la sérialisation. Une requête SQL UPDATE lancée à la main sur la table des options casse les données sérialisées, et les dégâts sont silencieux : réglages de thème perdus, widgets vides, options d’extensions réinitialisées. Autre règle absolue : on ne modifie jamais la colonne GUID, même quand elle contient encore l’ancienne adresse. WordPress documente ces deux points, et nous les appliquons sans exception.
Changer d’hébergeur WordPress sans coupure suppose une bascule DNS préparée : TTL réduit, enregistrements vérifiés, certificat posé avant le pointage. On abaisse le TTL des enregistrements concernés suffisamment en amont pour que le changement se propage vite, on relève les enregistrements existants (A, AAAA, CNAME, MX, TXT, éventuels sous-domaines) pour ne rien perdre au passage, et on installe le certificat SSL sur la nouvelle machine avant de pointer le domaine. Pendant la propagation, les deux hébergements répondent : l’ancien doit rester actif et à jour, sinon les visiteurs qui résolvent encore l’ancienne adresse tombent sur une version figée du site. Les enregistrements MX se traitent à part, une bascule DNS mal préparée pouvant couper les e-mails professionnels.
Étape 7 : redirections, permaliens et conservation des URL indexées
Le référencement se perd rarement à la copie : il se perd sur les URL. C’est l’étape qui décide si la migration WordPress se fait sans perdre le référencement ou si l’on repart de zéro sur une partie du site.
Si le domaine et les chemins ne changent pas, il n’y a rien à rediriger, et c’est la meilleure configuration possible. C’est le cas du simple changement d’hébergeur, à condition de ne pas modifier la structure des permaliens au passage. Une migration n’est pas le bon moment pour « profiter d’y voir plus clair » dans les URL : chaque changement de chemin crée une page qui n’existe plus aux yeux de Google.
Quand le domaine ou les chemins changent, chaque ancienne URL doit avoir une nouvelle adresse, en une seule redirection 301. Une correspondance se prépare sous forme de table, avant la bascule, à partir des URL réellement indexées et des pages qui reçoivent du trafic.
Page de l’ancien domaine
https://ancien-domaine.fr/page/ vers https://www.nouveau-domaine.fr/page/
Type : 301
Contrôle après bascule : Un seul saut, réponse 200 en cible
Article de blog
https://ancien-domaine.fr/blog/article/ vers https://www.nouveau-domaine.fr/article/
Type : 301
Contrôle après bascule : Correspondance de contenu vérifiée
Catégorie supprimée
https://ancien-domaine.fr/categorie/supprimee/ vers la page la plus proche ou 410
Type : 301 ou 410
Contrôle après bascule : Pas de 404 orpheline
Version HTTP
http://nouveau-domaine.fr/ vers https://www.nouveau-domaine.fr/
Type : 301
Contrôle après bascule : HTTPS et www cohérents
Une redirection 301 se prépare en une seule étape : une chaîne de redirections dilue le signal et ralentit le crawl. On évite donc les redirections en cascade, les 302 provisoires qui traînent et les redirections générées automatiquement par plusieurs extensions à la fois. On vérifie aussi la cohérence de l’hôte : une seule version du domaine doit répondre, avec ou sans www, en HTTPS, pour éviter que la même page existe à quatre adresses.
Les permaliens, le sitemap et le robots.txt se relisent après la bascule, dans cet ordre. Le sitemap doit contenir les nouvelles adresses, sans URL redirigées ni adresses de test. Le robots.txt ne doit pas bloquer ce qu’il bloquait avant, et surtout pas l’ensemble du site. Les balises canoniques doivent pointer vers la nouvelle version, y compris dans les contenus qui les codent en dur dans des constructeurs de pages.
Google recommande de conserver les redirections 301 au moins 180 jours, et plus longtemps si les anciennes URL reçoivent encore du trafic. Nous ne les supprimons donc pas « une fois que ça a l’air stable ». Le bon signal, c’est la disparition progressive des anciennes URL dans les données de performance de Search Console, pas une intuition.
Étape 8 : les contrôles post-migration dans Search Console et Analytics
Les contrôles post-migration se lisent dans Search Console et Analytics, pas au ressenti. Un site peut sembler parfait et avoir perdu la moitié de ses pages indexées.
La propriété Search Console se prépare avant la bascule, et l’ancienne propriété ne se supprime pas. On ajoute et on vérifie la nouvelle propriété à l’avance, par enregistrement DNS de préférence, pour ne pas se retrouver à attendre une validation le jour où les chiffres comptent. Si le domaine change, l’outil Change of Address de Search Console transmet le signal de déménagement ; il reste actif 180 jours, et une demande peut être annulée pendant cette période.
Le premier réflexe est de soumettre le nouveau sitemap, puis de lire les rapports d’indexation page par page. On regarde les pages exclues par une balise noindex, les erreurs 404, les erreurs de redirection, les erreurs serveur 5xx, les URL détectées mais non indexées, et les statistiques d’exploration. Un pic de 5xx dans les heures qui suivent la bascule se corrige immédiatement : il ne s’agit pas d’un détail technique, mais d’un signal envoyé à Google pendant que le robot explore activement.
La comparaison des clics et des impressions se fait à J+7 puis à J+28, toujours à périmètre égal. On compare les mêmes périodes, les mêmes requêtes, les mêmes pages, en tenant compte de la saisonnalité. Une baisse localisée sur quelques URL signale un problème de redirection ou de contenu. Une baisse générale sur tout le site oriente plutôt vers un noindex, un robots.txt ou une erreur de configuration côté serveur.
Côté Analytics, on vérifie que la collecte tourne encore : balise présente, événements déclenchés, e-commerce qui remonte, consentement toujours fonctionnel. Un identifiant de mesure perdu au passage donne l’illusion d’une chute de trafic alors que seule la mesure est cassée. Dans le même temps, on contrôle les performances réelles du site sur la nouvelle machine, car un serveur plus lent annule le bénéfice de la migration : notre page pour tester et améliorer les performances d’un site web donne la marche à suivre pour mesurer avant et après.
Les 7 erreurs qui coûtent des positions, et ce qu'elles changent vraiment
Dans notre expérience, une migration qui coûte des positions tombe presque toujours dans l’une de ces sept erreurs. Aucune n’est exotique, et toutes se détectent avant la bascule quand on sait quoi regarder.
Le noindex laissé en place. Le site de test était fermé aux moteurs, la production hérite du réglage, et les pages disparaissent des résultats sans erreur visible.
Les URL modifiées sans redirection. Un permalien réécrit « pour faire propre » condamne toutes les anciennes adresses, et les backlinks avec elles.
Le remplacement des URL par requête SQL brute. Les données sérialisées cèdent, les réglages de thème et d’extensions partent en fumée, souvent sans message d’erreur.
La modification de la colonne GUID. Elle ne sert pas à l’affichage, elle ne doit pas être réécrite, et certains flux la lisent encore.
La base importée sans adaptation de wp-config. Mauvais préfixe, mauvais identifiants, mauvaises constantes : le site s’affiche en erreur de connexion à la base.
La bascule DNS précipitée. Ancien hébergement coupé trop tôt, TTL trop long, propagation non anticipée : une partie des visiteurs reste bloquée sur une version incomplète.
Les dépendances oubliées. E-mails, tâches planifiées, CDN, certificat, propriété Search Console, sitemap, redirections gérées par une extension : tout ce qui vit en dehors des fichiers et de la base.
Rien ne se récupère au clic : une page désindexée revient au rythme de l’exploration, et plus l’erreur est ancienne, plus la remontée est lente. C’est ce qui distingue une migration propre d’une migration réparée : la seconde coûte du temps, des positions et parfois des clients, alors que la première n’a coûté qu’une préparation. Quand le site est déjà en panne après une bascule, il ne faut pas attendre : notre page de dépannage WordPress pour un site en panne décrit les premiers réflexes et les vérifications d’urgence.
Combien coûte une migration WordPress en 2026
Il n’existe pas de prix unique pour une migration WordPress, et un tarif affiché sans connaître le site est un prix faux. Le prix d’une migration WordPress dépend de ce qu’on déplace, pas de la page qui la décrit.
Les facteurs de coût sont techniques avant d’être commerciaux. Volume de la base et des médias, nombre d’extensions et licences à réinstaller, présence d’un e-commerce avec commandes et clients, nombre d’URL à rediriger, accès serveur disponible ou non, complexité DNS avec e-mails et sous-domaines, site multilingue ou multisite, niveau d’accompagnement SEO attendu, contrainte de calendrier. Un site vitrine de quelques pages et une boutique avec un historique de commandes ne mobilisent ni le même temps ni les mêmes précautions.
Chez nous, une migration WordPress fait l’objet d’un devis, parce que chaque site a ses fichiers, ses extensions et son historique. Le devis précise ce qui est inclus : sauvegarde testée, environnement de test, transfert des fichiers et de la base, remplacement des URL, plan de redirections, contrôles Search Console et Analytics après bascule, rapport de fin d’opération. Un devis qui ne mentionne pas les redirections et les contrôles post-migration ne couvre pas la partie risquée du travail. Pour en parler, notre page de contact suffit : nous partons du site réel, pas d’une grille tarifaire.
Le coût d’une migration ratée, lui, ne se lit pas sur la facture de prestation. Il se lit dans les semaines de trafic perdu, dans les demandes de devis qui n’arrivent plus et dans le temps passé à réparer ce qui aurait pu être vérifié. Une migration suivie d’un contrat de maintenance WordPress évite la deuxième erreur classique : croire que tout est terminé une fois le site en ligne, alors que les mises à jour, les sauvegardes et la surveillance doivent reprendre immédiatement sur la nouvelle machine.
Migrer en 2026 : PHP 8.6, WordPress 7.2 et ce que ça change dans la procédure
Une migration se prépare avec le calendrier des versions en tête, pas avec la version du site d’origine. C’est le meilleur moment pour corriger une dette technique, et le pire pour en créer une.
Côté PHP, la fenêtre est étroite : PHP 8.2 est en fin de vie le 31 décembre 2026, PHP 8.3 reste en sécurité seule jusqu’au 31 décembre 2027, et PHP 8.6 sort le 19 novembre 2026. Au moment où nous écrivons, PHP 8.6 n’est pas encore disponible. WordPress recommande PHP 8.3 minimum, et l’équipe hébergement de WordPress conseille PHP 8.4 ou 8.5 pour les installations 7.1. Concrètement : migrer un site en 2026 vers une machine en PHP 8.2, c’est programmer un chantier pour l’année suivante.
Côté WordPress, WordPress 7.1.4 est la version stable depuis le 28 octobre 2026 et WordPress 7.2 est prévu le 8 décembre 2026. On installe donc la cible sur la version stable actuelle, on teste les extensions contre elle, et on évite de basculer en pleine fenêtre de sortie d’une version majeure : une extension qui casse au mauvais moment se diagnostique mal quand deux changements se superposent.
En pratique, nous visons PHP 8.4 ou 8.5 sur la nouvelle machine, nous testons les extensions sur le site de test, et nous ne sautons pas sur une nouvelle version PHP le jour de sa sortie. Une version qui vient de paraître n’a pas encore été éprouvée par l’écosystème des extensions et des thèmes. Le bon réflexe est de migrer sur une version supportée, stable et testée, puis de planifier la montée de version comme un chantier distinct, avec sa propre sauvegarde.
Questions fréquentes sur la migration WordPress
Combien de temps dure une migration WordPress, et combien de temps le site reste-t-il hors ligne ?
La durée dépend du volume de fichiers, de la taille de la base et de la complexité du plan de redirections. Ce que nous pouvons dire sans chiffrer à l’aveugle : la coupure visible se limite à la bascule DNS quand tout est préparé en amont, car le site de test tourne déjà sur la nouvelle machine avant le pointage. L’essentiel du travail se fait donc hors ligne, sur l’environnement de test, et non pendant que les visiteurs attendent.
Une migration WordPress fait-elle perdre du référencement ?
Pas par nature. Les pertes viennent presque toujours de trois causes : des URL modifiées sans redirection 301, un noindex ou un robots.txt laissé en place après la bascule, et une base réécrite avec des données sérialisées cassées. Une migration WordPress sans perdre le référencement, c’est une migration où les URL sont conservées ou redirigées une pour une, où l’indexation est vérifiée dans Search Console, et où les redirections restent en place au moins 180 jours.
Faut-il refaire son site en même temps que la migration ?
Mieux vaut éviter de tout empiler. Une refonte modifie les URL, les gabarits, les contenus et parfois le maillage interne : superposée à une migration, elle rend impossible l’identification de la cause d’une baisse. Quand les deux chantiers sont nécessaires, nous les séquençons : migration d’abord, sur un site identique, puis refonte avec un plan de redirections dédié.
Peut-on migrer un site WordPress sans accès SSH ?
Oui, avec un plugin de migration correctement préparé, en vérifiant la taille d’upload autorisée par l’hébergeur et en gardant une sauvegarde restaurée en local. Sans SSH, on perd surtout la possibilité de lancer un remplacement d’URL contrôlé en ligne de commande, d’où l’importance de tester l’export avant de considérer la copie comme fiable.
Combien de temps faut-il conserver les redirections 301 après une migration ?
Google recommande de les conserver au moins 180 jours, et plus longtemps si les anciennes URL reçoivent encore du trafic de recherche. L’outil Change of Address de Search Console, quand le domaine change, reste actif 180 jours. Nous vérifions la disparition progressive des anciennes URL dans les données de performance avant d’envisager de retirer une redirection.
Un site à migrer sans perdre vos positions ?
Parlez-nous de votre site : nous partons du site réel pour préparer une migration encadrée, avec sauvegarde testée, redirections et contrôles après bascule.
