Servir un 404 à Googlebot et un 200 aux visiteurs est-il vraiment du cloaking ?

Pourquoi cette tolérance sur les codes HTTP divergents ?

Dans les Single Page Applications modernes, le pré-rendu est devenu une nécessité pour faciliter l'indexation. Les outils comme Prerender.io ou Rendertron interceptent les requêtes de Googlebot et leur servent du HTML statique, alors que les visiteurs humains chargent l'application JavaScript côté client.

Le problème surgit quand une route n'existe pas : la SPA affiche visuellement un message d'erreur avec un code 200, tandis que le pré-rendu envoie un 404 propre à Googlebot. Techniquement, c'est bien servir du contenu différent selon le user-agent — la définition classique du cloaking. Mais Google reconnaît ici que l'intention n'est pas frauduleuse.

Cette clarification répond à une anxiété légitime : beaucoup de développeurs craignent qu'optimiser l'expérience Googlebot via le pré-rendu ne déclenche une pénalité manuelle. Martin Splitt lève cette ambiguïté pour les cas standards.

Quelle est la limite entre optimisation et manipulation ?

La nuance critique tient dans l'expression « quelque chose de vraiment douteux ». Google ne définit pas précisément ce seuil, mais le contexte indique qu'il s'agit de cas où le contenu 200 pour l'utilisateur serait riche et fonctionnel, tandis que Googlebot recevrait systématiquement des 404 pour masquer des sections entières.

Si l'utilisateur voit effectivement une page d'erreur visuelle (« Page non trouvée », « Cette ressource n'existe plus »), alors servir un 404 à Googlebot est cohérent avec la réalité de l'expérience utilisateur. C'est même plus honnête que de laisser Google indexer un 200 vide qui déclencherait un soft 404.

Comment Google détecte-t-il les soft 404 ?

Un soft 404 survient quand un serveur renvoie un code 200 pour une page qui devrait logiquement être une 404 — contenu très maigre, message d'erreur visible, signaux UX dégradés. Google utilise des heuristiques de contenu : ratio texte/HTML, patterns linguistiques typiques des erreurs, absence d'éléments structurels habituels.

Dans le cas d'une SPA, si la page 200 servie aux visiteurs est bien une erreur, Google la classera comme soft 404 même sans recevoir le code HTTP approprié. C'est pourquoi servir le vrai 404 à Googlebot via pré-rendu est en fait une amélioration : vous alignez le signal HTTP avec la réalité du contenu.

• Pré-rendu 404 pour Googlebot + page 200 erreur visuelle pour l'utilisateur : toléré par Google, considéré comme optimisation technique légitime.
• Soft 404 : détecté par analyse du contenu, pas seulement par le code HTTP — Google repère les pages vides ou messages d'erreur même avec un 200.
• Cloaking interdit : masquer du contenu existant à Googlebot en servant des 404 systématiques, ou afficher du contenu riche au bot et une erreur aux visiteurs.
• Seuil vague : Google n'explicite pas « vraiment douteux » — la prudence impose de documenter toute divergence et de s'assurer qu'elle reflète fidèlement l'expérience utilisateur.

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

Globalement, oui. Depuis des années, les sites utilisant du pré-rendu avec des codes HTTP différenciés ne font pas l'objet de pénalités manuelles visibles, tant que l'expérience utilisateur reste cohérente. Les crawls de comparaison entre Googlebot et navigateur standard montrent que Google tolère ces écarts techniques quand ils servent l'indexation.

Cependant, la formulation « quelque chose de vraiment douteux » reste floue. [A vérifier] : aucune métrique chiffrée, aucun seuil de tolérance précis n'est donné. On reste dans l'appréciation subjective de l'équipe Quality Raters ou des algorithmes anti-spam. Un site peut passer sous le radar pendant des mois puis basculer si les patterns d'usage changent.

Quelles sont les zones grises à surveiller ?

Le vrai danger n'est pas la SPA 404 légitime, c'est le dérapage progressif : un développeur qui commence à servir des 404 pour des pages marginales « pour voir », puis étend la pratique à des catégories entières. Ou pire, qui sert un 200 riche au visiteur et un 404 à Googlebot pour contrôler l'indexation sans robots.txt.

Autre piège : les erreurs de configuration du pré-rendu. J'ai vu des sites où le service pré-rendu servait des 404 par défaut à cause d'un timeout mal calibré, alors que la page JavaScript finissait par charger côté client. Google peut interpréter ça comme instabilité, voire manipulation si le pattern est systématique.

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

Cette tolérance concerne uniquement les vraies pages d'erreur. Si vous servez un 404 à Googlebot pour une page produit active, une fiche service ou un article de blog, c'est du cloaking pur et dur — même si l'utilisateur voit un 200 avec du contenu.

De même, si vous utilisez cette technique pour masquer du contenu dupliqué ou des pages low-quality que vous ne voulez pas indexer, Google pourrait y voir une tentative de manipulation. La bonne pratique reste le noindex ou le canonical, pas un 404 sélectif selon le user-agent.

Que faut-il faire concrètement pour rester dans les clous ?

D'abord, auditer votre pré-rendu : listez toutes les routes qui servent un code HTTP différent à Googlebot versus utilisateurs. Documentez chaque cas avec une justification claire — « page supprimée », « paramètre invalide », « ressource jamais créée ». Si vous ne pouvez pas justifier la divergence en 10 secondes, c'est probablement un red flag.

Ensuite, testez la cohérence visuelle : naviguez sur les URLs qui renvoient un 404 à Googlebot. Est-ce que l'utilisateur voit effectivement un message d'erreur, un layout cassé, un contenu vide ? Si la page affiche du contenu utile, alignez le code HTTP — servez un 200 partout ou un 404 partout.

Quelles erreurs éviter absolument ?

Ne créez jamais de whitelist/blacklist par user-agent pour servir des 404 stratégiques. C'est exactement le pattern que les algorithmes anti-spam détectent. Si vous devez bloquer l'indexation, utilisez le fichier robots.txt, la balise meta noindex ou le header X-Robots-Tag.

Évitez aussi le 404 par défaut : certains services de pré-rendu sont configurés pour renvoyer 404 en cas de timeout ou d'erreur JavaScript. Ça peut masquer des bugs réels et créer un écart illégitime avec l'expérience utilisateur. Configurez des timeouts généreux et loggez les erreurs de rendu.

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

Utilisez l'outil Inspection d'URL dans Google Search Console pour comparer la version rendue par Googlebot avec celle vue dans un navigateur standard. Cherchez les divergences de code HTTP, mais aussi de contenu — un écart massif signale un problème.

Surveillez les rapports de couverture d'index pour détecter des pics de soft 404. Si Google classe massivement vos pages comme soft 404 alors que vous servez des 404 propres via pré-rendu, c'est bon signe — ça confirme que les deux signaux convergent. Si au contraire vous voyez des soft 404 sans avoir envoyé de 404 HTTP, creusez.

• Documenter chaque route servant un code HTTP différent à Googlebot versus utilisateurs, avec justification métier claire.
• Tester manuellement les URLs pré-rendues en 404 : l'utilisateur voit-il réellement une page d'erreur visuelle ?
• Configurer des timeouts généreux sur le service de pré-rendu pour éviter les 404 accidentels dus à des lenteurs JavaScript.
• Utiliser l'Inspection d'URL dans Search Console pour comparer le rendu Googlebot et le rendu navigateur standard.
• Surveiller les rapports de couverture pour repérer des anomalies (soft 404 massifs, désinexation inattendue).
• Éviter toute logique de whitelist/blacklist user-agent — préférer robots.txt, noindex ou canonical pour contrôler l'indexation.