Dans l’épisode 106 du podcast Search Off the Record, Martin Splitt et Gary Illyes de l’équipe Search Relations chez Google se penchent sur une question fondamentale : comment Google parse-t-il réellement le HTML ? Et surtout, qu’est-ce qui compte vraiment dans votre markup ?
Le HTML est un bazar — et c’est normal
Sur le papier, le HTML est un langage structuré, élégant, régi par un standard vivant maintenu depuis plus de 30 ans. En pratique, c’est souvent un joyeux désordre.
Et ce n’est la faute de personne en particulier. Les navigateurs sont extrêmement tolérants dans ce qu’ils acceptent : des balises non fermées, une structure approximative, du code bancal — tout fonctionne quand même à l’écran. Cette tolérance a naturellement rendu les développeurs eux-mêmes plus permissifs. Le résultat ? Un web qui fonctionne pour les utilisateurs, mais qui représente un cauchemar à parser de manière systématique.
Gary et Martin s’accordent sur un point : oubliez les Regex pour parser du HTML. Tout développeur qui a essayé a fini par découvrir que ça ne fonctionne que pour des cas très limités. Le HTML réel est bien trop imprévisible pour être capturé par des expressions régulières.
Le W3C Validator : utile, mais pas déterminant
Les deux intervenants confessent avoir été, à leurs débuts, obsédés par la validation W3C de leur code. Puis ils ont réalisé que cela n’avait finalement que peu d’impact — tant pour les navigateurs que pour les moteurs de recherche.
Il fut un temps où la conformité au standard avait un réel intérêt pratique : à l’époque de Netscape, d’Internet Explorer et des premiers Firefox, chaque navigateur interprétait le HTML différemment. Un code valide était alors la meilleure assurance d’un rendu cohérent partout. Aujourd’hui, les navigateurs modernes sont suffisamment convergents pour que les écarts de parsing soient marginaux.
Google ne donne pas de bonus de classement au HTML valide. Gary est catégorique sur ce point : si vous oubliez de fermer un <span>, rien ne changera pour l’utilisateur ni pour votre positionnement. Cela ne veut pas dire pour autant que la validité est sans importance — simplement qu’elle n’est pas un facteur de ranking.
Pourquoi les métadonnées doivent rester dans le <head>
C’est sans doute l’enseignement le plus concret de cet épisode pour les SEO. Martin et Gary explorent en direct le standard HTML pour vérifier où les balises <meta> et <link> peuvent apparaître. Le verdict est net : les métadonnées à destination des moteurs de recherche doivent se trouver dans le <head>.
Le standard autorise quelques exceptions techniques (un <link> avec un attribut itemprop peut techniquement vivre dans le <body>, par exemple), mais dans la pratique, placer vos balises meta robots, canonical ou hreflang dans le body est une très mauvaise idée.
L’exemple concret : quand le <head> se ferme prématurément
Martin évoque un cas réel qu’il avait discuté avec Bastian Grimm : un site avait placé ses balises <link hreflang> dans le <head>, là où elles devaient être. Mais un script, également dans le <head>, injectait un <iframe> juste après lui. L’iframe étant un élément de contenu (pas de métadonnées), le parser a considéré que le <head> était terminé et a ouvert le <body> automatiquement. Résultat : les balises hreflang se sont retrouvées dans le body — et ont été ignorées par Google.
Ce mécanisme s’explique simplement : quand le parser rencontre dans le <head> un élément qui ne peut pas être une métadonnée (un paragraphe, un iframe, une image…), il considère que le développeur a oublié d’ouvrir le <body> et le fait à sa place. Tout ce qui suit bascule dans le body.
Pourquoi le canonical ne fonctionne que dans le <head>
Gary soulève un argument de sécurité particulièrement parlant. Si Google acceptait les <link rel="canonical"> dans le body, n’importe quel utilisateur malveillant pourrait injecter un canonical via un commentaire de blog mal protégé et détourner l’indexation d’une page vers son propre site. En limitant cette balise au <head>, on réduit considérablement la surface d’attaque.
Les signaux contradictoires : un piège à éviter
Un autre point soulevé par Martin concerne les modifications apportées par JavaScript aux métadonnées. Si votre serveur envoie un canonical dans le HTML initial, et qu’un script JavaScript le modifie ensuite au moment du rendu, Google se retrouve face à un dilemme : quelle version reflète votre intention réelle ?
Le conseil est clair : évitez de modifier les métadonnées avec JavaScript si vous les avez déjà définies dans le HTML côté serveur. Si pour une raison technique vous ne pouvez pas les inclure dans le HTML initial, alors oui, ajoutez-les via JavaScript — mais ne créez pas de signaux contradictoires.
Prefetch, preload, DNS prefetch : utile pour les utilisateurs, pas pour le SEO technique
La discussion aborde également les indices de performance que l’on peut placer dans le HTML : dns-prefetch, preconnect, preload, prefetch… Ces mécanismes peuvent faire une différence spectaculaire pour l’expérience utilisateur en réduisant les temps de chargement perçus.
Mais du côté de Google Search, ces indications n’ont pas d’utilité directe. Les raisons sont logiques :
- DNS Prefetch : Google n’en a pas besoin car ses serveurs communiquent déjà très rapidement avec les serveurs DNS.
- Preconnect : inutile puisque le crawler ne suit pas les liens de manière synchrone comme un navigateur.
- Preload / Prefetch : le rendu chez Google n’est pas synchrone — les ressources sont récupérées et mises en cache indépendamment.
Cela dit, Gary et Martin nuancent : si vous élargissez la définition du SEO au-delà de la technique pure, ces optimisations restent très pertinentes. Des études indépendantes montrent que les utilisateurs convertissent mieux et restent plus longtemps sur les sites rapides. Le bénéfice SEO existe, mais il est indirect.
Le markup sémantique : pas si crucial pour Google
Faut-il s’acharner à utiliser les balises HTML5 sémantiques (<article>, <section>, <nav>, <header>, <footer>) pour améliorer son référencement ? Selon Gary, cela ne fait pas de différence significative pour les moteurs de recherche.
Le débat récurrent sur le nombre de <h1> autorisés sur une page est un bon exemple : utiliser un seul H1 ou plusieurs n’a pas d’impact mesurable sur le classement. La structure sémantique reste importante pour l’accessibilité et l’expérience utilisateur, mais ce n’est pas un levier de ranking.
Le raisonnement de Gary est d’ailleurs assez logique : la validité HTML est binaire — le code est valide ou il ne l’est pas. Donner un bonus à du code “valide” quand une simple balise <span> non fermée peut faire basculer un document dans “invalide” serait absurde et injuste.
Ce qu’il faut retenir
Voici les enseignements clés de cet épisode pour les professionnels du SEO et du développement web :
- Placez vos métadonnées SEO dans le
<head>— canonical, hreflang, meta robots : tout doit être dans le head. C’est non négociable. - Attention aux scripts qui ferment prématurément le
<head>— si un script injecte un élément de contenu (iframe, div…), tout ce qui suit sera traité comme du body. - La validation W3C n’est pas un facteur de ranking — écrivez du HTML correct par professionnalisme, pas pour plaire à Google.
- Évitez les signaux contradictoires — ne modifiez pas avec JavaScript une métadonnée déjà présente dans le HTML initial.
- Les hints de performance (preload, prefetch…) n’ont pas d’impact SEO direct — mais ils améliorent l’expérience utilisateur, ce qui a des effets indirects positifs.
- Le markup sémantique HTML5 n’influence pas significativement le classement — utilisez-le pour l’accessibilité, pas pour le ranking.
Source : Search Off the Record — Épisode 106 : Parsing HTML, podcast de l’équipe Google Search Relations.
