Heading System: H1, H2, and H3 Rules

A heading system is the ordered set of one page title and its section labels. It turns a long page into a readable route for people and a machine-readable outline for search engines, assistive technology, and AI answer systems.

The page title above is this page’s single H1. Every major specification below is an H2, and any subdivision inside a major section is an H3. That live outline is the rendered element: its levels express relationships rather than font sizes.

Why this element matters

Readers rarely consume a long page in one uninterrupted pass. They scan for a recognizable question, compare section labels with their current need, and decide where to slow down. Descriptive headings reduce that effort because each one makes a small promise about what follows. “How stable heading IDs preserve citations” is useful at a glance; “A few more thoughts” is not.

The same hierarchy supports machine extractability, meaning an automated system can identify a section, understand how it relates to the page topic, and retrieve it without confusing it with a neighboring section. H1 establishes the page subject. H2 divides that subject into primary concerns. H3 narrows one H2 into a method, case, criterion, or exception. A skipped level hides that relationship and forces a parser to infer whether a subsection is a sibling, a child, or an unrelated block.

Headings also create addressable sections. A fragment identifier is the part of a URL after #, such as #qa-checklist. Search results, internal links, browser bookmarks, and AI answers can point to that exact destination. A casually renamed auto-generated ID can therefore break a URL even when the page itself still exists. The heading is not decoration: its text defines the section and its ID becomes a durable public address.

Follow the element writing rules when a section’s purpose matches a typed element. An H2 named “Warning” does not replace a warning box, and an H2 named “Comparison” does not replace a comparison table. Headings provide document hierarchy; typed elements provide purpose-specific structure. Both may be needed.

When to use it

Use the heading system on every substantive indexable page. Even a short page needs one H1. Add H2 sections when the reader must move between distinct questions, stages, criteria, or evidence groups. Add H3 subsections only when an H2 contains at least two genuinely distinct parts that benefit from separate navigation.

The near misses are visual labels that look like headings but do not belong in the article outline:

• A card title names one repeated card; it is not automatically a document section.
• A callout label such as “Tip” or “Important” identifies the box type; it does not become an H2 simply because it is bold.
• A chart title identifies a figure. It belongs in the figure’s caption or accessible name unless the chart begins a complete section.
• A navigation menu label, breadcrumb, tab, accordion control, footer heading, and modal title may need component semantics, but they do not enter the main article hierarchy.
• A large promotional slogan is display copy. Font size cannot promote it into the document’s H1.

Do not add a heading merely to introduce one sentence, split a continuous explanation, or create visual breathing room. Use paragraph spacing or editing for those jobs. A useful heading marks a section substantial enough to answer a distinct reader need.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place headings

Position expresses parentage. Place the H1 at the start of the main content, after breadcrumbs or other site navigation and before the introduction. Place each H2 before a primary section. Place an H3 only after its parent H2 and the parent’s orienting content, never before the first H2 and never as a peer chosen for visual appearance.

Two headings may not be adjacent in authored article content. Every heading must own useful content before the next heading of the same or deeper level. This rule prevents empty section labels, gives readers context before a subsection list, and creates extractable passages rather than a bare outline.

Anatomy

The labelled anatomy has five parts:

1. H1: the unique page subject and top of the content outline.
2. H2: a primary question, stage, or dimension within that subject.
3. H3: a child topic that cannot be understood correctly without its parent H2.
4. Owned content: the answer, evidence, instructions, or explanation between one heading and the next heading at the same or higher level.
5. Stable ID: the fragment destination attached to the heading and preserved after publication.

The relationship remains valid if typography changes. A theme may render H2 with a smaller font on mobile, but it must remain H2 in the HTML. Conversely, making a paragraph large and bold does not give it heading semantics or a fragment destination.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Design variants correspond to semantic levels and real wrapping states, not arbitrary color options.

H1 page title: show the unique subject at the start of main content. A supporting description may follow, but no eyebrow, logo, or hero slogan becomes another H1.

H2 primary section: make the section understandable from a table of contents and follow it with content that establishes scope.

H3 subsection: use the smaller level because the topic is subordinate, not because the designer wants smaller text.

Wrapped heading: permit a natural two-line wrap on narrow screens. Do not shorten a clear heading into an ambiguous label merely to keep it on one line.

Anchored states: show hover and keyboard focus without making the anchor the only way to understand the destination. Direct navigation must offset any sticky header so the heading is not hidden.

Parameters

The heading system is a document contract rather than a decorative component. Its parameters define the outline, the text readers see, the content each node owns, and the URL by which that node can be reached.

The character and word limits are editorial bands, not reasons to omit necessary specificity. A 94-character heading that distinguishes two similar procedures is better than a short but misleading one. The structural limits are strict: one H1, no skipped levels, no duplicate IDs, and no empty sections.

Syntax and code examples

The canonical portable form wraps the native outline in a heading-system directive. The first heading maps to the document title; later headings remain ordered content nodes. Explicit IDs are added once the headings become public.

Portable Markdown directive

:::heading-system
# Rotate an API key without downtime

Replace the credential in every dependent service before revoking the old key.

## Prepare the replacement

Record every service that currently reads the credential.

### Identify hidden consumers

Check scheduled jobs, deployment secrets, and local integrations.

## Verify and revoke

Test the replacement, then revoke the exposed key.
:::

On publication, pin stable IDs rather than allowing future text edits to regenerate them:

## Prepare the replacement {#prepare-replacement}
### Identify hidden consumers {#identify-hidden-consumers}

Hugo shortcode

{{< heading-system h1="Rotate an API key without downtime" >}}
## Prepare the replacement {#prepare-replacement}

Record every service that currently reads the credential.

### Identify hidden consumers {#identify-hidden-consumers}

Check scheduled jobs, deployment secrets, and local integrations.
{{< /heading-system >}}

This is the Hugo adapter contract, not a claim that this repository registers a heading-system shortcode. A Hugo implementation may continue to render the H1 from frontmatter and the body headings through Markdown, as this page does, provided it validates the same hierarchy and preserves explicit IDs.

WordPress block

<!-- wp:heading {"level":2,"anchor":"prepare-replacement"} -->
<h2 id="prepare-replacement">Prepare the replacement</h2>
<!-- /wp:heading -->

<p>Record every service that currently reads the credential.</p>

<!-- wp:heading {"level":3,"anchor":"identify-hidden-consumers"} -->
<h3 id="identify-hidden-consumers">Identify hidden consumers</h3>
<!-- /wp:heading -->

WordPress should store the H1 in the page-title field or approved hero block, not as a second heading block in the article body. Set each published heading’s HTML anchor explicitly so a later wording edit does not silently change its URL.

Examples

Good: the outline predicts complete answers

# How to choose an invoice approval workflow

## Define the approval risk
Explain which invoice values, vendors, and exceptions need review.

### Set value thresholds
Assign a named approver to each threshold and document what happens at the boundary.

### Route policy exceptions
Send missing purchase orders and changed bank details to a separate review path.

## Test the workflow
Run ordinary and exceptional invoices through the complete route before launch.

This works because the H1 states one task, each H2 names a primary stage, each H3 belongs to its parent, and every label is followed by content that fulfills its promise. A reader can scan the outline and predict where thresholds, exceptions, and testing are covered.

Bad: styling substitutes for hierarchy

# Invoice approval

### Things to think about
## More information
### Exceptions
### Other

This fails for four independent reasons. It skips from H1 to H3, uses labels that do not predict an answer, places headings beside one another without owned content, and leaves “Exceptions” with no explanation before the next heading. The resulting outline suggests coverage that the page does not provide. It also creates weak auto-generated IDs such as #other, which are ambiguous when cited outside the page.

Schema markup and accessibility

Headings do not need a standalone Schema.org type. The H1 commonly supplies or mirrors the headline of an Article, TechArticle, or other appropriate page entity, but visible wording and JSON-LD must describe the same subject. H2 and H3 sections remain HTML structure; do not manufacture a schema entity for every heading. A heading titled “Frequently asked questions” also does not create FAQPage markup by itself—the visible question-and-answer data must satisfy the FAQ element contract.

Accessibility depends on semantic HTML and logical order. Screen-reader users can navigate by heading, inspect a heading list, or jump directly between sections. That workflow breaks when the page skips levels for styling, uses bold paragraphs as fake headings, or includes utility and article headings in one incoherent hierarchy.

Use actual <h1>, <h2>, and <h3> elements. Keep heading text visible; an aria-label must not replace clear on-screen wording. Anchor controls need a descriptive accessible name, visible keyboard focus, and a click target separate from the heading text when linking the entire heading would confuse selection. When a fragment URL loads, keyboard focus does not need to move automatically, but the destination heading must be visible and not covered by a sticky header.

Heading IDs must be unique within the page and should begin with a letter. Keep them lowercase, hyphenated, readable, and free from transient dates or position numbers. A stable ID can remain #verify-results even if the visible heading improves from “Verify the results” to “Verify the new credential works.” If the section’s meaning changes completely, create a new ID and preserve the old fragment through an alias or documented redirect behavior when the platform supports it. The separate anchor links specification governs anchor navigation and interaction details.

Writing rules

Write the page’s outline before polishing individual labels. Each heading should answer “what will I learn, decide, or do here?” in concrete language. Prefer “Compare annual and monthly billing costs” to “Pricing considerations,” and “Why the import rejects duplicate IDs” to “Troubleshooting.” Descriptive does not mean verbose; it means the label predicts the section’s actual content.

Use one H1 of 20–80 characters. Prefer H2 and H3 headings of 2–12 words and no more than 90 characters. A long guide normally has 3–12 H2 sections. An H2 needs at least one scope or answer sentence before any H3. Use two or more H3 sections under a parent when subdivision helps; a single H3 often signals that its content should merge into the H2.

Use sentence case unless a proper noun or product name requires capitals. Questions are appropriate when the section answers the exact question immediately. Declarative labels suit stages, criteria, findings, and specifications. Keep parallel sections grammatically parallel: use verbs for a process sequence, nouns for comparison criteria, or questions for an FAQ set.

Never put these inside heading text:

• Markdown links or raw URLs; they create competing destinations and unstable accessible names.
• Footnote markers or source citations; place evidence in the owned content.
• Emoji used as structural labels, status badges, or decorative prefixes.
• Manual numbering unless the post type defines a stable ordered sequence.
• CTA language such as “Buy now,” price claims, urgency, or promotional badges.
• Styling instructions, HTML line breaks, or device-specific abbreviations.
• A second sentence that belongs in the paragraph below.

Do not write clever labels that depend on surrounding copy to make sense. “The plot thickens” may suit an essay’s voice, but it gives a search result, table of contents, screen-reader heading list, or AI citation no usable context. Preserve personality in the explanation after a precise heading.

Post types that use it

The frontmatter postTypes array drives these relationships. Every listed post type uses the same hierarchy contract, while its own anatomy determines the exact section names and order.

QA checklist

• The page renders exactly one visible H1, and it names the page’s actual subject.
• The outline moves from H1 to H2 to H3 without skipped levels.
• Every H3 has one clear preceding H2 parent.
• Every heading is followed by meaningful owned content before the next heading.
• Every H2 includes an orienting or answer sentence before its first H3.
• Heading text is descriptive when read alone in a table of contents or screen-reader heading list.
• Parallel sections use parallel grammar and equivalent levels.
• Heading levels reflect relationships, not font size or desired visual weight.
• Typed purposes still use their required elements; headings do not imitate components.
• Every published heading has one unique, readable, stable fragment ID.
• Existing fragment IDs remain unchanged when visible wording is edited without changing section meaning.
• Direct fragment navigation leaves the destination visible below any sticky header.
• Heading text contains no links, citations, emoji labels, promotional badges, or manual line breaks.
• The HTML outline remains coherent with menus, cards, accordions, modals, and other page components present.
• The rendered page works at narrow width, with two-line headings wrapping without clipping or overlap.

Reject the page when the visual design looks polished but the outline fails. Heading defects compound: one skipped level or empty section makes every downstream consumer work harder to reconstruct relationships that the source should have stated directly.

FAQ

The questions below resolve the cases most likely to create inconsistent outlines across editors and platforms. Their authoritative values live in the structured [[faq]] frontmatter above so visible output and any eligible schema output can share one source.