Vous avez déplacé un site vers un nouveau domaine, et il est hors ligne. Ou bien il s’ouvre, mais sans les styles. Ou encore l’interface d’administration refuse de vous laisser entrer. Toute personne ayant migré manuellement un site WordPress a déjà vécu ce moment: la base de données se souvient encore de l’ancienne URL, et le site essaie désespérément de charger des ressources depuis une adresse qui n’existe plus.

Quatre requêtes SQL dans phpMyAdmin règlent le problème en cinq minutes. Pas d’extension, pas de WP-CLI, pas de panique. Voici un guide pas à pas, depuis la recherche du domaine actuel jusqu’à la vérification finale. Avec des adaptations pour les préfixes de table non standard, le HTTPS et les données sérialisées.

💡 Aperçu rapide:

• Trouver le domaine actuel dans la table wp_options: les champs siteurl et home
• Exécuter quatre requêtes UPDATE dans l’onglet SQL de phpMyAdmin
• Réinitialiser le mot de passe administrateur via wp_users si l’interface d’administration refuse l’accès
• Enregistrer les permaliens dans les réglages WordPress pour rétablir les styles
• Pour les boutiques et les multisites, utiliser Better Search Replace ou WP-CLI: un simple REPLACE casse les tableaux sérialisés

Par où commencer: trouver le domaine actuel dans la base de données

Avant de procéder au remplacement, assurez-vous de connaître le domaine actuellement défini pour le site. Cela vous fera gagner du temps si le site a déjà été déplacé auparavant et qu’une troisième URL «intermédiaire» pourrait subsister dans la base.

Ouvrez phpMyAdmin, sélectionnez la base de données du site et repérez la table wp_options. Elle contient deux lignes: siteurl (l’adresse de WordPress) et home (l’adresse du site). Ce sont ces valeurs que nous allons modifier en premier.

Si le préfixe de table n’est pas standard (par exemple, mysite_ au lieu de wp_), cherchez la table mysite_options. Vous trouverez le préfixe dans le fichier wp-config.php: la variable $table_prefix.

Quatre requêtes SQL pour un remplacement complet du domaine

Exécutez chaque requête l’une après l’autre dans l’onglet «SQL» de phpMyAdmin. Avant de les lancer, veillez à sauvegarder la base de données: une exportation via phpMyAdmin prend une minute et vous protège des erreurs irréversibles.

Remplacez http://www.oldurl par http://www.newurl dans toutes les requêtes ci-dessous. Si le site fonctionne en HTTPS, utilisez https:// dans les deux adresses.

1. Mise à jour de HOME et SITEURL

Cette opération modifie les deux adresses clés dans wp_options. Sans cette étape, le site ne s’ouvrira tout simplement pas sur le nouveau domaine; WordPress continuera d’essayer de rediriger vers l’ancien.

1
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

2. Mise à jour des GUID des articles

Le champ guid de la table wp_posts stocke l’identifiant permanent de chaque article. Le remplacer n’est pas critique pour le fonctionnement du site; WordPress n’utilise pas le GUID pour le routage. Mais si des personnes lisent votre site via des lecteurs RSS, la propreté des GUID a son importance: les anciennes URL dans le flux généreront des liens brisés.

1
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl', 'http://www.newurl');

3. Mise à jour du contenu des articles

La requête la plus volumineuse. post_content contient le texte de toutes les pages et de tous les articles, y compris les images intégrées et les liens internes. Après l’avoir exécutée, toutes les images présentes dans le contenu se chargeront depuis le nouveau domaine.

1
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

4. Mise à jour des champs meta

Champs personnalisés, réglages d’extensions, données de thème: tout cela est stocké dans wp_postmeta. Sautez cette requête et vous obtiendrez des liens brisés dans des endroits inattendus: le logo dans le pied de page, l’arrière-plan dans l’outil de personnalisation, l’URL dans votre extension SEO.

1
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.oldurl', 'http://www.newurl');

Après avoir exécuté les quatre requêtes, ouvrez le site sur le nouveau domaine. Si tout a été fait correctement, il ne devrait pas y avoir de problème. Mais il arrive parfois autre chose: un message «Erreur d’établissement d’une connexion à la base de données» ou la page qui s’ouvre sans les styles.

La première chose dont vous avez besoin dans cette situation, c’est l’accès à l’interface d’administration.

Comment accéder à l’interface d’administration si le mot de passe est perdu ou si le site refuse l’accès

Le client n’a pas laissé de mot de passe. Ou vous vous êtes bloqué vous-même en changeant le domaine, et /wp-admin vous renvoie dans une redirection infinie. Voici deux méthodes pour obtenir les droits administrateur directement via la base de données.

Réinitialiser le mot de passe administrateur via phpMyAdmin

Ouvrez la table wp_users (votre préfixe peut être différent: mysite_users, etc.). Trouvez l’utilisateur disposant des droits administrateur et cliquez sur «Modifier»:

Dans la ligne user_pass, sélectionnez la fonction MD5 dans la liste déroulante et saisissez le nouveau mot de passe dans le champ adjacent. Cliquez sur «Exécuter»:

Remarque: WordPress moderne utilise phpass (hachages bcrypt), pas MD5. Mais lorsque vous saisissez un mot de passe WordPress, il vérifie le hachage de manière séquentielle: si la vérification bcrypt échoue, il essaie la solution de secours MD5 et re-hache immédiatement le mot de passe dans le format actuel. C'est pourquoi le MD5 via phpMyAdmin fonctionne comme une clé temporaire.

Créer un administrateur via PHP

Une autre méthode consiste à ajouter un nouvel utilisateur administrateur de manière programmatique. Le code s'insère dans le fichier functions.php du thème actif ou via un MU-plugin.

Ajoutez ce qui suit au functions.php de votre thème enfant:

1
function sdstudio_add_admin_user() {
2
    $userdata = array(
3
        'user_login' => 'tempadmin',
4
        'user_pass'  => 'TempPass123!',
5
        'user_email' => '[email protected]',
6
        'role'       => 'administrator',
7
    );
8
    wp_insert_user( $userdata );
9
}
10
add_action( 'init', 'sdstudio_add_admin_user' );

La fonction wp_insert_user() crée un utilisateur avec les paramètres fournis, et le hook init se déclenche à chaque requête WordPress. Ouvrez simplement une page du site une fois, et l'utilisateur est créé.

Après vous être connecté au panneau d'administration, veillez à supprimer à la fois la fonction du functions.php et l'utilisateur temporaire que vous avez créé. Laisser tempadmin avec un mot de passe en clair constitue une faille de sécurité.

Corriger les images et les styles cassés après un changement de domaine

Vous avez accès au panneau d'administration, mais les images ne se chargent pas et la mise en page est cassée. Dans neuf cas sur dix, une simple opération suffit.

Allez dans «Réglages» → «Permaliens»:

Ne changez rien; cliquez simplement sur «Enregistrer les modifications»:

WordPress reconstruira la structure des URL, mettra à jour le cache des règles de réécriture et videra le cache de redirection interne. Après cela, les images retrouvent généralement leur place.

Si cela n'a pas aidé, cela signifie que l'ancien domaine est intégré dans des tableaux sérialisés. Un simple REPLACE en SQL les casse: la longueur de la chaîne dans un tableau sérialisé est codée en dur sous forme de nombre, et remplacer «ancien-long-domaine.ru» par «nouveau-court.io» modifie cette longueur, rendant le tableau illisible. Installez l'extension gratuite Better Search Replace; elle gère correctement la sérialisation et vous montre combien de correspondances ont été trouvées dans chaque table avant le remplacement.

Pour les sites avec WP-CLI, c'est encore plus simple avec une commande:

1
wp search-replace 'http://olddomain.ru' 'https://newdomain.io' --all-tables --dry-run

L'option --dry-run affiche d'abord ce qui sera remplacé sans effectuer de modifications. Une fois que vous êtes sûr, exécutez-la sans l'option. La commande search-replace de WP-CLI gère également les données sérialisées et le fait plus rapidement que l'interface web.

La vidéo ci-dessous montre l'ensemble du processus, de la connexion à phpMyAdmin à la vérification du site après le remplacement:

⁉️🤔 Foire aux questions

Est-il obligatoire d'utiliser phpMyAdmin pour remplacer le nom de domaine?

Non. Si le site n'a pas encore été déplacé, Duplicator ou All-in-One WP Migration effectuent le remplacement automatiquement lors du déploiement. Si le site est déjà sur le nouvel hébergement sans accès à l'administration, il ne vous reste que les requêtes SQL via phpMyAdmin, Adminer ou WP-CLI. Pour la plupart des webmasters, phpMyAdmin est la méthode la plus directe et la plus contrôlée: vous voyez chaque opération au lieu de faire confiance à la boîte noire d'une extension.

Que faire si le préfixe des tables n'est pas wp_?

Vérifiez la valeur de la constante $table_prefix dans le fichier wp-config.php. Il s'agit généralement de wp_, mais les hébergeurs ou les extensions de sécurité comme Solid Security (anciennement iThemes Security) le modifient parfois pour une valeur aléatoire. Dans toutes les requêtes ci-dessus, remplacez wp_ par votre préfixe (par exemple, xyz123_options au lieu de wp_options).

Pourquoi le site s'affiche-t-il sans styles après le remplacement?

L'ancien domaine est resté dans les réglages du thème, le cache ou le CDN. Réinitialisez les permaliens (instructions ci-dessus) et videz le cache de votre extension de cache. Si vous utilisez Cloudflare ou un autre CDN, purgez le cache côté fournisseur. Si cela n'a pas suffi, lancez Better Search Replace: l'ancienne URL est probablement intégrée dans un tableau sérialisé theme_mods_*.

Le site est en HTTPS, mais après le déménagement, le certificat ne fonctionne pas. Que faire?

Assurez-vous d'avoir utilisé https:// (et non http://) dans toutes les requêtes. Vérifiez que les deux adresses dans les réglages WordPress, après connexion à l'administration, commencent par https://. Le certificat SSL lui-même se configure côté hébergement, via le panneau de contrôle ou Let's Encrypt gratuit. Il s'agit d'une procédure distincte, sans rapport avec la base de données.

Puis-je remplacer le domaine sans accès à phpMyAdmin?

Oui. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. FTP uniquement: ajoutez les lignes define('WP_HOME','http://newdomain'); et define('WP_SITEURL','http://newdomain'); dans wp-config.php. Cela remplace temporairement les adresses et vous donne accès à l'administration. Après connexion, supprimez ces lignes et enregistrez les réglages via l'interface.

Dois-je modifier le GUID dans wp_posts, ou puis-je l'ignorer?

Ce n'est pas nécessaire au fonctionnement du site. WordPress n'utilise pas le GUID pour le routage, seulement pour identifier les articles dans les flux RSS. Si des personnes lisent activement votre site via RSS, le remplacement a un sens. Sinon, vous pouvez sauter la troisième des quatre requêtes sans conséquence.

Après avoir remplacé le domaine via SQL, certains réglages d'extension ont disparu. Pourquoi?

Des extensions comme WooCommerce, Advanced Custom Fields et les sliders stockent des URL dans des tableaux sérialisés dans wp_postmeta. Un simple REPLACE ne tient pas compte du compteur de longueur de chaîne dans la sérialisation et casse la structure. La solution est Better Search Replace ou wp search-replace (ils désérialisent le tableau, remplacent la chaîne et resérialisent le tout). Si vous avez déjà cassé la structure, restaurez la base de données depuis la sauvegarde et refaites le remplacement avec le bon outil.

Que faire dans les cas complexes: boutiques, multisites et bases volumineuses

Le remplacement de domaine via SQL est une procédure de cinq minutes si vous avez un accès direct à phpMyAdmin et un préfixe de table standard. Mais il existe des situations où le remplacement manuel par REPLACE est réellement risqué.

Des boutiques en ligne sous WooCommerce avec des centaines de milliers de commandes. Des réseaux multisites avec des dizaines de tables distinctes pour chaque sous-site. Des sites où les URL sont codées en dur dans des tableaux sérialisés (réglages de thème, constructeurs de pages, sliders). Dans ces cas, un simple REPLACE SQL peut endommager la structure des données, et restaurer la base depuis la sauvegarde prendra plus de temps que de faire un remplacement précis du premier coup.

Better Search Replace ou la commande search-replace de WP-CLI gèrent la sérialisation; utilisez-les. Et si la base de données dépasse le gigaoctet et que le coût d'une erreur est élevé, une heure de travail d'un développeur spécialisé coûtera moins cher que la restauration d'une boutique dont l'indisponibilité coûte de l'argent.

Nous avons traité le sujet de la migration de site en préservant le SEO et sans perte de trafic dans un guide dédié. Et si vous rencontrez une erreur spécifique après le remplacement, écrivez en commentaire, nous vous aiderons à diagnostiquer.