Re : Référencement?
Bonjour,
...Compris.
Une lecture complémentaire utile trouvée ici : http://css.4design.tl/quelques-notes...-h1-avec-html5.
______________
Il me semble que PieceOfCake a raison concernant la pertinence de ces <H1> multiples : Google n'est pas très loquace à ce sujet.
A mon (humble) avis, il faut distinguer au moins deux questions concernant la multiplication des balises <H1> dans un même document HTML5 :
On peut faire l'hypothèse que ces deux questions sont liées. En effet, ce sont les moteurs de recherche qui sont susceptibles d'utiliser de telles indications dans le code source même des pages. Dès lors, quel peut être le gain, de leur point de vue, de permettre deux balises <H1> sur la même page (sans risque de pénalité), sinon de les aider à (encore mieux) extraire la structure du contenu ?
PieceOfCake fait bien là aussi de rappeler le triste destin de la méta <keywords>, aujourd'hui quasi délaissée par les moteurs de recherche : si tous les webmasters s'imaginent que multiplier les balises <H1> va améliorer le positionnement d'une page, alors ils vont tous multiplier les balises <H1>, et le sort des balises <H1> multiples subira le même sort que la méta <keywords>. Mais à mon avis, ce risque n'existe pas en l'occurrence, même si tout le monde se met à multiplier les <H1>, car Google (& co) a tiré les leçons de l'affaire des balises <keywords> surexploitées et n'entend pas subir à nouveau le même assaut.
=> Cet argument va dans le sens d'un effet neutre des balises <H1> multiples sur le plan du positionnement. Autrement dit, si mon hypothèse est correcte, alors l'impact de ces multiples <H1> sur le plan du positionnement moteur peut être estimé nul, c'est-à-dire ni négatif ni positif : considérée sous cet angle, une structure comportant plusieurs <H1> dans un document HTML5 aurait ni plus ni moins de chance de propulser la page en 1e position chez Google qu'une structure plus classique comportant une seule balise <H1> et plusieurs balises secondaires <H2>, <H3>...
Certains disent que la balise <H1> située dans <header>, par le fait même qu'elle se trouve dans l'en-tête, aurait un « poids SEO » supérieur aux autres. Certains vont même jusqu'à soutenir que cette première <H1> est la seule à avoir un réel « poids SEO », les suivantes n'étant vues que comme des marqueurs de hiérarchie du contenu.
C'est vraisemblable : les documents HTML5 permettant une structuration plus « claire » pour les moteurs, on peut supposer que l'impact des <H1> multiples serait sensible essentiellement au point de vue de la lisibilité et de la visibilité de la page dans les SERP, l'extraction de « l'arbre » des contenus étant facilitée.
En quelque sorte, cette hypothèse revient à voir la multiplication des balises <H1> de la page seulement comme un moyen venant compléter la méta <description> (...et les microformats, microdata, RDF et compagnie), mais côté structure uniquement — et probablement alors surtout pour les pages comportant un contenu long.
Bonjour,
Si tu respectes la structure ci dessus, chaque header peut contenir un titre h1.
Une lecture complémentaire utile trouvée ici : http://css.4design.tl/quelques-notes...-h1-avec-html5.
______________
Il me semble que PieceOfCake a raison concernant la pertinence de ces <H1> multiples : Google n'est pas très loquace à ce sujet.
A mon (humble) avis, il faut distinguer au moins deux questions concernant la multiplication des balises <H1> dans un même document HTML5 :
- L'impact de ces balises <H1> multiples dans de tels documents est-il positif ou négatif sur le plan de la SEO ?
- A quoi bon multiplier les balises <H1> dans un document strictement structuré dans lequel la hiérarchie H1 > H2 > H3 > ... est déjà scrupuleusement respectée ?
On peut faire l'hypothèse que ces deux questions sont liées. En effet, ce sont les moteurs de recherche qui sont susceptibles d'utiliser de telles indications dans le code source même des pages. Dès lors, quel peut être le gain, de leur point de vue, de permettre deux balises <H1> sur la même page (sans risque de pénalité), sinon de les aider à (encore mieux) extraire la structure du contenu ?
PieceOfCake fait bien là aussi de rappeler le triste destin de la méta <keywords>, aujourd'hui quasi délaissée par les moteurs de recherche : si tous les webmasters s'imaginent que multiplier les balises <H1> va améliorer le positionnement d'une page, alors ils vont tous multiplier les balises <H1>, et le sort des balises <H1> multiples subira le même sort que la méta <keywords>. Mais à mon avis, ce risque n'existe pas en l'occurrence, même si tout le monde se met à multiplier les <H1>, car Google (& co) a tiré les leçons de l'affaire des balises <keywords> surexploitées et n'entend pas subir à nouveau le même assaut.
=> Cet argument va dans le sens d'un effet neutre des balises <H1> multiples sur le plan du positionnement. Autrement dit, si mon hypothèse est correcte, alors l'impact de ces multiples <H1> sur le plan du positionnement moteur peut être estimé nul, c'est-à-dire ni négatif ni positif : considérée sous cet angle, une structure comportant plusieurs <H1> dans un document HTML5 aurait ni plus ni moins de chance de propulser la page en 1e position chez Google qu'une structure plus classique comportant une seule balise <H1> et plusieurs balises secondaires <H2>, <H3>...
Certains disent que la balise <H1> située dans <header>, par le fait même qu'elle se trouve dans l'en-tête, aurait un « poids SEO » supérieur aux autres. Certains vont même jusqu'à soutenir que cette première <H1> est la seule à avoir un réel « poids SEO », les suivantes n'étant vues que comme des marqueurs de hiérarchie du contenu.
C'est vraisemblable : les documents HTML5 permettant une structuration plus « claire » pour les moteurs, on peut supposer que l'impact des <H1> multiples serait sensible essentiellement au point de vue de la lisibilité et de la visibilité de la page dans les SERP, l'extraction de « l'arbre » des contenus étant facilitée.
En quelque sorte, cette hypothèse revient à voir la multiplication des balises <H1> de la page seulement comme un moyen venant compléter la méta <description> (...et les microformats, microdata, RDF et compagnie), mais côté structure uniquement — et probablement alors surtout pour les pages comportant un contenu long.
Commentaire