how to structure html headings and titles

A perennial question on discussion lists, and in fact at work, is how to handle heading hierarchies in pages and title structure across sites.

While there's a fair bit of opinion to be had, when people focus on creating a valid document structure the same rules consistently appear. These rules not only match up to the high-minded ideals of specification, but also serve the prosaic requirements of the daily development grind.

the rules, condensed

Page headings:

  1. Only one h1 per page - it should define the one overall topic of the current page
  2. All subheadings are h2; all sub-subheadings are h3; etc
  3. No skipping levels (no, you can not go from h1 straight to h3)

Site headings:

  1. On the homepage the site name is the h1
  2. On a section/index page the site name becomes a strong, and the section name is h1
  3. On a content page the article title is h1 and the site and section name are both strong

Page titles across the site:

  1. The homepage simply gets the site name
  2. Moving into the site, increasingly specific information is added to the start of the title
  3. The names are consistently separated with a neutral character like a pipe

Putting it all together:

Homepage:
"Name of Site"
Section:
"Section Name | Name of Site"
Content page:
"Title of content which does tend to be longer | Section Name | Name of Site"

the rules, explained

what are headings and titles for, really?

Broadly speaking, headings and title structure help make your site accessible and your documents readable. They have other functions too, but these are their prime purpose.

The title should be an accurate statement of context; the h1 should clearly define what the page is about; and the heading levels should assist all users as they determine the structure of your content.

If you skip levels, if you repeat titles, if you pepper your page with h1s, if you randomly skip up and down heading levels... then you are making life hard for people who were just trying to read what you've written.

Even you don't care about people that much, if you confuse the humans you're not helping search engine bots either.

headings in a page

Page headings introduce and define the content that follows immediately after them. They set out the discrete sections of content, so the user can quickly understand what they're reading and how the sections of content relate to each other.

Subheadings group logical subsets of the content, sub-sub headings divide the content further, and so on. This sets up the document's fundamental structure. The headings relate to each other in a specific order, which needs to be maintained to avoid miscommunication.

It can help to consider how a table of contents for the page would look, since that will also reflect the page outline. For example:

  • h1: Dogs
    • h2: Working dogs
      • h3: Sheep dogs
      • h3: Sniffer dogs
    • h2: Pet dogs

When you see the structure laid out this way, it is clear that Working dogs and Pet dogs are logically set at an even level. However you wouldn't group Working dogs, Sheep dogs and Pet dogs, since they are not all on the same level - sheep dogs fit within the working dogs category.

Being consistent with heading levels also pays off for maintenance. If you use headings randomly, I'm willing to bet sooner or later you'll end up trying to restyle h3 elements on one page to look like h2 elements on other pages - or something along those lines.

headings across a site

Ideally there should only be only one page per site with a particular h1, or at the least you should avoid having the same h1 on every single page (which really doesn't make sense). That rules out using an h1 for the logo on every page.

Of course on the homepage the h1 can enclose the site's name and logo; your homepage's h1 should not be "home"!

Together with a complementary title scheme you should end up with a fairly natural site hierarchy and avoid large numbers of pages all using the same h1 contents (which is misleading and confusing). The occasional double-up can be salvaged by well-written titles.

duplicate page headings

If you have two pages with the same name in two different sections, the title scheme comes to the rescue:

  • "About us | Web Development | YourCorp"
  • "About us | Marketing | YourCorp"

It's still a bit confusing, so it would be better to have something like:

  • "About the web team | Web Development | YourCorp"
  • "About the marketing team | Marketing | YourCorp"

...but since you may not control both pages, it's good to have a title scheme that can survive common issues like this.

titles across a site

Titles really need to be unique, to provide context and disambiguation. A reasonably robust system goes as follows:

  1. Start with the site name on the homepage.
    • If you have to add a tag line, append it after a colon ("Sitename: clever tag line for the site") but don't put it on every page across the site.
  2. Add more-specific information to the start of the title as you move deeper into the site.
    • Consistency is absolutely the key here. Always
  3. Use a consistent, neutral separator character.
    • I use pipes (vertical bars). Although they're a bit verbose in screen readers, they're semantically pretty neutral and they are used so commonly they've taken on a sort of de facto meaning as a generic separator.

Why add the more-specific information to the start of the title?

  • Screen readers start with the most relevant information, rather than starting by telling the user which site they're on for the fifteenth FRICKING time.
  • Depending on screen resolution and browser, the end of the title may well be cut off in the user's interface. So you want the most contextually-important information to remain available.
  • Similarly, titles tend to get truncated in search results. Get the unique stuff in first.
  • SEO people - the good kind, that I trust ethically - tell me it's the way to go for good ranking. This point is intentionally last.

If you have more than one section level you have to make a discretionary call about whether to include them all or not. Too many levels in the title is just going to be overload; and you're probably best off with a proper in-page breadcrumb trail at that point.

If you just have a couple of logical steps you might get away with it. But if in doubt, just include the the immediate section name and then go straight to the site name. Basically: don't bung your breadcrumbs into the title or vice versa. They're different things, craft them as such.

the separator characters problem

pointy characters

Although it's common to see separator characters chosen because they "look a bit pointy", it's a flawed practice since most of them turn out to have a very specific meaning. Sometimes it's mathematical (<, >, etc), sometimes grammatical (», ›, etc ).

Using characters with a specific and irrelevant meaning ensures at least some people will see something that just doesn't make sense. For example, the » character is a quote mark in some languages. That means your title would read "Page Name Closing Quote Site Name", or perhaps "Page Name right double angle bracket Site Name".

To put that another way: your title is essentially gibberish. You might as well just put in "Page name MONKEYS! Site Name", at least it'd be original.

Then of course if someone gets the implementation wrong, you're going to get broken characters in your title - or for extra fun, raw HTML of encoded characters. Best just to steer clear!

greater than...?

While the greater-than and less-than signs can arguably be used to define higher and lower levels of content, I think it's ultimately too much cognitive load.

  • Does greater-than imply denser content, or a higher level in the site structure (ie. lower density content)?
  • Does it mean one's more important than the other?
  • Are they breadcrumbs?

Ultimately it's just too much thinking, it's just getting in the way.

conversational titles

Alternative ways of handling titles are to use conversational language, "Article Name at Site Name" and "Article Name in the Section Name at Site Name". Systems like this can work pretty nicely on a small site, but do tend to collapse on bigger sites. It also sets also a more-friendly, less-formal tone that is unlikely to be popular with serious corporate clients.

relevant punctuation

You could use hyphens or colons to indicate depth... "Sitename: Article Name". If your site only has two levels this might work, but for bigger sites it's going to break. Sooner or later you'll have a page name with a hyphen or a colon, and the whole system just doesn't work.

just use pipes, already!

Regardless of what you choose, it's worth considering how many people will have to maintain and comply with the system. Especially consider how many people who don't care will have to do it. Best to keep it simple, to have a better shot at consistency against the odds.

So when all's said and done, the simplest "one rule" is to use pipes.

common questions and statements...

"But h2s are too big, I just want to use h4s."
Bad. No. If you're convinced your h2s are too big, write some CSS rather than screwing up your document structure. Besides, if you need to accommodate all six levels, you quickly discover why the higher level headings tend to be big...
"I used nothing but h5s all the way through... that's ok isn't it?"
That is at least better than jumping around, but you still should have used an h1 and some h2s.
"It doesn't matter if I skip from h1 to h3!"
Yes it does. You're implying that your document is incomplete, that there was a sectional marker left out. This could be very confusing to someone trying to follow a complex document. Think of headings like replies in a set of threaded comments: if you skip a level you make it look like something's missing. Valid structure is important for meaning.
"I'm just using h2 when the sections are bigger, the rest of the time I just use h3s."
Swap the other way around. Add in the h3s when you need the extra subheadings.
"I think it's fine to use multiple h1s in a single page..."
Some people do feel that's a valid way to go; but I just don't think so. Pages need at least one top-level heading, which logically has to be h1. That means any subsequent heading has to be a subheading, ie. an h2. If you have a page with significantly different sets of content, you don't "fix" it by using h1 all over the place - you're better off writing an h1 which explains why the disparate content is on one page in the first place. If there's no reason at all, your content structure probably needs a rethink.
"Calling them sub-sub-sub-- headings is just silly, users don't get that."
Well fair enough, so don't label them that way. In your interface, label h2 as "Subheading level 1", then h3 as "Subheading level 2" or something along those lines. Do some workshops with your users and see what actually works for them. But remember that what you do under the bonnet doesn't matter to users. They just want to get their work done. If they only have five heading levels at their disposal, plus a document title, they probably won't notice what's going on. But you'll have handled the structure for them.

last thoughts

Heading levels, title separators and so on should be chosen according to their function and not for aesthetics. Headings aren't defined by their font size, they're elements with specific (and useful!) meanings.

Using a consistent, semantically-valid scheme for headings and titles makes your site more readable and easier to navigate. It's also easier to maintain and better for search engines. It's well worth the effort to get your headings and titles in order!

Update 2011.11.08: A quick note on <h1> usage

The Webaim Screen Reader Survey #3 produced a surprising result regarding pages with two h1 elements within a single page. While 37.1% preferred "One first level heading that contains the document title", 50.3% preferred one h1 for the page heading in addition to one h1 as the site heading.

It is important to note that the majority did not like sites with a single h1 as the site heading and no other first level headings. Also, it is not clear if the preference for two h1 elements is a strong preference; nor whether the one h1 per page model actually creates difficulties. Hopefully future surveys will dig deeper into this area to see if a better understanding can be gained.

This basically means you should definitely still ensure the page title is an h1, but it's probably acceptable to leave your site header as an h1.

Labels:

Comments

  1. OpenID lachlanhardy, March 12, 2010 7:50 am: 

    +1

    Internal cross-post imminent?

  2. Anonymous Ben Harrison, March 12, 2010 10:58 am: 

    Good roundup, though I'm not entirely convinced on your title separator argument. To me it just reads as:

    Page name BITWISE OR Site Name

    ;)

    What are your thoughts where headings aren't directly hierarchical, eg. module headings in the side panel of an article page.

    Also, rich-text fields - education or restriction?

    Cheers,
    Ben

  3. Blogger 200ok, March 12, 2010 1:45 pm: 

    @lachlan: now internally crossposterised for extra shine :)

    @ben: We're in a minority - people who actually use pipe symbols for something ;)

    For a side panel in an article, I think probably start with the highest subheading level in that article. So, the article heading is ideally h1; so give it an h2. The logic being that heading wise, the sidebar is a section of the article. It's perhaps not perfect but it should be reasonably understandable.

    Rich text fields... ideally both, educate users and restrict any obviously-broken options. But I'd say education works for small companies or small user groups; restriction works better when things scale up and you can't catch everyone.

    I'd rather see "what you see is what you mean" as an editing paradigm, since "what you see is what you get" has had long enough to prove it's busted :)

  4. OpenID colinmo, March 15, 2010 9:58 am: 

    I was going to argue your title section until I realized you meant [title] rather than the English use of title. I will comment that while that works from an SOE/ XML structure, do you find that confuses people when they find the page titles don't match a mental image of Left to Right importance? Perhaps that's some English bias coming in there.

    As a comment for the sidebar, would it depend on your Article model of importance? If it is part of the Article, or relevant to it directly, I can see headers for page hierarchy. A side bar of navigation, for example, is not necessarily article relevant but is page utilization relevant. Conflicting.

  5. Blogger 200ok, March 15, 2010 1:45 pm: 

    @colinmo: yeah, title meaning <title>.

    I think the potential left-to-right confusion is outweighed by the confusion of having the most specific/important information cut off in the browser's title; and/or annoyance of getting repetitive information first. It's a good point for i18n though, in a right-to-left language the logic would be the same but the effect would be reversed from my English examples.

    I did kind of make a jump with the side panel question since I suspect I know the code Ben's thinking of ;) I was thinking of a side panel inserted within the body of an article, providing related links, polls and comments about the story (potentially you could find an example on a news website ;)).

    For a nav sidebar, I think on balance I'd probably still go for an h2 (or proximity-correct heading level, eg. if there's already a "sidebar" h2 heading) but that's primarily to avoid conflicting with h1.

    I think in many ways the problems of sidebars illustrate why both XHTML 2 and HTML 5 have moved to a system of containers+localised headings. I think XHTML 2 did it better, but that's a moot point these days.

  6. Anonymous Jason Grant, March 16, 2010 10:47 am: 

    I wrote an article which touched on the topic of using h1 to h6 headings in HTML documents which compliments this article also.

    http://www.flexewebs.com/semantix/semantic-uses-of-h1-h2-h6-html-tags/

  7. Anonymous Niina, March 16, 2010 11:11 am: 

    Great post with good tips.

    I personally prefer title tags shown left-to-right because I often have multiple instances of the same site open in tabs and it becomes time consuming to locate the tab I want (I won't go in to Chrome's hover-on-tab-titles!).

    When I add URLs to delicious I regularly reverse titles that show the site name first because when I scan through my links the specific page titles are more important to me than the site they belong to.

    And the left-to-right for screen readers is a very important point.

    However when it comes to an audience using a web site, is a user likely to have multiple instances of the same site open at once? If not, would the site name first be better at helping them if they’re using a tabbed browser? If they’re bookmarking the site in their browser would the site name first be better for their recall purposes as they browse their bookmarks? An obvious favicon might help with the product recognition in both of those instances.

    I would suggest that the purpose of a web site may play a big factor in the title order decision, and perhaps some behind-the-scenes work could be done to generate the title order based on the technology being used to access the page. Complicating matters? Sure :)

  8. OpenID halans, March 16, 2010 12:58 pm: 

    Practice what you preach?
    Meh, just stirring the pot ;p
    +1

  9. Blogger 200ok, March 16, 2010 2:07 pm: 

    @niina: Yeah I agree it depends on the site, although I think having a good favicon is a must in these days of tabbed browsing. Looking at my browser tabs right now all I can see is favicons! Actually I've also just realised nearly every tab is one of several open for each site. Hovering gives me a preview that truncates the title, so left-to-right works pretty well.

    If people are bookmarking I think they're either bookmarking a specific page (ie. specific content is the primary concern) or the whole site (which should mean the homepage, which is just the site name). So I think the scheme should hold up pretty well.

    @halans: heheh that's a fair point, this blog does currently break the h1-on-article-heading rule due to earlier templating limitations and legacy content needing a manual overhaul. On the flip side, the News network now follows these rules :)

  10. Anonymous Niels Matthijs, March 16, 2010 7:20 pm: 

    One little addition to the "only 1 h1 rule".

    I believe that when a page serves multiple languages (landing page, 404 page) that multiple h1s can be used on the same page, especially when the content is simply mimicked in different languages.

    Just to say that every rule has its exceptions :)

  11. Anonymous Jonas Jacek, March 16, 2010 8:07 pm: 

    In HTML5 every part of the website can have it's own, complete set of headings. For example: can have h1-h6, can have h1-h6, etc...

    The only reason not to use headings in all the different parts, is for SEO. I'm not sure Search Engine bots already understand HTML5. However, you can use this technique without breaking the document structure in HTML5.

  12. Blogger 200ok, March 16, 2010 8:08 pm: 

    @niels: I can see what you mean there, I guess since the content is duplicated that makes sense. It's not exactly an exception, so much as repeating the same logic/rule for each duplicate block of information. Interesting case!

  13. Blogger 200ok, March 16, 2010 8:57 pm: 

    @jonas: It's the unanswered questions about accessibility and SEO that make HTML5's headings a "wait and see" proposition just for now. I expect the answers will be clear soon enough, and ultimately I think HTML5 will just extend the rules to accommodate more levels (it'll also extend the potential to make a mess ;)).

  14. Anonymous Vicky, March 17, 2010 7:02 pm: 

    Very good article!

  15. Anonymous Dey Alexander, March 18, 2010 10:34 am: 

    Ben, I agree with your thoughts on heading structures, but the page title has a critical role, particularly in search (keyword weighting and reading search results) and I have some comments that differ from your thoughts on that.

    I agree that the specific or unique terms need to be first. Users focus most attention down the left edge of the content, so the specific page content needs to be highly visible. The further down the results page they go (which often isn't that far), the less they look across the line.

    However, it's often unnecessary to include the section name (and sometimes I've seen a long hierarchy of section and sub-section names, like breadcrumbs). Why?

    a) It is merely a repetition (as in your 'About the marketing team | Marketing' example).
    b) It can push the organisation name out of view. This might be important secondary information for a user to assess in choosing which search result to click through to.
    c) As many users will be reading titles from public search engine results pages, there's no need to identify the section of the site. That's the role of breadcrumbs and other location markers once they're in the site, viewing a particular page.

    I think the reason you suggest adding the section name is to compensate for when the H1 lacks context (e.g. 'About us', which could be a page for the marketing or web dev teams). The solution instead is to write a title like 'About marketing, CompanyName'.

    The best approach to page titles is to write them for the role they play. Trying to automatically generate them (as many content management systems do) is too risky.

    We should be writing page titles primarily for:

    * Scan reading in search results
    * Keyword indexing in search engines
    * Managing pages open in multiple browser tabs
    * Finding things added to browser bookmarks or favorites
    * Looking for something in the browser history

    Oh, and one last thought. On punctuation, I'd be using what reads best or makes the most sense to a user given the context in which people read page titles (ie those listed above).

  16. Blogger 200ok, March 21, 2010 11:25 pm: 

    @dey: Good points; a simple "Page Title | Site name" pattern can work pretty well for some sites. The main limitation is the dedication and copywriting skills of the people maintaining the site (assuming there aren't any technical limitations). Well-crafted headings and titles would remove the need for some recommendations, I suppose the cynic in me was just jumping straight to "when they didn't do that" ;)

  17. Anonymous Anonymous, March 23, 2010 7:47 am: 

    Reserving H1 for the article's main title makes sense but it seems to conflict with the requirement of not skipping levels, since the article is rarely the first item in the document. is there a way to avoid that? For reference:
    http://www.maxdesign.com.au/2006/01/17/about-structural-labels/
    http://www.usability.com.au/resources/source-order.cfm

  18. Blogger 200ok, March 28, 2010 9:59 pm: 

    @anon: That's why I've recommended switching the site and section headings to strong tags when you're on an article page. That way the article's heading is the first heading.

    The other solution I've seen recommended is to use h2s and just accept the step back up to h1 for the article/page title. Personally I'm less comfortable with that solution, I think it has the potential to be more confusing than helpful.

  19. OpenID jufemaiz, May 11, 2010 11:00 am: 

    My best recommendation to those learning how to structure content is to open up a document (word/open office/whatever) and use default styles (lists, headings 1-6) build the page up in the way that is logical with all the components.

    That is then the *start* point.

Post a Comment

Got something to say? Leave a comment! OpenID or Name/URL is preferred. I reserve the right to delete comments that are spam, offensive or simply unconstructive (especially if they're anonymous).

Direct link to comment form

about

Web development and standards, as seen by Ben Buchanan.

subscribe

elsewhere

[More bookmarks]