WordPress erreur 404 : retrouver une page introuvable

Une WordPress erreur 404 signifie que le serveur répond, mais ne trouve pas la ressource demandée à cette adresse. Pour la corriger, vérifiez d’abord l’URL exacte, régénérez les permaliens dans Réglages puis contrôlez la redirection, le slug et les règles de réécriture. La plupart des 404 WordPress se réparent sans réinstaller le site et sans modifier le thème.

Le bon diagnostic dépend de ce qui est introuvable. Une ancienne page supprimée, un article déplacé, une image cassée, une route REST ou une URL d’administration ne se traitent pas de la même façon. Ce guide vous donne une méthode sûre, avec des tests reproductibles et des correctifs réversibles.

Que veut dire une erreur 404 dans WordPress ?

Le code HTTP 404 signifie que le serveur n’a pas trouvé la représentation correspondant à l’URL reçue. Le domaine peut être joignable, le serveur peut fonctionner et la page peut malgré tout être absente. Une 404 n’est donc pas une panne globale. Elle indique généralement une adresse incorrecte, une ressource supprimée ou une règle de réécriture qui ne transmet plus correctement la demande à WordPress.

Dans un site WordPress, le serveur web reçoit souvent une URL puis la transmet à index.php. WordPress cherche alors un article, une page, une catégorie ou une archive correspondant au chemin. Si les permaliens ne sont plus synchronisés avec les règles du serveur, une page existante peut apparaître comme introuvable. À l’inverse, une vraie ressource supprimée doit recevoir une redirection 301 ou rester en 404 selon son remplacement.

Commencez par noter l’URL complète, le statut observé, la page depuis laquelle vous êtes arrivé et la date d’apparition. Une seule URL en 404 n’a pas la même gravité que plusieurs milliers d’URLs après une migration.

Identifier le type de 404 avant de corriger

Testez l’URL dans une fenêtre privée et depuis un second réseau si possible. Regardez si la page 404 est celle du thème WordPress, celle du serveur ou celle d’un CDN. Une page qui reprend le header et le footer du site est souvent générée par WordPress. Une page très différente, avec une signature Apache, Nginx, LiteSpeed ou CDN, indique plutôt une couche située avant le CMS.

curl -sS -D /tmp/headers.txt -o /tmp/body.html 
  -L --max-redirs 5 'https://exemple.fr/ancienne-page/'

grep -iE 'HTTP/|location:|server:|content-type:' /tmp/headers.txt
head -c 300 /tmp/body.html

Le paramètre -L suit les redirections. Retirez-le pour connaître le premier statut renvoyé. Une chaîne de redirections, une redirection vers une mauvaise adresse ou une boucle doit être corrigée avant de conclure à une simple page absente.

Contrôlez également la casse. Sur de nombreux hébergements, /Guide-WordPress/ et /guide-wordpress/ ne désignent pas le même chemin. Les espaces encodés, les caractères accentués et les slashs finaux peuvent aussi révéler une URL construite incorrectement par un plugin ou un lien ancien.

Régénérer les permaliens sans modifier les fichiers

La première réparation WordPress est la plus simple. Dans l’administration, ouvrez Réglages, Permaliens, vérifiez le format souhaité puis cliquez sur Enregistrer les modifications. Même sans changer l’option, cette action reconstruit les règles de réécriture utilisées par WordPress. Testez ensuite une page, un article et une archive.

Cette opération ne supprime normalement ni contenu ni réglage de plugin. Faites-la avec un compte administrateur et évitez de modifier simultanément le thème. Si les pages reviennent mais que les fichiers statiques restent en 404, le problème se trouve probablement dans l’URL d’un asset, un cache ou une configuration serveur.

Si vous n’avez plus accès à l’administration, WP-CLI peut régénérer les règles depuis le répertoire du site.

cd /chemin/vers/wordpress
wp rewrite flush

La commande doit être lancée avec l’utilisateur et l’environnement du site. N’ajoutez pas --hard sans sauvegarde et sans connaître les règles présentes. Cette variante peut écrire dans le fichier de configuration du serveur et écraser une règle personnalisée utile.

Vérifier le slug, le statut et la corbeille

Si une seule page renvoie 404, ouvrez son édition et vérifiez son slug. Un changement de titre ne modifie pas toujours le slug de la manière attendue, tandis qu’une migration peut avoir remplacé des caractères ou supprimé un niveau de dossier. Contrôlez aussi que le contenu est publié, qu’il n’est pas privé et qu’il n’est pas programmé pour une date future.

Consultez la corbeille. Une page supprimée peut encore être référencée par le menu, un article ou un moteur de recherche. Si un remplacement existe, créez une redirection 301 vers la page la plus proche. Ne redirigez pas toutes les anciennes URLs vers l’accueil, car cette pratique désoriente les visiteurs et ne transmet pas une pertinence claire.

wp post list --post_type=page,post 
  --post_status=publish,private,draft,trash 
  --fields=ID,post_type,post_status,post_name,post_title 
  --format=table

Avec un accès SQL ou WP-CLI, cherchez le slug exact plutôt que le titre affiché. Les accents, les apostrophes et les caractères spéciaux sont normalisés dans le chemin final. Si l’ancien slug n’existe plus et qu’aucune page équivalente ne le remplace, une 404 peut être la réponse correcte jusqu’à la mise en place d’une redirection éditoriale.

Corriger une page déplacée avec une redirection 301

Une redirection 301 convient lorsqu’une URL permanente a changé et qu’une destination pertinente existe. Elle doit être directe, unique et stable. Avant de l’ajouter, vérifiez que la nouvelle URL renvoie bien 200 et qu’elle ne redirige pas à son tour.

Redirect 301 /ancien-guide/ https://exemple.fr/nouveau-guide/

Cette syntaxe Apache se place dans le contexte approprié, souvent avant les règles WordPress du fichier .htaccess. Sur Nginx, elle se configure dans le bloc du serveur. Sur un hébergement géré, utilisez le module de redirections fourni ou demandez la syntaxe à l’hébergeur. N’insérez pas une règle Apache dans une configuration Nginx.

Pour une règle conditionnelle dans WordPress, préférez un outil de redirection maîtrisé ou une configuration documentée. Une règle trop large peut capturer les pages valides. Testez l’ancienne URL avec curl -I, vérifiez le statut 301 puis la destination finale.

curl -sS -I 'https://exemple.fr/ancien-guide/'
# Attendu : HTTP/2 301 puis un en-tête Location cohérent

Réparer les 404 après une migration ou un changement de domaine

Après une migration, comparez les structures d’URL de l’ancien et du nouveau site. Les causes fréquentes sont un préfixe de catégorie différent, une date retirée du permalink, une installation placée dans un sous-répertoire ou un protocole HTTPS mal déclaré. Vérifiez dans Réglages, Général l’URL WordPress et l’URL du site, sans les modifier à l’aveugle sur un site en production.

Recherchez aussi les anciennes URLs dans la base, les menus, les widgets et les champs personnalisés. Un remplacement global doit être effectué avec un outil qui comprend les données sérialisées. Une simple commande SQL sur des valeurs sérialisées peut endommager des réglages et créer d’autres erreurs.

wp search-replace 'http://ancien-exemple.fr' 'https://exemple.fr' 
  --all-tables-with-prefix --dry-run

Le mode simulation permet d’estimer les changements. Faites une sauvegarde vérifiée avant une exécution réelle. Une migration réussie se contrôle par échantillon, mais aussi par une liste des URLs historiques. Les pages prioritaires, les fichiers robots, le sitemap et les redirections méritent un contrôle séparé.

Traiter les 404 des images, CSS et JavaScript

Une page peut être accessible tout en affichant des images manquantes ou un style incomplet. Dans les outils de développement, filtrez l’onglet Réseau sur les statuts 404. Notez le chemin demandé et comparez-le au fichier réellement présent dans la médiathèque ou dans le thème. Un chemin absolu qui conserve l’ancien domaine est fréquent après une migration.

Ne téléversez pas à nouveau toutes les images avant d’avoir identifié la cause. Vérifiez les permissions raisonnables, le protocole HTTPS, la casse du nom de fichier et les règles du CDN. Pour un asset généré par un plugin, videz le cache concerné puis régénérez les fichiers optimisés. Contrôlez enfin les en-têtes et le type MIME, car un fichier présent mais mal servi peut provoquer un affichage cassé différent d’une vraie 404.

Les références relatives sont sensibles à la profondeur de l’URL. Un lien images/logo.svg depuis /guides/wordpress/ ne pointe pas au même endroit qu’un lien commençant par /images/. Corrigez la génération du lien plutôt que de multiplier les copies du fichier.

Comprendre les 404 de la REST API et de wp-admin

Une route /wp-json/ en 404 peut venir des permaliens, d’une réécriture serveur ou d’un plugin qui bloque une route. Testez d’abord la racine de l’API puis la route précise. Une route personnalisée peut aussi avoir été retirée après une mise à jour. Vérifiez la documentation de l’extension et la liste des routes exposées.

curl -sS -i 'https://exemple.fr/wp-json/'
curl -sS -i 'https://exemple.fr/wp-json/wp/v2/types'</nwp route list --format=table

Si seule l’administration affiche 404, vérifiez que l’URL de connexion n’a pas été modifiée par une extension de sécurité, puis désactivez le plugin uniquement par la méthode prévue par l’hébergeur ou WP-CLI. Ne changez pas le nom du dossier d’un plugin en production sans sauvegarde et sans plan de retour.

Une erreur REST 404 n’est pas identique à une erreur d’authentification ou de permission. Pour distinguer les cas, consultez nos guides sur l’erreur REST API 401, l’erreur REST API 403 et l’erreur REST API 404.

Contrôler le cache, le CDN et les règles serveur

Un cache peut conserver une ancienne 404 après la réparation. Purgez d’abord le cache de la page concernée, puis celui du CDN si vous en utilisez un. Testez avec un paramètre de requête temporaire uniquement pour le diagnostic, pas comme solution permanente. Comparez les réponses avec et sans cache et vérifiez l’en-tête qui indique la couche ayant servi la page.

Si les journaux WordPress ne voient pas la demande, examinez les journaux Apache, LiteSpeed, Nginx ou du CDN. Une règle de réécriture trop restrictive, une installation dans un sous-dossier ou une règle de sécurité peuvent répondre avant PHP. Évitez de recopier un .htaccess trouvé sur un autre site. Les extensions, le chemin d’installation et l’hébergeur peuvent rendre cette configuration inadaptée.

Activez le débogage uniquement pour observer le problème et sans afficher les erreurs aux visiteurs. Notre guide sur le mode debug WordPress détaille la configuration du journal. Pour un diagnostic plus large des codes HTTP, consultez aussi notre guide sur WordPress erreur 422.

Vérifier le référencement et la qualité des liens

Une 404 publique n’est pas automatiquement un problème SEO. Elle devient prioritaire lorsqu’elle concerne une page utile, reçoit des liens internes ou externes, figure dans le sitemap ou accumule des impressions. Supprimez du sitemap les URLs réellement supprimées, remplacez les liens internes cassés et redirigez les pages déplacées vers leur équivalent.

Dans Search Console, regroupez les erreurs par modèle d’URL. Une liste de centaines de paramètres, de fichiers temporaires ou d’anciennes variantes ne se traite pas comme cinq pages éditoriales importantes. Vérifiez les corrections après le délai nécessaire à une nouvelle exploration. Ne demandez pas l’indexation de chaque 404 corrigée si une redirection 301 claire suffit.

Utilisez un outil de contrôle local pour repérer les liens cassés avant publication.

python3 - <<'PY'
from urllib.request import Request, urlopen

url = 'https://exemple.fr/guide-wordpress/'
req = Request(url, method='GET', headers={'User-Agent': 'wpadminlab-check/1.0'})
with urlopen(req, timeout=15) as response:
    print(response.status, response.geturl())
PY

Checklist de résolution d’une erreur 404

Commencez par confirmer l’URL et le premier statut. Vérifiez ensuite les permaliens, le slug, le statut de publication, la corbeille et les redirections. Testez une page et un article différents. Contrôlez les liens internes, les assets et le sitemap. Purgez les caches seulement après le correctif. Enfin, consultez les journaux si la 404 est produite avant WordPress.

Conservez une note de la cause, de la règle ajoutée et de l’URL testée. Une 404 corrigée proprement doit donner 200 pour une ressource existante ou 301 vers une destination pertinente. Elle ne doit pas créer une boucle, une chaîne inutile ou une redirection générale vers l’accueil.

FAQ sur WordPress erreur 404

Pourquoi WordPress affiche-t-il 404 pour une page qui existe ?

Les règles de permaliens peuvent être désynchronisées, le slug peut avoir changé ou la page peut être privée. Enregistrez à nouveau les permaliens, puis contrôlez le statut et l’adresse exacte.

Comment corriger une erreur 404 après avoir changé les permaliens ?

Régénérez les permaliens, testez les nouvelles URLs et ajoutez des redirections 301 pour les anciennes adresses qui ont une destination équivalente.

Une 404 est-elle mauvaise pour le référencement ?

Une 404 isolée et justifiée n’est pas forcément problématique. Une page importante cassée, présente dans le sitemap ou reliée depuis d’autres pages doit être corrigée rapidement.

Pourquoi les images WordPress renvoient-elles 404 ?

Le chemin, le domaine, la casse, le CDN ou le fichier généré peuvent être incorrects. Relevez l’URL exacte dans les outils réseau avant de retéléverser les médias.

Que faire si wp-json renvoie 404 ?

Régénérez les permaliens, testez la racine de la REST API, puis vérifiez les règles serveur et les extensions qui modifient ou bloquent les routes.

Sources et références

• MDN, définition officielle du statut HTTP 404
• RFC 9110, statut 404 Not Found
• Documentation WordPress, écran des permaliens
• Documentation officielle WordPress sur les règles de réécriture
• Documentation officielle de la REST API WordPress
• Google Search Central, pages 404 et référencement
• MDN, fonctionnement des redirections HTTP