Pourquoi renvoyer un HTTP 200 sur vos erreurs sabote-t-il votre crawl budget ?

Pourquoi les codes d'état HTTP restent-ils critiques dans l'architecture moderne ?

L'essor des single-page applications (SPA) a déplacé la logique de routage du serveur vers le navigateur. Historiquement, un serveur Apache ou Nginx renvoyait automatiquement un 404 Not Found si une URL n'existait pas. Avec React, Vue ou Angular, le serveur sert souvent un fichier index.html unique qui répond toujours HTTP 200, laissant au JavaScript le soin d'afficher « Page introuvable ».

Googlebot interprète ce 200 comme un signal de réussite. Il indexe la page, tente de la crawler à nouveau, et consomme votre crawl budget sur du contenu qui n'existe pas. Le bot ne voit que le HTML initial, pas le rendu JavaScript qui affiche l'erreur — sauf si vous avez mis en place un SSR (server-side rendering) ou un pre-rendering qui génère le bon code d'état dès le serveur.

Quelles sont les conséquences concrètes d'un mauvais code d'état ?

Un soft 404 (page d'erreur renvoyant 200) entraîne plusieurs problèmes cumulatifs. Googlebot crawle des URLs mortes à répétition au lieu d'explorer vos nouvelles pages stratégiques. La Search Console vous alerte sur des « pages indexées mais introuvables », mais sans mécanisme automatique pour les supprimer rapidement de l'index.

Le second impact touche la qualité perçue du site. Google détecte que vos pages ont un taux de rebond anormal ou un contenu vide, et ajuste son évaluation globale. Les utilisateurs cliquent, tombent sur une erreur camouflée en 200, et repartent — ce qui dégrade vos signaux comportementaux. Un 404 propre, en revanche, est compris par tous les acteurs : bot, navigateur, CDN, analytics.

Comment gérer les codes d'état dans une SPA sans SSR ?

Si votre stack ne permet pas de SSR (contraintes techniques, legacy, budget), vous devez implémenter un middleware côté serveur qui inspecte l'URL avant de renvoyer l'HTML. Un simple routeur Express.js ou un edge worker Cloudflare peut vérifier si la route existe dans votre sitemap ou base de données, et renvoyer 404 ou 410 Gone en conséquence.

Alternativement, utilisez un pre-rendering service (Prerender.io, Rendertron) qui génère des snapshots HTML avec les bons codes d'état pour Googlebot uniquement. Cette solution hybride préserve l'expérience SPA pour les humains tout en servant du HTML statique correctement configuré aux bots. Attention cependant : Google considère le cloaking entre users et bots comme une violation si le contenu diffère, mais pas si seuls les codes d'état et le rendu diffèrent.

• Soft 404 : page d'erreur renvoyant HTTP 200, crawlée indéfiniment par Googlebot
• Crawl budget : nombre de pages que Google accepte de crawler par jour sur votre domaine, limité et précieux
• SSR / Pre-rendering : techniques permettant de générer le HTML côté serveur avec les codes d'état corrects avant envoi au client
• Middleware serveur : couche logicielle qui intercepte les requêtes pour injecter les codes d'état appropriés avant le rendu SPA
• Edge workers : fonctions JavaScript exécutées au niveau du CDN (Cloudflare, Fastly) pour manipuler les réponses HTTP à la volée

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument, et c'est l'un des rares points où la doctrine officielle de Google colle parfaitement à la réalité. Les audits techniques révèlent régulièrement des dizaines, voire des centaines de soft 404 sur des sites SPA mal configurés. La Search Console les signale sous « Exclues : page introuvable (404) » alors que le serveur renvoie 200 — preuve que Google détecte l'incohérence mais ne la corrige pas automatiquement.

Les tests avec des outils comme Screaming Frog ou OnCrawl confirment que Googlebot recrawle ces URLs plusieurs fois par semaine, gonflant artificiellement les logs serveur et consommant du crawl budget qui manque ailleurs. Sur un site de 50 000 pages avec 10 % de soft 404, cela représente 5 000 pages fantômes qui capturent du budget inutilement.

Quelles nuances faut-il apporter à cette recommandation ?

Martin Splitt ne précise pas un cas limite crucial : les pages de résultats vides. Une page de recherche produit/0 résultats ou une catégorie temporairement épuisée doit-elle renvoyer 404 ou 200 ? La réponse dépend de votre stratégie. Si la catégorie reviendra en stock sous 48h, un 200 avec contenu alternatif (produits similaires, newsletter) préserve l'indexation. Si la catégorie est définitivement vide, un 410 Gone est plus approprié qu'un 404.

Autre nuance : les erreurs 500/503 dans les SPA. Un plantage JavaScript côté client ne doit pas renvoyer 200, mais le serveur ne le sait pas forcément. Il faut un monitoring actif (Sentry, LogRocket) qui détecte ces crashs et signale au serveur de renvoyer 503 Service Unavailable temporairement, pour éviter la désindexation brutale. [A vérifier] : Google n'a jamais clarifié le seuil de tolérance avant désindexation pour un 500 récurrent — les observations suggèrent 7 jours consécutifs, mais aucune confirmation officielle.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Les PWA offline-first constituent un cas particulier. Une Progressive Web App qui fonctionne hors ligne peut légitimement renvoyer 200 avec un contenu en cache même si le serveur est inaccessible. Googlebot ne crawle pas hors ligne, donc cette situation ne se présente pas pour lui — mais elle crée une incohérence théorique que Google tolère pour l'instant.

Les paywalls et contenus réservés posent un autre dilemme. Un article premium inaccessible sans abonnement doit-il renvoyer 401 Unauthorized, 403 Forbidden ou 200 avec du contenu tronqué ? Google recommande 200 + structured data Paywall, car un 401/403 empêche l'indexation. C'est l'exception explicite à la règle « toujours renvoyer le code d'état réel », et elle mérite d'être documentée dans votre stratégie SEO.

Que faut-il auditer en priorité sur votre site SPA ?

Commencez par un crawl complet avec Screaming Frog en mode « JavaScript rendering » activé. Comparez les codes d'état HTTP renvoyés par le serveur (avant rendu JS) avec le contenu final affiché. Toute page affichant « 404 » ou « Page introuvable » dans le DOM mais renvoyant 200 OK en HTTP est un soft 404 à corriger immédiatement.

Croisez ces données avec la Search Console, section « Couverture » → « Exclues ». Les URLs marquées « Introuvable (404) » alors que votre serveur répond 200 sont des signaux d'alarme. Exportez la liste et vérifiez si ce sont des pages réellement supprimées (auquel cas il faut corriger le code) ou des faux positifs détectés par l'analyse sémantique de Google (auquel cas il faut enrichir le contenu).

Quelles modifications techniques implémenter concrètement ?

Si vous utilisez Next.js ou Nuxt.js, la solution est native : getServerSideProps() ou asyncData() permettent de définir le code d'état HTTP côté serveur avant le rendu. Exemple Next.js : res.statusCode = 404 dans getServerSideProps pour une page introuvable. Le framework gère le reste automatiquement.

Pour une SPA pure (React, Vue, Angular sans SSR), ajoutez un middleware Express.js ou un edge worker Cloudflare qui inspecte l'URL avant de servir index.html. Créez une whitelist des routes valides (issue de votre router côté client ou d'une API) et renvoyez 404 pour tout le reste. Exemple nginx : map $request_uri $status_code puis return $status_code basé sur une regex des routes connues.

Comment vérifier que votre implémentation fonctionne correctement ?

Utilisez curl -I https://votresite.com/page-inexistante en ligne de commande pour vérifier le code d'état brut, sans JavaScript. Si vous obtenez HTTP/1.1 200 OK au lieu de 404, le problème persiste. Testez également avec l'outil d'inspection d'URL de la Search Console : il affiche le code HTTP capturé par Googlebot, distinct du rendu final.

Mettez en place une alerte automated dans vos logs serveur (Cloudflare Analytics, AWS CloudWatch, Datadog) pour détecter un ratio anormal de 200 sur des URLs contenant /404, /erreur, /not-found. Un pic soudain signale souvent une régression après un déploiement. Surveillez également le taux de soft 404 dans la Search Console : il devrait tendre vers 0 % après correction.

Ces optimisations techniques, bien que critiques pour la santé SEO de votre SPA, nécessitent une expertise pointue en architecture web et un suivi rigoureux dans la durée. Si votre équipe manque de ressources ou que vous suspectez des angles morts dans votre configuration, un audit réalisé par une agence SEO spécialisée peut identifier les failles invisibles et sécuriser votre crawl budget sur le long terme.

• Crawler le site en mode JavaScript rendering et extraire tous les codes HTTP vs contenu DOM
• Vérifier dans Search Console section « Couverture » les pages exclues pour soft 404
• Implémenter un middleware serveur ou edge worker qui renvoie 404/410 pour les routes invalides
• Tester avec curl -I et l'outil d'inspection d'URL Google les codes HTTP bruts avant rendu JS
• Configurer des alertes automatiques sur les ratios anormaux de 200 dans les logs serveur
• Documenter dans un playbook les routes valides et le mapping codes d'état attendus