Fichier .htaccess par défaut de WordPress : contenu et restauration

Le fichier .htaccess par défaut de WordPress est le court bloc RewriteEngine que le logiciel écrit dans le .htaccess à la racine de votre site pour que des permaliens comme /2026/10/nom-article/ se résolvent au lieu de renvoyer une 404. Il se présente ainsi :

# 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

C’est le bloc exact, reproduit du guide officiel de WordPress sur Apache HTTP Server et de la logique de réécriture documentée sur la page HelpHub consacrée aux permaliens. Si votre RewriteBase n’est pas / — par exemple parce que WordPress est installé dans un sous-dossier — il correspondra à ce chemin à la place, ce qui est également normal et généré par WordPress lui-même.

L’essentiel

• WordPress génère ce bloc automatiquement, sous Apache et LiteSpeed uniquement, dès que le fichier est accessible en écriture et que vous enregistrez Réglages > Permaliens.
• Si le fichier est absent ou corrompu, tous les permaliens sauf la page d’accueil renvoient une 404, car seule la page d’accueil peut être trouvée sans les règles de réécriture.
• Tout ce que vous ou une extension ajoutez doit se trouver au-dessus de # BEGIN WordPress, jamais à l’intérieur des marqueurs — WordPress réécrit tout ce qui s’y trouve à chaque enregistrement des permaliens.

Besoin de reconstruire le fichier avec votre vrai chemin et quelques règles supplémentaires ? Le générateur .htaccess WordPress en assemble un correct directement dans votre navigateur.

Ce que fait chaque ligne

RewriteEngine On active le module mod_rewrite d’Apache pour ce répertoire ; sans elle, tout ce qui suit est inerte.

RewriteBase / indique à Apache que les chemins réécrits sont relatifs à la racine du site. WordPress l’ajuste pour correspondre à l’emplacement réel du site — une installation en sous-dossier reçoit RewriteBase /blog/, pas /.

RewriteRule ^index\.php$ - [L] est une garde sans effet : si la requête est déjà index.php, la réécriture s’arrête et la requête passe inchangée.

Les deux lignes RewriteCond constituent la logique réelle. %{REQUEST_FILENAME} !-f et !-d demandent « cette requête ne correspond-elle PAS à un fichier réel, et PAS à un dossier réel ? ». Les deux doivent être vraies pour que la règle finale se déclenche — une vraie image, un fichier CSS ou un PDF téléversé est donc servi directement sans jamais toucher le routage de WordPress.

RewriteRule . /index.php [L] est ce qui fait fonctionner les permaliens : tout ce qui a survécu aux deux conditions précédentes — c’est-à-dire qui n’est ni un fichier ni un dossier réel — est envoyé vers index.php, et le routage propre de WordPress (WP_Query, balises de réécriture) décide quel article, quelle page ou quelle archive cette URL désigne réellement.

Quand WordPress recrée ce fichier, et quand il n’y parvient pas

WordPress essaie d’écrire le .htaccess lui-même chaque fois que vous ouvrez Réglages > Permaliens et cliquez sur Enregistrer les modifications, même si rien n’a changé à l’écran. Cet enregistrement déclenche flush_rewrite_rules(), qui tente d’ouvrir .htaccess en écriture et d’y insérer le bloc actuel entre les marqueurs.

Cette tentative échoue silencieusement, laissant le fichier absent ou obsolète, quand :

• Le fichier ou son dossier parent n’est pas accessible en écriture pour l’utilisateur sous lequel PHP s’exécute. Sur de nombreux hébergements mutualisés, PHP s’exécute sous un utilisateur système différent de celui qui a envoyé les fichiers par FTP, donc des permissions qui paraissent correctes dans un client FTP peuvent tout de même empêcher WordPress d’écrire.
• Vous êtes sous nginx. .htaccess est un mécanisme propre à Apache et LiteSpeed (la documentation Apache sur AllowOverride explique pourquoi : nginx n’a pas de fichier de configuration par répertoire relu à chaque requête). L’équivalent sous nginx est une directive try_files dans le bloc server, modifiable uniquement par quelqu’un ayant accès au serveur ; WordPress ne peut jamais l’écrire à votre place.
• AllowOverride est réglé sur None pour le répertoire de votre site dans la configuration principale d’Apache. C’est ce réglage qui permet à un .htaccess de surcharger quoi que ce soit ; la documentation Apache est explicite : avec AllowOverride None, « les fichiers .htaccess sont complètement ignorés » — WordPress peut écrire un fichier parfait, il restera sans effet jusqu’à ce que ce réglage soit changé au niveau du serveur.
• Le fichier a été supprimé ou n’a jamais existé et quelque chose dans l’enregistrement n’a pas déclenché de régénération — le plus souvent parce que les permaliens avaient déjà la même structure, donc WordPress n’a vu aucun changement à réécrire.

Comment le restaurer à la main

Si les articles et les pages affichent une 404 alors que la page d’accueil fonctionne toujours, c’est la signature d’un .htaccess absent ou cassé. Réparez-le en deux étapes.

1. Essayez d’abord la solution en un clic. Allez dans Réglages > Permaliens depuis l’administration WordPress et cliquez sur Enregistrer les modifications sans rien changer. Si le fichier est accessible en écriture, cela suffit à le régénérer.

2. Si cela ne suffit pas, créez le fichier à la main. Connectez-vous en FTP/SFTP ou via le gestionnaire de fichiers de votre hébergeur, allez dans le dossier où WordPress est installé (celui qui contient wp-config.php) et vérifiez si .htaccess existe — c’est un fichier caché, certains gestionnaires de fichiers le masquent par défaut ; activez « afficher les fichiers cachés ».

• S’il est absent, créez un nouveau fichier nommé exactement .htaccess (pas de .txt, rien avant le point).
• Collez le bloc par défaut ci-dessus, en ajustant RewriteBase si WordPress vit dans un sous-dossier.
• Enregistrez, puis rechargez le permalien d’un article pour confirmer que ça fonctionne.

Si la 404 persiste après cela, la cause n’est plus « .htaccess est absent » mais « .htaccess est ignoré » — vérifiez AllowOverride avec votre hébergeur, car un fichier correct dans un répertoire où Apache a l’ordre de l’ignorer se comporte exactement comme l’absence de fichier.

Vos propres règles face au bloc de WordPress

Une extension ou une modification manuelle peut ajouter ses propres règles — redirections, protection anti-hotlinking, en-têtes de cache. C’est un bloc distinct de celui que génère WordPress, et les deux ne devraient jamais se chevaucher :

# Règles ajoutées par vous ou une extension — AU-DESSUS des marqueurs WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # exemple : protection anti-hotlinking, règles de cache, etc.
</FilesMatch>

# 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

Tout ce qui est placé entre # BEGIN WordPress et # END WordPress est supprimé silencieusement la prochaine fois que quelqu’un enregistre l’écran des Permaliens, parce que WordPress traite toute cette portion comme la sienne et la réécrit entièrement. C’est la cause la plus fréquente de « ma règle personnalisée a disparu » — elle n’a jamais été retirée volontairement, elle se trouvait juste dans un bloc que WordPress considère comme le sien. Pour les redirections en particulier, voir les règles de redirection .htaccess WordPress bien faites pour savoir où elles doivent aller et comment éviter les boucles.

C’est aussi la cause la plus fréquente d’une 500 Internal Server Error soudaine juste après avoir modifié le fichier : une règle copiée d’un forum écrit pour une autre version d’Apache (syntaxe Order/Deny de la 2.2 mélangée à la syntaxe Require de la 2.4) casse l’analyse de tout le fichier, y compris le bloc WordPress situé en dessous, et c’est le site entier qui tombe — pas seulement la partie modifiée.

Au-delà du bloc par défaut

Le bloc par défaut ne gère que le routage des permaliens. Si vous voulez aussi renforcer l’accès aux fichiers sensibles ou ajouter la poignée de règles .htaccess qui réduisent réellement la surface d’attaque — bloquer l’exécution PHP dans /uploads, refuser l’accès direct à wp-config.php —, consultez les règles de sécurité .htaccess WordPress qui aident vraiment. Et si les permaliens renvoient une 404 pour une autre raison — mauvaise structure de permaliens, une couche de cache servant des règles obsolètes, conflits multisite en sous-répertoires —, les permaliens WordPress qui ne fonctionnent pas passe en revue les autres causes.

Questions fréquentes

Qu’est-ce que le fichier .htaccess par défaut de WordPress ? C’est le bloc RewriteEngine que WordPress écrit entre # BEGIN WordPress et # END WordPress pour que les permaliens se résolvent vers index.php au lieu de renvoyer une 404.

Quel est le code exact du .htaccess par défaut de WordPress ? RewriteEngine On, RewriteBase /, une règle de passage pour index.php, deux conditions vérifiant que la requête n’est ni un fichier ni un dossier réel, et une règle finale envoyant tout le reste vers index.php. Le bloc complet est reproduit en haut de ce guide.

Pourquoi tous mes articles affichent-ils une 404 sauf la page d’accueil ? La page d’accueil peut être trouvée sans aucune règle de réécriture ; tout autre permalien en a besoin. Un .htaccess absent ou corrompu sous Apache produit exactement ce schéma.

WordPress recrée-t-il .htaccess automatiquement ? Seulement si le fichier est accessible en écriture — ré-enregistrer Réglages > Permaliens déclenche ça. Si le fichier n’est pas accessible en écriture, absent chez un hébergeur qui ne le génère pas automatiquement, ou si AllowOverride est désactivé, WordPress ne peut pas le corriger à votre place et vous devez créer ou corriger le fichier vous-même.

Pourquoi nginx n’a-t-il pas de fichier .htaccess WordPress ? .htaccess ne fonctionne que sous Apache et LiteSpeed. nginx n’a pas de fichier de configuration par répertoire et ignore totalement .htaccess ; le même routage s’écrit comme une règle try_files dans le bloc server de nginx.

Pourquoi mon .htaccess s’est-il cassé après l’enregistrement des permaliens ? Une règle personnalisée a été placée à l’intérieur des marqueurs # BEGIN WordPress / # END WordPress plutôt qu’au-dessus, et WordPress a réécrit toute cette portion lors du prochain enregistrement des permaliens.

---

Reconstruisez un .htaccess propre et correct — bloc de permaliens par défaut plus toute règle de sécurité ou de redirection dont vous avez vraiment besoin — avec le générateur .htaccess WordPress gratuit.