Erreur 404 Not Found : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Une page affiche 404, Not Found ou un message personnalisé indiquant que la page est introuvable, tandis que les autres pages du même site se chargent.
• Une requête d’API renvoie un 404 alors que le nom d’hôte et le serveur sont accessibles.
• Une URL qui fonctionnait auparavant commence à renvoyer un 404 après un déploiement, une migration, une modification des permaliens ou une mise à jour de l’application.
• Les résultats de recherche, les favoris ou les liens internes renvoient vers du contenu qui n’est plus disponible.
• Plusieurs chemins sans rapport échouent après une modification de la configuration du serveur web, du reverse proxy ou des réécritures.

Causes principales, classées par probabilité

Causes probables, de la plus fréquente à la moins fréquente :

1. URL mal saisie ou incomplète : Une erreur d’orthographe, un segment de chemin manquant ou une casse incorrecte pointe vers une ressource qui n’existe pas.
2. Contenu supprimé ou déplacé : La page ou le fichier a été supprimé, renommé ou déplacé sans redirection pertinente.
3. Lien interne ou externe cassé : Un lien pointe toujours vers une URL obsolète, souvent après une migration ou une modification de la structure des URL.
4. Route d’application manquante : L’application déployée ne définit pas la page ou le endpoint d’API demandé, ou le chemin utilise une version ou un préfixe d’API incorrect.
5. Règles de réécriture ou de permaliens incorrectes : Apache, Nginx, un routeur de framework ou la configuration d’un CMS n’envoie pas un chemin valide vers le gestionnaire prévu.
6. Problème de déploiement ou de racine des documents : Un fichier, une route ou la sortie du build n’a pas été déployé, ou le serveur sert un répertoire différent de celui attendu.
7. Incohérence du reverse proxy : Un proxy ou une passerelle envoie la requête vers la mauvaise application ou le mauvais backend, où ce chemin est inconnu.
8. Différence de casse dans le chemin : Une URL qui fonctionne dans un environnement peut échouer sur un système de fichiers ou un serveur sensible à la casse lorsque ses majuscules et minuscules ne correspondent pas à la route ou au nom de fichier.

Comment corriger le problème

Si vous consultez le site

1. Vérifiez à nouveau l’adresse, notamment l’orthographe, la casse, les tirets, les extensions de fichier et chaque segment du chemin.
2. Supprimez le dernier segment de chemin suspect ou naviguez depuis la page d’accueil du site et sa recherche intégrée pour trouver la page actuelle.
3. Si vous avez accédé à la page depuis un favori ou un résultat de recherche, cherchez une version plus récente du contenu au lieu d’actualiser sans cesse la même URL.
4. Signalez tout lien fiable cassé au propriétaire du site en indiquant l’URL exacte et la page où vous l’avez trouvé.

Si vous gérez le site

1. Confirmez la requête en échec. Notez le chemin exact, la méthode HTTP, l’hôte, la chaîne de requête et l’heure de l’échec. Vérifiez si le problème concerne une seule URL, une famille de routes ou l’ensemble du site.
2. Déterminez si la ressource doit exister. Vérifiez l’enregistrement de contenu, les fichiers déployés ou la définition de la route de l’application. Une ressource supprimée volontairement doit normalement rester en 404, sauf si un remplacement réellement pertinent existe.
3. Comparez un chemin en échec et un chemin fonctionnel. Recherchez les différences de casse, de slash final, d’extension de fichier, de préfixe de langue, de version d’API, de préfixe de route et de gestion des paramètres de requête.
4. Examinez la configuration du routage et des réécritures. Vérifiez le routeur de l’application, les permaliens du CMS, les règles du serveur web, la racine des documents et les correspondances du reverse proxy. N’apportez des modifications de configuration qu’avec l’autorisation appropriée, après avoir sauvegardé la configuration actuelle et évalué leurs effets sur les autres routes.
5. Vérifiez le déploiement. Confirmez que le fichier, la sortie du build, la route et les ressources statiques attendus sont inclus dans la version déployée et que le serveur actif utilise bien la version prévue.
6. Consultez les journaux. Utilisez les journaux du serveur web, du proxy et de l’application pour déterminer quel composant a généré le 404 et vérifier si la requête a atteint le backend attendu. Supprimez ou anonymisez les identifiants, jetons et données personnelles avant de partager les journaux.
7. Réparez les liens ou les redirections. Mettez à jour les liens internes pour utiliser le chemin actuel. Si le contenu a été déplacé définitivement, configurez une redirection permanente autorisée vers la destination équivalente la plus proche. Ne redirigez pas les URL manquantes sans rapport vers la page d’accueil.
8. Vérifiez la réponse d’erreur. Demandez l’URL manquante d’origine et confirmez qu’elle renvoie le statut HTTP 404. Une page d’erreur personnalisée peut être utile, mais elle ne doit pas transformer une ressource manquante en réponse 200 réussie et trompeuse.
9. Retestez les chemins concernés. Après la modification, vérifiez l’URL d’origine, l’URL de remplacement si elle existe, des routes fonctionnelles représentatives et les méthodes d’API pertinentes. Surveillez ensuite les journaux des 404 pour repérer les liens encore cassés.

Prévention et vérification du correctif

• Effectuez des vérifications des liens cassés avant et après les migrations, refontes et modifications de la structure des URL.
• Documentez les redirections des contenus importants déplacés définitivement.
• Testez des routes représentatives de pages, de ressources et d’API lors de chaque déploiement.
• Traitez la casse des chemins, les slashs finaux, les préfixes de langue et les versions d’API comme des décisions de routage explicites.
• Soumettez la configuration du serveur web, du reverse proxy et du routage de l’application à un processus de contrôle des changements.
• Surveillez les chemins 404 fréquemment demandés afin d’identifier les liens internes cassés, les intégrations obsolètes et les demandes récurrentes des utilisateurs.
• Conservez des URL stables pour les contenus destinés à rester disponibles ou indexés.
• Veillez à ce que les modèles d’erreur personnalisés conservent le statut HTTP correct.

Questions fréquentes