Codes HTTP : la liste complète et comment corriger les erreurs sur ton site

Tu as forcément déjà croisé une page « 404 Not Found ». Peut-être même une « erreur 500 » un lundi matin, avec ton site tout entier remplacé par un message blanc incompréhensible. Et à ce moment-là, personne ne t’explique ce qui se passe ni quoi faire.

Ces numéros à trois chiffres, ce sont les codes HTTP. Une fois que tu les comprends, ton site arrête d’être une boîte noire : tu sais lire ce qu’il te dit, et surtout tu sais réagir.

Chez Palmsquare, on surveille et on répare des dizaines de sites toute l’année avec nos contrats de maintenance de site WordPress. Des erreurs 500 et des 404 en pagaille, on en voit toutes les semaines. Dans cet article, je t’explique chaque code avec des mots simples, et je te donne la méthode pour corriger les erreurs les plus courantes sur WordPress. Zéro jargon non traduit, promis.

C’est quoi un code HTTP ?

Un code HTTP est un nombre à trois chiffres que le serveur renvoie à ton navigateur à chaque demande de page. Il indique le résultat de la demande : réussite (200), redirection vers une autre adresse (301), page introuvable (404) ou panne du serveur (500). C’est le langage de statut du web.

Pour bien comprendre, imagine que le web est un restaurant. Toi, c’est le client : ton navigateur passe commande (« je veux cette page »). Le serveur web, c’est la cuisine : il reçoit la commande, la prépare et renvoie une réponse. Le code HTTP, c’est ce que te dit le serveur en revenant à ta table. « Voilà ton plat » (200). « On a déménagé, voici la nouvelle adresse » (301). « Ce plat n’est plus à la carte » (404). « La cuisine a pris feu » (500).

Cet échange a lieu des dizaines de fois par page consultée : chaque image, chaque fichier, chaque police d’écriture fait sa propre requête et reçoit son propre code HTTP. Tu ne les vois jamais, et c’est normal : ils circulent en coulisses, dans le protocole HTTP qui fait tourner tout le web.

Comment voir le code d’une page ? Ouvre les outils développeur de ton navigateur (touche F12), onglet « Réseau », puis recharge la page.

La colonne « Statut » affiche le code de chaque requête envoyée. Pas besoin d’être développeur : tu regardes juste la couleur des chiffres. Du 200 partout, tout va bien.

Petite précision au passage, parce qu’on me pose souvent la question : HTTPS ne change rien à tout ça. Le S signifie simplement que l’échange entre ton navigateur et le serveur est chiffré, donc illisible pour un curieux qui intercepterait la conversation. Les codes, eux, restent exactement les mêmes.

Les 5 familles de codes HTTP

Bonne nouvelle : pas besoin d’apprendre des dizaines de codes par cœur. Le premier chiffre te dit déjà tout, comme un feu tricolore.

La distinction la plus utile à retenir : 4xx, le problème vient de la requête. 5xx, le problème vient du serveur. Une 404, c’est toi (ou un lien) qui demande une page qui n’existe pas. Une 500, c’est la machine qui n’arrive plus à répondre. Le diagnostic ne se fait pas du tout au même endroit.

Ce premier chiffre est ton meilleur ami pour diagnostiquer vite. Un visiteur t’appelle en disant « ton site ne marche pas » ? Demande-lui juste le numéro affiché. Ça commence par 4 : tu cherches du côté des liens et des adresses. Ça commence par 5 : tu fonces voir ton serveur et tes plugins. Tu viens de gagner une heure de recherche à l’aveugle.

Les codes 1xx, tu peux les oublier tout de suite : ce sont des messages techniques échangés entre machines pendant le traitement, tu n’en croiseras jamais en naviguant. Passons aux familles qui te concernent vraiment.

Les codes 2xx : tout roule

Le code 200 OK, c’est la situation normale du web. Le navigateur a demandé une page, le serveur l’a trouvée et l’a envoyée. Le plat est arrivé à table, chaud et complet. Un site en bonne santé renvoie du 200 sur toutes ses pages publiques.

Deux cousins que tu peux croiser dans tes outils : le 201 Created (une ressource vient d’être créée, par exemple après l’envoi d’un formulaire) et le 204 No Content (demande réussie, mais rien à renvoyer). Rien à faire de spécial avec eux : succès, c’est succès.

Les codes 3xx : les redirections (le nerf de la guerre SEO)

Une redirection, c’est un panneau « nous avons déménagé » collé sur la porte de l’ancienne adresse. Le visiteur qui tape l’ancienne URL est automatiquement emmené vers la nouvelle, sans rien faire. Simple en apparence, mais c’est ici que se jouent (et se perdent) des années de référencement.

La redirection 301 : le déménagement définitif

Le code 301 Moved Permanently annonce un déménagement permanent. Il dit aux visiteurs ET aux moteurs de recherche : « cette page a changé d’adresse pour toujours, mettez le carnet d’adresses à jour ». Google transfère alors l’historique et l’autorité SEO de l’ancienne URL vers la nouvelle. Sans redirection 301, tout ce capital part à la poubelle.

C’est LE réflexe vital en refonte de site. Quand on refond un site chez Palmsquare, le plan de redirections 301 fait partie de la mise en ligne au même titre que les sauvegardes : chaque ancienne URL doit pointer vers sa remplaçante. On détaille d’ailleurs ce point dans les questions à se poser avant une refonte WordPress. Un site refondu sans plan de redirections, c’est la garantie de voir son trafic organique s’effondrer en quelques semaines.

La redirection 302 : le déménagement temporaire

Le code 302 Found signale une redirection provisoire. En clair : « on est momentanément à côté, mais on revient, ne changez rien au carnet d’adresses ». Les moteurs de recherche gardent l’ancienne adresse dans leur index et ne transfèrent pas l’autorité.

Utilise la 302 pour une page en travaux, une opération ponctuelle, un test. Le piège classique : mettre une 302 à la place d’une 301 lors d’un vrai déménagement. Résultat, Google attend indéfiniment le retour de l’ancienne page et ta nouvelle page ne décolle jamais.

• ❌ Mauvais réflexe : une 302 posée « en attendant » pour un changement définitif.
• ✅ Bon réflexe : une 301 dès que l’adresse change pour de bon, et on n’y touche plus.

304, 307, 308 : les seconds rôles

Le 304 Not Modified est un code d’économie : le serveur dit à ton navigateur « la page n’a pas changé depuis ta dernière visite, ressers-toi dans ton cache ». C’est comme réchauffer les restes d’hier au lieu de recommander le même plat : plus rapide pour tout le monde. Ce mécanisme de cache est un des leviers pour améliorer la vitesse de ton site WordPress.

Les 307 et 308 sont les versions modernes et plus strictes des 302 et 301. Même logique : 307 temporaire, 308 permanent. Si tu les croises, traduis-les mentalement pareil.

⚠️ Le piège des chaînes de redirections

Une redirection qui pointe vers une redirection qui pointe vers une troisième, c’est un courrier réexpédié trois fois : il finit par arriver, mais lentement, et le facteur s’agace. Chaque saut ralentit le chargement et gaspille le budget crawl, c’est-à-dire le temps que Google accepte de consacrer à explorer ton site.

Au-delà de quelques sauts, Googlebot abandonne carrément.

Règle simple : une redirection va toujours directement à la destination finale, sans escale.

Les erreurs 4xx : le problème vient de la demande

L’erreur 404 : la page introuvable

Le code 404 Not Found est l’erreur la plus célèbre du web : la page demandée n’existe pas à cette adresse. Le plat n’est plus à la carte. Ça arrive quand une page a été supprimée, quand une adresse a changé sans redirection, ou quand un lien contient une faute de frappe.

Quelques 404 isolées, ce n’est pas un drame, tous les sites en ont. Le vrai problème, c’est l’accumulation : des dizaines de liens morts dégradent l’expérience utilisateur, gaspillent le temps d’exploration des robots et envoient aux moteurs de recherche un signal de site à l’abandon.

Trois réflexes pour bien gérer tes 404 :

• Crée une page 404 personnalisée. Sur WordPress avec Elementor, tu peux la designer en dix minutes : un message sympa, un lien vers l’accueil, une barre de recherche, tes contenus phares. Le visiteur perdu redevient un visiteur guidé, au lieu de fermer l’onglet.
• Redirige en 301 les pages supprimées qui recevaient du trafic vers la page la plus proche thématiquement. Pas toutes vers l’accueil : les moteurs considèrent ça comme des soft 404, des fausses réponses qui ne trompent personne.
• Surveille tes 404 dans Google Search Console, rapport « Pages ». C’est gratuit et ça te liste exactement quelles URL posent problème.

À savoir aussi : le code 410 Gone existe pour dire « cette page a été supprimée volontairement et définitivement ». Plus honnête qu’une 404 quand tu assumes la suppression, et la désindexation est plus rapide.

Les erreurs 401 et 403 : accès refusé

Le 401 Unauthorized réclame une authentification : c’est la porte du salon privé, il faut montrer patte blanche (se connecter). Le 403 Forbidden, c’est plus sec : « je sais qui tu es, mais tu n’entres pas ».

Sur WordPress, une erreur 403 qui surgit sans prévenir vient presque toujours d’un fichier .htaccess corrompu, de mauvaises permissions de fichiers ou d’un plugin de sécurité trop zélé qui bloque des visiteurs légitimes. Le réflexe : désactiver temporairement le plugin de sécurité, régénérer le fichier de configuration (Réglages puis Permaliens, bouton Enregistrer, sans rien changer), et vérifier les permissions avec ton hébergeur.

400 et 429 : les mal aimées

Le 400 Bad Request signale une requête incompréhensible pour le serveur, souvent une URL malformée ou des cookies corrompus. Vider le cache et les cookies du navigateur règle la plupart des cas.

Le 429 Too Many Requests dit « tu me sollicites trop, calme-toi ». Il apparaît quand un robot (ou un plugin trop bavard) bombarde le serveur de requêtes. Si ce code apparaît dans tes rapports d’exploration, parles-en à ton hébergeur : tu refuses peut-être du monde, y compris Googlebot.

Les erreurs 5xx : le serveur est en panne (et comment réparer sur WordPress)

On entre dans la catégorie qui fait transpirer : les erreurs 5xx rendent ton site inaccessible. La demande du visiteur était bonne, c’est la cuisine qui ne répond plus. Voici comment reprendre la main, sans paniquer.

L’erreur 500 : le diagnostic pas à pas

Le code 500 Internal Server Error est le message le plus flou du web : « quelque chose a cassé côté serveur », sans plus de détail. Sur WordPress, dans 9 cas sur 10, le coupable est un plugin, un thème ou la mémoire PHP. Voici la méthode qu’on applique chez Palmsquare, dans l’ordre :

1. Désactive tous les plugins. Si tu n’as plus accès à l’administration, renomme le dossier wp-content/plugins en plugins-old via le FTP ou le gestionnaire de fichiers de ton hébergeur. Le site revient ? Réactive les plugins un par un jusqu’à trouver le fautif.
2. Bascule sur un thème par défaut (Twenty Twenty-Four par exemple). Si le site revient, le problème est dans ton thème.
3. Augmente la mémoire PHP. Une ligne dans le fichier wp-config.php : define('WP_MEMORY_LIMIT', '256M');. Les sites chargés en plugins saturent vite la mémoire allouée par défaut.
4. Régénère le fichier .htaccess. Renomme l’ancien, puis Réglages, Permaliens, Enregistrer. WordPress en recrée un propre.
5. Consulte les logs d’erreur depuis ton hébergeur : ils nomment noir sur blanc le fichier qui plante. C’est l’étape que tout le monde saute alors qu’elle donne la réponse.

Le scénario qu’on voit sans arrêt en maintenance de site web : une mise à jour automatique de plugin dans la nuit, incompatible avec la version de PHP du serveur, et le site est tombé au petit matin.

Personne ne s’en rend compte avant le premier appel d’un client. C’est exactement pour ça qu’une surveillance existe : nous, on reçoit l’alerte dans les minutes qui suivent et on restaure avant que quiconque ait remarqué.

Les erreurs 502 et 504 : les intermédiaires qui toussent

Le 502 Bad Gateway signifie qu’un serveur intermédiaire (un proxy, un CDN comme Cloudflare) a reçu une réponse invalide du serveur principal. Le 504 Gateway Timeout, c’est le même intermédiaire qui n’a pas reçu de réponse du tout dans les temps : la cuisine met tellement de temps que le serveur en salle abandonne la commande.

Ces deux-là viennent rarement de ton site lui-même. Vide le cache de ton CDN si tu en as un, patiente quelques minutes, et si ça persiste, contacte ton hébergeur. Des 502 ou 504 à répétition sont souvent le signe d’un hébergement sous-dimensionné : un mutualisé à 3 € qui héberge un site à fort trafic, ça finit toujours par déborder. Notre comparatif des meilleurs hébergements WordPress peut t’aider à choisir une base saine.

L’erreur 503 : service temporairement indisponible

Le code 503 Service Unavailable dit « le serveur existe, mais il ne peut pas répondre pour le moment ». Restaurant fermé pour travaux : c’est provisoire, repassez plus tard.

Sur WordPress, la 503 apparaît dans deux situations. La première est normale : pendant une mise à jour, WordPress se met brièvement en pause, le temps d’installer les nouveaux fichiers. Si le message d’indisponibilité reste bloqué, supprime le fichier .maintenance à la racine du site et tout rentre dans l’ordre. La deuxième est plus sérieuse : le serveur est surchargé (pic de trafic, attaque, ressources épuisées) et refuse du monde. Là encore, logs et hébergeur.

La liste complète des codes HTTP

Le tableau de référence à garder sous le coude. Les codes en gras sont ceux que tu croiseras vraiment.

Pourquoi les codes HTTP comptent pour ton référencement

Google ne voit pas ton site comme un visiteur. Il le voit comme une immense liste de requêtes et de codes de réponse. Et il en tire des conclusions.

Chaque code HTTP envoie un signal aux moteurs de recherche. Du 200 partout : site sain, on indexe. Des 301 propres : on suit et on transfère l’autorité. Des 404 en masse, des chaînes de redirections, des 500 à répétition : site négligé, on crawle moins, on positionne moins bien. Le budget crawl que Google t’accorde est limité, chaque erreur en gaspille une partie.

Un mot sur les soft 404, le piège le plus sournois de la famille. C’est une page qui affiche « contenu introuvable » à l’écran mais renvoie quand même un code 200 au serveur. Le visiteur voit une erreur, Google voit un succès : personne ne comprend plus rien, et la Search Console te le reproche. Ça arrive typiquement quand un plugin affiche un message d’erreur dans une page normale au lieu de renvoyer un vrai code 404. Vérifie ce rapport de temps en temps, il révèle souvent des pages fantômes dont tu ignorais l’existence.

Les erreurs 5xx sont les plus dangereuses pour ton référencement : si Googlebot tombe plusieurs fois de suite sur un site en panne, il espace ses visites et peut désindexer des pages. Couplé à un temps de chargement dégradé, c’est la double peine. Après une mise en ligne ou une refonte, va vérifier que tout répond en 200 avant même de penser à faire indexer tes pages rapidement.

Et côté humain, c’est encore plus simple : un visiteur qui tombe sur une erreur ne revient presque jamais. Chaque 404 et chaque 500 est un prospect qui repart chez le concurrent.

Les outils pour détecter et surveiller les erreurs

Pas besoin d’une armée d’outils pour surveiller tes codes HTTP. En voici quatre, du plus simple au plus costaud :

• Google Search Console : gratuit et obligatoire. Le rapport « Pages » liste les 404, les fausses pages d’erreur, les erreurs serveur et les problèmes de redirection que Google rencontre sur ton site. Si tu ne dois en installer qu’un, c’est lui.
• Les outils développeur du navigateur (F12, onglet Réseau) : pour vérifier ponctuellement une page et voir le code de chaque ressource.
• Le plugin Redirection sur WordPress : il gère tes redirections 301 sans toucher au .htaccess et journalise toutes les 404 rencontrées par tes visiteurs. Parfait après une refonte.
• Screaming Frog : le scanner professionnel. Il parcourt ton site comme le ferait Googlebot et te sort le code de chaque page. La version gratuite couvre 500 URL, assez pour la plupart des TPE. On l’utilise dans tous nos audits, comme on l’explique dans notre guide pour analyser un site web.

Ma recommandation : une vérification mensuelle de la Search Console et un passage du scanner après chaque grosse modification du site. Trente minutes par mois qui t’évitent de découvrir en catastrophe que la moitié de ton site renvoie des erreurs depuis des semaines.

C’est exactement ce qu’on fait pour nos clients sous contrat : surveillance du site 24h/24, correction des erreurs avant qu’elles fassent des dégâts, mises à jour testées.

👉 Si tu préfères déléguer tout ça, jette un œil à nos tarifs de maintenance WordPress, ça démarre à 89 € par mois. Et si tu veux en discuter de vive voix, parlons de ton site.

Deux pannes réelles (et ce qu’elles t’apprennent)

La théorie c’est bien, mais rien ne vaut deux histoires vécues pour comprendre ce que ces codes changent concrètement dans la vie d’un site.

Cas n°1 : le site tombé dans la nuit de dimanche

Un client nous appelle un lundi à 8h30 : « mon site affiche une erreur, les clients me le signalent ». Diagnostic en dix minutes : erreur 500, déclenchée par la mise à jour automatique d’un plugin de formulaire pendant la nuit, incompatible avec la version PHP du serveur.

Correction : restauration de la sauvegarde de la veille, mise à jour testée sur une copie du site, puis redéployée proprement. Le tout en vingt minutes.

La leçon : ce n’est pas la mise à jour le problème, c’est la mise à jour non surveillée. Un site professionnel ne devrait jamais apprendre ses pannes par ses propres clients.

Cas n°2 : la refonte qui a fait fondre le trafic

Un prospect nous contacte trois mois après une refonte réalisée sans plan de redirections : son trafic organique a été divisé par deux.

Passage de Screaming Frog : plus de 80 anciennes adresses renvoyaient une erreur 404, tout l’historique SEO accumulé pendant des années pointait dans le vide.

Correction : redirections 301 vers les pages équivalentes du nouveau site, réindexation, quelques semaines de patience, et le trafic est remonté progressivement. La leçon : ce n’est pas la refonte qui a cassé le référencement, c’est l’absence de redirections.

Ces deux histoires racontent la même chose : les codes HTTP ne préviennent pas, ils constatent. Personne ne t’enverra d’email pour te dire que ton site accumule les erreurs. C’est à toi, ou à ton prestataire, d’aller les lire régulièrement. Trente minutes par mois suffisent, mais il faut les faire.

FAQ : tes questions sur les codes HTTP