Qu’est-ce que l’exploration (crawling) en SEO ? Comment les bots des moteurs de recherche lisent votre site

TL;DR : Un crawl SEO correspond à l’étape de découverte et de téléchargement. Googlebot trouve une URL, récupère son contenu et peut aussi rendre son JavaScript. Le crawling ne garantit ni l’indexation ni le classement : identifiez donc si l’échec vient du crawl, du rendu, de l’indexation ou du ranking avant de modifier votre site.

La plupart des problèmes de crawl se diagnostiquent “par la mauvaise extrémité”. Une page n’apparaît plus dans les résultats de recherche, quelqu’un en déduit que Google ne l’a pas crawlé, et robots.txt est modifié. Pourtant, Google a peut-être déjà récupéré la page et décidé de ne pas l’indexer, sélectionné une autre URL canonique, ou simplement estimé qu’elle ne méritait pas de se classer pour la requête contrôlée.

Crawl, render, index et rank sont des étapes distinctes. Google place officiellement le rendu dans la phase de crawl, mais les dissocier pendant le diagnostic rend beaucoup plus facile la localisation des défaillances techniques.

Ce que “crawling” signifie vraiment en SEO

Google Search Central définit le crawling de façon simple :

« Crawling : Google télécharge le texte, les images et les vidéos depuis les pages qu’il trouve sur Internet à l’aide de programmes automatisés appelés crawlers. »

Concrètement, le crawling correspond à la découverte plus la récupération. Google comprend qu’une URL existe et demande son contenu afin que la page puisse être traitée ensuite.

Le programme qui effectue ce travail s’appelle Googlebot. Google le décrit comme « également connu sous les noms crawler, robot, bot ou spider. » Ces noms désignent le même type général de logiciel : un programme automatisé qui demande des pages et suit des liens pour découvrir d’autres URL.

Googlebot n’inspecte pas votre site en “cliquant partout” comme le ferait une personne. Il demande le HTML et les ressources associées. Pendant la phase de crawl, Google peut aussi rendre la page avec une version récente de Chrome et exécuter son JavaScript. C’est crucial si votre texte important, votre navigation ou vos liens internes n’existent qu’une fois les scripts exécutés.

Un détail supplémentaire, facile à rater : Googlebot est majoritairement mobile. Google indique : « Pour la plupart des sites, Google Search indexe principalement la version mobile du contenu. Ainsi, la majorité des requêtes de crawl de Googlebot seront faites avec le crawler mobile, et une minorité avec le crawler desktop. » Si un contenu important existe sur la version desktop mais est absent sur la version mobile, des tests desktop “qui passent” peuvent vous donner une fausse impression de sécurité.

J’ai déjà passé du temps à corriger la mauvaise étape. Le fait qu’une URL ne soit pas dans la recherche ne prouve pas que la découverte a échoué, et demander un nouveau crawl ne réparera pas forcément une duplication ou un contenu peu utile (une erreur de catégorie frustramment courante).

Crawl, render, index et rank : des jobs différents

1. Crawl : découvrir et télécharger

Googlebot doit d’abord savoir qu’une URL existe. Une fois découverte, il tente de récupérer le HTML brut de la page et les ressources nécessaires. Une restriction via robots.txt, une panne DNS ou réseau, un timeout, ou une erreur serveur peuvent stopper le processus ici.

Un fetch réussi fait passer l’URL à travers la première étape. Rien de plus.

2. Render : exécuter la page

Google inclut officiellement le rendu dans le crawling, mais il vaut mieux tester séparément (pas comme une quatrième étape officielle, à être précis). Google indique qu’au cours du crawling il rend des pages et exécute du JavaScript via une version récente de Chrome, un peu comme un navigateur “normal”.

Pour les applications JavaScript, Google documente la séquence de fonctionnement comme étant crawling, rendering et indexing. Les pages qui renvoient une réponse réussie peuvent entrer dans une file de rendu, où Chromium headless exécute leur JavaScript. Google Search utilise une version “evergreen” de Chromium plutôt qu’une version de navigateur figée.

Cela crée une séparation diagnostique importante. Googlebot peut récupérer une page qui renvoie un HTTP 200 tout en échouant à voir son contenu final. Des ressources bloquées, des erreurs de script, du contenu côté client retardé, ou des liens qui n’apparaissent qu’après interaction utilisateur peuvent laisser le rendu incomplet.

3. Index : analyser et stocker

Google définit l’indexation comme l’analyse du texte, des images et des vidéos d’une page, puis le stockage d’informations dans l’index Google. Pendant ce processus, Google évalue aussi les doublons et choisit l’URL qu’il considère comme canonique.

Une page crawlée n’est pas automatiquement indexée. Une directive noindex peut l’exclure. Google peut aussi refuser d’indexer un contenu trop “thin” ou fortement dupliqué, ou consolider la page sous une autre URL canonique. Notre guide sur comment fonctionne l’indexation chez Google détaille plus précisément cette passation.

4. Rank et serve : répondre à une requête

“Indexée” signifie éligible à apparaître. Cela ne veut pas dire visible pour chaque recherche, ni garantie d’une position donnée. Google doit encore décider que la page correspond à la requête et déterminer où elle se place parmi les autres résultats éligibles.

• Une URL peut être découverte mais ne pas être récupérée correctement.
• Elle peut être récupérée mais rendue de façon incorrecte.
• Elle peut être rendue mais exclue de l’index.
• Elle peut être indexée mais échouer à se classer pour la requête que vous vérifiez.

Google donne aux propriétaires de sites un contrôle de réalité utile : « Google ne garantit pas qu’il va crawler, indexer ou afficher votre page, même si votre page respecte les Google Search Essentials. » L’accessibilité technique est nécessaire. Ce n’est pas une promesse d’inclusion ou de visibilité.

Comment Google découvre les pages

Google ne commence pas avec un répertoire complet de toutes les URL présentes sur le web. Sa documentation identifie trois voies principales de découverte :

1. Revisiter des URL connues. Google retourne sur les pages qu’il a déjà récupérées.
2. Suivre des liens. Google extrait un lien depuis une page connue et découvre sa destination.
3. Lire des sitemaps. Google traite les listes d’URL soumises par les propriétaires de sites.

C’est pour cela que le maillage interne est une infrastructure, pas de la décoration. Une page sans lien interne pointant vers elle est orpheline. Elle peut exister dans le CMS et apparaître dans le sitemap XML tout en restant déconnectée des parcours que Googlebot suit normalement.

L’étude de Cyrus Shepard, “study of roughly 23 million internal links” sur environ 1 800 sites, met en évidence une relation directionnelle entre liens internes et clics Google : « Les URL avec 0 à 4 liens internes ont reçu en moyenne 2 clics depuis la recherche Google, tandis que les URL avec 40 à 44 liens internes ont reçu 4 fois plus de clics. » Il s’agissait d’une corrélation, pas d’une preuve que l’ajout de liens multiplie mécaniquement le trafic.

L’étude a aussi trouvé que l’effet s’inverse après environ 45 à 50 liens internes. “Plus” n’est pas toujours “mieux”. La conclusion utile est que les pages importantes ont besoin de plusieurs parcours de crawl pertinents, pas que chaque page reçoive des dizaines de liens arbitraires.

Ce que nous observons sur SEOJuice à travers les sites, c’est que les pages orphelines et les routes internes faibles apparaissent bien plus souvent que de vrais problèmes de capacité de crawl. La correction consiste le plus souvent à connecter la page depuis du contenu déjà indexé, pertinent, et à la conserver dans le sitemap. Une structure cohérente comme les content silos pour le SEO offre aux crawlers des parcours répétables entre pages liées.

J’avais tendance à traiter l’inclusion dans le sitemap comme une preuve plus forte qu’elle ne l’est. Elle prouve qu’une URL a été fournie à Google, pas que Google l’a récupérée ou indexée (j’interprétais trop le signal). Un sitemap aide à la découverte ; il ne remplace pas le maillage interne et ne force aucun résultat.

Pour une URL nouvelle ou mise à jour unique, l’outil URL Inspection dans Google Search Console propose aussi une action Request Indexing. Cela ajoute une requête à la file de traitement de Google. C’est une impulsion, pas un ordre.

robots.txt, noindex et nofollow ne font pas la même chose

robots.txt contrôle la récupération

Un fichier robots.txt indique aux crawlers conformes quelles URL ils ont le droit d’explorer. Google explique qu’il est principalement utilisé pour éviter que les requêtes de crawl ne surchargent un site.

Ce n’est pas un outil de suppression fiable. La documentation robots.txt de Google indique que « Une page interdite dans robots.txt peut quand même être indexée si elle est liée depuis d’autres sites » et qualifie explicitement ce fichier de « non mécanisme pour empêcher une page web d’apparaître dans Google. » Google peut savoir qu’une URL bloquée existe sans être autorisé à en récupérer le contenu.

Vérifiez chaque règle générale avant publication. Un Disallow: / en production contient très peu de texte et peut retirer l’accès de Googlebot à l’ensemble du site. Le générateur robots.txt peut aider à rédiger un fichier, mais la sortie doit quand même être testée sur vos chemins importants.

noindex contrôle l’éligibilité à l’indexation

Utilisez noindex quand Google peut crawler une page, mais ne doit pas la conserver dans les résultats de recherche. Ne désactivez pas simultanément cette URL dans robots.txt. Google doit récupérer la page pour lire sa directive noindex.

Appliquer les deux peut produire l’effet inverse de la certitude recherchée. La restriction de crawl empêche Google de voir l’instruction d’indexation : l’URL bloquée peut alors rester connue via des liens externes ou internes.

nofollow est un indice au niveau du lien

L’attribut nofollow n’est pas une interdiction de crawl au niveau de la page. Google le traite comme un indice, pas comme un blocage garanti. Il ne devrait pas être utilisé pour masquer une URL, protéger du contenu privé, ou garantir une exclusion de l’index.

La navigation à facettes est l’endroit où ces définitions “propres” deviennent moins confortables. Il n’existe pas de modèle robots.txt universellement sûr pour chaque catalogue. Certaines URL filtrées correspondent à des recherches distinctes ; d’autres créent des combinaisons quasi infinies. Bloquer d’abord puis cartographier la valeur ensuite est risqué (et oui, c’est un des rares domaines où je me méfie des “fix” en une ligne).

Vous n’avez probablement pas un problème de crawl-budget

Le crawl budget correspond à l’ensemble des URL que Google peut et veut crawler. Google décrit deux composantes : la limite de capacité de crawl, qui tient compte des connexions en parallèle, du temps de réponse et de la santé serveur ; et la demande de crawl, qui reflète des facteurs comme la taille du site, la fréquence de mise à jour, la qualité, la popularité et l’obsolescence.

Le terme sonne assez important pour inquiéter n’importe quel propriétaire de site. Les seuils de Google disent le contraire.

« Si votre site n’a pas un grand nombre de pages qui changent rapidement, ou si vos pages semblent être crawlées le même jour qu’elles sont publiées, vous n’avez pas besoin de lire ce guide. »

Google adresse ses recommandations de crawl-budget principalement aux sites de plus d’un million de pages uniques qui changent environ chaque semaine, ou aux sites de plus de 10 000 pages uniques qui changent quotidiennement. Pour la majorité des sites plus petits, maintenir le sitemap et vérifier la couverture d’indexation suffit.

Si vous publiez un nombre modeste d’URL et que Google récupère les nouvelles pages rapidement, arrêtez d’essayer d’optimiser le crawl budget. Corrigez plutôt les parcours de découverte cassés, les directives accidentelles, les échecs de rendu, les erreurs serveur, ou la qualité du contenu. Pour les sites réellement très volumineux ou très dynamiques, notre guide d’optimisation du crawl budget couvre les cas plus difficiles.

Comment voir ce que Google crawl

Commencez par l’Inspection d’URL

Pour une page manquante, l’outil URL Inspection dans Google Search Console est le point de départ le plus rapide. Il peut afficher la date du dernier crawl, si le crawling est autorisé, l’état d’indexation et la canonique sélectionnée par Google.

Interprétez ces champs dans l’ordre. Si le crawling a été bloqué, réparez l’accès. Si Google a crawlé l’URL mais l’a exclue de l’index, une autre demande de crawl a peu de chances de résoudre le problème sous-jacent.

Utilisez Crawl Stats pour repérer des schémas à l’échelle du site

Le rapport Crawl Stats montre l’historique de crawl de Google, y compris le nombre de requêtes, la taille totale téléchargée, le temps de réponse moyen, les réponses serveur, les problèmes de disponibilité, les types de fichiers, l’objectif du crawl et le type de Googlebot.

Google le présente comme un rapport “avancé” et indique que les sites de moins de 1 000 pages ne devraient généralement pas en avoir besoin. C’est raisonnable. Je le consulte encore après des migrations ou des changements abrupts à l’échelle du site, mais ce n’est pas un tableau de bord quotidien utile (plus de crawling n’est pas automatiquement une bonne chose).

Utilisez les logs serveur pour des requêtes exactes

Les logs d’accès serveur enregistrent les requêtes qui ont réellement atteint votre infrastructure. Ils peuvent révéler quelles URL Googlebot récupère, à quelle fréquence il visite chaque section, et si des paramètres ou des URL “poubelle” reçoivent de l’attention pendant que des pages utiles sont rarement visitées.

Les chaînes user-agent de Googlebot contiennent Googlebot/2.1, mais le texte user-agent peut être imité. Pour une identification fiable, vérifiez les requêtes suspectées comme venant de Googlebot via le reverse et le forward DNS, plutôt que de vous fier uniquement à la chaîne.

Pour la plupart des sites, une activité “réelle” de Googlebot devrait rester assez discrète. Google indique : « Pour la plupart des sites, Googlebot ne devrait pas accéder à votre site plus d’une fois toutes les quelques secondes en moyenne. »

Cinq échecs de crawl SEO à corriger en priorité

1. Pages orphelines et quasi-orphelines

Une page orpheline n’a aucun chemin de lien interne depuis le reste du site. Une quasi-orpheline peut avoir un lien peu visible depuis une page d’archive ou de pagination, que Google revisite rarement. Ajoutez plutôt des liens contextuels depuis des pages pertinentes déjà indexées, au lieu de vous reposer uniquement sur le sitemap.

C’est généralement le premier problème structurel que je vérifie. L’URL existe, donc l’équipe suppose que le site l’expose correctement. Ce ne sont pas la même chose.

2. JavaScript ou CSS bloqués

Google rend les pages avec Chromium. Si robots.txt bloque des ressources nécessaires pour afficher le contenu ou la navigation, la requête HTML peut réussir tandis que la page rendue reste incomplète.

Comparez la sortie rendue par Google avec ce que voient les utilisateurs, en particulier sur les applications rendues côté client dont le HTML initial contient peu de contenu réellement substantiel.

3. Pièges de crawl infinis

Les filtres, les paramètres de tri, les calendriers, les pages de recherche et les identifiants de session peuvent générer un volume énorme de combinaisons d’URL peu utiles. Sur les gros sites, cela devient un vrai problème de crawl.

Les remèdes fréquents incluent la consolidation des doublons via des canonicals, la limitation des combinaisons de paramètres explorables et le blocage de patterns appropriés. Cartographiez les combinaisons qui méritent d’être indexées avant de les restreindre ; une règle globale peut supprimer des pages catégories utiles avec les URL “junk”.

4. Serveurs lents ou peu fiables

Google ajuste la capacité de crawl en fonction de la santé serveur. Des timeouts persistants, des réponses lentes et des erreurs 5xx peuvent amener Google à réduire le crawling. Crawl Stats peut révéler les changements agrégés de temps de réponse, tandis que les logs identifient les templates et les URL qui les provoquent.

5. Blocs de production accidentels

Vérifiez les règles robots.txt de staging déployées en production, les directives noindex déployées à l’échelle du site, les assets bloqués et les réglages du CMS prévus pour décourager les moteurs de recherche. Ce sont des échecs “basiques” avec des conséquences sur tout le site.

Pendant notre migration de seojuice.io vers seojuice.com en janvier 2026, nous avons traité la découverte, la récupération, la sélection de canonique et l’indexation comme des contrôles séparés. Le fait qu’une URL sur l’ancien host soit recrawlée ne prouvait pas que son remplacement sur le nouvel host ait été indexé, et une redirection correcte ne prouvait pas non plus que Google avait encore basculé sa canonique. Cette séparation nous a évité de réduire la migration à une case “Google voit ça”.

Nous sommes une équipe de deux, Lida et moi, donc l’ordre du diagnostic compte. Nous ne pouvons pas passer des jours à polir des théories de crawl-budget pendant qu’une page orpheline ou un noindex en production fait réellement les dégâts.

Si ces problèmes récurrents sont difficiles à surveiller manuellement, SEOJuice propose un plan gratuit sans carte bancaire. Son automatisation peut ajouter des liens internes pertinents et l’audit de site signale les blocages robots.txt, les tags noindex et les ressources bloquées. Il peut corriger ou mettre en évidence des problèmes spécifiques sur le site ; il ne peut pas forcer Google à crawler plus vite, à indexer une page, ni à attribuer des positions.

Questions fréquentes

Qu’est-ce que le crawling en SEO ?

Le crawling en SEO est le processus par lequel des bots des moteurs de recherche découvrent et téléchargent des pages. Googlebot trouve des URL en revisitant des pages déjà connues, en suivant des liens et en lisant des sitemaps. Un crawl réussi ne garantit pas qu’une page sera indexée ou classée.

Quelle est la différence entre crawling et indexation ?

Crawling signifie que Google récupère une page. Indexation signifie que Google analyse la page, évalue sa canonique et peut stocker des informations la concernant dans l’index Google. Une page peut être crawlée mais ne pas être indexée à cause de noindex, de la duplication, de la qualité du contenu ou du choix de la canonique.

Qu’est-ce qu’un web crawler, un spider ou un bot ?

Un web crawler est un programme automatisé qui visite des URL, télécharge du contenu et suit des liens pour trouver d’autres pages. Le crawler de Google est Googlebot. Crawler, spider, robot et bot sont différents noms pour le même type général de logiciel.

Comment Google trouve-t-il et crawl-il mon site ?

Google revisite les URL déjà connues, suit des liens depuis des pages connues vers de nouvelles destinations, et lit les sitemaps XML soumis. Les liens internes fournissent des parcours directs de découverte, tandis que le sitemap fournit une liste utile d’URL que Google peut envisager de crawler.

robots.txt empêche-t-il Google de crawler ou d’indexer ?

robots.txt limite le crawling, pas l’indexation. Une URL bloquée peut quand même apparaître dans Google si elle est découverte via des liens. Pour empêcher une page crawlable d’entrer dans l’index, utilisez noindex et ne bloquez pas simultanément le fetch de la directive.

Comment puis-je voir ce que Google crawl ?

Utilisez l’Inspection d’URL pour le statut d’une URL, Crawl Stats pour les requêtes et schémas serveur à l’échelle du site, et les logs d’accès serveur pour les URL exactes que Googlebot a demandées. Ensemble, ces sources permettent de distinguer un véritable échec de crawl d’un problème ultérieur de rendu ou d’indexation.