Faut-il servir des pages allégées aux bots pour améliorer les performances ?

Pourquoi cette pratique séduit-elle certains SEO ?

L'idée de servir aux bots des pages allégées part d'un constat légitime : Googlebot et les autres crawlers consomment du temps serveur et du crawl budget. Retirer les webfonts — qui peuvent peser de quelques dizaines à plusieurs centaines de Ko — semble une optimisation logique pour accélérer le rendu et réduire la charge.

Dans la pratique, certains sites à fort volume de pages ou à infrastructure technique contrainte ont été tentés par cette approche. Le raisonnement : pourquoi servir une police custom à un robot qui ne "voit" pas le design ? Autant lui envoyer une version épurée, plus rapide à charger, pour maximiser les pages crawlées.

Quel est le problème selon Google ?

Martin Splitt pointe trois faiblesses majeures dans cette stratégie. D'abord, la détection des bots n'est jamais fiable à 100 % — user-agents spoofés, crawlers tiers, outils SEO qui se font passer pour Googlebot. Vous risquez de servir la mauvaise version au mauvais visiteur.

Ensuite, le code supplémentaire nécessaire pour gérer cette logique conditionnelle introduit de la fragilité. Chaque couche de détection est une opportunité de bug : erreur de configuration, cache mal invalidé, règle serveur qui s'applique trop largement. Et quand ça casse, Google peut indexer une version dégradée de votre site.

Enfin, le gain réel est minime par rapport au risque. Les webfonts modernes sont compressées, souvent mises en cache, et leur impact sur le temps de rendu global reste marginal comparé à JavaScript, images ou requêtes réseau multiples. Autrement dit : vous compliquez votre stack technique pour gratter quelques millisecondes.

Quelles alternatives recommande Google ?

Deux pistes simples, sans risque de cloaking. Première option : bloquer les webfonts via robots.txt. Googlebot ne les téléchargera pas, mais continuera de crawler et indexer votre contenu normalement. Aucune détection bot requise, aucune logique conditionnelle côté serveur.

Seconde approche : utiliser font-display:swap dans vos déclarations @font-face. Le navigateur affiche immédiatement le texte avec une police système, puis swap vers la webfont dès qu'elle est chargée. Googlebot obtient un rendu rapide, les utilisateurs aussi, et vous évitez toute complexité technique inutile.

• Détection bot : jamais fiable à 100 %, risque de servir la mauvaise version
• Code supplémentaire : chaque couche de logique conditionnelle = opportunité de bug
• Gain marginal : webfonts pèsent peu face à JS, images, requêtes réseau
• Alternative 1 : bloquer webfonts via robots.txt (simple, sans risque)
• Alternative 2 : font-display:swap pour chargement asynchrone

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

Oui, et elle rejoint un principe constant chez Google : éviter toute forme de cloaking, même bien intentionné. Servir du contenu différent aux bots reste une zone grise — techniquement autorisé dans certains cas (mobile vs desktop en responsive par exemple), mais scruté de près par l'algo. Ici, la différence porte sur des ressources esthétiques, mais le mécanisme reste le même : détection + variation = risque.

Sur le terrain, les sites qui ont tenté cette approche ont souvent rencontré des problèmes d'indexation imprévisibles. Cache CDN mal configuré qui sert la version bot aux users, règle serveur trop large qui bloque des crawlers légitimes, ou encore Google qui détecte la manipulation et pénalise. Le jeu n'en vaut pas la chandelle.

Dans quels cas cette règle pourrait-elle être nuancée ?

Difficile d'imaginer un scénario légitime. Même sur des sites à crawl budget ultra-contraint (millions de pages, actualisation quotidienne), bloquer les webfonts via robots.txt suffit. Pas besoin de détection bot, pas de code conditionnel, résultat identique.

Le seul cas limite : un site avec des webfonts extrêmement lourdes (plusieurs Mo, polices custom non optimisées) où le temps de téléchargement plombe réellement le crawl. Mais là, le vrai problème est en amont — il faut optimiser ou remplacer ces polices, pas contourner le souci par du cloaking. [A vérifier] si Google tolère une exception documentée dans ce contexte, mais aucune communication officielle ne va dans ce sens.

Quelle est la vraie priorité en matière de performance pour Googlebot ?

Réduire le Time to First Byte (TTFB), limiter les redirections en chaîne, optimiser la vélocité serveur. Les webfonts arrivent bien après dans la hiérarchie des optimisations. Un serveur qui met 800 ms à répondre pénalise le crawl bien plus qu'une webfont de 50 Ko.

Et pour les Core Web Vitals côté utilisateur, font-display:swap résout élégamment le problème de layout shift et de temps de rendu. Vous gagnez sur les deux tableaux — bot et humain — sans compromis technique. C'est exactement ce que recommande Martin Splitt, et c'est cohérent avec l'approche "une seule version, optimisée pour tous" que Google prône depuis des années.

Que faut-il faire si vous servez déjà des pages différentes aux bots ?

Première étape : auditer votre configuration serveur pour identifier toutes les règles de détection bot. Cherchez les conditions sur user-agent, les variations de fichiers CSS/fonts selon le visiteur, les caches CDN avec clés basées sur le user-agent. Documentez chaque point de divergence entre version bot et version user.

Ensuite, testez l'impact réel de cette optimisation. Mesurez le temps de crawl avant/après suppression des webfonts côté bot. Si le gain est inférieur à 100 ms par page, vous êtes dans le bruit de mesure — autant simplifier votre stack. Si le gain dépasse 200 ms, posez-vous la question : pourquoi vos webfonts sont-elles si lourdes ?

Comment migrer vers une approche conforme sans perte de performance ?

Option 1 : ajoutez vos fichiers de webfonts au robots.txt avec Disallow. Googlebot ne les téléchargera plus, mais continuera de crawler vos pages HTML/CSS normalement. Zéro risque de cloaking, zéro code supplémentaire. Testez dans Search Console (outil Inspection d'URL) pour vérifier que le rendu reste correct.

Option 2 : implémentez font-display:swap dans vos @font-face. Le texte s'affiche instantanément avec une police système, la webfont se charge en arrière-plan et swap dès disponible. Vous améliorez LCP et CLS en même temps, et Googlebot obtient un rendu rapide sans télécharger la police. C'est la solution recommandée par Google, et elle bénéficie aussi aux utilisateurs sur connexion lente.

Quelles erreurs éviter lors de cette transition ?

Ne bloquez pas l'intégralité de votre CSS via robots.txt en pensant gagner du temps — Google a besoin des styles pour comprendre la mise en page et détecter le contenu principal. Bloquez uniquement les fichiers .woff, .woff2, .ttf, .eot si vous optez pour cette approche.

Évitez aussi de garder une détection bot "dormante" dans votre code, même désactivée. Si un développeur la réactive par erreur lors d'un déploiement, vous risquez un retour de bâton. Supprimez complètement la logique conditionnelle pour éliminer le risque à la source.

• Auditer toutes les règles de détection bot (serveur, CDN, application)
• Mesurer le gain réel de performance avant de décider
• Bloquer les webfonts via robots.txt OU implémenter font-display:swap
• Tester le rendu bot avec l'outil Inspection d'URL de Search Console
• Supprimer complètement la logique de détection bot du code source
• Documenter la nouvelle configuration pour éviter les régressions futures