Une page 404 digne : liens utiles, recherche, humour léger

À quoi sert vraiment une page 404 (et à quoi elle ne sert pas)

Une page 404 est à la fois support client, navigation et télémétrie dans une seule réponse. Traitez-la comme une surface opérationnelle, pas comme de l’art d’erreur décoratif.

Quand quelqu’un atteint une URL manquante, il vous dit l’une des quatre choses suivantes :

• Il a suivi un lien cassé (interne, externe ou cache obsolète).
• Il a tapé quelque chose de proche (erreur humaine, autocomplétion, ou « je jure que ça existait »).
• Un bot probe (crawlers normaux, scanners de sécurité, ou bruit opportuniste).
• Votre routage ou déploiement est incorrect (règles de réécriture mal configurées, assets manquants, déploiement partiel, mauvais comportement CDN).

Le travail du 404 est de trier ces cas rapidement : récupérer l’utilisateur si possible, et vous donner suffisamment de données pour corriger la cause racine. Ce qu’il ne doit pas faire, c’est prétendre que tout va bien. Retourner un 200 avec un message d’erreur est dangereux pour le SEO et le cache, et rend le dépannage plus difficile parce que le « succès » dans les métriques cache les échecs réels.

Il y a aussi un contrat social. Un utilisateur qui arrive sur un 404 est un peu gêné, même si c’est de votre faute. N’amplifiez pas cela avec un ton passif-agressif. Soyez direct, utile et faites avancer la personne.

Faits et historique encore pertinents en 2025

Ce ne sont pas des anecdotes pour l’anecdote. Chaque point explique pourquoi certains choix autour du 404 restent étonnamment importants.

1. HTTP 404 est défini comme « Not Found », ce qui signifie que le serveur n’a pas de représentation actuelle pour la ressource cible. Ce mot « actuelle » compte : il ne prétend pas que la ressource n’a jamais existé, juste qu’elle n’est pas disponible maintenant.
2. 410 Gone est différent. 410 est une déclaration explicite que la ressource est intentionnellement et définitivement supprimée. Les moteurs de recherche retirent généralement les URL en 410 plus vite que celles en 404.
3. Les moteurs ont inventé le terme « soft 404 » pour décrire les pages qui ressemblent à des erreurs mais retournent 200 OK, ou qui redirigent tout vers la page d’accueil. Cela nuit à la qualité d’indexation et à la confiance.
4. Les premiers serveurs web livraient des pages d’erreur nues parce que la bande passante et le CPU étaient chers et les templates dynamiques moins courants. Cet héritage influence encore les paramètres par défaut : beaucoup de stacks envoient toujours du HTML minimal pour les 404 sauf override.
5. Les CDN ont popularisé la gestion d’erreurs au bord. Un 404 peut être mis en cache à la périphérie comme un 200, et cela peut être soit votre meilleur ami (performance) soit votre pire ennemi (pages manquantes obsolètes après un déploiement).
6. Les navigateurs et proxies traitent les 404 différemment des 200. Par exemple, les caches peuvent stocker les 404 avec des heuristiques différentes, et le code client vérifie souvent le statut pour changer de logique.
7. Les scanners de sécurité adorent les surfaces 404. Beaucoup de chaînes d’exploitation commencent par la découverte : requêtes pour des chemins d’admin courants, anciens endpoints de plugins, ou backups mal configurés. Vos en-têtes et le timing de la réponse 404 peuvent fuir des détails de stack si vous êtes négligent.
8. Les SPA ont rendu le routage 404 confus. Les routeurs côté client veulent souvent « servir index.html pour les chemins inconnus », ce qui est correct pour les routes d’application mais incorrect pour un contenu réellement manquant. La distinction importe pour le SEO et la clarté utilisateur.
9. Historiquement, un lien cassé était « le problème de quelqu’un d’autre ». Aujourd’hui, l’analyse et les outils de Search Console rendent cela mesurable, donc ignorer les 404 est un choix—souvent un mauvais choix.

Principes de conception : faire travailler le 404

1) Confirmer ce qui s’est passé, sans drame

Énoncez la vérité en termes simples : « Nous ne trouvons pas cette page. » Puis proposez quelques actions suivantes. Ne blâmez pas l’utilisateur. N’insinuez pas que le site est cassé à moins que ce le soit. Un 404 est souvent une URL manquante unique, pas une panne.

2) Offrir deux ou trois sorties de qualité

Une bonne page 404 est volontairement petite. Vous ne refaites pas la navigation ; vous proposez des échappatoires :

• Accueil (oui, mais n’en faites pas la seule option).
• Recherche (le meilleur outil universel de récupération).
• Tâches principales pour votre produit (tarifs, docs, statut, contact, connexion—choisissez ce que font réellement vos utilisateurs).

Limitez-vous à 5–8 liens. Trop de liens deviennent un haussement d’épaules visuel, et les utilisateurs partent quand même.

3) Préserver le contexte quand c’est possible

Si vous savez d’où vient l’utilisateur, utilisez-le. « Revenir en arrière » n’est pas un lien ; c’est une fonction du navigateur, et les utilisateurs la connaissent. Donnez-leur un vrai lien : « Retourner à la page précédente » (basé sur le referrer), ou affichez « Vous vouliez peut‑être… » avec des suggestions dérivées du chemin manquant.

Une astuce simple qui marche : analyser les segments du chemin URL et proposer un chemin parent plus large s’il existe (par ex. /docs/storage/… → /docs/storage/).

4) Ne pas divulguer les internes

Votre page 404 est vue par tout le monde, y compris des bots qui collectent vos erreurs. Évitez :

• Chaînes de framework/version dans les en-têtes ou le HTML.
• Stack traces, identifiants de debug qui mappent aux systèmes internes, ou messages d’exception bruts.
• Echoing de contenu d’URL non fiable dans la page sans échappement.

5) Rendre la page peu coûteuse à servir

Les 404 sont sujettes à des rafales. Quand quelque chose casse—un lien de blog populaire, un renommage de produit, un endpoint supprimé—votre taux de 404 peut exploser de 10 à 100×. Si votre page 404 dépend d’appels backend lents ou de bundles clients lourds, elle transforme une erreur de contenu en incident de disponibilité.

6) Instrumenter comme un endpoint de production

Vous voulez savoir :

• Quelles URL manquantes sont les plus chaudes.
• Les referrers générant le trafic cassé.
• Les user agents qui indiquent scanners vs humains.
• Si les 404 corrèlent avec des déploiements, changements CDN ou décalages DNS.

Rédaction et humour : un sourcil levé, pas un spectacle comique

Rédigez comme pour une note d’incident : calme, claire et orientée vers les étapes suivantes.

À faire : « Cette page n’est pas disponible. Essayez la recherche ou rendez-vous sur Tarifs. »

À éviter : « Oupsie ! Quelque chose a planté !!! » (Ce n’est pas le cas. Un lien manque.)

L’humour est permis, mais il doit être léger et optionnel—comme un assaisonnement. Si l’utilisateur est bloqué, les blagues donnent l’impression que vous vous moquez de lui. Si l’utilisateur peut récupérer rapidement, un petit sourire est acceptable.

Blague n°1 : La page que vous avez demandée est en pause-café et n’a pas laissé d’adresse de réexpédition.

Remarquez ce que cette blague ne fait pas : elle ne se moque pas de l’utilisateur, elle ne mentionne pas de « erreurs serveur », et n’implique pas que le site est instable. C’est un petit instant humain, puis retour au travail.

Blague n°2 : Nous avons tout fouillé—even under the cache—but this URL still isn’t real.

Deux blagues. C’est suffisant. Si vous avez besoin de plus d’humour que ça, ce dont vous avez réellement besoin, ce sont de meilleures IA, redirections et hygiène de liens.

La boîte de recherche : rapide, sûre et utile

La boîte de recherche est la fonctionnalité la plus rentable sur une page 404. Elle transforme une « impasse » en « poursuivre la tâche ». Mais seulement si elle fonctionne vite et renvoie des résultats pertinents.

Choix UX pour la recherche qui comptent

• Autofocus sur l’entrée sur desktop. Sur mobile, soyez prudent : l’autofocus peut déclencher le clavier et irriter les gens. Rendez-le conditionnel.
• Pré-remplir avec le chemin manquant comme suggestion, pas comme requête forcée. Les gens veulent souvent un terme apparenté, pas « docs-v2-final-final ».
• Accepter des requêtes simples. N’exigez pas une syntaxe avancée. C’est un outil de récupération, pas la console de recherche d’un power-user.
• Retourner les résultats rapidement. Si votre backend de recherche est lent, dégradez gracieusement : montrez des liens sélectionnés et un moyen de parcourir les catégories.

Contrôles de sécurité et anti-abus

Les endpoints de recherche attirent les scrapeurs. Votre page 404 peut amplifier le trafic de recherche si des bots arrosent des URLs aléatoires et que vous répondez par des appels de recherche lourds.

Des contrôles qui ne ruinent pas l’UX :

• Ne pas lancer la recherche automatiquement uniquement parce qu’un 404 est survenu. Attendez une action utilisateur (submit) ou faites une liste de suggestions très légère à partir d’un index local.
• Limiter le débit des requêtes de recherche par IP et/ou session. Gardez la page 404 découplée de la partie coûteuse.
• Définir un timeout strict pour les appels de recherche, puis basculer vers des liens sélectionnés. Une recherche lente est pire que pas de recherche.
• Échapper les entrées et éviter de refléter les chaînes de requête brutes dans le HTML. C’est l’hygiène XSS standard, et les 404 sont des cibles fréquentes car ils reflètent le chemin demandé.

Réalité opérationnelle : la recherche est une dépendance

Si votre page 404 appelle le backend de recherche, vous venez de rendre « lien manquant » dépendant de votre système le plus complexe. C’est une inversion de dépendance. Une règle simple que je suis : la page 404 doit se rendre complètement sans aucun appel en amont. La recherche peut être un lien vers une page de recherche, ou une boîte intégrée qui soumet vers un endpoint séparé. La réponse 404 elle‑même doit rester peu coûteuse.

L’ingénierie de la fiabilité propose un principe clair ici. Pour paraphraser John Gall : « Les systèmes complexes qui fonctionnent ont généralement évolué à partir de systèmes plus simples qui fonctionnaient. » Votre 404 devrait être l’une des pages les plus simples que vous servez.

Liens utiles qui ne ressemblent pas à un dump de sitemap

Une page 404 avec 40 liens n’est qu’un autre type de « introuvable ». Faites une curation.

Comment choisir les bons liens

Choisissez des liens basés sur l’intention, pas sur la structure organisationnelle. Dans les sites d’entreprise, l’organigramme saigne souvent dans la navigation. Résistez à cela. Les utilisateurs ne se soucient pas de savoir quel VP possède « Solutions ». Ils veulent accomplir une action.

Bons choix par défaut pour beaucoup de produits :

• Accueil
• Recherche (ou un lien vers la recherche)
• Tarifs (ou Plans)
• Documentation (ou Centre d’aide)
• Statut (si vous en avez ; si vous n’en avez pas, ne le fabriquez pas)
• Contacter le support
• Se connecter (si applicable)

Suggestions contextuelles

Les suggestions contextuelles surpassent les génériques. Exemples efficaces :

• Si le chemin commence par /docs/, proposer « Accueil Docs » et « Référence API ».
• Si le chemin commence par /blog/, proposer « Articles récents » et « Thèmes ».
• Si le chemin ressemble à un asset (.js, .css, .png), afficher un court message destiné aux développeurs : « Cela ressemble à un fichier statique manquant. Si vous déployez, vérifiez le pipeline d’assets et le cache CDN. »

Un lien pour signaler le problème (sans en faire votre pompe à tickets)

Une option « Signaler ce lien cassé » peut être précieuse, mais seulement si vous l’implémentez intelligemment :

• Pré-remplir l’URL manquante et le referrer.
• Exiger un effort minimal (un clic pour ouvrir un formulaire).
• Ne pas exiger de connexion sauf si votre produit est exclusivement authentifié.
• Diriger dans un flux de triage (pas directement vers des pages d’ingénierie). Sinon, vous entraînerez les gens à l’utiliser comme bouton de plainte général.

HTTP et SEO : éviter les pièges du « soft 404 »

Voici la règle opinionnée : retournez 404 pour le contenu qui n’existe pas. Ne redirigez pas tout vers la page d’accueil. Ne retournez pas 200 avec un message amical. C’est ainsi que votre index de recherche finit rempli de déchets et que votre monitoring ment.

Choix de codes de statut

• 404 Not Found : par défaut pour les pages ou ressources manquantes.
• 410 Gone : à utiliser pour du contenu supprimé intentionnellement de façon permanente lorsque vous êtes sûr qu’il ne reviendra pas.
• 301 Moved Permanently : à utiliser lorsqu’il existe une URL de remplacement claire. Ne pas 301 vers un « à peu près similaire ».
• 302/307 : pour des déplacements temporaires pendant des migrations ou des expérimentations.

Guidance sur canonical et indexation

Une page 404 ne devrait pas être indexée comme contenu. Habituellement vous :

• Retournez un vrai statut 404.
• Incluez une balise noindex (ceinture et bretelles ; le statut indique déjà la marche à suivre à la plupart des crawlers).
• Évitez les balises canonical pointant vers des pages réelles sauf si c’est très délibéré.

Pourquoi « rediriger vers la page d’accueil » est une mauvaise habitude

Ça semble utile. Ce n’est pas le cas. Cela cache les liens cassés, confond les entonnoirs d’analyse, et apprend aux crawlers que votre site ne respecte pas le sens des URL. Les utilisateurs détestent aussi : ils ont cliqué une page spécifique et se retrouvent dans le hall sans direction.

SPAs : séparer « route inconnue » et « contenu manquant »

Les SPA servent souvent index.html pour n’importe quel chemin afin que le routeur client rende la vue appropriée. C’est acceptable pour des routes applicatives valides. Mais quand la route n’existe vraiment pas, vous voulez quand même un 404 — pas un 200 avec un composant « page introuvable ».

Approche pratique : garder une allowlist côté serveur pour les chemins SPA, ou faire en sorte que l’application retourne 404 au niveau de l’API pour le contenu inconnu et que le serveur retourne 404 pour les chemins d’assets inconnus.

Journalisation, monitoring et alertes : les 404 comme signaux

Les 404 ne sont pas toujours des « erreurs » au sens opérationnel. Les bots vont sonder. Les anciens liens existent encore. Mais les pics et les motifs sont exploitables, et si vous les ignorez vous passerez plus de temps plus tard à faire de l’archéologie médico-légale.

Que journaliser pour un 404

• Chemin demandé et chaîne de requête (avec garde-fous privacy).
• Referrer.
• User agent (ou classification hachée/parsée).
• Header Host (important pour sites multi-tenant).
• Temps de réponse et temps en amont (devraient être quasi-nuls en amont pour un bon 404).
• Statut de cache (HIT/MISS/BYPASS) si derrière un CDN ou reverse proxy.

Sur quoi alerter

Alertez sur les changements de rythme, pas sur les valeurs absolues. Un site avec beaucoup de contenu à longue traîne aura toujours quelques 404.

• Pic de taux 404 par rapport à la baseline.
• URL 404 en tête devenue soudainement chaude (souvent indique un lien interne cassé ou une faute de frappe dans une campagne marketing).
• 404 pour des assets statiques (peut indiquer un déploiement cassé, assets manquants, ou problèmes de purge CDN).
• Beaucoup de 404 + forte latence (votre handler 404 fait trop de travail).

Réalité vie privée et conformité

Ne journalisez pas à la légère des données personnelles. Les chaînes de requête contiennent souvent des emails, tokens ou termes de recherche. Vous pouvez rester utile tout en étant prudent :

• Supprimez ou hachez les paramètres sensibles connus.
• Gardez une rétention courte pour les logs bruts ; conservez plus longtemps les métriques agrégées.
• Classifiez les user agents au lieu de stocker les chaînes complètes si possible.

Performance et fiabilité : votre 404 est sur le chemin critique

La plupart des équipes pensent performance pour la page d’accueil et les flux clés produit. Pendant ce temps, les 404 deviennent silencieusement un vecteur de perte financière parce qu’ils sont faciles à déclencher et souvent mal mis en cache.

Garder la charge utile petite

Une page 404 devrait être principalement du HTML et une pincée de CSS. Si vous envoyez un énorme bundle JS pour dire à l’utilisateur « introuvable », vous méritez la facture que vous recevrez.

Mettre en cache de manière stratégique

Le caching des 404 est utile mais nuancé :

• Cachez les 404 pour les probes de bots évidentes (par ex. chemins d’exploit courants) pendant un TTL court, de préférence à la périphérie.
• Faites attention à cacher les 404 pour du contenu potentiellement nouveau. Si vous mettez en cache un 404 pour une URL qui existera après le prochain déploiement, vous créez des incidents auto-infligés « ça marche à l’origine mais pas au bord ».
• Utilisez des TTLs différents par préfixe de chemin. Les 404 d’assets statiques peuvent être mis en cache plus longtemps ; les chemins de contenu dynamique peuvent nécessiter des TTLs plus courts.

Rendre résilient face aux pannes des backends

Un de mes gains silencieux préférés est de servir les 404 entièrement depuis la couche reverse proxy, sans dépendance à l’application. Quand l’app est tombée, le proxy peut toujours répondre correctement aux chemins manquants et éviter d’encombrer les files en amont.

Playbook de diagnostic rapide

Ceci est le flux « j’ai 15 minutes et un stakeholder impatient ». L’objectif est d’identifier si le goulot est le contenu, le routage, le cache ou le déploiement.

Première étape : confirmer les codes de statut et la portée

• Est-ce un vrai 404 de l’origine, ou un 404 du CDN/WAF, ou un 200 avec contenu « introuvable » ?
• C’est une URL isolée ou tout un préfixe ?
• Est-ce seulement une région/POP, ou partout ?

Deuxième étape : trouver le referrer et la source de vérité

• Lien interne ? Corrigez-le immédiatement et publiez.
• Lien externe ? Ajoutez une redirection si c’est populaire et que la destination est évidente.
• Bruit de bot ? Limitez le débit ou mettez en cache ; pas de panique.

Troisième étape : vérifier les changements de déploiement et de routage

• Est-ce qu’une règle de rewrite a changé ?
• Une règle de fallback SPA a-t-elle accidentellement englouti de vrais 404 ?
• La build a-t-elle cessé de publier des assets (mismatch de hash, artefact manquant) ?

Quatrième étape : vérifier le comportement de cache

• Le CDN met-il en cache les 404 trop agressivement ?
• L’origine envoie-t-elle des en-têtes de cache inattendus ?
• Y a-t-il une config de bord obsolète ?

Cinquième étape : valider la page 404 elle-même

• Le handler 404 est-il lent ou appelle-t-il des services en amont ?
• Génère-t-il des erreurs (500) sous charge ?
• Charge-t-il des JS/CSS lourds depuis des URLs manquantes (404 à l’intérieur du 404) ?

Tâches pratiques : commandes, sorties et décisions

Ces tâches sont conçues pour le débogage en production. Chacune inclut une commande, une sortie représentative, ce que cela signifie, et la décision suivante.

Task 1: Verify the status code is a real 404 (not a soft 404)

cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page
HTTP/2 404
date: Mon, 29 Dec 2025 10:15:21 GMT
content-type: text/html; charset=utf-8
cache-control: max-age=60

Ce que cela signifie : Le serveur retourne un vrai 404. Bon début. Cache-Control indique qu’il peut être mis en cache pendant 60 secondes.

Décision : Si des utilisateurs rapportent « ça existe mais j’ai un 404 », soupçonnez le cache ou le déploiement. Si c’est vraiment manquant, passez à l’analyse des referrers.

Task 2: Detect a soft 404 (200 with “not found” content)

cr0x@server:~$ curl -s -D- https://www.example.com/definitely-missing-page | head -n 12
HTTP/2 200
date: Mon, 29 Dec 2025 10:16:02 GMT
content-type: text/html; charset=utf-8

<!doctype html>
<html>
<title>Page not found</title>

Ce que cela signifie : C’est un soft 404. Votre monitoring, cache et SEO vont tous en pâtir.

Décision : Corrigez le routage pour que le contenu manquant renvoie 404. Pour les SPA, implémentez une allowlist côté serveur ou une gestion correcte des statuts.

Task 3: Check whether the CDN is the one returning the 404

cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page | egrep -i 'server:|via:|x-cache:|cf-cache-status:|x-served-by:'
server: cloudflare
cf-cache-status: HIT

Ce que cela signifie : La réponse est servie par le CDN et mise en cache (HIT). L’origine pourrait ne pas être impliquée.

Décision : Si la page a récemment commencé à exister, purgez ou réduisez le TTL des 404 sur ce chemin. Si elle est vraiment manquante, envisagez de mettre en cache plus longtemps pour les chemins fréquentés par les bots.

Task 4: Confirm origin behavior by bypassing the CDN (where possible)

cr0x@server:~$ curl -s -D- -o /dev/null --resolve www.example.com:443:203.0.113.10 https://www.example.com/definitely-missing-page
HTTP/2 404
date: Mon, 29 Dec 2025 10:18:12 GMT
server: nginx

Ce que cela signifie : Le direct-to-origin renvoie aussi 404, donc le CDN n’invente pas l’erreur.

Décision : Traitez-le comme contenu manquant ou routage d’origine erroné. Passez aux logs pour voir les referrers et motifs.

Task 5: Find top 404 paths in NGINX access logs

cr0x@server:~$ awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  842 /wp-login.php
  311 /docs/storage/zfs-tuning
  207 /assets/app.8f3c1d.js
   98 /favicon.ico

Ce que cela signifie : Vous avez à la fois des probes de bots (/wp-login.php) et un lien probablement cassé réel (/docs/storage/zfs-tuning) plus un asset manquant.

Décision : Probe de bot : cache court et/ou règle WAF. Lien docs : ajouter une redirection ou corriger les liens internes. Asset manquant : traiter immédiatement comme un problème de déploiement/CDN.

Task 6: Identify who is sending users to the missing URL (referrer analysis)

cr0x@server:~$ awk '$9==404 {print $11}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  126 "https://www.example.com/docs/storage/"
   88 "https://www.example.com/blog/introducing-zfs"
   41 "-"

Ce que cela signifie : Une page docs et un article de blog renvoient vers des cibles manquantes. « – » indique aucun referrer (saisie/bookmark/bot).

Décision : Corrigez d’abord les pages sources. Les redirections aident, mais corriger les liens internes évite des 404 répétés.

Task 7: Confirm whether the missing asset exists on disk (static build sanity)

cr0x@server:~$ ls -lh /var/www/html/assets/ | head
total 12M
-rw-r--r-- 1 www-data www-data  92K Dec 29 09:57 app.91a2ce.js
-rw-r--r-- 1 www-data www-data  31K Dec 29 09:57 app.91a2ce.css

Ce que cela signifie : L’asset référencé dans les logs (app.8f3c1d.js) n’est pas présent ; un autre hash existe. Probablement un HTML référant une build obsolète ou un déploiement partiel.

Décision : Vérifiez les artefacts de déploiement et assurez-vous que HTML et assets sont déployés atomiquement. Si vous utilisez un CDN, purgez l’ancien HTML ou ajustez le caching pour éviter de servir des bundles non assortis.

Task 8: Check NGINX config for 404 handling and SPA fallbacks

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'error_page|try_files|location /' | head -n 20
45:    error_page 404 /404.html;
78:    location / {
79:        try_files $uri $uri/ /index.html;
80:    }

Ce que cela signifie : Le serveur utilise try_files pour retomber sur /index.html. C’est acceptable pour les routes SPA, mais cela peut créer des soft 404 si index.html retourne 200 pour des routes manquantes.

Décision : Assurez-vous que le routeur SPA retourne un 404 correct pour les routes client inconnues, ou implémentez une distinction côté serveur entre chemins SPA connus et inconnus.

Task 9: Validate the 404 page is lightweight (TTFB and size)

cr0x@server:~$ curl -s -o /dev/null -w "status=%{http_code} ttfb=%{time_starttransfer} size=%{size_download}\n" https://www.example.com/definitely-missing-page
status=404 ttfb=0.038241 size=6142

Ce que cela signifie : TTFB rapide et payload faible. C’est ce que vous voulez.

Décision : Si le TTFB est élevé, le chemin 404 fait du travail en backend. Corrigez en servant un 404 statique à la périphérie/proxy.

Task 10: Verify cache headers for 404 responses

cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page | egrep -i 'cache-control|expires|age'
cache-control: public, max-age=3600
age: 2540

Ce que cela signifie : Le 404 est mis en cache pendant une heure et a déjà été mis en cache depuis 42 minutes. Ça peut être correct pour les probes de bots, dangereux pour du contenu récemment publié.

Décision : Réduisez le TTL pour les chemins de type contenu, gardez un TTL plus long pour les chemins clairement inutiles. Séparez par bloc de location ou règles CDN.

Task 11: Check whether redirects exist for known legacy paths

cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/docs/storage/zfs-tuning | head -n 8
HTTP/2 404
date: Mon, 29 Dec 2025 10:24:19 GMT

Ce que cela signifie : Pas de redirection. Si c’est une erreur fréquente (Task 5), vous perdez des utilisateurs.

Décision : Ajoutez un 301 vers la meilleure page de remplacement, ou restaurez la page si elle a été supprimée par erreur. Si elle a été supprimée intentionnellement, envisagez le 410.

Task 12: Identify whether 404s correlate with deploy time

cr0x@server:~$ journalctl -u nginx --since "2025-12-29 09:30" --until "2025-12-29 10:30" | egrep -i 'reload|signal|start'
Dec 29 09:58:01 web-1 nginx[1321]: signal process started
Dec 29 09:58:02 web-1 nginx[1321]: signal process started

Ce que cela signifie : Un reload NGINX s’est produit autour du moment où les assets ont changé. Combiné au hash d’asset manquant, cela suggère un problème de déploiement.

Décision : Inspectez la pipeline de déploiement pour l’atomicité ; vérifiez que le HTML référence le bon hash d’asset et que les caches sont purgés de façon cohérente.

Task 13: Spot a 404 storm driven by a single bot UA

cr0x@server:~$ awk '$9==404 {print $12,$7}' /var/log/nginx/access.log | head -n 3
"Mozilla/5.0" /wp-login.php
"SomeScanner/1.2" /admin.php
"SomeScanner/1.2" /.git/config

Ce que cela signifie : Un scanner sonde des chemins prévisibles. Ceux-ci devraient être peu coûteux à servir et idéalement bloqués ou tarpittés à la périphérie.

Décision : Ajoutez des règles WAF ou du rate limiting NGINX pour les motifs abusifs. Mettez ces 404 en cache plus longtemps avec un corps minimal pour économiser les ressources d’origine.

Task 14: Confirm the 404 page isn’t itself causing more 404s (missing CSS/JS)

cr0x@server:~$ curl -s https://www.example.com/404.html | egrep -o 'href="[^"]+|src="[^"]+' | head
href="/assets/app.8f3c1d.css
src="/assets/app.8f3c1d.js

Ce que cela signifie : Votre page 404 dépend d’assets qui pourraient être manquants (comme vu précédemment). Cela crée un second mode d’échec : « la page 404 s’affiche mal », et génère plus de bruit 404.

Décision : Inlinez un CSS minimal pour la page 404 ou référencez des assets stables et versionnés que vous garantissez présents. Gardez-la indépendante du bundle principal de l’app.

Trois mini-histoires d’entreprise (anonymisées, douloureusement plausibles)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’entreprise était en pleine refonte de marque, ce qui signifiait des changements d’URLs. Un chef de produit a demandé « pas de liens cassés », et quelqu’un a traduit cela par « rediriger tous les chemins inconnus vers la page d’accueil ». Ça semblait orienté client et ça a fait taire le graphe 404. Tout le monde a pris le silence pour un succès.

Deux semaines plus tard, les conversions Search payantes ont chuté. Pas une panne—juste une baisse. L’équipe marketing a accusé le ciblage des annonces. L’équipe web a mis la faute sur le tracking. L’analytics montrait du trafic sain et un taux de 404 suspectement bas, ce qui semblait réfuter l’existence de « liens cassés ».

Le vrai problème : des utilisateurs arrivaient sur des liens profonds depuis des annonces et anciens contenus, étaient 302és vers « / » puis partaient. Les sessions semblaient « réussies » dans les tableaux de bord basiques parce que la page d’accueil renvoyait 200. L’entonnoir était cassé parce que l’intention de la landing page était détruite.

Quand l’on-call SRE a finalement tiré les logs bruts, c’était évident : un petit ensemble d’anciennes URLs à forte intention redirigées en masse vers « / ». La réparation a été ennuyeuse : implémenter des redirects 301 spécifiques vers les bonnes pages, restaurer de vrais 404 pour les URLs inconnues, et ajouter du monitoring pour détecter les anomalies de redirection-vers-accueil.

L’hypothèse erronée était « les utilisateurs détestent les 404, donc éliminons-les ». Les utilisateurs détestent les impasses. Un 404 honnête avec une boîte de recherche vaut mieux que mentir avec une redirection vers la page d’accueil.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe voulait réduire la charge sur l’origine. Ils ont décidé de mettre en cache agressivement les 404 à la périphérie : Cache-Control: public, max-age=86400 pour tout ce qui renvoyait 404. Ça a fonctionné immédiatement pour le bruit de bots et les probes aléatoires. Le volume de requêtes vers l’origine a chuté. Quelqu’un a décrété victoire.

Puis un partenaire a publié un lien à fort trafic vers une page qui n’existait pas encore, parce que le calendrier de lancement avait été décalé d’un jour. Lors de la première vague de trafic, la page a correctement renvoyé 404. Le CDN l’a mise en cache pour une journée. Quand la page est devenue live quelques heures plus tard, les utilisateurs recevaient encore le 404 depuis la périphérie.

L’incident a été violent car cela ressemblait à « la page est déployée mais toujours manquante ». Les tests d’origine passaient. Seules certaines régions étaient affectées. Des purges ont été lancées, mais la propagation n’a pas été instantanée et toutes les caches n’ont pas été vidées de façon cohérente.

Le postmortem n’a pas dit « ne jamais mettre en cache les 404 ». Il a dit « mettre en cache les 404 avec intention ». Ils ont introduit des TTLs par chemin : court pour les chemins susceptibles d’apparaître prochainement, long pour les probes d’exploit évidents, et bypass immédiat pour certains préfixes critiques pendant les lancements.

L’optimisation n’est pas synonyme de « définir un TTL long ». Optimiser, c’est choisir ce que vous pouvez vous permettre d’avoir faux.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre entreprise avait une règle peu glamour : chaque 404 doit inclure un identifiant de requête interne, et les 20 chemins 404 principaux doivent être revus chaque semaine. Pas « quand on a le temps ». Chaque semaine. La revue alternait entre l’équipe web et le support.

Un lundi, le rapport montrait un nouveau 404 chaud : un chemin dans la section facturation. Le referrer était interne : un lien dans un template d’email d’onboarding. Personne n’avait touché l’app de facturation. Le template email était géré par le marketing.

Parce que la page 404 incluait l’ID de requête et que les logs étaient structurés, ils ont tracé la source en minutes. L’URL manquait un trait d’union—une faute humaine facile. La correction aussi a été banale : mettre à jour le template d’email et ajouter une redirection depuis l’URL erronée vers la bonne par sécurité.

Le meilleur : cela n’est jamais devenu une « panne du site ». C’est resté une coupure opérationnelle mineure qui a été nettoyée avant de s’aggraver. Pas de reproches. Pas de drame. Juste une petite habitude hebdomadaire qui rapporte gros.

Les processus ennuyeux sont sous-estimés. L’astuce est de choisir des processus ennuyeux qui se connectent réellement à la douleur utilisateur.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: “Our 404 page shows up in Google results”

Cause racine : Soft 404 (statut 200), ou gestion canonique/noindex incorrecte, ou un CDN réécrivant les codes de statut.

Correction : Retournez un vrai 404 pour les pages manquantes. Ajoutez noindex dans le template 404. Vérifiez avec curl -D- que le statut est 404 de bout en bout (CDN inclus).

2) Symptom: “Users see the homepage when they click old links”

Cause racine : Règle de redirection catch‑all pour les chemins inconnus.

Correction : Supprimez les redirections catch‑all. Ajoutez des redirects 301 ciblés pour les URLs legacy connues et gardez de vrais 404 pour les URLs inconnues.

3) Symptom: “404 spike after deploy, mostly assets”

Cause racine : Déploiement non-atomique de HTML + assets hashés ; HTML obsolète mis en cache plus longtemps que les assets ; ordre de purge incorrect.

Correction : Déployez les assets d’abord, puis le HTML, ou déployez dans des répertoires versionnés et basculez un pointeur de façon atomique. Alignez le caching : TTL court pour le HTML, TTL long pour les assets immuables hashés.

4) Symptom: “404 page is slow and triggers timeouts under load”

Cause racine : Le handler 404 appelle des services applicatifs (recherche, personnalisation, expériences), ou rend via des templates serveur lourds.

Correction : Servez une page 404 statique au niveau du proxy/edge. Gardez-la indépendante des dépendances en amont. Limitez le temps pour tout appel optionnel et échouez en renvoyant la statique.

5) Symptom: “We can’t reproduce the 404; users in one region can”

Cause racine : Caching CDN des 404, purges incohérentes, ou déploiements fractionnés.

Correction : Vérifiez les en-têtes de cache et l’état de cache. Testez en contournant le CDN. Purgez les URLs spécifiques, puis ajustez le TTL des 404 par chemin.

6) Symptom: “Support gets spammed with broken link reports”

Cause racine : Le lien de signalement manque de friction et de routage ; les bots le déclenchent ; les utilisateurs l’utilisent comme feedback général.

Correction : Ajoutez des contrôles anti-abus basiques (rate limit, CAPTCHA seulement si nécessaire), incluez des champs structurés, et routez vers un triage avec sélection de catégorie claire.

7) Symptom: “Security team complains the 404 page leaks stack details”

Cause racine : Signatures serveur par défaut, en-têtes de framework, sortie debug, ou reflet d’input.

Correction : Supprimez/overridez les tokens serveur, désactivez le debug, échappez toutes les chaînes reflétées, et assurez-vous que les templates d’erreur n’incluent pas de détails d’environnement.

8) Symptom: “Monitoring doesn’t show the issue; users complain anyway”

Cause racine : Soft 404 comptés comme succès, ou dashboards ne suivent que les 5xx, ou redirections qui cachent les erreurs.

Correction : Suivez séparément les taux 404 et 3xx. Alertez sur les changements. Journalisez les referrers. Surveillez les chemins manquants principaux.

Listes de contrôle / plan étape par étape

Checklist A: Build a 404 page that helps users recover

1. Rédiger un texte clair : « Nous ne trouvons pas cette page. » Pas de blâme, pas de panique.
2. Ajouter une boîte de recherche qui soumet vers un endpoint de recherche dédié (ne pas lancer la recherche automatiquement au rendu).
3. Curater 5–8 liens vers les tâches principales. Restez concis.
4. Offrir du contexte : afficher le chemin demandé, échappé en sécurité, et un lien « revenir » si le referrer existe.
5. Ajouter une option de signalement seulement si vous pouvez la trier. Pré‑remplir l’URL manquante et le referrer.
6. Rendre accessible : titres appropriés, gestion du focus, et contraste lisible.

Checklist B: Make it correct for SEO and caching

1. Retourner HTTP 404 pour les ressources manquantes. Valider au bord.
2. Utiliser 410 sélectivement pour les pages supprimées définitivement.
3. Ajouter noindex au template 404.
4. Ne pas rediriger les URLs inconnues vers la page d’accueil. Utiliser des redirections ciblées seulement.
5. Définir des en-têtes de cache sensés : TTL court pour les 404 de type contenu, TTL plus long pour les probes de bots évidents.

Checklist C: Instrumentation and operations

1. Journaliser les 404 de façon structurée : chemin, statut, referrer, classe UA, ID de requête, statut de cache.
2. Créer un rapport top-404 (quotidien ou hebdo) et assigner une responsabilité.
3. Alerter sur les pics, pas sur l’existence. Les 404 sont normaux ; les changements soudains ne le sont pas.
4. Suivre les 404 d’assets séparément des 404 de pages.
5. Exécuter un check de liens internes cassés dans le CI pour la doc/contenu.

Checklist D: Migration and redesign safety

1. Inventorier les URLs à fort trafic avant de changer l’architecture d’information.
2. Planifier des redirections pour les remplacements évidents ; éviter les redirections « assez proches ».
3. Garder les anciennes URLs actives pendant une période avec des 301, surtout pour la doc et les articles de blog.
4. Retester après les changements CDN : codes de statut, caching et comportement de purge.

FAQ

Une page 404 doit-elle retourner 404 ou 200 ?

Retournez 404. Un 200 avec contenu « introuvable » est un soft 404 qui casse les signaux SEO, la précision des analytics et la visibilité opérationnelle.

Quand devons‑nous utiliser 410 Gone plutôt que 404 ?

Utilisez 410 quand vous êtes sûr que le contenu est intentionnellement supprimé et ne reviendra pas. C’est un signal plus fort pour les crawlers et aide à réduire le crawl répété d’URLs mortes.

Est‑il acceptable de rediriger les pages manquantes vers la page d’accueil ?

Non, pas en règle générale. Cela cache les liens cassés et nuit à l’intention utilisateur. N’utilisez des redirections ciblées que lorsqu’il existe un remplacement réel.

La page 404 doit‑elle inclure le menu de navigation du site ?

Généralement non. Fournissez un petit ensemble de liens à forte valeur. La navigation complète encourage l’errance jusqu’à l’abandon et alourdit la page.

Faut‑il une boîte de recherche sur la page 404 ?

Si vous avez plus que quelques pages, oui. C’est l’outil de récupération le plus rapide. Mais ne faites pas dépendre le rendu du 404 d’un appel au backend de recherche.

Comment empêcher les bots de provoquer des réponses 404 coûteuses ?

Servez des 404 bon marché, mettez en cache les chemins de probe évidents, et limitez le débit pour les motifs abusifs. Gardez votre handler 404 statique et évitez les dépendances backend.

Pourquoi voit‑on beaucoup de 404 pour /wp-login.php alors que nous n’utilisons pas WordPress ?

C’est du bruit courant provenant des scanners. Traitez‑le comme une opportunité d’économies : renvoyez un 404 minimal mis en cache et envisagez des règles WAF.

Comment savoir si le CDN met en cache les 404 de façon incorrecte ?

Vérifiez les en‑têtes comme Age et le statut de cache du CDN. Comparez le comportement bord vs origine en contournant le CDN (si possible) et en révisant la politique cache-control par chemin.

Notre SPA sert toujours index.html. Comment gérer correctement le 404 ?

Conservez le fallback SPA uniquement pour les routes applicatives connues. Les chemins inconnus doivent retourner 404 côté serveur, ou le routeur client doit rendre une vue 404 tandis que le serveur retourne 404 lorsque c’est faisable.

Devons‑nous inclure un bouton « signaler un lien cassé » ?

Uniquement si vous pouvez le trier de façon fiable et le défendre contre les abus. Si vous l’ajoutez, pré‑remplissez l’URL manquante + le referrer et routez vers une file qui sera revue.

Conclusion : prochaines étapes pratiques

Une page 404 non gênante n’est pas un exercice de branding. C’est une petite fonctionnalité de fiabilité qui maintient les utilisateurs en mouvement et informe votre équipe. Bien faite, elle réduit la charge support, protège le SEO et transforme le « manquant » en « actionnable ».

Faites ceci ensuite, dans l’ordre :

1. Rendre les codes statut véridiques : éliminez les soft 404 et les redirections catch‑all vers la page d’accueil.
2. Rendre le 404 peu coûteux : réponse statique, assets minimaux, pas d’appels backend requis.
3. Ajouter des outils de récupération : une boîte de recherche (basée sur la soumission) et une courte liste de liens top‑tâches.
4. Instrumenter et revoir : journaliser les referrers, suivre les URLs manquantes principales et définir des alertes de pic.
5. Corriger les sources : d’abord les liens internes cassés, puis les redirections ciblées pour les manques externes populaires.

Si vous ne faites qu’une chose : arrêtez de traiter le 404 comme une impasse. C’est un endpoint diagnostic avec un utilisateur devant.