Test de positionnement web : HTML 5 VS xHTML

Mathieu Chartier Référencement 15 commentaires

xHTML Vs HTML 5 - Positionnement web GoogleL'HTML 5 n'est pas encore totalement validé par le W3C (normalement fin 2014) mais nous pouvons dès à présent nous intéresser au positionnement des sites web construits sur cette nouvelle architecture interne. S'il est difficile de déterminer le rôle de l'HTML 5 dans le positionnement des pages web, seuls quelques tests pourront nous donner des idées de la réalité.

Pour se faire, j'ai réalisé 2 tests distincts basés sur le même principe afin d'avoir une première approche des résultats. Je précise tout de suite que ces résultats ne sont pas nécessairement à prendre au pied de la lettre et que c'est seulement sur la durée avec d'autres tests que nous pourrons confirmer ou infirmer la tendance que je vais vous présenter.

Protocole des tests de positionnement web (HTML 5 et xHTML)

L'idée des tests me trotte dans la tête depuis un moment, mais je ne savais pas trop comment m'y prendre pour obtenir des résultats intéressants (ou non). Je me suis lancé, et même si ces tests ne sont pas parfaits, ils apporteront déjà quelques petits éléments de réponse éventuellement ou au pire, ils contribueront au débat sans fin à ce sujet...

Globalement, les deux tests avaient pour objectif de déterminer si des pages optimisées en HTML 5 obtenaient un meilleur positionnement que des pages équivalentes (test 1) ou quasi équivalentes (test 2) fondées sur une architecture en xHTML.

Test 1

Le premier test vise à utiliser le même contenu pendant quelques temps (pour éviter une pénalité ou d'être ignoré à cause du duplicate content) dans quatre architectures différentes :

  • page d'accueil en HTML 5 pur avec attributs "role" et "aria-labelledby" de la norme WAI-ARIA. La page est totalement à jour et présente des zones de contenus déterminées à l'aide des balises HTML 5 les plus connues (header, footer, article, section, hgroup, aside, nav...).
  • seconde page avec les mêmes contenus mais construites en xHTML 1.0 Transitionnal classique.
  • troisième page équivalente à la page d'accueil mais sans les attributs "role" et "aria-labelledby".
  • dernière page équivalente en tout point à la page d'accueil, son but étant justement de ne pas être considérée comme une page d'accueil.

Certes, les pages sont identiques et certains auront tendance à penser que cela a influer sur le résultat final. Cela est vrai en partie mais mes pages n'ont pas été sanctionnées après plusieurs semaines de test donc au final, cela reste un classement de pages web comme un autre (et surtout, ça n'est qu'un test...).

Structure d'une page web en HTML 5 - Test de positionnement web Google

Test 2

J'ai repris le même principe que le premier test avec 4 pages différentes, mais cette fois, j'ai varié quelque peu les contenus d'une page à l'autre ainsi que la sémantique du code source HTML. Cependant, j'ai veillé à ce que les mots clés principaux et le nombre de stop words soit identique pour que les différences ne soient pas majeures et influent trop sur le résultat final. La page d'accueil n'est qu'un menu vers ces 4 pages et ne sera pas indexée (de page4 à page7 en réalité). En définitive, voici le test 2 :

  • Page 4 - architecture totale en HTML 5 avec WAI-ARIA.
  • Page 5 - architecture totale en xHTML.
  • Page 6 - architecture en HTML 5 sans WAI-ARIA.
  • Page 7 - architecture partielle en HTML 5, uniquement fondée sur quelques balises (pas de <nav>, <aside> et <hgroup> notamment).

Dans les premières semaines de test, l'ordre a été celui-ci : page6 > page7 > page5 > page4 ! En d'autres termes, l'HTML 5 dominait sauf dans le cas de la norme WAI-ARIA (nous reviendrons sur ce cas particulier).

Après plusieurs semaines, j'ai effectué quelques modifications en affichant les mêmes contenus (comme dans le test 1) et l'ordre final a été celui-ci : page6 > page5 > page4. La page 7 en HTML 5 partiel a été retirée des SERP mais l'ordre est donc resté identique au final.

Pourquoi les pages HTML 5 sont-elles mieux positionnées ?

Les deux tests effectués ont clairement placés les pages en HTML 5 devant celles construites en xHTML, mais rien ne permet d'affirmer que cela est dû à 100% à ce nouveau langage de balisage. En effet, plusieurs questions peuvent se poser :

  • Les balises sont déjà reconnues par Google et mieux valorisées ? Nous pouvons penser que Google a déjà prévu le coup et valorise davantage certaines balises HTML 5 parce qu'elle l'aide à mieux comprendre les contenus et leur rôle dans les pages web.
  • La sémantique des balises, leur taille (...) influent-elles sur la densité globale dans la page et donc sur le positionnement ? La multiplication des balises et des attributs ainsi que leur sémantique jouent éventuellement un rôle dans les calculs finaux qui peuvent modifier à peu de choses près la valeur des pages, et donc faire la différence dans les SERP. Au vu de la batterie de critères prise en compte par Google, il est fort à parier que nombre d'inconnus affinent la valeur des pages, donc je soumets cette hypothèse naïvement... ^^
  • La multiplication des balises entraînent des sauts de ligne dans le code source, cela pourrait-il influer sur la valeur finale de la page ? En effet, nous affirmons régulièrement que les robots lisent les pages de haut en bas (et de gauche à droite !) et que les contenus placés le plus haut ont davantage de poids et de valeur. Partant de ce constat, la différence de sémantique entre les pages HTML 5 et xHTML peut influer sur le nombre de lignes qui composent les pages web, et donc sur le placement des contenus. Si dans une page un texte est placé en ligne 20 et que dans une autre il est en ligne 22 ou 23, sa valeur pourrait alors être dévaluée quelque peu...
  • Les différences entre les morceaux de textes ont-elles pu influer énormément sur le positionnement final ? En effet, le test 2 montre des petites différences de textes (mais en conservant la même densité sur les mots clés principaux !) pour éviter le duplicate content, cela a forcément dû jouer un minimum sur le positionnement dans ce cas de figure.
  • Le hasard fait-il bien les choses ? C'est tout bête, mais peut-être que sur les 8 pages de test, il y a une part de "chance" qui explique ce positionnement en faveur de l'HTML 5... :D
Le cas particulier qui fait "tâche"...

Parmi les résultats, seules les pages web qui contenaient l'attribut "role" (WAI-ARIA) en HTML 5 ont semblé réagir différemment. Sur un total de 8 pages de test (réparties sur deux tests distincts), il est difficile de savoir le rôle tenu par cet attribut, son éventuelle valeur mais surtout son impact sur la positionnement. Je m'explique :

  • le premier cas contenant les attributs "rôle" est dans le test 1. Ici, la page s'est positionnée 1re des SERP, ce qui semblerait confirmer les autres résultats de positionnement web sur Google. Toutefois, il s'agissait de la page index.html, nous pouvons donc aussi nous poser la question du poids attribué à la page d'accueil d'un site. En effet, est-ce que la page a été positionnée en premier parce que l'HTML 5 était optimisé ou est-ce parce qu'il s'agissait d'une page d'accueil que Google valoriserait naturellement un peu plus ? Son équivalent (4e page du test 1) s'est glissé en 3e position (entre la page HTML 5 et xHTML) donc là encore, cela ne nous aide pas...
  • le second cas de figure est plus étonnant puisque dans le test 2, la page HTML 5 la plus optimisée (donc celle avec l'attribut "rôle") s'est tout simplement positionnée en... dernière position ! Elle s'est retrouvée juste derrière la page xHTML donc une fois encore, nous pouvons douter de la réelle incidence du balisage WAI-ARIA mais aussi de l'HTML 5 au passage...

Si nous résumons, le premier cas s'est bien positionné en premier lien sur Google, mais le doute est permis, c'est réellement le second cas qui pose question car après plusieurs semaines de tests, la page est restée dernière. Au final, 7 pages ont réagit dans le même sens sur les 8 existantes dans les deux tests, c'est un bon ratio, mais cette marginale se pose en troubleur de fête au final...

Que reste-t-il à découvrir ?

Tout d'abord, il faudrait déjà confirmer que l'HTML 5 positionne mieux les pages web que les anciennes moutures du langage. En effet, ce n'est pas parce que ces deux tests tendent vers cette idée qu'il s'agit d'une confirmation... J'attends d'ailleurs d'autres tests, d'autres études et d'autres confirmations avant que nous puissions nous enflammer... :D

L'autre point essentiel est de déterminer quelles sont les balises HTML 5 qui favorisent le positionnement des pages web au détriment des anciens éléments xHTML. En effet, mes deux tests ont permis d'analyser un ensemble de facteurs, pas de cibler des balises en particulier...

J'ai juste "joué" sur l'attribut "role" de la norme WAI-ARIA pour voir si l'impact était là mais les résultats n'ont pas été probants et laissent place aux doutes. Qui plus est, j'ai tenté une page uniquement avec les balises <header>...</header>, <footer>...</footer>, <section>...</section> et <article>...</article> qui s'est elle-même positionnée devant la page approchante en xHTML, mais cela n'est pas suffisant. Il faudra donc aller plus loin pour en savoir davantage.

Conclusion sur le positionnement des pages en HTML 5

Globalement, la bonne nouvelle est que dans deux cas approchants mais différents, les pages en HTML 5 sont devant dans les SERP de Google, mais il va falloir s'armer de patience pour confirmer les résultats et déterminer les balises qui amélioreraient éventuellement le positionnement des pages web. N'hésitez pas à m'apporter vos témoignages, vos idées, vos résultats, vos tests (...) car tout est bon à prendre afin de mieux se préparer à l'avenir...

Test de positionnement web Google - HTML 5 VS xHTML

N.B. : ces tests sont loin d'être parfaits, c'est d'ailleurs pour cela que cela s'appelle "test"... Je préfère le dire car je sais à quel point la critère est facile derrière un écran. Mon objectif est d'apporter ma mini pierre à l'édifice et petit-à-petit de trouver des remèdes pour améliorer le positionnement des pages web sur Google (et autres moteurs de recherche si possible !), je n'ai pas la prétention d'affirmer que j'ai réalisé les test idéaux qui vont changer le monde SEO... :D

15 commentaires

  • Thomas Cubel dit :

    Salut Mathieu,

    Intéressant ton article !

    Après, moi je te le dis tout de suite, je ne fais quasiment plus que du HTML5.
    Sans parler de positionnement ou autre. Le HTML5 ça fait presque 10 ans qu'on en parle ! Je serais tenté de dire "Réveillez vous, on est en 2014 !"

    Sérieux, pourquoi se faire chier avec un autre HTML compliqué, vieux, où certaines balises seront dépréciées dans quelque temps alors que celui-ci est simple, compréhensible, évite de mettre des div partout, etc. ? En plus, il est basé sur la sémantique... Hummingbird aime la sémantique.

    Sinon, pour revenir sur les tests, c'est bien joué. Si tu veux en savoir plus sur ça, je te conseille le bouquin de Danny Dover "Search Engine Optimization Secrets". Tu as un procédé pour faire des tests. Tu as aussi d'autres chapitres très intéressant qui devrait te plaire. Je compte faire une critique prochainement sur mon blog si ça t'intéresse.

    Merci pour l'article en tout cas et bonne continuation à toi !

    • Je suis d'accord, l'HTML 5 est très utile au-delà même de l'idée de référencement, je suis un partisan de son usage. Pour être honnête, j'ai commencé à former des gens à ce sujet il y a 4 ans déjà, quand il y avait bien moins de polyfill qu'aujourd'hui, et déjà, j'étais satisfait. Comme j'aime le code propre, la sémantique HTML 5 est mieux pensée et me convient davantage.
      Je sais que ça ne se voit pas au premier abord mais je passe peut-être autant de temps dans les docs des moteurs de recherche que dans celles du W3C, je suis passionné par ça et le seul regret que j'ai, c'est qu'il faille autant de temps pour valider toutes les étapes de l'HTML 5 et du CSS 3 (surtout quand on sait que l'xHTML 5 est dans les cartons en train d'attendre, ou que le CSS 4 est développé depuis 2010 déjà... :S).

      Je ne connaissais pas le livre de Danny Dover mais ça peut être intéressant en effet, je ne sais jamais trop comment m'y prendre pour les tests. J'ai beau prendre des précautions et suivre des recommandations (...), j'ai toujours l'impression que je vais faire n'importe quoi... :D

  • Pour un nouveau site ou de nouvelles pages, je pense que ce test tient la route, et je trouve le résultat logique même s'il reste à confirmer.
    En revanche, pour avoir fait le test sur un vieux site qui utilisait des tableaux, les résultats n'ont pas été identiques, au contraire il est descendu de 2 ou 3 pages sans rien faire d'autre à côté. Peut-être qu'une absence de mise à jour du contenu en est la cause (faut dire qu'il n'a pas changé depuis environ 2 ans).
    Mais bon, il y a tellement de critères qui peuvent entrer en jeu...

    • C'est pour cela que les tests se font sur des sites "propres" en gros, pour que d'autres critères ne viennent pas trop interférer et nuancer encore plus les résultats. Toutefois, cela reste des tests comme je le dis dans l'article et il est difficile de confirmer ou d'infirmer les résultats... :S

  • Victor dit :

    Super-intéressant le test. Juste en complément d'info, Bing déconseille l'utilisation de multiples h1 dans ses guidelines, bien que la spécification HTML5 nous permette de les employer.
    J'ai fait des test avec figcaption sur les images, mais je n'arrive pas à déterminer si l'impact est appréciable. Peut-être que vous le testerez la prochaine fois ?
    Bonne journée !

    • J'avoue que je suis plutôt partisan de l'idée de Bing de ne pas multiplier les h1 malgré la spécification, tout comme pour les balises header et footer dans les articles dont je ne suis pas fervent, mais bon, Bing ne peut pas nous sanctionner pour ça si la spécification l'autorise. :D

  • karnabal dit :

    "Sérieux, pourquoi se faire chier avec un autre HTML compliqué, vieux, où certaines balises seront dépréciées dans quelque temps alors que celui-ci est simple, compréhensible, évite de mettre des div partout, etc. ?" Pour des questions de compatibilité des navigateurs, non ?

    Pour l'histoire des H1, sur une page de navigation, c'est quand même moins tendu que sur une page de contenu (où là, pas trop de raison d'en utiliser plusieurs).

    • Il existe des polyfills qui rendent tout cela compatible, le problème peut donc se régler et nous faire passer à l'HTML 5 dès maintenant. Je ne dis pas que c'est bien, mais c'est la solution employée par beaucoup pour "sauver les meubles". ^^

  • Dan dit :

    A suivre, mais je pense qu'au final Html 5 ou xhtml, les liens entrants feront la différence. Même si c'est pas le sujet du test :-D

    • Et moi je ne pense pas que se focaliser sur les liens entrants sera la réussite à l'avenir (sans même parler de Google Penguin), mais c'est ce qui fait la beauté de notre métier, c'est que nous pouvons nous positionner en travaillant des aspects différents. :D

  • Victor dit :

    En même temps, l'utilisation de plusieurs h1 sur une page peut rendre la détermination du sujet principale de la page un peu plus compliquée pour nos chers moteurs de recherche. Autant ne pas les utiliser !

    • Oui, entièrement d'accord, le principal problème est "technique" pour les moteurs, car ils ne sauront plus faire la différence entre un spammeur et une multiplication logique des h1. Toutefois, comme Google détaille l'arbre DOM des pages, il devrait être capable en théorie de repérer des h1 contenus dans des balises

      ou non, mais entre la théorie et la réalité, il y a un pas... :D
  • Ramenos dit :

    Merci pour ces tests. Après, quand on rentre + dans le détails, on peut voir que Google a encore du mal avec la gestion de certaines nouvelles normes... Comme le blocklinks par exemple :).

    Je te laisse deviner pourquoi mais un ingénieur de chez Google m'avait confirmé que Google avait encore un peu de misère avec ça.

  • Dominique dit :

    Si je comprends bien, les tests portent sur des pages sans réellement de contenu et pour que google peut afficher de façon aléatoire ?
    C'est un peu ce que google fait avec la "prime de fraicheur". Sauf que sur des domaines un tant soit peu concurrentiel, les nouvelles pages se retrouvent vite à une place plus "adaptée". Là, sur une requête que toi seul et quelques uns de tes lecteurs vont faire, google n'aura pas assez de statistiques pour voir quelle est la place la plus juste pour telle ou telle page. D'autant plus que, souvent, on affichera juste la page des serp, sans cliquer sur les liens. Et là, gg n'aura aucune indication sur comment ordonner cette serp

    • J'ai volontairement fait deux tests (chaque test ayant été envoyé à la même heure pour éviter ce problème de fraîcheur) avec des tests différenciés. Court pour le premier, un peu plus long pour le second. Google avait donc de quoi différencier les pages, notamment au niveau des balises.
      Il faut savoir qu'aucun test de balise n'est idéal et vraiment sûr puisque dans tous les cas, il existe des "variables" qui peuvent jouer sur le positionnement final. J'ai donc tenté de limiter au maximum les interférences, mais ça reste des tests, rien ne peut assurer que c'est vrai à 100% comme je le dis dans l'article.

      Je ne suis pas totalement fou quand même, j'ai pris mes dispositions pour éviter tout problème, mais c'est toujours compliqué, c'est pour cela que je dis qu'il faudra plusieurs autres tests pour valider ou invalider tout ça (sachant qu'un autre blogueur avait aussi testé et obtenu des résultats comme les miens).

  • Déposer un commentaire

    Répondre à Dan Annuler la réponse

    L'adresse de messagerie ne sera pas publiée.* Champs obligatoires