Pourquoi les Core Web Vitals concernent les LLMs
Les Core Web Vitals (CWV) sont souvent présentés comme un enjeu exclusivement UX : améliorer l'expérience utilisateur, réduire le taux de rebond, améliorer le ranking Google. Cette vision est incomplète. Pour un praticien du SEO IA, les CWV ont une deuxième dimension : ils conditionnent la capacité des bots IA à crawler et indexer votre contenu.
La connexion n'est pas directe. GPTBot, PerplexityBot ou ClaudeBot ne mesurent pas votre Largest Contentful Paint. Mais ils souffrent des mêmes goulots d'étranglement techniques que Googlebot : un TTFB élevé ralentit le crawl, un rendu JavaScript côté client rend le contenu invisible, un CLS qui déplace le DOM perturbe l'extraction de texte, une latence serveur élevée provoque des timeouts.
Résultat : les sites bien optimisés sur le plan des CWV sont généralement aussi mieux crawlés par les bots IA, non pas parce que ces bots mesurent les CWV, mais parce que les bonnes pratiques techniques qui améliorent les CWV améliorent aussi la crawlabilité générale.
Les quatre métriques CWV et leur impact sur les bots IA
Le tableau suivant détaille chaque métrique Core Web Vitals, son seuil cible, et son impact spécifique sur les crawlers des LLMs.
| Métrique | Seuil cible | Ce que mesurent les bots IA | Impact crawl IA |
|---|---|---|---|
| TTFB (Time to First Byte) | < 200 ms | Oui, directement mesuré | TTFB élevé = crawl ralenti, timeouts, budget de crawl consommé plus vite |
| LCP (Largest Contentful Paint) | < 2,5 s | Non, UX seulement | Indirect : un LCP élevé signale souvent du JS lourd qui peut masquer le contenu |
| INP (Interaction to Next Paint) | < 200 ms | Non, interactivité UX | Aucun impact direct ; un thread JS bloqué peut ralentir le parsing du DOM |
| CLS (Cumulative Layout Shift) | < 0,1 | Non, visuel UX | Faible impact direct ; signale parfois des structures DOM instables |
Conclusion opérationnelle : pour les bots IA, le TTFB est la métrique critique. C'est la seule que ces bots mesurent directement. Les autres métriques CWV ont un impact indirect, principalement via les problèmes de rendu JavaScript qu'elles signalent.
Le problème central : le rendu JavaScript côté client
La majorité des bots IA, GPTBot, PerplexityBot, ClaudeBot, DuckAssistBot, n'exécutent pas JavaScript. Ils lisent le HTML brut retourné par le serveur, sans passer par l'étape de rendu navigateur. Ce comportement a une conséquence majeure : tout contenu généré par JavaScript côté client est invisible pour ces bots.
Un site construit comme une SPA (Single Page Application) React, Vue ou Angular sans SSR retourne typiquement une page HTML de quelques lignes contenant uniquement un <div id="app"></div> et un bundle JS volumineux. Un bot IA qui crawle cette page ne voit rien d'utile.
Les trois solutions pour corriger ce problème :
- SSG (Static Site Generation), Astro, Next.js en export statique, Gatsby. Le contenu est rendu au moment du build, le HTML est complet et statique. C'est la solution la plus efficace pour les bots IA.
- SSR (Server-Side Rendering), Next.js avec getServerSideProps, Nuxt, SvelteKit. Le HTML est rendu à la demande côté serveur avant envoi. Les bots reçoivent un HTML complet.
- Prerendering, Prerender.io, Rendertron. Un service génère un snapshot HTML pour les bots détectés. Moins propre que SSR/SSG mais fonctionne en retrofit sur des SPAs existantes.
Budget de crawl et bots IA
Le concept de budget de crawl s'applique aux bots IA comme à Googlebot. Chaque bot dispose d'une capacité de crawl limitée par site, déterminée par la combinaison de la vitesse de crawl autorisée (configurable dans robots.txt via Crawl-delay) et de la vitesse de réponse du serveur.
Un site lent consomme son budget de crawl plus vite : chaque page prend plus de temps à crawler, le bot couvre moins de pages par session. Les conséquences :
- Les pages récentes ou mises à jour ne sont pas re-crawlées rapidement.
- Les articles en profondeur de silo (3 ou 4 clics depuis la home) peuvent ne jamais être crawlés.
- Le contenu publié n'est pas disponible pour les LLMs si les bots n'ont pas pu le lire.
La relation entre TTFB et fréquence de crawl est documentée pour Googlebot. Les mêmes dynamiques s'appliquent aux bots tiers qui respectent les conventions de crawl : un serveur qui répond en < 200 ms sera crawlé plus agressivement qu'un serveur qui répond en 800 ms.
5 leviers d'optimisation prioritaires
Voici les interventions à impact le plus direct sur la crawlabilité par les bots IA, classées par effort.
1. Passer à SSG ou SSR pour le contenu principal
C'est le levier le plus impactant. Si votre site est une SPA JS sans SSR, aucune autre optimisation de performance n'aura d'effet sur les bots IA. La migration vers Astro, Next.js ou un équivalent SSG/SSR est la priorité absolue.
Pour un site existant difficile à migrer : configurez un service de prerendering ciblant les user-agents des bots IA (GPTBot, PerplexityBot, ClaudeBot, Googlebot).
2. Réduire le TTFB sous 200 ms
Le TTFB est le seul CWV directement mesurable par les bots IA. Les leviers principaux : CDN avec edge computing (Cloudflare, Fastly, Vercel Edge), cache serveur agressif sur les pages statiques, optimisation des requêtes base de données pour les pages dynamiques, suppression des redirections inutiles (chaque redirect ajoute un aller-retour réseau).
3. Optimiser le crawl budget avec robots.txt
Réserver le budget de crawl aux pages utiles pour les LLMs. Bloquer les pages à faible valeur :
- Pages de recherche interne (
/search?q=) - Pages de pagination au-delà de la page 2
- Pages de filtres e-commerce sans contenu unique
- Pages d'administration, de connexion, de panier
- URLs avec paramètres de session ou de tracking
Un robots.txt bien configuré libère du budget de crawl pour vos contenus à haute valeur éditoriale.
4. Implémenter des sitemaps XML maintenus à jour
Les sitemaps ne sont pas utilisés par tous les bots IA, mais certains (notamment Googlebot pour les AI Overviews) les utilisent pour découvrir les nouvelles pages. Un sitemap XML à jour, avec des dates lastmod précises et des priorités correctement renseignées, améliore la fréquence de re-crawl des pages mises à jour.
Pour les sites à contenu fréquemment mis à jour (blogs, news), les sitemaps news XML (sitemap-news.xml) permettent une indexation plus rapide dans Google Discover et potentiellement dans les AI Overviews.
5. Corriger les chaînes de redirections
Chaque redirect consomme une requête réseau supplémentaire. Une chaîne de 3 redirects (A → B → C → D) quadruple le temps d'atteinte de la ressource finale. Les bots IA ont généralement une limite de 5 à 10 redirects avant d'abandonner. Auditez et corrigez les chaînes de redirections, en particulier sur les URLs canoniques et les liens internes.
Signaux techniques lus par les crawlers IA
Au-delà des CWV, les bots IA sont sensibles à plusieurs signaux techniques supplémentaires :
| Signal technique | Impact sur les bots IA | Action recommandée |
|---|---|---|
| HTTP/2 ou HTTP/3 | Améliore le débit de crawl (multiplexage) | Activer HTTP/2 minimum sur le serveur |
| Compression gzip / Brotli | Réduit la taille des pages transmises | Activer Brotli (meilleure compression) ou gzip en fallback |
| Headers Cache-Control | Permet aux bots de respecter la fréquence de re-crawl | Configurer max-age selon la fréquence de mise à jour réelle |
| Canonical URL | Évite le crawl de contenu dupliqué | Balise <link rel="canonical"> sur toutes les pages |
| HTTPS | Pré-requis pour certains bots | TLS à jour, certificat valide, pas d'erreurs de mixed content |
Diagnostic en 5 étapes
Processus de diagnostic rapide pour identifier les blocages techniques impactant les bots IA :
- Test de rendu : Simulez un bot IA en désactivant JavaScript dans votre navigateur (DevTools → Settings → Disable JavaScript). Naviguez sur les pages principales. Si le contenu disparaît, vous avez un problème de rendu JS côté client.
- Mesure TTFB : Utilisez WebPageTest.org (mode "Mobile" depuis un data center européen) ou la commande
curl -w "TTFB: %{time_starttransfer}\n" -o /dev/null -s https://votre-site.fr/article-clé/. Objectif : < 200 ms. - Audit de budget de crawl : Dans Google Search Console, onglet "Statistiques d'exploration" → analysez les pages crawlées par jour et les réponses. Un ratio élevé de pages bloquées ou d'erreurs 4xx/5xx signale un budget mal utilisé.
- Vérification redirects : Crawlez votre site avec Screaming Frog ou Ahrefs Site Audit. Exportez les chaînes de redirections. Toute chaîne A→B→C est à corriger en redirect direct A→C.
- Test user-agent : Simulez GPTBot avec curl :
curl -A "GPTBot" https://votre-site.fr/page-cle/. Vérifiez que la réponse HTTP 200 contient le contenu textuel attendu, pas seulement un shell HTML vide.
Checklist Core Web Vitals pour les bots IA
- ✅ Contenu principal rendu en HTML côté serveur (SSG ou SSR), pas de SPA JS sans rendu serveur
- ✅ TTFB < 200 ms mesuré depuis un serveur européen (CDN ou edge configuré)
- ✅ HTTP/2 ou HTTP/3 activé sur le serveur de production
- ✅ Compression Brotli ou gzip active sur les réponses HTML
- ✅ Sitemap XML à jour avec
lastmodprécis et soumis dans Google Search Console - ✅ Pas de chaîne de redirects (maximum 1 redirect entre URL source et destination finale)
- ✅ Balise
<link rel="canonical">présente et correcte sur toutes les pages - ✅ robots.txt bloque les pages sans valeur éditoriale (search, filtres, pagination > 2)
- ✅ Test user-agent GPTBot confirme que le HTML retourné contient le contenu complet de la page
FAQ
Est-ce que GPTBot ou PerplexityBot tiennent compte des Core Web Vitals ?
Non directement : GPTBot et PerplexityBot ne mesurent pas les CWV côté utilisateur. En revanche, une page lente (TTFB > 800 ms, JS bloquant) ralentit le crawl et peut provoquer des timeouts, ce qui fait que le bot abandonne avant d'avoir lu le contenu.
Un site avec un mauvais LCP peut-il quand même être cité par les LLMs ?
Oui, si le contenu est accessible en HTML côté serveur. Le LCP mesure l'expérience visuelle utilisateur, pas la disponibilité du texte pour un crawler. Ce qui importe pour les LLMs, c'est que le contenu figure dans le HTML initial (SSR/SSG), pas qu'il s'affiche rapidement.
Quel est le seuil de TTFB critique pour les bots IA ?
La documentation Google Googlebot recommande un TTFB < 200 ms pour un crawl efficace. Au-delà de 500 ms, le bot réduit sa fréquence de crawl. Au-delà de 5 secondes, il peut abandonner la requête. Ces seuils s'appliquent aussi aux bots tiers comme GPTBot ou PerplexityBot.
Le JavaScript côté client empêche-t-il les LLMs de lire mon contenu ?
En grande partie, oui. GPTBot, PerplexityBot et ClaudeBot n'exécutent pas le JavaScript. Si votre contenu principal est rendu par JS (React SPA, Vue, Angular sans SSR), ces bots voient une page quasi vide. La solution : SSG (Astro, Next.js export statique), SSR, ou prerendering (Prerender.io).
Les Core Web Vitals impactent-ils le classement dans les AI Overviews de Google ?
Indirectement. Les AI Overviews héritent en partie des signaux de ranking Google classique, où les CWV sont un signal parmi d'autres. Un site avec d'excellents CWV n'est pas automatiquement cité dans les AIO, mais un site trop lent ou avec des problèmes de crawl sera désavantagé dès l'étape d'indexation.