Migrer un domaine WordPress sans perdre le SEO

Si vous avez déjà changé un domaine “vite fait” et découvert trois jours après que Google indexe encore l’ancien, que vos images 404 et que l’admin WordPress vous renvoie sur l’ancienne URL, vous connaissez le vrai problème : ce n’est pas un simple réglage, c’est une chaîne complète à sécuriser.

Ce qu’on va construire

Vous allez mettre en place une procédure de changement de domaine pour WordPress 6.9.4 (avril 2026) qui :

conserve le SEO via des redirections 301 propres (et vérifiables),
évite les pièges WordPress (URLs sérialisées, verrouillage de l’admin, contenu mixte),
limite l’indisponibilité (préparation DNS/TLS + staging),
donne des tests concrets à exécuter avant/après.

C’est destiné aux sites vitrines, blogs éditoriaux et sites avec page builders (Divi 5 / Elementor / Avada). Pour un e-commerce très actif, je vous donne des garde-fous spécifiques (sessions, webhooks, paiements) dans les étapes.

À la fin, vous saurez : préparer le move, modifier WordPress sans vous enfermer dehors, faire un search/replace sans casser la sérialisation, poser des 301 robustes, et envoyer les bons signaux à Google.

Résumé rapide

Préparez : inventaire des URLs, sauvegardes, staging, TTL DNS bas, certificat TLS prêt.
Changez l’URL WordPress (WP_HOME/WP_SITEURL ou admin) sans perdre l’accès.
Faites un search/replace “safe” (WP-CLI recommandé) pour les URLs dans la base.
Déployez des 301 de l’ancien domaine vers le nouveau, en gardant les chemins.
Mettre à jour sitemaps, Search Console, analytics, liens externes critiques.
Testez : 200/301, canonicals, robots, mixed content, logs 404, performances.

Quand utiliser cette solution

Vous changez uniquement le domaine (ex : example.fr → example.com) en gardant la structure d’URLs.
Vous migrez vers un nouvel hébergeur en même temps (possible, mais on sépare les risques).
Votre site est en HTTPS (ou vous en profitez pour passer en HTTPS).
Vous avez accès à l’hébergement (Apache/Nginx) et/ou à un reverse-proxy/CDN.

Quand ne PAS utiliser cette solution

Vous changez domaine + structure de permaliens + arborescence en même temps. Faites-le en deux phases, sinon vous ne saurez pas ce qui casse.
Vous n’avez aucun contrôle sur les redirections côté ancien domaine (cas fréquent quand on “perd” l’ancien). Sans 301, vous perdez une partie du SEO.
Vous avez un multisite et vous ne maîtrisez pas les implications (domain mapping, tables, cookies). La logique est proche, mais les détails changent.
Vous n’avez pas de fenêtre de maintenance et votre site a des transactions en continu (WooCommerce à fort volume). Dans ce cas, prévoyez une stratégie de gel des commandes et une bascule plus encadrée.

Avant de commencer (prérequis)

Versions et environnement

WordPress : 6.9.4 (ou plus récent).
PHP : 8.1+ (recommandé). Vérifiez vos extensions et OPcache.
Accès : FTP/SSH, base de données, panneau DNS, et idéalement WP-CLI.

Sauvegardes (non négociable)

Sauvegarde fichiers (wp-content inclus) + dump SQL.
Testez la restauration sur un staging. J’ai souvent vu des sauvegardes “réussies” mais inutilisables (dump incomplet, tables manquantes).

Outils utiles

WP-CLI (recommandé) pour un search/replace fiable.
Un crawler (Screaming Frog ou équivalent) pour vérifier 301/404.
Accès à la Search Console.

Précautions de sécurité

Ne laissez pas un staging indexable. Ajoutez auth HTTP et/ou robots noindex.
Évitez d’exposer des dumps SQL ou des logs contenant des URLs et tokens.

Étape 1 : Cartographier vos URLs (et figer l’état SEO)

Le but : savoir exactement ce que vous devez préserver. Un changement de domaine “SEO-safe” repose sur une règle simple : chaque URL importante de l’ancien domaine doit répondre 301 vers l’URL équivalente du nouveau domaine.

1) Exporter les URLs clés

Récupérez votre sitemap actuel : https://ancien-domaine.tld/sitemap.xml (WordPress génère des sitemaps nativement).
Exportez les pages/URLs les plus importantes (top trafic) depuis Analytics et Search Console.
Listez les URLs “hors WP” si vous en avez (landing pages statiques, sous-dossiers spéciaux).

2) Noter les paramètres SEO actuels

Vérifiez vos canonicals (source HTML) sur 5–10 pages types.
Notez le fichier robots.txt (virtuel ou réel).
Repérez les éventuelles règles de redirection existantes sur l’ancien domaine.

3) Diagnostic rapide avant migration (table)

Symptôme	Cause probable	Vérification	Solution
Des URLs 404 déjà présentes	Liens internes cassés / médias manquants	Logs serveur + crawler	Corriger avant le move, sinon vous masquez le problème
Canonical pointe vers une autre URL	Plugin SEO / réglage “URL canonique”	Voir le HTML + réglages SEO	Corriger avant la bascule
Beaucoup d’URLs avec paramètres	Filtres, facettes, tracking	Search Console & logs	Définir la stratégie (laisser, bloquer, canonicaliser)

Résultat attendu : un fichier (ou doc) listant vos URLs critiques et la règle de correspondance vers le nouveau domaine.

Étape 2 : Préparer DNS, hébergement et TLS sans casser l’indexation

Voici ce qui se passe en coulisses : le jour J, si le DNS met 24h à se propager et que le TLS n’est pas prêt, vous aurez une fenêtre où Googlebot et vos visiteurs tombent sur des erreurs. Ça se paye.

1) Baisser le TTL DNS (48h avant)

Dans votre zone DNS (chez votre registrar / Cloud DNS), baissez le TTL des enregistrements concernés (A/AAAA/CNAME) à 300s ou 600s au moins 48h avant la bascule.

2) Préparer le TLS du nouveau domaine

Générez/installez le certificat (Let’s Encrypt ou autre) sur le serveur cible.
Vérifiez la chaîne complète et le renouvellement.

Si vous utilisez un CDN/proxy (Cloudflare, Fastly…), préparez aussi le mode SSL et les règles de cache.

3) Préparer l’hébergement

Créez le vhost du nouveau domaine (et idéalement l’ancien aussi, si vous hébergez les deux au même endroit).
Préparez la version PHP 8.1+ et les extensions (intl, mbstring, curl, mysqli/pdo_mysql).

Résultat attendu : le nouveau domaine répond en HTTPS sur une page de test (même temporaire), sans erreurs TLS.

Étape 3 : Cloner sur un staging et valider la migration avant production

Sur des sites intermédiaires, le staging vous évite 80% des catastrophes (surtout avec des builders qui stockent des URLs partout).

1) Créer un staging isolé

Dupliquez fichiers + base sur un sous-domaine (ex : staging.nouveau-domaine.tld) ou un domaine technique.
Protégez-le par mot de passe (auth HTTP) et bloquez l’indexation.

2) Bloquer l’indexation du staging

Deux couches recommandées :

Auth HTTP (la meilleure).
Et côté WordPress : Réglages → Lecture → “Demander aux moteurs…” (ce n’est pas une garantie, mais ça aide).

3) Vérifier que le staging est fonctionnel avant toute modification

Connexion wp-admin OK
Front OK
Pas d’erreurs PHP dans les logs

Résultat attendu : un staging identique au site actuel, prêt pour les manipulations de domaine.

Étape 4 : Changer l’URL WordPress proprement (sans vous verrouiller dehors)

Le piège classique : changer “Adresse web de WordPress” et “Adresse web du site” dans l’admin, puis se retrouver redirigé vers l’ancien domaine, ou bloqué par un cache/proxy. Je préfère une approche contrôlée via wp-config.php, le temps de stabiliser.

Méthode A (recommandée) : définir WP_HOME et WP_SITEURL

Éditez le fichier wp-config.php (à la racine WordPress) et ajoutez ces lignes au-dessus de /* That's all, stop editing! */.

<?php
// Forcer l'URL du site pendant la migration de domaine.
// À placer dans wp-config.php au-dessus de "That's all, stop editing!".
define('WP_HOME', 'https://nouveau-domaine.tld');
define('WP_SITEURL', 'https://nouveau-domaine.tld');

// Optionnel : si vous êtes derrière un proxy/CDN qui termine le SSL.
// À activer uniquement si votre serveur voit du HTTP alors que le visiteur est en HTTPS.
/*
if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
	$_SERVER['HTTPS'] = 'on';
}
*/

Où cliquer / quoi faire : via FTP/SFTP ou SSH, éditez wp-config.php avec un éditeur qui respecte l’encodage (évitez Word). Sauvegardez, puis rechargez le front et /wp-admin.

Résultat attendu : WordPress génère les URLs sur le nouveau domaine, et l’admin est accessible sur le nouveau domaine.

Méthode B : modifier en admin (utile si vous n’avez pas accès fichiers)

Dans le staging : Réglages → Général → changez :

Adresse web de WordPress (URL)
Adresse web du site (URL)

Je la déconseille sur un site avec cache agressif. Si ça tourne mal, vous devrez passer par la base ou wp-config.

Méthode C : WP-CLI (rapide et scriptable)

# Remplacez les domaines par les vôtres
wp option update home "https://nouveau-domaine.tld"
wp option update siteurl "https://nouveau-domaine.tld"

Référence options : get_option() (developer.wordpress.org).

Étape 5 : Recherche/remplacement sûr dans la base (URLs, médias, sérialisation)

Le problème vient de la sérialisation : beaucoup de données stockées par WordPress et les plugins (builders inclus) sont sérialisées. Un remplacement SQL naïf (UPDATE ... REPLACE()) casse les longueurs et peut rendre des pages illisibles ou provoquer des erreurs.

1) WP-CLI search-replace (recommandé)

Exécutez d’abord un dry-run pour voir ce qui sera modifié.

# À exécuter à la racine WordPress (là où se trouve wp-config.php)
# --dry-run : n'écrit rien, affiche un aperçu
wp search-replace "https://ancien-domaine.tld" "https://nouveau-domaine.tld" --all-tables --precise --dry-run

Si le résultat vous semble cohérent, lancez la commande réelle :

# Remplacement réel
wp search-replace "https://ancien-domaine.tld" "https://nouveau-domaine.tld" --all-tables --precise

# Si vous aviez aussi du HTTP historique (fréquent sur les vieux sites)
wp search-replace "http://ancien-domaine.tld" "https://nouveau-domaine.tld" --all-tables --precise

–all-tables : inclut les tables non standard (plugins/builders).
–precise : plus lent mais plus sûr sur les données complexes.

WP-CLI : wp search-replace.

2) Ajuster les GUID ? Non.

Vous verrez parfois des tutos qui modifient la colonne guid dans wp_posts. Évitez. Le GUID n’est pas une URL “à mettre à jour” au sens SEO, c’est un identifiant. WordPress lui-même a une doc claire sur l’esprit du GUID. Dans la pratique, je laisse le GUID tranquille, sauf cas très spécifiques (et jamais pour “réparer” du SEO).

3) Vérifier les URLs “cachées” (builders, widgets, options)

Après le search/replace, faites une recherche ciblée dans la base (lecture seule) pour repérer d’éventuels restes.

# Cherche encore l'ancien domaine dans la DB (selon votre shell)
wp db query "SELECT COUNT(*) AS nb FROM wp_options WHERE option_value LIKE '%ancien-domaine.tld%';"
wp db query "SELECT COUNT(*) AS nb FROM wp_posts WHERE post_content LIKE '%ancien-domaine.tld%';"

Résultat attendu : la majorité des occurrences de l’ancien domaine a disparu des contenus/options, sans casser les pages.

Étape 6 : Mettre les redirections 301 (Apache/Nginx + cas Woo)

Sans 301, vous perdez une partie des signaux (liens entrants, historique). La règle : ancien domaine → nouveau domaine, en conservant le chemin et la query string.

Option 1 : Apache (.htaccess)

Sur l’hébergement de l’ancien domaine (ou vhost qui sert l’ancien), ajoutez en haut du .htaccess (avant les règles WordPress si possible) :

# .htaccess (Apache) - redirection 301 de domaine à domaine
# À placer avant le bloc WordPress si vous pouvez
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?ancien-domaine.tld$ [NC]
RewriteRule ^ https://nouveau-domaine.tld%{REQUEST_URI} [R=301,L]

Note : ce snippet est volontairement minimal. Si vous avez des sous-domaines, des exceptions, ou des environnements (staging), adaptez.

Option 2 : Nginx (server block)

Dans le serveur qui répond à l’ancien domaine :

# Nginx - redirection 301 vers le nouveau domaine
server {
	listen 80;
	listen 443 ssl http2;
	server_name ancien-domaine.tld www.ancien-domaine.tld;

	# ... config SSL si vous écoutez en 443 ...

	return 301 https://nouveau-domaine.tld$request_uri;
}

Cas WooCommerce / sites avec comptes

Gardez les 301, mais vérifiez les pages de compte/checkout après bascule (cookies, sessions, cache).
Si vous aviez des webhooks (Stripe, PayPal, Shipstation…), ils pointent souvent vers l’ancien domaine : il faut les mettre à jour (voir Étape 9).

Résultat attendu : toute URL de l’ancien domaine renvoie une 301 vers la même URL sur le nouveau domaine (même chemin).

Étape 7 : Sitemaps, Search Console, analytics et signaux de changement

Les redirections font le gros du travail, mais vous devez aussi “déclarer” le nouveau domaine aux outils et remettre les sitemaps dans le circuit.

1) Vérifier et soumettre le sitemap sur le nouveau domaine

Ouvrez https://nouveau-domaine.tld/sitemap.xml.
Assurez-vous qu’il référence des URLs du nouveau domaine.

Doc sitemaps WP : WP Sitemaps API.

2) Google Search Console

Ajoutez et validez la propriété du nouveau domaine.
Soumettez le sitemap du nouveau domaine.
Surveillez Couverture/Indexation et les erreurs 404.

3) Analytics / Tag Manager

Mettez à jour le domaine dans les réglages si nécessaire.
Vérifiez que les scripts se chargent bien (pas bloqués par CSP, consent, cache).

4) Mettre à jour les backlinks “faciles”

Vous ne contrôlez pas tous les liens entrants, mais vous contrôlez souvent :

profils sociaux,
Google Business Profile,
annuaires clés,
signatures email,
partenaires.

Étape 8 : Traquer le contenu mixte, les assets cassés et les caches

Après un changement de domaine, les symptômes les plus fréquents que je vois : CSS/JS non chargés (cache), images en HTTP (contenu mixte), et pages builder qui gardent des URLs en dur.

1) Purger tous les caches (dans le bon ordre)

Cache plugin (si présent)
Cache serveur (Varnish/NGINX microcache)
Cache CDN
Cache navigateur (testez en navigation privée)

2) Détecter le contenu mixte

Ouvrez DevTools → Console / Network et cherchez “mixed content”.
Recherchez des http://ancien-domaine restants via WP-CLI (Étape 5).

3) Regénérer les permaliens

Dans l’admin : Réglages → Permaliens → cliquez Enregistrer (sans rien changer). Ça force la régénération des règles de réécriture.

Doc : flush_rewrite_rules() (à ne pas appeler à chaque page, mais ici c’est un acte volontaire).

Résultat attendu : aucune ressource critique (CSS/JS/images) ne pointe vers l’ancien domaine, et les pages chargent sans erreurs console.

Étape 9 : Vérifier emails, WP-Cron, API externes et webhooks

Ce sont les “dommages collatéraux” qui coûtent cher parce qu’ils ne se voient pas immédiatement.

1) Emails (SPF/DKIM/DMARC)

Si vous envoyez des emails depuis le domaine (newsletter, transactional), mettez à jour SPF/DKIM/DMARC.
Testez l’envoi de mails (mot de passe perdu, formulaire).

2) WP-Cron

Vérifiez que les tâches planifiées tournent (sauvegardes, publications programmées).
Si vous avez un cron système, vérifiez qu’il pointe vers la bonne URL.

3) APIs, webhooks et callbacks

Stripe/PayPal : URL de webhook
ReCAPTCHA : domaines autorisés
OAuth (Google, Facebook) : URLs de callback
Services de cache : purge hooks

Résultat attendu : les intégrations externes continuent de fonctionner, et les tâches planifiées s’exécutent.

Le résultat complet

Si vous voulez une vue “copier-coller” des éléments techniques les plus courants, voici un assemblage minimal : forçage d’URL (temporaire) + redirection serveur. Adaptez les domaines.

1) wp-config.php

<?php
// Migration de domaine : forcer les URLs WordPress.
// À retirer une fois la migration stabilisée (optionnel, mais je le fais souvent).
define('WP_HOME', 'https://nouveau-domaine.tld');
define('WP_SITEURL', 'https://nouveau-domaine.tld');

// Si vous êtes derrière un proxy qui termine le SSL, décommentez si nécessaire.
/*
if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
	$_SERVER['HTTPS'] = 'on';
}
*/

2) Redirection Apache (.htaccess) sur l’ancien domaine

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?ancien-domaine.tld$ [NC]
RewriteRule ^ https://nouveau-domaine.tld%{REQUEST_URI} [R=301,L]

3) Commandes WP-CLI (search/replace)

wp search-replace "https://ancien-domaine.tld" "https://nouveau-domaine.tld" --all-tables --precise
wp search-replace "http://ancien-domaine.tld" "https://nouveau-domaine.tld" --all-tables --precise

Personnalisation

Si vous passez de www à sans www (ou l’inverse), faites-le en même temps que le domaine, mais gardez une seule version canonique.
Si vous changez aussi de protocole (HTTP → HTTPS), traitez-le dans le search/replace et assurez-vous que le serveur force HTTPS.
Pour des exceptions (ex : ne pas rediriger /.well-known/), ajoutez des règles avant le return 301 / RewriteRule.

Adapter pour Divi 5 / Elementor / Avada

Les builders stockent souvent des URLs d’images/boutons dans des structures JSON/sérialisées. WP-CLI gère généralement bien le remplacement, mais il reste des cas où il faut “forcer” une régénération.

Divi 5

Après migration, ouvrez 2–3 pages Divi représentatives et re-sauvegardez. Ça déclenche souvent une normalisation des données.
Si vous utilisez la génération de CSS statique/optimisations Divi, purge/rebuild depuis les options Divi (et purgez le cache).

Elementor

Elementor a une fonctionnalité de remplacement d’URL dans ses outils (selon version). Même si vous avez fait WP-CLI, je vérifie souvent qu’il n’y a pas de restes dans les templates.
Regénérez CSS & Data (dans les outils Elementor) après la bascule pour éviter des assets compilés avec l’ancien domaine.

Avada

Avada/Fusion stocke des contenus complexes. WP-CLI fonctionne bien, mais je recommande un passage dans les outils Avada pour régénérer le CSS compilé et purger les caches.
Testez les sliders, portfolios et éléments dynamiques : ce sont souvent eux qui gardent des URLs en dur.

Vérification finale

Je valide toujours la migration avec une batterie de tests simples, répétables, et orientés “SEO + UX”.

1) Tests HTTP (301/200) sur un échantillon d’URLs

# Vérifier une URL de l'ancien domaine : doit répondre 301 vers le nouveau
curl -I "https://ancien-domaine.tld/une-page/"

# Vérifier la destination : doit répondre 200
curl -I "https://nouveau-domaine.tld/une-page/"

2) Canonical et hreflang

Sur le nouveau domaine, vérifiez que <link rel="canonical"> pointe vers le nouveau domaine.
Si site multilingue, vérifiez hreflang.

3) Crawl rapide

Crawlez le nouveau domaine (200 attendus).
Crawlez l’ancien domaine (301 attendus, pas de chaînes 301→302→200).

4) Logs serveur et erreurs 404

Surveillez les 404 sur le nouveau domaine.
Surveillez les hits sur l’ancien domaine : ils doivent diminuer progressivement.

5) Search Console

Soumission sitemap OK
Pas d’explosion d’erreurs d’exploration
Indexation du nouveau domaine qui démarre

Si le résultat n’est pas celui attendu

Problème 1 : vous êtes redirigé vers l’ancien domaine (impossible d’accéder à wp-admin)

Cause probable : options home/siteurl encore sur l’ancien domaine, cache, ou règles proxy.
Vérification : regardez la redirection dans l’onglet Network, et vérifiez WP_HOME/WP_SITEURL dans wp-config.php.
Solution : forcez WP_HOME/WP_SITEURL (Étape 4) puis purge cache.

Problème 2 : pages OK mais images/CSS cassés

Cause probable : contenu mixte, URLs en dur, cache builder/CDN.
Vérification : console navigateur “mixed content”, recherche ancien-domaine dans la DB.
Solution : WP-CLI search/replace + régénération CSS du builder + purge caches.

Problème 3 : redirections en boucle (ERR_TOO_MANY_REDIRECTS)

Cause probable : conflit entre redirection HTTPS, redirection domaine, et proxy.
Vérification : suivez la chaîne avec curl -I et regardez les en-têtes Location.
Solution : gardez une seule logique au niveau edge (CDN) ou serveur, pas les deux en double.

Problème 4 : 301 OK mais SEO chute (indexation lente)

Cause probable : canonicals incorrects, sitemap pas soumis, robots/noindex, ou trop de chaînes de redirection.
Vérification : source HTML, robots, Search Console.
Solution : corrigez canonicals, soumettez sitemap, supprimez chaînes, gardez 301 stables.

Problème 5 : erreurs PHP après migration

Cause probable : PHP trop ancien sur le nouveau serveur, extension manquante, plugin incompatible.
Vérification : logs PHP-FPM/Apache, écran critique WordPress.
Solution : passez en PHP 8.1+, mettez à jour plugins/thèmes, désactivez le plugin fautif via renaming dossier si besoin.

Pièges et erreurs courantes

Erreur	Cause	Solution
Faire un `REPLACE()` SQL direct sur la base	La sérialisation casse les longueurs	Utilisez `wp search-replace` avec `--precise`
Changer l’URL en admin puis perdre l’accès	Redirection immédiate + cache	Forcez `WP_HOME`/`WP_SITEURL` dans `wp-config.php`
Oublier de purger le cache CDN	Le CDN sert encore l’ancien HTML	Purge complète + bypass cache pendant les tests
Tester en production sans staging	Vous découvrez les cas builder en live	Clone staging, validez, puis bascule
Chaînes de redirection (301→302→301…)	Règles doublées (serveur + plugin + CDN)	Centralisez les redirections au même endroit
Permaliens cassés après bascule	Règles de rewrite non régénérées	Réglages → Permaliens → Enregistrer
Snippet collé au mauvais endroit	Ajout dans functions.php au lieu de .htaccess/nginx	Les 301 doivent être côté serveur (ou edge), pas dans le thème
Code d’un vieux tuto incompatible	Vieilles pratiques, hooks inadaptés	Restez sur WP-CLI + réglages WP + redirections serveur

Variante / alternative

Alternative 1 : migration “sans SSH” avec un plugin (pragmatique)

Si vous n’avez pas WP-CLI, un plugin de migration peut faire le search/replace correctement (en gérant la sérialisation). Choisissez un plugin maintenu et compatible WP 6.9.4.

Procédure : export → import sur nouveau domaine → outil de remplacement d’URL → redirections 301 côté ancien domaine.
Risque : certains plugins excluent des tables custom, ou ne gèrent pas bien de très gros volumes.

Alternative 2 : approche “edge” via CDN (avancé)

Si l’ancien domaine passe par un CDN/proxy, vous pouvez poser les 301 au niveau edge. C’est souvent plus rapide à déployer et plus robuste qu’un .htaccess sur un vieux serveur.

Avantage : latence faible, règles centralisées.
Attention : évitez de cumuler edge + serveur + plugin.

Conseils sécurité, performance et maintenance

Gardez l’ancien domaine au moins 12 à 24 mois si possible. J’ai vu des sites perdre des liens entrants “longue traîne” parce que le domaine a expiré après 3 mois.
Surveillez les logs 404 et corrigez les URL manquantes par des redirections ciblées (pas seulement la redirection globale).
Performance : après migration, revalidez HTTP/2/HTTP/3, compression, cache headers, et le warmup cache.
Sécurité : vérifiez que l’admin n’est pas exposée via l’ancien domaine (qui redirige bien), et que le TLS est propre (HSTS si vous maîtrisez).
Maintenance : une fois stabilisé, vous pouvez retirer WP_HOME/WP_SITEURL si vous préférez gérer via la DB, mais je les garde parfois sur des setups avec reverse-proxy pour éviter les surprises.

Pour aller plus loin

Mettre en place un monitoring automatique des 404 et des chaînes de redirection (alerting).
Ajouter des redirections spécifiques pour les URLs qui changent (si vous profitez de la migration pour nettoyer).
Mettre en place des tests de non-régression (smoke tests) via curl ou un outil CI.
Si vous avez beaucoup de médias, envisager une stratégie de offload (S3) — mais pas le même jour que le changement de domaine.

Ressources

FAQ

Dois-je garder l’ancien domaine ?

Oui. Gardez-le au minimum 12 mois si vous pouvez. Les liens entrants et les signaux mettent du temps à se transférer complètement, et certains backlinks “ressortent” des mois plus tard.

301 ou 302 ?

Pour un changement de domaine définitif, c’est 301. Une 302 indique un déplacement temporaire et transfère moins bien les signaux.

Combien de temps pour que Google prenne en compte le nouveau domaine ?

Ça dépend de la taille du site et du crawl budget. Sur un blog moyen, j’observe souvent quelques jours à quelques semaines pour une stabilisation, avec des fluctuations normales.

Puis-je faire le changement de domaine et de permaliens en même temps ?

Techniquement oui, mais je ne le recommande pas. Vous multipliez les variables et les risques. Faites d’abord le domaine (301 simples), puis la structure (redirections ciblées) plus tard.

Faut-il mettre à jour la colonne GUID ?

Non dans la majorité des cas. Le GUID sert d’identifiant. Le modifier n’est pas une “optimisation SEO” et peut avoir des effets de bord avec des flux/agrégateurs.

Pourquoi mes images pointent encore vers l’ancien domaine après search/replace ?

Souvent à cause d’un cache (builder/CDN) ou de contenus stockés dans des meta/options non standards. Refaites une recherche dans wp_options et régénérez les assets du builder.

Est-ce que WordPress met à jour automatiquement les liens internes après changement de domaine ?

Non. WordPress met à jour home/siteurl, mais pas le contenu de vos articles/pages. D’où le search/replace.

Que faire si je n’ai pas accès au serveur de l’ancien domaine pour mettre des 301 ?

Si vous ne pouvez pas rediriger l’ancien domaine, vous perdrez une partie des bénéfices SEO. Essayez au minimum de récupérer l’accès DNS/hébergement, ou mettez en place une solution edge si le domaine passe par un CDN.

Dois-je re-soumettre toutes mes URLs à l’indexation ?

Soumettez surtout le sitemap du nouveau domaine. Pour quelques pages critiques, une demande d’indexation peut aider, mais ce n’est pas nécessaire à grande échelle.

Les réseaux sociaux vont-ils mettre à jour les aperçus (Open Graph) ?

Pas toujours immédiatement. Purgez les caches de partage (Facebook Debugger, etc.) et vérifiez que vos meta OG pointent vers le nouveau domaine.

Quel est le test le plus fiable pour valider les 301 ?

curl -I et un crawler. Vous cherchez : 301 unique depuis l’ancien domaine vers le nouveau, puis 200 sur la destination, sans boucle ni chaîne.