Comment supprimer “wordpress” de l’URL de votre site (Guide technique complet)

Lorsque WordPress est installé dans un sous-répertoire nommé /wordpress, chaque URL publique contient ce segment de chemin — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — ce qui nuit à la crédibilité de la marque et dilue l’équité SEO. La solution consiste en une migration de fichiers contrôlée combinée à des mises à jour d’URL dans la base de données : vous déplacez tous les fichiers core WordPress du sous-répertoire vers la racine du document du serveur (public_html), mettez à jour les paramètres Adresse WordPress et Adresse du site, régénérez les règles de réécriture et émettez des redirections 301 pour les anciennes URL indexées. Aucune réinstallation n’est nécessaire.

Ce guide couvre chaque couche technique de ce processus — opérations sur le système de fichiers, remplacement de chaînes dans la base de données, logique de réécriture .htaccess, stratégie de redirection et validation post-migration — y compris les cas particuliers qui provoquent des échecs silencieux dans la plupart des tutoriels.

Pourquoi WordPress se retrouve dans un sous-répertoire

Comprendre la cause première permet d’éviter que le même problème ne se reproduise. Les scénarios les plus courants sont :

• Paramètres par défaut des installateurs : De nombreux installateurs en un clic (Softaculous, Installatron) utilisent par défaut un chemin de sous-répertoire si l’utilisateur ne définit pas explicitement le chemin d’installation sur /.
• Promotion de l’environnement de staging vers la production : Un développeur installe WordPress sur /wordpress pour les tests et le site est mis en ligne sans correction du chemin.
• Planification multi-site qui ne s’est jamais concrétisée : Quelqu’un anticipait l’exploitation de plusieurs CMS sous un même domaine et a attribué WordPress à son propre dossier.
• Particularités de l’auto-installateur cPanel : Dans les environnements VPS avec cPanel, l’installateur ajoute parfois le nom de l’application comme sous-répertoire sauf si cela est remplacé.

Quelle que soit l’origine, la procédure de migration est identique.

Liste de contrôle pré-migration

Avant de toucher un seul fichier, complétez chaque élément de cette liste. En ignorer un seul est la principale cause de temps d’arrêt lors de cette opération.

• Sauvegarde complète du site : Archivez à la fois le système de fichiers et la base de données MySQL. Des plugins comme UpdraftPlus ou Duplicator fonctionnent bien ; un snapshot au niveau du serveur également si votre fournisseur d’hébergement VPS le prend en charge.
• Identifiants de base de données à portée de main : Vous en aurez besoin si une modification manuelle de wp-config.php devient nécessaire.
• Mode maintenance activé : Utilisez un plugin ou ajoutez temporairement define('WP_MAINTENANCE_MODE', true); pour empêcher les écritures pendant la fenêtre de migration.
• Journalisation des erreurs PHP activée : Définissez WP_DEBUG_LOG sur true dans wp-config.php afin que les erreurs post-migration soient écrites dans /wp-content/debug.log plutôt que d’apparaître à l’écran.
• TTL DNS noté : Si un changement DNS est également impliqué, réduisez le TTL à 300 secondes au moins une heure avant de commencer.

Étape 1 : Déplacer les fichiers WordPress vers la racine du document

L’objectif est de copier tout ce qui se trouve dans /public_html/wordpress/ directement dans /public_html/ — pas le dossier lui-même, mais son contenu.

Utilisation d’un client FTP (FileZilla)

1. Connectez-vous à votre serveur via SFTP (port 22) plutôt que via FTP simple pour éviter l’interception des identifiants.
2. Naviguez vers public_html/wordpress/.
3. Sélectionnez tous les fichiers et dossiers, y compris les fichiers cachés. Dans FileZilla, activez Affichage > Afficher les fichiers cachés pour exposer .htaccess et tous les fichiers .env.
4. Faites glisser la sélection d’un niveau de répertoire vers le haut dans public_html/.
5. Lorsqu’on vous demande d’écraser index.php (si un espace réservé existe dans la racine), confirmez l’écrasement.

Utilisation de la ligne de commande (recommandé pour VPS)

Si vous avez un accès SSH — ce qui devrait être le cas sur tout environnement hébergement VPS ou serveur dédié correctement configuré — l’approche en ligne de commande est plus rapide et évite les problèmes de délai d’expiration FTP sur les installations volumineuses :

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

Ne supprimez pas encore le répertoire /wordpress. Laissez-le intact jusqu’à ce que la migration soit entièrement validée. Vous pourrez le supprimer lors de l’étape de nettoyage final.

Cas particulier critique : liens symboliques et chemins absolus dans les plugins

Certains plugins (notamment les plugins de sauvegarde et de sécurité) stockent des chemins de fichiers absolus dans la base de données — par exemple, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Ceux-ci se briseront silencieusement après le déplacement. Le remplacement de recherche dans la base de données à l’étape 5 gère cela, mais vous devez inclure la table wp_options et toutes les tables de plugins personnalisés dans la portée du remplacement.

Étape 2 : Mettre à jour l’adresse WordPress et l’adresse du site

WordPress stocke deux valeurs d’URL critiques dans la table wp_options : siteurl (l’adresse WordPress, pointant vers l’emplacement des fichiers core WordPress) et home (l’adresse du site, l’URL que les visiteurs utilisent pour accéder au site). Les deux doivent être mises à jour.

Méthode A : Tableau de bord WordPress

1. Connectez-vous à yourdomain.com/wordpress/wp-admin — cela fonctionne encore car les fichiers se trouvent toujours aux deux emplacements à ce stade.
2. Allez dans Réglages > Général.
3. Mettez à jour les deux champs :

• Adresse WordPress (URL) : https://yourdomain.com
• Adresse du site (URL) : https://yourdomain.com

1. Cliquez sur Enregistrer les modifications.

Méthode B : Modification directe de la base de données (lorsque le tableau de bord est inaccessible)

Si le tableau de bord est déjà inaccessible, utilisez WP-CLI ou phpMyAdmin :

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Ou dans phpMyAdmin, exécutez :

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

Remplacez wp_ par votre préfixe de table réel s’il a été modifié lors de l’installation.

Méthode C : Remplacement temporaire dans wp-config.php

Si le tableau de bord et la base de données sont temporairement inaccessibles, ajoutez ces deux lignes à wp-config.php comme remplacement de démarrage :

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

Cela remplace ce qui est stocké dans la base de données. Supprimez ces lignes après avoir confirmé que le tableau de bord est accessible et que les valeurs de la base de données ont été mises à jour de façon permanente.

Étape 3 : Vérifier et mettre à jour le fichier .htaccess

Le fichier .htaccess dans la racine du document contrôle la réécriture d’URL d’Apache pour WordPress. Après le déplacement des fichiers, ce fichier devrait déjà se trouver dans public_html/ — mais sa directive RewriteBase doit refléter la nouvelle installation au niveau de la racine.

Ouvrez public_html/.htaccess et assurez-vous qu’il contient exactement le bloc de réécriture WordPress suivant :

# 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

Le changement clé par rapport à une installation dans un sous-répertoire est RewriteBase / au lieu de RewriteBase /wordpress/. Si cette ligne est incorrecte, tous les permaliens personnalisés renvoient des erreurs 404 tandis que la page d’accueil se charge correctement — une signature diagnostique classique d’un RewriteBase mal configuré.

Utilisateurs Nginx : WordPress n’utilise pas .htaccess. Mettez plutôt à jour la directive try_files de votre bloc serveur :

location / {
    try_files $uri $uri/ /index.php?$args;
}

Étape 4 : Vider la structure des permaliens

WordPress met en cache les règles de réécriture dans la base de données. Après avoir modifié l’URL du site, ces règles mises en cache font référence à l’ancienne structure de chemin et doivent être régénérées.

1. Allez dans Réglages > Permaliens dans le tableau de bord WordPress.
2. Sans modifier la structure de permalien sélectionnée, cliquez sur Enregistrer les modifications.

Cela force WordPress à reconstruire et mettre en cache les règles de réécriture par rapport au nouveau chemin au niveau de la racine. Vous pouvez également utiliser WP-CLI :

wp rewrite flush --hard

L’indicateur --hard régénère le fichier .htaccess en plus de vider le cache de la base de données — utile si vous n’êtes pas sûr que le .htaccess est correct.

Étape 5 : Remplacement d’URL à l’échelle de la base de données

Déplacer les fichiers et mettre à jour siteurl/home n’est pas suffisant. WordPress stocke des chaînes d’URL sérialisées dans toute la base de données — dans le contenu des articles, postmeta, les paramètres des widgets, les options de thème et les tables de configuration des plugins. Toute référence de chemin /wordpress restante produira des images brisées, des balises canoniques incorrectes et des fonctionnalités de plugin défaillantes.

Utilisation du plugin Better Search Replace

1. Installez et activez le plugin Better Search Replace.
2. Allez dans Outils > Better Search Replace.
3. Configurez le remplacement :

• Rechercher : https://yourdomain.com/wordpress
• Remplacer par : https://yourdomain.com

1. Sélectionnez toutes les tables de la base de données.
2. Décochez Exécuter en mode test ? uniquement après avoir confirmé que le mode test affiche le nombre de remplacements attendu.
3. Cliquez sur Exécuter la recherche/remplacement.

Effectuez également un second passage pour le chemin absolu du serveur :

• Rechercher : /public_html/wordpress
• Remplacer par : /public_html

Utilisation de WP-CLI (préféré pour la production)

La commande search-replace de WP-CLI gère correctement les données sérialisées, ce que la fonction SQL REPLACE() naïve ne fait pas :

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Effectuez un second passage pour les chemins absolus du système de fichiers :

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

L’indicateur --precise utilise le remplacement tenant compte de la sérialisation PHP plutôt que les expressions régulières, ce qui évite de corrompre les tableaux sérialisés stockés dans la base de données.

Étape 6 : Mettre en place des redirections 301 pour la continuité SEO

Si le site a été publiquement accessible via des URL /wordpress — et surtout si ces URL ont été indexées par Google ou liées depuis des sources externes — les redirections permanentes sont obligatoires, pas optionnelles. Sans elles, chaque URL indexée devient une 404, et toute l’équité de liens accumulée est perdue.

Ajoutez la règle de redirection suivante à public_html/.htaccess, au-dessus du bloc de réécriture WordPress :

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Cette règle capture toute requête commençant par wordpress/ et la redirige vers le chemin équivalent au niveau de la racine. Par exemple :

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Note importante sur le placement : Ce bloc de redirection doit apparaître avant le commentaire # BEGIN WordPress. Les propres règles de réécriture de WordPress intercepteront la requête en premier si la redirection est placée après elles.

Pour Nginx, ajoutez ceci au bloc serveur :

rewrite ^/wordpress/(.*)$ /$1 permanent;

Étape 7 : Validation post-migration

Des tests systématiques empêchent les échecs silencieux de passer inaperçus en production.

Vérifications fonctionnelles

Validation en ligne de commande

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Soumettez le plan du site mis à jour dans Google Search Console immédiatement après la validation. Utilisez l’outil Inspection d’URL pour demander la réindexation de la page d’accueil. Surveillez le rapport de Couverture au cours des 48 à 72 heures suivantes pour détecter toute augmentation des erreurs 404, ce qui indiquerait des remplacements d’URL manqués.

Étape 8 : Nettoyage et renforcement final

Une fois que le site fonctionne de manière stable à l’URL racine pendant 24 à 48 heures :

1. Supprimez le sous-répertoire /wordpress du serveur. Le laisser en place crée un risque de contenu dupliqué et expose un point d’entrée secondaire vers l’installation WordPress.

rm -rf /var/www/html/public_html/wordpress

1. Supprimez la constante WP_MAINTENANCE_MODE de wp-config.php si vous l’avez ajoutée.
2. Supprimez les définitions temporaires WP_HOME/WP_SITEURL de wp-config.php si vous avez utilisé la méthode C à l’étape 2.
3. Vérifiez la couverture SSL : Si votre certificat SSL a été émis pour yourdomain.com/wordpress en tant que portée basée sur un chemin (peu courant mais possible dans certaines configurations), confirmez que le certificat couvre correctement le domaine apex.
4. Mettez à jour toutes les configurations DNS ou CDN externes qui pourraient avoir mis en cache l’ancienne structure de chemin.
5. Purgez toutes les couches de cache : Videz le cache de pages côté serveur, le cache d’objets (Redis/Memcached) et le cache CDN. Les entrées de cache obsolètes pour les URL /wordpress serviront un contenu incorrect même après la fin de la migration.

Comparaison : méthodes de migration en un coup d’œil

Pour tout environnement avec accès SSH — y compris les serveurs dédiés et les instances VPS non gérées — l’approche WP-CLI est l’option la plus fiable et la moins sujette aux erreurs.

Matrice de décision technique

Utilisez cette matrice pour déterminer quelles étapes sont obligatoires par rapport à celles qui sont situationnelles pour votre scénario spécifique :

Points clés à retenir

• L’opération principale est : copier les fichiers vers la racine du document, mettre à jour siteurl et home dans la base de données, corriger .htaccess RewriteBase, exécuter une recherche-remplacement tenant compte de la sérialisation, ajouter des redirections 301.
• N’utilisez jamais un SQL REPLACE() simple sur les tables WordPress sans gestion de la sérialisation — cela corrompra les valeurs d’options et brisera les plugins silencieusement.
• La directive .htaccess RewriteBase / est l’élément le plus souvent mal configuré dans cette migration ; une valeur incorrecte produit des 404 sur toutes les URL basées sur des permaliens tandis que la page d’accueil continue de se charger.
• Les redirections 301 ne sont pas cosmétiques — elles transfèrent l’équité des liens et préviennent la fragmentation de l’index. Elles sont obligatoires pour tout site ayant une visibilité dans les moteurs de recherche existante.
• Supprimez le répertoire /wordpress original uniquement après une fenêtre d’observation stable de 24 heures.
• Si vous exécutez WordPress sur un VPS avec cPanel, utilisez l’option Afficher les fichiers cachés du Gestionnaire de fichiers pour vous assurer que .htaccess est inclus dans l’opération de copie.

Foire aux questions

La suppression de /wordpress de l’URL affectera-t-elle mon classement SEO ?

À court terme, attendez-vous à de légères fluctuations de classement pendant que Googlebot re-explore les nouvelles URL. Si les redirections 301 sont correctement mises en œuvre, l’équité des liens se transfère entièrement et les classements se stabilisent généralement en deux à quatre semaines. Ignorer les redirections 301 entraîne une perte permanente de classement pour toutes les pages précédemment indexées.

Que faire si mon tableau de bord WordPress est inaccessible après le déplacement des fichiers ?

La cause la plus courante est une discordance entre la valeur siteurl dans la base de données et l’emplacement réel des fichiers. Utilisez WP-CLI (wp option update siteurl) ou ajoutez define('WP_SITEURL', 'https://yourdomain.com'); à wp-config.php comme remplacement temporaire pour restaurer l’accès.

Dois-je mettre à jour wp-config.php après avoir déplacé WordPress vers la racine ?

Dans la plupart des cas, non. Le fichier wp-config.php utilise des chemins relatifs pour la connexion à la base de données et ne code pas en dur le chemin d’installation. L’exception est si ABSPATH a été défini manuellement comme un chemin absolu pointant vers l’ancien répertoire /wordpress — dans ce cas, mettez à jour ou supprimez cette ligne.

Pourquoi les images sont-elles toujours brisées après l’exécution de Better Search Replace ?

Cela signifie généralement que le plugin a été exécuté sur un sous-ensemble de tables et a manqué les tables de plugins personnalisés ou la table wp_postmeta. Réexécutez le remplacement avec toutes les tables sélectionnées, et vérifiez également les chemins absolus du système de fichiers (par ex., /public_html/wordpress/wp-content/uploads/) en plus des chaînes basées sur les URL.

Comment gérer cela sur une installation WordPress Multisite ?

Multisite nécessite des constantes supplémentaires dans wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) et les URL du site du réseau doivent être mises à jour dans les tables wp_site et wp_blogs. La procédure standard pour un site unique est insuffisante — traitez cela comme une migration complète du réseau et testez d’abord sur un clone de staging.