Servir un 404 à Googlebot et un 200 aux utilisateurs, est-ce vraiment du cloaking ?

Pourquoi cette question se pose-t-elle pour les SPAs React ?

Les applications single-page modernes renvoient systématiquement un code 200 OK, même quand le contenu n'existe pas. La logique d'affichage de l'erreur 404 est gérée côté client en JavaScript, après le chargement initial.

Ce comportement pose un problème évident : Googlebot reçoit un 200 pour une page qui devrait techniquement renvoyer un 404. Les services de pre-rendering comme Prerender.io ou Rendertron permettent justement de corriger ce décalage en servant le bon code HTTP au crawler.

Le dynamic rendering change-t-il vraiment la donne ?

Oui, car il permet de servir une version pré-rendue à Googlebot avec les codes d'état HTTP corrects, tout en gardant la SPA intacte pour les utilisateurs réels. Google a toujours validé cette approche comme solution temporaire.

Martin Splitt précise ici que renvoyer un 404 au bot alors que l'utilisateur voit la même page d'erreur en 200 n'est pas considéré comme du cloaking, puisque le contenu affiché reste identique. Seul le code HTTP change — et c'est exactement ce qu'on cherche à corriger.

Que se passe-t-il si on laisse le 200 pour tout le monde ?

Google détectera un soft 404 si le contenu de la page indique clairement une erreur (message « page introuvable », peu de contenu, etc.). Les soft 404 sont traités comme des vraies 404 côté indexation, mais avec un délai de détection.

Le problème, c'est que cette détection n'est pas instantanée et peut entraîner du gaspillage de crawl budget, surtout sur des sites avec des milliers de pages générées dynamiquement. Servir un vrai 404 via dynamic rendering accélère le processus.

• Dynamic rendering avec codes HTTP corrects : pratique validée par Google, pas de risque de cloaking
• Soft 404 : détectés automatiquement par Google, mais avec un délai variable selon les sites
• Contenu identique : seul le code HTTP change entre bot et utilisateur, c'est précisément l'objectif du dynamic rendering
• Comportement suspect : si le contenu diffère significativement ou si des patterns de manipulation sont détectés, le risque de pénalité existe

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

Complètement. J'ai vu des dizaines de sites React/Vue/Angular utiliser du dynamic rendering avec codes d'état différenciés sans jamais recevoir de pénalité. Tant que le contenu visible reste le même, Google ne considère pas ça comme du cloaking.

Ce qui compte pour Google, c'est l'intention de manipulation. Si tu sers une page 404 au bot et un contenu commercial à l'utilisateur, là tu franchis la ligne. Mais corriger un code HTTP tout en affichant la même page d'erreur ? C'est exactement ce que le dynamic rendering est censé faire.

Quelles nuances faut-il apporter à cette affirmation ?

La formulation « sauf comportement suspect » reste volontairement vague. Google ne détaille jamais précisément ce qui déclenche un flag de cloaking dans ces cas-là. [A verifier] : on manque de données sur les seuils de tolérance — combien de pages peuvent différer sur les codes HTTP avant qu'un pattern suspect soit détecté ?

Autre point : Splitt mentionne que les soft 404 seront détectés de toute façon, mais il ne donne aucun délai. Sur des sites avec un crawl budget limité, ça peut prendre des semaines. Servir un vrai 404 reste donc objectivement plus efficace, même si Google finit par comprendre tout seul.

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

Si ton service de dynamic rendering introduit du contenu supplémentaire uniquement visible par Googlebot — métadonnées enrichies, textes cachés, liens additionnels — tu bascules dans du cloaking pur. Même si les codes HTTP sont corrects.

Attention aussi aux différences non intentionnelles : si ton pre-renderer injecte des scripts tiers, des bandeaux de consentement différents ou modifie la structure HTML de manière significative, Google pourrait y voir une tentative de manipulation. Vérifie systématiquement que la version pré-rendue correspond pixel pour pixel à ce que voit l'utilisateur.

Que faut-il faire concrètement pour rester conforme ?

D'abord, configure ton service de dynamic rendering (Prerender.io, Rendertron, ou solution maison) pour qu'il renvoie les bons codes HTTP selon le contenu. Si ta SPA affiche une 404, le bot doit recevoir un 404. Si c'est une 301, idem.

Ensuite, teste systématiquement avec l'outil d'inspection d'URL de la Search Console. Compare la version rendue par Google avec ce que voit un utilisateur réel. Zéro différence de contenu visible — c'est la règle d'or.

Quelles erreurs éviter absolument ?

Ne sers jamais de contenu enrichi uniquement à Googlebot sous prétexte que tu utilises du dynamic rendering. Ajouter du texte caché, des balises Schema.org survitaminées ou des liens internes supplémentaires uniquement dans la version pré-rendue, c'est du cloaking classique.

Évite aussi les discordances de codes HTTP involontaires. Si ta SPA renvoie une redirection 301 côté client mais que ton pre-renderer sert un 200, Google va s'embrouiller. Documente clairement les règles de mapping entre états JavaScript et codes HTTP.

Comment vérifier que mon implémentation est solide ?

Mets en place un monitoring automatisé qui compare régulièrement la version bot et la version utilisateur sur un échantillon de pages (existantes, 404, redirections). Des outils comme Screaming Frog ou Sitebulb peuvent faire ça en mode comparaison.

Vérifie dans la Search Console la présence de soft 404 détectées. Si Google en détecte malgré ton dynamic rendering, c'est que ton service ne renvoie pas les bons codes ou que le contenu ne signale pas assez clairement l'erreur.

• Configurer le dynamic rendering pour servir des codes HTTP corrects (404, 301, 410, etc.)
• Tester chaque type de page (existante, erreur, redirection) avec l'outil d'inspection d'URL Google
• Comparer pixel par pixel les versions bot et utilisateur — aucune différence de contenu visible
• Monitorer les soft 404 dans la Search Console pour détecter les écarts de configuration
• Documenter les règles de mapping entre états JavaScript et codes HTTP pour toute l'équipe
• Auditer régulièrement les services tiers de pre-rendering pour éviter les modifications non contrôlées