Qu'est-ce que Googlebot ? Exploration, rendu et indexation expliqués

TL ; DR : Googlebot n’est pas un seul robot mais une famille de crawlers, et Googlebot Smartphone pilote quasiment tout depuis que l’indexation mobile-first est devenue la valeur par défaut en 2023. Son travail se déroule en trois phases (crawl, rendu, indexation) espacées de quelques heures à plusieurs jours ; la plupart des plaintes « Googlebot ne voit pas ma page » surviennent en réalité pendant la phase de rendu. Sur les tickets d’assistance traités chez SEOJuice entre mi-2024 et début 2026, environ 6 signalements d’indexation sur 10 étaient dus au rendu ; seuls 2 sur 10 relevaient vraiment du crawl (le reste venait de balises noindex ou de mauvaises règles robots.txt). Ce guide présente la famille de bots, le pipeline en trois phases, la procédure pour vérifier qu’un hit provient bien de Googlebot, les questions récurrentes sur les robots et le crawl budget, ainsi qu’une comparaison 2026 entre Googlebot, Bingbot, GPTBot, PerplexityBot et ClaudeBot.

Mise à jour : mai 2026. Ajout des données propriétaires issues des tickets SEOJuice, d’une anecdote nommément citée sur une panne Cloudflare due au Bot Fight, et d’un rappel dans la section IA renvoyant aux modes d’échec du rendu JS décrits plus haut.

J’ai écrit cet article parce que j’envoie le même pavé explicatif sur Intercom trois ou quatre fois par semaine. Le client affirme « Googlebot est bloqué sur mon site ». On ouvre Search Console : le crawl est OK, c’est le rendu qui a planté la semaine précédente quand un dev a refondu un panneau d’onglets sans voir que le corps de l’article ne se monte qu’après un clic. Je voulais une URL à coller dans le ticket au lieu de retaper le même paragraphe. Voici cette URL.

Googlebot, c’est quoi exactement ? (version simple)

Googlebot est le programme que Google utilise pour récupérer des pages web afin de les ajouter à l’index Google. Quand vous publiez un billet de blog qui finit par apparaître dans les résultats de recherche, tout commence par Googlebot qui demande l’URL, télécharge le HTML, exécute le JavaScript et transmet le résultat au système d’indexation. Sans Googlebot, vos pages n’existent tout simplement pas pour Google Search.

Deux précisions utiles dès le départ. « Googlebot » est parfois utilisé comme synonyme de « tout crawler Google ». Techniquement, Googlebot est le crawler qui alimente l’index principal de la recherche Google. D’autres crawlers existent (AdsBot pour la qualité des pages d’atterrissage, Storebot pour Shopping, Google-Extended pour l’opt-out IA) avec leurs propres règles et cadences. Soyez précis sur celui que vous diagnostiquez.

Googlebot n’est pas non plus un scraper. Il lit votre fichier robots.txt avant chaque crawl, respecte les balises noindex, se modère si votre serveur ralentit et s’identifie dans les en-têtes HTTP, ce qui vous permet de vérifier que la requête vient réellement de Google. Si un prétendu « Googlebot » matraque votre origin sans se retenir, il y a 99 % de chances que ce ne soit pas le vrai. Vérifiez avant de le rate-limiter.

Googlebot est en réalité une famille de crawlers

Celui qui vous concerne le plus est Googlebot Smartphone, qui crawl par défaut la version mobile de votre site depuis la finalisation de l’indexation mobile-first mi-2023. Les crawl desktop existent toujours, mais sont désormais secondaires. Voici l’arbre généalogique avec les chaînes user-agent officielles :

Le placeholder W.X.Y.Z n’est pas littéral : Google remplace par la version Chromium courante, mise à jour au rythme de Chrome stable. À la rédaction, le moteur de rendu de Googlebot suit de quelques semaines la version publique de Chrome. (Pendant longtemps je disais aux clients de considérer que Googlebot rendait comme Chrome 41 ; c’était vrai jusqu’à la mise à jour « evergreen » de 2019. J’ai continué à donner ce mauvais conseil jusqu’en 2021, avant qu’une conf de Martin Splitt dans « Search Off the Record » ne me force à lire la doc.) Si votre site requiert une feature JavaScript supportée à partir de Chrome 130, Googlebot la gère probablement. Au-delà, non.

Le pipeline en trois phases : Crawl, Rendu, Indexation

Le travail de Googlebot se divise en trois étapes distinctes. Elles ne se produisent pas simultanément, et un retard ou un échec à n’importe laquelle peut empêcher votre page d’apparaître. La doc Google le résume : « Google traite les applications web JavaScript en trois phases principales : 1. Crawling 2. Rendering 3. Indexing. » Si vous ne pouvez pas nommer la phase où se situe le problème, vous devinez la solution. Toute la raison d’être de cet article est là.

Phase 1 : Crawling

Googlebot sélectionne une URL de sa file, envoie une requête HTTP et reçoit le HTML brut. Fin de la phase. Aucun JavaScript n’est exécuté. Le crawler lit le code de statut, les en-têtes (cache, X-Robots-Tag, redirections) et le corps HTML. Les URL proviennent des sitemaps XML, des liens internes déjà indexés, des liens externes et des soumissions manuelles via l’inspection d’URL.

Si votre HTML contient déjà tout le contenu à indexer (rendu côté serveur classique), Googlebot peut avancer. Si le HTML est quasi vide et que le contenu arrive via JS, la page part en phase de rendu. C’est aussi ici que Googlebot lit robots.txt. Si une URL est interdite, Googlebot ne la télécharge même pas.

Phase 2 : Rendu

Si la page a besoin de JavaScript, Googlebot la transmet au Web Rendering Service (WRS). Le WRS est un Chromium headless qui charge la page, exécute les scripts et produit le HTML final. Google l’explique clairement : « Dès que les ressources le permettent, un Chromium headless rend la page et exécute le JavaScript. »

L’expression « dès que les ressources le permettent » en dit long. Le rendu coûte cher ; Google le batch et le met en file. Une page peut attendre quelques secondes, des heures, voire des jours. (J’ai une capture de 2024 montrant 96 heures entre crawl et rendu sur un site e-commerce Next.js, que je garde épinglée pour gagner certains débats.) La doc reste floue : « La page peut rester dans cette file quelques secondes, mais cela peut être plus long. » Je n’ai jamais percé le secret de la priorité dans la file ; des sites quasi identiques reçoivent un rendu en 5 minutes ou 36 heures sans logique apparente.

Ce délai de rendu est le vrai souci des sites JS. Votre article peut être crawlé en minutes mais pas rendu avant 24 h ; il n’apparaît donc pas en recherche avant le lendemain. Les pages SSR évitent complètement cette file.

Phase 3 : Indexation

Une fois le HTML final obtenu (directement ou via le WRS), le système d’indexation analyse le document, extrait le texte, classe le contenu, évalue les signaux de ranking et stocke le tout. La page devient alors éligible aux résultats de recherche. L’indexation prend encore quelques minutes ou heures, mais le job de Googlebot est terminé ; la suite dépend des algos de ranking.

Ce qui casse le rendu JavaScript (et comment le détecter)

C’est au rendu que ça se brise. Le crawl réussit presque toujours ; la page ne se rend simplement pas comme prévu. Voici les six causes que je vois le plus chez SEOJuice, par ordre décroissant ; les deux premières comptent pour plus de la moitié des escalades de rendu selon l’échantillon cité en TL;DR.

1. Contenu nécessitant une interaction utilisateur pour se charger

Si un bouton « Afficher plus » est le seul moyen de dévoiler une section, Googlebot ne la verra pas. Le WRS exécute JS mais ne clique ni ne scrolle. Tout élément important doit être présent dans le DOM au chargement, même masqué via CSS. C’est l’échec n°1, souvent dans des bibliothèques qui montent en lazy des onglets, accordéons ou feeds « load more ».

2. Lazy-loading sans signaux adéquats

Les images et blocs lazy doivent utiliser loading="lazy" ou un Intersection Observer que le WRS puisse résoudre. Les librairies custom basées sur l’évènement scroll échouent car il n’y a pas de scroll. Utilisez loading="lazy" pour les images ; pour les composants, rendez côté serveur ou utilisez un framework SSR/hydratation.

3. Erreurs JavaScript à l’exécution

Si un script en haut de page lance une exception non captée, les suivants ne tournent pas et la page reste vide. Le WRS voit ce qui est rendu avant l’erreur. L’outil d’inspection d’URL → « Afficher la page testée » montre le HTML rendu et une capture.

4. Règles WAF et anti-bots

CAPTCHA, Cloudflare Bot Fight trop agressif, blocage géo naïf : tout ça peut renvoyer un 403 ou une page de défi aux IP de Googlebot. (Le Bot Fight par défaut de Cloudflare a causé plus d’incidents clients qu’aucun autre réglage : un SaaS B2B a perdu ⅔ de ses pages indexées en un week-end fin 2024 après qu’un stagiaire sécu l’a activé ; trois semaines de resoumissions pour revenir à la normale. Je finirai par en faire un billet.) Liste blanchez les plages IP Google publiées (googlebot.json), et testez avec l’inspection d’URL à chaque changement WAF.

5. Ressources bloquées dans robots.txt

Si robots.txt interdit /static/ ou /assets/, le WRS ne peut pas charger vos bundles JS/CSS : la page s’affiche cassée. Autorisez Googlebot sur les assets statiques, même si vous bloquez d’autres chemins.

6. Contenu derrière authentification ou cookies

Googlebot ne s’authentifie pas, n’accepte pas les cookies de manière exploitable et ne maintient pas de session. Tout ce qui est derrière un login ne sera pas indexé. Utilisez l’API d’indexation ou des données structurées pour le contenu payant si besoin et indiquez clairement ce qui est protégé.

La communauté SEO a débattu 2017-2020 pour savoir si le renderer de Googlebot rattraperait Chrome. Le débat est clos : depuis l’update evergreen 2019, il suit Chrome stable. Beaucoup de conseils en circulation datent d’avant, d’où la persistance des points 1 et 2 ci-dessus.

Comment vérifier qu’une requête vient vraiment de Googlebot

La chaîne user-agent Googlebot est trivialement spoofable. La seule vérification fiable passe par l’IP : reverse DNS puis forward DNS. Procédure concrète :

1. Récupérez l’IP dans vos logs.
2. Reverse DNS : l’hostname doit finir par .googlebot.com ou .google.com.
3. Forward DNS sur cet hostname : il doit rediriger vers la même IP.
4. Si les deux passent, c’est le vrai Googlebot ; sinon, c’est un faux.

En CLI : host 66.249.66.1 puis host crawl-66-249-66-1.googlebot.com. Sur un site à fort trafic, automatisez-le ; vous découvrirez que bien des « pics Googlebot » sont des scrapers tiers. Ahrefs propose un pas-à-pas similaire avec des exemples curl.

robots.txt et crawl budget : les questions tactiques

Quelle quantité de crawl Googlebot consacrera-t-il à mon site ?

C’est le crawl budget. Pour les sites < 10 000 URLs, rarement un problème. Googlebot crawle tout ce qui compte en temps raisonnable. Le sujet devient réel sur les sites à millions d’URLs, e-commerce à facettes ou duplication massive. Deux facteurs : taux de crawl (vitesse supportée sans erreurs) et demande de crawl (popularité, fréquence de mise à jour). Semrush détaille les signaux de taux de crawl dans son guide Googlebot.

Dois-je bloquer Googlebot sur les URLs à faible valeur ?

Oui, sur un gros site si elles grignotent le crawl budget. Classique : bloquer les URLs facettées, la recherche interne, les pages d’archive paginées au-delà de la page 5, les variantes avec ID de session, les endpoints admin. Utilisez robots.txt pour bloquer le crawl et la balise noindex pour bloquer l’indexation ; ce n’est pas la même chose.

Comment accélérer l’indexation d’une nouvelle page ?

Soumettez-la via l’inspection d’URL dans Search Console. Cela déclenche un crawl hors file (Google-InspectionTool) plus rapide. Liez aussi la page depuis une page à forte autorité déjà indexée, afin que le prochain crawl régulier la découvre via le graph de liens.

Pourquoi Googlebot crawl-t-il mon environnement de dev ?

Parce qu’une URL de staging/dev a fuité publiquement (lien, résultat de recherche, tracker d’issues). Bloquez tout le domaine de staging dans robots.txt avec Disallow: / et ajoutez une auth basique si c’est sensible.

Déboguer « Googlebot ne voit pas cette page »

La méthode systématique comporte quatre vérifs, dans l’ordre, jusqu’à obtenir une réponse claire.

Vérif 1 : inspection d’URL dans Search Console. Collez l’URL. L’outil indique si Google l’a crawlée/ indexée, quand, et permet « Afficher la page testée ». Si le HTML rendu manque de contenu → problème de rendu. Si le statut ≠ 200 → problème de crawl. En pratique, cela résout ~2/3 des tickets.

Vérif 2 : curl avec l’UA Googlebot. curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://votresite.com/path. Si votre serveur sert un contenu différent à Googlebot, vous le verrez. Cloaking volontaire ou accidentel = source fréquente de mystères.

Vérif 3 : audit robots.txt et balises meta. Ouvrez https://votresite.com/robots.txt. Vérifiez le non-blocage. Puis cherchez noindex dans le code source. Une part étonnante des cas « page non indexée » vient d’une balise laissée depuis la préprod.

Vérif 4 : analyse des logs serveur. Filtrez les requêtes Googlebot vérifiées sur 30 jours. Si l’URL n’apparaît jamais → problème de découvrabilité ; ajoutez-la au sitemap et liez-la. Si elle apparaît mais répond toujours 4xx/5xx, corrigez l’erreur puis renvoyez. SEOJuice exécute cette analyse et alerte dès qu’une URL critique disparaît du trafic Googlebot.

Googlebot vs Bingbot vs les crawlers IA

Googlebot n’est plus le seul crawler à considérer ; le paysage a changé. Comparatif 2026 :

Remarquez que les modes d’échec 1, 2 et 5 du rendu JS — interaction utilisateur, lazy-load mal signalé, assets bloqués — touchent encore plus les crawlers IA que Googlebot car leurs renderers sont plus faibles. Le même check-list s’applique pour un problème de citation Perplexity ; l’enjeu est juste plus faible côté IA search… pour l’instant.

Deux implications : les crawlers IA disposent d’un rendu JS moins robuste. Si votre contenu dépend du client-side, vous pouvez très bien ranker sur Google mais être invisible pour ChatGPT, Perplexity ou Claude — ils voient une page vide. La solution est la même que pour Googlebot : SSR ou pré-rendu. Notre outil de vérification de visibilité IA vous dira en une minute quels moteurs voient réellement votre contenu. Par ailleurs, chaque crawler IA a ses directives robots.txt. User-agent: GPTBot bloque OpenAI, User-agent: Google-Extended bloque Gemini, User-agent: Googlebot reste indépendant. Vous pouvez autoriser Google Search tout en bloquant l’IA.

« Ce que les gens ratent le plus sur Googlebot, c’est que crawl et rendu ne sont pas la même étape. Une URL peut être crawlée et ne disposer d’une version rendue qu’heures plus tard. » — Martin Splitt, Google Search Relations, paraphrasé de ses interventions récurrentes dans Search Off the Record.

FAQ

Qu’est-ce que Googlebot ?

Le crawler web de Google qui découvre et télécharge les pages pour les indexer. C’est une famille de robots (Smartphone, Desktop, Image, Video, News) aux UA et objectifs distincts, mais on parle le plus souvent de Googlebot Smartphone, crawler principal depuis 2023.

Googlebot exécute-t-il le JavaScript ?

Oui. Le Web Rendering Service, un Chromium headless, exécute le JS. Sa version suit Chrome stable, donc les features modernes fonctionnent généralement. Attention : la file de rendu peut retarder l’indexation de quelques secondes à quelques jours. Les pages SSR ne passent pas par cette file.

Comment vérifier qu’une requête est vraiment Googlebot ?

Reverse DNS sur l’IP : le hostname doit finir par .googlebot.com ou .google.com. Puis forward DNS sur ce hostname : retour à la même IP. Si l’un échoue, c’est un spoof. La chaîne user-agent seule ne prouve rien.

Puis-je bloquer Googlebot ?

Oui. Dans robots.txt : User-agent: Googlebot puis Disallow: /. Cela bloque le crawl donc l’indexation. Pour un contrôle plus fin, utilisez noindex sur des pages individuelles ou bloquez des chemins précis dans robots.txt. Ne bloquez pas Googlebot sur vos bundles CSS/JS, le renderer en a besoin.

Googlebot est-il le même robot que GPTBot ou PerplexityBot ?

Non. Ce sont des crawlers différents, opérés par d’autres sociétés et pour d’autres usages. Googlebot alimente Google Search, GPTBot collecte des données pour ChatGPT, PerplexityBot sert le moteur de réponses Perplexity. Chacun son UA et ses directives robots.txt. Vous pouvez autoriser Googlebot et bloquer GPTBot, etc.

Pourquoi Googlebot n’a-t-il pas encore indexé ma nouvelle page ?

Causes les plus fréquentes : la page n’est liée depuis aucune URL indexée, renvoie un statut ≠ 200, comporte une balise noindex, est bloquée par robots.txt, ou dépend d’un JS que le renderer n’a pas encore traité. Utilisez l’inspection d’URL pour voir laquelle. Les pages neuves mettent quelques heures à quelques jours à être indexées, plus si le crawl rate est bas.

Ce que cela implique vraiment pour votre site

L’implication pratique, formulée comme une position : si votre contenu dépend du JavaScript et que votre seul KPI est « ranke-t-il sur Google », vous optimisez pour le renderer le plus fort et ignorez le reste. Les crawlers IA sont plus faibles, et leur part de trafic grandit chaque trimestre. Le SSR n’est plus un « bonus Google » ; c’est un prérequis de visibilité IA. C’est l’idée la plus utile à retenir.

Pour savoir rapidement quels crawlers voient votre site, notre test de visibilité IA rend votre URL sous les mêmes contraintes que Googlebot, GPTBot, PerplexityBot et ClaudeBot, et vous montre lesquels lisent une page vide. La plupart des audits révèlent au moins un template critique (souvent produit ou blog) rendu vide pour Perplexity alors qu’il est OK pour Google.

Ce que je n’ai pas encore élucidé : la logique de priorité dans la file de rendu. La doc parle de ressources, mais la variance observée suggère autre chose. Si vous avez un jeu de données clair avant/après, je suis preneur.

Lectures associées :

• SEO pour les Single Page Applications
• Answer Engine Optimization (AEO)
• Outil d’audit SEO gratuit
• Test de visibilité IA gratuit