La réponse courte à la question « Combien de balises `h1` dans une page Web HTML5 ? » est : « Autant que nécessaire ! » En gros, chaque fois que vous avez une nouvelle section, vous pouvez mettre un `h1`. D’une manière générale, `h1` accompagnera `article`, `aside`, `nav` ou `section` avec brio ! (cf. Sectioning content). Allons voir ce que nous disent les spécifications HTM5 sur l’emploi des balises de titre `h1` — `h6`, notamment les exemples concernant les niveaux de titre. Ils sont assez parlant bien que parfois déroutant lorsqu’on a l’habitude du balisage utilisé jusqu’à présent. Les éléments `h1` — `h6` représentent les niveaux d’en-têtes de leurs sections respectives. Quant à l’élément `hgroup`, il regroupe un ensemble d’en-têtes composé d’au moins deux niveaux de titre, comme un titre et son sous-titre ou un titre et le slogan associé (un bon candidat pour Logo et Motto, faute de mieux).
Quelques exemples avec H1
Les deux bouts de code qui suivent sont équivalent :
<body> <h1>Let's call it a draw(ing surface)</h1> <h2>Diving in</h2> <h2>Simple shapes</h2> <h2>Canvas coordinates</h2> <h3>Canvas coordinates diagram</h3> <h2>Paths</h2> </body>
<body> <h1>Let's call it a draw(ing surface)</h1> <section> <h1>Diving in</h1> </section> <section> <h1>Simple shapes</h1> </section> <section> <h1>Canvas coordinates</h1> <section> <h1>Canvas coordinates diagram</h1> </section> </section> <section> <h1>Paths</h1> </section> </body>
La première forme est celle que l’on utilisera le plus souvent dans le cadre d’un CMS, puisque il est rare que l’on puisse saisir des balises `section` lors de la rédaction d’un article, même en passant par l’éditeur HTML puisqu’il supprime les balises exotiques. A moins qu’un plugin ne permette d’y remédier.
Dans un autre exemple, on trouve une utilisation des niveaux `h1` suivis de `h2` et `h3` à l’intérieur des sections :
<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <section> <h3>Sweet</h3> <p>Red apples are sweeter than green ones.</p> </section> </section> <section> <h2>Color</h2> <p>Apples come in various colors.</p> </section> </body>
Toutefois, le W3C recommande d’utiliser la forme suivante plus explicite et plus simple à maintenir si l’on doit modifier l’ordre des sections en cours de rédaction (ou lors de corrections plus tardives) :
<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section> <h1>Taste</h1> <p>They taste lovely.</p> <section> <h1>Sweet</h1> <p>Red apples are sweeter than green ones.</p> </section> </section> <section> <h1>Color</h1> <p>Apples come in various colors.</p> </section> </body>
Si la première version semble mieux hiérarchisée, la deuxième est plus claire : un `h1` gratuit pour chaque création de section explicite ! Et l’on peut continuer avec les balises `h2`, `h3`, etc. C’est la profondeur du document, l’imbrication des sections et des sous-sections qui définit la hiérarchie du document. Ce qui ne signifie pas que les balises `h2` — `h6` sont inutiles. Elle sont toujours indispensables pour structurer le message à l’intérieur des sections.
Pour l’application des styles CSS, en revanche, pas sûr que `section section h1 {…}` soit plus simple que `h3 {…}`. Voir à ce sujet HTML5 Titles Inception, la courageuse descente de Nicolas Hoizey dans les limbes pour styler les `h1` selon leur profondeur.
Sémantique ou optimisation SEO ?
La question du nombre de fois où l’on peut utiliser la balise `h1` dans un document présente deux facettes :
- Logique interne du document (Semantic). Un document est souvent identifié par un titre et les parties qui le composent par des sous-titres. Si un document peut ne posséder qu’un seul titre (à l’image des livres où le titre se trouve en couverture), il est possible d’utiliser un titre `h1` par `section`. On suppose alors que les sections forment des parties dissociables du tout. A cet égard, on peut se demander si une balise `article` n’est pas préférable dans la mesure où une partie indépendante peut bénéficier (en théorie) d’un flux RSS dédié.
- Le référencement au niveau de la page (In Page). Google accorde un poids supplémentaire (un petit poids, faut pas trop rêver non plus) aux mots-clés contenus dans les balises de titre `h1`, `h2` et `h3`. La tentation est grande de vouloir en utiliser un maximum dans une même page.
Est-il est possible de mixer ces deux approches en tentant le Jackpot de la beauté sémantique et du charme SEO ? Lorsqu’on regarde de près les ouvrages imprimés (livre ou magazine), on s’aperçoit que le titre ne se retrouve pas toujours uniquement sur la 1ère de couverture. Dans certains livres, le titre est parfois répété dans les feuillets intérieurs précédé et/ou suivi de quelques pages blanches. Dans certains magazines, le nom de la revue peut se retrouver sur toutes les pages avec le titre de la rubrique en regard.
Du coup, l’argument du titre unique pour l’ensemble du site Web — en comparaison logique avec le Livre (objet de référence dès qu’il s’agit de bon goût) — ne tient plus. CQFD. Reste la question du `title` présent dans les balises `meta`. D’un point de vue SEO, cette balise est fondamentale car elle fait office de titre dans les SERP’s (Résultats dans les pages de recherche). Il faut donc lui accorder un soin tout particulier. Elle doit être unique sur la page. Or, la plupart des CMS utilisent le titre de l’article pour garnir ce `title`, ce qui le fait apparaitre deux fois. Sans compter l’URL du billet qui reprend souvent ce même titre lors de la réécriture des URL (URL Rewriting).
Il est important de s’assurer que ce `title` n’est pas redondant. Le meilleur moyen d’y parvenir est de considérer qu’il représente le vrai titre de la page Web, indépendamment des niveaux de titres `h1` présents (sans compter que la page n’est pas forcément synonyme de document) ou même du logo, qu’il s’agisse d’un texte ou d’une image. Le Web n’est pas totalement réductible aux pratiques de l’imprimé, fussent-elles de bon goût.
En matière de SEO, redondance rime avec décadence, du moins lorsque la répétition s’effectue sur des niveaux hiérarchiques d’égale importance.
Document vs Site Web
La plupart des exemples fournis par le W3C concernent des documents et pas des sites Web, et ce n’est pas un détail : de nombreuses ambiguïtés concernant le bon usage de la balise `h1` viennent de là. Si l’on doit présenter le compte-rendu d’une réunion, le titre du document pourrait être l’objet du mail qui a servi pour inviter les participants.
Prenons par exemple le document suivant :
<h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1> <p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p> <h2>La réunion d'intégration</h2> <p>blablabla [...]</p> <h2>Le livret d'intégration</h2> <p>blablabla [...]</p> <h2>Partenaires</h2> <ul> <li>La Tête dans l'Ecu</li> <li>La Tête allant vers... </li> </ul>
Une fois que le document est balisé correctement, il reste à l’intégrer dans le site Web qui contient généralement des balises d’en-tête de différents niveaux avant et après la zone des articles. Pour simplifier, on peut utiliser le marquage suivant :
<header> <hgroup> <h1>Mon logo qu'il est beau</h1> <h2>Mon Slogan qu'il est grand</h2> </hgroup> <p>Ma description étendue qu'elle est bien fichue [...]</p> </header>
Sous réserve que le logo en question soit composé en HTML et signifie quelque chose. Pendant longtemps, ce blogzine avait pour titre «CSS & Webdesign», ce qui en faisait un titre efficace dans le sens où 1) l’expression était représentative du contenu et 2) signifiait quelque chose pour les moteurs de recherche. D’ailleurs, sans trop vouloir enfoncer le clou du SEO, si votre logo-titre n’est pas utile pour les moteurs de recherche (ex. css4design, logo en image), autant utiliser une balise `div`.
Pour intégrer notre document dans le site Web, nous allons l’envelopper avec une balise `article`. Puis, nous allons modifier le marquage du `header` pour supprimer la balise `h1` bien que les spécifications HTML5 ne nous y oblige pas. L’idée est de garder la ou les balises `h1` uniquement à l’intérieur de la balise `article` pour optimiser le SEO In Page. Nous en profiterons pour remplacer la description du site par un résumé de l’article qui servira de chapô :
<header> <p> <span id="logo">Mon logo qu'il est beau </span> <span id="slogan">Mon Slogan qu'il est grand</span> <p> <p>Un résumé de l'article qui servira de chapô [...]</p> </header> <article> <h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1> <p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p> <h2>La réunion d'intégration</h2> <p>blablabla [...]</p> <h2>Le livret d'intégration</h2> <p>blablabla [...]</p> <h2>Partenaires</h2> <ul> <li>La Tête dans l'Ecu</li> <li>La Tête allant vers... </li> </ul> <article>
Pour continuer dans cette logique de donner la primeur au contenu principal de la page, le mieux est encore de le placer en premier dans le code. En effet, un des avantages du Web par rapport à l’imprimé, c’est que l’ordre d’affichage des éléments n’est pas forcément celui du code source. Ainsi, dans l’exemple, ci-dessus, on peut très bien placer le contenu de la balise `article` avant celui de `header` dans le code et inverser l’ordre d’affichage avec la propriété `float` ou `position: absolute`.
Adaptez la feuille de style aux documents, pas l’inverse !
Si les spécification du W3C autorisent — voire encouragent — l’utilisation de plusieurs balises `h1` pour structurer le contenu à l’aide de `section`, il me semble important d’adapter le balisage HTML à la sémantique des documents. Vous trouvez ça bateau ? Pourtant je remarque que l’on a tendance à baliser les documents de manière à les adapter à la feuille de style que l’on a déjà, plutôt que d’adapter la feuille de style aux documents ! Cela passe par une analyse approfondie des documents existants, par la création d’une feuille de style CSS souple et par la capacité de remettre son travail en question selon la nature des documents à venir.
Linkographie
- Combien peut-on mettre de « H1 » dans une page ?
- Un balisage sémantique idéal existe-t’il
- Non, je n’ai pas de mots clés dans l’URL
- H1 ne sert pas à faire n’importe quoi.
- WordPress — Une meilleure indexation avec Not at All in One SEO
- Accessibilité Web et ordre des éléments dans le flux
- Guide AccessiWeb : structuration de l’information
- Glossaire AccessiWeb : Les titres
- HTML5 titles Inception
Est-ce que tu sais si Google a déjà communiqué sur ce sujet ?
Je sais que c’est un sujet de discorde entre référenceurs, mais globalement il est admis qu’on ne met qu’une balise h1 par page.
Google va-t-il faire la différence entre un h1 sur une page html classique et plusieurs h1 sur une page en html5 ?
Il ne me semble pas que google se soit exprimé pour l’instant, mais par contre on peut regarder le code source de leur site html5 rocks pour voir comment ils implémentent les h1. Moi je serais partant pour respecter les nouvelles specs et pourvoir mettre des h1 dans chaque section.
Je ne suis pas spécialement d’accord !
Même sur le papier, les documents n’ont qu’un seul gros titre (h1) les sections détaillées ensuite dans le document étant par nature des « enfants » de ce document, doivent avoir un H2.
Pour ce qui est du point de vue SEO, trop de h1 tue le h1 et comme il semble que ce soit le seul capable de compléter efficacement les autres métas données de la page, il faut non seulement l’optimiser mais surtout ne pas le noyer.
Puis, entre nous soit dit, avoir plusieurs h1 sur une page, c’est comme si un bouquin avait 50 couvertures quelque part, c’est pas cohérent.
Bon après ca n’engage que moi hein mais quand même ^^
Je viens de regarder le site de google sur l’html5 et ils suivent un peu ce que dit l’oiseau de nuit : a savoir un h1 et les sections avec des h2.
C’est noté & tweeté 🙂
Si on veut suivre la comparaison avec l’objet livre, ne suffit-il pas de considérer que seul un
h1
inclus dans unheader
corresponde en fait au fameux titre de couverture évoqué ?Loiseau2nuit, Alban >
En fait, l’idée c’est que la page Web n’est pas réductible au(x) document(s) qu’elle contient. La première balise h1 (par exemple pour le logo), se rapporte à la section la plus proche (par exemple le body). On le voit bien lorsqu’on utilise le Outliner HTML5 pour voir l’imbrication des différentes sections.
Cette notion de section la plus proche est la base de la sémantique introduite par html5, elle concerne également l’élément address qui peut se rapporter à l’ensemble du document s’il suit la balise body, ou tout autre élément en fonction des sections où on le place.
Pour en revenir à la solution choisie par Google, il faut se rappeller qu’il n’a jamais été un exemple en terme de balisage.
Mais surtout, l’intérêt de HTML5 ce de permettre presque tout, à condition que le ramage se rapporte au plumage 😉
GizMecano >
C’est un choix valable, mais ce n’est pas le seul choix possible. Je suis convaincu que HTML5 est propice à l’expérimentation, alors essayons de sortir des sentiers battus !
C’est là que je me dis que les gars qui nous pondent ces normes feraient bien d’ouvrir une fois Word (titre, puis titre1, titre2, titre3, etc. et notion de sections) ou mieux d’aller regarder du côté de LaTeX. Parce que tout en s’adressant à priori à la création de supports papiers, ces deux logiciels (pour faire simple, désolé pour les puristes de LaTeX) ont résolu ce genre de problème simplement et avec élégance depuis longtemps.
Ah ! un très bon article sur le sujet.
Le nouvel algo d’HTML5 qui sert à l’extraction de la structure du document permet effectivement de bien voir l’arbre du document.
J’utilise l’extension de Chrome HTML5 Ouliner et je me suis aperçu que ce n’était pas encore très clair après avoir pourtant fait bon nombre d’efforts pour comprendre comment ce balisage sémantique. Un exemple ?
On veut placer la balise sidebar pour un contenu en rapport article à l’intérieur de l’article même. Je m’imaginais que la seule présence de sidebar permettait d’avoir un contenu bien séparé. Eh bien non.
Si on met la sidebar ainsi ça ne marche pas :
article
H1
H2
sidebar
H1
H2
H2
H2
Les 2 H2 qui suivent la sidebar et qui devraient appartenir à l’article se retrouvent raccordés à l’article.
Pour y remédier, il faut sectionner tout l’article :
article
H1
section
H2
section
sidebar
H1
H2
/section
/section
H2
H2
Ça devient vite énervant…
Par contre le châpo n’est pas un résumé.
Le résumé a d’ailleurs ses propres balises : details, puis summary.
Je l’utilise sur mon blog : sur la home de la catégorie j’extraie le résumé et quand on rentre sur l’article on part sur le chapô tandis que le résumé se retrouve sur la colonne de droite. La règle étant que celui-ci ne soit visible qu’à la demande du lecteur.
Bref, tout cela est assez compliqué et depuis plus d’un an que je code en HTML5 (voir HTML5 machin chose je n’ai toujours pas de preuve tangible d’un bénéfice côté référencement.
Oui, en dehors du fait que je n’utilise jamais de h1 dans les heander de mes sites parce que ce n’est pas prévu pour ça et que, derrière le logo du site, ya souvent unlien vers la home et que les liens en home sont moins bien (pour ne pas dire « pas du tout ou presque ») pris en compte pour le SEO
Non, je reste fixée à mon idée que le H1, c’est 1 seul par document pour le qualifier dans son ensemble. Ensuite, h2 qualifie ses sections.
Lookez sur OpenWeb je ne pense pas qu’ils vous diront des choses sensiblement différentes des miennes, html5 ou pas d’ailleurs 😉
Mais je le re-dis, ca n’engage que moi hein, alors pas taper (ou pas la tête !) ^^
ah merdoum !
que les liens en home sont moins bien (pour ne pas dire « pas du tout ou presque ») pris en compte pour le SEO
Il fallait bien sur lire « les liens EN BALISE HX » et non pas « en home ». Désolé…
Très intéressant, j’en apprends en même temps sur le HTML5 et sur le référencement : je ne savais pas que le Title devait être unique sur la page (pas répété dans le H1) : il me semble avoir lu plusieurs fois le contraire, mais c’est vrai que c’est plus logique (ce n’est pas très naturel sinon). Je vais de ce pas changer mes balises H1. 😉
Merci pour l’article
@Bigg : disons pour être clair que si tu dois choisir entre 2 optimisations, c’est le title qui doit faire l’objet de toutes tes attentions. Ca peut reprendre ton h1 mais le mieux est d’adapter ton H1 pour qu’il tape des mot-clés complémentaires à ton title (principe d’optimisation de la longue traine)
Si déjà entre title et h1 t’as une bonne combo, quelque part les urls propres sont presque superflues derrières 😉
Mais de base, les 2 éléments les plus importants pour le ref de ta page sont title et h1 d’où l’intérêt de ne surtout pas les multiplier dans la page sinon tu risques :
– soit de foutre toute ta SEO par terre
– soit de te faire blacklister par Google pour suroptimisation, ce qui en soit, revient à epu près au même donc…
Merci pour cet article synthétique et intéressant à propos du balisage html5 et son implication dans le cadre du référencement d’un site Web.
Pour ma part, je pense que le contenu rédactionnel prévaut car il permet de se distinguer de la masse d’article sur Internet traitant d’un sujet similaire.
Il faut un balisage bien fait pour se faire comprendre au mieux par les moteurs de recherche.
A partir du moment où il y a un balisage respectueux du W3C. Alors on peut chipoter et tenter de s’approcher toujours plus près de la perfection de la structure et des balises de son code.
Mais le contenu entre les deux balises :
…..
est celui qui fait la plus-value et sans lequel il n’y a pas de page Web à écrire !
Encore merci
Belle démonstration.
J’ai eu plus de mal à expliquer que trop de H1 tue le H1 dans mon billet sur le sujet.
http://www.laurentbourrelly.com/blog/640.php
La question du HTML5 est encore plus intéressante, même si je pense que sa généralisation n’est pas pour (demain ou même après demain).
En tout cas, je me penche assidument sur le sujet et je suis en ce moment même en train de bosser sur mon tout premier site en HTML5.
Aïe, les gueguerres de H1 en SEO.
Autant je rejoins Laurent et loiseaudenuit sur la théorie, autant on se rend compte des milliers d’exemples contraires qui fonctionnent bien (les blog WP avec H1 et Title et URL idem par défaut).
Mon avis est de moins en moins tranché sur le sujet. Les tests que j’ai fait ne remontent rien de significatif, bref, je nage en plein flou artistique.
En fait, je traite vraiment ce cas au cas par cas.
Un vieux site bien ranké pourra faire n’importe quelle cochonerie et tout passe. Un jeune site aura intérêt à limiter au maximum la suroptimisation. Dans ce dernier cas, les recommandations de Loiseau et Laurent sont à suivre à la lettre.
@Loiseau2nuit : merci beaucoup pour ces précisions et tes conseils précieux!
Bien sûr qu’il faut prendre chaque site comme un cas particulier!
C’est ce que je dis dans mon billet, mais les gens ne lisent pas forcément tout.
Les facteurs principaux qui permettent de supporter une suroptimisation relative étant évidemment âge du domaine et autorité/popularité.
@Loiseau2nuit : merci pour ces précisions et conseils très précieux!
C’est clair, styler les h1 différemment selon leur profondeur n’est pas simple.
D’où ma tentative HTML5 Titles Inception … 😉
Merci Nicolas pour cet excellent html5 titles inception. J’ai ajouté une note à ce sujet dans le billet, et un lien dans la linkograhie.
On voit bien que Less est beaucoup plus concis, mais je me suis toujours demandé (sans avoir vraiment cherché de réponse) si on ne déportait pas trop de choses sur le serveur depuis quelque temps ? Quelqu’un a fait des calculs ?
Merci pour le lien ! 😉
Concernant LESS, pas de problème de perfs côté serveur, vu que je génère la « vraie » CSS à la volée directement quand j’édite ma CSS LESS, grâce à l’appli LESS.app pour Mac.
Euh… Woaw oO !
Je crois que l’approche qui reste la plus light est celle de Nicole Sullivan à ce stade :
h1, .h1 {…}
h2, .h2 {…}
…
Quand tu génères le contenu avec un CMS, tu ne sais pas toujours à l’avance à quelle profondeur sera ton contenu, d’autant plus si un même contenu peut servir à plusieurs profondeur selon les endroits du site.
S’appuyer uniquement sur des h1 « sectionnés » et mon HTML5 Titles Inception est alors un grand confort. C’est visible sur mon site.
Peut être faudrait voir à l’usage, moi ce que je vois surtout, c’est la complexité que prend d’un coup la CSS pour styler un truc aussi simple qu’un titre en fait, j’avoue que je ne suis pas habitué à ça. Peut être aussi parce que depuis quelques temps je travaille sur des projets à plusieurs mains et que du coup le plus simple reste encore une garantie qu’aucune boulette ne sera commise en amont comme en aval… je sais pas. Je passe en test on verra bien 🙂
Nous sommes bien d’accord que c’est inutilement compliqué et lourd (et sans doute pas très performant pour le dessin de la page par le navigateur), mais en attendant que tous les navigateurs supportent le sélecteur any() de Firefox, c’est bien utile ! 😉
Côté SEO, on reste quand même pendu à une réponse du Dieu Google par rapport à la prise en compte du HTML5.
Si j’en crois des indices comme ceux là http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=146750
les micro formats commencent à émerger, mais j’aimerai être sur des bases solides avant de revoir le balisage de fond en comble.
LaurentB — C’est en forgeant que l’on devient forgeron, et je suis convaincu qu’il faut se mettre le plus rapidement possible à expérimenter HTML5 pour être prêt.
Dans une optique SEO, c’est différent : si c’est pour faire du « keyword stuffing », autant rester avec une seule balise h1 pour éviter de se faire blackbouler ;))
Sinon, si un article présente plusieures parties distinctes, autonomes, pourquoi ne pas les introduire avec plusieurs h1, même si d’un autre point de vue, on aurait plutôt intérêt à écrire plusieurs billets, mais c’est un autre débat 😉
Vi vi j’ai mis les mains dans le cambouis http://www.laurentb.me/
Pour l’instant, c’est juste un thème chopé chaisplusoù, mais ça m’a permis de voir comment c’est foutu.
Prochaine étape est d’étoffer le site avec des tests pour voir la prise en compte par Google.
Sinon, oui je pense aussi que si le H1 de section doit revenir sur une même page, c’est peut-être qu’il fallait déporter sur une autre page.
Ah ben Laurent je vois que tu te fais plaisir ^^
Ben en même temps, roulez donc jeunesse parce que si c’est moi qui fait le test (ce qui était implicitement prévu) vous n’aurez pas le résultat avant 2018 compte tenu de l’emploi du temps à venir …
Mais plus j’y pense et moins je vois pourquoi html5 révolutionnerait si fondamentalement le SEO / la nature même d’un document.
Le balisage exotique (html5, microformat, etc…) est une chose, la structure globale d’un document en revanche, en est une autre et reste immuable AMHA.
De toute façon, là c’est même pas Google qu’il faut attendre, c’est le W3C. On parle d’un standard qui n’est pas vraiment finalisé et au train où vont les choses c’est pas pour demain. Peut être pas un hasard si GG ne communique dessus que du bout des lèvres….
argh, la balise « code » ne semble pas fonctionner… 🙁