Explicateur de codes de statut HTTP

Tape n'importe quel code de statut HTTP pour voir sa famille, ce qu'il fait aux navigateurs et aux crawlers, et l'angle SEO, avec une table de référence et un check d'URL en direct.

Cet explicateur de codes de statut HTTP te dit ce qu'un code veut vraiment dire, pas la formulation aride de la spec, mais ce qu'il fait à un navigateur, à un crawler et à ton SEO. Tape 200, 301, 304, 404, 429, 503 ou n'importe lequel des plus de trente codes intégrés et lis la famille à laquelle il appartient, l'usage typique, le comportement client, la lecture du cache et la checklist de correction, le tout en clair. Des boutons rapides sautent vers les codes qui mordent le plus souvent. Colle une URL en direct et le check suit le vrai parcours de la réponse : il remonte le statut final, les en-têtes de la première réponse et chaque saut de redirection, puis sort le code auquel tu as vraiment affaire, parce que le premier contact et la réponse finale sont souvent en désaccord. Une table de référence pratique couvre toute la plage 1xx à 5xx pour que tu arrêtes de deviner et copies un rapport de statut propre.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Référence des codes HTTP avec contexte d'URL en direct

Tape un code de statut. Je te dis ce qu'il veut vraiment dire. Pas la formulation aride de la spec, mais ce qu'il fait concrètement au navigateur ou à un crawler. Et à ton week-end, quand il débarque dans un log au pire moment. Tu récupères la famille à laquelle il appartient et l'angle SEO. Et si en plus tu me donnes une URL en direct, je remonte le vrai parcours de la réponse, puis je te sors le code auquel tu as vraiment affaire.

Code de statut HTTP

URL en direct (optionnel)

Le check en direct attrape le statut final, les en-têtes de la première réponse et chaque saut de redirection sur le chemin. Mais le code ne raconte jamais toute l'histoire. Ta méthode, tes règles de cache, l'auth, le filtrage des bots, ce que l'appli essayait de faire, n'importe lequel de ces éléments peut renverser le diagnostic. Lis-le en gardant ça en tête.

Pourquoi les codes de statut HTTP comptent

Un code de statut HTTP, c'est le nombre à trois chiffres qu'un serveur renvoie en premier, et il décide de tout ce qui suit. Le navigateur le lit, puis il affiche la page, ou il suit une redirection, ou il sort une copie du cache. Peut-être qu'il te colle une fenêtre de connexion, peut-être une erreur. Ou il reste juste là à attendre que le service revienne. Et les navigateurs ne sont que le début de l'histoire. Les crawlers, tes clients d'API, le moniteur d'uptime qui te réveille par SMS à trois heures du matin, chaque ligne de log que tu vas un jour fouiller, tout ça est suspendu à ce premier chiffre.

Là où les gens se trompent, c'est qu'ils prennent le code pour le verdict. Il ne l'est pas. Un 404 est parfaitement correct pour une URL qui n'a jamais existé. C'est une petite catastrophe quand ton propre menu pointe encore dessus. Un 301 est génial pour un vrai déplacement permanent. Mais laisse tous tes liens internes viser l'ancienne adresse, et il devient un poids mort qui oblige tout le monde à faire le détour. Un 503 dit la vérité sur une maintenance bien mieux qu'une page 200 toute souriante mais cassée en douce. Mais balance du 5xx encore et encore, et tu ne poses plus une question de code de statut. Là, c'est une urgence. Donc tu commences par le code, bien sûr. Ensuite, demande-toi ce que cette URL était censée faire au juste.

Les familles, c'est la première carte

Voilà le truc sur lequel s'appuyer. N'apprends pas tout le registre par cœur. Apprends juste le premier chiffre. Les codes 1xx, c'est du bavardage protocolaire entre client et serveur, et honnêtement tu peux à peu près oublier qu'ils existent. 2xx, ça veut dire que la requête est arrivée d'une façon ou d'une autre. 3xx, c'est le serveur qui dit pas ici, va voir là-bas, que ce soit une autre adresse ou la copie que tu as déjà en cache. 4xx, c'est le serveur qui te signale que la requête était mauvaise, ou que tu n'avais pas le droit. Et 5xx, c'est le serveur qui admet qu'il t'a très bien compris, et qu'il s'est ensuite vautré tout seul. Une fois que ce premier chiffre fait tilt, le reste arrête de faire peur.

2xx ne prouve pas que la page est bonne. Ça veut juste dire que c'est la famille dans laquelle le contenu a même le droit d'apparaître.
3xx, c'est une question d'intention : un vrai déplacement permanent, un routage temporaire, une vérification de cache, un chemin que tu as mis en place exprès.
4xx renvoie en général vers l'URL elle-même : l'accès, la connexion, la mauvaise méthode, un quota, une requête mal formée.
5xx ramène ton attention droit vers la fiabilité : les upstreams, les logs de l'appli, et la grande question de savoir si le bidule se rétablit tout seul.

Les codes de statut côté SEO et exploitation du site

C'est l'endroit où l'équipe SEO et l'équipe serveur finissent par se chamailler, et le code de statut tranche en général le débat. Tes pages stratégiques veulent une réponse publique propre, avec des signaux qui sont réellement d'accord entre eux. Ne redirige une ancienne URL que s'il y a vraiment quelque chose vers quoi envoyer les gens. Sinon, laisse tomber. Un contenu réellement disparu a le droit de rester disparu, et le dire honnêtement vaut mieux que faire semblant. Une panne temporaire devrait se lire comme une panne temporaire, pas se faire maquiller derrière un 200 souriant. Et tes liens internes et tes sitemaps devraient pointer droit vers la destination que tu veux vraiment, pas condamner les crawlers à redécouvrir à chaque passage la même redirection inutile. Sur WordPress en particulier, revérifie les codes de statut après tout ce qui touche à la tuyauterie : modifs de permaliens, migrations, un nouveau plugin de cache, des règles de sécurité, un changement de CDN, une protection par mot de passe, le mode maintenance, des modifs de sitemap, tout le tralala.

La routine à dérouler à chaque fois

Pars de l'URL exacte qu'on t'a signalée, celle du visiteur, du log, du crawler ou du moniteur, pas celle que tu crois qu'on voulait dire.
Décortique la première réponse et la réponse finale après redirections. Elles te mentent séparément.
Lis la famille d'abord, puis le code précis, puis demande-toi quel était le rôle de la page au départ.
Partout où la réponse contredit l'intention, va corriger : liens internes, lignes du sitemap, règles de redirection, ou le problème de fiabilité en dessous. Ensuite, re-tape l'URL pour confirmer.

Questions fréquentes

Un 200, c'est toujours bon pour le SEO ?

Non. Tout ce qu'un 200 te dit, c'est que la requête est passée. La page derrière peut très bien être un doublon, maigre comme du papier, planquée sous un noindex, canonicalisée vers ailleurs, ou tout simplement inutile pour celui qui a atterri dessus. Un feu vert sur la requête ne dit rien du contenu qui se trouve derrière.

Un 404, c'est toujours mauvais ?

Pas du tout. Une URL réellement absente devrait renvoyer un 404. C'est la réponse honnête. Ça ne devient un problème que quand des liens importants, ou ton sitemap, ou un chemin que les gens suivent vraiment, les y mènent encore tout droit.

Quelle est la différence entre une redirection 301 et 302 ?

Un 301 dit que ça a bougé pour de bon, et les moteurs de recherche le traitent comme tel, donc les signaux de positionnement passent vers la nouvelle URL. Un 302 dit juste pour l'instant, donc l'original garde sa valeur et rien n'est transmis. Choisis le mauvais pendant une migration et, quelques semaines après, tu resteras les yeux rivés sur une courbe de trafic en te demandant où sont passés tes positionnements.

Quelle est la différence entre un 401 et un 403 ?

Un 401 veut dire que le serveur ne sait pas encore qui tu es, donc va te connecter. Un 403 veut dire qu'il sait exactement qui tu es et qu'il refuse quand même de te laisser entrer. Se connecter règle le premier cas. Ça ne change rien au second.

Une réponse 304 Not Modified, c'est une erreur ?

Non. Un 304 Not Modified, c'est un succès. C'est le serveur qui dit au navigateur que la copie en cache est encore bonne, ce qui évite tout un téléchargement. Le client a déjà une bonne copie stockée, demande si elle est toujours d'actualité, et le serveur répond que oui, rien n'a changé, sers-toi de ce que tu as.