---
title: "Codes de statut HTTP pour le SEO et les performances web"
description: "Un guide pratique des réponses 2xx, 3xx, 4xx et 5xx : comment les codes de statut influent sur l'exploration, l'indexation, les redirections, la mise en cache et les performances web."
canonical_url: https://optimi.com/fr/guides/http-status-codes-seo
md_url: https://optimi.com/fr/guides/http-status-codes-seo.md
last_updated: 2026-07-14
---

# Codes de statut HTTP pour le SEO et les performances web

Le code de réponse fait partie de votre contenu. Choisissez-le délibérément, vérifiez-le en périphérie et à l'origine, et rendez les défaillances visibles avant que les robots ou les clients ne les découvrent.

La réponse courte est simple : renvoyez `200` pour une page qui existe, une redirection permanente pour une page qui a été déplacée définitivement, `404` ou `410` pour du contenu qui n'existe plus, et des erreurs serveur temporaires uniquement lorsque la défaillance est réellement temporaire. Ne renvoyez pas `200` pour une page d'erreur et n'utilisez pas des redirections pour masquer une indisponibilité.

Cette distinction compte à la fois pour les moteurs de recherche et pour les personnes. Google indique qu'une réponse `2xx` peut être prise en compte pour l'indexation, sans la garantir. Il ignore le contenu renvoyé avec une réponse `4xx` ou `5xx`, et des erreurs serveur persistantes peuvent finir par retirer des URL de l'index. La même réponse détermine également si un navigateur, un CDN, un robot ou un système de supervision considère la requête comme réussie, mise en cache, à réessayer ou défaillante.

**Choisissez le code de réponse selon l'intention de l'URL**

![Flux de décision montrant une page existante qui renvoie 200, une page déplacée définitivement qui renvoie 301 ou 308, un contenu supprimé qui renvoie 404 ou 410, et une indisponibilité temporaire qui renvoie 503.](/diagrams/http-status-codes-seo/response-by-url-intent.svg)

*Le bon code de réponse indique si le contenu peut être traité, s'il a été déplacé, s'il n'existe plus ou s'il faut réessayer plus tard.*

## Signification de chaque classe de statut

HTTP regroupe les codes de réponse selon leur premier chiffre. La classe est utile, mais le code exact porte la signification opérationnelle.

- **Succès 2xx :** la requête a réussi. `200 OK` est la réponse normale pour une page HTML indexable. `204 No Content` convient à un endpoint qui ne renvoie volontairement aucun corps, pas à une page qui n'a pas réussi à s'afficher. Une page qui affiche « introuvable » tout en renvoyant `200` est une soft 404 et peut être exclue de la recherche.
- **Redirection 3xx :** la ressource demandée est ailleurs ou le client peut réutiliser sa représentation en cache. `301` et `308` indiquent un déplacement permanent. `302` et `307` indiquent un déplacement temporaire. Google traite les formes permanentes comme des signaux de canonicalisation plus forts, tandis que les formes temporaires préservent généralement l'URL source.
- **Erreur client 4xx :** le serveur ne peut pas servir la ressource demandée telle qu'elle est demandée. `404 Not Found` est la réponse normale pour une URL inconnue. `410 Gone` est utile lorsqu'un contenu a été délibérément et définitivement supprimé. `401` et `403` décrivent le contrôle d'accès, pas une manière recommandée de ralentir les robots. `429 Too Many Requests` est particulier : Google le traite comme une erreur serveur, car il peut indiquer une surcharge.
- **Erreur serveur 5xx :** le serveur ou une passerelle n'a pas pu achever une requête pourtant valide. `500` est une défaillance applicative générique, `502` indique habituellement une mauvaise réponse amont, `503` indique une indisponibilité temporaire et `504` indique un délai d'attente amont.

> **Un code de statut n'est pas un score SEO**
>
> Un `200` correct rend le contenu éligible au traitement ; il ne rend pas le contenu utile, rapide ou assuré d'être bien classé. Les codes de statut font partie de la fiabilité technique, pas d'un raccourci pour contourner la pertinence et la qualité.

## Une séquence d'audit pratique

### 1. Inventorier les URL par intention

Commencez par une liste d'URL représentative : pages de destination importantes, modèles, pages produit et catégorie, API, ressources, flux, `robots.txt` et sitemaps XML. Incluez les URL des journaux serveur, de Search Console, de l'analytique, des liens internes et du CDN. Un tableau de bord de statut qui vérifie uniquement la page d'accueil passera à côté des défaillances dans un chemin localisé, une route d'API ou une variante de cache.

Pour chaque URL, consignez la réponse depuis la périphérie publique et, si possible, depuis l'origine. Comparez le statut, l'URL finale, le temps de réponse, le type de contenu, le statut de cache, `Location`, `Cache-Control`, les directives canonical et robots. Un CDN peut renvoyer un code ou un corps différent de l'origine ; testez donc les deux couches lors d'une investigation.

### 2. Classer chaque réponse autre que 200

Pour une page déplacée, faites correspondre l'ancienne URL directement à la destination équivalente la plus proche avec une seule `301` ou `308` côté serveur. Évitez les chaînes allant d'une ancienne URL à une URL intermédiaire puis à l'URL finale. Mettez à jour les liens internes, les URL canoniques et les sitemaps pour qu'ils pointent directement vers la destination.

Pour une page supprimée, utilisez `404` ou `410` lorsqu'il n'existe pas de remplacement pertinent. Ne redirigez pas chaque URL supprimée vers la page d'accueil : cela dégrade l'expérience utilisateur et peut être interprété comme une soft 404. Une page d'erreur personnalisée utile convient, mais la réponse HTTP doit toujours rester une erreur.

Pour une indisponibilité, renvoyez une erreur serveur temporaire adaptée et rétablissez rapidement le service. Une `503` peut inclure `Retry-After` lorsqu'une estimation de nouvelle tentative utile est connue. Veillez à ce qu'un corps d'erreur ne soit pas accidentellement mis en cache longtemps dans le navigateur ou le CDN.

### 3. Vérifier le chemin de réponse, pas uniquement le code applicatif

Testez depuis plusieurs réseaux et régions avec une requête qui suit les redirections et une autre qui ne les suit pas. Confirmez que HTTPS, la normalisation de l'hôte, les règles de barre oblique finale, le routage des langues, l'authentification et le basculement d'origine produisent tous le résultat attendu. Vérifiez `HEAD` seulement en complément : de nombreux visiteurs et robots réels utilisent `GET`, et un serveur peut gérer les deux méthodes différemment.

La vérification générique suivante rend visibles les sauts de redirection :

```text
request https://www.example.test/old-page
inspect status, Location, cache headers, and final URL
repeat from a second region and with a crawler user agent
```

Pour un travail SEO spécifique, [SEO technique/GEO](/fr/visibility/seo-geo-technique) relie la fiabilité des réponses au comportement d'exploration et à l'analyse des journaux. Pour la diffusion, un [CDN managé](/fr/performance/cdn) peut faciliter la comparaison entre les réponses de périphérie et d'origine, tandis que [Multi CDN](/fr/performance/multicdn) ajoute un autre chemin de défaillance à observer indépendamment.

### 4. Surveiller les taux et les transitions

Suivez les décomptes de statut par nom d'hôte, modèle de chemin, méthode, région, user agent, statut de cache et version de mise en production. Alertez sur les changements de taux de `5xx`, `429`, boucles de redirection, chaînes de redirection, soft 404 et réponses `200` inattendues depuis des routes d'erreur connues. Associez le taux à la latence et à la saturation d'origine : une hausse des `504` peut être un problème de délai d'attente, tandis qu'une hausse des `502` peut être un problème de protocole ou de connexion amont.

Maintenez un budget d'erreur pour la visibilité dans les moteurs de recherche comme pour la disponibilité. Examinez les journaux de crawl et Search Console après des changements de routage ou d'application. Google recommande d'utiliser ses outils Crawl Stats et URL Inspection pour examiner les problèmes de disponibilité et de rendu, et indique que l'exploration peut reprendre progressivement une fois le site de nouveau sain.

### 5. Définir le retour arrière avant de modifier les codes

Déployez les changements de code de statut derrière une configuration ou une mise en production réversible. Gardez disponibles les règles de routage, la version applicative et la politique de cache précédentes. Si une nouvelle table de redirections augmente les erreurs, restaurez la dernière table connue comme fonctionnelle et purgez uniquement les réponses affectées. Si un nouveau gestionnaire d'erreurs provoque un pic de `5xx`, rétablissez la version applicative précédente. Ne résolvez pas un mauvais déploiement en renvoyant `200` pour chaque requête ; cela masque l'incident et crée du bruit d'indexation.

## Erreurs fréquentes

- Renvoyer `200` avec un modèle d'erreur, un résultat de recherche vide ou une charge utile d'API en échec.
- Utiliser `302` pour une migration d'URL permanente ou `301` pour une page de maintenance temporaire.
- Laisser plusieurs sauts de redirection après un changement de site ou d'hôte.
- Traiter `403` ou `401` comme un contrôle du taux d'exploration. Google documente plutôt `429`, et temporairement `503`, pour les situations de surcharge.
- Mettre en cache une réponse `404` ou `503` au-delà de ce que permet le plan de rétablissement.
- Vérifier uniquement l'origine alors que le CDN sert un ancien corps, un statut différent ou une erreur obsolète.
- Oublier qu'une réponse `2xx` n'est qu'un signal d'éligibilité. L'indexation dépend toujours du contenu renvoyé et d'autres systèmes de recherche.

Lisez le [guide de migration CDN](/fr/guides/cdn-migration) avant de modifier la couche qui génère ou met en cache vos réponses, et utilisez le [guide du budget de performance web](/fr/guides/web-performance-budgets) pour relier le temps de réponse à des limites de diffusion mesurables.

> Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le nommage des choses.

[Contacter Optimi](/fr/contact): Rendez chaque réponse intentionnelle — Échangez avec notre équipe sur les audits de codes de statut, la visibilité de l'exploration et une diffusion de périphérie résiliente.