Erreur 404 WordPress : ce que signale vraiment ce message
Une erreur 404 sur WordPress indique que le serveur n’a trouvé aucune ressource à l’adresse demandée. Sur un site classique, ce message reste rare et ponctuel. Sur WordPress, il prend une forme particulière : le contenu existe presque toujours encore dans la base de données, mais la règle de réécriture qui doit faire correspondre l’URL à cet article ou cette page a disparu ou a changé.
C’est la différence à retenir avant de commencer un diagnostic. Une erreur 404 « classique » (lien externe cassé, faute de frappe dans une URL) ne se corrige pas de la même façon qu’une 404 massive touchant tout un site après une migration ou un changement de structure de permaliens — dans ce second cas, WordPress lui-même a perdu la carte entre ses URL et son contenu, et la correction se joue côté configuration, pas côté contenu.
Les deux familles de 404 à distinguer
404 isolée : un seul article ou une seule page renvoie l’erreur, le reste du site fonctionne. Cause la plus fréquente : l’URL a changé (renommage de slug, suppression du contenu, faute de frappe dans un lien interne) sans redirection mise en place.
404 généralisée : tout le site, ou une section entière (articles, pages, catégories), renvoie 404 alors que le contenu est visible dans l’administration WordPress. Cause la plus fréquente : la structure des permaliens s’est corrompue, ou le fichier .htaccess qui contient les règles de réécriture a été écrasé, mal restauré ou n’est pas pris en compte par le serveur.
Le premier cas se corrige article par article. Le second demande de reconstruire la mécanique de routage de WordPress — c’est ce cas qui pose problème en urgence, et sur lequel porte l’essentiel de cet article.
Régénérer les permaliens : la première chose à tester
Sur une 404 généralisée, la commande la plus efficace ne touche à aucun fichier : dans l’administration, Réglages > Permaliens, sans rien modifier, cliquer sur « Enregistrer les modifications ». Cette action force WordPress à réécrire ses règles de réécriture internes et, si le serveur le permet, à régénérer le fichier .htaccess.
Dans une bonne partie des cas de 404 généralisée, cette seule manipulation suffit : elle répare une structure de permaliens qui s’est perdue après une mise à jour de WordPress, un changement de thème, ou une intervention manuelle sur les réglages. Si le problème persiste après cette étape, la cause se situe plus probablement dans le fichier .htaccess lui-même ou dans la configuration du serveur.
Le fichier .htaccess corrompu ou absent
WordPress s’appuie sur le module Apache mod_rewrite (ou son équivalent sur les serveurs OpenLiteSpeed et Nginx) pour transformer une URL propre (/mon-article/) en requête compréhensible par PHP. Ces règles vivent dans le fichier .htaccess, à la racine de l’installation.
Trois scénarios provoquent une 404 généralisée par ce biais :
- Le fichier
.htaccessa été supprimé ou écrasé (changement d’hébergeur, restauration de sauvegarde incomplète, plugin de sécurité mal configuré qui l’a remplacé). - Le contenu a été modifié manuellement (ajout d’une règle par un plugin tiers) et une règle mal formée bloque toutes les requêtes suivantes.
- Le module
mod_rewriten’est pas activé côté serveur — dans ce cas, régénérer les permaliens depuis WordPress ne change rien, puisque le serveur ignore les règles qu’il reçoit.
Le bloc .htaccess standard généré par WordPress commence par # BEGIN WordPress et se termine par # END WordPress. Le comparer à un site WordPress fonctionnel de référence (même version) permet de repérer rapidement une ligne manquante ou une règle ajoutée par erreur.
Après une migration : la cause la plus fréquente de 404 en masse
Une migration de site est la circonstance la plus courante pour déclencher une vague de 404 généralisée : changement de nom de domaine, de sous-dossier d’installation, ou de serveur sans reprise à l’identique de la configuration de réécriture. Le contenu est intégralement transféré, mais le fichier .htaccess de l’ancien serveur ne s’applique pas forcément tel quel sur le nouveau, notamment si le passage se fait d’un serveur Apache vers un serveur Nginx ou OpenLiteSpeed, dont la syntaxe de réécriture diffère.
Le guide de migration de site web détaille l’ordre des étapes à respecter pour éviter ce trou d’air ; si une migration est déjà en cours et que les 404 apparaissent après le basculement, la régénération des permaliens décrite plus haut reste le premier réflexe, suivie d’une vérification que le module de réécriture du nouveau serveur est bien actif.
Avant toute modification manuelle du fichier, une sauvegarde de la version existante (même défaillante) évite d’aggraver la situation si l’intervention suivante échoue. Si le site dispose déjà d’un plan de sauvegarde régulier, une restauration ciblée du seul fichier .htaccess — sans toucher au reste du site — est, dans la majorité des cas, plus rapide qu’une reconstruction manuelle des règles de réécriture. La méthode de sauvegarde et de restauration ciblée est détaillée dans le guide de sauvegarde et restauration.
Page 404 personnalisée : une réponse au symptôme, pas à la cause
Beaucoup de thèmes WordPress proposent une page 404 personnalisée (message rassurant, barre de recherche, liens vers la page d’accueil). C’est une bonne pratique pour l’expérience visiteur, mais elle ne corrige rien : une page 404 bien designée qui s’affiche sur un article censé exister masque le problème sans le résoudre. Si l’objectif est de retrouver l’accès au contenu — pas seulement d’améliorer l’apparence de l’erreur — les étapes de régénération des permaliens et de vérification du .htaccess restent la seule voie de correction réelle.
Quand le problème vient de l’hébergeur, pas de WordPress
Si la régénération des permaliens et un fichier .htaccess conforme au standard WordPress ne suffisent pas, la cause se situe probablement dans la configuration du serveur lui-même : module de réécriture désactivé, directive AllowOverride limitée sur Apache, ou configuration Nginx qui ne relaie pas les règles WordPress vers PHP. Cette vérification dépasse ce qu’un accès à l’administration WordPress permet de constater — elle nécessite un accès à la configuration serveur, obtenu via le support de l’hébergeur.
C’est un point de vigilance à intégrer avant de changer d’offre : un hébergement qui ne documente pas clairement son support de mod_rewrite/.htaccess complique ce diagnostic dès qu’un problème de réécriture survient. Le comparatif des hébergeurs WordPress détaille les critères techniques à vérifier avant de choisir une offre sur ce point précis.
Prévenir la prochaine vague de 404
Trois réflexes limitent le risque de revivre une 404 généralisée : conserver une copie du fichier .htaccess fonctionnel en dehors des sauvegardes automatiques (il est parfois exclu par erreur des plans de sauvegarde qui ne ciblent que la base de données), tester la structure des permaliens immédiatement après toute migration ou changement de thème plutôt que d’attendre un signalement utilisateur, et mettre en place des redirections 301 pour toute URL volontairement supprimée ou renommée plutôt que de laisser une 404 s’afficher sur un lien qui existait auparavant.