Changer de domaine WordPress sans rien casser

La première fois que j’ai migré un site WordPress vers un nouveau domaine, j’ai fait la chose « évidente » : une grosse requête de chercher-remplacer directement dans la base de données. Dix minutes plus tard, la page d’accueil se chargeait sans broncher — et chaque page Elementor n’était plus qu’un mur de blocs cassés. J’avais corrompu les données sérialisées, et j’ai passé la soirée à restaurer une sauvegarde que j’avais eu la chance d’avoir. Un changement de domaine fait partie de ces chantiers où la méthode naïve détruit votre site en silence, et où la bonne méthode prend environ une minute. Voici la bonne méthode.

L’essentiel

• Votre domaine vit dans des milliers de lignes de base de données, pas seulement dans les options siteurl et home que vous voyez dans les Réglages.
• Les constructeurs de pages (Elementor, Divi…) et WooCommerce stockent les URL sous forme de données sérialisées ; un remplacement SQL brut les corrompt en cassant les longueurs de caractères enregistrées.
• Le module Domain Changer désérialise, remplace et resérialise correctement, en attrapant les références https://, http:// et les URL relatives au protocole en //domaine.
• Il prévisualise le nombre exact de lignes qu’il va modifier, table par table, et sauvegarde d’abord votre base de données (activé par défaut).
• Si quelque chose cloche, un clic annule le changement entier — et il ne réécrit jamais le GUID des articles, exactement comme WordPress le recommande.

Pourquoi un simple chercher-remplacer ne fonctionne-t-il pas ?

Parce que la plupart de vos références au domaine ne sont pas du texte brut. Des plugins comme Elementor, Divi et WooCommerce stockent leurs données sérialisées — un format PHP où chaque valeur est préfixée par son nombre exact de caractères, comme s:23:"https://example.com/page". Ce 23, c’est la longueur de la chaîne qui suit.

Maintenant, remplacez example.com par monnouveausite.org avec une requête SQL brute. Le texte s’allonge, mais le 23 enregistré ne bouge pas. PHP essaie de lire 23 caractères, atterrit au milieu de votre nouvelle URL et abandonne : la valeur est devenue illisible. Concrètement, cela donne des mises en page de constructeur en miettes, des widgets vides et des réglages de plugins remis à néant. C’est l’unique raison pour laquelle les migrations de domaine tournent mal, et c’est pourquoi il vous faut un outil qui comprend les données sérialisées au lieu de traiter la base de données comme un fichier texte.

Voici tous les endroits où votre ancien domaine se cache réellement — et ce qui casse si une référence est oubliée :

Où le domaine se cache	Ce qui y est stocké	Si on ne le change pas
siteurl et home	Les deux options de Réglages → Général	Rien — ce sont les seules lignes que l’écran des Réglages met à jour
Liens internes et images	Le contenu de vos articles et pages	Liens et médias continuent de pointer vers l’ancien domaine et finissent en 404
Mises en page des constructeurs	Métadonnées d’articles sérialisées (Elementor, Divi…)	Un remplacement brut casse la longueur enregistrée et pulvérise la mise en page
Réglages des widgets et plugins	Options de plugins et données de widgets sérialisées	Widgets vides et réglages remis à néant
URL relatives au protocole	Les références en //domaine que les thèmes utilisent souvent	Les assets restent accrochés à l’ancien hôte
GUID des articles	La colonne guid de chaque article	N’y touchez pas — la réécrire fait réapparaître chaque article comme nouveau dans les lecteurs de flux

Dans quels cas faut-il changer de domaine ?

Le déclencheur est presque toujours l’un de ceux-ci :

• Mettre en ligne un site depuis une URL de préproduction ou de développement vers la production.
• Changer de marque avec un nouveau nom de domaine.
• Quitter un sous-domaine (blog.example.com) pour le domaine racine, ou l’inverse.
• Migrer depuis localhost vers un vrai serveur.

Passer de HTTP simple à HTTPS est un chantier voisin mais différent — le module HTTPS Redirect s’en charge plus proprement qu’une réécriture complète du domaine. Et si vous changez de domaine, rappelez-vous que les anciens liens entrants vers le domaine précédent doivent recevoir des redirections 301 pour ne pas perdre leur SEO.

Comment changer de domaine WordPress en toute sécurité, étape par étape ?

Activez le module Domain Changer dans Blaminhor Essentials. Au lieu d’une requête aveugle, il parcourt chaque table de la base, désérialise ce qui doit l’être, remplace le domaine, recalcule les longueurs et resérialise — donc rien ne se corrompt.

Le domaine actuel détecté pour vous, le nouveau domaine dans un seul champ, et une prévisualisation qui compte chaque ligne avant d’en modifier une seule.

Étape 1 — Sauvegardez d’abord (c’est automatique)

Avec « sauvegarder avant le changement » activé — le réglage par défaut — le module écrit un dump SQL complet de votre base avant de toucher à quoi que ce soit, et se branche sur le module Backup si vous l’avez actif, pour que l’archive atterrisse au même endroit que vos autres sauvegardes. C’est votre filet de sécurité, et il est en place sauf si vous le désactivez délibérément.

Étape 2 — Saisissez le nouveau domaine

Le domaine actuel est détecté automatiquement depuis l’URL de votre site. Vous tapez le nouveau — sans http:// ni https://, juste monnouveausite.com. Le module gère les trois formes de référence en coulisses : https://, http://, et le //monnouveausite.com relatif au protocole que les thèmes utilisent souvent.

Étape 3 — Prévisualisez les changements exacts

Cliquez sur prévisualiser et le module scanne chaque table, en rapportant combien de lignes vont changer dans chacune — « 142 lignes dans postmeta », « 38 lignes dans options », et ainsi de suite, avec un total cumulé. Rien n’est encore écrit. Vous voyez toute l’étendue des dégâts potentiels avant de valider, exactement la confiance qu’une requête SQL brute ne vous donnera jamais.

Étape 4 — Appliquez

Un clic lance le remplacement sur toute la base : il met à jour les options siteurl et home, puis chaque autre table — contenu des articles, métadonnées, widgets, réglages des plugins — avec les données sérialisées traitées correctement de bout en bout. Comme l’URL de votre administration vient elle-même de changer, le module vous redirige vers le tableau de bord du nouveau domaine une fois terminé, pour ne pas vous laisser face à une page morte.

Et si quelque chose semble encore cassé ?

C’est là que le module dépasse le stade du « espérons que la sauvegarde fonctionne ». Après un changement, il enregistre la migration dans son historique et allume un bouton « Annuler ce changement ». Cliquez dessus et le module rejoue le remplacement à l’envers — en échangeant les deux domaines dans l’autre sens — puis vide l’historique pour ne pas pouvoir se déclencher deux fois. C’est une véritable annulation à un niveau, pas une restauration manuelle.

Vous avez donc deux filets, pas un : la sauvegarde automatique d’avant-changement pour un retour arrière complet, et l’annulation intégrée pour le cas courant du « ce n’était pas ça, remets comme avant ». Sur une installation multisite, les sauvegardes sont même conservées par site, donc annuler la migration d’un site ne touche pas les autres.

La méthode sûre pour migrer est aussi la plus rapide

Les changements de domaine traînent une réputation de galère disproportionnée, et tout tient à ce seul piège de la sérialisation. Traitez-le correctement et l’ensemble prend moins d’une minute : prévisualiser, confirmer, terminé — avec une sauvegarde derrière vous et un bouton d’annulation devant vous.

Une fois sur le nouveau domaine, mettez en place des redirections 301 depuis les anciennes URL pour préserver votre classement dans les moteurs, et si ce n’est pas encore fait, forcez le HTTPS sur tout le site pour finir la migration proprement.

Domain Changer est l’un des plus de 20 outils de Blaminhor Essentials — gratuit et open source sur WordPress.org.

Télécharger Blaminhor Essentials

– blaminhor