Status codes HTTP : guide SEO complet (2xx à 5xx)

Un site e-commerce de 22 000 pages migre son catalogue vers une nouvelle arborescence. Trois semaines plus tard, le trafic organique a chuté de 38 %. La cause : 4 200 anciennes URLs retournent un 302 au lieu d'un 301, et 1 800 pages supprimées renvoient un 200 avec un body vide — des soft 404 que Googlebot met des semaines à comprendre. Chaque status code HTTP est un signal direct envoyé aux moteurs de recherche. Mal configuré, il détruit l'équité de liens, gaspille le crawl budget et provoque des déindexations silencieuses.

Les codes 2xx : quand tout va bien (en apparence)

200 OK — le seul code que vous voulez en masse

Un 200 signifie que le serveur a traité la requête et retourne le contenu demandé. C'est le status code cible pour toute page que vous souhaitez indexer. Mais un 200 ne garantit pas que le contenu est correct.

Le piège classique : une page produit épuisé qui retourne un 200 avec le message "Ce produit n'est plus disponible" et aucun contenu utile. Pour l'utilisateur, c'est clair. Pour Googlebot, c'est une page indexable avec un contenu quasi vide — un soft 404 que Google finira par détecter et signaler dans la Search Console, mais parfois avec plusieurs semaines de retard.

Vérifiez vos 200 avec un crawl Screaming Frog filtré sur "word count < 50" combiné au status code 200. Toute page qui matche mérite une investigation.

204 No Content — le cas API

Le 204 indique une réponse réussie sans body. Aucun intérêt pour le SEO — Googlebot n'a rien à indexer. Si vous le rencontrez sur une URL censée servir du HTML, vous avez un bug côté serveur. Ce code est légitime uniquement pour les endpoints API (suppression de ressource, confirmation d'action).

206 Partial Content — le piège du range request

Le 206 intervient quand le client demande une portion du contenu via le header Range. Les CDN l'utilisent pour le streaming vidéo ou les téléchargements de fichiers volumineux. Googlebot peut envoyer des range requests sur des fichiers volumineux. Si votre serveur ne gère pas correctement le fallback vers un 200 quand le header Range est absent, certaines ressources peuvent être incomplètement crawlées.

Les codes 3xx : redirections et transfert de signaux

C'est ici que se joue l'essentiel des problèmes SEO post-migration. Chaque type de redirection envoie un signal différent à Google sur la permanence du changement.

301 Moved Permanently — le standard pour les migrations

Le 301 indique un déplacement définitif. Google transfère la quasi-totalité des signaux de ranking (PageRank, ancres, historique) vers l'URL de destination. C'est le code à utiliser pour :

Toute migration d'URL permanente
La consolidation de pages dupliquées
Le changement de domaine
La normalisation avec ou sans trailing slash

Configuration Nginx pour une migration d'arborescence e-commerce :

# Migration catégorie : /shop/category/shoes → /catalogue/chaussures
location ~ ^/shop/category/(.+)$ {
    return 301 /catalogue/$1;
}

# Mapping exact pour les slugs traduits
map $uri $new_uri {
    /shop/category/shoes      /catalogue/chaussures;
    /shop/category/bags       /catalogue/sacs;
    /shop/category/watches    /catalogue/montres;
    # ... 340 autres mappings
}

server {
    if ($new_uri) {
        return 301 $new_uri;
    }
}

Un point critique souvent négligé : les chaînes de redirections. Si /page-a redirige en 301 vers /page-b, et que /page-b redirige en 301 vers /page-c, Googlebot suit la chaîne (jusqu'à 10 sauts selon la documentation officielle), mais chaque saut dilue potentiellement le signal et gaspille du crawl budget. Sur un site de 20 000+ pages, ces chaînes s'accumulent vite après plusieurs migrations successives.

Diagnostic avec Screaming Frog : lancez un crawl en mode "Spider", puis filtrez par "Redirect Chains" dans l'onglet Reports. Toute chaîne de 3+ sauts doit être aplatie.

302 Found — le mauvais réflexe

Le 302 signale un déplacement temporaire. En théorie, Google ne devrait pas transférer les signaux de ranking. En pratique, Google a longtemps traité les 302 comme des 301 quand le contexte suggérait une redirection permanente — John Mueller l'a confirmé à plusieurs reprises. Mais ce comportement n'est pas garanti et dépend de l'interprétation algorithmique.

Le problème réel d'un 302 mal utilisé : Google continue de crawler l'ancienne URL et la conserve dans l'index pendant une durée indéterminée. Sur un site à fort volume, ça signifie des milliers de crawls inutiles sur des URLs obsolètes, au détriment des nouvelles pages.

Cas légitime du 302 : un A/B test temporaire, une maintenance de page qui sera rétablie sous 48h, une redirection géolocalisée qui change selon l'IP du visiteur.

307 et 308 — les variantes HTTP/1.1

Le 307 est l'équivalent strict du 302 en HTTP/1.1 : il préserve la méthode HTTP (un POST reste un POST). Le 308 est l'équivalent strict du 301. Pour le SEO, la différence est négligeable sur des requêtes GET — Googlebot crawle en GET. Ces codes sont pertinents pour vos API ou vos formulaires, pas pour votre stratégie de redirections SEO. Si vous utilisez HTTP/2 ou HTTP/3, les 308 sont techniquement plus corrects, mais les 301 fonctionnent de manière identique côté SEO.

Le méta refresh — la fausse redirection

Techniquement, ce n'est pas un status code HTTP mais un comportement côté client. Google le traite comme une redirection, mais avec des réserves. Un <meta http-equiv="refresh" content="0;url=..."> avec un délai de 0 est traité comme un 301. Un délai supérieur à 5 secondes n'est pas traité comme une redirection du tout. Évitez cette approche — elle est fragile, dépendante du rendu JavaScript pour les SPA, et envoie un signal ambigu.

Les codes 4xx : erreurs client et gestion de l'obsolescence

404 Not Found — le code le plus mal géré

Un 404 légitime n'est pas un problème SEO. Google le dit explicitement : les 404 ne pénalisent pas votre site. Le problème survient quand un 404 frappe une page qui avait des backlinks, du trafic organique, ou de l'équité de lien interne.

Voici le processus de décision :

La page supprimée avait-elle des backlinks entrants ? → 301 vers la page la plus pertinente
La page n'avait aucun backlink et aucun trafic ? → 404 ou 410, au choix
La page fait partie d'un contenu définitivement retiré (CGU obsolètes, produit rappelé) ? → 410

Le vrai danger, c'est le soft 404 : une page qui retourne un 200 mais affiche "Page introuvable" ou un contenu vide. Google détecte ce pattern via son algorithme de classification de contenu, mais le délai de détection peut atteindre plusieurs semaines. Pendant ce temps, Googlebot continue de crawler ces URLs, gaspillant votre crawl budget.

Script Node.js pour auditer les soft 404 en bulk :

import fetch from 'node-fetch';
import * as cheerio from 'cheerio';
import { createReadStream } from 'fs';
import { parse } from 'csv-parse';

interface AuditResult {
  url: string;
  statusCode: number;
  wordCount: number;
  hasSoft404Signal: boolean;
}

const SOFT_404_PATTERNS = [
  /page\s*(not|non)\s*(found|trouvée)/i,
  /erreur\s*404/i,
  /cette\s*page\s*n.*existe/i,
  /product\s*(is\s*)?(no\s*longer|unavailable|discontinued)/i,
];

async function auditUrl(url: string): Promise<AuditResult> {
  const res = await fetch(url, {
    headers: { 'User-Agent': 'SEO-Audit-Bot/1.0' },
    redirect: 'manual',
  });

  const html = await res.text();
  const $ = cheerio.load(html);
  const bodyText = $('body').text().replace(/\s+/g, ' ').trim();
  const wordCount = bodyText.split(/\s+/).length;

  const hasSoft404Signal =
    SOFT_404_PATTERNS.some((p) => p.test(bodyText)) || wordCount < 50;

  return {
    url,
    statusCode: res.status,
    wordCount,
    hasSoft404Signal,
  };
}

// Lecture d'un export Screaming Frog CSV
async function auditFromCsv(filePath: string): Promise<void> {
  const results: AuditResult[] = [];
  const parser = createReadStream(filePath).pipe(
    parse({ columns: true, delimiter: ',' })
  );

  for await (const row of parser) {
    if (row['Status Code'] === '200') {
      const result = await auditUrl(row['Address']);
      if (result.hasSoft404Signal) {
        console.warn(`⚠ SOFT 404: ${result.url} (${result.wordCount} mots)`);
      }
      results.push(result);
    }
  }

  const soft404Count = results.filter((r) => r.hasSoft404Signal).length;
  console.log(`\nAudit terminé: ${soft404Count}/${results.length} soft 404 détectés`);
}

auditFromCsv('./screaming-frog-export.csv');

410 Gone — le signal d'obsolescence définitive

Le 410 dit explicitement à Googlebot : "cette ressource a existé, elle est définitivement supprimée, ne revenez plus". Google traite le 410 de manière plus agressive que le 404 pour la désindexation. Sur un 404, Googlebot revient périodiquement vérifier si la page est revenue. Sur un 410, il la supprime plus rapidement de l'index et réduit la fréquence de re-crawl.

Utilisez le 410 pour les pages que vous ne restaurerez jamais : offres d'emploi pourvues, événements passés, produits définitivement retirés du catalogue. Configuration Apache :

# Dans .htaccess — produits retirés définitivement
<IfModule mod_rewrite.c>
    RewriteEngine On

    # Liste de produits retirés
    RewriteRule ^product/discontinued-widget-x42$ - [G,L]
    RewriteRule ^product/recalled-device-z19$ - [G,L]

    # Pattern pour une catégorie entière supprimée
    RewriteRule ^archive/promotions-2023/(.*)$ - [G,L]
</IfModule>

# Alternative avec Nginx
location = /product/discontinued-widget-x42 {
    return 410;
}

location ~ ^/archive/promotions-2023/ {
    return 410;
}

Le flag [G] dans Apache signifie "Gone" — il retourne un 410.

403 Forbidden vs 401 Unauthorized

Le 403 indique que le serveur comprend la requête mais refuse de la servir. Le 401 demande une authentification. Côté SEO, les deux empêchent l'indexation — Googlebot ne s'authentifie pas. Si ces codes apparaissent sur des pages qui devraient être publiques, vous avez un problème de configuration serveur ou de contrôle d'accès.

Un cas fréquent : après un déploiement, les permissions fichiers changent et certains répertoires deviennent inaccessibles. Le serveur retourne un 403 sur toutes les images d'un répertoire /uploads/, ce qui casse les featured snippets et les résultats images.

429 Too Many Requests — le rate limiting qui tue le crawl

Le 429 est un signal de rate limiting. Googlebot le respecte et réduit sa vitesse de crawl. Sur un site de 50 000 pages où le serveur envoie des 429 parce que le rate limiter est trop agressif, le crawl complet peut passer de 3 jours à 3 semaines.

Vérifiez dans la Search Console (section "Paramètres > Statistiques sur l'exploration") si Google rapporte des réponses 429. Si votre WAF (Cloudflare, AWS WAF) bloque Googlebot, ajoutez une exception pour les user agents Google vérifiés — mais validez l'IP source via DNS inverse pour éviter le spoofing. Consultez la documentation sur la configuration CDN pour les détails.

Les codes 5xx : erreurs serveur et crawl budget

500 Internal Server Error — l'urgence silencieuse

Un 500 sporadique ne pose pas de problème immédiat. Google re-crawle l'URL plus tard. Mais des 500 persistants sur un segment du site déclenchent un mécanisme de protection : Googlebot réduit sa fréquence de crawl globale, pas seulement sur les URLs en erreur.

Scénario concret : un média en ligne avec 18 000 articles. Un déploiement introduit un bug dans le template de la section "Sport" (2 400 pages). Le rendu côté serveur échoue sur ces pages à cause d'un composant React qui appelle une API dépréciée. Résultat : 2 400 URLs retournent un 500. En 5 jours, Google a réduit le crawl rate de 40 % sur l'ensemble du domaine. Les nouvelles pages de la section "Économie" ne sont plus crawlées dans l'heure mais sous 3-4 jours. Pour un site d'actualité, ce délai est fatal.

La détection de ce type de régression est exactement le cas d'usage d'un monitoring continu. Un outil comme Seogard détecte les pics de 5xx en temps réel et alerte avant que l'impact sur le crawl budget ne se propage à l'ensemble du site.

502 Bad Gateway et 504 Gateway Timeout

Le 502 signale que votre reverse proxy (Nginx, HAProxy) n'a pas reçu de réponse valide du serveur applicatif en amont. Le 504 signifie que le serveur upstream n'a pas répondu dans le délai imparti. Les deux sont des symptômes d'infrastructure, pas de code applicatif.

Causes fréquentes :

Pool PHP-FPM saturé (toutes les workers sont occupées)
Timeout Node.js sur des pages à rendu lourd (SSR avec appels API multiples)
Serveur upstream down après un déploiement

Pour le SEO, l'impact est identique au 500 : Googlebot reçoit une erreur et ralentit. La différence est dans le diagnostic — un 502 pointe vers l'infrastructure, pas vers le code.

Commande rapide pour monitorer les 5xx dans vos access logs Nginx en temps réel :

# Comptage des 5xx par minute sur les dernières 24h
awk '$9 ~ /^5[0-9][0-9]$/ {print $4}' /var/log/nginx/access.log \
  | cut -d: -f1-3 \
  | sort | uniq -c | sort -rn | head -20

# Filtre live pour voir les 5xx en temps réel
tail -f /var/log/nginx/access.log | awk '$9 ~ /^5[0-9][0-9]$/ {print $0}'

# Vérification spécifique du user-agent Googlebot
grep "Googlebot" /var/log/nginx/access.log \
  | awk '$9 ~ /^5[0-9][0-9]$/ {print $7, $9}' \
  | sort | uniq -c | sort -rn | head -30

503 Service Unavailable — le code de maintenance SEO-friendly

Le 503 est le seul code 5xx que vous devriez utiliser intentionnellement. Il signale une indisponibilité temporaire. Combiné au header Retry-After, il indique à Googlebot quand revenir.

C'est le code à retourner pendant une maintenance planifiée. Contrairement au 500, un 503 avec Retry-After ne dégrade pas votre crawl budget à long terme — à condition que la maintenance dure moins de quelques jours. Au-delà de 72h de 503 continu, Google commence à considérer les URLs comme potentiellement mortes.

Configuration Nginx pour une page de maintenance avec 503 :

# Fichier de flag pour activer/désactiver la maintenance
# Créez /etc/nginx/maintenance.flag pour activer
# Supprimez le fichier pour désactiver

server {
    listen 443 ssl http2;
    server_name www.monsite-ecommerce.fr;

    set $maintenance 0;

    if (-f /etc/nginx/maintenance.flag) {
        set $maintenance 1;
    }

    # Exclusions : IP de l'équipe + Googlebot (pour tests)
    if ($remote_addr = "203.0.113.42") {
        set $maintenance 0;
    }

    # Ne pas bloquer les assets statiques
    location ~* \.(css|js|png|jpg|svg|ico)$ {
        # Servir normalement les assets
        try_files $uri =404;
    }

    location / {
        if ($maintenance = 1) {
            return 503;
        }

        # Config habituelle
        proxy_pass http://backend;
    }

    error_page 503 @maintenance;

    location @maintenance {
        add_header Retry-After 3600 always;
        add_header Content-Type "text/html; charset=utf-8" always;
        root /var/www/maintenance;
        rewrite ^(.*)$ /maintenance.html break;
    }
}

Point subtil : ne retournez jamais un 200 sur votre page de maintenance. C'est l'erreur la plus fréquente. Si Googlebot crawle votre site pendant la maintenance et reçoit un 200 avec "Site en maintenance, revenez bientôt" sur chaque URL, il indexe ce contenu pauvre à la place de vos vraies pages. La récupération peut prendre des semaines.

Scénario de migration : 22 000 pages, de Magento 1 à Shopify

Un retailer mode avec 22 000 URLs indexées migre de Magento 1 vers Shopify. L'arborescence change complètement :

/catalog/category/robes.html → /collections/robes
/catalog/product/view/id/4521/robe-noire-soie.html → /products/robe-noire-soie
3 200 pages produits supprimées (fin de collection)
180 pages de contenu CMS restructurées

Plan de redirection par status code

Segment	Volume	Status code	Cible
Produits actifs migrés	12 400	301	Nouvelle URL produit
Catégories restructurées	340	301	Nouvelle URL collection
Produits supprimés avec backlinks	800	301	Collection parente
Produits supprimés sans backlink	2 400	410	—
Pages CMS migrées	180	301	Nouveau chemin
URLs techniques Magento (/checkout, /customer)	~500	410	—

Les erreurs commises et leur impact

Semaine 1 post-migration : L'agence en charge a configuré les redirections produits via l'app Shopify "URL Redirect". Problème : l'app ajoute automatiquement un trailing slash sur les URLs cibles, créant des chaînes /old-url → 301 → /products/new-url/ → 301 → /products/new-url (Shopify normalise sans trailing slash). Chaque produit subit 2 redirections au lieu d'une.

Semaine 2 : 4 200 URLs de produits supprimés retournent un 404 au lieu du 410 prévu — l'agence a oublié de configurer les 410. Pas critique immédiatement, mais Googlebot continue de re-crawler ces 4 200 URLs régulièrement.

Semaine 3 : Le trafic organique a chuté de 38 %. Diagnostic Search Console :

"Pages avec des redirections" : 12 400 URLs signalées avec chaînes de redirections
"Pages introuvables (404)" : 4 200 URLs
Taux de crawl réduit de 30 % par rapport à la période pré-migration

Correction : Aplatissement de toutes les chaînes de redirections en un seul 301 direct, passage des 2 400 produits sans backlink en 410, et mise en place des 301 des 800 produits supprimés avec backlinks vers leurs collections parentes. Récupération du trafic en 6 semaines — dont 3 semaines de délai incompressible pour que Google re-traite les signaux.

Ce scénario illustre parfaitement pourquoi le monitoring des cinq portes de l'infrastructure (crawl, rendu, indexation) doit être automatisé. Un contrôle manuel post-migration sur 22 000 URLs est irréaliste.

Diagnostiquer et monitorer les status codes à l'échelle

Search Console : le minimum vital

L'outil "Inspection d'URL" dans la Search Console montre le status code vu par Googlebot. Le rapport "Pages" (anciennement "Couverture") regroupe les URLs par type d'erreur : soft 404, 404, erreur serveur, bloquée par robots.txt.

Limitation majeure : la Search Console ne montre que les problèmes que Google considère significatifs. Si 50 URLs retournent un 500 sur 22 000, elles peuvent ne pas apparaître dans le rapport si Google les considère comme non importantes. Ce n'est pas un monitoring — c'est un rapport post-mortem.

Chrome DevTools pour le diagnostic unitaire

L'onglet Network de Chrome DevTools affiche le status code de chaque requête. Filtrez par "Doc" pour voir uniquement les requêtes de document HTML. Utile pour diagnostiquer les redirections : vous voyez la chaîne complète avec les status codes intermédiaires.

Astuce avancée : utilisez curl avec le flag -I pour vérifier les headers sans télécharger le body, et -L pour suivre les redirections :

# Vérifier le status code et les headers de redirection
curl -I -L -s -o /dev/null -w "URL: %{url_effective}\nCode: %{http_code}\nRedirects: %{num_redirects}\nTime: %{time_total}s\n" \
  "https://www.monsite.fr/ancienne-url"

# Voir chaque étape de la chaîne de redirections
curl -v -L "https://www.monsite.fr/ancienne-url" 2>&1 | grep -E "^< HTTP|^< [Ll]ocation"

Screaming Frog pour l'audit en bulk

Configurez un crawl en "Spider" mode avec les options :

"Always follow redirects" activé
"Crawl All Subdomains" désactivé (pour rester sur votre domaine)
"Respect Robots.txt" activé (pour voir ce que Googlebot voit)

Après le crawl, utilisez l'onglet "Response Codes" pour segmenter par famille (2xx, 3xx, 4xx, 5xx). L'export "Redirect Chains" identifie automatiquement les chaînes de plus de 2 sauts.

Pour les sites de 15 000+ pages, préférez le mode "List" : importez vos URLs depuis un sitemap XML ou un export de la Search Console, et Screaming Frog vérifie le status code de chaque URL sans crawler le reste du site. Le crawl est plus rapide et plus ciblé.

Log analysis : la vérité du terrain

L'analyse des logs serveur est le seul moyen de voir exactement ce que Googlebot reçoit. Les rapports Search Console sont agrégés et filtrés. Les logs sont exhaustifs.

Filtrez vos access logs par user agent Googlebot et agrégez par status code et par jour. Un pic de 5xx sur 2 jours, invisible dans la Search Console, peut expliquer une baisse de crawl rate 10 jours plus tard. La corrélation temporelle est la clé du diagnostic — et c'est précisément là où les outils de monitoring automatisé surpassent l'analyse manuelle.

Edge cases et subtilités que les guides classiques ignorent

Le 404 qui protège votre crawl budget

Sur un site attaqué par du negative SEO ou du scraping générant des milliers d'URLs inexistantes (paramètres aléatoires, chemins inventés), retourner un 404 rapidement est mieux que de laisser votre serveur générer une réponse 200 complexe. Configurez votre serveur pour retourner un 404 léger (page HTML minimale, pas de rendu SSR) sur les patterns d'URLs manifestement invalides.

Le 301 qui boucle

Une redirection circulaire (A → B → A) retourne un ERR_TOO_MANY_REDIRECTS côté navigateur. Googlebot abandonne après 10 sauts. Mais le vrai problème est que chaque crawl de A ou B consomme du budget sans jamais aboutir à une page indexable. Les boucles sont fréquentes après une fusion de règles de redirection entre .htaccess, configuration serveur, et application (middleware Express, Next.js redirects).

Le 200 avec un canonical vers une autre page

Ce n'est pas une redirection HTTP, mais c'est un signal de consolidation. Google le traite comme une suggestion, pas une directive. Si le contenu des deux pages est significativement différent, Google peut ignorer le canonical. Ce pattern est légitime pour les variantes de pages (pagination, filtres), mais ne doit pas remplacer un vrai 301 quand la page source n'a plus de raison d'exister.

Pour approfondir l'interaction entre les données structurées et les status codes : un 301 sur une page qui contient du JSON-LD transfère le contenu structuré vers la page de destination, à condition que celle-ci contienne également des données structurées valides. Les rich results ne survivent pas à une redirection vers une page sans markup structuré.

Chaque status code HTTP est un micro-contrat entre votre serveur et les moteurs de recherche. Un 301 dit "faites-moi confiance, le contenu a déménagé définitivement". Un 503 dit "revenez dans une heure, tout ira bien". Un 200 sur une page vide dit... rien de cohérent, et c'est précisément le problème. La rigueur dans la configuration des status codes, combinée à un monitoring automatisé qui détecte les régressions avant qu'elles n'impactent votre crawl budget, est la base invisible sur laquelle repose toute stratégie SEO technique durable.