Codes de statut HTTP pour le SEO : 200, 301, 404 et 503

Lorsqu'une URL disparaît, les ingénieurs demandent souvent à l'équipe SEO : « Quel statut cette page doit-elle renvoyer ? » La réponse ne se trouve pas seulement dans un tableau appris par cœur. Elle dépend de l'existence d'une ressource équivalente, du caractère temporaire ou permanent de l'interruption et de ce que vous voulez qu'un robot fasse à sa prochaine visite.

Un mauvais statut peut créer des pages d'erreur qui renvoient quand même 200, de longues chaînes de redirections ou des milliers de réponses 503 qui réduisent l'exploration. Le bon choix permet aux navigateurs, aux robots de recherche, aux caches, aux systèmes de supervision et aux équipes de maintenance de comprendre le même état.

Le statut HTTP est un message du serveur

Chaque fois qu'un navigateur ou un robot demande une URL, le serveur répond par un code de statut. Les cinq grandes classes sont :

• 1xx : information pendant le traitement.
• 2xx : la requête a été traitée avec succès.
• 3xx : une autre adresse ou une autre action est nécessaire.
• 4xx : la requête du client ne peut pas être satisfaite telle qu'elle a été envoyée.
• 5xx : le serveur ne peut pas traiter une requête valide.

Pour le SEO, le statut doit concorder avec le contenu visible. Une page qui indique « produit introuvable » tout en renvoyant 200 OK crée une soft 404. Une page complète qui répond par 500 donne aux robots une erreur dont le corps est ignoré. Le statut et le corps ne doivent pas raconter des histoires différentes.

Réponses 2xx : le succès ne garantit pas l'indexation

200 OK

200 signifie que le serveur a renvoyé une réponse réussie. Google peut transmettre le contenu aux traitements suivants, mais l'indexation n'est pas garantie. La page peut encore être exclue à cause d'un noindex, d'une canonique pointant ailleurs, d'un doublon, d'une valeur insuffisante ou d'autres signaux de qualité.

Ne renvoyez 200 que lorsqu'une URL fournit un vrai contenu. Ne l'utilisez pas pour garder techniquement « en vie » chaque adresse après la suppression d'un produit ou d'un article.

204 No Content

204 indique que la requête a réussi sans corps de réponse. Il convient à certaines API et actions qui n'exigent aucune représentation, pas à une page de destination destinée à la recherche. Une page HTML vide ne peut pas fournir un résultat utile simplement parce que son statut appartient à la classe des succès.

206 Partial Content

206 est courant lorsqu'un client demande une plage d'une vidéo ou d'un gros fichier. Ce n'est pas la valeur par défaut normale d'un document HTML. Si un CDN ou un proxy renvoie soudain 206 pour toutes les pages, inspectez les règles de requêtes par plage et de cache.

Réponses 3xx : déplacement volontaire

301 Moved Permanently

Utilisez 301 lorsqu'une adresse a été déplacée définitivement et qu'une destination équivalente existe. Cas typiques :

• Modification du slug d'un article.
• Passage de HTTP à HTTPS.
• Fusion d'articles répondant à la même intention.
• Remplacement d'une structure de catégories.
• Redirection d'un ancien produit vers un successeur réellement équivalent.

La destination doit correspondre à l'ancien besoin. Rediriger un produit abandonné vers la page d'accueil ou une catégorie trop large frustre les visiteurs et peut être traité comme une soft 404.

302 Found

302 convient à un déplacement temporaire : expérimentation courte, page de remplacement pendant une maintenance, routage limité dans le temps ou campagne qui reviendra à l'URL d'origine. Si le déplacement est devenu permanent, remplacez la réponse par 301 afin que son objectif soit sans ambiguïté pour tous les clients.

Google peut traiter plusieurs types de redirections de façon similaire après avoir examiné des signaux plus larges. Choisir le bon statut reste cependant important pour les navigateurs, les caches, les autres clients et les futurs mainteneurs.

303 See Other

303 suit souvent une requête POST et envoie le client vers une page de résultat en GET. Un formulaire envoyé qui mène à une page de confirmation en est un exemple courant. C'est un flux applicatif plutôt que l'outil principal d'une migration d'URL SEO.

307 et 308

307 Temporary Redirect et 308 Permanent Redirect conservent la méthode HTTP pendant le déplacement. 308 est permanent et 307 temporaire. Ils peuvent servir pour des migrations GET ordinaires, mais les ingénieurs doivent comprendre la conservation de la méthode avant de les appliquer à des formulaires et à des API.

Chaînes de redirections : une décision étirée sur plusieurs générations d'URL

Un article a commencé en A, est passé en B puis en C. Lorsque A redirige encore vers B et B vers C, chaque visite demande deux sauts. Un site ancien peut accumuler des chaînes de cinq ou six étapes que personne n'a conçues délibérément.

Les coûts comprennent :

• Plus de latence pour les visiteurs et les robots.
• Des requêtes serveur supplémentaires.
• Un débogage plus difficile des canoniques et de l'analytics.
• Un plus grand risque de saut en échec ou de boucle.
• Des liens internes qui conservent une architecture obsolète.

Chaque ancienne adresse doit pointer directement vers la destination actuelle. Utilisez le Redirect Chain Checker pour inspecter chaque saut, statut, boucle et l'URL finale. Mettez ensuite à jour les liens internes, les canoniques et les sitemaps pour utiliser l'adresse finale au lieu de dépendre indéfiniment des redirections.

Réponses 4xx : problèmes d'adresse ou d'accès

400 Bad Request

Si un robot reçoit une réponse différente, examinez la requête réelle et les journaux autorisés du serveur ou de la périphérie. La détection publique de Cloudflare ne révèle pas les règles WAF, limites d’en-têtes ou politiques du compte.

401 Unauthorized

401 demande une authentification. Il convient aux espaces connectés, aux API privées et aux documents à permissions. Un contenu destiné à se positionner ne peut pas aussi exiger qu'un robot se connecte. N'utilisez pas 401 pour contrôler le rythme d'exploration ; traitez directement la capacité du serveur et l'architecture des URL.

403 Forbidden

403 indique que le serveur a compris mais refuse la requête. Des réglages CDN, WAF et anti-bot trop agressifs peuvent le renvoyer à tort à des robots légitimes. Si des pages publiques commencent à sortir de l'index, comparez les logs par heure, user agent et IP vérifiée au lieu de vous fier à la seule chaîne user agent.

404 Not Found

404 est correct lorsqu'une ressource n'existe pas et n'a pas de remplacement équivalent. Toutes les 404 ne sont pas des « erreurs SEO » nécessitant une redirection. Une adresse mal saisie, un produit retiré ou un article de test supprimé peut normalement renvoyer 404.

Une page 404 utile devrait :

• Expliquer brièvement que la ressource est indisponible.
• Conserver la navigation et la recherche lorsque c'est approprié.
• Suggérer des zones liées sans forcer une redirection.
• Continuer à renvoyer le statut 404, et non 200.

410 Gone

410 indique explicitement que la ressource a été supprimée volontairement. Pour Google Search, des réponses 404 et 410 persistantes entraînent toutes deux le retrait de l'URL ou sa non-indexation. Choisissez 410 lorsque l'application sait que la ressource a pris fin et 404 lorsqu'elle est simplement absente. Convertir des milliers de 404 valides en 410 dans l'espoir d'un retrait plus rapide n'a guère d'intérêt.

429 Too Many Requests

429 indique qu'un client a envoyé trop de requêtes. Google le traite comme un signal de surcharge du serveur et peut réduire temporairement l'exploration. Si un limiteur de débit renvoie fréquemment 429 aux robots, revoyez les quotas, les caches et les règles de vérification. Supprimer toutes les limites n'est pas la solution ; une capacité fiable l'est.

Réponses 5xx : le serveur est en échec

500 Internal Server Error

500 représente une défaillance d'application ou de serveur non spécifiée. Des erreurs transitoires occasionnelles arrivent, mais un taux élevé sur de nombreuses URL révèle un problème de déploiement, de base de données, de dépendance ou de capacité.

502 Bad Gateway

502 apparaît souvent lorsqu'un proxy ou un CDN reçoit une réponse invalide d'un service amont. Vérifiez la santé du serveur d'application, les délais d'expiration entre les couches, le DNS interne et les limites de connexions.

503 Service Unavailable

503 convient à une maintenance courte ou à une surcharge temporaire. Un en-tête Retry-After peut indiquer aux clients quand réessayer. Une page de maintenance doit renvoyer 503, pas 200 ; sinon les systèmes de recherche peuvent rencontrer sur tout le site le même contenu « en maintenance » comme s'il était valide.

Ne laissez pas 503 en place pendant des jours lorsque le site est réellement fermé ou que la ressource a définitivement disparu. Des erreurs serveur persistantes peuvent finir par retirer des URL indexées et réduire l'activité d'exploration sur tout le site.

504 Gateway Timeout

504 signifie qu'une passerelle a trop attendu son service amont. Recherchez des requêtes de base de données lentes, des API dépendantes, des échecs de cache, des workers épuisés et des délais d'expiration incohérents entre CDN et origine.

Un tableau de décision pour les statuts

Le tableau est un point de départ. En e-commerce, un produit temporairement en rupture de stock peut quand même renvoyer 200 avec les informations produit, la disponibilité et des alternatives. Un produit définitivement retiré dont le successeur est quasi équivalent peut utiliser 301 ; sans remplacement pertinent, 404 ou 410 est plus honnête.

Soft 404 : statut de succès, contenu en échec

Les cas de soft 404 comprennent souvent :

• Un ensemble de produits vide qui renvoie 200.
• Chaque URL mal formée qui affiche la page d'accueil.
• Des pages de recherche interne sans résultat qui restent indexables.
• Un contenu supprimé qui ne laisse qu'un en-tête et un pied de page.
• Des URL sans rapport qui redirigent vers une catégorie large.

Consultez le rapport d'indexation des pages dans Search Console et échantillonnez les URL concernées. N'ajoutez pas quelques phrases à un modèle d'erreur uniquement pour éviter la classification. Renvoyez le statut honnête ou fournissez un contenu qui répond réellement au besoin d'origine.

Robots.txt ne peut pas remplacer un statut de réponse

Interdire /old-page dans robots.txt indique seulement à un robot qu'il ne peut pas récupérer le corps de la page ; celle-ci peut donc encore apparaître dans les résultats de recherche sans que l'on sache si elle a été déplacée, a disparu ou exige une authentification ; utilisez le Robots.txt Checker pour vérifier.

Si l'URL a été déplacée, redirigez-la. Si elle a disparu, renvoyez 404 ou 410. Si elle reste disponible mais ne doit pas être indexée, laissez les robots y accéder et lire noindex. Le Robots.txt Checker repère les blocages accidentels, mais le cycle de vie de l'URL relève toujours de la réponse.

Auditer les statuts par modèle, pas quelques pages soignées

Une page d'accueil qui renvoie 200 en dit peu sur la santé d'un catalogue. Échantillonnez et agrégez par modèle :

1. Page d'accueil et navigation principale.
2. Catégories, pagination et filtres.
3. Produits en stock, temporairement indisponibles et retirés.
4. Articles récents, anciens, renommés et supprimés.
5. Variantes de paramètres, de casse, de barre oblique et de nom d'hôte.
6. Sitemaps, robots.txt, images clés et fichiers importants.

Comparez chaque statut avec sa canonique, ses directives robots, son appartenance au sitemap et ses liens internes. Une URL en 301 ne devrait pas rester dans un sitemap. Une 404 ne devrait pas recevoir des milliers de liens internes. Une page 200 destinée à l'indexation ne devrait pas avoir de canonique ailleurs.

Utilisez le SEO Checker pour inspecter une réponse représentative et ses signaux on-page, puis lancez un audit SEO gratuit pour trouver les défauts répétés au niveau des modèles.

Surveiller avant que le trafic ne chute

Créez des alertes sur le taux de 5xx, le temps de réponse et les changements de statut des URL critiques. Après chaque déploiement ou migration, lancez un test de fumée couvrant :

• La page d'accueil, la connexion et les pages de revenus.
• Une URL représentative de chaque modèle.
• Robots.txt et l'index de sitemaps.
• Les redirections depuis d'anciennes adresses.
• Un chemin inexistant pour confirmer une vraie 404.

Les logs du serveur doivent conserver le statut, le chemin, la durée, le user agent et l'identifiant de requête assez longtemps pour permettre des comparaisons avant et après. Lorsqu'une panne n'affecte qu'un robot ou une région, les logs répondent généralement plus vite que le rechargement d'une page depuis un seul ordinateur portable.

Conclusion

Un code de statut HTTP est un contrat compact entre serveur et client. Les systèmes de recherche s'en servent pour comprendre si un contenu existe, a été déplacé, a disparu ou est temporairement indisponible. Choisissez le code selon le véritable cycle de vie de l'URL, gardez-le cohérent avec le corps de la page et nettoyez sitemaps et liens internes après chaque déplacement.

Ne redirigez pas chaque erreur vers la page d'accueil, ne renvoyez pas 200 pour des pages vides et n'utilisez pas robots.txt pour masquer un cycle de vie non tranché. Un système de statuts clair laisse moins de place aux conjectures pour les visiteurs, les robots et les équipes d'exploitation.

Références : Google Search Central sur les codes de statut HTTP et l'exploration et conseils de Google sur les redirections.