Déplacer WordPress d'un sous-répertoire vers la racine du domaine sur cPanel

Ce guide vous accompagne pour sortir un site WordPress d’un sous-dossier afin qu’il réponde à la racine de votre domaine, sur un compte d’hébergement cPanel. Vous êtes sans doute ici parce qu’un installateur en un clic a déposé WordPress dans example.com/wordpress/, ou parce qu’un blogue installé dans example.com/blog/ est devenu le site au complet, et que chaque URL traîne encore ce nom de dossier. La réponse courte tient au réglage « Adresse web du site » de WordPress, qui laisse les fichiers où ils sont et ne change que l’adresse vue par les visiteurs. Cette méthode est documentée et prise en charge par WordPress lui-même, demande une quinzaine de minutes, et survit aux mises à jour du cœur. Déplacer physiquement les fichiers dans public_html est l’autre option, couverte ici aussi, avec les redirections qui gardent vos liens et votre référencement en vie.

Ce que vous allez accomplir

Votre page d’accueil, vos articles et vos pages répondent tous à https://example.com/ plutôt qu’à https://example.com/blog/.
Un choix réfléchi entre les deux méthodes, avec la raison notée pour la prochaine personne qui touchera au site.
Les anciennes URL du sous-répertoire renvoient un 301 Moved Permanently vers leur nouvelle adresse, pour que les signets, les liens entrants et les résultats de recherche continuent d’aboutir sur de vraies pages.
Des permaliens régénérés (les motifs d’URL que WordPress construit pour les articles et les pages), avec les règles de réécriture correspondantes écrites dans un fichier .htaccess qu’Apache lit au nouvel emplacement.
Les URL stockées en base réécrites sans casser le PHP sérialisé, le format que WordPress emploie pour ranger des tableaux dans une seule colonne de base de données.

Prérequis

Un compte cPanel joignable en SSH, ou la tuile Terminal de cPanel. Connectez-vous sous l’utilisateur du compte, jamais sous root.
WP-CLI 2.x, l’outil WordPress en ligne de commande, disponible comme wp. Chaque commande ci-dessous peut aussi se faire au Gestionnaire de fichiers de cPanel et dans les écrans d’administration de WordPress, et le guide indique où.
Une version de WordPress encore prise en charge. Les deux réglages concernés sont au même endroit depuis WordPress 3.x.
Le chemin de votre racine web, normalement /home/USER/public_html, où USER est le nom du compte cPanel. Les domaines additionnels et les sous-domaines ont leur propre racine, alors confirmez la vôtre avant de taper un chemin.
Une sauvegarde complète des fichiers et de la base, prise avant de commencer. La tuile Sauvegarde de cPanel en produit une, ou utilisez la commande wp db export plus bas.
Savoir si une extension de cache ou un CDN (réseau de diffusion de contenu, qui sert des copies de vos pages depuis d’autres serveurs) se trouve devant le site.

Choisissez une heure tranquille. Les deux méthodes laissent le site brièvement incohérent pendant le travail.

Comment ça fonctionne

WordPress conserve deux adresses distinctes en base. L’adresse web de WordPress (l’option siteurl) désigne l’endroit où se trouvent les fichiers du programme. L’adresse web du site (l’option home) est l’adresse que les gens tapent, et celle que WordPress emploie pour construire ses liens. Sur une installation ordinaire, les deux sont identiques. Elles ont le droit de différer, et c’est là tout le truc de la méthode officielle.

Quand elles diffèrent, WordPress construit chaque lien à partir de home et charge son code depuis siteurl. Un court fichier index.php placé à la racine web sert de pont. Son seul rôle est de charger wp-blog-header.php depuis le sous-dossier, ce qui démarre WordPress et affiche la page. Vos visiteurs ne voient jamais le nom du dossier, et vos écrans wp-admin restent à l’ancien chemin, là où les mises à jour du cœur continuent de les trouver.

Arborescence et chemin de requête d'une installation WordPress avant le déplacement, après un simple changement d'adresse, et après un déplacement physique des fichiers

L’option B fait plutôt la chose évidente : remonter tous les fichiers d’un niveau dans public_html, puis régler les deux adresses sur le domaine nu. Le résultat est une arborescence plus propre et un siteurl conforme à ce que présument la plupart des tutoriels. Le prix à payer est une fenêtre plus longue où le site est à moitié déplacé, et des dégâts plus larges si un chemin a été écrit en dur quelque part.

Prenez l’option A à moins d’avoir une raison concrète de faire autrement. Elle change une valeur en base et ajoute deux fichiers, le tout réversible en quelques secondes. Passez à l’option B quand un élément externe exige les fichiers à la racine. Une chaîne de déploiement peut s’attendre à trouver wp-content/ un niveau sous la racine web. Un outil d’analyse de sécurité peut être configuré pour cette disposition. Ou vous voulez peut-être récupérer le nom de dossier blog pour autre chose.

Dans les deux cas, deux tâches restent identiques. Les URL déjà écrites dans votre contenu et vos réglages pointent encore vers le sous-dossier, donc il faut les réécrire. Et les anciennes URL en /blog/ circulent sur les sites des autres et dans l’index de Google, donc il leur faut une redirection.

Étape par étape

Chaque commande présume que USER est le nom de votre compte cPanel et que blog est le sous-dossier actuel. Remplacez par wordpress, wp ou le nom que porte le vôtre.

Prenez la sauvegarde et confirmez que vous pouvez la restaurer. Lancez ceci depuis le dossier WordPress.
```
cd /home/USER/public_html/blog
wp db export ~/pre-root-move.sql
tar -czf ~/pre-root-move-files.tar.gz -C /home/USER/public_html .
```
Vous devriez voir Success: Exported to '/home/USER/pre-root-move.sql'. puis l’invite du shell. Vérifiez que les deux fichiers sont bien là avec ls -lh ~/pre-root-move* — le fichier SQL doit peser des mégaoctets, pas zéro. La commande de restauration, au besoin, est wp db import ~/pre-root-move.sql.
Lisez les deux adresses avant de changer quoi que ce soit. Notez le résultat.
```
wp option get siteurl
wp option get home
```
Sur une installation standard en sous-répertoire, les deux affichent la même valeur, https://example.com/blog. Si elles diffèrent déjà, quelqu’un est passé avant vous, et il vaut mieux savoir pourquoi avant de continuer.
Option A — changez seulement l’adresse web du site. Dans l’administration, allez à Réglages → Général, laissez Adresse web de WordPress (URL) exactement telle quelle, et mettez Adresse web du site (URL) à https://example.com. Enregistrez. En ligne de commande, l’équivalent est :
```
wp option update home 'https://example.com'
```
Attendez-vous à Success: Updated 'home' option. Le site aura l’air cassé jusqu’à l’étape suivante, ce qui est normal.
Option A — copiez index.php et .htaccess à la racine web. Copiez, ne déplacez pas. Les originaux doivent rester dans le sous-dossier.
```
cd /home/USER/public_html/blog
cp index.php /home/USER/public_html/index.php
cp .htaccess /home/USER/public_html/.htaccess
```
Si cp: .htaccess: No such file or directory revient, le site n’a pas encore de .htaccess. Sautez cette ligne ; l’étape 8 en crée un. Si public_html/index.html ou public_html/index.php existe déjà à cause d’une vieille page d’attente, renommez-le d’abord avec mv index.html index.html.old, sinon Apache le servira à la place de WordPress.
Option A — faites pointer l’index.php copié vers le sous-dossier. Ouvrez /home/USER/public_html/index.php et modifiez la dernière ligne pour que le chemin inclue le nom du dossier. Elle doit se lire :
```
require __DIR__ . '/blog/wp-blog-header.php';
```
Les installations plus anciennes utilisent plutôt require( dirname( __FILE__ ) . '/wp-blog-header.php' ); ; ajoutez /blog de la même façon. Depuis le shell :
```
sed -i "s#'/wp-blog-header.php'#'/blog/wp-blog-header.php'#" /home/USER/public_html/index.php
grep wp-blog-header /home/USER/public_html/index.php
```
Le grep doit afficher la ligne contenant /blog/. Ne touchez pas à blog/index.php. Modifier celui-là par erreur est la façon la plus courante de rater cette méthode, et ça brise l’administration. Passez maintenant à l’étape 7 ; l’étape 6 est le chemin de l’option B.
Option B — remontez les fichiers d’un niveau, puis réglez les deux adresses. Ceci déplace ensemble les fichiers visibles et les fichiers cachés.
```
cd /home/USER/public_html/blog
find . -mindepth 1 -maxdepth 1 -exec mv -n {} /home/USER/public_html/ \;
ls -a /home/USER/public_html/blog
```
Le ls ne doit afficher que . et ... Ce qui reste listé est entré en collision avec un fichier du même nom à la racine, que mv -n a refusé d’écraser ; traitez ces cas à la main. Comme le déplacement reste dans un seul compte cPanel, la propriété et les permissions sont conservées telles quelles. Retirez ensuite le dossier vide et mettez à jour les deux options :
```
rmdir /home/USER/public_html/blog
cd /home/USER/public_html
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'
```
Gardez plutôt le dossier si vous comptez servir les redirections depuis un .htaccess placé dedans. Les règles de l’étape 9 vivent à la racine, alors le retirer ne pose pas de problème.
Réécrivez les URL stockées en base. Le contenu, les menus et les réglages d’extensions contiennent encore des liens absolus avec /blog dedans. Faites d’abord un essai à blanc et lisez le rapport.
```
cd /home/USER/public_html
wp search-replace 'example.com/blog' 'example.com' --all-tables-with-prefix --precise --skip-columns=guid --report-changed-only --dry-run
```
La dernière ligne indique Success: N replacements to be made. La majorité devrait se trouver dans wp_posts.post_content et wp_options.option_value. Relancez sans --dry-run pour appliquer. Faites ensuite une seconde passe pour le balisage de l’éditeur de blocs, qui stocke les URL avec des barres obliques échappées que le premier motif ne touche jamais :
```
wp search-replace 'example.com\/blog' 'example.com' --all-tables-with-prefix --precise --skip-columns=guid --report-changed-only
```
Utilisez search-replace plutôt que du SQL brut. Le PHP sérialisé inscrit une longueur en octets devant chaque chaîne. Un simple UPDATE laisse ce nombre périmé, si bien que la valeur devient illisible sans aucune erreur au journal. WordPress search-replace après un changement de domaine sur cPanel couvre les options, le retour arrière et les couches qu’une passe en base n’atteint jamais. La référence WP-CLI de search-replace documente chaque option.
Videz les permaliens pour qu’Apache reçoive des règles de réécriture fraîches. Le plus sûr est l’écran d’administration, parce qu’il s’exécute dans une vraie requête web et résout correctement la racine web. Allez à Réglages → Permaliens et appuyez sur Enregistrer les modifications sans rien changer. L’équivalent en ligne de commande est :
```
wp rewrite flush --hard
```
Attendez-vous à Success: Rewrite rules flushed. Confirmez ensuite que les règles ont atterri dans le bon fichier :
```
grep -c 'BEGIN WordPress' /home/USER/public_html/.htaccess
```
La réponse doit être 1. Si c’est 0, WP-CLI a écrit le bloc dans le sous-dossier ; passez par l’écran Réglages → Permaliens et revérifiez. Dans ce bloc, RewriteBase doit indiquer / et non /blog/.
Redirigez les anciennes URL du sous-répertoire. Ajoutez ces lignes dans /home/USER/public_html/.htaccess, au-dessus du bloc # BEGIN WordPress. WordPress réécrit son propre bloc à chaque enregistrement des permaliens et les effacerait autrement.

Pour l’option B, où il ne reste rien dans le dossier :
```
RewriteEngine On
RewriteRule ^blog$ / [R=301,L]
RewriteRule ^blog/(.*)$ /$1 [R=301,L]
```
Pour l’option A, où les fichiers du programme sont toujours dans blog/, excluez les chemins dont WordPress a encore besoin :
```
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/blog/wp-(admin|content|includes)/
RewriteCond %{REQUEST_URI} !^/blog/(wp-login|wp-cron|xmlrpc)\.php
RewriteRule ^blog/(.*)$ /$1 [R=301,L]
```
Gardez ces règles en place de façon permanente. Les moteurs de recherche ont besoin de mois de réponses 301 cohérentes avant d’abandonner l’ancienne adresse, et les liens entrants d’autres sites ne se mettent jamais à jour.
Videz tous les caches placés devant le site. L’ordre compte ici. Commencez par l’extension, puis le serveur, puis la bordure réseau.
```
wp cache flush
wp transient delete --all
```
Attendez-vous à Success: The cache was flushed. et à un décompte de transients supprimés. Purgez ensuite le cache de votre CDN ou de Cloudflare depuis son tableau de bord, et régénérez le CSS du constructeur de pages depuis son propre panneau d’outils. Elementor garde ses feuilles de style sous wp-content/uploads/elementor/css/, et Elementor → Outils → Régénérer le CSS les réécrit.

Valider que ça fonctionne

Lancez ceci depuis votre poste, pas depuis le serveur, pour tester le vrai chemin de requête.

curl -sI https://example.com/ | head -1

Attendu : HTTP/2 200. Un 301 ici signifie qu’une règle de redirection attrape la racine.

curl -sI https://example.com/blog/hello-world/ | grep -iE '^HTTP|^location'

Attendu : deux lignes, HTTP/2 301 et location: https://example.com/hello-world/. Un seul saut, pas deux.

curl -s https://example.com/ | grep -c 'example.com/blog'

Attendu : 0. Un décompte supérieur à zéro signifie qu’une URL stockée a survécu à l’étape 7, en général dans une option de thème ou un widget.

cd /home/USER/public_html && wp option get home && wp option get siteurl

L’option A affiche https://example.com puis https://example.com/blog. L’option B affiche deux fois la même valeur.

Vérifiez ensuite à la main : chargez la page d’accueil, ouvrez un article, ouvrez une page, soumettez le formulaire de recherche, et connectez-vous à wp-admin. Avec l’option A, l’administration se trouve à https://example.com/blog/wp-admin/ et c’est correct.

Dépannage

Le navigateur signale trop de redirections. Quelque chose fait rebondir une requête entre deux adresses. Réglez les valeurs directement dans wp-config.php, au-dessus de la ligne /* That's all, stop editing! */, ce qui prend le pas sur la base : define( 'WP_HOME', 'https://example.com' ); et define( 'WP_SITEURL', 'https://example.com/blog' );. Chargez le site. S’il se rétablit, les valeurs en base étaient mauvaises. S’il boucle encore, mettez vos règles de redirection .htaccess en commentaire et retestez.

Vous n’arrivez plus à wp-admin après l’option A. La règle de redirection attrape le chemin d’administration parce que les lignes RewriteCond manquent, ou parce qu’elles ont été placées sous la RewriteRule au lieu d’au-dessus. Apache lit les conditions comme un préfixe de la règle qui suit, alors l’ordre n’a rien de cosmétique.

Les images renvoient 404 mais les articles s’affichent. Vérifiez si une ancienne installation a défini une URL d’envois personnalisée avec wp option get upload_url_path. Une sortie vide est le bon résultat. Si elle affiche un chemin avec /blog dedans, videz-le avec wp option update upload_url_path '' puis purgez les caches. Les images encore manquantes après ça sont habituellement écrites en dur dans les options du thème ou dans le contenu du constructeur de pages, que l’étape 7 n’atteint que si elles y sont en texte clair.

Une 500 Internal Server Error apparaît juste après l’étape 5. Le chemin du require dans l’index.php de la racine ne correspond à aucun fichier réel. Vérifiez avec ls /home/USER/public_html/blog/wp-blog-header.php. Si ce fichier existe, cherchez dans le .htaccess copié une ligne RewriteBase /blog/ et remplacez-la par RewriteBase /.

Le constructeur de pages affiche l’ancienne mise en page ou perd des widgets. Son CSS en cache et ses données de mise en page sérialisées sont deux choses distinctes. Régénérez d’abord le CSS depuis le panneau d’outils du constructeur. Si des widgets ont vraiment disparu, un remplacement s’est exécuté sans --precise sur des valeurs sérialisées ; restaurez ~/pre-root-move.sql et refaites l’étape 7. Permaliens brisés après une migration WordPress couvre la panne voisine où les articles renvoient 404 pendant que l’accueil se charge.

Quand ce n’est pas la bonne approche

Le sous-dossier est parfois le bon choix. Si votre site principal tourne sur une autre plateforme à la racine et que WordPress ne sert que la section blogue, le déplacer ferait tomber le site principal. Laissez-le où il est.

Arrêtez-vous et planifiez à part si le site est un réseau WordPress multisite. Changer la racine du réseau touche wp_blogs, wp_site et chaque table d’options par site, et les étapes ci-dessus ne couvrent rien de tout ça.

Si deux sites partagent le compte et que la racine appartient déjà à l’autre, il vous faut un second domaine ou un domaine additionnel plutôt qu’un déplacement.

Réinstaller va plus vite quand l’installation a quelques jours, sans trafic, sans liens entrants et avec peu de contenu. Supprimez-la et installez de nouveau à la racine avec l’installateur WordPress de cPanel. Tout le travail ci-dessus existe pour protéger des liens et un référencement déjà gagnés. L’article Giving WordPress its own directory de WordPress est la référence amont pour l’option A.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.