Bon usage des balises de titre

Bonsoir à tous

Pendant des années, les quelques sites dont je m'occupais n'étaient pas particulièrement riches en documents, essentiellement quelques textes des images et des tables de divers sortes d'objets (événements, partitions de musique, photos ou enregistrements) et donc un titre en haut de chaque page suffisait.

Je participe actuellement à la modernisation d'un site qui comporte de nombreux documents, avec chapitres, paragraphes de divers niveaux, etc.
Je cherche un document qui fasse le point sur les "bonnes pratiques" en matière d'utilisation des "balises de titre" (<hx>), du genre quand et comment il est raisiponnable d'utiliser une balise h3 ou h4.

Ce que je comprends c'est que ces balises sont "sémantiques", c'est à dire qu'elles véhiculent une signification. Pour le lecteur humain, cette signification est portée par la présentation du texte, pas par les balises qu'il ne voit pas. Que cette présentation soit portée par telle ou telle balise n'a en soi aucune sorte d'importance. Ce sont donc les lecteurs "machines" qui les utilisent, si je comprends bien essentiellement les "renifleurs".

Je serais heureux d'avoir un peu plus d'information pour guider nos choix.

Merci de bien vouloir nous faire partager votre expertise en ce domaine

En théorie, depuis html5 (et pour les puristes) : chaque balise section ou article est en mesure d'avoir sa propre hiérarchie h1-h6 indépendante des autres.

En pratique (et donc, pour les pragmatiques comme moi) : bien que nous soyons en 2015 il est toujours recommandé de n'avoir qu'un seul h1 par page ; les articles et sections devront donc commencer au plus haut par h2. La faute aux moteurs de recherche qui, pour analyser un site, se basent avant tout sur une moyenne statistique des structures de sites qu'ils rencontrent.

Il faut toujours penser que les moteurs de recherche sont pragmatiques, pas idéalistes : ils extraient les données à partir de ce qui est utilisé par le plus grand nombre à un instant T, pas à partir ce qui devrait être l'idéal.

Les balises de titre ne sont pas uniquement utiles pour les moteurs de recherche. AVant tout ils sont primordiaux pour les lecteurs d'écran et toute autre logiciel d'assistance, ainsi que pour le mode spécial lecture de certains navigateurs. Ce serait bien de ne pas réduire la sémantique à une simple SEO.

Pour le reste je rejoins la réponse précédente, en théorie chaque article ou section peut avoir sa hiérarchie propre recommençAnt à H1. Mais en pratique il y a encore d'anciens logiciels d'assistance qui ne reconnaissent pas ou mal ces nouvelles possibilités.

Merci de vos réponses.

Quentin, peux tu expliquer un peu plus en détail:

QuentinC a écrit :
...Avant tout ils sont primordiaux pour les lecteurs d'écran et toute autre logiciel d'assistance, ainsi que pour le mode spécial lecture de certains navigateurs.

Que fait un logiciel de ce genre quand il rencontre une balise <h4> et en quoi est-ce different d'un <h3> ou un <h5>?
J'ai constaté que Wikipedia ne va jamais au delà de <h3>, même si les articles ont une structure qui justifierait plus de niveaux
En quoi est il important de mettre <h4> plutôt que <h3 class="...">?

Bonjour,

une introduction est disponible sur Openweb : http://openweb.eu.org/articles/respecter_semantique MAIS il FAUT arrêter la lecture quand ça commence à parler de Lynx.
Trop de lignes de disclaimer :
ce n'est plus depuis 10 ans un navigateur représentatif de quoi que ce soit (s'il l'a jamais été), il y a bien quelques phrases à conserver mais avec tellement de pincettes de la taille d'une débardeuse que... Un utilisateur de lecteur d'écran a le même navigateur que la moitié des internautes (vu que c'est pas Chrome, ha !) avec JS activé, le même support des API HTML5 et la moitié de la norme ARIA supportée et quand un contenu est caché en CSS avec display: none il est tout autant caché au lecteur d'écran (alors que Lynx ne supporte même pas CSS)
</fin du semi-HS>

Les lecteurs d'écran ont plusieurs modes d'accès à l'information d'une page et quand une page est longue ça devient très utile :
- Lire du début à la fin
- Reconstruire un sommaire à partir des niveaux de titre (comme dans Wikipedia ou Word / LibreOffice)
- Lister les liens l'un après l'autre
- Lister les "zones" de la page, ce qui pour l'instant correspond plutôt aux landmark role ARIA (role="main", role="navigation", etc) mais correspond nativement en HTML5 aux éléments main (unique), navigation (normalement unique ou presque), aside, header, footer (pas du tout uniques en HTML5 parce que c'est pas le même usage, du coup l'attribut role c'est bien)

Pour vérifier rapidement les niveaux de titre d'une page, j'utilise l'extension HeadingsMap et son 1er onglet.
PAS le 2e onglet "HTML5 Outline" (dont parle Olivier C) : c'était une bonne idée, en fait non, ce n'est tellement pas la priorité pour les constructeurs de navigateurs de l'implémenter correctement voire tout court que ça va être supprimé par le W3C d'HTML5.1

Merci Felipe

L'article me semble un peu succinct, et l'argument

a écrit :
Les navigateurs afficheront le texte encadré par cette balise avec un rendu par défaut (caractères plus grand, plus gras) qui permettra de le dissocier du reste.

est à mon sens un contre argument.

Les propriétés données par défaut aux balises <hx>, et en particulier <h1> sont ridicules. Il faut toutes les restyler, et comme il y en a 6... Cela m'a conduit pendant longtemps à n'utiliser qu'une seule balise de titre (<h4> parce que ses propriétés par défaut sont "acceptables"), notamment dans les mails (Thunderbird) où le restylage est très pénible à effectuer, et par extension dans les feuilles HTML n'ayant qu'un seul titre, plutôt que <h1>, ce qui je le sais n'est pas conforme aux "bonnes pratiques" mais je n'en ai jamais constaté le moindre effet négatif.
Par ailleurs ce document n'indique pas quelle est l'importance de dire <h4> plutôt que <h3> ou <h5>.

Je vais installer HeadingsMap pour voir ce que ça donne, mais je ne comprends pas quel intérêt pratique ça peut représenter.

Pour moi, une page écrite en HTML a 4 sortes de lecteurs:
1) le mainteneur de la page, c'est à dire un être humain qui est intéressé à se retrouver rapidement dans le code d'une page pour y apporter des modifications
2) les navigateurs, qui s'en servent uniquement pour calculer la présentation sur écran (ou autre)
3) les renifleurs, qui parait-il prennent en compte certains aspects "sémantiques" de certaines balises (bien qu'il ne soit pas très clair de comprendre ce qu'ils en font)
4) les lecteurs d'écrans, qui à mon sens ne sont que des navigateurs d'un genre particulier, et dont je ne comprends pas vraiment ce qu'ils font de spécial selon la balise dans laquelle ils trouvent un bout de texte. J'ai fait quelques essais, mais c'est inaudible quand on n'en a pas soi même besoin.

Si je reviens à mon site à rénover, les pages sont en texte "au kilomètre", les titres et sous titres sont des <span> stylés, les paragraphes sont indiqués par des <br><br>, etc.
Cela n'a cependant pas l'air d'empêcher Google de l'indexer correctement.

Introduire un peu de structuration dans ce site (ce qui implique de développer des moulinettes informatiques pour ce faire, compte tenu du nombre de pages) me semble intellectuellement intéressant, mais après tout le mainteneur actuel du site s'en sort très bien.... J'aimerais bien avoir quelques "klling arguments" pour changer cet état de choses, plutôt que de semer le souk sans réel bénéfice pour qui que ce soit, et même en perturbant les habitudes de travail du gestionnaire du site.

Pour oser une comparaison, essayez un peu d'introduire réellement le système métrique dans les pays anglo-saxons! 40 ans après, les Canadiens vous disent toujours qu'il y a eu 6 pieds de neige dans leur jardin, sans compter la vieille dame à qui je demandais (début des années 80) si la prochaine station-service était loin:
- Non, me dit-t-elle, c'est tout près!
- Un ou deux kilomètres?
- Oh non! pas tant que ça, ça doit faire une paire de miles.

A priori, les balises Hn me semblent avoir une évidente utilité dans la structuration d'un document.
Je ne vois pas trop comment, en effet, apréhender les différentes parties / sous parties d'un article ou d'un bouquin sans qu'il y ait des chapitres, sections et sous sections correctement emboîtés.
Je développe actuellement un générateur HTML en Java (projet personnel) et cette problématique de niveaux dans un document est au coeur de l'analyse.
Cette analyse a mis en évidence le fait qu'il paraît manquer un niveau hiérarchique, situé au-dessus du H1, qui m'a fait défaut lorsque j'ai récupéré des récits de voyages rédigés à la fin de 18ème siècle.
Ceux-ci introduisaient la notion de "Livre I" / "Livre II" etc.
Pas d'équivalent en HTML, hormis peut-être la notion de <section> de HTML5 qui engloberait un "Livre" et ses chapitres / sections / sous sections.
Plus important à mon sens, les niveaux Hn de HTML servent à structurer les tables des matières des epub...
Si un jour le gestionnaire du site s'avise d'en faire une version epub, il appréciera probablement le travail fourni en amont pour structurer les documents (cf. logiciel libre Sigil pour construire des epub).

N'oublions pas que le HTML a été inventé au CERN, en très peu de temps, par quelques personnes, et que nous du subissons toujours le contre coup (et même le contre coût) de cette improvisation. Toute tentative d'apporter de la rationalité en fonction de l'expérience et des besoins des utilisateurs se heurte à la nécessité d'être compatible avec l'existant.
Sur le fond les h1 à h6 sont une cote mal taillée qui date de la fin des années 1980 qui ne correspond pas à grand chose. La question n'est pas de savoir quelle est la pensée profonde qui est contente dans ces balises, il n'y en a évidemment aucune, c'est de savoir ce que les divers outils du web font de ces balises, de façon à pouvoir prendre des décisions sensées quant à leur utilisation.
Une réflexion sur la logique d'un document (je veux dire quelque chose du genre communication scientifique ou article de fond d'une revue) conduit assez naturellement à considérer qu'une structure hiérarchisée du genre

<document>
    <partie>
      <chapitre>
         <paragraphe>
            ........

avec à chaque niveau une balise <titre>
serait bien plus approprié que ce que nous trouvons actuellement dans les pages HTML.
On peut très bien faire ça en utilisant des balises <section> imbriquées avec une seule balise de titre, disons <h2>, à chaque niveau, et je suis en train de me demander sérieusement si ce n'est pas tout simplement ce que je vais faire.
Y a-t-il à votre connaissance un outil (lecteur d'écran ou renifleur) qui serait perturbé par une telle approche?
Modifié par PapyJP (13 Nov 2015 - 22:10)

Dans le cadre de mon développement Java, j'ai eu à me poser ce genre de question afin de rendre l'outil le plus générique possible.
La réponse la plus adaptée que j'ai trouvée, et mise en place, au niveau de mes classes objets est de ne pas créer d'instance de type "chapitre" ou "section", par exemple, mais de n'avoir qu'une seule entité nommée "Heading" (pas très original...).
Selon le niveau auquel cette entité se trouve dans l'arborescence, le logiciel génère ensuite un H1, H2, etc. lors de la sérialisation HTML.
L'aspect très pratique de cette approche c'est qu'elle permet de déplacer un bloc structuré (heading donc...) d'un endroit de l'arboresence à un autre, sans avoir à renuméroter quoi que ce soit puisque cette renumérotation est dynamique.
La seule condition lors du déplacement d'un Heading est de lui affecter omme parent, une fois le déplacement effectué, la racine du document (ce qui correspond alors à un "Chapitre" -> H1) ou un autre Heading (ce qui équivaut à une section H2 ou sous section H3..H6).
S'agissant d'un générateur, c'est lui qui affecte in fine les balises adéquates (qu'il s'agisse de flux HTML, RTF ou PDF) lors de la sérialisation finale.
Pour l'instant cela fonctionne et j'obtiens des pages HTML correctement structurées.

Quand j'explique l'utilité de la sémantique et son utilisation par les lecteurs d'écran, je prends toujours l'exemple du bouquin et des magnétophones

Quand tu lis un bouquin, que ce soit un ouvrage scientifique ou littéraire, je pense que tu apprécies le fait qu'il y a une table des matières. C'est ce qui te permet de te repérer dans l'ensemble que constitue le livre, et ça te permet de commencer ou recommencer la lecture à un point précis sans devoir chercher un passage désigné ou bien l'endroit où tu t'étais arrêté précédemment.

Imagine maintenant un livre sans table des matières. Il est où le chapitre 12 ? Inévitablement, tu es obligé de chercher à tâtons en tournant rapidement les pages.
Par chance, tu as des yeux qui fonctionnent bien et les titres, écrit en plus gros, en gras et centrés en haut de la page, tu les repères assez vite.

Réfléchis maintenant à ceci: un lecteur d'écran, très sommairement, c'est ton bouquin lu par une voix plus ou moins monocorde, enregistré sur une K7.
Sur une K7, tu peux avancer ou reculer, mais tu n'as pas d'index. Comment je trouve mon chapitre 12 ? J'avance un peu, j'écoute 20 sec, OK c'est plus loin, j'avance encore un peu, j'écoute 20 sec, ah non c'est trop loin, je recule un peu, j'écoute 20 sec, ah mince c'est un tout petit peu plus loin, je ravance, oh non j'ai trop avancé, arf, zut, fait ch&§\ et m#@*%!

Ajouter des titres de section sur ta page web, c'est quoi ? c'est passer de la K7 au CD.
Sur un CD, tu as un bouton pour passer à la chanson suivante, un autre pour retourner à la précédente, et parfois un troisième pour recommencer au début de la chanson en cours (souvent c'est le même que le deuxième).
Je veux écouter le chapitre 12 ? C'est pas compliqué, j'appuie 12 fois sur le bouton pour passer au chapitre suivant; c'est simple, rapide et efficace; à tout casser ça me prend 5 sec.
Pourquoi et comment ça marche ? l'éditeur qui a construit le CD a mis une table des matières au tout début du CD et dans cette table, il a indiqué que telle plage commençAit à telle position.

Eh bien, ajouter une hiérarchie de titres correctement construite sur ta page web, en tant qu'utilisateur de lecteur d'écran, c'est ça que tu m'apportes. Mon lecteur d'écran analyse le contenu de la page et est capable de constituer une table des matières, à partir de laquelle je peux lui commander de commencer la lecture à un point précis. Je ne suis plus obligé de parcourir ta page tantôt en avant, tantôt en arrière pendant des heures, au petit bonheur la chance, pour trouver l'information que je recherche.

Bien sûr, ceci n'est qu'une métaphore extrêmement simplifiée, et techniquement, ce n'est pas de cette façon que ça marche. Demander une table des matières automatique est une possibilité parmi beaucoup d'autres. Les lecteurs d'écran sont bien plus puissants que cela en réalité; mais à condition, et uniquement à condition que toi, en tant qu'éditeur du contenu, tu indiques correctement quel est le rôle de chaque élément. C'est ça la sémantique: expliquer à un logiciel, en l'occurence ici un lecteur d'écran qui me permet de lire des pages web, quel est le sens de ton contenu, afin qu'il puisse me le restituer dans les meilleures conditions possibles.
Si ton contenu n'est pas hiérarchisé et classé, ou si c'est fait faux ou n'importe comment, devant moi j'ai une K7: je peux toujours essayer de trouver quelque chose mais c'est laborieux.

A ce stade, tu pourrais me répondre que le lecteur d'écran devrait me dire que tel texte est écrit en ARial 18, en gras, centré, et à 2cm du bord supérieur de la page, et ce serait à moi d'en déduire que c'est probablement un titre.
Mais, premièrement: puisque les règles typographiques peuvent changer énormément d'une oeuvre à l'autre, je n'aurais pas de moyen simple et universel pour sauter d'un chapitre à l'autre; pour chaque livre la règle serait à reconstruire. Ce serait l'enfer, et surtout, ce serait globalement inutilisable. Le seul moyen sûr et fiable pour que j'obtienne l'information qu'est-ce qui est un titre est bel et bien que toi, en tant qu'éditeur du contenu, tu me la donnes.
ET deuxièmement, qu'est-ce que j'en ai à cirer de l'apparence visuelle de cette portion de texte ? Pas grand chose. Tout ce que je veux, c'est comprendre le message que l'écrivain souhaite faire passer. Que tu écrives en rouge, en vert ou en bleu, moi, concrètement, je m'en fiche. Si la couleur fait partie de ton message, i.e. le fait que tu écrives en rouge plutôt qu'en bleu a de l'importance pour toi autre que purement esthétique, alors c'est une information que tu dois aussi me transmettre par un autre moyen.

Si avec tout ça tu n'as pas compris l'utilité et l'importance de baliser ton contenu dans les règles de l'art, j'abandonne.

Voilà. Désolé pour ce long pavé nocturne, et bon week-end.
La prochaîne fois, on parlera des recherches sous forme de questions posées en langage naturel, une autre application importante nécéssitant une sémantique riche et précise.

Rajout:

a écrit :
On peut très bien faire ça en utilisant des balises <section> imbriquées avec une seule balise de titre, disons <h2>, à chaque niveau, et je suis en train de me demander sérieusement si ce n'est pas tout simplement ce que je vais faire.

C'est l'aproche proposée par le W3C pour HTML5, à ceci près que le titre de plus haut niveau d'une section est toujours H1 (pourquoi diable proposes-tu H2 ?). En théorie ça devrait fonctionner; sauf que personne n'a réellement pris le pli au point qu'il est suggéré de supprimer cette possibilité, et que si ça a des avantages intéressants par rapport à l'approche H1-6 classique, p.ex. déplacer des sections ou remixer des documents sans nécessité de modifier le balisage, ça a aussi des inconvénients, la complexité plus grande notamment, mais aussi la continuité de la hiérarchie sur plusieurs pages, ou le stylage CSS peut-être moins facile/direct.
Modifié par QuentinC (13 Nov 2015 - 23:41)

Merci Quentin pour cet exemple du bouquin et du magnétophone/k7, je te l'emprunterait volontiers à l'avenir car il explique plutôt bien quelque chose de pas si évident pour les personnes non familiarisées avec les problématiques d'accessibilité des documents web et avec la question de leur sémantique intrinsèque, bien trop souvent perdue de vue pour des raisons un peu stupides : ici un problème de rendu visuel des niveaux de titres (non mais c'est la meilleure celle là !) ; là pour des raisons de SEO (purée mais si les textes de ton site avaient été réalisés suivant les standards existant même il y a 10 ans, il n'y aurait rien à redire ). Merci

Pour abonder dans le sens de QuentinC (fort juste au demeurant la comparaison K7 / CD...), j'ajouterais que les balises H1..H6 sont bien souvent assorties d'un attribut ID utilisé comme ancre pour un renvoi direct depuis une autre partie de la page et/ou du site web.
On en revient de fait à la notion de structure du document, très importante, totalement distincte de sa représentation graphique (gras, souligné, clignotant, peu importe...).
Autre aspect à prendre en compte : sans que cela concerne stricto sensu la typographie (la tendance semble être à revaloriser cet aspect un peu perdu de vue), nous restons tout de même dans la notion de "beau" document, c'est à dire agréable à lire ET parcourir en ayant des points d'ancrage parfaitement identifiés.

QuentinC a écrit :
C'est l'aproche proposée par le W3C pour HTML5, à ceci près que le titre de plus haut niveau d'une section est toujours H1 (pourquoi diable proposes-tu H2 ?). En théorie ça devrait fonctionner; sauf que personne n'a réellement pris le pli au point qu'il est suggéré de supprimer cette possibilité, et que si ça a des avantages intéressants par rapport à l'approche H1-6 classique, p.ex. déplacer des sections ou remixer des documents sans nécessité de modifier le balisage, ça a aussi des inconvénients, la complexité plus grande notamment, mais aussi la continuité de la hiérarchie sur plusieurs pages, ou le stylage CSS peut-être moins facile/direct.

Je me suis toujours demandé, en effet, pourquoi le W3C n'avait pas pris une approche plus agnostique de la titraille en ne définissant qu'un seul type de balise <heading>, par exemple et comme je le citais précédemment.
Cela fait plusieurs années que je bosse sur la problématique de l'auto-documentation dans mon entreprise et ce concept s'est imposé très vite pour, justement, ne pas avoir à renuméroter des tas de chapitres / sections et sous sections en fonction de l'arrangement des documents.
La documentation informatique étant par nature très vite obsolète et réécrite, ce qui est un chapitre aujourd'hui se retrouve relégué parfois en section ou sous section le mois suivant.
Pas très "cool" de devoir tout réorganiser si l'outil d'auto-documentation n'a pas été conçu dès l'origine dans une optique de généricité et réorganisation automatique.

a écrit :
Merci Quentin pour cet exemple du bouquin et du magnétophone/k7, je te l'emprunterait volontiers à l'avenir car il explique plutôt bien quelque chose de pas si évident pour les personnes non familiarisées avec les problématiques d'accessibilité des documents web et avec la question de leur sémantique intrinsèque, bien trop souvent perdue de vue pour des raisons un peu stupides

Mais fais seulement ! Cet exemple a déjà fonctionné plusieurs fois IRL. Le principal intérêt de cet exemple c'est que tout le monde sait ce qu'est une K7 et un CD. L'ennui c'est que dans 25 ans, quand mon âge aura doublé, plus personne ne comprendra...

a écrit :
Je me suis toujours demandé, en effet, pourquoi le W3C n'avait pas pris une approche plus agnostique de la titraille en ne définissant qu'un seul type de balise <heading>, par exemple et comme je le citais précédemment.
Cela fait plusieurs années que je bosse sur la problématique de l'auto-documentation dans mon entreprise et ce concept s'est imposé très vite pour, justement, ne pas avoir à renuméroter des tas de chapitres / sections et sous sections en fonction de l'arrangement des documents.

Il me semble que ça avait été proposé tout au début, dans les brouillons de HTML5, avec un unique élément <h>; ou peut-être que c'était dans les travaux du WHATWG ou ceux de XHTML2; je ne sais plus. A mon avis c'est à cause de l'argument rétrocompatibilité qu'on a finalement hérité de ce système hybride, pas forcément des plus logiques ni pratiques. Du coup personne n'a compris et la plupart des gens se servent de <section> exactement comme ils se servent de <div>; et ça leur donne faussement bonne conscience en plus, parce qu'ils croient avoir ajouté de la'ccessibilité alors qu'en fait, ça ne change pas grand chose vu la façon dont ils les utilisent.

L'avantage de ne pas utiliser <section> et de se contenter des titres <h1-6> se voit dans les epub et la continuité de la hiérarchie sur plusieurs pages, aisément réassemblables sans débuts/fins intermédiaires de <section> parasites. ET pour identifier et déplacer des sections entières, c'est moins facile mais l'algorithme n'est pas pour autant très compliqué (je l'ai déjà fait dans un projet d'éditeur epub).
L'amélioration qui serait possible, c'est de changer <h1> en <h level="1">; ça faciliterait certaines manipulations DOM.

Merci à tous pour cette discussion nocturne, dont je partage totalement le point de vue.

Simple réponse -- mais je croyais que c'était évident -- pourquoi <h2> et pas <h1>?
En fait la bonne réponse serait <h> ou <heading> comme expliqué plus haut, mais cela n'a pas été retenu. Ce le sera peut être un jour, mais à mon âge on évite de faire des choses pour un temps que les plus de septante ans ne pourront pas connaître.

L'utilisation des balises n'est pas un problème technique, c'est un problème de psychologie: qu'y a-t-il dans la tête de celui ou celle qui écrit un programme renifleur ou lecteur d'écran?
<h1> est tellement associé "traditionnellement "à "titre de page" qu'il est plus prudent de ne pas mettre de <h1> dans le corps de la page si on craint de perturber le reniflage des renifleurs.

Un point qui a un peu à voir avec ce sujet:
sur la recommandation de Felipe, j'utilise HeadingsMap pour regarder la structure des pages HTML, non seulement les miennes mais également celles des autres.

Je constate ainsi que CETTE PAGE (sur laquelle je suis en train d'écrire) ne possède qu'un <h1> et pas d'autres <hx>, le site privé de Raphaël a un titre en <h1> et un sous titre en <h2>, les pages Wikipédia ont un titre <h1>, quelques <h2> et des <h3>.... Le site du Monde a des h2 et des h3 un peu au petit bonheur, et pas de h1
Je n'ai pas (encore) trouvé de site avec plusieurs h1.

Tada !! :

http://www.alsacreations.fr/



M'enfin pour avoir égrené la question sur le forum de webrankinfo (donc orientée SEO la question), c'est encore pire que les meta keywords : il semble que tout le monde reste sur un seul h1 par page au cas z'où...
Pire de chez pire : lorsqu'on trouve un article contredisant le schmilblick, les SEO's fans répondent qu'il s'agit d'une méthode pour améliorer le référencement de l'article concerné : le môssieur écrit un article disant que non, il ne faut pas 1 seul titre de niveau 1 par page ; comme il sera le seul ou presque à le dire, il ressortira d'avantage dans les SERPS...
Modifié par Manhattan (14 Nov 2015 - 16:01)

Manhattan a écrit :
Tada !! :
http://www.alsacreations.fr/

Exact, mais ça ne donne pas vraiment l'impression d'être fait sciemment....

a écrit :
Simple réponse -- mais je croyais que c'était évident -- pourquoi <h2> et pas <h1>?
En fait la bonne réponse serait <h> ou <heading> comme expliqué plus haut, mais cela n'a pas été retenu.

C'est pas forcément très logique, d'accord, mais c'est bien <h1> qui joue le rôle du <h> ou du <heading> décrit, dans le modèle HTML5.

La prochaîne fois, choisis plutôt <h+Math.ceil(Math.random()*6))>

a écrit :
<h1> est tellement associé "traditionnellement "à "titre de page" qu'il est plus prudent de ne pas mettre de <h1> dans le corps de la page si on craint de perturber le reniflage des renifleurs.

Non, faux, le titre de page ça devrait être <title>, et rien d'autre.
Pour information, le contenu de <title> est la toute première chose qui m'est lue quand j'arrive sur une nouvelle page.

a écrit :
Je n'ai pas (encore) trouvé de site avec plusieurs h1.

Je suis loin d'être une référence en matière de sémantique, je fais parfois des contours au standard volontairement pour simplifier encore davantage l'accès aux lecteurs d'écran, mais sur mon petit site web perso, il y a plusieurs H1 par page sur la page d'accueil, un par chapeau de billet.

Il me semble aussi que l'ancien site de Laurent Denis, blog-and-blues.org, avait aussi un H1 par chapeau de billet. Par contre inutile de cliquer, il n'est plus en ligne.

C'est une question de point de vue, il y a des arguments pour et des arguments contre. Mais ce n'est pas parce que l'écrasante majorité du monde fait les choses d'une certaine façon qu'elle a forcément raison.
Le problème de Google, c'est justement que, pour eux, ce que fait la majorité est nécessairement bon. C'est la façon de fonctionner de leurs algorithmes qui veut ça: en statistiques, on ne peut pas inventer des données qu'on n'a pas.

En fait c'est ça le souci: Google nous pousse au conformisme: tu veux innover, faire autrement parce que tu es convaincu que c'est mieux ? Tant pis pour toi, ça sera forcément à ton détriment dans le classement.
Et comme dans notre société d'hyperconsommation, un véritable culte est voué au classement, eh bien, on suit la masse et on ne se pose plus de question.
Modifié par QuentinC (14 Nov 2015 - 16:46)

QuentinC a écrit :
En fait c'est ça le souci: Google nous pousse au conformisme: tu veux innover, faire autrement parce que tu es convaincu que c'est mieux ? Tant pis pour toi, ça sera forcément à ton détriment dans le classement.
Et comme dans notre société d'hyperconsommation, un véritable culte est voué au classement, eh bien, on suit la masse et on ne se pose plus de question.

Tu as tout à fait raison.
Il y a une loi contre le monopole aux US, mais elle n'a jamais été appliquée contre IBM en son temps, ni contre Microsoft, et elle ne le sera pas plus contre Google. On peut le regretter, mais c'est comme ça, et je serai mort avant que ça change... si ça change un jour.
Quand on se dit que dans 10 ans, 20 tout au plus on ne sera plus là, on finit par arrêter de se battre contre des moulins à vent...

L'objectif de ce site, c'est de publier des photos avec explications et commentaires sur un sujet pointu.
L'objectif de notre opération de relooking, c'est que les utilisateurs anciens ne soient pas paumés, et que de nouveaux utilisateurs ne soient pas rebuté par l'aspect du site.
Comment recruter de nouveaux utilisateurs autrement qu'en améliorant le référencement?
Et comment améliorer le référencement autrement qu'en se pliant aux bons vouloirs de Google?