Hello friends,

When I was working on On-Page optimization, one question arisen in my mind that how many H1 tag can be used on a webpage? Suggest me here please.

9 billion

 

Edit:

 

Nock beat me to it, but his answer is wrong.

Edited June 14, 201610 yr by Jack

Interestingly I was discussing this very thing with Harry Roberts a few months back, I've always been of the opinion that you can use as many H1s as you like as long as your HTML5 is properly structured and he pointed me to this... http://adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html

let's discus

@@citypaul read the link I posted, it really opens up a can of worms here...

I've always thought headings should reflect the content in the document, so the answer is as many as is needed....?

The code doesn't care. You can add as many as you want.

 

But the H1 should really introduce the page - like a headline in a newspaper. If you then have sections on the page use H2, H3 and so on.

 

I know the html5 spec allows for multiple H1 but why make life complicated. The search engines are quite dumb machines so just give them what they expect to see: h1 > intro paragraph > h2 > content > h2 content ... und so wieter. It's a structure that has worked since day one so why mess with it.

I know the html5 spec allows for multiple H1 but why make life complicated.

 

I actually find using a H1 per article or section tag easier to reason about than using a H2. Each one of those articles has a primary heading, and possible subheading. The exception being a dedicated article, which will only have a single heading and a subsequent subheading on a page. A lot of the marketing tools we use flag it as incorrect when you use multiple H1's, yet the spec allows you to do this and actually recommends doing so. Here's a quote from MDN.

 

The HTML <article> element represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable (e.g., in syndication). This could be a forum post, a magazine or newspaper article, a blog entry, an object, or any other independent item of content. Each <article> should be identified, typically by including a heading (<h1>-<h6> element) as a child of the <article> element.

https://developer.mozilla.org/en/docs/Web/HTML/Element/article

 

Another from Tuts+

This is because by marking up your article headlines with <h2> tags you are effectively saying they are level two headings, even though they are actually level one headings within the scope of the <article> section.

 

In turn, the second level subheadings of your articles would necessarily be marked up with <h3> tags incorrectly setting them to level three, your third level headings marked up with <h4> tags and so on.

http://webdesign.tutsplus.com/articles/the-truth-about-multiple-h1-tags-in-the-html5-era--webdesign-16824

 

Every news site seems to do things differently. BBC start with H3's, ITV the same, and the FT and The Guardian seem to have no clear structure to headings that I can work out.

 

(╯°□°）╯︵ ┻━┻

Anybody any views on the article I posted? This was backed up by Harry Roberts advising me against multiple H1s because of user agent issues as mentioned in that article. http://adrianroselli...ultiple-h1.html

 

@@fisicx, This has nothing to do with SEO, Google's algorithm is far from dumb and as far as I am aware it understands HTML5 sectioning with no issues. It's more an issue with accessibility.

Like Jack said, it is not at all complicated to understand that each now section (Article, Section, Aside Nav etc) get's it's own heading context and this allows you to have multiple articles in the same document each with their own heading hierarchy. Again the issue lies with some user agent not interpreting the spec correctly which leads to some accessibility issues.

Edited June 15, 201610 yr by rbrtsmith

Anybody any views on the article I posted? This was backed up by Harry Roberts advising me against multiple H1s because of user agent issues as mentioned in that article. http://adrianroselli...ultiple-h1.html

 

@@fisicx, This has nothing to do with SEO, Google's algorithm is far from dumb and as far as I am aware it understands HTML5 sectioning with no issues. It's more an issue with accessibility.

Like Jack said, it is not at all complicated to understand that each now section (Article, Section, Aside Nav etc) get's it's own heading context and this allows you to have multiple articles in the same document each with their own heading hierarchy. Again the issue lies with some user agent not interpreting the spec correctly which leads to some accessibility issues.

 

That article's interesting, I wonder why it's not common knowledge. It seems like it has been a bug very early on, that possibly won't get fixed.

Anybody any views on the article I posted?

 

I had a read, I agree but to be honest I'm pretty long in the tooth, using the heading family as standard since 1999 and with the HTML 5 claims of multiple I was dubious, and in my stubborn ways kept using the h1 - h3 (occasionally h4). I always look at a web page as a newspaper with the same structural outline, it makes perfect sense to have one single headline h1 just like the papers, h2 for section headings and h3 for nested sections in sections. Semantically with microdata you have the option for headline, alternativeHeadline etc to add additional meaning to the use of headings.

Anybody any views on the article I posted?

Yes, I read the whole thing and still can't see a good reason to have multiple H1s.

 

Just because you can doesn't mean you should. The search engines may be able to understand HTML5 sectioning and if that's what you want to do then fine, but in most cases it's just not necessary.

The article Robert posted advises against multiple H1's, even though it's widely documented that you can use them. In basically any book or article I've read on HTML5 this is presented as something you can do, and should be doing. I've certainly used them before in HTML5 article and section elements. It's an interesting find.

On HTML5 Doctor, for example, the article on <section> written by Bruce Lawson says that you can use H1's per section, there's even a tool to view how the outlining works, but from the article that Robert posted, this outline isn't used by graphical browsers or assistive technology.

The theme of each section should be identified, typically by including a heading (h1–h6 element) as a child of the section element.

 

Check your work in the HTML 5 outliner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).

There's a really good MDN article I've found here about how the outline algorithm works, some of it I wasn't aware of, the section in red at the top sums up the article Robert posted.

A lot of literature on the web was following the spec, but there are currently rewrites of the spec taking place to avoid author confusion.

The page linked to in the comments of the article Robert posted demonstrates things clearly. Using multiple H1's essentially flattens the document.
https://www.w3.org/wiki/HTML/Usage/Headings/h1only

If you read through some of the related links at the bottom of the above page:

https://github.com/w3c/html/issues/110
Steve Faulkner states:

Only headings scoped to the body element can have a rank of 1 (=h1) so the highest rank a heading can have in a section/article is 2 (=h2).

 

The same issue links to a rewrite of the Article section of the spec, which states:

A general rule is that the article element is appropriate only if the element's contents would be listed explicitly in the document's outline. Each article should be identified by including a heading (h2-h6 element) as a child of the article element.

 

So apparently we're now advised to have only one H1 tag in the root of the document and subsequent H2 - 6 depending on the nesting of content.

It's no wonder there is so much confusion surrounding heading structure and semantics in HTML.

I don't think there is any confusion.

 

I you structure a document so that it makes sense when stripped of everything except core html tags then it seems obvious you should only have 1 H1 (to introduce the document) and then h2 to identify each section within that document.

 

In the 30ish years I've been creating websites all sorts of thing have come and gone and after all the shouting everything always heads back to the simplest structure being the most effective.

 

I can remember everyone getting all excited when they discovered Google could index flash, this was supposed to be the breakthrough to all sites being built in flash (rich media and all that malarkey). Like everything else it was a flash in the pan. Multiple H1s will go the same way.

I don't think there is any confusion.

 

I you structure a document so that it makes sense when stripped of everything except core html tags then it seems obvious you should only have 1 H1 (to introduce the document) and then h2 to identify each section within that document.

 

In the 30ish years I've been creating websites all sorts of thing have come and gone and after all the shouting everything always heads back to the simplest structure being the most effective.

 

I can remember everyone getting all excited when they discovered Google could index flash, this was supposed to be the breakthrough to all sites being built in flash (rich media and all that malarkey). Like everything else it was a flash in the pan. Multiple H1s will go the same way.

 

I think your very statement here shows there is confusion. As well as conflicting articles and resources - that is all the very definition of confusion.

 

So 30 years creating websites... you were creating them before even the first web browser was released which was in 1992. Even IE1 wasn't a thing until 1995.

 

As for multiple H1s going the way of the Dodo - they won't it's a good idea which was why it made it's way into the spec. Just some vendors have failed to implement it correctly.

Edited June 15, 201610 yr by rbrtsmith

sorry many apologies, I can't do sums today. Should have said 20 ish years.

 

But I still don't think there is any confusion. There may be all sorts of articles and a spec that allows this but it's not needed. If you want to use multiple h1 in a document then that's fine. If you just want just 1 then that's fine as well. If you really want to get fancy, try using multiple meta descriptions to go with your multiple h1s, you can get some very interesting results in the serps.

sorry many apologies, I can't do sums today. Should have said 20 ish years.

 

But I still don't think there is any confusion. There may be all sorts of articles and a spec that allows this but it's not needed. If you want to use multiple h1 in a document then that's fine. If you just want just 1 then that's fine as well. If you really want to get fancy, try using multiple meta descriptions to go with your multiple h1s, you can get some very interesting results in the serps.

 

Using multiple H1's is not even close to being the same as using multiple meta descriptions. It's in the HTML5 spec. The reason it's not recommended in the article Robert posted is to do with a lack of implementation and nothing to do with the fact it shouldn't be done.

 

I actually think this is cleaner, less error prone, and has a better component structure. That's just my opinion, though.

<section>
  <h1>News</h1>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>
</section>

<section>
  <h1>Events</h1>

  <article>
    <h2>Event heading</h2>
    <p>Description</p>
  </article>
</section>

I actually think this is cleaner, less error prone, and has a better component structure. That's just my opinion, though.

<section>
  <h1>News</h1>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>
</section>

<section>
  <h1>Events</h1>

  <article>
    <h2>Event heading</h2>
    <p>Description</p>
  </article>
</section>

 

That seems a more sensible approach. As the spec states that a <section> is meant to represent a standalone piece of content, nesting section elements in order to simply stick a headline and slug in one seems to me to not really be what the <section> element is for. Using a <header> for the headline and slug might be a better option.

 

Overall though it seems to me that the W3C do a lot of 'speculative specs', apparently waiting for one of the browser vendors to come up with a good implementation, then they can claim that that is what they intended all along.

 

As far as accessible UA's go then the producers of them need to get their act together, particularly as some of them cost more than a pretty penny, in fact they cost large ugly numbers of pounds. Another possibility is to implement a form of ReSS (Responsive Server Side) as AcceSS (Accessibility Server Side). Basically use a combination of .htaccess and server side scripting to serve up content specifically tailored to the user agent so browsers being used in text only mode for the blind don't even get served the images in the first place just the descriptive alt text or possibly even content that is more relevant to the visually impaired. Same with those using browsers for physical impairment who might be using other devices than a mouse or a finger.

Using multiple H1's is not even close to being the same as using multiple meta descriptions. It's in the HTML5 spec. The reason it's not recommended in the article Robert posted is to do with a lack of implementation and nothing to do with the fact it shouldn't be done.

 

I actually think this is cleaner, less error prone, and has a better component structure. That's just my opinion, though.

<section>
  <h1>News</h1>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>

  <article>
    <h2>Article heading</h2>
    <p>Description</p>
  </article>
</section>

<section>
  <h1>Events</h1>

  <article>
    <h2>Event heading</h2>
    <p>Description</p>
  </article>
</section>

 

I think the problem with this multiple h1 example is what it the overall heading for this structure? This code is all nested sections and articles, where would nav, header and main exist in this demo?

 

Edit: To clarify can you start from body?

Edited June 15, 201610 yr by BrowserBugs

I think the problem with this multiple h1 example is what it the overall heading for this structure? This code is all nested sections and articles, where would nav, header and main exist in this demo?

 

It's not a perfect example but it does illustrate how each section can be self-contained. Your primary heading would whatever H1 appears in the sectioning element first.

 

It's all theoretical at this stage anyway, but you can see what the idea is here http://html5doctor.com/outlines/ and how the outlining algorithm is supposed to interpret the new structure. It's a shame it doesn't work like that.

I believe the <hgroup> element was supposed to sort a lot of this out but it did a sort of W3C hokey-cokey and then got dropped out.

 

The HTML <hgroup> Element (HTML Headings Group Element) represents the heading of a section. It defines a single title that participates in the outline of the document as the heading of the implicit or explicit section that it belongs to.

 

Nothing seems to have replaced it.

 

I think the most pertinent point here is the one made in the link posted by Jack.

 

The concepts behind HTML5 document outlines are actually older than you might think! Tim Berners-Lee posted to the www-talk mailing list back in 1991 (props to Dr Oli for digging that up), suggesting something quite close to what is demonstrated in this article.

 

 

Which leads to: http://lists.w3.org/Archives/Public/www-talk/1991SepOct/0003.html

 

In writing a new generic parser, I wondered whether your text object will store the nested structure of a document. At the moment, the document is a linear sequence of styles: you can't have lists within lists, etc. Ideally, it would be able to handle this - although its more difficult for a human writer to handle when formatting the document. I would in fact prefer, instead of <H1>, <H2> etc for headings [those come from the AAP DTD] to have a nestable <SECTION>..</SECTION> element, and a generic <H>..</H> which at any level within the sections would produce the required level of heading.

 

For a browser, it is quite satisfactory to flatten the structure back into a sequence of styles, but for an editor it isn't.

 

 

So 25 years on and still little implementation.

What? I really don't think this will work SEO-wise but would love to stand corrected on that, oh the possibilities!

This was something I experimented with some years back. I had different meta descriptions for each section on the page. Google delivered a different snippet depending on the search keywords. Don't know if it will still work though.

This was something I experimented with some years back. I had different meta descriptions for each section on the page. Google delivered a different snippet depending on the search keywords. Don't know if it will still work though.

 

I did some experimenting with micro data along similar lines although I used itemprop="description" for the isolated items, interesting what got taken in the serps was either the itemprop description for the element from the parent or the actual meta description for the page it linked to, I know you can pass quite a bit of data via schema from page to page.

 

I think the problem with this multiple h1 example is what it the overall heading for this structure?

 

That shows an example where the H1's have equal value because they're headings for distinct topics in the same document.

 

If we simplify it:

<h1>News</h1>
<h1>Events</h1>

If you stick to one H1 you could write it as:

<h1>News and events</h1>
<h2>News</h2>
<h2>Events</h2>

...but that sort of duplicates the headings and is pretty pointless, not to mention frustrating for peeps using screen readers because it's all read out twice.

I think to try to explain what i'm thinking, it's hard with words sometimes.

<main>
<header>
<h1>Company Staff</h1>
<p>Some sort of introduction, results count, last mod and stuff like that.</p>
</header>

<section>
<h2>Sales</h2>
<article>
<h3>James Smith</h3>
<p>Address or something. Link to profile</p>
</article>
<article>
<h3>Miss Smith</h3>
<p>Address or something. Link to profile</p>
</article>
</section>

<section>
<h2>Warehouse</h2>
<article>
<h3>Paul Sanders</h3>
<p>Address or something. Link to profile</p>
</article>
<article>
<h3>Mr Bigglesworth</h3>
<p>Address or something. Link to profile</p>
</article>
</section>

<footer>
<h2>You might also like cheese.</h2>
</footer>
</main>

With this h1-h3 structure in a kind of parent & child or breadcrumbs sort of way implies that h3 'Mr Bigglesworth' is a child of h2 'warehouse department' of h1 company employees? You might also like cheese

Yes that heading structure is logical because Sales and Warehouse are natural parents of Company Staff

Is it generally safe to asume that the way browsers renders the headings is equivalent to the semantic hierarchy?

<main>
  <h1>Main heading not nested</h1>
  <section>
    <h1>Nested h1 equivalent to unnested h2</h1>
    <article>
      <h1>Nested/Nested h1 equivalent to unnested h3</h1>
    </article>
  </section>
</main>

In this example the first h1 is rendered as "top-level" heading. The following h1s are rendered as h2 and h3 depending on how deeply they are nested in section and article elements

https://jsfiddle.net/Nillervision/rr6r29ke/

Is it generally safe to asume that the way browsers renders the headings is equivalent to the semantic hierarchy?

<main>
  <h1>Main heading not nested</h1>
  <section>
    <h1>Nested h1 equivalent to unnested h2</h1>
    <article>
      <h1>Nested/Nested h1 equivalent to unnested h3</h1>
    </article>
  </section>
</main>

In this example the first h1 is rendered as "top-level" heading. The following h1s are rendered as h2 and h3 depending on how deeply they are nested in section and article elements

https://jsfiddle.net/Nillervision/rr6r29ke/

 

 

You would be right in thinking so. However I suggest you read the article I posted earlier in this thread... It seems the spec has not yet been properly implemented across the board.

Edited June 20, 201610 yr by rbrtsmith

Did not find time to read all the replies, from what i read, "as many H1s as i want", thats what im taking away from this and its hopefully right.

Did not find time to read all the replies, from what i read, "as many H1s as i want", thats what im taking away from this and its hopefully right.

 

It should be but it's not.

Maybe nesting H1s in document outline can be a mistake when it comes to sections but what about the article element?

According to the specs the article element is an independent part of the document. So in other words an article is a publication with its own "local" embeded formatiting that could be published in all sorts of contexts (you could have 1 or 50 individual articles on a page which might or might not have existing "outer" headings). The nesting structure of headings in articles is the same as with sections and it is the only thing that makes sense. If each article should be considered a truly independent unit it should contain at least one h1 element no matter how many articles you publish on a page.

Edited June 20, 201610 yr by Nillervision

Niller have you read the article I linked to? We know what the spec says but that doesn't mean it's always implemented across the board.

Niller have you read the article I linked to? We know what the spec says but that doesn't mean it's always implemented across the board.

I did read the article I just don't understand it. How can the document outline not be "real"?

Im especially confused when it comes to the "independent" article-element. It makes no sense

Edited June 21, 201610 yr by Nillervision

It's more to do with vendors not implementing the spec more than anything else.

 

I'll point out the article is highly unlikely to be bogus / unreliable as it was shown to me by Harry Roberts when we were debating the subject of how many H1s can appear on the page - I was saying you can have as many as you like until he pointed me to that article.

I did read the article I just don't understand it. How can the document outline not be "real"?

Im especially confused when it comes to the "independent" article-element. It makes no sense

 

If all the articles (complete body etc) are in one page then the h1 per article would make sense, however if the articles are holders which link to a full article then I would think that h2 or h3 would be more logical, as to the importance of the title in the context of the listing page. Then once a link is followed through then the article title would now become the h1 (primary for page) as it would house the full article ... probably I'm clear as mud as usual

It's more to do with vendors not implementing the spec more than anything else.

 

I'll point out the article is highly unlikely to be bogus / unreliable as it was shown to me by Harry Roberts when we were debating the subject of how many H1s can appear on the page - I was saying you can have as many as you like until he pointed me to that article.

I don't believe the article is unreliable. I glad that you linked to it. When I said that I didn't understand I ment that I literally have difficulties understanding how to properly format a document.

 

 

If all the articles (complete body etc) are in one page then the h1 per article would make sense, however if the articles are holders which link to a full article then I would think that h2 or h3 would be more logical, as to the importance of the title in the context of the listing page. Then once a link is followed through then the article title would now become the h1 (primary for page) as it would house the full article ... probably I'm clear as mud as usual

Well if the articles are "excerpts" I would think they should be nested in another type of element as they are part of a listing page rather than individual block of content

@@Nillervision Yes I think it only adds to the confusion. I'd probably just use a single H1 again and then build up a hierarchy starting from H2s within next sectioning contexts. I think that is a fair compromise that will largely work as intended.