Tout au long de sa vie, un site WordPress connaît des mises à jour, des refontes et, parfois, un véritable déménagement : le changement de nom de domaine. Rebranding, changement d’extension, fusion de plusieurs sites : les raisons sont nombreuses, mais la crainte est toujours la même, perdre le référencement construit pendant des années. Bonne nouvelle : bien menée, l’opération provoque au pire un creux de trafic temporaire de quelques semaines, avant un retour à la normale. Mal menée, en revanche, elle peut effacer des années de travail. Toute la différence tient à une checklist appliquée dans le bon ordre, sans étape sautée. La voici, détaillée pas à pas : sauvegarde, bascule du domaine, redirections 301, déclaration aux moteurs de recherche et vérifications finales.

En bref

  • Sauvegardez tout avant de toucher quoi que ce soit : fichiers + base de données.
  • Les redirections 301 sont l’étape qui sauve votre SEO : elles transmettent 90 à 99 % de la valeur de vos backlinks.
  • Déclarez le changement dans la Search Console via l’outil « Changement d’adresse » (propriété de niveau domaine requise).
  • Comptez 2 à 8 semaines de flottement, c’est normal : Google réindexe. Les 301 restent en place indéfiniment.

Avant de commencer : ce qu’un changement de domaine change (et ne change pas) pour Google

Un nom de domaine n’est qu’une adresse. Ce que Google évalue (votre contenu, vos backlinks, votre structure) peut suivre le déménagement presque intégralement, à condition de laisser une adresse de réexpédition au facteur : les redirections 301. Sans elles, Google découvre un site « neuf » d’un côté et voit mourir un site établi de l’autre. Avec elles, il comprend qu’il s’agit du même site et transfère progressivement les signaux accumulés.

Les 5 raisons légitimes de changer de domaine

Dans notre pratique, les migrations de domaine répondent presque toujours à l’un de ces cinq cas : un changement de nom d’entreprise (rebranding, fusion), un changement d’extension (du .fr vers le .com pour viser l’international, ou l’inverse), un domaine plus court ou plus mémorisable, la consolidation de plusieurs sites en un seul, ou la sortie d’un domaine pénalisé par un historique douteux. Si votre motivation n’entre dans aucune de ces cases, posez-vous la question deux fois : chaque migration comporte un risque, même bien menée.

Conserver la structure d’URL : la règle d’or

C’est la règle que nous imposons à tous nos clients : on change le domaine, rien que le domaine. ancien-domaine.fr/mon-article/ doit devenir nouveau-domaine.fr/mon-article/, au caractère près. Modifier la structure des permaliens en même temps que le domaine multiplie les risques et rend le diagnostic impossible en cas de chute : vous ne saurez jamais lequel des deux changements est en cause. Si votre structure d’URL doit évoluer, faites-le dans un second temps, plusieurs mois après la migration, une fois les positions stabilisées.

Étape 1 : sauvegarder intégralement le site

Aucune manipulation de base de données ne commence sans une sauvegarde complète et testée. Une sauvegarde jamais restaurée est une promesse, pas une garantie.

Par extension

Deux valeurs sûres en 2026 : UpdraftPlus, dont la version gratuite couvre les sauvegardes planifiées avec envoi vers le cloud (les sauvegardes incrémentielles sont réservées à la version premium), et Duplicator, gratuit pour l’essentiel, dont la version Pro automatise carrément la migration avec remplacement des URLs. Vérifiez toujours les limites de la version gratuite au moment où vous lisez ces lignes : les éditeurs les font évoluer régulièrement.

Manuellement (SFTP + export MySQL)

La méthode que nous préférons pour les sites clients, car elle ne dépend d’aucune extension : téléchargez l’intégralité du site via SFTP (le dossier wp-content contient thèmes, extensions et médias), puis exportez la base de données depuis phpMyAdmin ou en ligne de commande avec mysqldump. Stockez les deux archives hors du serveur, datées.

Export de la base de données MySQL d'un site WordPress depuis phpMyAdmin avant un changement de domaine
L’export SQL complet de la base : votre filet de sécurité avant toute manipulation.

Étape 2 : basculer WordPress sur le nouveau domaine

Mettre à jour les URLs du site

Trois portes d’entrée, selon votre niveau d’accès : les champs « Adresse web de WordPress » et « Adresse web du site » dans Réglages → Général ; les constantes WP_HOME et WP_SITEURL dans wp-config.php (pratique quand l’admin n’est plus accessible) ; ou directement la table wp_options en base. Après l’enregistrement, le tableau de bord ne répond plus que sur le nouveau domaine : c’est normal, pas de panique.

Recherche-remplacement : Better Search Replace ou WP-CLI

Changer l’adresse du site ne suffit pas : l’ancien domaine reste codé en dur dans les contenus, les métadonnées et les réglages d’extensions, souvent dans des données sérialisées qu’un simple SQL REPLACE() corromprait. Il faut un outil qui gère la sérialisation.

Côté interface, Better Search Replace fait le travail proprement, avec un mode test. En ligne de commande (notre méthode en agence), WP-CLI est imbattable :

BASH
<h1>D’abord un test à blanc : rien n’est modifié, on compte les remplacements</h1> wp search-replace ‘https://ancien-domaine.fr’ ‘https://nouveau-domaine.fr’ –dry-run <h1>Si le résultat est cohérent, on exécute</h1> wp search-replace ‘https://ancien-domaine.fr’ ‘https://nouveau-domaine.fr’ –all-tables
Le réflexe --dry-run

Lancer un search-replace sans --dry-run sur une base de production, c’est sauter à l’élastique sans vérifier l’élastique : statistiquement, ça se passe presque toujours bien. Le test à blanc prend dix secondes et vous dit exactement combien de remplacements vont être effectués, table par table : un chiffre aberrant se repère immédiatement.

Étape 3 : mettre à jour les liens internes, médias et CDN

Le search-replace de l’étape 2 couvre la base de données, mais pas les URLs codées en dur ailleurs : fichiers de thème, CSS, scripts, et surtout la configuration de votre CDN.

Le cas du CNAME CDN personnalisé

Si vous servez vos assets via un CNAME du type cdn.ancien-domaine.fr, deux opérations : remplacer l’URL du CDN partout où elle est référencée (configuration de l’extension de cache, thème, base), puis créer le nouvel enregistrement CNAME cdn.nouveau-domaine.fr dans votre zone DNS, pointant vers votre fournisseur CDN. Un oubli ici ne casse pas le site, mais dégrade silencieusement les performances et fait apparaître l’ancien domaine dans le code source, ce qui brouille le signal envoyé à Google.

Étape 4 : les redirections 301, l’étape qui sauve votre SEO

Si vous ne deviez retenir qu’une étape de ce guide, c’est celle-ci.

Pourquoi les 301 sont vitales

Trois raisons. Vos backlinks, d’abord : chaque lien pointant vers l’ancien domaine continue d’exister, et une redirection 301 transmet entre 90 et 99 % de sa valeur au nouveau domaine. Sans elle, cette autorité accumulée est perdue. L’expérience utilisateur, ensuite : personne ne doit tomber sur une 404 en cliquant un vieux lien depuis un moteur, un favori ou un réseau social. Le signal envoyé à Google, enfin : la 301 est précisément ce qui lui dit « même site, nouvelle adresse ».

Configuration Apache (.htaccess) et nginx

Sur l’hébergement de l’ancien domaine, une règle générique redirige chaque URL vers son équivalente : c’est là que la conservation de la structure d’URL paie.

APACHE
<h1>.htaccess à la racine de l’ancien domaine (Apache)</h1> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?ancien-domaine.fr$ [NC] RewriteRule ^(.*)$ https://nouveau-domaine.fr/$1 [R=301,L]
NGINX
<h1>Bloc serveur nginx pour l’ancien domaine</h1> server { listen 443 ssl; server_name ancien-domaine.fr www.ancien-domaine.fr; # ssl_certificate … (le SSL de l’ancien domaine reste actif !) return 301 https://nouveau-domaine.fr$request_uri; }

Les 301 restent en place indéfiniment

C’est le point que nous répétons le plus en rendez-vous client : les redirections ne sont pas une mesure transitoire de six mois. Vos backlinks, eux, ne seront jamais tous mis à jour. Continuez donc à renouveler l’ancien nom de domaine (quelques euros par an, le meilleur ROI de votre budget SEO) et gardez un certificat SSL actif dessus : un navigateur doit d’abord établir la connexion HTTPS avec l’ancien domaine avant de pouvoir suivre la redirection. Sans certificat valide, vos visiteurs voient une erreur de sécurité, pas votre nouveau site.

Vérifier ses redirections

Testez une dizaine d’URLs représentatives (accueil, articles, pages, images) avec l’extension Chrome Redirect Path ou un simple curl -I. Deux points de contrôle : chaque URL doit répondre en un seul saut 301 (les chaînes de redirections diluent le signal et ralentissent le crawl), et aucune boucle ne doit provoquer l’erreur « too many redirects ».

Étape 5 : déclarer le changement à Google et Bing

L’outil « Changement d’adresse » de la Search Console

Prérequis : posséder l’ancienne et la nouvelle propriété dans la Search Console, sur le même compte Google, et, condition qui bloque le plus souvent, utiliser des propriétés de niveau domaine (validation DNS), pas des préfixes d’URL. L’outil se trouve dans Paramètres → Changement d’adresse, depuis la propriété de l’ancien domaine.

Avant de valider le transfert, Google vérifie lui-même que les redirections 301 fonctionnent sur vos URLs principales. Une fois la migration déclarée, les signaux sont transférés progressivement pendant 180 jours, d’où l’importance de ne rien démonter pendant cette fenêtre. Attention : cet outil sert uniquement aux changements de domaine ou de sous-domaine. Ne l’utilisez ni pour un passage HTTP → HTTPS, ni pour un changement www/sans-www : les redirections seules suffisent dans ces cas.

Écran Changement d'adresse de Google Search Console, avec le sélecteur de la propriété de destination
Avant d’accepter le changement d’adresse, la Search Console rappelle les prérequis : redirections 301 en place et propriété des deux sites confirmée.

Bing Webmaster Tools : Site Move

Même logique côté Bing : les deux propriétés vérifiées, puis depuis l’ancienne, la fonction Site Move pour déplacer les URLs vers le site vérifié de destination. Deux minutes, souvent oubliées, et Bing alimente aussi DuckDuckGo et une partie des réponses des assistants IA : ce serait dommage de s’en priver.

Étape 6 : sitemap, Analytics et vérifications finales

Soumettre le nouveau sitemap

Dans la propriété du nouveau domaine : rubrique Sitemaps, soumission de https://nouveau-domaine.fr/sitemap_index.xml (URL fournie par Yoast, Rank Math ou SEOPress). Ce n’est pas obligatoire, mais cela accélère nettement la découverte des nouvelles URLs.

GA4 : mettre à jour le flux de données

Inutile de créer une nouvelle propriété : vous perdriez votre historique. Dans GA4 : Admin → Flux de données → sélectionnez votre flux web → modifiez l’URL du site avec le nouveau domaine, puis enregistrez. La balise (ID « G- ») reste identique, la collecte continue sans interruption et vos comparaisons avant/après migration restent possibles dans la même propriété.

Checklist post-migration

  • robots.txt : vérifier qu’aucun Disallow parasite n’a suivi la migration (un environnement de préprod cloné avec son robots.txt bloquant, c’est un classique).
  • Emails transactionnels et DNS : reconfigurer SPF, DKIM et DMARC sur le nouveau domaine, et mettre à jour l’expéditeur dans votre outil d’emailing.
  • Profils sociaux et fiches : liens LinkedIn, Instagram, X, fiche d’établissement Google, tout ce qui pointe encore vers l’ancien domaine.
  • Campagnes payantes : URLs finales Google Ads, Meta Ads, et process de réapprobation des programmes d’affiliation le cas échéant.
  • Monitoring des 404 : rapport « Indexation des pages » de la Search Console + journal 404 de l’extension Redirection pendant les premières semaines.

Pour compléter ce tour d’horizon, voici les erreurs que nous croisons le plus souvent en reprenant des migrations faites sans méthode :

Erreur fréquente Conséquence Parade
301 configurées puis supprimées au bout d'un an Perte sèche de la valeur des backlinks Renouveler l'ancien domaine et laisser les 301 indéfiniment
SSL expiré sur l'ancien domaine Erreur de sécurité avant même la redirection Garder un certificat actif (Let's Encrypt suffit)
Changement de domaine + refonte des permaliens en même temps Chute impossible à diagnostiquer Une migration à la fois, espacées de plusieurs mois
search-replace SQL brut sans gestion de la sérialisation Réglages et widgets corrompus Better Search Replace ou wp search-replace
Propriétés GSC en préfixe d'URL uniquement Outil Changement d'adresse inaccessible Valider les propriétés de niveau domaine (DNS) en amont

Combien de temps avant de retrouver ses positions ?

Soyons honnêtes, parce que c’est la question que tous nos clients posent : oui, il y aura un creux. Sur les migrations propres que nous menons, la baisse de trafic organique est généralement contenue entre 5 et 15 % et se résorbe en 2 à 8 semaines, le temps que Google recrawle et réattribue les signaux. La fenêtre officielle de transfert de la Search Console dure 180 jours : pendant ces six mois, ne démontez rien, ne « re-migrez » rien, et contentez-vous d’un suivi hebdomadaire : impressions et position moyenne dans la Search Console, journal des 404, état des redirections. Un creux qui se prolonge au-delà de deux mois sans amorce de remontée est le signal qu’une étape a été ratée, presque toujours du côté des redirections.

Cas réel (anonymisé)

Un client e-commerce nous a contactés trois semaines après avoir migré seul : trafic organique divisé par deux. Diagnostic : redirections posées uniquement sur la page d’accueil, toutes les URLs profondes répondaient en 404, et le certificat SSL de l’ancien domaine avait été résilié. Après remise en place de 301 exhaustives et réactivation du SSL, le site a retrouvé 90 % de son trafic en six semaines. Le même travail fait avant la bascule aurait limité le creux à quelques points.

FAQ

Indéfiniment, tant que des backlinks pointent vers lui, c’est-à-dire, en pratique, toujours. Le renouvellement coûte une dizaine d’euros par an, contre des années d’autorité perdues si les redirections tombent. Gardez aussi un certificat SSL actif dessus pour que les redirections HTTPS fonctionnent.

Techniquement oui, mais nous le déconseillons systématiquement. Chaque changement simultané ajoute un risque et rend le diagnostic impossible en cas de chute. Migrez d’abord le domaine à structure constante, stabilisez, puis retravaillez les permaliens plusieurs mois après si nécessaire.

Non, si vos redirections 301 sont exhaustives et permanentes : elles transmettent entre 90 et 99 % de la valeur des liens. Profitez-en tout de même pour contacter les sites qui vous apportent le plus d’autorité et leur demander de mettre à jour leur lien en direct : un lien direct vaudra toujours mieux qu’un lien redirigé. Pour comprendre ce qui se joue ici, voyez notre article qu’est-ce qu’un backlink.

Non. Google est explicite : cet outil est réservé aux changements de domaine ou de sous-domaine. Pour un passage HTTP → HTTPS ou un changement www/sans-www, les redirections 301 et les propriétés Search Console correspondantes suffisent.

Un changement de domaine n’est pas une opération à improviser un vendredi soir, mais ce n’est pas non plus une boîte noire : sauvegarde, bascule, redirections, déclaration aux moteurs, monitoring. Dans cet ordre, sans exception, votre SEO suit le déménagement. Si la migration s’accompagne d’un changement d’hébergeur ou d’un transfert de données, notre guide complet de la migration WordPress couvre l’autre moitié du sujet, et notre guide d’utilisation de la Search Console vous aidera à piloter le suivi post-migration. Pensez enfin à retravailler votre maillage interne une fois la poussière retombée : c’est le bon moment pour un audit.