Les pages lentes sont-elles vraiment indexées par Google ?

Quelle différence entre indexation et crawl ?

Google fait une distinction nette entre deux processus souvent confondus. L'indexation désigne l'intégration d'une page dans l'index de recherche, tandis que le crawl correspond au passage du bot pour télécharger le contenu.

Une page peut être indexée même si son temps de chargement côté utilisateur est catastrophique. Ce qui compte pour l'indexation, c'est que Googlebot puisse accéder au contenu HTML, pas la rapidité d'affichage final. Cette nuance change tout dans l'approche des optimisations prioritaires.

Qu'est-ce qui freine vraiment le crawl ?

Le problème surgit quand le serveur met trop de temps à répondre et transmettre le HTML. Si votre serveur crache le code source en 8 secondes au lieu de 200 millisecondes, Googlebot va ralentir sa cadence de visite.

Ce n'est pas une question de Core Web Vitals ou de JavaScript qui rame. C'est du pur temps de téléchargement serveur. Un bot qui attend 5 secondes par page va naturellement espacer ses requêtes pour ne pas cramer votre infrastructure ou perdre son temps.

Comment Google ajuste-t-il sa fréquence de crawl ?

Googlebot fonctionne avec un budget de crawl qu'il adapte en permanence. Si vos pages répondent vite, il augmente la fréquence. Si elles traînent, il espace les passages pour éviter de surcharger votre serveur.

Cette logique protège les sites fragiles, mais pénalise aussi ceux qui ont des ressources suffisantes mais mal configurées. Un serveur capable de servir 100 pages par seconde mais qui en met 2 à répondre sera traité comme un serveur faible, même si c'est juste un problème de config.

• L'indexation n'est pas bloquée par la vitesse : une page lente peut parfaitement figurer dans l'index Google
• Le crawl budget se réduit si le temps de téléchargement serveur est élevé
• La vitesse utilisateur et la vitesse bot sont deux choses distinctes : Core Web Vitals ≠ temps de réponse serveur
• Un serveur lent freine la découverte de nouveaux contenus et retarde la mise à jour des pages existantes
• Google adapte son comportement automatiquement sans prévenir : vous ne recevez pas d'alerte si votre crawl budget s'effondre

Cette déclaration correspond-elle aux observations terrain ?

Oui, et c'est même confirmé depuis des années dans les logs serveur. Les sites avec des temps de réponse serveur dégradés voient leur fréquence de crawl chuter progressivement. Ce n'est pas binaire : Google ne boycotte pas une page lente, il espace juste ses visites.

Par contre, Mueller reste vague sur les seuils précis. À partir de combien de secondes le crawl budget commence-t-il à souffrir ? [À vérifier] dans vos propres logs, parce que Google ne publie aucun chiffre officiel. Les retours terrain suggèrent qu'au-delà de 1-2 secondes de TTFB moyen, ça commence à coincer.

Faut-il relativiser l'impact de la vitesse sur le ranking ?

Attention à ne pas mélanger les sujets. La vitesse reste un facteur de classement direct via Core Web Vitals et la page experience. Ce que dit Mueller, c'est juste que ça ne bloque pas l'indexation pure.

Mais une page indexée qui ne se classe jamais ne sert à rien. Donc non, ce n'est pas parce que Google indexe vos pages lentes que vous pouvez négliger les perfs. Vous serez juste dans l'index, mal classé, et crawlé moins souvent. Triple peine.

Dans quels cas cette règle ne change-t-elle rien ?

Si votre site génère peu de contenu neuf (site vitrine statique, quelques pages produits), le crawl budget n'est pas votre priorité. Google passera de toute façon assez souvent pour capter vos rares mises à jour.

Le vrai danger concerne les sites à fort volume : e-commerce avec milliers de fiches produits, agrégateurs de contenu, sites d'actualité. Là, un serveur lent peut carrément empêcher Google de découvrir vos nouveaux contenus dans des délais acceptables. Une fiche produit indexée 3 semaines après sa publication, c'est mort commercialement.

Que faut-il optimiser en priorité pour le crawl ?

Concentrez-vous sur le Time To First Byte (TTFB), pas sur le Largest Contentful Paint. Googlebot télécharge le HTML brut, il se fiche de savoir si votre hero image met 4 secondes à s'afficher.

Auditez vos logs serveur pour identifier les pages avec des TTFB supérieurs à 1 seconde. C'est là que le crawl budget part en fumée. Regardez aussi la taille de vos réponses HTML : un code source de 500 Ko avec du contenu dupliqué en inline ralentit inutilement le téléchargement.

Comment vérifier l'impact réel sur votre crawl budget ?

Google Search Console affiche les statistiques d'exploration : nombre de pages crawlées par jour, temps de téléchargement moyen, erreurs serveur. Si vous voyez une chute progressive du nombre de requêtes quotidiennes alors que votre contenu augmente, c'est un signal.

Croisez ces données avec vos logs serveur pour identifier les patterns. Certains sites voient Googlebot limiter son crawl sur des plages horaires spécifiques parce que le serveur rame pendant les pics de trafic. Résultat : les nouvelles pages publiées à 14h ne sont crawlées que le lendemain à 3h du matin.

Quelles erreurs éviter absolument ?

Ne sacrifiez pas la vitesse serveur au profit de features inutiles. Les frameworks JS lourds qui tournent côté serveur (SSR mal optimisé) peuvent multiplier par 10 votre TTFB sans bénéfice réel pour l'utilisateur.

Autre piège : les CDN mal configurés qui ajoutent de la latence au lieu d'en retirer. Un cache qui se vide toutes les 5 minutes ne sert à rien si Googlebot tombe systématiquement sur un cache miss. Pensez aussi à vos redirections en chaîne : chaque saut ajoute une requête et du temps.

• Mesurez votre TTFB moyen sur un échantillon représentatif de pages stratégiques
• Auditez les logs serveur pour tracer la fréquence de crawl réelle par section du site
• Optimisez la génération HTML côté serveur avant de toucher au front-end
• Vérifiez que votre CDN ne pénalise pas le TTFB pour les bots
• Surveillez les stats d'exploration dans GSC chaque semaine, pas une fois par trimestre
• Testez vos nouvelles pages en conditions réelles avec un délai d'indexation mesuré