Gary Illyes et Martin Splitt de Google ont utilisé une épisode du podcast Search Off the Record pour expliquer comment le robot d’exploration de Google gère le HTML. La conversation a révélé des différences entre la manière dont les navigateurs et Googlebot traitent la même page.
La discussion a porté sur les conseils en matière de ressources, le placement des métadonnées et la validation HTML. Plusieurs explications d’Illyes remettent en question les hypothèses sur les changements techniques qui facilitent la recherche.
Pourquoi les conseils de ressources n’aident pas Googlebot
Fonctionnalités de performances du navigateur telles que dns-prefetch, preload, prefetchet preconnect résoudre les problèmes de latence que l’infrastructure de Google n’a pas.
Illyes a déclaré que la résolution DNS de Google n’avait pas besoin de l’aide que la plupart des sites tentent de fournir.
Il a déclaré :
« C’est très utile si vous avez un Internet de mauvaise qualité pour faire de la prélecture DNS par exemple. Dans notre cas, nous n’en avons pas besoin car nous pouvons communiquer très rapidement avec tous les serveurs DNS en cascade. »
Il a ajouté que Google met en cache les ressources des pages séparément et ne les récupère pas en temps réel comme le fait un navigateur. Illyes a déclaré que Google procédait ainsi pour réduire la bande passante et la charge du serveur sur les sites qu’il explore.
Illyes a dit :
« Idem avec le préchargement. Si nous ne sommes pas synchrones, nous n’avons pas particulièrement besoin d’écouter et d’examiner le préchargement. »
Google utilise l’API Spéculation Rules pour accélérer les clics sur les résultats de recherche pour les utilisateurs de Chrome. Ce système fonctionne car il fonctionne au niveau du navigateur, où la latence entre un utilisateur et un serveur est importante. Googlebot opère à partir de la propre infrastructure de Google, où ces goulots d’étranglement n’existent pas.
Illyes et Splitt ont clairement indiqué que ces astuces aident toujours les utilisateurs. Des chargements de pages plus rapides améliorent la rétention et la conversion. La différence est que ces modifications ont un impact sur l’expérience du navigateur, et non sur l’exploration ou l’indexation.
Les métadonnées appartiennent à la tête
Splitt a partagé un cas où une balise de script conforme aux spécifications dans la tête a injecté une iframe, ce qui a déclenché le comportement de fermeture de la tête du navigateur. Cela a poussé les balises de lien hreflang dans le corps, où Splitt a déclaré que les systèmes de Google les ignoraient à juste titre.
Illyes a expliqué pourquoi Google est strict à ce sujet. UN meta name="robots" La balise, selon le standard de vie HTML, ne peut apparaître que dans l’en-tête. La même chose s’applique à rel=canonical éléments de lien.
Il a dit :
« Je dirais qu’il est vraiment très dangereux d’avoir des éléments de lien qui transportent des métadonnées dans le corps. »
Son raisonnement est que si Google acceptait les balises canoniques dans le corps, il serait possible de détourner la balise canonique de cette page et de la supprimer des résultats de recherche en injectant du balisage.
Illyes a précédemment proposé des conseils sur l’analyse HTML et la mise en œuvre relative-canonique, conseillant d’épeler le chemin complet de l’URL dans les balises canoniques pour éviter toute ambiguïté de l’analyseur. C’est la même idée, un placement clair dans la tête élimine les incertitudes.
La validité HTML n’équivaut pas à un avantage de classement
Illyes a expliqué clairement pourquoi un code HTML valide ne peut pas être un signal de classement. Validité en tant que binaire, ce qui signifie qu’elle est soit valide, soit sans espace entre les deux. Illyes a déclaré qu’il était difficile de faire quelque chose de significatif avec une métrique réussite/échec.
« Il est très difficile de dire que quelque chose est presque valide. Et puis, que faites-vous là quand quelque chose est presque valide. »
Il a donné un exemple selon lequel une balise de fermeture span manquante rend le code HTML d’une page techniquement invalide, mais comme le dit Illyes, « Cela ne changera rien pour l’utilisateur ».
Splitt est d’accord, notant que le balisage sémantique comme la hiérarchie de titres appropriée et les éléments structurels HTML5 n’a pas non plus de poids significatif pour les moteurs de recherche, bien qu’il soit utile pour l’accessibilité et l’expérience utilisateur.
Pourquoi c’est important
Les audits techniques peuvent signaler des opportunités d’indices de ressources et des erreurs de validation HTML. Savoir lesquels d’entre eux affectent le robot d’exploration de Google et lesquels affectent les navigateurs peut vous aider à prioriser les éléments à corriger.
Lorsque les balises hreflang, les liens canoniques ou les directives méta-robots ne fonctionnent pas comme prévu, la première chose à vérifier est de savoir s’ils se retrouvent dans le corps une fois que le navigateur a analysé la page. Une balise qui semble correcte dans votre HTML source peut se retrouver au mauvais endroit si un script ou une iframe déclenche une fermeture anticipée du head.
Roger Montti a couvert les conseils mis à jour de Google sur la mise en cache des robots d’exploration, qui recommandent les en-têtes ETag pour réduire les explorations inutiles. Ces conseils sont cohérents avec ce qu’Illyes a décrit dans cet épisode.
Regarder vers l’avenir
Splitt a mentionné que les conseils des clients étaient le sujet initial qu’il souhaitait aborder et que la discussion sur l’analyse HTML était la base d’un prochain épisode. Si cet épisode se produit, il pourrait expliquer comment Googlebot gère le nouveau Accept-CH et Sec-CH-UA en-têtes qui remplacent les chaînes d’agent utilisateur traditionnelles.
La conversation complète est disponible sur YouTube et Podcasts Apple.
Commentaires