Pages en erreur 404 sur WordPress : réparer les permaliens

404 Not Found

En anglais : 404 Not Found

Vous cliquez sur un article, une page ou une catégorie, et le site affiche « 404 Not Found », « Page non trouvée » ou la page 404 de votre thème, alors que le contenu est bien publié et visible dans l’administration. L’accueil fonctionne souvent encore ; ce sont les adresses « propres » (/mon-article/) qui échouent.

C’est l’un des problèmes les plus courants après une migration, un changement d’hébergeur, le passage d’Apache à nginx ou l’activation d’une extension qui ajoute un type de contenu. Dans l’immense majorité des cas, vos contenus ne sont pas perdus : seule la correspondance entre l’adresse demandée et le contenu est cassée.

Ce que signifie cette erreur

WordPress utilise une seule porte d’entrée, index.php. Pour qu’une adresse comme /mon-article/ y arrive, il faut que le serveur web réécrive l’URL vers index.php, puis que WordPress la reconnaisse grâce à ses règles de réécriture (classe WP_Rewrite, wp-includes/class-wp-rewrite.php, stockées dans l’option rewrite_rules). Deux mécanismes distincts peuvent donc échouer :

• La réécriture côté serveur : sur Apache, un .htaccess absent ou ignoré (mod_rewrite désactivé, AllowOverride None) ; sur nginx, l’absence de try_files vers /index.php?$args. Dans ce cas, c’est le serveur qui répond « 404 Not Found » sans même appeler WordPress ;
• Les règles de WordPress : l’option rewrite_rules est vide ou périmée, par exemple parce qu’un type de contenu a été déclaré sans vider les règles. WordPress répond alors lui-même par sa page 404, dont le titre de l’onglet est « Page non trouvée » (wp-includes/general-template.php).

La distinction est essentielle : si la page d’erreur est celle de votre thème (avec en-tête et menu), WordPress a bien été appelé et ses règles sont en cause ; si c’est une page grise et nue (« Not Found », « 404 Not Found » sur fond blanc), le serveur n’a pas transmis la requête à PHP (et si le message est « Forbidden », voyez plutôt la fiche erreur 403).

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Page 404 grise et nue, sans thème	Réécriture non active côté serveur	.htaccess, mod_rewrite, AllowOverride, try_files nginx
Page 404 du thème, l’accueil fonctionne	Règles de réécriture WordPress périmées	Réenregistrer les permaliens ; wp rewrite flush
Seul un type de contenu (produits, portfolio…) est en 404	Type de contenu enregistré sans purge des règles	Réglages > Permaliens ; code d’activation de l’extension
Tout est en 404 après migration ou changement de serveur	Fichier .htaccess non copié ou configuration serveur différente	Présence de .htaccess ; vhost du nouveau serveur
L’URL avec ?p=123 fonctionne, pas l’adresse propre	Réécriture d’URL inactive	Passer en permaliens « Simple » pour confirmer
Un seul article est en 404	Statut brouillon ou privé, slug modifié, cache	Statut dans l’administration ; cache de pages

Les causes les plus fréquentes

1. Des règles de réécriture périmées après l’activation d’une extension, un changement de thème ou l’ajout d’un type de contenu.
2. Un fichier .htaccess absent, vide ou non pris en compte (Apache) après une migration.
3. Une configuration nginx sans try_files vers index.php, très courante quand on passe d’Apache à nginx.
4. Un .htaccess non inscriptible : WordPress ne peut pas écrire les règles, et l’écran des permaliens vous demande de les ajouter vous-même.
5. Un cache (extension, CDN, navigateur) qui sert une ancienne réponse 404.
6. Un conflit d’adresses : deux contenus avec le même slug, ou une extension qui réserve la même base d’URL.

Solutions pas à pas

Aucune de ces manipulations ne modifie vos contenus, mais sauvegardez d’abord le fichier .htaccess et la base si vous touchez à la configuration. Du moins invasif au plus technique :

1. Réenregistrer les permaliens

C’est la correction qui règle près de la moitié des cas. Dans l’administration, ouvrez « Réglages > Permaliens » et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress régénère ses règles et, sur Apache, tente d’écrire le .htaccess (le simple affichage de cet écran vide déjà les règles : wp-admin/options-permalink.php appelle flush_rewrite_rules()). Le message de succès est « Structure des permaliens enregistrée. » ; s’il est remplacé par « Vous devez mettre à jour votre fichier .htaccess maintenant. », WordPress n’a pas pu écrire le fichier (solution 3). Videz ensuite le cache de pages et testez dans une fenêtre privée.

2. Confirmer avec les permaliens « Simple »

Pour trancher entre un problème de réécriture serveur et un problème de règles, choisissez temporairement la structure « Simple » (adresses en ?p=123) : si les pages s’affichent alors, le serveur ne réécrit pas les URL. Remettez ensuite votre structure (par exemple « Titre de la publication ») une fois le serveur corrigé.

3. Réparer le .htaccess (Apache)

Vérifiez que le fichier .htaccess existe à la racine du site, et qu’il contient les règles par défaut. Si votre fichier est absent, créez-le avec ce contenu (tout ce qui est entre les marqueurs est géré par WordPress) :

# 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

Vérifiez ensuite que le fichier est lisible (644) et que le serveur autorise les surcharges. Activez le module et autorisez .htaccess dans le VirtualHost :

sudo a2enmod rewrite

# dans le VirtualHost ou la section Directory du site
<Directory /var/www/exemple/html>
    AllowOverride All
    Require all granted
</Directory>

sudo apachectl configtest && sudo systemctl reload apache2

4. Ajouter try_files (nginx)

nginx ne lit pas les fichiers .htaccess : la réécriture doit figurer dans la configuration du site. Le bloc location / doit renvoyer vers index.php :

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

Rechargez avec sudo nginx -t && sudo systemctl reload nginx. Pour comparer les deux serveurs, l’article Apache ou nginx pour WordPress détaille ce qui change à la migration.

5. Régénérer les règles avec WP-CLI

Sans accès à l’administration, mais avec SSH, WP-CLI fait la même chose en ligne de commande :

wp rewrite structure '/%postname%/' --hard
wp rewrite flush --hard
wp rewrite list --format=table | head -n 20

--hard réécrit aussi le .htaccess (sans effet sous nginx). La dernière commande liste les règles actives : si elle est vide, WordPress ne connaît aucune règle.

6. Cas d’un type de contenu personnalisé

Si seuls vos contenus personnalisés sont en 404, c’est que l’extension ou le thème qui les déclare n’a pas déclenché la purge. Réenregistrez les permaliens (solution 1). Si vous développez l’extension, videz les règles une seule fois à l’activation, jamais à chaque chargement de page :

register_activation_hook( __FILE__, function () {
    mon_plugin_enregistrer_types(); // déclare les types et taxonomies
    flush_rewrite_rules();
} );
register_deactivation_hook( __FILE__, 'flush_rewrite_rules' );

7. Écarter les autres suspects

• Le statut du contenu : un brouillon, un contenu en attente ou privé renvoie une 404 aux visiteurs.
• Le cache : videz le cache de l’extension, celui du CDN, et testez avec un paramètre inutile (?test=1).
• Les extensions : désactivez-les en renommant wp-content/plugins en plugins.off par SFTP, puis réactivez-les une à une.
• Les redirections : si vous avez changé de structure de permaliens, les anciennes adresses ne mènent plus nulle part ; la méthode est détaillée dans rediriger une ancienne structure de permaliens.

Si le site boucle plutôt que d’afficher une 404, consultez la fiche trop de redirections.

Prévenir l’erreur

• Après toute migration, vérifiez que le .htaccess a été copié (les fichiers commençant par un point sont souvent oubliés) ou que la configuration nginx contient try_files.
• Réenregistrez les permaliens après l’activation ou la mise à jour d’une extension qui ajoute des types de contenu.
• Changez la structure des permaliens le plus rarement possible, et prévoyez des redirections 301 si vous le faites.
• Ne déclenchez jamais flush_rewrite_rules() à chaque requête : l’opération est coûteuse.
• Surveillez les erreurs 404 dans la Search Console pour détecter une rupture rapidement.