WordPress dans un sous-dossier : corriger l’adresse de l’accueil

Reconnaissez un problème d’adresse avant de déplacer le site

Votre domaine affiche une page provisoire, tandis que WordPress fonctionne seulement en ajoutant /wordpress. Ou l’accueil s’ouvre, mais le logo renvoie vers un sous-dossier inattendu. Commencez par noter les deux adresses exactes et ce qui apparaît à chacune. Une mauvaise destination ne signifie pas que les articles ou les images ont été perdus.

Décidez aussi où le public doit réellement arriver. Un blog volontairement placé sous /blog n’a pas besoin d’être ramené à la racine. À l’inverse, si le domaine doit ouvrir directement le site, conserver le cœur WordPress dans un sous-dossier reste possible. Ce choix demande un acheminement cohérent des requêtes ; supprimer un mot dans un champ ne suffit pas toujours.

Ce guide concerne surtout une installation WordPress indépendante avec un accès autorisé à l’hébergement. Il propose deux parcours : conserver tout le site dans son sous-dossier, ou afficher le site à la racine en gardant le cœur séparé. Les réseaux multisites et les plateformes administrées demandent un traitement adapté. Aucune extension supplémentaire n’est nécessaire pour établir le diagnostic.

Préservez les anciennes valeurs et un accès de secours

Avant toute modification, recopiez les adresses actuelles, l’adresse de connexion qui fonctionne et le chemin du dossier contenant WordPress. Relevez les changements récents : installation automatique, ajout d’un domaine, déplacement ou modification des réglages généraux. Une capture privée du panneau de domaine aidera le prestataire à retrouver la configuration d’origine.

Vérifiez que vous disposez d’une sauvegarde exploitable des fichiers et de la base. Préservez séparément les fichiers de configuration concernés avant de les éditer. Le téléchargement du dossier WordPress ne contient normalement pas les données de la base. Stockez les copies hors du répertoire public : un fichier de secours accessible sur le Web pourrait exposer des informations confidentielles.

Testez votre accès au gestionnaire de fichiers ou au transfert sécurisé fourni par l’hébergeur. Une session WordPress ouverte peut cesser de fonctionner après une correction d’adresse ; elle ne constitue donc pas à elle seule un accès de secours. Si vous ne pouvez pas restaurer les valeurs sans le tableau de bord, faites préparer l’intervention par le support avant d’enregistrer un changement.

Repérez la racine réellement associée au domaine

Dans le panneau d’hébergement, consultez le domaine exact et son dossier de destination. La racine du domaine est le répertoire depuis lequel le serveur sert ce nom de site. Elle peut déjà correspondre à un dossier appelé wordpress. Le nom physique d’un répertoire ne se retrouve pas automatiquement dans l’adresse publique.

Par exemple, si le domaine pointe directement vers le dossier contenant le cœur, son accueil peut être servi à la racine sans /wordpress. Si le domaine pointe vers le dossier parent et que le cœur se trouve dans son enfant wordpress, ce segment peut effectivement apparaître dans l’URL applicative. Faites confirmer cette correspondance plutôt que de déduire l’adresse depuis l’arborescence seule.

Inspectez ensuite la racine sans effacer de fichier. Une page index.html peut être présentée avant index.php selon l’ordre configuré. Elle peut appartenir à un ancien site ou à une autre application. Ne la remplacez pas avant d’avoir identifié son propriétaire et son rôle. Si la racine héberge déjà un service à conserver, l’affichage de WordPress à cet endroit devient un projet de remplacement à préparer.

Lisez les deux réglages sans chercher à les rendre identiques

Dans Réglages, puis Général, repérez Adresse web de WordPress et Adresse web du site. Les libellés peuvent varier avec la traduction. Le premier réglage désigne l’emplacement accessible des fichiers applicatifs. Le second indique l’adresse de la partie publique. Recopiez les deux valeurs avant de les comparer à votre organisation cible.

Pour un site entièrement accessible sous /wordpress, les deux valeurs comprennent normalement ce chemin. Pour un cœur sous /wordpress et un accueil à la racine, seule l’adresse WordPress conserve ce segment. Une différence entre les champs peut donc être parfaitement normale. Examinez également le protocole et le nom du domaine, avec ou sans www, sans modifier simultanément tous ces éléments.

Si les champs sont grisés, recherchez avec le responsable technique une configuration imposée. Les constantes WP_SITEURL et WP_HOME peuvent prendre la priorité sur les options stockées. Certaines offres injectent aussi leurs réglages ailleurs. Insister dans la base alors qu’une autre source impose encore l’ancienne valeur ne corrige pas cette source. Conservez une seule configuration de référence clairement identifiée.

Choisissez le parcours qui correspond à l’adresse souhaitée

Le premier parcours convient lorsque le sous-dossier fait partie de l’adresse publique prévue. Vous souhaitez par exemple conserver un site principal indépendant à la racine et un blog sous /blog. La réparation consiste alors à rétablir une adresse cohérente, à corriger les liens erronés et, si nécessaire, à préparer une redirection ciblée de l’accueil.

Le second parcours convient lorsque WordPress doit gérer le domaine à sa racine tandis que ses fichiers restent dans un sous-dossier. Il implique un point d’entrée public et des règles compatibles avec le serveur. Il nécessite un accès aux bons fichiers, une racine disponible et une procédure de restauration. Préparez ces éléments avant de changer l’adresse du site.

Si votre objectif est de déplacer aussi les fichiers, de changer d’hébergeur ou de remplacer une application existante, arrêtez cette correction locale. Vous préparez une migration plus large. Ne transformez pas un dépannage d’accueil en déplacement complet par commodité : cela ajoute des changements de chemins et des données à vérifier alors que le problème initial peut être limité.

Approche 1 : conservez tout le site dans son sous-dossier

Confirmez d’abord l’adresse publique prévue et la racine du domaine. Le parcours ci-dessous prend l’exemple fictif d’un site dont les fichiers et le public sont accessibles sous https://exemple.invalid/blog. Adaptez le protocole, le domaine et le chemin ; ne recopiez pas cette adresse d’exemple.

Contrôlez ensuite l’accueil, une page et la connexion à l’adresse applicative. Un dossier physique nommé blog ne justifie pas ce segment si le domaine pointe directement dedans. Si la correction vous déconnecte, utilisez le chemin confirmé et vos identifiants habituels ; l’accès aux fichiers préparé reste disponible pour le retour.

Corrigez aussi les liens manuels qui pointent au mauvais endroit. Dans la page source, sélectionnez le lien du bouton ou du paragraphe, modifiez sa destination et enregistrez ; vérifiez le clic publiquement. Un menu personnalisé utilise son propre éditeur selon le thème. Le résultat attendu est un parcours qui reste dans l’espace prévu.

Si la racine sans autre service doit seulement conduire au blog, préparez une redirection de cette seule adresse avec le responsable du routage. Ne couvrez pas tous les chemins. Pour annuler un réglage injustifié, restaurez sa valeur initiale ; pour un lien, remettez son ancienne cible. Une nouvelle boucle appelle le retrait de la règle précise ajoutée, pas un déplacement du cœur.

1. Ouvrez Réglages → Général dans le WordPress concerné, avec votre accès de secours aux fichiers déjà vérifié.
2. Relevez Adresse web de WordPress et Adresse web du site. Dans cette organisation, toutes deux doivent contenir la même adresse complète avec le sous-dossier.
3. Corrigez uniquement le champ erroné, sans barre finale ajoutée, puis cliquez sur Enregistrer les modifications.
4. Contrôlez l’accueil, une page et la connexion à l’adresse applicative. Si le changement empêche l’accès, rétablissez la valeur relevée par le moyen de secours préparé.

Approche 2 : servez la racine en gardant le cœur séparé

Cette voie concerne une installation indépendante déjà présente dans un sous-dossier et une racine disponible pour son accueil. Préparez l’opération sur copie, avec accès aux fichiers, sauvegardes privées et règles serveur adaptées. Une autre application à conserver à la racine exclut cette manipulation simple.

L’exemple suppose un sous-dossier nommé exactement wordpress. Respectez son nom réel et sa casse. La ligne de code ci-dessous remplace seulement le chargement du cœur dans la copie racine : ce n’est pas un fichier index.php complet. Conservez l’ouverture PHP et toutes les autres instructions de ce fichier.

1. Identifiez la racine réelle du domaine et le dossier WordPress. Si un index existe à la racine, identifiez son rôle et préservez sa copie avant tout remplacement.
2. Copiez, sans déplacer, le index.php du dossier WordPress vers la racine. Gardez l’index applicatif initial en place.
3. Dans cette copie racine uniquement, repérez la ligne chargeant wp-blog-header.php et adaptez son chemin au sous-dossier réel, comme dans l’exemple ci-dessous.
4. Préparez les règles adaptées à Apache, Nginx ou IIS selon la section suivante. Ne superposez pas une configuration générique à celle du prestataire.
5. Dans Réglages → Général, gardez Adresse web de WordPress sur l’adresse applicative, par exemple https://exemple.invalid/wordpress, et placez Adresse web du site à la racine, ici https://exemple.invalid, avec vos vraies valeurs. Enregistrez dans l’intervention préparée.
6. Actualisez les règles de permaliens comme indiqué plus loin, puis contrôlez l’accueil racine, un article, les médias et la connexion applicative, ici /wordpress/wp-admin/.
7. Si le chargement échoue, remettez les champs initiaux et les seuls fichiers ou règles changés. Conservez le sous-dossier et le cœur ; ne réinstallez pas WordPress pour récupérer l’accueil.

require __DIR__ . '/wordpress/wp-blog-header.php';

Adaptez les règles au serveur sans écraser sa configuration

Sur Apache, les règles utiles peuvent se trouver dans .htaccess ou dans la configuration du serveur. Faites afficher les fichiers cachés dans le gestionnaire si nécessaire. Une copie complète prise ailleurs peut contenir des directives inadaptées, des protections ou des règles propres à une autre application. Faites préserver ces éléments lorsque les règles WordPress sont adaptées à la racine.

Avant d’ouvrir Réglages, puis Permaliens, sauvegardez en privé le .htaccess concerné : l’écran peut déjà régénérer les règles lors de son ouverture. Après la mise en place du point d’entrée, gardez la structure actuelle et utilisez Enregistrer les modifications une fois. Lisez les éventuels avertissements d’écriture. Cette action ne remplace pas l’installation du point d’entrée manquant. Si WordPress ne peut pas écrire les règles nécessaires, faites appliquer uniquement la configuration vérifiée au bon emplacement ; n’élargissez pas toutes les permissions pour forcer l’enregistrement.

Avec Nginx natif, .htaccess n’est pas interprété. Le prestataire doit adapter la configuration serveur et contrôler les chemins vers PHP. Un en-tête Nginx peut aussi provenir d’un proxy devant Apache : demandez quelle couche traite réellement le site. Sous IIS, les règles relèvent notamment de web.config ; n’y appliquez pas une recette Apache.

Récupérez une adresse erronée sans multiplier les changements

Si la connexion est perdue juste après une correction d’adresse, utilisez d’abord le chemin applicatif confirmé. Pour une installation indépendante dont vous maîtrisez les fichiers, une surcharge peut rétablir provisoirement les valeurs attendues. Ouvrez le vrai wp-config.php par SFTP ou gestionnaire de fichiers, conservez sa copie privée et repérez les définitions existantes de WP_HOME et WP_SITEURL. Un refus de mot de passe demande un autre diagnostic : créer un administrateur supplémentaire ne répare pas l’adresse.

Remplacez seulement leurs valeurs si elles existent. Sinon, ajoutez les lignes justifiées avant le chargement de wp-settings.php, habituellement avant le commentaire de fin d’édition. L’exemple suppose l’accueil à la racine et le cœur sous wordpress ; pour un site public entièrement sous ce chemin, les deux adresses doivent le conserver. Adaptez protocole, domaine et organisation, sans doublon ni barre finale.

Enregistrez puis contrôlez l’accueil et l’administration. Ces constantes prennent la priorité sur les options sans les réécrire ni déplacer les fichiers. Une fois l’accès retrouvé, préparez la correction durable avec les anciennes options relevées : retirer les constantes peut faire revenir une mauvaise adresse stockée. N’effacez pas les surcharges avant d’avoir prévu ce passage et votre accès de secours. Si le site utilise volontairement une configuration par fichier, ces deux valeurs peuvent rester la référence documentée. Dans ce cas, les champs correspondants du tableau de bord restent non modifiables ; il ne faut pas maintenir une seconde consigne concurrente.

Pour annuler cet essai, restaurez les définitions initiales ou retirez uniquement celles ajoutées. Cette procédure ne s’applique pas directement à un multisite, à WordPress.com ou à une configuration injectée par le prestataire. N’ajoutez pas une réparation dans le thème et ne remplacez pas globalement les URL dans la base pour récupérer un seul réglage.

define( 'WP_HOME', 'https://exemple.invalid' );
define( 'WP_SITEURL', 'https://exemple.invalid/wordpress' );

Distinguez le sous-dossier physique d’un chemin multisite

Une adresse terminée par /boutique peut représenter un site d’un réseau multisite sans qu’un dossier boutique existe sur le serveur. Le chemin fait alors partie du routage du réseau. Chercher à créer ce répertoire, y déplacer des fichiers ou lui donner un index indépendant risque de perturber le fonctionnement prévu.

Repérez si votre interface propose une administration du réseau et demandez confirmation au responsable. L’absence de cet écran pour votre compte n’exclut pas un multisite. Le domaine et le chemin du site doivent être étudiés dans ce contexte, avec les règles communes et les autres sites concernés. Les modifications adaptées à une installation indépendante ne se transposent pas automatiquement.

Si vous êtes seulement administrateur d’un site du réseau, transmettez l’adresse attendue et celle obtenue au super administrateur. Demandez une vérification du site ciblé plutôt qu’un changement global. Après une intervention réseau, contrôlez aussi un autre site représentatif pour détecter un effet involontaire. Gardez le projet de migration d’un réseau séparé de cette correction d’accueil.

Contrôlez les ressources et les liens déjà enregistrés

Une fois l’accueil accessible, ouvrez un article ancien, une page récente et plusieurs images. Regardez si les feuilles de style et les scripts se chargent. Un accueil sans mise en forme peut révéler des chemins de ressources incorrects ; il ne justifie pas de changer immédiatement de thème. Relevez une ressource qui échoue et son adresse exacte pour affiner le diagnostic.

Les contenus peuvent conserver des liens absolus saisis avant la correction. Examinez les menus personnalisés, boutons, logos et liens intégrés aux pages. Corrigez d’abord un exemple identifié, puis vérifiez qu’il mène directement à la destination voulue. La présence du sous-dossier dans une adresse de ressource n’est pas automatiquement une erreur lorsque les fichiers restent effectivement à cet endroit.

Si une migration réelle impose de remplacer de nombreuses adresses enregistrées, préparez une opération distincte sur copie de test avec une sauvegarde. Certaines données sont sérialisées : une substitution brute dans un export SQL peut les endommager. Définissez précisément l’ancienne et la nouvelle adresse, le périmètre et un aperçu des changements. Ne remplacez jamais aveuglément chaque occurrence du mot wordpress.

Préparez des redirections qui respectent les chemins encore utiles

Si l’adresse publique des articles a changé, relevez quelques paires ancienne adresse et nouvelle destination. Chaque redirection doit conduire vers le contenu équivalent. La racine réparée ne suffit pas à traiter les liens déjà diffusés. Commencez par une seule correspondance vérifiée, puis étendez la configuration lorsque le comportement est confirmé.

Ne retirez pas globalement /wordpress de toutes les requêtes si le cœur y reste. Des ressources et des chemins d’administration utilisent encore cet emplacement. Une règle trop large peut envoyer les fichiers applicatifs vers des adresses inexistantes ou boucler. Faites distinguer les anciens contenus publics des chemins techniques avant de créer une règle couvrant plusieurs URL.

Contrôlez l’adresse finale et la chaîne de réponses dans l’onglet Réseau du navigateur : ouvrez les outils de développement, activez la conservation du journal si elle est proposée, puis rechargez l’ancienne adresse. Examinez la requête du document et l’en-tête Location des réponses de redirection. Pour un déplacement permanent confirmé, utilisez une redirection permanente appropriée vers une destination qui répond correctement. Les liens internes devraient pointer directement vers celle-ci. Si la chaîne revient à son point de départ, désactivez la dernière règle ajoutée et comparez les consignes du serveur, du proxy et de WordPress.

Sur WordPress.com ou une offre gérée, utilisez le bon interlocuteur

Sur WordPress.com, ne cherchez pas à appliquer directement une recette d’Apache trouvée pour un hébergement indépendant. La plateforme gère son environnement serveur. Vérifiez quel site vous consultez, son domaine et les options réellement disponibles dans votre compte, puis transmettez au support les deux destinations observées si l’accueil ne correspond pas à la configuration attendue.

Une offre WordPress administrée chez un autre prestataire peut également imposer les adresses ou les règles de routage. Le fait d’avoir accès à certains fichiers ne signifie pas que tous les réglages serveur peuvent être changés librement. Demandez où la valeur est définie et quelle procédure permet de la corriger durablement, sans combattre une configuration automatiquement régénérée.

Dans votre demande, précisez si vous voulez conserver une adresse publique en sous-dossier ou afficher l’accueil à la racine. Mentionnez l’existence éventuelle d’un autre site à cette racine. Cette décision explicite évite qu’une correction de domaine soit interprétée comme une demande de migration. Ne transmettez ni mot de passe, ni copie complète de configuration dans un échange public.

Validez la correction et déclenchez le retour arrière si nécessaire

Reprenez la liste d’adresses notée avant l’intervention. Testez l’accueil depuis une fenêtre privée, puis un article, une page, un média et la connexion. Vérifiez l’adresse finale, le contenu et le statut de la requête principale. Une page provisoire qui répond correctement n’est pas le résultat attendu si elle appartient au mauvais site.

Contrôlez ensuite une action représentative sans créer d’effet commercial involontaire : ouverture de l’éditeur, aperçu d’une page ou formulaire sur un environnement de test. Pour une boutique, les essais de commande doivent suivre le protocole prévu par son responsable. Purgez seulement les caches concernés après confirmation de la correction ; une purge ne remplace pas un routage serveur manquant.

Si plusieurs pages deviennent inaccessibles, si une autre application est touchée ou si la connexion reste bloquée, revenez à l’état préparé. Restaurez les valeurs et les fichiers modifiés dans l’ordre prévu avec le prestataire. Évitez une restauration globale de base si des commandes ou inscriptions ont été ajoutées depuis la sauvegarde. Préservez ces nouvelles données avant toute restauration qui pourrait les écraser.

Documentez l’organisation retenue pour éviter la prochaine erreur

Conservez une courte fiche privée indiquant le domaine public, l’adresse du cœur, le dossier servi par le domaine et le chemin d’administration. Ajoutez l’emplacement du point d’entrée racine et le responsable des règles serveur. La mention « WordPress est dans wordpress » est trop vague pour préparer une future intervention sans refaire toute l’enquête.

Notez la date de correction, les anciennes valeurs et les fichiers réellement modifiés. Si des constantes imposent les adresses, indiquez-le afin qu’un prochain administrateur ne cherche pas inutilement à débloquer les champs. Avant une migration ou un changement de domaine, faites relire cette fiche pour conserver l’organisation voulue dans l’environnement de destination.

Pour une demande d’aide encore nécessaire, fournissez le symptôme précis et un exemple de destination incorrecte. Séparez ce qui fonctionne de ce qui échoue : accueil, articles, fichiers ou administration. Un article qui reste en 404 après correction de l’accueil relève ensuite du diagnostic des permaliens ; une boucle de connexion doit être étudiée avec ses redirections. Le dossier ainsi constitué permet de poursuivre au bon niveau sans recommencer des déplacements inutiles.