Sommaire
Lors d’un épisode du podcast Search Off the Record, Gary Illyes et Martin Splitt (Google) ont détaillé la manière dont Googlebot traite le HTML. L’échange met en lumière des différences entre le fonctionnement d’un navigateur et celui de l’infrastructure de crawl de Google.
Trois points principaux ont été abordés : les resource hints, l’emplacement des métadonnées dans le HTML et la validité du code.
Les resource hints n’influencent pas Googlebot
Les optimisations comme dns-prefetch, preload, prefetch ou preconnect visent à réduire la latence côté navigateur. Selon Gary Illyes, ces mécanismes ne présentent pas d’intérêt pour Googlebot.
Il explique que l’infrastructure DNS de Google n’a pas les contraintes de latence d’un utilisateur standard et que Google communique très rapidement avec les serveurs DNS. De plus, Google met en cache les ressources séparément et ne les récupère pas de manière synchrone comme le ferait un navigateur.
Dans ce contexte :
dns-prefetchn’apporte pas de bénéfice au crawl,preloadn’est pas exploité par Googlebot,- les autres hints liés à la performance navigateur ne modifient ni le crawl ni l’indexation.
Gary Illyes précise que ces optimisations restent utiles pour les utilisateurs. Elles améliorent les temps de chargement et l’expérience côté navigateur. En revanche, elles n’ont pas d’impact direct sur le comportement de Googlebot.
Google utilise par ailleurs la Speculation Rules API pour accélérer les clics sur les résultats de recherche dans Chrome. Ce mécanisme agit au niveau du navigateur, pas au niveau du robot d’exploration.
Les métadonnées doivent rester dans le <head>
Martin Splitt a évoqué un cas où un script conforme aux spécifications HTML, placé dans le <head>, injectait un iframe. Le navigateur a alors considéré que le <head> était fermé, ce qui a déplacé certaines balises (dont des hreflang) dans le <body>.
Selon Splitt, les systèmes de Google ont ignoré ces balises une fois placées dans le <body>.
Gary Illyes rappelle que :
meta name="robots"doit apparaître dans le<head>,- les balises
rel="canonical"doivent également être placées dans le<head>.
Il souligne qu’accepter des balises canoniques dans le <body> poserait un risque. Une injection de code pourrait modifier la canonique d’une page et influencer son indexation.
Toutes les balises transportant des directives SEO doivent être correctement positionnées dans le <head>, conformément aux standards HTML.
La validité HTML n’est pas un facteur de classement
Gary Illyes indique que la validité HTML ne constitue pas un signal de ranking.
Il explique qu’il s’agit d’un critère binaire. Un document est valide ou ne l’est pas. Selon lui, il est difficile d’en faire un signal exploitable, notamment dans les cas intermédiaires.
Il donne l’exemple d’une balise <span> non fermée. Le code devient techniquement invalide, sans effet notable pour l’utilisateur.
Martin Splitt ajoute que la hiérarchie stricte des titres ou l’usage d’éléments HTML5 sémantiques n’ont pas de poids significatif pour les moteurs de recherche, même s’ils restent utiles pour l’accessibilité et la qualité du code.
Points opérationnels à retenir
- Les resource hints améliorent la performance navigateur, pas le crawl Googlebot.
- Les balises
meta robots,canonicalethreflangdoivent rester dans le<head>. - Une erreur de parsing peut déplacer des balises dans le
<body>, ce qui entraîne leur ignorance par Google. - La validité HTML n’est pas un facteur de classement.
L’épisode complet est disponible sur les plateformes habituelles du podcast Search Off the Record.
