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

> Pages ou articles WordPress en 404 alors qu’ils existent ? Réparez les permaliens : réenregistrement, .htaccess, mod_rewrite, nginx try_files, WP-CLI.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/erreur-404-permaliens/

> Vos pages existent mais renvoient une 404 : les règles de réécriture sont perdues ou inactives. Enregistrez à nouveau Réglages > Permaliens ; si cela ne suffit pas, vérifiez .htaccess et mod_rewrite (Apache) ou try_files (nginx).

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](https://www.wpmoderne.fr/erreurs-wordpress/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](https://www.wpmoderne.fr/hebergement/apache-ou-nginx-wordpress-comparatif-migration/) 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](https://www.wpmoderne.fr/tips/rediriger-ancienne-structure-permaliens-vers-nouvelle/).

Si le site boucle plutôt que d’afficher une 404, consultez la fiche [trop de redirections](https://www.wpmoderne.fr/erreurs-wordpress/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.