Avant même d’envoyer la moindre ligne de contenu, votre serveur envoie un nombre à trois chiffres. Ce nombre dit tout : la page existe-t-elle, a-t-elle déménagé, définitivement ou non, le serveur est-il en panne. Les navigateurs le traitent silencieusement, les visiteurs ne le voient jamais, et les moteurs de recherche en tirent des conclusions durables. Savoir quel code renvoyer dans quelle situation évite une bonne partie des problèmes techniques classiques.
À quoi sert un code de réponse
Chaque requête adressée à un serveur reçoit une réponse en deux parties : un en-tête, puis éventuellement un contenu. Le code de statut figure dans l’en-tête, avant tout le reste.
C’est cette antériorité qui compte. Un moteur sait qu’une page a disparu avant même d’avoir lu son contenu, ce qui lui permet de traiter la situation sans perdre de ressources. Inversement, un serveur qui annonce « tout va bien » puis affiche un message d’erreur envoie une information contradictoireet c’est la première partie qui fait foi.
Les codes se répartissent en familles : 200 pour les succès, 300 pour les redirections, 400 pour les erreurs venant de la demande, 500 pour les erreurs venant du serveur. Une poignée d’entre eux suffit à couvrir tous les cas courants. Les erreurs de configuration les plus fréquentes, recensées sur www.seo-jimenezjulien.com, tiennent d’ailleurs presque toutes à un code mal choisi plutôt qu’à un problème de fond.
Les codes de succès et de redirection
200OK. La page existe et son contenu suit. C’est ce que doivent renvoyer toutes vos pages destinées à être vues et indexées.
301Déplacé définitivement. L’adresse a changé pour de bon. Le moteur remplace l’ancienne URL par la nouvelle dans son index et transfère l’historique accumulé : liens entrants, ancienneté, positions. C’est le code à utiliser dans l’immense majorité des cas de changement d’adresserefonte, changement de domaine, passage en HTTPS, fusion de deux pages.
302Trouvé ailleurs temporairement. L’adresse d’origine reste la référence, le contenu est simplement servi ailleurs pour un temps. Le moteur conserve l’ancienne URL et attend son retour. Réservez-le aux situations réellement provisoires : maintenance, opération saisonnière, test comparatif entre deux versions.
307Redirection temporaire stricte. Variante moderne du 302, qui garantit que la méthode de la requête initiale est préservée. Sans importance pour la navigation classique, utile pour les formulaires et les interfaces applicatives.
La distinction permanent/temporaire n’est pas cosmétique. Utiliser un 302 pour un changement définitif retarde le transfert de valeur de plusieurs mois, le temps que le moteur constate que la situation ne bouge pas et requalifie de lui-même la redirection.

Les codes d’erreur côté client
404Introuvable. L’adresse ne correspond à rien. Ce n’est pas une faute : un site vivant en produit forcément. Google a indiqué à plusieurs reprises que les 404 ne pénalisent pas un site. Ce qui compte est le contexteune 404 sur une page oubliée est sans conséquence, une 404 sur une page qui recevait du trafic et des liens est une perte à traiter.
410Supprimé définitivement. Vous affirmez que la page a existé et n’existera plus. Le retrait de l’index est légèrement plus rapide qu’avec un 404. Utile lors d’un nettoyage de masse assumé, sans être indispensable : la différence pratique reste modeste.
403Interdit. Le serveur a compris la demande et refuse d’y répondre. À réserver aux ressources réellement protégées. Attention : un 403 renvoyé par erreur sur des fichiers de style ou de script empêche le rendu correct de vos pages.
401Authentification requise. La ressource est accessible après identification. C’est le code approprié pour protéger un environnement de préproductionnettement plus sûr qu’une directive dans le code, qui risque d’être déployée en production par mégarde.
Les codes d’erreur côté serveur
500Erreur interne. Quelque chose a échoué côté serveur. Ponctuel, c’est sans gravité. Récurrent, c’est un problème sérieux : le moteur réduit progressivement son rythme d’exploration sur un site qui renvoie régulièrement des erreurs, et cette réduction affecte l’ensemble du site, pas seulement les pages fautives.
503Service indisponible. Le bon code pour une maintenance planifiée. Il indique une indisponibilité temporaire et invite le robot à repasser plus tard. Accompagnez-le d’un en-tête Retry-After précisant le délai.
Un point à connaître : une indisponibilité de quelques heures n’a aucune conséquence. Prolongée sur plusieurs jours, elle conduit le moteur à commencer à retirer des pages de son index. Au-delà d’une semaine, la récupération demande du temps.
Les erreurs de configuration classiques
Certaines erreurs de configuration reviennent avec une régularité déconcertanteet toutes se corrigent en quelques minutes une fois identifiées.
La page d’erreur qui renvoie un code 200. C’est la fameuse soft 404. Le visiteur voit « page introuvable », le serveur annonce « tout va bien ». Le moteur indexe alors une page vide, ou, s’il détecte l’incohérence, applique sa propre interprétation. Vérifiez que votre page d’erreur personnalisée renvoie bien un véritable code 404 : beaucoup de configurations sur mesure oublient ce détail.
La redirection temporaire laissée en place des années. Mise en place pour une opération de trois semaines, jamais retirée. Elle empêche la consolidation de la valeur sur la destination.
Les chaînes de redirection. A vers B vers C vers D. Chaque saut ajoute de la latence pour le visiteur et consomme une requête d’exploration. Après deux refontes successives, ces chaînes se comptent parfois par milliers. Refaites systématiquement pointer chaque redirection vers sa destination finale.
La redirection en masse vers la page d’accueil. Traitée comme une soft 404, sans transfert de valeur, et déroutante pour le visiteur.
Les boucles. A redirige vers B qui redirige vers A. La page devient inaccessible à tout le monde.
Comment vérifier ce que renvoie une URL
Trois méthodes, selon le volume.
Pour une URL isolée, les outils de développement de votre navigateur affichent le code dans l’onglet réseau. Des vérificateurs en ligne gratuits donnent également la chaîne complète de redirection, ce qui est plus pratique pour repérer les sauts intermédiaires.
Pour un contrôle en masse, un outil d’exploration de site parcourt l’ensemble de vos URL et produit un tableau des codes rencontrés. C’est la méthode à employer avant et après toute migration.
En ligne de commande, une simple requête permet d’afficher uniquement les en-têtes, ce qui suffit pour un contrôle rapide et scriptable sur une liste d’adresses.
Tableau récapitulatif
| Situation | Code à renvoyer | Effet attendu |
|---|---|---|
| Page normale, à indexer | 200 | Contenu exploré et indexé |
| Adresse changée définitivement | 301 | Transfert de l’historique vers la nouvelle URL |
| Contenu servi ailleurs provisoirement | 302 ou 307 | L’ancienne URL reste la référence |
| Page inexistante ou supprimée | 404 | Retrait progressif de l’index |
| Suppression définitive et assumée | 410 | Retrait légèrement plus rapide |
| Ressource protégée par identification | 401 | Non indexé, accès réservé |
| Accès refusé | 403 | Non indexé |
| Maintenance planifiée | 503 + Retry-After |
Le robot repasse plus tard, sans désindexer |
| Panne applicative | 500 | À corriger : réduit le rythme d’exploration |
Une dernière recommandation, valable quel que soit le sujet : contrôlez les codes réellement renvoyés après chaque intervention technique. Un plugin, une règle de serveur ou une configuration d’hébergeur peut annoncer une chose et en faire une autreet cet écart ne se voit que si on le cherche.
