Contact

Changer le nom de domaine d’un site WordPress avec une redirection 301

Mis à jour le :

Pour changer le nom de domaine d’un site WordPress sans perdre son trafic, faites répondre le site sur la nouvelle adresse, remplacez l’ancien domaine dans la base de données avec un outil qui respecte les données sérialisées, redirigez chaque ancienne URL vers son équivalent par une redirection 301, puis déclarez le déménagement dans la Search Console. Voici la méthode complète, de la préparation aux contrôles après la bascule, avec les règles .htaccess et Nginx prêtes à adapter.

Dans les exemples, remplacez ancien-domaine.example (adresse actuelle) et nouveau-domaine.example (nouvelle adresse, en HTTPS et sans www) par vos domaines.

Préparer le changement de nom de domaine

Google conseille de ne changer qu’une chose à la fois lors d’une migration : déplacez d’abord le domaine, et gardez la refonte ou la nouvelle structure d’URL pour plus tard, et visez une période de faible trafic.

Fixer la forme définitive des nouvelles URL

Décidez si le nouveau domaine s’affichera avec ou sans www, toujours en HTTPS, et visez directement cette forme dans toutes les redirections. Googlebot suit jusqu’à 10 redirections en chaîne, mais Google recommande d’aller directement à la destination finale : chaque saut ralentit le visiteur.

Configurer les DNS du nouveau domaine

Quelques jours avant la bascule, faites pointer le nouveau domaine et sa variante www vers votre hébergement (enregistrements A et AAAA, ou valeurs fournies par l’hébergeur). Gardez l’ancien domaine actif et renouvelé : c’est lui qui servira les redirections.

Installer un certificat HTTPS sur les deux domaines

Le nouveau domaine a besoin d’un certificat couvrant les formes avec et sans www. L’ancien aussi, ce qu’on oublie souvent : la connexion chiffrée s’établit avant l’envoi de la requête, donc avant la redirection. Sans certificat valide, un visiteur arrivant par un lien en https:// voit une alerte de sécurité au lieu d’être redirigé. Avec Let’s Encrypt, la validation HTTP-01 passe par le port 80 : le domaine doit déjà pointer vers le serveur. Le détail est dans mon guide pour passer un site WordPress en HTTPS.

Sauvegarder les fichiers et la base de données

Sauvegardez les fichiers (y compris wp-config.php et .htaccess) et la base de données, et rangez le tout hors du serveur. Avec WP-CLI :

# Export the database before any change
wp db export avant-changement-domaine.sql

Préparer la Search Console

Validez les deux domaines dans la Search Console, en tant que propriétaire et avec le même compte Google, variantes avec et sans www comprises : l’outil de changement d’adresse l’exige. Si le nouveau domaine a déjà servi, vérifiez qu’il ne traîne ni action manuelle ni suppression d’URL laissée par un précédent propriétaire.

Faire répondre le site sur le nouveau domaine

  • Même hébergement : ajoutez le nouveau domaine dans le panneau de l’hébergeur en le faisant pointer vers le dossier de WordPress. Les deux domaines servent alors les mêmes fichiers, et un seul .htaccess gère la redirection.
  • Nouveau serveur : copiez les fichiers, importez la base et adaptez les identifiants de base de données dans wp-config.php. Je fais les remplacements d’URL sur la copie : le site d’origine reste intact jusqu’à la bascule.

La documentation officielle sur la migration de WordPress détaille ces deux situations.

Mettre à jour l’adresse de WordPress

WordPress stocke son adresse dans deux options, home et siteurl, affichées dans Réglages > Général sous les libellés « Adresse web du site (URL) » et « Adresse web de WordPress (URL) ». Les deux s’écrivent avec https:// et sans barre oblique finale.

Depuis Réglages > Général

Remplacez l’ancien domaine dans les deux champs, puis enregistrez. Tant que le nouveau domaine ne répond pas, la documentation prévoit l’affichage d’une page d’erreur : c’est normal. Reconnectez-vous ensuite sur la nouvelle adresse.

Avec les constantes WP_HOME et WP_SITEURL

Si l’administration n’est plus accessible, déclarez l’adresse dans wp-config.php, avant la ligne « C’est tout, ne touchez pas à ce qui suit ! » (That’s all, stop editing! dans un fichier en anglais) :

// Public address of the site, without trailing slash.
define( 'WP_HOME', 'https://nouveau-domaine.example' );
// Address of the WordPress core files (same value unless WordPress lives in a subdirectory).
define( 'WP_SITEURL', 'https://nouveau-domaine.example' );

Les deux champs de Réglages > Général deviennent alors non modifiables. Inutile en revanche de lancer wp option update : le remplacement global de l’étape suivante met aussi ces deux options à jour.

Remplacer l’ancien domaine dans la base de données

Modifier home et siteurl ne suffit pas : liens internes, images, menus, widgets et réglages d’extensions contiennent encore l’ancien domaine en dur.

Pourquoi pas un simple REPLACE en SQL ?

Beaucoup d’options sont enregistrées au format sérialisé de PHP, où chaque chaîne est précédée de sa longueur : s:30:"https://ancien-domaine.example";. Un UPDATE … REPLACE() écrit https://nouveau-domaine.example (31 caractères) mais laisse s:30 : PHP ne lit plus la valeur, et des réglages de thème, widgets ou options d’extensions semblent perdus. La documentation de WordPress met en garde contre ce piège.

Simuler puis lancer wp search-replace

D’après la documentation de wp search-replace, la commande gère les données sérialisées, et --dry-run exécute toute l’opération sans rien enregistrer. J’ajoute deux options :

  • --skip-columns=guid : la documentation de WordPress interdit de modifier la colonne guid, sinon les lecteurs de flux réafficheraient vos anciens articles comme nouveaux ;
  • --all-tables-with-prefix : inclut les tables d’extensions non déclarées auprès de WordPress.
# 1. List every table and column that still contains the old domain
wp db search 'ancien-domaine.example' --all-tables-with-prefix --stats

# 2. Dry run: shows what would change, writes nothing
wp search-replace '//www.ancien-domaine.example' '//nouveau-domaine.example' --all-tables-with-prefix --skip-columns=guid --report-changed-only --dry-run
wp search-replace '//ancien-domaine.example' '//nouveau-domaine.example' --all-tables-with-prefix --skip-columns=guid --report-changed-only --dry-run

# 3. Same commands without --dry-run, then force HTTPS on the new domain
wp search-replace '//www.ancien-domaine.example' '//nouveau-domaine.example' --all-tables-with-prefix --skip-columns=guid --report-changed-only
wp search-replace '//ancien-domaine.example' '//nouveau-domaine.example' --all-tables-with-prefix --skip-columns=guid --report-changed-only
wp search-replace 'http://nouveau-domaine.example' 'https://nouveau-domaine.example' --all-tables-with-prefix --skip-columns=guid --report-changed-only

# 4. Flush the object cache and the rewrite rules
wp cache flush
wp rewrite flush

Chercher //ancien-domaine.example attrape les URL en http:// comme en https://, mais pas les adresses e-mail du type [email protected], à traiter à part. Si le nouveau domaine garde le www, adaptez les chaînes. Pour débuter avec l’outil, consultez mon guide de WP-CLI.

Sans accès SSH

L’extension gratuite Better Search Replace, citée par la documentation de WordPress, gère la sérialisation et propose une simulation (« dry run ») à lancer avant tout remplacement. Je la supprime une fois le travail terminé.

Constructeurs de pages, fichiers et multisite

Elementor enregistre ses mises en page en JSON, avec des barres obliques échappées (https:\/\/ancien-domaine.example) : la recherche sur //ancien-domaine.example ne les trouve pas, alors que wp db search les signale. Elementor fournit une commande WP-CLI dédiée à ce format :

# Elementor: replace URLs inside its JSON layout data
wp elementor replace-urls 'https://ancien-domaine.example' 'https://nouveau-domaine.example'

# Look for the old domain hard-coded in files
grep -rIl 'ancien-domaine.example' wp-config.php wp-content/themes

La seconde commande repère les adresses écrites en dur. En multisite, le domaine figure aussi dans les tables wp_site et wp_blogs, les options de chaque site et la constante DOMAIN_CURRENT_SITE : c’est un chantier à part, à vérifier table par table.

Rediriger l’ancien domaine en 301, page à page

Google recommande des redirections permanentes côté serveur, de chaque ancienne URL vers son équivalent. Comme WordPress conserve les mêmes slugs, une seule règle générique suffit, à condition qu’elle :

  • conserve le chemin : /mon-article/ mène à https://nouveau-domaine.example/mon-article/ ;
  • conserve la chaîne de requête (?utm_source=…, ?p=123) ;
  • capte les quatre entrées de l’ancien domaine : HTTP et HTTPS, avec et sans www ;
  • envoie directement vers la forme définitive, en un seul saut.

Avec le fichier .htaccess (Apache)

Placez ces lignes tout en haut du .htaccess qui répond pour l’ancien domaine, avant # BEGIN WordPress et les blocs des extensions de cache. WordPress réécrit tout ce qui se trouve entre ses marqueurs : une règle placée à l’intérieur serait écrasée.

# Permanent redirect from the old domain to the new one
RewriteEngine On
# Let certificate validations of the old domain through (Let's Encrypt HTTP-01)
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
# Old domain, with or without www, over HTTP or HTTPS
RewriteCond %{HTTP_HOST} ^(www\.)?ancien-domaine\.example$ [NC]
# Same path on the new domain; the query string is kept by default
RewriteRule ^(.*)$ https://nouveau-domaine.example/$1 [R=301,L]

La condition sur HTTP_HOST laisse passer les requêtes du nouveau domaine quand les deux partagent le même dossier. Selon la documentation de mod_rewrite, la chaîne de requête est transmise telle quelle par défaut. L’exclusion de /.well-known/acme-challenge/ protège le renouvellement du certificat de l’ancien domaine : Let’s Encrypt suit les redirections pendant la validation et chercherait sinon son fichier sur le nouveau domaine.

La version d’origine de cet article utilisait la directive Redirect, toujours valable si l’ancien domaine a un dossier à lui qui ne contient que ce .htaccess : Apache ajoute le reste du chemin et les paramètres à l’adresse cible. Elle ne filtre ni le domaine ni les validations de certificat, d’où ma préférence pour la règle précédente.

Redirect 301 / https://nouveau-domaine.example/

L’équivalent pour Nginx

Nginx ignore le .htaccess : déclarez un bloc server dédié à l’ancien domaine. La documentation de Nginx préconise un return 301 avec $request_uri, qui contient l’URI d’origine et ses paramètres.

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name ancien-domaine.example www.ancien-domaine.example;

    # Certificate covering both names of the old domain (adjust the paths)
    ssl_certificate     /etc/letsencrypt/live/ancien-domaine.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ancien-domaine.example/privkey.pem;

    # Let certificate validations through (webroot used by your ACME client)
    location ^~ /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    # Same path and query string on the new domain
    location / {
        return 301 https://nouveau-domaine.example$request_uri;
    }
}

Testez la configuration avec nginx -t avant de recharger le service.

Afficher le fichier .htaccess sur macOS

Le Finder masque les fichiers dont le nom commence par un point, comme le .htaccess téléchargé pour être modifié. Dans une fenêtre du Finder, le raccourci Commande + Maj + . (la touche qui porte le point) les affiche ou les masque. Pour les afficher en permanence, passez par le Terminal :

# Always show hidden files in the Finder (use false to revert)
defaults write com.apple.finder AppleShowAllFiles -bool true
killall Finder

Déclarer le changement d’adresse dans la Search Console

Une fois les redirections actives, ouvrez la propriété de l’ancien domaine, puis Paramètres > Changement d’adresse, et choisissez la nouvelle propriété. L’aide de l’outil de changement d’adresse pose ces conditions :

  • être propriétaire des deux propriétés, avec le même compte Google ;
  • utiliser des propriétés au niveau du domaine, sans chemin du type /blog/ ;
  • rediriger en 301 l’ancienne page d’accueil vers la nouvelle, et idéalement toutes les pages canoniques : l’outil en contrôle quelques-unes avant d’accepter la demande ;
  • répéter la demande pour chaque variante de l’ancien domaine, avec et sans www, car l’outil ne déplace pas les sous-domaines.

Soumettez ensuite le sitemap du nouveau domaine dans la nouvelle propriété. Pendant 180 jours, Google privilégie alors l’exploration du nouveau site et lui transfère les signaux de l’ancien.

Combien de temps conserver les redirections ?

Google demande de conserver les redirections aussi longtemps que possible, « généralement au moins un an », et suggère de les garder indéfiniment pour les utilisateurs. L’aide de l’outil de changement d’adresse fixe un minimum de 180 jours et conseille de payer l’ancien domaine au moins un an, pour éviter qu’il soit racheté à des fins malveillantes.

Je recommande de renouveler l’ancien domaine et de laisser les redirections en place sans date de fin : liens entrants, favoris et anciens e-mails continueront de fonctionner. Corrigez en parallèle vos propres liens, car chaque redirection ralentit le visiteur.

Ce qu’il faut mettre à jour ailleurs

Statistiques d’audience

Dans Google Analytics 4, ouvrez Administration > Collecte et modification des données > Flux de données, choisissez le flux et modifiez l’URL du site web, comme l’indique l’aide de Google Analytics. Dans Matomo, ajoutez le nouveau domaine aux URL du site depuis la gestion des sites web. Pour le reste, voir mes guides pour configurer Google Analytics sur WordPress et utiliser Matomo avec WordPress.

E-mails

Si vos adresses changent aussi de domaine, configurez les enregistrements MX, SPF, DKIM et DMARC du nouveau domaine avant la bascule : Gmail exige au minimum SPF ou DKIM de tout expéditeur qui écrit à ses utilisateurs. L’Adresse e-mail d’administration de Réglages > Général ne devient active qu’après confirmation depuis la nouvelle boîte. Vérifiez aussi les expéditeurs des formulaires, de WooCommerce et de la newsletter, et, en cas de souci, voyez comment résoudre les problèmes d’envoi d’e-mails de WordPress.

Cache, CDN et licences

WP Rocket garde des fichiers de configuration nommés d’après le domaine : sa documentation demande de désactiver puis réactiver l’extension, ou d’utiliser le bouton de régénération proposé dans l’administration. Sa licence étant liée au site, retirez l’ancien domaine de votre compte, et faites le même contrôle pour chaque extension premium. Ajoutez le nouveau domaine à votre CDN et videz tous les caches. Si l’ancien domaine passe par Cloudflare en mode proxifié, une règle de redirection Cloudflare peut remplacer le .htaccess, avec l’option Preserve query string activée.

Profils, campagnes et liens entrants

Mettez à jour vos profils sociaux, campagnes publicitaires, signatures d’e-mail et fiches d’annuaires. Contactez ensuite les sites qui vous envoient le plus de liens, repérés grâce au rapport sur les liens de la Search Console.

Les contrôles après la bascule

Testez d’abord les redirections en ligne de commande : chaque URL doit renvoyer un code 301 vers la bonne adresse, paramètres compris, en un seul saut.

# Status code and target of each entry point of the old domain
for url in \
  'http://ancien-domaine.example/' \
  'http://www.ancien-domaine.example/' \
  'https://ancien-domaine.example/' \
  'https://www.ancien-domaine.example/' \
  'https://ancien-domaine.example/mon-article/?utm_source=test'
do
  curl -s -o /dev/null -w "%{http_code} $url -> %{redirect_url}\n" "$url"
done

# Follow the whole chain: expect 1 redirect and a final 200
curl -s -o /dev/null -L -w '%{num_redirects} redirect(s), %{http_code}: %{url_effective}\n' 'http://www.ancien-domaine.example/mon-article/'

Vérifiez ensuite que :

  • la case « Demander aux moteurs de recherche de ne pas indexer ce site » de Réglages > Lecture est décochée ;
  • le robots.txt ne bloque pas l’ancien domaine : Googlebot doit visiter chaque ancienne URL pour découvrir sa redirection ;
  • les balises canonical, le sitemap et les éventuelles annotations hreflang utilisent le nouveau domaine ;
  • wp db search 'ancien-domaine.example' ne renvoie plus que les occurrences voulues ;
  • les formulaires, l’envoi d’e-mails et le tunnel de commande fonctionnent ;
  • les semaines suivantes, le rapport d’indexation des pages de la Search Console ne signale pas de hausse des erreurs 404 ; un crawl avec Screaming Frog, cité par Google, le confirme.

Un changement de domaine touche à la fois au serveur, à la base de données et au référencement. Si vous souhaitez un second regard sur votre plan de redirection ou une aide le jour de la bascule, je peux intervenir dans le cadre du support technique WordPress.

Questions fréquentes

Un changement de nom de domaine fait-il perdre du référencement ?

Pas si les redirections sont correctes : selon Google, les redirections 301 et autres redirections permanentes n’entraînent pas de perte de PageRank. Attendez-vous toutefois à des fluctuations temporaires : pour un site de taille moyenne, Google met quelques semaines ou plus à afficher les nouvelles URL à la place des anciennes.

Faut-il une redirection 301 ou 308 ?

Les deux sont permanentes, et Google recommande l’une ou l’autre pour une migration. J’utilise la 301, celle que l’outil de changement d’adresse contrôle sur vos pages.

Peut-on rediriger toutes les anciennes pages vers la nouvelle page d’accueil ?

Non. Google déconseille de rediriger en masse vers une seule URL sans rapport, comme la page d’accueil : cela déroute les visiteurs et peut être traité comme une erreur de type soft 404. Redirigez chaque page vers son équivalent, et laissez les contenus supprimés répondre en 404 ou 410.

Faut-il l’outil de changement d’adresse pour passer en HTTPS ou retirer le www ?

Non. L’outil sert uniquement à passer d’un domaine ou d’un sous-domaine à un autre. Pour un passage de HTTP à HTTPS, ou de www à sans www sur le même domaine, les redirections et les balises canoniques suffisent.

Avatar de Aurélien Denis
Aurélien Denis
Expert WordPress – Créateur de WP channel et co-fondateur de GuttyCorp – Orateur

Protégez votre site WordPress

Vos données sont précieuses,
ne prenez pas le risque de tout perdre.
Confiez-moi votre maintenance !

Me contacter

Ces articles devraient t’intéresser…