Fichier .htaccess par défaut WordPress : code, 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/post-name/ fonctionnent au lieu de renvoyer une 404. Il ressemble à ceci :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ces règles viennent du code que WordPress utilise pour générer le bloc, et elles correspondent au guide .htaccess de WordPress. WordPress écrit aussi trois lignes de commentaire juste après # BEGIN WordPress, qui préviennent que les modifications entre les marqueurs seront écrasées. Elles ne changent pas le fonctionnement des règles.

Dans une installation en sous-dossier, WordPress place le chemin du sous-dossier dans RewriteBase et dans la dernière règle, par exemple RewriteBase /blog/ et RewriteRule . /blog/index.php [L]. Les réseaux multisite utilisent un bloc différent, et WordPress n’écrit pas ce fichier automatiquement pour eux.

L’essentiel

• WordPress génère ce bloc sous Apache et LiteSpeed quand il a un accès en écriture et que les permaliens personnalisés sont activés. Ouvrir Réglages > Permaliens suffit.
• Si le fichier est manquant ou corrompu, les permaliens renvoient une 404 alors que la page d’accueil se charge encore, car elle n’a pas besoin des règles de réécriture.
• Placez ce que vous ou une extension ajoutez au-dessus de # BEGIN WordPress, jamais entre les marqueurs. WordPress remplace tout ce qui s’y trouve quand il met à jour le fichier.

Ce que fait chaque ligne

RewriteEngine On active le module mod_rewrite d’Apache pour ce répertoire ; sans cette ligne, les règles de réécriture qui suivent ne font rien.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] laisse l’URL telle quelle (c’est le sens du -) et copie l’en-tête Authorization de la requête dans une variable du serveur. WordPress lit cette variable pour récupérer un identifiant et un mot de passe envoyés dans l’en-tête, comme un mot de passe d’application.

RewriteBase / définit le préfixe de chemin qu’Apache utilise pour les URL réécrites. WordPress le règle selon l’emplacement du site, donc une installation en sous-dossier reçoit RewriteBase /blog/.

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

Les deux lignes RewriteCond sont la vraie logique. %{REQUEST_FILENAME} !-f et !-d demandent : « Cette requête NE correspond-elle PAS à un fichier réel, et PAS à un répertoire réel ? » Les deux doivent être vraies pour que la dernière règle s’applique. Une vraie image, un fichier CSS ou un PDF téléversé est donc servi directement et ne passe jamais par le routage de WordPress.

RewriteRule . /index.php [L] est ce qui fait fonctionner les permaliens. Tout ce qui remplit ces deux conditions est envoyé vers index.php, et WordPress décide à quel article, quelle page ou quelle archive correspond l’URL.

Quand WordPress recrée ce fichier, et quand il ne le fait pas

WordPress vide ses règles de réécriture à chaque chargement de l’écran Réglages > Permaliens. L’ouvrir suffit donc, sans cliquer sur Enregistrer les modifications. Si le .htaccess est manquant, WordPress le crée tant que le dossier est accessible en écriture et que les permaliens personnalisés sont activés. Si le fichier existe et est accessible en écriture, WordPress remplace le bloc entre les marqueurs.

Cela ne règle pas le problème dans ces cas :

• Le fichier ou son dossier n’est pas accessible en écriture pour l’utilisateur sous lequel PHP s’exécute. L’écran affiche une erreur indiquant que le fichier .htaccess n’est pas accessible en écriture, avec les règles à coller. Chez certains hébergeurs, PHP s’exécute sous un autre utilisateur système que celui qui possède vos envois FTP, donc des droits qui semblent corrects dans un client FTP peuvent quand même bloquer WordPress.
• Vous êtes sous nginx. Le guide nginx de WordPress indique que nginx n’a pas de fichier de configuration par répertoire comme .htaccess et que WordPress ne peut pas modifier la configuration du serveur. Le routage équivalent est une directive try_files dans la configuration du serveur, qu’un administrateur doit modifier.
• AllowOverride est réglé sur None pour le répertoire de votre site dans la configuration principale d’Apache. La documentation d’Apache dit : “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Autrement dit, les fichiers .htaccess sont totalement ignorés tant que vous ne les activez pas explicitement pour un répertoire. WordPress peut écrire un fichier parfait, il restera sans effet. Les règles de réécriture exigent AllowOverride FileInfo (ou All), ce que votre hébergeur devra peut-être changer.
• Vos permaliens sont réglés sur Simple (Plain). Les URL simples n’ont pas besoin de règles de réécriture, donc WordPress ne crée pas le fichier pour elles.

Comment le restaurer à la main

Si les articles et les pages renvoient une 404 alors que la page d’accueil fonctionne, vérifiez d’abord si le .htaccess est manquant ou cassé. Corrigez-le en deux étapes.

1. Essayez d’abord la solution en un clic. Ouvrez Réglages > Permaliens dans wp-admin, puis cliquez sur Enregistrer les modifications sans rien changer. Si WordPress peut écrire le fichier, cela le régénère. Sinon, l’écran affiche l’erreur et les règles dont vous avez besoin.

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 et allez dans le dossier racine de votre site, normalement celui qui contient wp-admin. Vérifiez si .htaccess existe. Son nom commence par un point, donc certains gestionnaires de fichiers le masquent par défaut ; activez « afficher les fichiers cachés ».

• S’il manque, créez un nouveau fichier nommé exactement .htaccess (sans .txt, rien avant le point).
• Collez les règles que WordPress vous a montrées, ou le bloc par défaut du début de ce guide. Dans une installation en sous-dossier, adaptez RewriteBase et la dernière règle.
• Enregistrez, puis rechargez le permalien d’un article pour vérifier que cela fonctionne.

Si la 404 persiste, le .htaccess est peut-être ignoré. Vérifiez AllowOverride avec votre hébergeur, car Apache ignore même un fichier correct quand cette option est désactivée.

Vos propres règles face au bloc de WordPress

Une extension ou une modification manuelle peut ajouter ses propres règles, comme des redirections, une protection contre le hotlinking ou des en-têtes de cache. Gardez-les hors du bloc de WordPress, et au-dessus pour qu’elles s’exécutent avant sa règle générale :

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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 perdu la prochaine fois que WordPress met à jour le fichier, et charger l’écran des permaliens suffit à le déclencher. Les lignes avant et après les marqueurs sont conservées. Pour les redirections en particulier, consultez Règles de redirection .htaccess pour WordPress bien faites pour savoir où les placer et comment éviter les boucles.

Une 500 Internal Server Error juste après avoir modifié le fichier pointe vers ce que vous venez de changer. La documentation d’Apache indique que le journal d’erreurs nommera probablement une directive non autorisée ou une erreur de syntaxe. Des règles copiées d’un ancien tutoriel peuvent en être la cause : Order est une commande invalide sous Apache 2.4 sauf si mod_access_compat est chargé. Annulez la modification pour rétablir le site, puis lisez le journal d’erreurs.

Au-delà du bloc par défaut

Le bloc par défaut ne gère que le routage des permaliens et l’en-tête Authorization. Pour mieux protéger l’accès aux fichiers sensibles, par exemple bloquer l’exécution de PHP dans /uploads ou refuser les requêtes directes vers wp-config.php, consultez Règles de sécurité .htaccess pour WordPress vraiment utiles. Si les permaliens renvoient une 404 pour une autre raison, comme une mauvaise structure de permaliens, une couche de cache qui sert des règles obsolètes ou un conflit de sous-répertoires en multisite, Les permaliens WordPress 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 dans le .htaccess à la racine de votre site. Il transmet l’en-tête Authorization à PHP et envoie vers index.php toute requête qui n’est ni un fichier ni un dossier réel.

Quel est le code exact du .htaccess par défaut de WordPress ? RewriteEngine On, une règle qui transmet l’en-tête Authorization à PHP, RewriteBase /, une règle de passage pour index.php, deux conditions qui vérifient que la requête n’est ni un fichier ni un dossier réel, et une dernière règle qui envoie tout le reste vers index.php. Le bloc complet se trouve au début de ce guide.

Pourquoi tous mes articles affichent-ils une 404 sauf la page d’accueil ? Un fichier .htaccess manquant ou corrompu sous Apache produit ce schéma. Le serveur peut trouver la page d’accueil sans règles de réécriture. Tout autre permalien a besoin de ces règles pour atteindre index.php. Sans elles, Apache cherche un fichier qui n’existe pas et renvoie une 404.

WordPress recrée-t-il .htaccess automatiquement ? Oui, sous Apache ou LiteSpeed avec mod_rewrite, si les permaliens personnalisés sont activés et que WordPress peut écrire à cet endroit. Ouvrir Réglages > Permaliens suffit à le déclencher. Un fichier manquant exige un dossier accessible en écriture, et un fichier existant doit lui-même être accessible en écriture. Sinon, l’écran affiche une erreur, avec les règles à coller à la main.

Pourquoi nginx n’a-t-il pas de fichier .htaccess WordPress ? nginx n’a pas de fichier de configuration par répertoire comme le .htaccess d’Apache. Le même routage s’écrit sous forme de règle try_files dans la configuration du serveur nginx, qu’un administrateur doit modifier car WordPress ne peut pas le faire.

Pourquoi mon .htaccess s’est-il cassé après l’enregistrement des permaliens ? Vérifiez si une règle personnalisée a été placée entre les marqueurs # BEGIN WordPress et # END WordPress. WordPress remplace tout ce qui s’y trouve quand il met à jour le fichier, donc cette règle est perdue. Gardez les règles personnalisées au-dessus des marqueurs.

Sources

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Code source de WordPress : class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4 : .htaccess files, mod_rewrite, Upgrading to 2.4

---

Créez un .htaccess propre et correct, avec le bloc de permaliens par défaut et les règles de sécurité ou de redirection dont vous avez vraiment besoin, grâce au générateur .htaccess WordPress gratuit.