Le message erreur 404 not found s’affiche quand un navigateur a contacté le serveur, que le serveur a répondu, mais qu’il n’a pas trouvé la ressource demandée à l’URL indiquée. Le serveur tourne normalement. La page, elle, n’existe pas ou plus.
C’est l’un des codes HTTP les plus courants sur le web et l’un des plus mal gérés. Pas parce que la correction est complexe, mais parce que la plupart des guides s’arrêtent à « faites une redirection 301 ». Ce guide va plus loin : il couvre les types d’erreurs 404, leur impact réel sur le SEO selon le contexte, les méthodes de détection et leurs angles morts respectifs, et la correction étape par étape sur WordPress.
Ce que signifie réellement le code HTTP 404 Not Found
Le protocole HTTP définit des classes de codes de réponse. La classe 4xx regroupe les erreurs côté client : le serveur a bien reçu la requête, mais quelque chose dans la demande pose problème. Le code 404 signifie spécifiquement que la ressource demandée n’existe pas à cette URL, et que le serveur ne sait pas où elle se trouve.
Ce n’est pas la même chose qu’un code 500 (erreur serveur) ni qu’un code 503 (service temporairement indisponible). Le 404 est une réponse définitive : « cette page n’est pas ici ».
Les causes concrètes sont au nombre de quatre. Une URL modifiée sans redirection mise en place. Une page supprimée dont l’ancienne URL est encore référencée dans des liens internes, des backlinks externes ou des signets d’utilisateurs. Une faute de frappe dans un lien hypertexte. Une migration de site où des URLs ont changé de structure sans que les redirections aient été configurées. Si vous gérez un site WordPress avec un hébergement infogéré, la surveillance des erreurs peut être intégrée à un contrat de maintenance.
Hard 404 et soft 404 : une distinction que Google fait mais que beaucoup ignorent
Un hard 404 est une erreur 404 propre : le serveur retourne effectivement le code HTTP 404 en réponse à la requête. C’est le comportement correct quand une page n’existe pas.
Un soft 404 est plus insidieux. La page retourne un code HTTP 200 (succès) tout en affichant un message du type « page introuvable » ou « aucun résultat ». Le serveur dit que tout va bien, mais le contenu est vide ou inexistant. Google détecte cette incohérence et la traite comme une erreur, mais elle n’apparaît pas dans les rapports de couverture de la Search Console de la même façon qu’un hard 404.
Les soft 404 apparaissent fréquemment dans trois situations. Les pages de résultats de recherche interne qui retournent une page vide sans erreur serveur. Les pages produit d’e-commerce qui affichent « article épuisé » sans retourner de code d’erreur. Les pages générées dynamiquement avec des paramètres d’URL invalides qui produisent une page vide.
Le problème des soft 404 : ils gaspillent du budget crawl (voir section suivante) sans que le problème soit immédiatement visible. Les corriger nécessite soit de retourner un vrai code 404, soit de rediriger en 301 vers une page pertinente, soit de produire un contenu réel sur la page.
L’impact réel des erreurs 404 sur le SEO
L’impact des 404 sur le SEO est souvent mal évalué. Voici la réalité selon le contexte.
Une 404 sur une URL jamais indexée n’a aucun impact SEO. Si personne n’a jamais lié cette URL et qu’elle n’est pas dans votre sitemap, Google ne la connaît pas et ne perdra pas de temps à l’explorer.
Une 404 sur une URL qui reçoit des backlinks est un problème direct. Les backlinks transmettent de l’autorité SEO. Quand ils pointent vers une URL en 404, cette autorité est perdue. La correction par redirection 301 récupère une partie de cette autorité vers la nouvelle URL.
Un grand nombre de 404 internes affecte le budget crawl. Google alloue à chaque site un quota de pages crawlées par session, appelé crawl budget. Un site qui génère des centaines ou des milliers de 404 internes force Googlebot à consommer ce budget sur des pages inexistantes plutôt que sur du contenu utile. Sur les petits sites (moins de quelques centaines de pages), l’impact est négligeable. Sur les gros sites ou les e-commerces avec de nombreuses pages produit, c’est un facteur à prendre sérieusement en compte.
Les soft 404 sur des pages anciennement bien classées sont les plus dommageables. Si une page avait accumulé des signaux positifs (backlinks, engagement, historique de positionnement) et retourne désormais une soft 404, Google va progressivement dégrader son positionnement sans que l’erreur soit clairement identifiée dans les outils.
404 ou 410 : quand utiliser lequel
Le code 410 (Gone) indique qu’une ressource a été définitivement supprimée et ne reviendra pas. Contrairement au 404 qui laisse entendre que la ressource pourrait réapparaître, le 410 est un signal explicite de suppression permanente.
En pratique, Google traite actuellement les codes 404 et 410 de façon identique pour la désindexation. Les deux signalent à Googlebot que la page doit être retirée de l’index. La différence est sémantique : le 410 accélère légèrement la désindexation car le signal est plus clair.
Utiliser un 410 est pertinent quand vous supprimez délibérément du contenu de façon permanente et que vous voulez que Google le désindexe rapidement : pages produits retirés définitivement, contenu obsolète supprimé, pages dupliquées consolidées. Dans tous les autres cas, un 404 standard est suffisant.
Les trois méthodes de détection et leurs angles morts
C’est le point que la plupart des guides traitent trop rapidement. Il n’existe pas une seule méthode qui détecte tous les types d’erreurs 404. Chaque outil SEO a un angle mort.
Google Search Console
La Search Console remonte les URLs en 404 que Googlebot a tenté de crawler. Elle identifie bien les 404 qui ont des backlinks externes ou qui sont présentes dans votre sitemap.
Son angle mort : elle ne remonte que les URLs que Google connaît. Une URL en 404 liée uniquement depuis des pages internes de votre site peut passer sous le radar si Google n’a pas encore crawlé ces pages ou si elles sont peu liées. De plus, l’export est limité à 1 000 lignes : sur les gros sites, vous n’avez pas l’exhaustivité.
Comment l’utiliser : dans la Search Console, aller dans « Indexation » puis « Pages », filtrer sur « Introuvable (404) » et « Soft 404 » séparément. Exporter la liste et trier par nombre d’impressions pour prioriser. La documentation officielle de Google sur les pages introuvables détaille la procédure de validation après correction.
Screaming Frog
Screaming Frog crawle votre site comme le ferait un moteur de recherche : il suit tous les liens internes et identifie les URLs qui retournent un code 404. C’est l’outil le plus complet pour détecter les 404 liées depuis votre propre site.
Son angle mort : il ne voit que les liens qui partent de votre site. Les backlinks externes qui pointent vers des 404 ne sont pas détectés, sauf si vous connectez Screaming Frog à votre compte Search Console ou Ahrefs.
Gratuit jusqu’à 500 URLs. Au-delà, licence payante. Indispensable pour tout audit sérieux.
Ahrefs ou Semrush
Ces outils identifient les URLs de votre site qui reçoivent des backlinks externes et retournent une 404. C’est la méthode pour récupérer de l’autorité perdue : une URL en 404 qui a des backlinks est une opportunité directe de redirection.
Son angle mort : ils ne voient que les liens externes dans leur index. Les 404 générées par des liens internes ne sont pas détectées. Et leur index n’est jamais exhaustif à 100 %.
Les logs serveur
Les logs serveur enregistrent toutes les requêtes reçues par le serveur, y compris les requêtes de Googlebot, des bots tiers, et des utilisateurs réels. C’est la seule source vraiment exhaustive.
Son angle mort : l’analyse nécessite des compétences techniques ou un outil dédié (Screaming Frog Log File Analyser, AWStats, GoAccess). Les hébergements mutualisés ne donnent pas toujours accès aux logs facilement.
En pratique, combiner Search Console + Screaming Frog couvre 90 % des cas pour un site de taille standard. Ajouter Ahrefs si des backlinks sont en jeu. Les logs sont réservés aux gros sites avec des problèmes de budget crawl identifiés.
Corriger une erreur 404 Not Found sur WordPress : les étapes dans l’ordre
Étape 1 : vérifier les réglages des permaliens
Un nombre soudain et massif d’erreurs 404 sur l’ensemble d’un site WordPress est souvent causé par un problème de permaliens. Avant toute autre action, aller dans Réglages > Permaliens dans l’admin WordPress et cliquer sur « Enregistrer les modifications » sans rien changer. Cette action régénère le fichier .htaccess et résout la majorité des problèmes de permalink cassés.
Cas particulier : un plugin ou un thème qui génère des 404
Si les erreurs persistent après la régénération des permaliens, un plugin ou le thème actif est probablement en cause. C’est la deuxième cause la plus fréquente sur WordPress, en particulier après une mise à jour récente.
La méthode de diagnostic : désactivez vos plugins un par un, en commençant par les plus récemment installés ou mis à jour. Après chaque désactivation, testez l’URL problématique. Si le 404 disparaît, le dernier plugin désactivé est en cause. Si aucun plugin n’est responsable, activez temporairement un thème WordPress par défaut (Twenty Twenty-Four ou Twenty Twenty-Five) et recommencez le test. Un thème mal configuré peut générer des conflits de réécriture d’URL qui produisent des 404 sans que les permaliens soient en cause.
Étape 2 : mettre en place les redirections 301
La redirection 301 est la correction standard pour un slug qui a changé ou pour une page supprimée qui a un équivalent. Elle indique aux navigateurs et aux moteurs de recherche que la ressource a été déplacée de façon permanente vers une nouvelle URL.
Le plugin Redirection (Jon Cameron) est la solution recommandée sur WordPress. Il permet de créer des redirections sans toucher au fichier .htaccess, de suivre les erreurs 404 automatiquement, et d’importer des listes de redirections en masse via CSV.
Pour configurer une redirection dans le plugin : Outils > Redirection, onglet « Ajouter une redirection », renseigner l’URL source (l’ancienne URL en 404) et l’URL cible (la nouvelle URL), type 301.
Quelques règles à respecter sur les redirections. Rediriger vers une page au contenu proche de l’original, pas vers la page d’accueil par défaut sauf si aucune page pertinente n’existe. Éviter les chaînes de redirections (A redirige vers B qui redirige vers C) : chaque étape supplémentaire ralentit la transmission d’autorité. Vérifier régulièrement que les URLs cibles existent toujours.
Étape 3 : corriger les liens internes cassés
Une fois les redirections en place, identifier et corriger les liens internes qui pointaient vers les anciennes URLs. Avec Screaming Frog, filtrer sur « Response Codes > 3xx Redirection » pour voir toutes les URLs qui font l’objet d’une redirection depuis vos pages internes. Idéalement, mettre à jour ces liens pour pointer directement vers la nouvelle URL plutôt que de laisser la redirection faire le travail.
Étape 4 : modifier le .htaccess en dernier recours
Le fichier .htaccess permet de configurer des redirections directement au niveau du serveur Apache, sans plugin. C’est plus rapide à l’exécution mais plus risqué à manipuler : une erreur de syntaxe peut rendre le site inaccessible.
Format d'une redirection 301 dans le .htaccess :
Redirect 301 /ancienne-url/ https://votresite.com/nouvelle-url/Si vous avez de nombreuses redirections à gérer, le plugin Redirection est plus sûr. Le .htaccess devient pertinent sur des serveurs où les plugins WordPress ne peuvent pas intervenir ou pour des migrations avec plusieurs centaines de redirections à traiter en une seule opération.
La page 404 personnalisée : pourquoi elle compte
Une erreur 404 n’est pas nécessairement une impasse si la page d’erreur est bien conçue. Une page 404 par défaut (texte blanc sur fond blanc, ou message serveur brut) provoque un départ immédiat du visiteur. Une page 404 personnalisée peut récupérer une partie de ce trafic.
Ce qu’une bonne page 404 doit contenir : un message clair qui reconnaît le problème sans jargon technique, un lien vers la page d’accueil, un moteur de recherche interne si le site en dispose, et idéalement des liens vers les sections principales du site ou les contenus les plus consultés.
Ce qu’elle ne doit pas faire : rediriger automatiquement vers la page d’accueil avec un code 200 (c’est une soft 404), afficher un contenu vide, ou ne proposer aucune sortie au visiteur.
Sur WordPress, la page 404 se personnalise via le fichier 404.php dans le répertoire du thème actif. La plupart des thèmes incluent ce fichier. Il suffit de le modifier pour ajouter les éléments souhaités. Les page builders comme Elementor ou Divi proposent des modules dédiés à la conception de pages 404 sans code.
Surveiller les 404 dans le temps
Corriger les erreurs 404 une fois n’est pas suffisant. De nouvelles erreurs apparaissent continuellement : pages supprimées, URLs modifiées, liens externes cassés. Un processus de surveillance régulier est nécessaire.
La Search Console envoie des alertes par email quand une augmentation significative des erreurs de couverture est détectée. Activer ces alertes est la première ligne de défense. Le plugin Redirection propose également des notifications par email dès qu’une nouvelle URL génère un 404 : utile sur les sites qui évoluent fréquemment.
Scheduler un crawl mensuel avec Screaming Frog sur les sites de taille moyenne. Exporter les 404, les comparer au mois précédent, identifier les nouvelles URLs en erreur et les traiter.
Pour les sites e-commerce avec un catalogue de produits qui évolue fréquemment, une vérification hebdomadaire est préférable. Les pages produits supprimées ou archivées sans redirection sont la source la plus fréquente de 404 en production.
Questions fréquentes
Erreur 404 Not Found : toutes vos questions
Pas directement. Google ne pénalise pas un site pour le simple fait d’avoir des pages en 404. En revanche, les conséquences indirectes sont réelles : perte d’autorité sur les URLs qui reçoivent des backlinks, gaspillage de budget crawl sur les gros sites, dégradation de l’expérience utilisateur qui augmente le taux de rebond. L’impact dépend du nombre d’erreurs et de leur nature.
Non. Rediriger vers la page d’accueil est souvent une erreur. Google considère une redirection vers une page sans rapport comme une soft 404 ou une redirection non pertinente. La règle est de rediriger vers la page la plus proche sémantiquement de l’URL d’origine. Si aucune page équivalente n’existe, retourner un vrai code 404 est préférable à une redirection non pertinente.
Variable selon la fréquence de crawl de la page concernée. Pour une page qui était régulièrement crawlée, Google constate généralement le 404 dans les jours ou semaines qui suivent. La désindexation peut prendre quelques semaines supplémentaires. Sur des pages peu crawlées, le délai peut s’étirer sur plusieurs mois.
Commencer par exporter la liste complète des anciennes URLs avant la migration. Après la migration, crawler le nouveau site avec Screaming Frog en mode « List » en chargeant les anciennes URLs pour identifier celles qui retournent 404. Créer les redirections 301 en masse via l’import CSV du plugin Redirection ou via le .htaccess. Vérifier ensuite dans la Search Console que Googlebot a bien détecté les nouvelles URLs.
Le plugin Redirection sur WordPress suffit pour gérer les redirections et suivre les nouvelles 404 en temps réel sur un site de taille standard. Pour un site avec plusieurs centaines de pages ou après une migration importante, Screaming Frog est indispensable pour une détection exhaustive des liens internes cassés. Les deux sont complémentaires, pas alternatifs.
Désactivez vos plugins un par un, en commençant par les plus récemment installés ou mis à jour, et testez l’URL problématique après chaque désactivation. Si les erreurs disparaissent, le dernier plugin désactivé est en cause. Si aucun plugin n’est responsable, activez temporairement un thème WordPress par défaut (Twenty Twenty-Four ou Twenty Twenty-Five) et recommencez le test. Le plugin Redirection peut aussi vous aider : il logge toutes les URL qui génèrent un 404 en temps réel, ce qui facilite l’identification de la source.
