WordPress affiche « Index of / » : retirer la liste de fichiers et rétablir l’accueil

Identifier une liste de répertoire à la place de l’accueil

Votre domaine affiche « Index of / » ou une page qui énumère des fichiers et dossiers au lieu de WordPress. Le serveur produit une liste de répertoire, souvent parce qu’il ne trouve pas le fichier d’index prévu ou ne le sélectionne pas. Ce résultat ne signifie pas automatiquement que les articles de la base ont été supprimés.

Le résultat recherché est double : arrêter l’exposition de la liste puis retrouver le bon fichier d’entrée du site. Désactiver la liste peut produire une page 403 tant que l’index manque ; cette étape contient le symptôme mais ne répare pas encore l’accueil. Il faut ensuite vérifier le domaine, sa racine et le fichier qui doit lancer WordPress.

Les manipulations demandent le panneau du domaine, un accès fichier ou l’intervention de l’administrateur du serveur. Elles ne commencent pas par l’installation d’une extension WordPress, car le serveur peut produire la liste avant d’exécuter WordPress. Sur WordPress.com ou un hébergement entièrement géré, fournissez l’adresse exacte au prestataire. Dans un multisite, identifiez le domaine et le répertoire concernés avant de changer une configuration commune.

Conserver une preuve limitée et protéger les fichiers privés

Notez l’adresse exacte, l’heure et les noms de dossiers utiles au diagnostic. Ne diffusez pas une capture complète si elle montre des archives, journaux ou identifiants privés. N’ouvrez pas les fichiers listés pour tester leur contenu. La liste visible et les réglages du domaine suffisent pour commencer le contrôle.

Si des sauvegardes ou fichiers privés sont placés dans ce répertoire public, faites contenir leur accès par le responsable et conservez les originaux dans un emplacement privé approprié. Retirer l’index automatique n’empêche pas nécessairement de télécharger un fichier dont l’adresse est connue. Cette distinction compte lorsque des documents sensibles étaient stockés au mauvais endroit.

Avant de modifier la racine ou un fichier d’entrée, gardez une copie de la configuration actuelle et des fichiers concernés hors du répertoire public. Préparez un accès permettant de revenir en arrière si l’accueil reste inaccessible. Une protection temporaire doit être appliquée au bon périmètre, en tenant compte des autres services qui utilisent le domaine. N’effacez pas les dossiers affichés pour faire disparaître la liste.

Vérifier si la liste concerne l’accueil ou un dossier secondaire

Comparez l’adresse demandée avec celle de l’accueil prévu. Une liste dans /uploads/ ou un dossier de fichiers n’est pas la même panne qu’une liste à la racine du domaine. Le premier cas demande surtout de gérer la publication de ce répertoire ; le second impose aussi de retrouver le point d’entrée du site.

Dans le panneau, relevez la racine documentaire associée au domaine. Puis, dans le gestionnaire de fichiers, vérifiez quel dossier correspond réellement à cette racine et quels fichiers d’index y existent. Un WordPress installé dans un autre dossier ne sera pas trouvé simplement parce que sa base de données est accessible.

1. Relevez le domaine, le protocole et le chemin complet de l’adresse qui liste les fichiers.
2. Comparez avec l’accueil attendu, sans supposer que tous les sous-domaines partagent leur racine.
3. Identifiez le dossier servi dans le panneau du domaine.
4. Examinez ses fichiers d’entrée sans les écraser.
5. Choisissez ensuite entre correction de racine, récupération d’un index absent et configuration de sélection d’index.

Désactiver la liste du dossier dans cPanel quand cet outil existe

Ce premier parcours contient l’affichage automatique sans installer d’extension. Dans cPanel, ouvrez Advanced ou Avancé, puis Indexes. Si l’outil est absent, demandez à l’hébergeur s’il l’autorise : sa présence dépend de la configuration du compte. Ne prenez pas automatiquement le répertoire personnel comme périmètre de modification.

Conservez l’option actuelle, puis choisissez No Indexing pour le dossier concerné. L’outil peut afficher un refus d’accès à la place de la liste si aucun index n’est disponible. C’est le résultat attendu pour cette étape de protection, mais l’accueil reste à réparer si ce dossier est celui du site.

1. Dans Indexes, ouvrez Settings si nécessaire, choisissez Document Root for et le domaine concerné, puis Save Changes pour commencer la navigation dans sa racine.
2. Naviguez jusqu’au dossier exact qui produit la liste. Cliquez Edit dans sa colonne Actions et relevez l’option initiale.
3. Choisissez No Indexing puis Save. Vérifiez que la colonne Index Type reflète ce choix pour le bon dossier.
4. Rechargez l’adresse dans une nouvelle requête et vérifiez l’absence de liste. Un accueil devenu 403 demande encore la réparation de l’index.
5. Si ce réglage ne s’applique pas, faites vérifier la couche qui sert réellement le domaine, sans multiplier les modifications sur d’autres dossiers.

Vérifier les fichiers présents sans les remplacer tous

Dans le gestionnaire de fichiers ou par SFTP, examinez la racine documentaire confirmée. Vérifiez si index.php existe, sa taille, sa date et son contenu dans une copie privée. Un fichier vide, absent ou remplacé par un autre produit ne se traite pas comme un simple ordre de priorité d’index.

WordPress peut avoir un fichier d’entrée adapté à une installation particulière. La racine publique peut appeler un cœur situé ailleurs. Ne remplacez donc pas tous les fichiers nommés index.php par celui d’une archive téléchargée. Les petits fichiers d’index présents dans certains sous-dossiers n’ont pas tous le rôle de lancer l’accueil.

Si une consultation de index.php proposée par le responsable renvoie du code PHP ou déclenche un téléchargement, arrêtez les essais publics et faites traiter l’exécution PHP. La sélection d’index ne suffit pas dans ce cas. Si le fichier est correct et exécuté normalement mais que l’adresse du dossier produit encore une liste, la priorité ou le mécanisme d’index du serveur devient la piste principale. Conservez ces deux résultats distincts.

Corriger la racine documentaire quand le domaine vise le mauvais dossier

Cette approche convient si le panneau montre une racine différente du dossier public prévu pour le site. Avec cPanel, ouvrez Domains et regardez Document Root sur la ligne du domaine. Le lien ouvre le dossier dans le gestionnaire de fichiers ; l’action Manage sert à ses réglages. La racine du domaine principal et celles des domaines partageant sa racine ne sont pas modifiables par ce parcours. Une offre gérée peut aussi imposer l’intervention du prestataire.

Conservez le chemin initial et faites confirmer le nouveau dossier par l’architecture du site. Ne pointez pas le domaine vers un répertoire privé contenant la configuration ou des sauvegardes. Changer la racine n’est pas équivalent à déplacer tous les fichiers ; un dossier public existant peut simplement être mal associé au domaine.

Dans l’écran de gestion, New Document Root attend un chemin relatif au répertoire personnel du compte. Vérifiez le chemin résultant indiqué par le panneau et faites-le confirmer si le préfixe vous paraît ambigu. Ne recopiez pas une adresse web ou un chemin absolu pris sur un autre serveur. Il n’est pas nécessaire de supprimer le domaine ni de changer ses DNS ou ses services de messagerie.

1. Dans Domains, identifiez le domaine exact et sa racine actuelle.
2. Utilisez Manage si le compte permet le changement correspondant.
3. Dans New Document Root, indiquez le dossier public confirmé au format attendu, puis cliquez Update. Cette action change l’association ; elle ne déplace pas les fichiers.
4. Vérifiez l’accueil puis une page interne et l’administration.
5. En cas d’erreur ou d’effet sur le mauvais site, remettez le chemin initial et faites corriger l’association avec le responsable.

Restaurer le fichier d’entrée manquant depuis une source adaptée

Si la racine est correcte mais que le fichier d’entrée manque, recherchez d’abord une copie fiable correspondant à cette installation. Une sauvegarde du site peut conserver son adaptation de chemin. Pour une installation WordPress standard sans adaptation, le fichier officiel de la même version constitue la référence à comparer. Relevez cette version dans l’inventaire de maintenance ; si nécessaire, le responsable peut lire la valeur de version dans une copie privée de wp-includes/version.php, sans exécuter un fichier de diagnostic public. Gardez les fichiers existants avant tout remplacement.

Récupérez l’archive depuis WordPress.org ou la sauvegarde privée validée, puis extrayez-la localement. Identifiez le seul fichier nécessaire. Ne transférez pas toute l’archive sur la production pour résoudre une absence d’index, et ne remplacez pas wp-config.php ou wp-content. Une récupération ciblée doit conserver les contenus et la configuration du site.

1. Confirmez que le fichier manque réellement dans la racine servie.
2. Choisissez une source fiable correspondant à la version et à l’architecture de l’installation.
3. Comparez le fichier d’entrée avec l’adaptation attendue avant transfert.
4. Remettez seulement ce fichier par l’accès autorisé, avec les droits appropriés.
5. Vérifiez l’accueil et gardez la copie initiale pour revenir à l’état précédent si l’hypothèse était incorrecte.

Corriger la sélection d’index sur Apache dans le contexte autorisé

Avec Apache confirmé, DirectoryIndex détermine les fichiers cherchés pour une adresse de répertoire. L’exemple convient si cette ligne remplace la définition effective du dossier concerné. Plusieurs directives DirectoryIndex au même niveau ajoutent leurs noms à la liste existante : coller une nouvelle ligne à la fin ne garantit donc pas la priorité d’index.php. Faites corriger la définition existante plutôt que multiplier les règles.

Le fichier .htaccess n’est utilisable que si ces directives y sont autorisées. DirectoryIndex dépend notamment de la catégorie Indexes ; l’autorisation d’Options doit être vérifiée séparément. Si toutes les dérogations sont désactivées, ce fichier peut être ignoré. Ne demandez pas d’ouvrir globalement toutes les dérogations pour ce seul besoin ; le responsable choisira le réglage limité ou la configuration serveur.

Options -Indexes retire uniquement l’option de liste automatique, en conservant les autres options applicables. Cela ne protège pas chaque fichier contre une adresse directe. Le bon index doit exister et PHP doit déjà être exécuté correctement. Conservez les règles de redirection et de sécurité étrangères à cette correction.

1. Sauvegardez en privé la configuration ou le fichier .htaccess concerné.
2. Faites confirmer le dossier, l’héritage des directives et leur autorisation ; corrigez l’unique définition utile.
3. Pour une configuration serveur, utilisez apachectl configtest dans le contexte du service avant application par l’exploitation.
4. Pour .htaccess, contrôlez aussi une nouvelle requête vers le dossier et le journal d’erreurs privé : ce fichier est lu à la requête, et le contrôle de la configuration principale ne suffit pas à le valider.
5. Si une erreur apparaît, restaurez seulement la définition fautive. Une édition .htaccess peut agir sans rechargement ; conservez la protection contre la liste quand elle est nécessaire.

DirectoryIndex index.php index.html
Options -Indexes

Corriger l’index Nginx sans remplacer son traitement PHP

Avec Nginx, la directive index sélectionne les fichiers dans l’ordre indiqué. Le fragment ci-dessous appartient au contexte effectif du site, dans http, server ou location selon sa configuration. La sélection d’un index peut produire une redirection interne et choisir un autre bloc location. Il faut donc préserver les règles qui transmettent PHP au moteur ; ajouter index.php ne suffit pas à l’exécuter.

autoindex est désactivé par défaut. Une liste visible demande d’identifier où il a été activé, ou quelle autre couche produit la réponse. autoindex off empêche la liste dans son périmètre, sous réserve de la configuration effective plus précise. N’ajoutez pas ce fragment dans .htaccess, que Nginx ne traite pas comme Apache. Une configuration générée par le panneau doit être modifiée par son mécanisme durable.

1. Conservez la configuration active et identifiez le contexte de l’accueil.
2. Corrigez la définition d’index sans supprimer les règles PHP existantes.
3. Contrôlez avec nginx -t en utilisant le binaire, les droits et le fichier de configuration du service concerné. Ce contrôle vérifie aussi l’ouverture des fichiers référencés ; corrigez ses erreurs avant toute application.
4. Après réussite, appliquez par l’exploitation ; une installation standard peut employer nginx -s reload.
5. Si le résultat est incorrect, restaurez l’ancienne définition, contrôlez puis appliquez le retour.

index index.php index.html;
autoindex off;

Appliquer les changements au bon serveur et conserver le retour

Un panneau, un proxy et plusieurs serveurs peuvent servir le même domaine. Vérifiez que le changement concerne celui qui répond à l’adresse observée. Une ancienne copie conservée par un cache peut aussi montrer une liste alors que l’origine a déjà été corrigée. La comparaison doit s’appuyer sur la configuration et les journaux de la même requête.

Pour une édition de configuration serveur, une vérification de syntaxe réussie ne charge pas automatiquement le nouveau réglage. Le responsable applique ensuite la méthode prévue par son service. Sur une installation Apache standard, un contrôle réussi peut être suivi de apachectl graceful avec les mêmes droits et le même contexte. Un panneau peut piloter une autre procédure qu’il faut conserver.

Gardez le moyen de remettre la racine, l’index ou la configuration initiale séparément. Ne rétablissez pas une liste publique simplement pour reproduire une preuve si une exposition privée a été identifiée. Le retour d’un réglage de diagnostic ne doit pas annuler une mesure de protection nécessaire. Notez ce qui a été corrigé et ce qui reste temporaire pour que le prochain intervenant ne confonde pas les deux.

Éviter une extension qui agirait trop tard dans le parcours

Une liste de répertoire peut être générée sans démarrage de WordPress. Installer une extension de sécurité dans l’administration ne garantit donc pas qu’elle modifiera cette réponse du serveur. Elle ne choisit pas automatiquement la racine documentaire du domaine et ne recrée pas le fichier d’entrée manquant. Le panneau ou la configuration du serveur restent les voies appropriées pour ce symptôme.

Si un outil déjà présent gère une règle d’index, identifiez son mécanisme et son propriétaire avant d’éditer le fichier qu’il produit. Une modification manuelle peut être écrasée à la prochaine sauvegarde de ses réglages. Inversement, supprimer tout le fichier de règles pour tester l’index peut retirer des redirections ou des protections utiles.

N’ajoutez pas non plus un fichier index.php vide à la racine pour considérer le site réparé. Il peut faire disparaître la liste tout en laissant un accueil blanc. Les fichiers d’index de protection de certains sous-dossiers ne sont pas le contrôleur d’entrée de WordPress. Le résultat attendu reste le rendu du bon site, avec un index automatique retiré là où il ne doit pas être public.

Vérifier l’accueil, les pages internes et les dossiers concernés

Après correction, ouvrez l’accueil dans une nouvelle requête et confirmez son contenu, pas seulement un statut HTTP 200. Testez une page interne et l’administration pour vérifier que la racine et le fichier d’entrée correspondent à la même installation. Contrôlez le domaine avec et sans le sous-domaine attendu si ces adresses font partie du parcours normal.

Reprenez ensuite l’adresse exacte qui affichait la liste. Un dossier sans index, destiné à rester non listable, peut légitimement répondre 403. Le dossier de l’accueil doit servir le site prévu. Si des fichiers privés étaient mal placés, vérifiez leur protection avec le responsable ; une liste masquée n’établit pas à elle seule leur inaccessibilité par adresse directe.

Conservez le relevé des modifications utiles et retirez les réglages d’essai qui n’ont rien apporté. Si l’accueil est rétabli mais que des pages internes échouent, traitez les règles de navigation séparément. Ne modifiez pas de nouveau le fichier d’entrée qui fonctionne sans preuve liée à ce nouveau symptôme. La réparation est validée lorsque les réponses correspondent aux usages prévus de chaque adresse.

Prévenir le retour d’un index automatique après déploiement

Documentez le dossier public du domaine, le fichier d’entrée et la configuration qui choisit cet index. Lors d’un transfert ou d’un déploiement, contrôlez ces trois éléments avant d’ouvrir le site. Une archive copiée dans le mauvais niveau de dossier peut laisser la racine sans index alors que tous les fichiers semblent présents dans le compte.

Gardez les sauvegardes et journaux privés hors du répertoire publié, avec leur procédure d’accès indépendante. N’utilisez pas la désactivation de la liste comme seule protection d’un document sensible. Vérifiez également les paramètres hérités quand un nouveau sous-dossier doit servir des fichiers ou héberger une copie de test.

Pour une aide technique, fournissez l’adresse, l’heure, la racine documentaire relevée et les noms des fichiers d’index présents, avec les données privées masquées. Précisez ce que donne l’accueil après désactivation de la liste et quelle modification a été appliquée. Ce dossier permet de distinguer mauvais dossier, fichier absent et règle de sélection incorrecte, sans effacer tout le contenu ni refaire une installation qui n’était pas nécessaire.