A page typically has one top-level heading that names the page topic

What it is

Open a page and the top-level heading should answer “what is this page about.” A page typically carries one top-level heading, naming the page topic; the site name, the section name, and card titles should not each take a top-level slot. Two equal top-level headings put two peer roots in the outline, and no one can tell which is the page.

The document title in the browser tab and the in-page top-level heading are different objects: one labels the window and history, the other is the root of the in-page outline. They should point at the same topic; they cannot substitute for each other.

Why it happens

An outline branches from the top level. One root makes every level-two a section of that topic. Two roots split the page into two peer documents: navigation first hears two items that both sound like “this page,” then shuttles among their children. The usual source is component reuse: every card, dialog and embedded widget starts at the top level because, in isolation preview, the component looks like a whole page. Once nested in a real page, the preview root becomes a second root on the page.

The product name in the site mark is also often tagged as top-level, so every page’s root is the product name and the real page topic is demoted. The strategy of using the top-level heading to tell “which page am I on” then fails — every page’s top-level heading is the same.

Studying it

In a site sample, count top-level headings per page and capture their text, then compare with the document title and the current primary-nav item. Ask people, hearing only each page’s top-level heading, to say what the page is, then open the page and score the judgement.

Independent variables: number of top-level headings, whether the top-level heading reuses the site name, whether components ship their own top-level heading. Dependent variables: roots per page, accuracy at naming the page topic from the top-level heading alone, mismatch rate with the document title.

Automation can count top-level headings; it cannot tell whether that single heading actually names the topic (some pages have one top-level heading that says “Welcome”). The accuracy task beats the count. Sample home, dashboard, and multi-card overviews — those pages grow extra roots most readily.

Where it stops holding

A single-page app that swaps “pages” for views still needs one top-level heading per view; the previous view’s heading must be removed on swap, or roots accumulate in the DOM. HTML permits several top-level headings on a page — a syntactic permission, not a good outline. Email, PDF and embedded third-party forms are documents of their own; their top-level heading is counted inside that document, not against the host page. Some portals stack contributed articles as independent pieces; multiple roots are then the content model, and the mitigation is an article boundary or landmark around each piece, not pretending the page has one topic.

Applying it

• Leave one top-level heading per page (or per view in a single-page app), written as the page topic, not the site name or a section slogan.
• Start cards, dialogs and embedded widgets at level two or below. Do not let a component begin at the top level.
• Point the in-page top-level heading and the document title at the same topic. Avoid a tab that reads “Settings / Notifications” while the in-page top-level heading reads the product name.
• How to check: list the top-level heading text on a sample of pages. Two or more on a page, or the same site name on every page, is a root failure.

Related

• Same group: J2.14.1 Heading levels must nest sequentially and must not skip levels for visual effect · J2.14.3 Landmark regions (navigation, main, footer) supply structure beyond headings · J2.14.4 Marking non-heading emphasis as headings dilutes their navigation value
• Nearby: J2.09 Semantic Structure · J3.03 Skip to Main Content · J5.01 Screen Readers
• Search terms: page h1 · document heading · single top-level heading