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
- Only one
h1per page - it should define the one overall topic of the current page
- All subheadings are
h2; all sub-subheadings are
- No skipping levels (no, you can not go from
- On the homepage the site name is the
- On a section/index page the site name becomes a
strong, and the section name is
- On a content page the article title is
h1and the site and section name are both
Page titles across the site:
- The homepage simply gets the site name
- Moving into the site, increasingly specific information is added to the start of the title
- The names are consistently separated with a neutral character like a pipe
Putting it all together:
- "Name of Site"
- "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:
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:
- 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.
- Consistency is absolutely the key here. Always
- 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
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!
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.
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.
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...
h2s are too big, I just want to use
- 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
- "It doesn't matter if I skip from
- 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
h2when the sections are bigger, the rest of the time I just use
- 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
h1all 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
h2as "Subheading level 1", then
h3as "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.
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
Labels: markup semantics headings titles