Les articles WordPress renvoient une erreur 404 mais la page d'accueil fonctionne

Si votre page d’accueil se charge correctement mais que chaque article et chaque page renvoie une erreur 404, c’est que les règles de réécriture d’URL dont WordPress dépend sont absentes ou cassées dans votre fichier .htaccess. La solution la plus rapide : allez dans Réglages → Permaliens dans wp-admin et cliquez sur Enregistrer les modifications sans rien changer du tout. Cela force WordPress à régénérer le bloc de réécriture. Si les 404 persistent, c’est que votre .htaccess n’est pas accessible en écriture par le serveur web, qu’Apache est configuré pour l’ignorer, ou que vous êtes sous Nginx (qui n’utilise pas du tout .htaccess).

Pourquoi la page d’accueil fonctionne mais pas les articles

Votre page d’accueil fonctionne parce qu’une requête vers / est servie directement par index.php à la racine du site. Aucune réécriture n’est nécessaire.

Une requête vers /2026/mon-article/, c’est différent. Ce chemin ne correspond à aucun dossier réel sur le disque. Pour que WordPress puisse y répondre, Apache doit rediriger la requête en interne vers index.php ; WordPress lit alors REQUEST_URI, le compare aux règles de réécriture stockées dans l’option rewrite_rules de la base de données, résout les variables de requête (WP::parse_request()) et charge le bon article.

C’est le passage de relais entre Apache et index.php qui casse. Il dépend entièrement de ce bloc dans le .htaccess :

# 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

Les deux lignes RewriteCond signifient : si le chemin demandé n’est pas un fichier réel (!-f) et n’est pas un répertoire réel (!-d), envoie-le vers index.php. Supprimez ce bloc et Apache cherche un répertoire /2026/mon-article/ littéral, ne le trouve pas, et renvoie sa propre erreur 404 — avant même que WordPress ne voie la requête.

Pourquoi WordPress écrase le .htaccess quand vous enregistrez les permaliens

C’est la partie que la plupart des guides passent sous silence. Quand vous cliquez sur Enregistrer dans l’écran des Permaliens, WordPress appelle flush_rewrite_rules(). Sous Apache avec un .htaccess accessible en écriture, cela déclenche save_mod_rewrite_rules(), qui régénère le bloc ci-dessus via WP_Rewrite::mod_rewrite_rules() et le réécrit avec insert_with_markers().

insert_with_markers() ne touche qu’aux lignes situées entre # BEGIN WordPress et # END WordPress. Tout ce qui se trouve en dehors de ces marqueurs est laissé intact. Tout ce qui se trouve à l’intérieur est supprimé et réécrit. Les versions récentes de WordPress affichent même l’avertissement directement dans le fichier :

Any changes to the directives between these markers will be overwritten.

Donc « WordPress écrase mon .htaccess » est vrai, mais à prendre au sens strict : il ne réécrit que son propre bloc balisé, et uniquement quand le fichier est accessible en écriture. Si le fichier n’est pas accessible en écriture, l’enregistrement ne fait rien du tout sur le disque, sans le moindre message. WordPress affiche un avis jaune sur l’écran des Permaliens vous demandant de coller les règles manuellement, et si vous ne remarquez pas cet avis, votre bloc de réécriture reste absent et chaque article continue de renvoyer une 404.

Comment corriger le problème, dans l’ordre

1. Ré-enregistrez vos permaliens. Réglages → Permaliens → Enregistrer les modifications. Aucune modification nécessaire. Cela relance le flush et réécrit le bloc. Cela résout la majorité des cas, y compris les règles obsolètes après une migration.

2. Vérifiez que le .htaccess existe et est accessible en écriture. Il se trouve dans le même dossier que wp-config.php. C’est un fichier caché (dotfile), alors activez « afficher les fichiers cachés » dans votre client FTP ou utilisez :

ls -la /path/to/wordpress/.htaccess

S’il est absent, créez-le et collez-y le bloc correct. Si votre installation se trouve dans un sous-répertoire, RewriteBase et la cible finale de la réécriture doivent correspondre à ce chemin — se tromper là-dessus est la raison la plus fréquente pour laquelle un bloc collé à la main renvoie encore une 404. Notre générateur de .htaccess construit le bloc exact adapté au chemin de votre installation, pour que vous n’ayez pas à deviner.

3. Confirmez qu’Apache est autorisé à lire le .htaccess. Si l’hôte virtuel a AllowOverride None, Apache ignore complètement le fichier, quel que soit son contenu. Il vous faut AllowOverride All (ou au moins FileInfo) sur le répertoire WordPress. Cela se trouve dans la configuration du serveur, pas dans le .htaccess, donc cela nécessite un accès au serveur :

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Confirmez que mod_rewrite est activé. Sous Debian/Ubuntu :

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Sous Nginx, il n’y a pas de .htaccess. Les réécritures se placent plutôt dans le bloc server :

location / {
    try_files $uri $uri/ /index.php?$args;
}

Diagnostic rapide : à qui appartient cette 404 ?

Regardez la page 404. Si c’est une page d’erreur Apache ou de l’hébergeur sans mise en forme, c’est qu’Apache n’a jamais atteint WordPress — il s’agit d’un problème de .htaccess ou de configuration serveur (étapes 2 à 4). Si c’est la page 404 mise en forme par votre thème, c’est que WordPress reçoit bien la requête mais ne parvient pas à la faire correspondre — les règles dans la base de données sont obsolètes, et ré-enregistrer les permaliens (étape 1) est la solution. Cette seule distinction fait gagner à la plupart des gens une heure de tâtonnements.

Ce qu’il ne faut pas faire

Ne commencez pas par désactiver tous vos plugins. Un symptôme purement « les articles renvoient une 404, la page d’accueil fonctionne » est un problème de réécriture, pas un conflit de plugin. Désactiver les plugins est le réflexe qu’on voit sur les forums, mais cela ne touche presque jamais à ce problème.

Ne faites pas chmod 777 sur votre .htaccess. WordPress a besoin que le fichier soit accessible en écriture par l’utilisateur du serveur web, ce qui n’est pas la même chose qu’accessible en écriture par tout le monde. 644 avec le bon propriétaire est correct et sûr ; 777 est une faille de sécurité qui, de toute façon, ne corrigera pas le routage.

Ne collez pas de règles de réécriture personnalisées à l’intérieur des marqueurs # BEGIN WordPress / # END WordPress. Elles seront effacées dès que quelqu’un enregistrera les permaliens. Placez vos directives personnalisées au-dessus de la ligne # BEGIN WordPress.

Ne réinstallez pas WordPress. Les fichiers du cœur vont bien. Il s’agit d’un seul bloc de texte manquant, pas d’une installation corrompue.

N’accusez pas votre thème. Le routage des permaliens fait partie du cœur de WordPress. Un thème ne peut ni en être la cause ni le corriger.

Toujours bloqué ?

Si vous avez ré-enregistré les permaliens, confirmé que le bloc est présent et accessible en écriture, et défini AllowOverride All, le suspect restant est un plugin de sécurité ou une règle au niveau de l’hébergeur qui régénère ou verrouille le .htaccess à votre insu. Vérifiez l’horodatage de modification du fichier juste après un enregistrement des permaliens — s’il n’a pas changé, quelque chose bloque l’écriture. Régénérez un bloc propre avec le générateur de .htaccess, collez-le, et retestez avec un rafraîchissement forcé.