Code HTTP 200

Ce que vérifie ce contrôle

Envoie une requête GET à l’URL auditée et lit le code de statut HTTP final. Le contrôle ne passe que sur 200 OK. Il signale :

• les redirections 3xx (l’URL n’est pas la canonique)
• les erreurs 4xx (404 page introuvable, 410 disparue, 403 interdite)
• les erreurs 5xx (crash serveur, timeout de passerelle)

Le crawler suit un petit nombre de redirections afin de pouvoir vous indiquer également le statut final en bout de chaîne.

Pourquoi c’est important

Les moteurs de recherche et les crawlers IA traitent les réponses non-200 comme un “n’indexez pas cette URL”.

• 301/302 — l’URL ne se classera pas ; la cible de la redirection le fera. Si vous avez partagé example.com/old-post et qu’il redirige en 301 vers example.com/new-post, chaque backlink, chaque partage social, chaque featured snippet pointe vers une URL que Google retirera de son index en quelques semaines.
• 404 / 410 — l’URL est retirée de l’index. Si c’est arrivé par accident (faute dans une règle de redirection, slash final manquant, page supprimée mais encore liée), vous perdez du trafic silencieusement.
• 500 / 502 / 503 / 504 — Google réessaie, puis désindexe après quelques jours d’échecs. Pire, Googlebot réduit le budget de crawl pour tout le domaine.

Une page qui renvoie autre chose qu’un 200 est invisible.

Comment corriger

D’abord, voyez exactement ce que renvoie le serveur. curl -I montre la chaîne complète :

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Ajoutez -L et -w "%{http_code} -> %{redirect_url}\n" pour cartographier chaque saut. Si vous voyez plusieurs lignes 30x avant le 200 final, vous avez une chaîne de redirection — à corriger également.

Si l’URL devrait renvoyer 200 mais renvoie 301/302 :

Les coupables courants :

• Décalage WWW ou slash final — example.com/page redirige en 301 vers example.com/page/. Choisissez une forme canonique (avec ou sans slash) et liez-y de manière cohérente. Ne pointez pas en interne vers la forme qui redirige.
• Mise à niveau HTTPS — http://example.com/page redirige en 301 vers https://example.com/page. Attendu, mais assurez-vous que tous les liens internes et le sitemap utilisent HTTPS pour que les crawlers ne touchent jamais à la redirection. Voir Rediriger HTTP vers HTTPS.
• Redirection de locale sur le chemin racine — / redirige en 302 vers /en/ selon Accept-Language. Googlebot crawle depuis les États-Unis avec en-US, donc / devient une redirection vers /en/. Soit faites en sorte que / serve directement le contenu anglais (avec hreflang pour les autres locales), soit utilisez un 302 plus x-default hreflang.

Si l’URL renvoie 404 par accident :

• Vérifiez la configuration du routage (nginx try_files, Next.js [...slug].tsx, Astro getStaticPaths).
• Vérifiez la sensibilité à la casse — /About et /about sont des URL différentes sur les serveurs Linux.
• Vérifiez la base — une page CMS définie en “brouillon” renvoie 404 dans la plupart des templates.

Si la page a vraiment disparu, renvoyez 410 Gone plutôt que 404 — Google désindexe les 410 environ deux fois plus vite. Mettez en place une page 404 personnalisée pour que la réponse reste utile aux humains.

Si l’URL renvoie 5xx :

C’est un problème de serveur, pas de configuration. Consultez les logs applicatifs à l’horodatage de l’audit MetricSpot. Causes courantes : pool de connexions à la base saturé, dépassement mémoire sur une fonction serverless, API tierce dont dépend la page en timeout.

Recettes :

# nginx — 200 explicite pour une route, sans redirection
location = /pricing {
  try_files /pricing.html =404;
}

// Express — renvoyer 410 pour des URL retirées définitivement
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — renvoyer 410 depuis un segment de route
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // renvoie 404 par défaut
  // ...
}

Pour les sites Astro statiques, un 410 doit être servi par votre hébergeur (nginx return 410; ou un Cloudflare Worker), puisque la sortie statique d’Astro n’émet que des 404 pour les routes manquantes.

Questions fréquentes

Un 301 est-il toujours mauvais ?

Non. Un 301 est correct quand l’URL a réellement bougé — ancien slug vers nouveau slug, HTTP vers HTTPS, www vers non-www. C’est uniquement mauvais lorsque MetricSpot audite l’URL que vous voulez canonique et qu’elle redirige en 301 — cela signifie que vous nous avez donné (à nous, à Google, à chaque backlink) la mauvaise URL.

Devrais-je renvoyer 200 pour les pages manquantes avec un message “non trouvé” ?

Non. Renvoyer 200 avec un corps “page non trouvée” s’appelle un soft 404. Google le détecte (par motif de contenu) et le traite comme un 404 de toute façon, mais cela perturbe l’analytique et gonfle votre budget de crawl. Renvoyez toujours le bon statut HTTP.

Et le 304 Not Modified ?

304 est une réponse conditionnelle réussie — le navigateur a déjà la page en cache. Ce n’est pas un problème ; MetricSpot n’envoie pas d’en-têtes If-Modified-Since donc vous ne le verrez normalement pas dans notre crawl. Si c’est le cas, votre CDN est trop agressif sur le cache des GET non authentifiés.