Comment appréhender au mieux le Budget Crawl sur son site (2nde partie) ?

Ce tableau permettra de suivre un nombre trop élevé de redirections, ou encore la présence d’erreur serveur (ex : code 503 = Site en maintenance / Service Unavailable) ce qui aura pour effet de ralentir le crawl de Google. A ce sujet, sachez qu’il est possible de renvoyer un code réponse 503 pour le fichier robots.txt afin de provoquer un arrêt instantané du crawl : tant que ce fichier ne répondra pas à nouveau en 200, l'exploration de Google sera en pause ce qui peut s’avérer pratique pour soulager le serveur en maintenance.

Attention cependant à ce que ces erreurs de type 5xx ne soit pas trop persistantes : cela pourrait affecter les positions du site au bout de quelques jours comme l’indique Google : « Si vous renvoyez un code 503 ou 429 pendant plus de deux jours, Google supprimera ces URL de l'index ».

Plus la quantité de codes réponses 404/410 ou 500 sera élevée, plus cela se fera au détriment de pages plus pertinentes. Il est cependant normal que certaines URL d’un site répondent en 404/410, comme c’est souvent le cas sur les sites de e-commerce lorsqu’un produit n’est plus disponible à la vente (si pas de redirection vers une pages proche/similaire).

Par ailleurs, un nombre trop important de redirections peut également impacter de façon importante l’exploration de Google. Bien que ces dernières soient nécessaires en cas de migration de site, ou de déplacement d’URL, il est recommandé de modifier les liens internes qui pointent vers les URL redirigées, ce qui aura pour effet de réduire le crawl sur ces dernières (Google continuera d’effectuer des crawls de contrôle, mais de façon plus espacée dans le temps).

D’un point de vue plus global, plus une URL sera maillée, plus sa fréquence de crawl sera importante. Il est donc indispensable de bien doser la répartition des liens vers vos URL, afin d’orienter au mieux les crawlers, et leur éviter de crawler des pages inutiles.

Types de fichiers explorés

L’ensemble des fichiers explorés par Google est comptabilisé dans ses besoins d’exploration : image, JS, CSS ou tout autre ressource nécessitant d’être visité par Google peuvent augmenter l’exploration au détriment d’autres URL.

Exploration par type de ressource

 

Le nombre important de fichier JSON explorés pour le site utilisé dans cet exemple met en avant un potentiel déséquilibre dans le crawl de Google. Ces fichiers permettent à Google de mieux comprendre ce que voit l’utilisateur final, mais placer leur contenu (si leur taille n’est pas trop importante) directement dans les pages HTML pourrait améliorer le nombre de demandes d’exploration par Google.

Les requêtes externes de type AJAX/XHR qui peuvent modifier le contenu final, sont des éléments pouvant perturber le crawl, il convient donc de les utiliser de façon raisonnable pour permettre l’exploration des ressources les plus pertinentes par les robots de Google, dans la mesure du possible.

L’ensemble des éléments chargés en complément du HTML sont visibles dans le bloc par type de Googlebot :

Exploration par type de Googlebot

 

La ligne "Chargement des ressources de la page" comprend l’appel des fichiers qui sont embarqués dans le code HTML comme les images ou les CSS, qui seront récupérées par Google afin d'afficher la page avant son indexation. Grâce à ces indicateurs, il est relativement facile d’identifier les éléments qui pourraient impacter le budget d’exploration.

Autres outils

La Search Console se limite à 1 000 URL pour chaque affichage détaillé, ce qui peut vite s’avérer insuffisant sur un site à forte volumétrie. L’ajout de propriété dans la Search Console pour chaque répertoire de son site, permet d’outrepasser cette limite, mais cela reste malgré tout limité si torop de répertoires sont à traiter, et rend les analyses plus complexes.

D’autres outils permettent d’aller plus loin dans l’analyse du comportement du crawler, comme Botify, Oncrawl ou encore SEOlyzer afin d’améliorer le budget d’exploration.  L’utilisation des logs brutes côté serveur utilisés par ces outils sont une mine d’informations pour monitorer le crawl au quotidien, et détecter un déséquilibre dans les URL explorées, ou encore mettre en avant d’éventuelles fuites de crawl sur des URL non pertinentes.

Suivi détaillé du crawl de Google sur un outil d'analyse de logs

 

Il conviendra toutefois de bien filtrer les logs au préalable pour ne conserver que les vrais bots de Google (et non d’autres crawlers qui utiliseraient Googlebot comme user-agent) ; Google met d’ailleurs à la disposition des webmaster la liste de ses adresse IPV4 et IPV6 : https://developers.google.com/static/search/apis/ipranges/googlebot.json?hl=fr

Pour ce qui est des user-agent, Googlebot Desktop et GoogleBot Smartphone sont facilement identifiables : https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers . Attention cependant, car pour Google Shopping, c’est le Googlebot standard qui est utilisé pour s’assurer de la qualité des pages proposées, ce qui peut parfois fausser les analyses.

Optimisations de l’inventaire d’URL

Pour optimiser au maximum le budget d’exploration, voici les principaux axes d’amélioration qui peuvent être liées à la structure d’un site. Il est très important de garder à l’esprit que plus le nombre d’URL non pertinentes et inadaptés à l’index sera important, plus Google pourra ralentir le crawl de votre site, et ne pas augmenter son budget d’exploration pour le couvrir en intégralité

Le fichier robots.txt

Bloquer l’exploration d’URL non pertinentes via le robots.txt pourra vous permettre d’améliorer votre crawl budget : les moteurs à facettes sont souvent la source d’un nombre très important de combinaisons d’URL. Tant que Google n’a pas crawlé une URL, il ne sait pas ce qu’elle contient. Bien que les crawlers fasse du machine learning pour « crawler utile », nous constatons encore aujourd’hui que les moteurs à facettes ou encore la pagination peuvent générer un nombre très important de hits.

Les directives de restrictions de crawl sont une bonne arme pour mieux orienter les robots d’exploration. A noter que l’information « crawl-delay » du robots.txt n’est pas prise en compte par Google.

Chaines de redirection

Bien que suivies par les robots d’exploration (jusqu’à 5 redirections d’après Google), ces dernières posent des problèmes d’indexation, mais également pour le crawl de Google. Les suites de redirections (ou redirections en cascade) sont considérées comme ayant un effet négatif sur l’exploration d’un site. Il est nécessaire de  limiterau maximum ces chaînes, qui provoquent des hits intermédiaires pour Googlebot.

Chaînes de redirection

 

Dans cet exemple, il faudra adapter les redirections afin que l’URL A redirige directement vers l’URL C (sans intermédiaire). Si Google a découvert l’URL B, il faudra alors que cette dernière redirige également vers l’URL finale (URL C). A terme, son crawl vers l’URL B sera ralenti, à condition qu’elle ne reçoive pas de liens, et qu’aucune URL ne redirige vers elle.

Soft 404

Les pages de type soft 404 (pages qui répondent en 200, mais qui sont considérées comme des 404 par Google : contenu « page introuvable » ou page vide) consomment de façon inutile du budget de crawl. Ces URL sont identifiables dans la Search Console via le rapport « Couverture de l'index ». Il est nécessaire de bien comprendre leur origine (source : sitemap, liens internes, liens externes, etc.) afin de limiter leur ajout à la file d’attente du crawler, pour ne pas gâcher de budget d’exploration.

Spidertrap (source)

Les sites générant des ID de session (ex : category.php?sessionid=3YER76)  dans l’URL, ou encore la présence de liens erronées créant ainsi des structures de répertoire indéfiniment profondes (http://example.com/bar/foo/bar/foo/bar/foo/bar/...) peuvent provoquer un crawl très important sur des URL sans intérêt. Un crawl du site peut mettre en avant la présence de ce type de spidertraps, si le niveau de profondeur est anormalement élevé (un niveau de profondeur supérieur à 10 pourrait vous alerter).

Sitemap avec la valeur lastmod

Les sitemaps sont crawlés de façon régulière. Pour chaque URL il est possible d’indiquer sa date de dernière modification :

Valeur lastmod dans le robots.txt

 

Google utilise cette valeur si elle est cohérente, et qu’il vérifie sa véracité en comparant la dernière modification de l'URL concernée. Cette instruction peut donc s’avérer utile pour limiter le crawl sur les URL qui ne subissent aucun changement. Google ira malgré tout crawler l’URL à un instant donné pour s’assurer de présenter une page actualisée dans ses pages de résultats.

Balise Canonical

Certaines configurations de sites peuvent générer plusieurs URL pour un même contenu (ex : URL dynamiques, URL multiples en cas de multi-rubriquage, etc.). La multiplicité des URL pour une seule et même page est un facteur d’augmentation du crawl inutile. Il est préférable de s’assurer qu’aucune page ne soit accessible via des URL différentes : cela permettra de concentrer l’exploration sur des contenus uniques, accessibles via une seule et même URL.

Optimisations techniques

Outre ces aspects on-site qui peuvent avoir une influence sur le budget d’exploration, d’autres facteurs techniques sont un vrai levier pour améliorer la qualité de l’exploration par les moteurs.

Code réponse 304

L’utilisation d’en-tête de validation dans les échanges http tel que Etag ou Last-modified indiquent qu’une ressource n’a pas été modifiée depuis la dernière visite. Un article complet a été rédigé à ce sujet : https://www.reacteur.com/2022/04/comment-bien-utiliser-le-code-304-en-seo.html

Google peut utiliser cette information pour optimiser son crawl de deux façons :

• Google demande une URL pour la première fois, en la crawlant. Si quelques temps plus tard il visite à nouveau cette URL, et que le serveur lui renvoie un code réponse 304 (contenu non modifié depuis la dernière fois), cela signifie que les robots peuvent réutiliser cette demande et explorer autre chose sur le site concerné (économie d’un hit supplémentaire).
• Les robots d’exploration essayent de déterminer la fréquence à laquelle les pages changent, et explorent à nouveau les pages en fonction de la fréquence de mise à jour constatée. Donc, ce n'est pas tant que ces URL en 304 sont explorées moins fréquemment, c'est plutôt que Google comprend un peu mieux à quelle fréquence ces pages changent.

Sur ces constats, Googlebot peut adapter son crawl en fonction de la fréquence de mise à jour.

Temps de chargement des pages et utilisation du cache

Comme vu dans l’article du mois dernier, le temps de chargement des pages est impactant : plus les URL d’un site répondent vite, meilleure sera la capacité d’exploration de Google. L’utilisation d’un serveur de cache sera un véritable atout pour améliorer le TTFB (TimeToFirstByte) et servir le contenu le plus rapidement possible aux robots (et aux internautes !), en évitant le recalcul de chaque page pour toutes les demandes. D’autres articles sur ce sujet son disponible pour optimiser cet axe de performance, liée en partie au LCP https://www.reacteur.com/2021/03/core-web-vitals-focus-sur-le-lcp.html

À vos optimisations !

Comme vous l’aurez compris, le crawl budget peut être amélioré de différentes façons sur un site ayant une importante volumétrie de pages. S’il n’y avait que deux choses à retenir :

• Utilisez tous les outils à votre disposition (Sitemap XML, robots.txt) pour limiter le crawl sur les URL n’ayant pas d’intérêt à être explorées, tout en adaptant votre maillage interne.
• Améliorer la vitesse d’exploration de votre site via des optimisation techniques liées à la performance web, et aux en-têtes de cache.

Sources :

• https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
• https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers