Martin Splitt (Google) "Les développeurs ne sont pas toujours bien formés au SEO, c'est un challenge pour Google"

Le JDN a croisé le chargé des relations avec les développeurs pour les sujets search chez Google au Search Y et l'a interrogé sur les avancées du moteur de recherche en matière de JavaScript, de mobile first et de webperf.

JDN. Quelles sont les difficultés pour Google avec le mobile first indexing ?

Martin Splitt. D'abord, il faut savoir quand on peut passer au mobile first indexing. On peut le déterminer sur un point, commun à tous, mais ce ne sera pas forcément pertinent pour tous les sites. Ensuite, nous sommes confrontés à des sites qui comportent des erreurs techniques, qui peuvent par exemple gêner le tracking dans la Search Console. Les résultats du mobile apparaissent alors dans le desktop. Donc, pour nous, c'est un challenge de nous assurer que les développeurs sont au courant de ces problématiques.

Et les erreurs importantes les plus fréquentes sur le mobile first ?

J'ai vu beaucoup de professionnels penser d'abord au site, en considérant qu'il sera toujours temps d'ajouter une "couche de mobile" plus tard.  Pour moi, c'est la plus grosse erreur, car les deux devraient être pensés ensemble dès le départ, sinon cela engendre des problèmes plus tard. Par exemple, un "no index" sur le mobile, ou la présence des données structurées uniquement sur le desktop. Et comme certains ne testent pas leur version mobile, ils se retrouvent avec un site très lent, ou une partie du contenu absente.

Ce n'est pas non plus une bonne chose que du contenu important, qui devrait être accessible aux crawlers directement, le soit seulement lorsque l'internaute interagit avec la page, en appuyant sur un bouton, par exemple. Pourquoi procéder de la sorte ? Il est toujours possible de le cacher simplement.

"J'ai vu beaucoup de professionnels penser d'abord au site, considérant qu'il sera toujours temps d'ajouter une couche de mobile plus tard"

En matière de webperf, sur quels indicateurs faut-il être le plus focalisé ?

Avec la webperf, l'objectif est de mesurer à quel point le site est rapide pour l'utilisateur. Mais parle-t-on du temps de passage du serveur au mobile ? Du temps entre l'ouverture de la page et l'apparition du premier élément, ou de l'ensemble du contenu, ou de la première interaction ? Tout ne se résume pas à un seul chiffre, nous cherchons le meilleur moyen de prendre cette mesure sans comparer des choux et des carottes. L'attente de l'internaute n'est pas la même d'un site à l'autre. Sur un site qui montre les horaires des trains, ce qu'il veut voir vite, c'est cette information précisément. Donc, l'apparition d'un premier élément est une métrique pertinente. Mais, nous, nous ne savons pas ce qui apparaît en premier, si ce sont bien les horaires ou si c'est le header, le menu, ou d'autres éléments de la page. Et si le contenu est caché et qu'il faut appuyer sur un bouton pour le faire apparaître, c'est l'interaction avec ce bouton-là qui est prioritaire. Ce qui compte, c'est donc de comprendre comment l'internaute interagit avec le site et de chercher les moyens de le satisfaire le plus rapidement possible . C'est une mesure subjective et spécifique à chaque site web et je recommande de faire tester l'expérience par des utilisateurs.

Pour nous, le challenge est d'accorder entre elles les bonnes métriques, c'est pourquoi il y en a régulièrement de nouvelles qui apparaissent et évoluent. Au final, les métriques sont souvent interdépendantes : l'apparition du premier élément ne peut arriver que lorsque le serveur a répondu. Donc il n'est pas possible de ne pas prendre en compte le time to first byte (ndlr : temps de téléchargement du premier octet) pour suivre les autres métriques. Car s'il faut dix secondes pour l'avoir, il faudra au moins dix secondes pour tout le reste. C'est donc un problème à résoudre. Mais recevoir le premier octet en 0,4 seconde ne suffit pas non plus à prouver que le site est rapide si, derrière, il faut dix secondes pour obtenir le rendu de la page.    

"Ce qui compte, c'est de comprendre comment l'internaute interagit avec le site et de chercher les moyens de le satisfaire le plus rapidement possible"

En conséquence, est-ce que Google pense adapter ses mesures au type de site ?

C'est très difficile à faire, car nous ne savons pas avec suffisamment de certitude et de précision ce que les internautes attendent de chaque site. De plus, certaines données ne peuvent pas être automatiquement vérifiées. Si un élément en JavaScript échoue à se télécharger et qu'il manque une partie cruciale du contenu de la page, pour nous, toutes les métriques sembleront bonnes, alors que l'utilisateur sera très frustré. Nous ne sommes pas capables de faire le tri, parmi toutes les erreurs de JavaScript, entre celles qui ont un réel impact et celles qui sont insignifiantes. Beaucoup d'acteurs du marketing, du search et des navigateurs cherchent à améliorer ces mesures et de nouvelles métriques plus pertinentes vont certainement émerger. En attendant, il faut se concentrer sur l'expérience et les attentes de l'utilisateur.

Quels sont les principales difficultés rencontrées par Google avec JavaScript ?

L'un des principaux problèmes, c'est que les développeurs ne sont pas toujours bien formés sur les attentes des moteurs de recherche. Ils n'ont donc pas le SEO en tête au moment de prendre des décisions techniques. Nous essayons d'informer ce public au mieux, quel que soit son niveau de technicité et de connaissance du SEO. La formation est un gros défi. Ensuite, de plus en plus de features arrivent, les framework ne cessent d'évoluer, donc nous nous assurons qu'il y a une base SEO fiable et une panoplie d'outils disponibles pour les utiliser.

Aujourd'hui, un site principalement bâti en JavaScript sera-t-il bien indexé ?

Oui, il n'y a pas de problème. Mais il faut rester attentif à de nombreux points. Par exemple, il ne faut pas mettre trop de JavaScript sur les éléments les plus avancés ou les plus complexes. Il faut aussi veiller à l'organisation de la stratégie de rendering du site web. Car sur un site de contenus, il n'y a pas de bénéfice à miser sur un client side rendering. Il est possible de le faire, mais cela inclut un risque. 

Est-ce que Googlebot evergreen est capable de suivre la fréquence de crawl habituelle d'un site avec beaucoup de contenu frais ?

La présence de JavaScript n'a pas d'influence sur le budget de crawl d'un site.  

Spécialisé dans le développement web depuis 2005, Martin Splitt intègre Google, à Zurich en 2018, avec pour mission de faire la jonction entre les ingénieurs de la firme et les développeurs web. Il crée des contenus pédagogiques et prend souvent la parole sur des sujets de référencement technique auprès de la communauté SEO internationale.