Comment gérer correctement les codes HTTP d'erreur dans une single-page app ?

Pourquoi les codes HTTP comptent-ils autant en architecture SPA ?

Les single-page applications posent un défi fondamental au crawl : tout se passe côté client. Googlebot arrive, charge la page, exécute le JavaScript, et découvre… qu'il n'y a rien. Sauf que sans signal HTTP explicite, le bot interprète ça comme une page vide avec un code 200.

Ce n'est pas un problème théorique. Une erreur 404 mal gérée peut rester indexée comme page blanche, diluer le crawl budget, et polluer l'index. Google a besoin d'une confirmation serveur que l'URL est morte — pas juste d'un rendu JavaScript affichant « Page introuvable ».

Quelle est la méthode préconisée par Martin Splitt ?

La solution consiste à configurer le serveur pour qu'il réponde avec le bon code HTTP sur des URLs dédiées. Par exemple : /not-found renvoie un 404, /error renvoie un 500. Ensuite, le JavaScript redirige l'utilisateur vers cette URL quand il détecte une erreur.

Concrètement, si un utilisateur tape /article-inexistant, le serveur charge la SPA (code 200), le JS détecte que l'article n'existe pas, et redirige vers /not-found où le serveur renvoie un vrai 404. Googlebot suit cette redirection et enregistre le 404 correctement.

Est-ce que toutes les architectures SPA sont concernées ?

Oui, dès qu'on parle de routage client-side : React Router, Vue Router, Angular Router, etc. Le problème est identique partout. Si ton SPA génère des URLs dynamiquement sans passer par le serveur, tu dois implémenter cette logique hybride.

Les frameworks SSR (Next.js, Nuxt, SvelteKit) gèrent ça nativement en rendant côté serveur avec le bon code HTTP. Mais pour une SPA classique avec create-react-app ou un build Vite standard, c'est à toi de câbler serveur et client.

• Le serveur doit être configuré pour renvoyer des codes HTTP spécifiques sur des URLs dédiées (/not-found, /error, etc.).
• Le JavaScript doit rediriger l'utilisateur vers ces URLs quand une erreur est détectée côté client.
• Googlebot suit la redirection et interprète le code HTTP retourné par le serveur, pas le rendu JS.
• Cette approche s'applique à toute SPA avec routage client-side, sauf si tu utilises un framework SSR qui gère nativement les codes HTTP.
• Sans cette configuration, une page 404 risque d'être indexée comme page blanche avec un code 200.

Cette déclaration est-elle cohérent avec les pratiques terrain observées ?

Oui, et c'est même un des rares points où Google est explicitement clair sur les SPA. On observe régulièrement des sites React ou Vue avec des centaines de 404 indexées comme pages vides. Le pattern de redirection vers une URL serveur dédiée est la seule solution documentée qui fonctionne à 100 %.

Cela dit, la déclaration reste silencieuse sur les alternatives. Qu'en est-il du rendu dynamique avec Puppeteer qui injecte un statcode ? Qu'en est-il des meta refresh ou des redirections 302 côté client ? Google ne dit rien, donc prudence. [A vérifier] si d'autres patterns sont tolérés en pratique.

Quelles limites ou effets de bord faut-il anticiper ?

La redirection JavaScript vers une URL serveur dédiée a un coût : tu casses l'historique de navigation. Si l'utilisateur tape une URL morte, est redirigé vers /not-found, puis clique sur « Retour », il revient sur /not-found, pas sur l'URL d'origine. Ça peut perturber l'UX.

Autre point : cette logique impose de maintenir deux couches — serveur et client — en cohérence. Si ton serveur renvoie un 404 sur /not-found mais que ton JS ne redirige jamais vers cette URL, tu as un dead-end invisible. Et si ton JS redirige vers /error mais que le serveur renvoie un 200, Googlebot enregistre un 200.

Enfin, cette approche ne fonctionne que si Googlebot exécute le JavaScript et suit la redirection. Si le JS plante, si la redirection est en boucle, ou si le serveur est mal configuré, tout s'effondre. Teste en Search Console avec l'outil « Inspection d'URL » avant de déployer.

Dans quels cas cette méthode ne suffit-elle pas ?

Si tu as des erreurs soft 404 (contenu vide mais pas techniquement en erreur), cette méthode ne les résout pas. Google peut toujours indexer une page vide si le serveur renvoie un 200 et que le JS charge un composant sans contenu.

De même, si tu veux gérer des erreurs serveur transitoires (503 pendant une maintenance), la redirection JS ne suffit pas : il faut que le serveur renvoie un 503 directement sur l'URL d'origine, sans passer par une redirection. Sinon, Googlebot interprète ça comme une page morte définitivement.

Que faut-il configurer concrètement sur le serveur ?

Première étape : créer des routes dédiées pour chaque type d'erreur. Par exemple, /not-found avec un code 404, /error avec un code 500, /maintenance avec un 503. Sur Nginx, ça ressemble à ça :

location /not-found { return 404; }
location /error { return 500; }

Sur Apache, tu utilises des directives ErrorDocument ou des RewriteRule avec le flag [R=404]. L'objectif est simple : forcer le serveur à renvoyer le bon statcode sans dépendre du rendu JS.

Comment câbler la redirection JavaScript dans la SPA ?

Dans ton routeur client-side, tu détectes l'erreur (route inexistante, données manquantes) et tu rediriges vers l'URL serveur. Avec React Router, ça donne :

if (!data) { window.location.href = '/not-found'; }

Attention : utilise window.location.href, pas navigate() ou history.push(). Ces méthodes restent côté client et ne forcent pas le serveur à renvoyer le code HTTP. Tu veux un rechargement complet qui passe par le serveur.

Quelles erreurs techniques éviter absolument ?

Ne redirige jamais vers une URL qui renvoie un 200 avec un message d'erreur. C'est le piège classique : ton serveur charge la SPA sur /not-found, la SPA affiche « 404 », mais le serveur a renvoyé un 200. Googlebot indexe ça comme page valide.

Autre erreur : ne pas tester avec l'outil d'inspection d'URL de Search Console. Le rendu Desktop peut fonctionner, mais le rendu Mobile peut planter si le JS ne charge pas. Vérifie les deux.

Enfin, n'oublie pas les erreurs serveur temporaires. Si ton API est down, tu veux un 503, pas une redirection vers /error. Sinon, Googlebot peut désindexer la page définitivement.

• Créer des routes serveur dédiées (/not-found, /error, /maintenance) qui renvoient les codes HTTP appropriés (404, 500, 503).
• Utiliser window.location.href pour forcer une redirection complète, pas navigate() ou history.push().
• Tester avec l'outil d'inspection d'URL de Search Console en Desktop ET Mobile.
• Vérifier que le serveur renvoie bien le code HTTP sur l'URL de destination, pas un 200 avec un rendu d'erreur.
• Distinguer les erreurs permanentes (404) des erreurs temporaires (503) pour éviter une désindexation accidentelle.
• Monitorer les logs serveur pour détecter les erreurs 500 non gérées qui pollueraient le crawl.