Les points essentiels avant de changer une URL WordPress
- WordPress Address et Site Address ne servent pas exactement au même usage, même s’ils se ressemblent.
- Si l’interface est verrouillée, c’est souvent parce que `WP_HOME` et `WP_SITEURL` sont définis dans `wp-config.php`.
- Après un changement d’adresse, je régénère toujours les permaliens pour éviter les routes cassées.
- Les liens d’images, les menus et certains contenus anciens gardent souvent l’ancienne URL en dur.
- Une redirection 301 propre est indispensable dès qu’une URL publiée change réellement.
Ce qu’il faut distinguer avant de toucher aux réglages
La première erreur consiste à tout mélanger. Dans WordPress, l’adresse du site, l’adresse de l’installation et le permalien d’un article sont trois choses différentes. La documentation officielle de WordPress distingue bien WordPress Address (URL) et Site Address (URL), et cette nuance change complètement la méthode à utiliser.
En pratique, je raisonne comme ça :
- Changer le domaine ou passer de `http` à `https` concerne l’adresse globale du site.
- Déplacer WordPress d’un sous-dossier vers la racine demande de séparer temporairement l’adresse de l’installation et l’adresse publique.
- Modifier l’URL d’une page précise revient surtout à changer son slug, pas toute la structure du site.
- Changer la structure des permaliens concerne les liens des articles, des pages, des catégories et des archives, pas l’hébergement lui-même.
Quand on a cette carte en tête, on évite 80 % des manipulations inutiles. Une fois cette distinction claire, on peut choisir la méthode la plus sûre.
Modifier l’adresse depuis l’interface quand c’est encore possible
Quand le tableau de bord répond encore et que les champs ne sont pas verrouillés, c’est la voie la plus propre. Je commence toujours par une sauvegarde complète, puis je vais dans Réglages > Général pour ajuster les deux champs d’URL.
- Ouvrir Réglages > Général.
- Modifier WordPress Address (URL) si l’emplacement des fichiers core change.
- Modifier Site Address (URL) si l’adresse publique change.
- Enregistrer, puis se reconnecter via `/wp-admin` ou `/wp-login.php` si nécessaire.
- Si le site passe en `https`, vérifier que le certificat SSL est actif avant d’aller plus loin.
Dans un site installé dans un sous-dossier, cette distinction est importante. Par exemple, WordPress peut vivre dans `https://exemple.fr/blog` pendant que l’adresse visible par les visiteurs reste `https://exemple.fr`. C’est une configuration normale, pas une anomalie.
Si vous déplacez aussi les fichiers, ne vous arrêtez pas au réglage dans l’admin. Il faut ensuite déplacer les répertoires, vérifier que le serveur réécrit bien les URL, puis rouvrir le site avec les nouvelles adresses. Quand les champs sont gris ou que l’accès admin a disparu, je passe à la couche inférieure.
Passer par wp-config.php ou la base de données quand l’admin est bloquée
Quand les champs sont grisés dans l’interface, c’est souvent parce que l’adresse est déjà définie dans wp-config.php. Dans ce cas, WordPress n’autorise plus la modification depuis le tableau de bord. C’est utile pour verrouiller une installation, mais moins pratique si l’on veut revenir en arrière.
define( 'WP_HOME', 'https://exemple.fr' );
define( 'WP_SITEURL', 'https://exemple.fr' );Je réserve cette approche aux cas où je veux débloquer rapidement un site ou maîtriser finement une migration. Voici comment je compare les méthodes les plus courantes :
| Méthode | Quand je l’utilise | Avantage | Limite |
|---|---|---|---|
| Interface WordPress | Le site est encore accessible et les champs sont modifiables | Simple, rapide, peu risqué | Impossible si l’URL est verrouillée ou si le site est cassé |
wp-config.php |
Je veux forcer une URL pendant une migration ou un dépannage | Immédiat et fiable | Les champs deviennent non éditables dans l’admin |
| Base de données | Le site ne répond plus ou l’admin est inaccessible | Permet de corriger une installation bloquée | Plus sensible aux erreurs, donc backup obligatoire |
Dans la base, les valeurs importantes sont généralement dans `wp_options`, sous les entrées `home` et `siteurl`. Sur un site déjà en production, je fais aussi un vrai search-and-replace pour les anciennes URL présentes dans les contenus, les images, les widgets et parfois les réglages de certains plugins. Sur un gros site, j’utilise volontiers WP-CLI plutôt qu’une correction manuelle, parce que c’est plus propre et plus reproductible.
Une fois l’adresse correcte en place, il faut remettre les permaliens en ordre pour éviter que les anciennes routes ne renvoient vers le vide.
Reconfigurer les permaliens pour éviter les 404 et garder un lien propre
Changer l’adresse du site ne règle pas automatiquement la structure des liens internes. Dans WordPress, les permaliens sont les URLs permanentes des articles, pages, catégories et archives. Je les traite comme un chantier à part, parce qu’ils influencent à la fois l’ergonomie, le référencement et la stabilité des liens partagés.
Dans la plupart des cas, je passe par Réglages > Permaliens et je vérifie trois choses :
- La structure choisie correspond bien au type de site.
- Je n’ai pas collé l’URL complète dans le champ de structure personnalisée, seulement des balises comme `%postname%`.
- Je clique à nouveau sur Enregistrer, même si je n’ai rien changé, pour forcer WordPress à réécrire les règles.
Pour un site éditorial ou un blog, je privilégie souvent `/%postname%/` parce qu’elle reste lisible, courte et stable. Les structures avec date ont du sens quand la chronologie est importante, mais elles alourdissent vite les liens si le contenu doit rester valable longtemps. Les structures personnalisées sont utiles, mais je les garde pour des cas précis, pas pour faire joli.
Si vos catégories ou vos tags doivent utiliser un préfixe différent, c’est aussi dans cette section que cela se règle. Le point de vigilance, ici, c’est le serveur : si les jolis permaliens ne fonctionnent pas, le problème vient parfois de la réécriture d’URL côté hébergement, pas de WordPress lui-même. Le vrai risque, ensuite, ce sont les erreurs de transition.
Les erreurs qui cassent le plus souvent un changement d’URL
La partie délicate n’est pas la modification en elle-même, mais tout ce qu’elle laisse derrière elle. Dans les migrations que je vois le plus souvent, les bugs viennent rarement d’un seul gros oubli ; ils viennent de plusieurs petits détails mal alignés.
- Changer seulement une des deux URL alors que l’autre reste sur l’ancien domaine.
- Oublier le HTTPS après un passage en `https`, ce qui provoque du contenu mixte ou des alertes de sécurité.
- Ne pas purger le cache du site, du navigateur ou du CDN, ce qui masque les vrais résultats.
- Laisser les anciens liens en dur dans les images, les menus, les widgets ou les constructeurs de pages.
- Ne pas prévoir de redirection 301 quand une ancienne URL publique doit continuer à exister pour les visiteurs et les moteurs de recherche.
- Confondre changement de slug et changement global : modifier une page ne met pas à jour tout le site.
Je garde aussi un œil sur les types de contenu personnalisés. Une extension qui gère ses propres règles de réécriture peut continuer à servir des 404 même si le site principal semble correct. Dans ce cas, il ne faut pas forcer au hasard : il faut vérifier les règles de réécriture, puis réenregistrer la structure des permaliens. Une fois ces pièges écartés, il reste la partie la plus rentable : le contrôle qualité.
Les vérifications à faire juste après le changement
Je ne considère jamais une bascule comme terminée tant que je n’ai pas testé le site comme un visiteur externe. Sur un site simple, je prévois souvent 15 à 30 minutes de vérification; sur un site plus dense, cela peut prendre davantage si je dois corriger des liens internes ou des médias.
- Ouvrir la page d’accueil dans une fenêtre privée.
- Tester au moins une page, un article, une catégorie et un média.
- Vérifier que l’ancienne URL renvoie bien vers la nouvelle via une redirection 301.
- Vider le cache du site, du CDN et du navigateur.
- Relancer le sitemap si un plugin SEO le génère automatiquement.
- Contrôler les erreurs 404 dans les logs ou dans l’outil de suivi du site pendant les 24 à 48 heures suivantes.
Je fais aussi un tour dans les menus et dans les réglages du thème, parce que certaines adresses sont parfois stockées ailleurs que dans les articles eux-mêmes. Si l’on a déplacé WordPress d’un sous-dossier vers la racine, il faut être encore plus attentif aux anciens chemins absolus. C’est souvent là que les corrections les plus discrètes font gagner le plus de temps.
La règle que je garde pour un changement d’URL qui tient dans le temps
Je procède toujours dans le même ordre : sauvegarde complète, changement de l’adresse, réécriture des permaliens, redirections, puis vérification. Quand on inverse cette logique, on finit à corriger des effets de bord au lieu de traiter la cause.
Sur un site WooCommerce, un multisite ou un blog avec beaucoup d’archives, je recommande de tester la bascule sur une copie de préproduction avant de toucher au domaine public. C’est plus long au départ, mais nettement moins coûteux qu’une remise en état après coup. C’est, à mon avis, la seule façon de transformer une modification d’URL en opération propre plutôt qu’en chaîne de correctifs improvisés.
