Googlebot Evergreen, ce que cela change pour le SEO – Chrome dev summit 2019
Ecrit par Mathieu CHAPON
le
Les 11 et 12 novembre derniers avait lieu le Chrome Dev Summit. Événement annuel où des Googlers viennent annoncer les nouveautés de Chrome et donnent des conseils aux développeurs pour s’adapter au mieux à ces changements.
Côté SEO, il s’agit souvent d’une mine d’or d’informations techniques qui peuvent avoir un impact plus ou moins fort sur notre métier.
En complément de l’excellent résumé sur le blog de deepcrawl, nous avons fait deux focus : l’un sur Googlebot Evergreen que vous vous apprêtez à lire et l’autre sur les nouveautés de Lighthouse et des indicateurs de performance.
Accrochez vos slips, it’s about to get technical.
Googlebot Evergreen
Les Nouvelles fonctionnalités
Il s’agit sans doute de la principale information pour nous SEO. Nous en parlions en mai dernier à l’occasion du Google I/O, Googlebot est passé en mode « Evergreen ».
Seulement, en mai dernier nous étions encore aveugles sur beaucoup d’éléments : le temps de rendering, le process exact, les outils de Google qui restaient sous Chrome 41, etc.
Nous avons aujourd’hui de nouvelles informations sur ce passage à Googlebot Evergreen (nous apprenons par ailleurs que Bingbot est également sur Evergreen).
La première information à retenir c’est que cette nouvelle version de Googlebot supporte nativement plus de 1000 nouvelles fonctionnalités telles que les web components ou encore le lazyloading (nous y reviendrons). En clair le message donné par Martin Splitt est le suivant « What you see in your Chrome is also what you see in Google Search ».
Dans la théorie, les développeurs n’ont donc plus à se soucier des incompatibilités de développement avec ce que Google est capable de comprendre.
Si vous êtes vous-même un SEO averti, ou que vous suivez l’actualité de prêt, vous savez que cette incompatibilité n’était pas le seul souci que nous rencontrions. L’autre véritable problème venait surtout du temps de rendering de Google pour les pages utilisant en grande partie des technologies JavaScript.
Le rendering
C’est l’annonce qui va sans doute créer de nouveaux conflits entre SEO et développeurs : avec Evergreen, Google mettrait en moyenne 5 secondes à « rendre » une page là où il y en encore un an cela pouvait prendre plusieurs semaines.
Pour rappel, voici le processus de récupération de nos pages par Google :
Tout ce qui est en noir est complètement invisible pour nous. Seules les parties “crawl” et « indexation » sont visibles pour les simples mortels.
C’est la partie «rendering» qui a bien évoluée et qui ne prend maintenant que 5 secondes en moyenne. Ce qui signifie dans la théorie que nous pouvons maintenant travailler avec des sites entièrement client-side rendering sans que cela ne pose problème pour l’indexation et le positionnement de nos pages dans les résultats de recherche.
NB : Ce processus n’est pas nécessairement une ligne droite unique. Google peut faire des allers-retours entre la phase de processing, de crawl et de rendering par exemple.
Cette accélération du rendering signifie aussi que les phases « boite noire » seront plus courtes pour les webmasters et ils pourront ainsi savoir plus rapidement si leurs optimisations sont bien prises en compte et si leurs pages sont correctement comprises par Google.l
Tout faire en client-side rendering ?
Il s’agit bien sûr d’une question rhétorique : Non. Et ce pour plusieurs raisons :
- 5 secondes à l’échelle du web c’est long, très long même. Pour une page plus classique server-side rendering qui n’a pas de problèmes majeurs, Google ne mettra que quelques millisecondes à récupérer le contenu et pourra ensuite passer à la compréhension et à l’indexation de la page. Sur un site à forte volumétrie (plusieurs centaines de milliers de pages voire plus) ces 5 secondes en moyenne auront un impact certain sur votre crawl rate.
- Google peut tout à fait passer à côté de quelque chose. Martin Splitt l’explique : il n’est pas toujours évident de savoir à partir de quand la page est correctement « rendue ». Amusez-vous à utiliser Puppeteer (oui c’est amusant) ou Rendertron, vous verrez que plusieurs questions se posent : quel viewport j’utilise ? Quand estime-je que la page est chargée ? Dois-je attendre que le CPU soit idle ? Dois-je attendre un certain pourcentage de chargement de la page ? Beaucoup de questions et de décisions arbitraires.
- C’est « nouveau » et incertain, et dans ce genre de situation mieux vaut adopter la stratégie du pleutre : laisser les autres tester, échouer, et apprendre de leurs erreurs. Puisqu’il ne s’agit pas d’une technologie qui vous donnera un avantage pour le SEO, il n’y a pas d’intérêt à dégainer plus vite que la concurrence.
Le cas National Geographic
Pour appuyer son propos, dans sa présentation Martin Splitt met rapidement en avant le cas de National Geographic qui a 100% de son contenu Javascripté qui est bien indexé par Google en reprenant une phrase de Bartosz Goralewicz : « Si vous regardez National Geographic, c’est un plutôt bon exemple […] 100% du contenu javascript est indexé rapidement ».
Cette phrase vient de la présentation au « Web Zürich » qui s’appelle « Google vs. Javascript – What’s the score in 2019 » de septembre 2019.
Bartosz Goralewicz est le CEO d’une agence polonaise « Onely » spécialisée dans la technique SEO et plus particulièrement dans les problématiques liées au Javascript.
Si Bartosz a bien dit cela, il ne s’est pas arrêté là. Malheureusement pour Google.
Dans cette même présentation, il indique bien que d’autres sites n’ont pas cette « chance » et que leur contenu n’est pas encore entièrement indexé :
Dans une autre présentation d’Octobre 2019 au « Digital Growth Unleashed », il met en lumière les grosses difficultés que Google a pour indexer des sites entiers au contenu généré en Javascript.
Il va plus loin en expliquant quels types de contenus ont du mal à être lus et indexés. Il met ensuite en avant des outils maison comme « What would javascript do ? » ou « TL ;DR » qui permettent de se rendre compte des limites du javascript sur notre site. Sources: https://www.slideshare.net/goralewicz/too-long-didnt-render-the-state-of-js-and-html-indexing & https://www.onely.com/tools/.
Sortie de son contexte, la citation sur National Geographic va donc bien dans le sens de Google, mais lorsque nous creusons le sujet (ce que fait très bien Onely), il est facile de se rendre compte que cette technologie est loin d’être parfaitement adaptée au SEO.
Notre conclusion sur cette partie dédiée au Javascript est donc la suivante : même si Google a fait un pas de géant dans la compréhension et le rendering de cette technologie, nous sommes encore loin du compte et des résultats que peut donner une technologie plus simple côté serveur.
Changement d’user-agent et mise à jour des outils
L’autre annonce que nous retiendrons concernant Evergreen c’est le changement de la string User-agent que nous connaissons. Même si Googlebot est en effet passé sur Evergreen, les lignes dans vos access logs ou autre ressemblent toujours à ceci :
Vous l’avez sans doute remarqué mais Chrome est toujours indiqué en version 41. Ce « status quo » a été choisi pour laisser le temps aux développeurs de mettre à jour leurs outils de détection d’user-agent. Cette ligne va changer sous peu, il est donc plutôt recommandé de chercher à identifier des éléments plus génériques comme par exemple « Googlebot ». Pour rappel, si vous voulez vous assurer qu’il s’agit bien de Google qui passe sur votre site et non d’une agence SEO avec un User-Agent Google (par exemple…), il vous suffit de faire un reverse DNS sur l’adresse IP et vous serez fixés.
Les outils Google eux-aussi vont être mis à jour et tourner sous Chrome Evergreen. Que ce soit l’outil de test de rich results ou l’outil d’exploration de la Google Search Console, vous serez maintenant au plus près de ce que Google voit.
Lazyloading
Enfin, pour terminer ce focus sur Googlebot Evergreen, sachez que Google sera maintenant capable de comprendre la fonctionnalité native de lazyloading. C’est fort utile et fort sympathique pour faciliter son utilisation mais n’oubliez pas que Google (bot et Chrome) n’est pas seul sur le marché et que cette fonctionnalité n’est pas encore supportée par tous les navigateurs et moteurs de recherche. A utiliser avec précaution donc.
Bonus Google image
A la fin de sa présentation Martin Splitt nous tease l’arrivée de données structurées / outil dans la Google Search Console qui permettront de baliser des images de haute résolution et d’indiquer à Google que nous souhaitons que ces images soient utilisées dans les résultats de recherche sans pour autant devoir les avoir sur notre site dans leur qualité optimale. . A suivre donc.
