Comment changer l’URL WP sans la casser

Publié le 12 mai 2026

Si vous devez changer l’URL WP, faites-le dans un ordre maîtrisé : sauvegardez d’abord, mettez à jour l’adresse WordPress et l’adresse du site, puis corrigez les redirections, le SSL et tous les liens codés en dur. La plupart des pannes ne viennent pas du changement d’URL lui-même, mais des éléments autour qui pointent encore vers l’ancien emplacement. Le site web n’est généralement pas fâché — il suit simplement des réglages obsolètes.

Cette tâche se présente lors des changements de domaine, du passage de HTTP à HTTPS, du déplacement de WordPress dans un sous-répertoire ou d’une migration de préproduction vers la production. Pour les propriétaires de boutiques, les agences et les équipes SaaS, un mauvais changement d’URL peut entraîner des boucles de connexion, des avertissements de contenu mixte, un accès administrateur cassé ou des formulaires envoyés au mauvais endroit. L’objectif n’est donc pas seulement de modifier deux champs. L’objectif est de garder toute l’application calme.

Ce que le changement de l’URL WP affecte réellement

Dans WordPress, il existe deux réglages fondamentaux : l’adresse WordPress et l’adresse du site. Ils se ressemblent parce que, franchement, c’est le cas. Mais ils ont des rôles différents.

L’adresse WordPress est l’endroit où se trouvent les fichiers principaux de WordPress. L’adresse du site est l’URL publique que les visiteurs utilisent pour accéder au site. Dans de nombreuses configurations, elles sont identiques. Dans d’autres, WordPress peut se trouver dans un sous-répertoire tandis que le site se charge depuis le domaine racine.

Si vous en modifiez une de manière incorrecte, WordPress peut vous rediriger hors de wp-admin, envoyer les ressources vers le mauvais domaine ou créer une boucle de redirection infinie. Les extensions, les thèmes, la base de données, le serveur web et les règles CDN peuvent aussi encore référencer l’URL précédente. C’est pourquoi un changement correct relève à la fois de WordPress et de l’hygiène d’infrastructure.

Avant de changer l’URL WP

Effectuez une sauvegarde récente des fichiers et de la base de données. S’il s’agit d’un site e-commerce ou d’un site de contenu très fréquenté, effectuez le travail pendant une période de faible trafic. Un changement d’URL peut toucher les pages en cache, les cookies de session et les callbacks de paiement, donc le timing compte.

Vous devez aussi confirmer quatre points avant de faire des modifications. Premièrement, le nouveau domaine ou le protocole pointe déjà vers le bon serveur. Deuxièmement, le certificat SSL est actif si vous passez à HTTPS. Troisièmement, votre hôte virtuel du serveur web ou votre bloc serveur Nginx est prêt pour le nouveau nom d’hôte. Quatrièmement, vous savez si WordPress se trouve derrière un proxy, un load balancer ou un CDN qui peut forcer des redirections.

Si l’un de ces éléments n’est pas en place, WordPress peut être correctement configuré et tout de même échouer publiquement. Les journaux racontent alors la même histoire.

Les moyens les plus sûrs de changer l’URL

Le changer dans l’administration WordPress

Si vous avez encore accès à l’administration, c’est la méthode la plus propre. Allez dans Réglages, puis Général. Mettez à jour l’adresse WordPress et l’adresse du site avec la nouvelle URL. Enregistrez les modifications.

Cela fonctionne bien lorsque le déplacement est simple et que le nouveau domaine pointe déjà correctement vers le site. Juste après l’enregistrement, reconnectez-vous si nécessaire et testez la page d’accueil, la zone d’administration, la bibliothèque de médias et quelques pages internes.

Le risque est évident : si vous saisissez la mauvaise URL, ou si le nouvel hôte n’est pas totalement prêt, vous pouvez vous exclure vous-même du tableau de bord.

Le changer dans wp-config.php

Si le tableau de bord n’est pas accessible ou si vous voulez plus de contrôle, définissez les valeurs directement dans wp-config.php. Ajoutez ces lignes au-dessus de la ligne d’arrêt des modifications :

define('WP_HOME','https://example.com'); define('WP_SITEURL','https://example.com');

Cela force WordPress à utiliser les valeurs du fichier de configuration. C’est souvent la méthode de récupération la plus rapide pour les boucles de connexion ou les redirections d’administration cassées.

C’est aussi un bon stabilisateur temporaire pendant les migrations. Une fois que tout fonctionne, vous pouvez conserver ces constantes en place ou les supprimer et gérer à nouveau les valeurs depuis l’administration.

Le changer dans la base de données

Si ni l’administration ni l’édition de la configuration ne sont disponibles, vous pouvez mettre à jour les valeurs dans la base de données, généralement dans la table wp_options. Les noms des options sont home et siteurl.

Cela fonctionne, mais c’est plus manuel et plus facile à mal faire si vous êtes pressé. Sur les sites avec des préfixes de table personnalisés, ne supposez pas que la table est wp_options. Vérifiez d’abord.

C’est en passant de HTTP à HTTPS que les gens sont surpris

Beaucoup de demandes pour changer l’URL wp sont en réalité des migrations HTTPS déguisées. Le changement visible semble minime, mais les navigateurs, les cookies et le chargement des ressources ne sont pas d’accord.

Après être passé de HTTP à HTTPS dans les réglages WordPress, confirmez que le certificat SSL est valide et installé pour le bon nom d’hôte. Ensuite, mettez à jour les redirections de votre serveur afin que les requêtes HTTP soient redirigées de manière permanente vers HTTPS. Si votre site se trouve derrière un reverse proxy ou un CDN, assurez-vous que WordPress peut détecter correctement HTTPS, sinon il risque de rediriger sans fin.

Le contenu mixte est le visiteur habituel suivant. Les pages se chargent en HTTPS, mais les images, scripts, polices ou CSS appellent encore des URL HTTP. Cela peut casser les mises en page ou déclencher des avertissements du navigateur. Vous pourriez avoir besoin d’un search-and-replace dans la base de données pour les anciennes URL absolues, surtout si le site a été construit avec un constructeur de pages ou des champs personnalisés stockant des liens complets.

Recherchez et remplacez les anciennes URL avec précaution

Modifier les deux réglages fondamentaux ne réécrit pas les anciens liens stockés dans les articles, les métadonnées, le contenu des widgets ou les réglages d’extension. Si l’ancien domaine apparaît en dur dans la base de données, les utilisateurs l’atteindront toujours.

C’est là qu’un search-and-replace correct, sûr pour les données sérialisées, devient important. N’exécutez pas un remplacement imprudent en texte brut sur un fichier SQL exporté en espérant que tout ira bien. Certaines données d’extensions et d’options sont sérialisées, et un mauvais remplacement peut corrompre les longueurs et casser les réglages.

Si vous utilisez un flux de migration professionnel, exécutez un outil qui comprend la sérialisation WordPress. Vérifiez ensuite les mises en page du constructeur de pages, les menus, les URL d’images, les balises canoniques, les réglages Open Graph et toute extension qui stocke des callbacks ou des URL d’API.

Problèmes courants après un changement d’URL

La page de connexion continue de rediriger

Cela signifie généralement que WordPress, le serveur web ou un proxy ne sont pas d’accord sur le schéma ou le nom d’hôte correct. Vérifiez WP_HOME et WP_SITEURL, puis inspectez les règles de redirection du serveur. Si la terminaison SSL se fait en amont, WordPress peut avoir besoin que l’en-tête HTTPS transmis soit géré correctement.

Les cookies peuvent aussi être liés à l’ancien domaine. Effacez les cookies du navigateur et testez dans une fenêtre privée avant de supposer que le site est maudit.

wp-admin est inaccessible

Si l’URL d’administration vous envoie au mauvais endroit, forcez les bonnes valeurs dans wp-config.php. Cela permet souvent de récupérer immédiatement le tableau de bord. Examinez aussi .htaccess ou les règles Nginx à la recherche d’un ancien comportement de réécriture.

Les images ou le CSS sont cassés

Cela indique des URL codées en dur ou du contenu mixte. Recherchez l’ancien domaine dans la base de données et inspectez les outils de développement du navigateur pour voir quelles ressources appellent encore l’URL précédente.

Chaînes ou boucles de redirection

Elles se produisent généralement lorsque WordPress redirige d’une façon et que le serveur web ou le CDN redirige d’une autre. Réduisez la logique à un seul jeu de règles clair. Si possible, gérez le nom d’hôte canonique et les redirections HTTPS à un seul endroit.

Les formulaires, webhooks ou callbacks de paiement échouent

Les services externes peuvent toujours publier vers l’ancien domaine. Vérifiez les URL de passerelle de paiement, les chemins de retour SMTP, les points de terminaison webhook et les intégrations tierces. Sur les sites d’adhésion ou d’e-commerce, c’est là que se produisent les pertes de revenus silencieuses.

Quand l’adresse WordPress et l’adresse du site doivent être différentes

La plupart des sites devraient les garder identiques. Mais il existe des exceptions valides. Si WordPress est installé dans un sous-répertoire comme /wordpress alors que le site public se charge depuis la racine du domaine, alors l’adresse du site peut être l’URL racine et l’adresse WordPress l’URL du sous-répertoire.

Cette configuration peut être utile pour l’organisation des fichiers, mais elle ajoute de la complexité. Si vous ne le faites pas intentionnellement, ne l’inventez pas au milieu d’une migration. Les configurations simples échouent moins souvent.

Un ordre pratique qui évite les temps d’arrêt

Utilisez une courte fenêtre de maintenance, confirmez d’abord le DNS, le SSL et la configuration du serveur, puis changez les URL WordPress. Après cela, exécutez le search-and-replace dans la base de données, videz les caches et testez les chemins clés : page d’accueil, administration, formulaires, tunnel d’achat, médias, points de terminaison API et comportement cron.

Si le site utilise la mise en cache d’objets, la mise en cache de pages complètes ou un CDN, purgez tout après le changement. D’anciennes redirections en cache peuvent faire paraître un site sain cassé pendant encore 20 minutes, ce qui n’est pas la plus belle situation DNS, mais reste sous contrôle.

Pour les sites critiques pour l’activité, préparez d’abord le changement dans un environnement de test. Chez Kodu.cloud, c’est exactement le type de tâche pour lequel le support d’infrastructure gérée s’amortit — non pas parce que changer une URL est impossible, mais parce que ce sont les petites vérifications autour qui évitent les mauvaises surprises.

Vérifications finales après avoir changé l’URL WP

Ouvrez le site dans une nouvelle session de navigateur et testez à la fois avec et sans www si c’est pertinent. Confirmez le cadenas SSL, inspectez quelques URL source et assurez-vous que l’administration, la connexion, les téléversements de médias et les formulaires de contact se comportent tous normalement. Si les moteurs de recherche ont déjà indexé l’ancien domaine, laissez des redirections correctes en place suffisamment longtemps pour que le trafic et les signaux de classement se déplacent proprement.

Un changement d’URL WP est généralement une tâche courte lorsque l’environnement est prêt. Cela ne devient une longue soirée que lorsque le DNS, le SSL, les règles du serveur, le cache et les références de base de données sont autorisés à se disputer. Gardez-les dans la même direction, et le service redevient calme.

Andres Saar Ingénieur Customer Care