Beaucoup de 404 : lesquelles corriger et lesquelles laisser mourir

Trier les erreurs 404 par priorité évite de corriger des URL que personne ne visite

À la une

Un rapport de crawl qui affiche 2 000 erreurs 404 ne signifie pas que 2 000 pages réclament une correction. La majorité de ces URL sont mortes depuis des mois, n’ont jamais reçu de lien entrant et ne génèrent aucun clic : les corriger reviendrait à repeindre une pièce que personne ne visite. Seules les 404 qui cassent un parcours utilisateur ou qui gaspillent du budget de crawl méritent une redirection. Toutes les autres peuvent rester en l’état, à condition de renvoyer proprement un code HTTP 404 (ou 410) et une page d’erreur utile.

Sommaire

Trois critères pour trier vos 404 en moins de dix minutes
Les 404 qui méritent une redirection 301 immédiate
Les 404 à laisser mourir sans culpabilité
Redirection, page 410 ou page d’erreur personnalisée : quelle réponse technique
Surveiller les nouvelles 404 avant qu’elles ne s’accumulent
Questions fréquentes sur les erreurs 404

Trois critères pour trier vos 404 en moins de dix minutes

Vu du côté de Google Search Console, toutes les erreurs 404 se valent : elles apparaissent dans le même rapport, sans hiérarchie. C’est au gestionnaire du site de faire le tri. Trois données suffisent pour classer chaque URL.

Premier critère : la page reçoit-elle des liens entrants ? Un backlink actif qui pointe vers une 404 gaspille de l’autorité transmise par le site référent. L’outil d’exploration de liens de la Search Console (ou un crawleur tiers) permet de repérer ces cas. Si un ou plusieurs domaines externes pointent vers l’URL, la redirection 301 vers le contenu le plus proche s’impose.

Deuxième critère : la page génère-t-elle encore du trafic ? Certaines URL restent bookmarkées par des utilisateurs ou indexées dans des annuaires. Si la page enregistre des clics dans les 90 derniers jours, le visiteur tombe sur un mur. Rediriger protège l’expérience utilisateur et conserve le signal de pertinence.

Troisième critère : des liens internes pointent-ils encore vers cette URL ? Un lien interne cassé est un défaut de maintenance, pas un problème de 404. Corriger le lien dans le menu, le footer ou le corps d’un article est plus propre qu’une redirection permanente. Le crawl du site via les logs serveur permet de repérer ces chaînes brisées.

Les 404 qui méritent une redirection 301 immédiate

Une URL qui cumule au moins deux des critères précédents doit être corrigée sans attendre. Voici les cas les plus courants, classés par ordre de priorité.

Situation	Action recommandée	Pourquoi
Ancien article supprimé avec backlinks externes	Redirection 301 vers l’article le plus proche thématiquement	Récupérer le jus de lien et éviter une impasse au visiteur
Changement de slug après refonte	Redirection 301 de l’ancien slug vers le nouveau	L’ancienne URL circule encore dans les résultats, les newsletters et les réseaux sociaux
Page produit retirée du catalogue	Redirection 301 vers la catégorie parente	Le visiteur cherche le produit, la catégorie lui propose des alternatives
Lien interne cassé dans un menu ou un footer	Corriger le lien directement dans le template	Une redirection masquerait un défaut structurel du site

Le point commun de ces situations : quelqu’un clique, ou un robot suit un lien, et tombe sur du vide alors qu’un contenu pertinent existe ailleurs sur le site.

Voir aussi Surveiller la disponibilité de son site : outils et seuils d’alerte

Les 404 à laisser mourir sans culpabilité

Google lui-même le confirme dans sa documentation pour les développeurs : les erreurs 404 sont normales sur le Web. Chaque site en produit, et le moteur de recherche sait les gérer. Il ne pénalise pas un site pour le simple fait d’avoir des pages introuvables, tant que celles-ci renvoient bien un code 404 (et non un faux 200).

Entrent dans cette catégorie :

Les URL inventées par des bots ou des scanneurs de vulnérabilités (/wp-login.php sur un site qui n’utilise pas WordPress, /admin, /.env). Elles polluent les rapports mais ne concernent aucun visiteur réel.
Les URL générées par d’anciens plugins désinstallés, dont aucune page du site ni aucun lien externe ne fait référence.
Les pages supprimées volontairement (contenu obsolète, doublon, page événementielle périmée) qui n’ont jamais attiré de backlinks.
Les variantes d’URL avec paramètres de tracking (?utm_source=...) mal formées par un outil d’emailing.

Créer des redirections pour ces URL revient à alourdir le fichier .htaccess ou la table de redirections du CMS. Sur un site WordPress avec plusieurs centaines de règles de réécriture, les performances du serveur peuvent s’en ressentir. Mieux vaut une 404 propre qu’une redirection inutile.

Redirection, page 410 ou page d’erreur personnalisée : quelle réponse technique

La redirection 301 reste la solution standard quand un contenu équivalent existe sur le site. Elle transfère le signal de classement et guide le visiteur. Mais ce n’est pas la seule option.

Le code 410 (Gone) indique au robot que la ressource a été supprimée définitivement. Contrairement au 404, le 410 accélère la désindexation de l’URL par les moteurs de recherche, selon la spécification HTTP RFC 9110. C’est le bon choix pour un contenu que l’on ne souhaite plus voir apparaître nulle part : fiche produit définitivement retirée, page juridique remplacée par une version entièrement différente.

La page d’erreur personnalisée est complémentaire, pas alternative. Que le serveur renvoie un 404 ou un 410, le visiteur doit voir une page utile : un lien vers l’accueil, un champ de recherche, une liste des rubriques principales. Le pire scénario est la page blanche du serveur par défaut, qui donne l’impression que le site est en panne.

Un cas particulier mérite attention. Si une erreur 500 intermittente est confondue avec une 404, le diagnostic est faussé. Vérifier le code HTTP réel dans les en-têtes de réponse (via l’onglet Réseau du navigateur) évite de rediriger une page qui fonctionne parfois.

Surveiller les nouvelles 404 avant qu’elles ne s’accumulent

Corriger un lot de 404 une fois par an est moins efficace que d’en détecter cinq par semaine. Deux sources de données permettent cette surveillance continue.

La Google Search Console signale les erreurs de couverture dans son rapport d’indexation. Configurer une alerte email (disponible dans les paramètres du compte) permet de recevoir une notification lorsque le nombre de pages en erreur augmente sensiblement. Ce rapport ne couvre toutefois que les URL que Googlebot tente de crawler.

Les logs du serveur capturent toutes les requêtes, y compris celles des visiteurs humains et des autres robots. Filtrer les réponses avec un code 404 dans les logs Apache ou Nginx, une fois par semaine, révèle les URL problématiques que la Search Console ne montre pas. Un outil de surveillance de disponibilité complète le dispositif pour les pages critiques.

Imaginez le rapport tel qu’il arrive sur le bureau du responsable du site chaque lundi matin : une liste de cinq nouvelles 404, classées par nombre de hits. Deux d’entre elles viennent d’un article de blog qui a changé de catégorie lors de la dernière mise à jour. Trois sont des tentatives d’accès à /xmlrpc.php par des bots. Les deux premières se corrigent en deux minutes, les trois autres s’ignorent. Ce tri hebdomadaire empêche l’accumulation.

À retenir

Vérifier les backlinks et le trafic récent avant de corriger une 404 : sans l’un ni l’autre, la correction est inutile.
Préférer la correction du lien interne cassé à la redirection : c’est la source du problème, pas la 404 elle-même.
Utiliser le code 410 pour les contenus supprimés définitivement afin d’accélérer leur désindexation.
Filtrer les logs serveur chaque semaine pour détecter les nouvelles 404 avant qu’elles ne s’empilent.

Questions fréquentes sur les erreurs 404

Questions fréquentes

Que signifie le code d’erreur 404 ?

Le code 404, défini par le protocole HTTP, indique que le serveur fonctionne mais que la ressource demandée n’existe pas à l’adresse sollicitée. L’URL a été supprimée, déplacée sans redirection ou mal saisie. Ce n’est pas une panne du serveur : c’est l’absence d’un contenu précis à une adresse précise.

Comment résoudre le problème « ce site est inaccessible » ?

Le message « ce site est inaccessible » affiché par le navigateur n’est pas une erreur 404. Il signale un problème réseau ou DNS : le navigateur ne parvient pas à joindre le serveur du tout. Vérifier la connexion internet, vider le cache DNS du système (ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache sous macOS) et tester avec un autre réseau permet d’isoler la cause. Si le site est réellement hors ligne, le problème relève de l’hébergeur, pas d’une URL manquante.

Comment dit-on « code not found » en français ?

La traduction littérale est « code non trouvé », mais dans le contexte du Web, l’expression consacrée est « page introuvable » ou « erreur 404 ». L’intitulé technique complet est « 404 Not Found », conservé tel quel dans la plupart des interfaces francophones.

Pourquoi le navigateur affiche-t-il « erreur de serveur » ?

Une « erreur de serveur » correspond généralement à un code HTTP de la famille 500 (500, 502, 503), pas à une 404. Elle indique un dysfonctionnement côté serveur : script PHP en erreur, base de données inaccessible, mémoire insuffisante. La distinction est importante, car une 500 empêche l’affichage de toutes les pages, là où une 404 ne concerne qu’une seule URL. Le diagnostic passe par la lecture des logs d’erreur du serveur.

Damien Roux

Damien Roux est l'hébergement web. de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress