WordPress 404 sur les articles : réparer les permaliens sans casser le SEO

Playbook de diagnostic rapide

Si vous n’avez que 15 minutes avant que quelqu’un « remette juste les permaliens » par panique, faites ceci dans l’ordre. Vous cherchez le chemin le plus court vers la certitude.

Premièrement : confirmez quel type de 404 vous avez

• 404 serveur (Nginx/Apache) : WordPress n’a pas été exécuté. Corrigez le routage serveur.
• 404 WordPress (page 404 du thème) : PHP a tourné, WordPress n’a pas pu résoudre la requête en un article. Corrigez les règles de réécriture, la structure des permaliens, les variables de requête ou les slugs en base.
• 404 mise en cache par le CDN/WAF : L’origine peut être corrigée mais les utilisateurs voient encore la 404. Purgez les caches et ajustez les règles de mise en cache.

Deuxièmement : testez une URL d’article connue de bout en bout

Choisissez un article qui existe définitivement dans la base. Ne testez pas des URL « peut-être ». Testez la réalité.

Troisièmement : vérifiez la plomberie de réécriture, puis videz les règles une fois (pas 37 fois)

Si vous êtes sur Apache, vérifiez mod_rewrite et les permissions sur .htaccess. Si vous êtes sur Nginx, vérifiez la section try_files. Ensuite, videz les règles de réécriture de façon contrôlée.

Quatrièmement : si le site a été déplacé ou si les permaliens ont changé, concevez les redirections avant de toucher à quoi que ce soit

Ne « corrigez » pas des 404 en changeant la structure des permaliens à l’aveugle. C’est comme transformer un problème de routage circonscrit en un événement de réindexation SEO.

Ce que signifie réellement une 404 d’article WordPress

« 404 d’article » est un terme qui masque trois échecs différents :

1. Le serveur web ne peut pas mapper l’URL vers WordPress (les permaliens propres nécessitent des règles de réécriture). C’est généralement la configuration Nginx/Apache ou un .htaccess manquant.
2. WordPress reçoit la requête mais ne peut pas la résoudre (règles de réécriture obsolètes, structure de permaliens erronée, balises de réécriture manquantes, conflit de plugin, siteurl/home mal configurés, préfixes de langue incorrects, etc.).
3. WordPress la résout, mais quelque chose d’autre intercepte (boucles de redirection, redirections canoniques vers des URL mortes, couches de cache servant des réponses périmées, WAF bloquant, ou un proxy envoyant les requêtes vers le mauvais backend).

Le correctif dépend de l’endroit où se situe le problème. L’erreur est de traiter toutes les 404 comme un simple « vider les permaliens ». Parfois, le vidage fonctionne parce qu’il régénère les règles. Parfois, cela ne change rien parce que le serveur ne transmet jamais la requête à WordPress. Parfois, ça empire parce que cela masque un décalage sous-jacent entre d’anciennes et nouvelles structures d’URL.

Une citation à garder en tête pendant le débogage : L’espoir n’est pas une stratégie. — Vince Lombardi

Ce n’est pas une citation d’ingénieur fiabilité, mais l’esprit SRE la reconnaît immédiatement : mesurer, vérifier, puis changer.

Blague #1 : Vider les permaliens, c’est comme redémarrer une imprimante : ça marche assez souvent pour devenir une superstition, mais pas assez pour être un plan.

Faits intéressants et contexte historique (parce que ce problème a une histoire)

• Les permaliens « propres » n’ont pas toujours été la valeur par défaut. Les premiers moteurs de blogs utilisaient souvent des URL avec query-string comme ?p=123. Les URL propres nécessitaient le support de réécriture côté serveur.
• WordPress compte sur le serveur web pour « mentir » pour lui. Avec les permaliens activés, votre serveur web fait comme si un fichier n’existait pas et route les requêtes vers index.php, où WordPress résout l’article.
• Le .htaccess d’Apache a rendu l’hébergement mutualisé bon marché — et fragile. WordPress est devenu omniprésent en partie parce que vous pouviez contrôler les réécritures sans accès root. Cette flexibilité a aussi facilité les ruptures à cause des permissions ou des modules manquants.
• Nginx n’a jamais supporté .htaccess par principe. Ce choix est plus rapide et plus sûr, mais signifie qu’une migration d’Apache vers Nginx révèle souvent immédiatement des problèmes de permaliens.
• La gestion des 404 par Google a évolué. Les moteurs de recherche sont meilleurs pour éliminer rapidement les URL mortes et considèrent les chaînes de redirections interminables comme de faible qualité. Cela augmente le coût des changements d’URL négligents.
• 301 vs 302 est devenu une préoccupation SEO pratique. Les redirections « permanentes » (301) transmettent généralement mieux les signaux que les temporaires (302), bien que les moteurs modernes interprètent l’intention. Toujours : utilisez 301 pour du contenu déplacé.
• Le système de réécriture WordPress est basé sur la base de données. Les règles de réécriture sont générées et stockées ; elles peuvent devenir obsolètes si un plugin modifie les routes puis est supprimé.
• Les URL canoniques comptent. WordPress essaiera de rediriger des URL « presque correctes » vers les canoniques ; si votre logique canonique pointe vers un chemin inexistant, vous pouvez créer des boucles 404 auto-infligées.
• Les CDN ont normalisé la mise en cache des réponses négatives. Mettre en cache une 404 peut être utile, mais quand la 404 est accidentelle, vous avez distribué votre bug globalement.

Tâches pratiques : commandes, sorties, ce qu’elles signifient et quoi faire ensuite

Ces tâches sont écrites comme un runbook d’astreinte : vous exécutez une commande, vous interprétez la sortie, vous prenez une décision. Utilisez-les dans l’ordre, ou allez directement à la section correspondant à votre stack.

Tâche 1 : Vérifier si la 404 vient de l’origine ou d’un CDN

cr0x@server:~$ curl -sI https://example.com/2025/hello-world/ | sed -n '1,12p'
HTTP/2 404
date: Fri, 26 Dec 2025 10:22:11 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-cache: HIT
cf-cache-status: HIT

Ce que ça signifie : Vous voyez une 404 probablement mise en cache (HIT). Si vous corrigez l’origine sans purger, les utilisateurs verront toujours l’erreur.

Décision : Purgez le cache CDN pour une URL représentative une fois que vous avez vérifié que l’origine est correcte. Si vous ne pouvez pas purger, définissez temporairement un TTL court pour les 404.

Tâche 2 : Confirmer si WordPress a exécuté (404 WordPress vs 404 serveur)

cr0x@server:~$ curl -s https://example.com/2025/hello-world/ | grep -iE 'wp-content|wp-includes|rel="shortlink"|wp-json' | head
<link rel='shortlink' href='https://example.com/?p=123' />
<script src='https://example.com/wp-includes/js/jquery/jquery.min.js' id='jquery-core-js'></script>

Ce que ça signifie : WordPress a généré la page (même si c’est un template 404). Cela pointe vers les règles de réécriture, un décalage de permalien, un post manquant ou des redirections canoniques — pas le routage de fichiers statiques.

Décision : Passez à l’inspection des règles de réécriture et aux contrôles au niveau WordPress.

Tâche 3 : Valider que l’article existe via WP-CLI

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp post list --post_type=post --name=hello-world --fields=ID,post_title,post_status,post_name --format=table
+-----+-------------+------------+------------+
| ID  | post_title  | post_status| post_name  |
+-----+-------------+------------+------------+
| 123 | Hello World | publish    | hello-world|
+-----+-------------+------------+------------+

Ce que ça signifie : L’article existe et est publié. La 404 est liée au routage, pas à une suppression de contenu.

Décision : Concentrez-vous sur les permaliens/réécriture/canonicalisation et la configuration serveur.

Tâche 4 : Vérifier la structure des permaliens actuelle dans WordPress

cr0x@server:~$ wp option get permalink_structure
/%year%/%postname%/

Ce que ça signifie : WordPress attend des URL comme /2025/hello-world/.

Décision : Si vos URL en production sont différentes (par ex. /blog/hello-world/), ne devinez pas — restaurez la structure ou mettez en place des redirections propres.

Tâche 5 : Inspecter la taille des règles de réécriture et si elles semblent peuplées

cr0x@server:~$ wp rewrite list --format=table | head -n 12
+-------------------------------+------------------------------------------+----------------+
| match                         | query                                    | source         |
+-------------------------------+------------------------------------------+----------------+
| ^wp-json/?$                   | index.php?rest_route=/                   | rest-api       |
| ^wp-json/(.*)?                | index.php?rest_route=/$matches[1]        | rest-api       |
| ^([0-9]{4})/([^/]+)/?$        | index.php?year=$matches[1]&name=$matches[2] | post          |
| ^([0-9]{4})/page/([0-9]{1,})/?$ | index.php?year=$matches[1]&paged=$matches[2] | post        |

Ce que ça signifie : Des règles de réécriture existent et incluent des motifs correspondant à votre structure de permaliens.

Décision : Si les règles sont vides ou manquent les motifs attendus, videz les règles de réécriture (tâche suivante) et cherchez un conflit de plugin ou un problème d’écriture.

Tâche 6 : Vider les règles de réécriture en toute sécurité (CLI, une fois)

cr0x@server:~$ wp rewrite flush --hard
Success: Rewrite rules flushed.

Ce que ça signifie : WordPress a régénéré les règles et les a écrites (ou mis à jour son cache interne). Sur Apache, le vidage « hard » tente aussi de mettre à jour .htaccess.

Décision : Retestez une URL qui échouait. Si elle renvoie toujours 404, le problème est probablement le routage serveur (.htaccess ignoré, config Nginx incorrecte) ou une logique de redirection canonique.

Tâche 7 : Sur Apache, confirmer que mod_rewrite est activé

cr0x@server:~$ apachectl -M 2>/dev/null | grep rewrite
 rewrite_module (shared)

Ce que ça signifie : Le module de réécriture est chargé.

Décision : S’il manque, activez-le (selon le paquet) et rechargez Apache ; sans lui, les permaliens propres feront 404.

Tâche 8 : Sur Apache, confirmer que le vhost permet les overrides (pour que .htaccess fonctionne)

cr0x@server:~$ sudo apachectl -S 2>/dev/null | sed -n '1,40p'
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/example.conf:1)
ServerRoot: "/etc/apache2"

cr0x@server:~$ sudo grep -R "AllowOverride" -n /etc/apache2/sites-enabled/example.conf
15:    AllowOverride None

Ce que ça signifie : AllowOverride None désactive .htaccess. WordPress peut régénérer des règles autant qu’il veut et Apache les ignorera.

Décision : Définissez AllowOverride All (ou au moins FileInfo) pour le document root, rechargez Apache et retestez. Ou mieux : déplacez les réécritures dans la configuration du vhost pour la performance et la clarté.

Tâche 9 : Sur Apache, vérifier que .htaccess existe et est lisible

cr0x@server:~$ ls -la /var/www/html/.htaccess
-rw-r--r-- 1 www-data www-data 612 Dec 26 10:10 /var/www/html/.htaccess

Ce que ça signifie : Le fichier existe et les permissions semblent correctes.

Décision : S’il manque ou est possédé par root avec des permissions restrictives, corrigez la propriété/les permissions et re-flushez les règles de réécriture.

Tâche 10 : Sur Nginx, confirmer que vous utilisez une ligne try_files compatible WordPress

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -n "try_files" | head
147:        try_files $uri $uri/ /index.php?$args;

Ce que ça signifie : C’est la ligne canonique de routage WordPress. Si elle manque, les permaliens feront souvent 404 parce que Nginx cherche un fichier qui n’existe pas et renvoie 404.

Décision : Si vous voyez quelque chose comme try_files $uri =404;, corrigez le bloc location et rechargez Nginx.

Tâche 11 : Confirmer que PHP-FPM est joignable (une « 404 » peut être un échec en amont masqué par la gestion d’erreur)

cr0x@server:~$ systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running)

Ce que ça signifie : PHP-FPM est actif ; bon signe.

Décision : S’il est arrêté ou instable, corrigez-le d’abord. Les bugs de routage n’ont pas d’importance si l’application ne peut pas s’exécuter de façon fiable.

Tâche 12 : Vérifier les valeurs « home » et « siteurl » de WordPress après une migration

cr0x@server:~$ wp option get home
https://example.com

cr0x@server:~$ wp option get siteurl
https://example.com

Ce que ça signifie : Ces valeurs contrôlent comment WordPress construit les URL canoniques et les liens internes. Des valeurs erronées peuvent créer des redirections vers des hôtes ou chemins morts, qui apparaissent comme des 404 pour les utilisateurs.

Décision : Si elles pointent vers un ancien domaine, corrigez-les et purgeZ les caches. Ensuite, vérifiez le comportement des redirections canoniques.

Tâche 13 : Identifier si les redirections canoniques interfèrent

cr0x@server:~$ curl -sI https://example.com/2025/hello-world | sed -n '1,12p'
HTTP/2 301
date: Fri, 26 Dec 2025 10:23:01 GMT
location: https://example.com/2025/hello-world/

Ce que ça signifie : WordPress (ou le serveur) normalise le slash final. C’est normal.

Décision : Si l’en-tête Location pointe ailleurs (ancien domaine, mauvais chemin de base comme /blog/), corrigez home/siteurl, la structure des permaliens ou les redirections serveur.

Tâche 14 : Vérifier qu’un article se résout par ID même si les permaliens échouent

cr0x@server:~$ curl -sI "https://example.com/?p=123" | sed -n '1,12p'
HTTP/2 200
date: Fri, 26 Dec 2025 10:23:22 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que ça signifie : WordPress peut servir l’article. Votre contenu est intact. Le routage « propre » est cassé.

Décision : Maintenez le site en ligne en basculant temporairement les permaliens sur « Plain » si nécessaire (court terme), mais vous aurez besoin de redirections et d’un plan soigné pour éviter un dommage SEO. Mieux : corrigez correctement les réécritures.

Tâche 15 : Sur Nginx, repérer une mise en cache « statique seulement » accidentelle qui renvoie 404

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -n "location ~ \\\\.php" -n | head
162:    location ~ \.php$ {

cr0x@server:~$ sudo nginx -T 2>/dev/null | sed -n '150,190p'
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

Ce que ça signifie : Le routage de base est correct. Si votre config avait à la place un bloc location pour / renvoyant 404 pour les chemins inconnus, vous casseriez les permaliens.

Décision : Si les configurations sont complexes (plusieurs blocs location), simplifiez jusqu’à ce que les permaliens fonctionnent, puis réintroduisez les optimisations prudemment.

Tâche 16 : Vérifier les règles de redirection qui mangent accidentellement les URLs d’articles

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -n "return 301\|rewrite " | head -n 20
88:     return 301 https://example.com$request_uri;
205:    rewrite ^/blog/(.*)$ /$1 permanent;

Ce que ça signifie : Vous avez des règles de réécriture/redirection. La réécriture /blog/ peut être correcte — ou elle peut supprimer un préfixe nécessaire et créer des 404 si WordPress est configuré pour l’inclure.

Décision : Validez l’intention des redirections par rapport à la structure réelle des permaliens et aux URL historiques. Ne « nettoyez » pas les règles de réécriture pendant une panne à moins que vous aimiez les surprises.

Tâche 17 : Inspecter le .htaccess généré par WordPress (Apache)

cr0x@server:~$ sed -n '1,120p' /var/www/html/.htaccess
# BEGIN WordPress

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]

# END WordPress

Ce que ça signifie : C’est le bloc standard WordPress. S’il manque ou est mal formé, les permaliens feront 404.

Décision : Restaurez le bloc WordPress (avec précaution, en préservant les autres directives), puis videz les règles de réécriture et retestez.

Tâche 18 : Vérifier les logs serveur pour l’URL en échec

cr0x@server:~$ sudo tail -n 50 /var/log/nginx/access.log
203.0.113.10 - - [26/Dec/2025:10:24:01 +0000] "GET /2025/hello-world/ HTTP/2.0" 404 548 "-" "Mozilla/5.0"

cr0x@server:~$ sudo tail -n 80 /var/log/nginx/error.log
2025/12/26 10:24:01 [error] 12345#12345: *910 open() "/var/www/html/2025/hello-world/index.html" failed (2: No such file or directory), client: 203.0.113.10, server: example.com, request: "GET /2025/hello-world/ HTTP/2.0", host: "example.com"

Ce que ça signifie : Nginx a tenté d’ouvrir un chemin de fichier (statique) et a échoué, ce qui suggère qu’il n’a pas routé vers index.php. C’est une erreur classique de try_files mal configuré ou d’un location en conflit.

Décision : Corrigez le bloc location / de Nginx pour le routage et rechargez.

Causes racines selon la stack : WordPress, Apache, Nginx, CDN

Causes côté WordPress (WordPress s’exécute, mais 404)

• Règles de réécriture obsolètes après des changements de plugin/thème ou des migrations. Correctif : vider les règles via WP-CLI ; confirmer que la structure des permaliens correspond aux URL attendues.
• Incohérence de la structure des permaliens (le site attend /%postname%/ mais les liens sont /%year%/%postname%/). Correctif : restaurer la structure précédente ou implémenter des redirections qui préservent les anciennes URL.
• Valeurs home / siteurl erronées conduisant à des redirections canoniques vers des chemins ou domaines morts. Correctif : corriger les options, puis vérifier le comportement des redirections.
• Types de contenu personnalisés et slugs de réécriture modifiés. Correctif : ré-enregistrer les post types avec des arguments de réécriture cohérents ; vider les règles ; ajouter des redirections pour les anciens slugs.
• Plugins en conflit qui s’accrochent aux réécritures, redirections ou canonicalisation. Correctif : désactiver temporairement le plugin suspect, confirmer le routage, puis ajuster la configuration.
• Multisite / plugins de langue ajoutant des préfixes (/en/) que le serveur ne route pas correctement. Correctif : s’assurer que les réécritures serveur transmettent les chemins préfixés à WordPress.

Causes Apache (les permaliens propres reposent sur la réécriture + overrides)

• mod_rewrite non chargé. Symptôme : tous les permaliens propres font 404, mais ?p=ID fonctionne.
• AllowOverride None empêche .htaccess de s’appliquer. WordPress « écrit » des règles mais Apache les ignore.
• .htaccess manquant ou corrompu. Peut arriver pendant des déploiements, des durcissements de permissions ou des builds de conteneurs.
• DocumentRoot incorrect (vhost pointant vers le mauvais répertoire) de sorte que les requêtes n’atteignent jamais l’installation WordPress qui possède la base.

Causes Nginx (pas de filet de sécurité .htaccess)

• Absence de try_files ... /index.php?$args;. C’est la cause n°1 des « posts 404 » après migration vers Nginx.
• Blocs location trop zélés qui court-circuitent le routage (location / { try_files $uri =404; }), ou des locations regex qui prennent la priorité de façon inattendue.
• Mauvais paramètres fastcgi provoquant des comportements PHP étranges ; se manifeste parfois par « fonctionne pour l’admin, pas pour les articles » selon les routes.

Causes CDN / reverse proxy

• Réponses 404 mises en cache (y compris le caching négatif). Vous corrigez l’origine, mais le monde continue de voir l’ancienne réponse.
• Règles de redirection à la périphérie qui réécrivent les chemins (/blog/ suppression ou ajout) sans que WordPress soit configuré pour correspondre.
• Discordance de terminaison HTTPS où WordPress pense être sur HTTP ; les redirections canoniques rebondissent et peuvent atterrir sur des variantes mortes.

Réparer les permaliens sans casser le SEO

Voici la vérité opérationnelle : la plupart des “corrections de permaliens WordPress” modifient accidentellement les URL. Changer des URL n’est pas intrinsèquement mauvais. Changer des URL sans plan de redirection est une faute professionnelle.

Décidez ce que vous cherchez réellement à faire

Il y a deux objectifs distincts que les gens confondent :

1. Restaurer le routage fonctionnel sans changer les URL publiques. C’est une correction d’incident. Amical pour le SEO.
2. Changer intentionnellement la structure des URL. C’est une migration / tâche de gestion des changements. Nécessite cartographie, redirections et validation.

Si vous voulez simplement que les articles cessent de faire 404, vous voulez probablement l’objectif n°1.

Règle n°1 : restaurer d’abord l’ancienne structure de permaliens

Si les articles font 404 parce que quelqu’un a changé les permaliens, le geste SEO le plus sûr est de revenir à la structure que les moteurs connaissent déjà. Ensuite, vous pourrez planifier toute amélioration d’URL ultérieurement, quand personne ne vous harcèle.

Opérationnellement : cela réduit le rayon d’impact. SEO-wise : cela préserve la continuité des URL indexées, des liens entrants et des métriques historiques d’engagement.

Règle n°2 : quand vous devez changer les URL, implémentez des redirections 301 en un seul saut

Une stratégie de redirection propre ressemble à ceci :

• Ancienne URL → Nouvelle URL (301), exactement un saut.
• Aucune ancienne URL ne doit rediriger vers une URL intermédiaire qui redirige ensuite.
• Aucune redirection ne doit aboutir sur une 404 ou une page soft-404.

Les chaînes de redirection gaspillent le budget de crawl et rendent le dépannage pénible. Elles s’accumulent aussi comme des moutons de poussière : silencieusement, jusqu’à ce que quelqu’un regarde derrière le canapé.

Règle n°3 : gardez l’identité du contenu stable

Les moteurs considèrent une URL comme un « pointeur d’identité de contenu ». Si vous changez les URL, gardez tout le reste stable :

• Même corps de contenu (ne faites pas de mass-edit pendant les changements d’URL).
• Même titre et métadonnées sauf raison valable.
• Balises canoniques pointant vers l’URL finale, pas vers les anciennes.

Règle n°4 : décidez où résident les redirections (et soyez cohérent)

Vous pouvez implémenter des redirections à plusieurs niveaux. Choisissez une couche principale pour éviter duplication et boucles.

• Au niveau du serveur web (Nginx/Apache) : Rapide, fiable, bon pour les motifs simples (par ex. suppression de /index.php/, changements de préfixe).
• Dans WordPress (plugin ou functions.php) : Flexible, mais ajoute une charge applicative et peut échouer si WordPress ne tourne pas.
• Au CDN/edge : Très rapide et global, mais facile à mal configurer à l’échelle. Peut aussi masquer le comportement d’origine.

Mon choix par défaut : redirections basées sur des motifs au niveau du serveur, redirections dépendantes du contenu dans WordPress uniquement quand nécessaire.

Règle n°5 : vérifiez par échantillonnage et via les logs

Ne validez pas une migration d’URL en cliquant trois liens et en déclarant victoire. Vérifiez avec :

• Un ensemble d’URL anciennes échantillon (articles principaux, plus des articles long-tail aléatoires).
• Contrôles de codes de statut (attendez 301 puis 200).
• Logs d’accès : assurez-vous que bots et utilisateurs atterrissent sur des 200, pas en train de rebondir dans des redirections.

Blague #2 : Le SEO est la seule discipline où l’on panique pour un 302 comme s’il s’agissait d’une faille de sécurité.

Erreurs courantes (symptôme → cause racine → correctif)

1) « Seuls les articles font 404, mais les pages fonctionnent »

Symptôme : /about/ fonctionne, /2025/my-post/ fait 404.

Cause racine : La structure des permaliens inclut des segments de date, mais les règles de réécriture ont été générées pour une structure différente ; ou les réécritures serveur sont trop restrictives (par ex. ne correspondant qu’aux slugs de premier niveau).

Correctif : Confirmez permalink_structure ; videz les règles de réécriture ; assurez-vous que Nginx route tous les chemins via index.php lorsque le fichier n’existe pas.

2) « L’admin fonctionne, le front-end des articles fait 404 »

Symptôme : /wp-admin/ fonctionne, la plupart des URLs publiques échouent.

Cause racine : Le serveur est configuré pour permettre les points d’entrée PHP explicites mais pas les chemins « propres » ; try_files manquant ou règles Apache absentes.

Correctif : Corrigez le location / de Nginx ou le support .htaccess d’Apache ; retestez avec ?p=ID pour isoler.

3) « Tout fait 404 après migration d’Apache vers Nginx »

Symptôme : Le site se charge partiellement, mais les URLs propres échouent.

Cause racine : Attente que .htaccess soit pris en charge. Nginx l’ignore.

Correctif : Ajoutez une configuration Nginx compatible WordPress avec try_files $uri $uri/ /index.php?$args; et le bloc PHP correct.

4) « La correction a marché pour moi mais pas pour les utilisateurs »

Symptôme : Vous obtenez 200 ; d’autres obtiennent 404.

Cause racine : CDN mettant en cache une 404 ; divergence entre plusieurs origines ; ou nœuds de cache anciens servant du contenu périmé.

Correctif : Purgez le cache edge pour les chemins affectés ; vérifiez l’origine directement (contournez le CDN si possible) ; assurez-vous que toutes les origines ont une configuration et des règles de réécriture identiques.

5) « Basculer les permaliens sur Plain règle le problème »

Symptôme : /?p=123 fonctionne ; les belles URLs ne fonctionnent pas.

Cause racine : La réécriture ne se produit pas au niveau serveur.

Correctif : Ne laissez pas la solution sur Plain comme un « fix ». Corrigez les réécritures et repassez à la structure propre, avec des redirections si vous avez modifié les URL publiques entre-temps.

6) « Après changement de structure de permaliens, le trafic chute et Search Console s’enflamme »

Symptôme : Beaucoup de rapports 404 pour d’anciennes URL.

Cause racine : La structure d’URL a changé sans redirections ; ou des redirections existent mais forment des chaînes/boucles ; ou les balises canoniques pointent mal.

Correctif : Implémentez une cartographie 301 anciens → nouveaux ; supprimez les chaînes ; confirmez que les balises canoniques et le sitemap reflètent les nouvelles URL ; validez par échantillonnage des logs.

Trois mini-histoires d’entreprise (anonymisées, techniquement réelles)

Histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré un site marketing WordPress depuis une VM legacy sous Apache vers une plateforme managée conteneurisée frontée par Nginx. La checklist de migration incluait export/import de la base, synchronisation des médias et « s’assurer que wp-admin fonctionne ». Ça marchait. L’équipe a déclaré la migration terminée.

Lundi matin : les rapports commerciaux « tous les articles du blog sont cassés ». La page d’accueil se chargeait, les pages de catégorie étaient inconsistantes, et les articles individuels renvoyaient des 404. L’ingénieur d’astreinte a fait le classique : vider les permaliens depuis l’UI admin. Aucun changement. Puis a recommencé. Toujours rien. La panique commence.

L’hypothèse erronée était subtile et commune : ils supposaient que WordPress « possédait » les permaliens. En environnement Apache, WordPress donne l’impression de posséder les permaliens parce qu’il peut écrire .htaccess. En Nginx, WordPress ne possède rien sauf si le serveur est configuré pour acheminer les chemins inconnus vers index.php.

La correction a été une ligne try_files modifiée dans le bon bloc serveur, plus un reload. Les articles ont immédiatement servi des 200. L’action postmortem la plus importante : ajouter un test synthétique pour une URL d’article connue (pas la page d’accueil) dans les portes de déploiement.

Ils n’avaient pas besoin d’héroïsme. Ils avaient besoin d’une meilleure définition de « fonctionne ».

Histoire 2 : L’optimisation qui a mal tourné

Une équipe d’entreprise avait un site WordPress derrière un CDN et une couche proxy inverse. Quelqu’un a remarqué un taux de cache miss élevé et a décidé « d’optimiser » en mettant en cache les réponses 404 à la périphérie avec un TTL long. L’argument semblait rationnel : les 404 proviennent souvent de bots, et les mettre en cache réduit la charge d’origine.

Puis un éditeur a publié une campagne majeure et l’a partagée sur les réseaux. En quelques minutes, la première vague de trafic a frappé une fenêtre brève où les réécritures étaient cassées sur un nœud d’origine (décalage de déploiement). Le CDN a mis en cache la 404 pour cette URL. Pas pour quelques secondes. Pour des heures.

Ils ont corrigé l’origine rapidement, mais l’internet continuait de voir la 404 mise en cache. Les tickets support ont afflué. L’équipe marketing croyait que « la correction n’avait pas marché », parce que, de leur point de vue, elle n’avait pas fonctionné. L’SRE de garde a dû tracer les en-têtes pour réaliser que la 404 était un artefact distribué, pas une réponse actuelle de l’origine.

La leçon : mettre en cache les 404 peut aller, mais seulement avec des TTL courts et une portée maîtrisée. Si vous cachez les négatifs trop agressivement, vous transformez des incidents de routage temporaires en pannes durables.

Ils ont terminé avec une politique nuancée : TTL court pour les 404, pas de cache pour des motifs de contenu connus comme /%year%/%postname%/, et un hook purge-on-publish pour les chemins à forte valeur.

Histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande organisation gérait plusieurs propriétés WordPress et avait été brûlée par des changements de permaliens des années plus tôt. Ils ont donc mis en place une pratique ennuyeuse : chaque déploiement incluait une petite suite de vérifications synthétiques basées sur curl depuis l’extérieur du réseau.

Pas « le site est up ». Des URL spécifiques : un article connu, une page connue, une catégorie connue, et une URL legacy connue censée 301 vers une destination canonique. Les contrôles tournaient à la fois contre le point d’entrée CDN et contre l’origine.

Lors d’une mise à jour de routine, un nouveau template de config Nginx a accidentellement supprimé la ligne try_files WordPress pour un environnement. Le déploiement a réussi, les contrôles de santé sont restés verts (ils ne testaient que /), mais les contrôles synthétiques ont échoué immédiatement sur l’URL d’article connue. Rollback avant que quelqu’un ne s’en aperçoive publiquement.

Pas de drame. Pas de réunion d’urgence. Juste une porte qui a échoué et une correction silencieuse. Voilà à quoi ressemble la « fiabilité » quand elle fonctionne : c’est presque décevant d’ennuyeux.

Listes de contrôle / plan étape par étape

Plan A : Restaurer des permaliens fonctionnels avec un risque SEO minimal (recommandé pour incidents)

1. Identifier un ID d’article connu avec WP-CLI (wp post list). Notez-le.
2. Tester ?p=ID. Si cela renvoie 200, le contenu est correct et les réécritures sont le problème.
3. Vérifier la structure des permaliens (wp option get permalink_structure). Confirmer qu’elle correspond à vos URL historiques.
4. Vider les règles de réécriture une fois (wp rewrite flush --hard).
5. Corriger le routage serveur :
   • Nginx : confirmer try_files $uri $uri/ /index.php?$args;
   • Apache : confirmer mod_rewrite, AllowOverride, et le bloc WordPress dans .htaccess
6. Vérifier un ensemble représentatif d’URL (top 10 des articles, plus 10 articles anciens aléatoires). Utilisez les en-têtes curl, pas seulement des clics de navigateur.
7. Purger les caches CDN pour les chemins affectés une fois que l’origine est correcte.
8. Surveiller les logs pour le taux de 404 et le taux de redirections ; assurer que les bots voient des 200 pour les URL canoniques.

Plan B : Vous avez changé intentionnellement les permaliens (migration / demande de changement)

1. Verrouillez la structure des permaliens cible. Décidez-la une fois. Ne la « peaufinez » pas en cours de migration.
2. Exportez une cartographie d’URL :
   • Anciennes structures d’URL (structure précédente des permaliens)
   • Nouvelles structures d’URL (nouvelle structure des permaliens)
3. Implémentez des redirections 301 :
   • Préférez des règles basées sur des motifs au niveau Nginx/Apache quand possible
   • Utilisez des redirections côté WordPress seulement pour des exceptions
4. Mettre à jour les liens internes si nécessaire (WordPress génère généralement les nouveaux permaliens automatiquement ; surveillez les liens codés en dur dans le contenu).
5. Valider les balises canoniques pointent vers les nouvelles URLs et que les anciennes redirigent vers la même destination canonique.
6. Valider à grande échelle par échantillonnage et logs ; rechercher des chaînes de redirection et des grappes de 404.
7. Conserver les redirections longtemps. « Longtemps » signifie suffisamment pour que les anciens liens et favoris disparaissent. En termes d’entreprise : plus longtemps que souhaité, moins longtemps que pour toujours.

Plan C : Contention temporaire quand vous ne pouvez pas corriger les réécritures immédiatement

1. Basculez sur les permaliens Plain (/?p=ID) uniquement en dernier recours et seulement temporairement.
2. Mettez une note dans les documents d’incident : « Permaliens Plain activés ; risque SEO ; revenir après correction des réécritures. »
3. Implémentez des redirections des anciennes belles URLs vers ?p=ID seulement si vous disposez d’une cartographie fiable (souvent vous ne l’avez pas). Sinon vous allez créer des redirections incorrectes.
4. Corrigez les réécritures correctement, restaurez la structure des permaliens, puis supprimez les rustines temporaires.

FAQ

1) Pourquoi les articles font-ils 404 alors que la page d’accueil se charge ?

La page d’accueil est souvent / qui peut se résoudre même quand les réécritures sont cassées. Les articles reposent sur les réécritures pour router /year/postname/ vers index.php.

2) « Réglages → Permaliens → Enregistrer » est-ce sûr ?

En général, oui — cela vide les règles de réécriture. Mais si votre serveur ignore .htaccess (overrides Apache désactivés) ou si vous êtes sur Nginx, cela ne corrigera pas le routage. Traitez-le comme une étape de diagnostic, pas une solution finale.

3) Quel est le test le plus rapide pour confirmer qu’il s’agit d’un problème de réécriture ?

Demandez /?p=POST_ID. Si cela renvoie 200 mais que la belle URL fait 404, vos réécritures sont cassées.

4) Dois-je basculer sur les permaliens « Plain » pour arrêter la panne ?

Seulement comme mesure de contention temporaire. Cela change les URL publiques et peut créer une situation SEO compliquée à moins de rediriger correctement. Corrigez la plomberie de réécriture à la place.

5) Comment réparer les permaliens sur Nginx ?

Assurez-vous que le location / du site inclut try_files $uri $uri/ /index.php?$args; et que les requêtes PHP sont passées à PHP-FPM. Ensuite rechargez Nginx et retestez.

6) Comment réparer les permaliens sur Apache ?

Assurez-vous que mod_rewrite est activé, que votre vhost autorise les overrides (AllowOverride) et que le bloc de réécriture WordPress existe dans .htaccess. Ensuite videz les règles de réécriture une fois.

7) Les redirections nuisent-elles au SEO ?

Les redirections sont normales. Les URL cassées sont pires. Utilisez des redirections 301 pour des déplacements permanents, évitez les chaînes, et assurez-vous que l’URL finale renvoie 200 avec le contenu attendu.

8) Pourquoi je vois encore des 404 après avoir corrigé la configuration serveur ?

Le plus souvent : le CDN a mis en cache la 404, le cache du navigateur, ou vous avez corrigé une origine mais pas toutes. Vérifiez les en-têtes de réponse pour des hits de cache et comparez le comportement origine vs CDN.

9) Un plugin peut-il causer des 404 d’articles ?

Oui. Les plugins SEO, multilingues, d’adhésion et les plugins de post types personnalisés peuvent enregistrer des règles de réécriture ou des redirections. Désactivez temporairement le plugin suspect, videz les réécritures, et retestez.

10) Comment éviter cela dans les futurs déploiements ?

Ajoutez des vérifications synthétiques pour une URL d’article connue et une redirection legacy connue. Garez les déploiements sur ces contrôles. Gardez la configuration du serveur web sous contrôle de version et traitez les réécritures comme du code applicatif.

Conclusion : prochaines étapes que vous pouvez livrer aujourd’hui

Si les articles WordPress font 404, ne commencez pas par la superstition. Commencez par la classification : 404 serveur vs 404 WordPress vs 404 mise en cache. Ensuite, prouvez que le contenu existe via ?p=ID. À partir de là, corrigez la couche de routage — support de réécriture Apache ou try_files Nginx — et videz les règles de réécriture une fois.

Si les permaliens ont changé intentionnellement ou accidentellement, traitez cela comme une migration d’URL. Restaurez l’ancienne structure si possible. Sinon, implémentez des redirections 301 propres en un seul saut et validez par échantillonnage et logs. Puis purgeZ les caches pour que la correction atteigne réellement les utilisateurs.

Étapes pratiques :

1. Choisissez une URL d’article en panne et exécutez les contrôles d’en-tête (Tâche 1 + Tâche 13).
2. Confirmez que l’article existe et que ?p=ID renvoie 200 (Tâche 3 + Tâche 14).
3. Vérifiez le routage serveur (try_files sur Nginx ou .htaccess/AllowOverride sur Apache).
4. Videz les règles de réécriture une fois, retestez, puis purgeZ le cache CDN.
5. Ajoutez une porte de déploiement : une URL d’article connue doit toujours renvoyer 200.