Adresse WordPress vs Adresse du site : Différences techniques, configuration et pièges courants

WordPress Address (URL) et Site Address (URL) sont deux paramètres de configuration distincts qui contrôlent, respectivement, l’emplacement des fichiers core de WordPress sur le serveur et l’URL que le public utilise pour accéder au front-end de votre site'. Dans la plupart des installations standard, les deux valeurs sont identiques, mais elles peuvent — et doivent parfois — diverger lorsque vous hébergez les fichiers WordPress dans un sous-répertoire tout en servant le site depuis le domaine racine.

Une erreur sur ces deux valeurs, même d’un seul caractère, peut vous bloquer l’accès au tableau de bord d’administration, déclencher des avertissements de contenu mixte, casser les endpoints de l’API REST et corrompre les chaînes de redirection. Les sections ci-dessous expliquent la logique architecturale derrière chaque paramètre, chaque scénario légitime pour les modifier, et les méthodes exactes pour le faire en toute sécurité.

La logique architecturale derrière les deux paramètres URL

WordPress stocke sa configuration URL à deux endroits simultanément : la table de base de données wp_options (lignes siteurl et home) et, optionnellement, le fichier wp-config.php via des constantes PHP. Comprendre quelle source a la priorité est essentiel avant de toucher quoi que ce soit.

Ordre de priorité (du plus élevé au plus bas) :

1. Constantes définies dans wp-config.php (WP_SITEURL, WP_HOME)
2. Valeurs stockées dans la table wp_options
3. Valeurs saisies dans Réglages > Général dans le tableau de bord

Lorsqu’une constante est définie dans wp-config.php, le champ correspondant dans Réglages > Général devient en lecture seule et grisé. C’est intentionnel — cela empêche les écrasements accidentels via l’interface tout en permettant un contrôle programmatique.

WordPress Address (URL) — WP_SITEURL

L’adresse WordPress correspond à l’option siteurl dans wp_options et à la constante WP_SITEURL dans wp-config.php. Elle indique à WordPress où résident physiquement ses fichiers PHP core, le répertoire wp-admin et le répertoire wp-includes. WordPress utilise cette valeur pour construire chaque référence de chemin de fichier interne, y compris l’URL de connexion à l’administration, les endpoints AJAX (/wp-admin/admin-ajax.php) et la base de l’API REST (/wp-json/).

Exemple : si votre installation WordPress se trouve à https://example.com/wordpress, alors WP_SITEURL doit être https://example.com/wordpress. Naviguer vers https://example.com/wordpress/wp-admin permettra d’accéder au tableau de bord.

Site Address (URL) — WP_HOME

L’adresse du site correspond à l’option home dans wp_options et à la constante WP_HOME dans wp-config.php. Elle définit l’URL publique canonique — l’adresse que les utilisateurs saisissent dans leur navigateur et la base à partir de laquelle WordPress génère toutes les structures de permaliens front-end.

Exemple : même si les fichiers core se trouvent à https://example.com/wordpress, vous pouvez définir WP_HOME sur https://example.com afin que la page d’accueil, les articles et les pages soient servis depuis le domaine racine. Cela nécessite un fichier index.php supplémentaire et une règle .htaccess à la racine (détaillé ci-dessous).

Comparaison : WordPress Address vs Site Address

Quand ces deux valeurs doivent différer

La raison légitime la plus courante pour séparer WP_SITEURL et WP_HOME est le modèle d’installation en sous-répertoire : vous souhaitez isoler les fichiers WordPress dans un sous-répertoire propre (par exemple, /wordpress ou /cms) tandis que le site public se résout au niveau du domaine racine. Il s’agit d’un choix architectural délibéré, et non d’une solution de contournement.

Autres scénarios nécessitant la mise à jour d’une ou des deux valeurs :

• Migration de domaine — passer de http://old-domain.com à https://new-domain.com nécessite de mettre à jour les deux valeurs simultanément.
• Passage de HTTP à HTTPS — l’ajout d’un certificat SSL implique de modifier le préfixe de protocole dans les deux paramètres de http:// à https://. Ne mettre à jour qu’un seul génère des erreurs de contenu mixte.
• Promotion de l’environnement de staging vers la production — un environnement de staging fonctionne généralement sur un sous-domaine ou un domaine différent ; les deux valeurs doivent être réécrites lors du déploiement.
• Proxy inverse ou déchargement CDN — lorsqu’un équilibreur de charge ou un CDN termine le SSL et transfère le trafic vers un serveur backend, les paramètres URL de WordPress doivent refléter le domaine public, et non l’adresse du serveur interne.
• Reconfiguration du réseau Multisite — dans WordPress Multisite, WP_SITEURL et WP_HOME interagissent avec les constantes DOMAIN_CURRENT_SITE et PATH_CURRENT_SITE, rendant une configuration correcte encore plus critique.

Méthode 1 : Mise à jour via le tableau de bord WordPress

C’est la méthode appropriée lorsque vous avez encore accès à l’administration et que la modification est simple (par exemple, HTTP vers HTTPS sur le même domaine).

1. Connectez-vous à https://yourdomain.com/wp-admin.
2. Naviguez vers Réglages > Général.
3. Localisez les champs WordPress Address (URL) et Site Address (URL).
4. Mettez à jour les deux valeurs selon vos besoins.
5. Cliquez sur Enregistrer les modifications.

WordPress vous redirigera immédiatement vers l’URL d’administration mise à jour. Si vous avez changé le domaine, votre navigateur suivra la redirection vers la nouvelle adresse. Si le nouveau domaine ne pointe pas encore vers le serveur, vous perdrez l’accès au tableau de bord — planifiez la propagation DNS en conséquence.

Méthode 2 : Définir des constantes dans wp-config.php

Cette méthode est préférable sur les serveurs de production car elle empêche les modifications accidentelles via l’interface, fonctionne même lorsque la base de données est temporairement indisponible, et est facilement gérée par contrôle de version. Dans un environnement d’hébergement VPS avec accès SSH root, c’est l’approche la plus fiable.

Ouvrez wp-config.php dans votre éditeur préféré :

nano /var/www/html/wp-config.php

Ajoutez les deux lignes suivantes au-dessus du commentaire /* That's all, stop editing! */ :

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

Pour le modèle d’installation en sous-répertoire où les fichiers core se trouvent dans /wordpress mais le site est servi depuis la racine :

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

Enregistrez et fermez le fichier. Les champs du tableau de bord seront désormais en lecture seule, ce qui est le comportement attendu.

Installation en sous-répertoire : les étapes requises pour .htaccess et index.php

Lorsque WP_HOME et WP_SITEURL diffèrent, WordPress seul ne peut pas router les requêtes du domaine racine vers les fichiers core dans le sous-répertoire. Vous devez placer un fichier index.php modifié et un fichier .htaccess à la racine du document.

Étape 1 : Copiez index.php depuis le sous-répertoire WordPress vers la racine :

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Étape 2 : Modifiez le fichier /var/www/html/index.php copié pour qu’il pointe vers le sous-répertoire :

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Étape 3 : Assurez-vous que votre .htaccess racine contient le bloc de réécriture WordPress standard :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ne pas copier le fichier .htaccess depuis le sous-répertoire — il contiendra RewriteBase /wordpress/ ce qui cassera le routage du domaine racine.

Méthode 3 : Mise à jour directe de la base de données via WP-CLI

Lorsque le tableau de bord est inaccessible et que vous préférez ne pas modifier wp-config.php de façon permanente, WP-CLI fournit une solution propre et scriptable. C’est particulièrement utile sur les serveurs dédiés exécutant des pipelines de déploiement automatisés.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Pour vérifier que la modification a été appliquée :

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI respecte les constantes wp-config.php — si WP_SITEURL ou WP_HOME sont déjà définies dans ce fichier, la commande wp option update ne les remplacera pas. Vous devez mettre à jour les constantes directement dans le fichier.

Méthode 4 : Mise à jour directe MySQL (dernier recours)

Utilisez cette méthode uniquement lorsque l’accès SSH est disponible mais que WP-CLI n’est pas installé et que le tableau de bord est verrouillé. Identifiez d’abord votre préfixe de table (vérifiez $table_prefix dans wp-config.php, généralement wp_).

mysql -u db_user -p db_name

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

Confirmez la mise à jour :

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

Quittez MySQL et videz tout cache d’objets (Redis, Memcached ou OPcache) avant de tester le site.

Configuration SSL et mises à jour des URL

Le passage de HTTP à HTTPS est la raison la plus courante pour mettre à jour les deux paramètres URL simultanément. Après l’installation d’un certificat SSL — que ce soit via Let's Encrypt avec Certbot ou un certificat commercial d’un fournisseur comme ceux disponibles via Certificats SSL — vous devez mettre à jour WP_HOME et WP_SITEURL pour utiliser le préfixe https://.

Ne pas mettre à jour les deux, ou n’en mettre à jour qu’un seul, génère des avertissements de contenu mixte : le navigateur reçoit une page HTTPS qui référence des ressources HTTP (scripts, feuilles de style, images). Les navigateurs modernes bloquent entièrement le contenu actif mixte, ce qui casse les fonctionnalités JavaScript et le tableau de bord d’administration.

Après avoir mis à jour les constantes URL, effectuez une recherche et remplacement dans la base de données pour mettre à jour toutes les URL sérialisées stockées dans le contenu des articles, les postmeta et les options :

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

L’indicateur --all-tables garantit que les données sérialisées dans les tables personnalisées (WooCommerce, constructeurs de pages) sont également mises à jour. Effectuez toujours une sauvegarde de la base de données avant d’exécuter cette commande.

Configuration des URL WordPress avec cPanel

Si vous gérez WordPress sur un VPS avec cPanel, vous pouvez utiliser le Gestionnaire de fichiers cPanel pour modifier wp-config.php sans nécessiter d’accès SSH :

1. Connectez-vous à cPanel et ouvrez le Gestionnaire de fichiers.
2. Naviguez vers la racine de votre document WordPress (généralement public_html ou un sous-répertoire).
3. Faites un clic droit sur wp-config.php et sélectionnez Modifier.
4. Ajoutez les constantes WP_HOME et WP_SITEURL comme indiqué dans la Méthode 2.
5. Enregistrez le fichier.

Vous pouvez également utiliser l’outil phpMyAdmin dans cPanel pour exécuter les instructions SQL UPDATE de la Méthode 4 directement sur votre base de données WordPress.

Pièges critiques et cas particuliers

Incompatibilité de protocole entre les deux paramètres. Définir WP_SITEURL sur https://example.com et WP_HOME sur http://example.com (ou vice versa) crée une boucle de redirection. Le navigateur suit la redirection HTTPS du serveur, mais WordPress génère des liens front-end HTTP, que le serveur redirige ensuite vers HTTPS. Cette boucle est invisible dans le tableau de bord mais dévastatrice pour les robots d’exploration et les utilisateurs.

Incohérence des barres obliques finales. WordPress est sensible aux barres obliques finales dans ces constantes. https://example.com et https://example.com/ sont traités comme des valeurs différentes. Omettez toujours la barre oblique finale dans les deux constantes pour correspondre aux attentes internes de WordPress.

Empoisonnement du cache d’objets après un changement d’URL. Si votre serveur exécute un cache d’objets persistant (Redis ou Memcached), les anciennes valeurs d’URL peuvent être mises en cache en mémoire même après la mise à jour de la base de données. Videz le cache d’objets immédiatement après tout changement d’URL :

wp cache flush --path=/var/www/html

Données sérialisées dans la base de données. WordPress stocke de nombreuses valeurs d’options et métadonnées d’articles sous forme de chaînes sérialisées PHP. Un remplacement de chaîne naïf (par exemple, utiliser sed sur un dump de base de données) corrompra les données sérialisées en invalidant les préfixes de comptage d’octets. Utilisez toujours la commande search-replace de WP-CLI, qui gère correctement la sérialisation.

Considérations relatives au réseau Multisite. Dans une installation WordPress Multisite, WP_SITEURL s’applique à l’administration du réseau, pas aux sous-sites individuels. Chaque sous-site possède ses propres entrées siteurl et home dans sa table wp_X_options respective. Un changement d’URL à l’échelle du réseau nécessite la mise à jour de la table d’options de chaque sous-site, ce que WP-CLI gère avec l’indicateur --network :

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Confiance dans les en-têtes de proxy inverse. Sur les serveurs derrière un équilibreur de charge ou un proxy inverse Nginx, WordPress peut détecter le mauvais protocole si le proxy ne transmet pas l’en-tête X-Forwarded-Proto. Même avec des constantes URL correctes, les liens internes peuvent revenir à HTTP. Ajoutez ce qui suit à wp-config.php pour forcer la détection HTTPS :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Vérification de la configuration après les modifications

Après avoir mis à jour l’un ou l’autre paramètre URL, effectuez les étapes de vérification suivantes avant de considérer la modification comme terminée :

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

L’indicateur --dry-run sur la dernière commande indique combien de remplacements seraient effectués sans modifier réellement les données. Si le nombre est zéro, la migration est propre.

Pour les équipes gérant plusieurs instances WordPress sur des environnements d’hébergement web mutualisé ou VPS, l’automatisation de cette étape de vérification dans un script post-déploiement élimine le risque de lancer un site avec des références URL obsolètes.

Matrice de décision : quelle méthode utiliser

Liste de contrôle des points techniques essentiels

• Mettez toujours à jour WP_SITEURL et WP_HOME ensemble, sauf si vous avez intentionnellement besoin du modèle en sous-répertoire.
• Définissez les constantes dans wp-config.php sur les serveurs de production pour éviter les écrasements accidentels via l’interface.
• Après tout changement d’URL, videz le cache d’objets et exécutez wp search-replace avec --all-tables pour traiter les données sérialisées.
• Pour les migrations HTTP vers HTTPS, mettez d’abord à jour les constantes URL, puis effectuez la recherche-remplacement, puis vérifiez avec curl pour détecter le contenu mixte.
• Dans les installations en sous-répertoire, le fichier index.php racine doit référencer le chemin du sous-répertoire, et .htaccess doit utiliser RewriteBase /.
• N’utilisez jamais de barre oblique finale dans les constantes WP_HOME ou WP_SITEURL.
• Sur les configurations avec proxy inverse, ajoutez la détection HTTP_X_FORWARDED_PROTO à wp-config.php ou WordPress générera des références de protocole incorrectes indépendamment des paramètres URL.
• Dans Multisite, la table wp_X_options de chaque sous-site doit être mise à jour indépendamment ; utilisez l’indicateur --network avec WP-CLI.

Foire aux questions

Que se passe-t-il si WordPress Address et Site Address sont différents sans la configuration en sous-répertoire ?

WordPress tentera de charger les fichiers core depuis le chemin spécifié dans WP_SITEURL. Si aucune installation WordPress n’existe à ce chemin, toutes les requêtes d’administration retourneront des erreurs 404 ou un écran blanc. Le front-end peut encore se charger si WP_HOME est correct et que les règles de réécriture sont intactes, mais toute requête AJAX, tout appel à l’API REST ou toute action d’administration échouera.

Puis-je définir WP_HOME et WP_SITEURL avec des protocoles différents (l’un HTTP, l’autre HTTPS) ?

Non. Mélanger les protocoles entre les deux constantes crée une boucle de redirection que ni les navigateurs ni les robots d’exploration ne peuvent résoudre. Les deux constantes doivent utiliser le même protocole. Si vous appliquez HTTPS au niveau du serveur (via Nginx ou Apache), les deux constantes doivent utiliser https://.

Pourquoi le champ WordPress Address est-il grisé dans Réglages > Général ?

Le champ est en lecture seule car WP_SITEURL (ou WP_HOME) est défini comme constante PHP dans wp-config.php. Les constantes définies dans le code ont la priorité sur les valeurs de la base de données et ne peuvent pas être remplacées via l’interface. Pour rendre le champ à nouveau modifiable, supprimez ou commentez la ligne define() correspondante dans wp-config.php.

Le changement de Site Address affecte-t-il mon référencement et mes backlinks existants ?

Oui. Modifier WP_HOME change l’URL canonique de base pour chaque page de votre site. Sans redirections 301 appropriées de l’ancienne structure d’URL vers la nouvelle, les moteurs de recherche traiteront les anciennes et nouvelles URL comme des pages distinctes, divisant l’équité des liens et pouvant potentiellement déclencher des pénalités pour contenu dupliqué. Configurez toujours des redirections 301 au niveau du serveur avant ou simultanément au changement d’URL.

Comment récupérer l’accès si j’ai saisi une URL incorrecte et que je suis maintenant bloqué hors de wp-admin ?

Connectez-vous à votre serveur via SSH et définissez les constantes correctes dans wp-config.php en utilisant la Méthode 2, ou utilisez WP-CLI pour mettre à jour les options siteurl et home directement via la Méthode 3. Si aucune de ces options n’est disponible, utilisez phpMyAdmin ou une connexion MySQL directe pour exécuter les instructions UPDATE de la Méthode 4. Une fois l’accès rétabli, supprimez toutes les constantes temporaires si vous préférez que le tableau de bord gère les valeurs à l’avenir.