Erreur 404 WordPress sur toutes les pages : réparer les permaliens

Toutes tes pages renvoient 404 — sauf l’accueil

Ce matin, on reçoit un message : “Mon site marche mais toutes mes pages sont en 404. L’accueil s’affiche, mais les articles, les produits, les catégories — rien.” C’est l’un des cas les plus fréquents et les plus angoissants sur WordPress, et pourtant l’un des plus rapides à corriger quand on sait quoi chercher.

Ce symptôme précis — l’accueil qui fonctionne, le reste en 404 — n’est presque jamais une suppression accidentelle de contenus. C’est une rupture dans la couche de routage de WordPress : le moteur de réécriture d’URL ne fonctionne plus correctement. Les pages existent bien dans la base de données, elles sont juste inaccessibles.

À ne pas confondre avec un 404 de page supprimée : si une seule URL spécifique renvoie 404 (et qu’elle n’apparaît plus dans l’admin), c’est une page réellement absente — restaure-la depuis une sauvegarde ou recrée-la. L’article ci-dessous traite exclusivement du cas “toutes les pages en 404 sauf l’accueil”.

Pourquoi ça arrive

• Migration de serveur ou de domaine : le fichier .htaccess n’a pas suivi, ou les règles de réécriture pointent encore vers l’ancien chemin.
• Module mod_rewrite désactivé sur Apache : WordPress en a besoin pour transformer /ma-page/ en une requête interne lisible.
• .htaccess corrompu ou vidé : une mise à jour de plugin, une opération FTP mal terminée, ou un conflit ont écrasé les règles.
• WordPress installé dans un sous-dossier sans que la configuration le sache.
• Mise à jour WordPress ou changement de thème qui a réinitialisé la structure des permaliens sans la ré-enregistrer.
• Hébergeur Nginx sans configuration équivalente : Nginx n’utilise pas .htaccess, il faut un bloc try_files dans la config serveur.
• Permissions incorrectes sur .htaccess : le fichier existe mais Apache ne peut pas le lire.

Si tu viens de faire une mise à jour WordPress qui a cassé le site, commence par cette liste de causes avant d’aller plus loin.

Solution 1 — Régénérer les permaliens depuis l’admin (30 secondes)

C’est le premier geste, et il règle le problème dans la majorité des cas.

1. Connecte-toi à WP Admin → Réglages → Permaliens.
2. Sans rien modifier, clique sur “Enregistrer les modifications” en bas de page.
3. WordPress réécrit alors les règles de réécriture dans le .htaccess automatiquement.
4. Vide le cache (plugin de cache, cache navigateur) et teste une page.

Si tu vois le message “Si votre fichier .htaccess est accessible en écriture, nous pourrions le faire automatiquement, mais comme il ne l’est pas…”, passe directement à la Solution 3.

Solution 2 — Vérifier et corriger le fichier .htaccess

Si la régénération depuis l’admin n’a pas suffi, le .htaccess est probablement corrompu ou vide.

Accéder au fichier

Via FTP (FileZilla, Cyberduck) ou le gestionnaire de fichiers de ton hébergeur, navigue à la racine de WordPress. Le .htaccess est un fichier caché — active l’affichage des fichiers cachés dans ton client FTP.

Contenu minimal correct pour WordPress

Remplace le contenu du fichier par ce bloc standard :

# 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

Si WordPress est installé dans un sous-dossier (ex. monsite.fr/wp/), ajuste RewriteBase /wp/ et RewriteRule . /wp/index.php [L].

Sauvegarde, vide les caches, teste. Si c’était bien le .htaccess le coupable, le site est de nouveau opérationnel.

Permissions du fichier

Le .htaccess doit avoir les permissions 644 (lecture/écriture pour le propriétaire, lecture seule pour les autres). En FTP, clic droit → Permissions → 644. Ni plus permissif (666, 777), ni trop restrictif (400).

Solution 3 — Vérifier que mod_rewrite est activé

mod_rewrite est le module Apache qui permet les URLs propres. Sans lui, WordPress ne peut pas router /ma-page/ vers index.php.

Tester depuis l’admin

Va dans WP Admin → Outils → Santé du site → Informations → Serveur. Cherche la ligne mod_rewrite. Si elle est absente ou marquée inactive, le module est désactivé.

Activer mod_rewrite (accès SSH requis)

Si tu as accès SSH à ton serveur (voir le guide SSH : connexion serveur, clés et bonnes pratiques) :

sudo a2enmod rewrite
sudo systemctl restart apache2

Sans accès SSH, contacte ton hébergeur : la plupart (OVH, Hostinger, o2switch) ont mod_rewrite activé par défaut. S’il est désactivé, c’est souvent une option à cocher dans le panel.

Solution 4 — Cas Nginx : configurer try_files

Nginx n’utilise pas .htaccess. Si ton hébergeur tourne sous Nginx (Kinsta, Serverpilot, certaines configs VPS), les règles de réécriture doivent être dans le bloc server de la config Nginx :

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

Sans cette directive, toutes les URLs WordPress autres que l’accueil tombent en 404. Cette modification nécessite un accès à la configuration Nginx du serveur — demande à ton hébergeur si tu n’as pas la main dessus.

Solution 5 — Forcer la régénération via wp-config.php ou WP-CLI

Si l’admin est inaccessible (par exemple, une erreur 500 coexiste avec les 404), deux options :

Via WP-CLI (si disponible sur l’hébergeur) :

wp rewrite flush --hard

L’option --hard force la réécriture physique du .htaccess, pas seulement le cache interne de WordPress.

Via un plugin de diagnostic comme Query Monitor ou Health Check & Troubleshooting, qui peuvent révéler des conflits de règles de réécriture sans toucher aux fichiers manuellement.

Tableau récapitulatif : cause → solution

Quand passer la main à un pro

Si après ces cinq solutions le problème persiste, c’est que la configuration serveur est plus profondément atteinte : Virtual Host Apache mal configuré, hébergeur avec règles de réécriture globales qui écrasent le .htaccess, WordPress dans une configuration multi-site complexe, ou conflit avec un plugin de sécurité (Wordfence, iThemes) qui bloque les règles de réécriture.

C’est aussi le moment de poser la question de la maintenance préventive : une 404 globale sur un site en production, c’est du chiffre d’affaires ou de la crédibilité perdus à chaque minute. Un environnement de staging et une sauvegarde quotidienne auraient permis de restaurer le site en moins de dix minutes plutôt qu’en plusieurs heures de diagnostic.