Open the page you are working on and read only the headings, in order, ignoring every paragraph. If that list reads like a coherent outline of the page, the structure is sound. If it reads like a random pile of labels at random sizes, the structure is broken, no matter how good the page looks on screen. That one-minute test is the whole discipline in miniature, and most pages fail it for the same predictable reasons.
Headings are the page’s outline, not its styling. They tell readers and machines what the page is about and mark the order and level of importance of each part. Visual size is a side effect, not the point. The trouble starts when someone wants a line to look bigger and wraps it in an H2, or a designer hands over a mockup where the call-to-action sits in an H1 because it is the largest text. The HTML then records a structure that does not exist. Screen readers read that structure. Google’s systems read it. A page with bigger fonts in the wrong places can look fine to a sighted reader scrolling fast while the underlying outline reads like nonsense.
Three things depend on that outline. Readers skim headings before deciding whether to read the paragraphs under them. Screen reader users navigate by heading level, often pulling up a heading list to understand a page before reading a word. And Google uses heading hierarchy to understand what a page covers and how it is organized. So heading structure is not a design decision. Write the outline first, then style it.
Use one clear H1, but know it is not a hard rule #
The H1 names the page’s primary topic in plain language. It should be specific enough that it could not fit ten other pages on the same site, and short enough to scan rather than stuffed with keywords. What does not belong in the H1: the site logo (even when it is visually the largest element), the site name repeated on every page (that is the title tag’s job), or a navigation label like “Services” unless the page is genuinely an index.
Here is where a persistent myth needs correcting. It is widely repeated that a page must have exactly one H1 or it will suffer in search. That is not what Google says. John Mueller has stated plainly that a page can rank with no H1, with one H1, or with five H1s, and that Google’s systems do not have a problem with multiple H1 headings on a page. Multiple H1s are common and valid in HTML5 sectioning elements such as <article> and <section>, and they will not break ranking. Google does not enforce a single H1.
The title tag and the H1 are also separate surfaces with separate jobs. The title tag is what shows in search results; the H1 is what shows on the page itself. They do not need to match word-for-word, but they should point at the same topic so the page confirms what the user expected when they clicked.
So why still favor one H1? Two practical reasons, neither of them a ranking penalty. First, accessibility: screen reader users treat the H1 as the page’s entry point, and WCAG-aligned checkers flag pages with zero or multiple H1s because the heading-navigation shortcut becomes ambiguous. Second, outline clarity: when several sections all claim top-level status, the outline flattens into a list of equal-weight topics instead of one topic with subsections. The practical rule, then, is a preference and not a mandate: write one H1 that names the page, place it once near the top of the main content, and let the H2s carry the structural weight underneath.
Keep H2 as section and H3 as subsection, never flipped #
H2s are the page’s chapters. H3s are subsections inside those chapters. The relationship stays strict: an H3 lives under an H2, never above one and never instead of one. A page on choosing running shoes shows the shape clearly:
H1: How to Choose Running Shoes for Beginners
H2: Match the shoe to your foot type
H3: Flat feet and stability shoes
H3: High arches and cushioning
H2: Match the shoe to your running surface
H3: Road running
H3: Trail running
H2: When to replace your shoesEach H2 names a section that could stand on its own. Each H3 names a smaller topic that belongs to its parent H2. The common failure is reaching for H3 because the text feels “less important,” without checking whether an H2 exists above it. A sequence that runs H1, H3, H3, H2 is not a hierarchy. It is a list with arbitrary sizes, and screen readers reading that outline get whiplash.
A clean H2 also helps Google’s snippet selection. When a user’s query closely matches one of your H2s, the text immediately following that H2 becomes a strong snippet candidate. Vague H2s like “Overview” or “More Info” do not earn that placement; specific ones like “How long should a title tag be?” do. The discipline is simple: before writing an H3, ask which H2 it sits under. If the answer is “none,” promote it to H2 or restructure the section.
Do not skip heading levels #
The hierarchy goes in order, H1 to H2 to H3 to H4. Skipping a level, jumping from H1 straight to H3, breaks the outline in a way that matters. This is a WCAG 1.3.1 (Level A) concern, not a style preference. The W3C Web Accessibility Initiative is explicit that skipping heading ranks can confuse assistive technology users and should be avoided where possible. A page with H1 followed directly by H4 reads as if two levels of structure exist between them that are not actually there, giving screen reader users false signals about depth.
The fix is to move down one level at a time and only move back up at the end of a section. A broken page that runs H1, H4, H2, H4 should become H1, then H2, with its H3 subsections, then the next H2 with its own H3s. There is one nuance worth keeping: it is fine to skip ranks when closing a subsection. An H2 that starts a new major section can follow an H4 that closed the previous one. What is not acceptable is opening a deeper rank before the rank above it has appeared.
When this gets violated in practice, the cause is usually template-driven. A CMS theme assigns H4 to sidebar headings, or a page-builder block hardcodes a level that does not fit the article. Fix the template, not the individual page as a workaround.
Style with CSS, structure with semantics #
Heading level is about structure. Heading appearance is about CSS. The two are independent, and confusing them is the single most common source of broken outlines. A writer wants a line to look smaller, so they wrap it in H3 instead of H2, and now the structural hierarchy no longer matches the content. The fix is never to choose a different heading level for a visual reason. Keep the correct level for the structure and adjust the CSS so it looks right.
The pattern to catch yourself in: “I’ll use H4 here because H3 looks too big,” or “I’ll add an extra H1 because I want a second big headline.” In each case the right move is to pick the level that matches the structure, then create the visual emphasis you want with CSS. Heading elements do two jobs at once: they organize the document outline for crawlers and screen readers, and they provide default visual sizes for sighted readers. The visual job is trivial to override. The structural job is the one that matters for users who cannot see the visual cues. If you find yourself choosing a heading level based on how big you want the text to be, stop and pick the level that matches the structure first.
Match the heading rhythm to the page type #
Heading structure is not uniform across page types. A long-form blog post needs more depth than a product page; a FAQ page needs a different shape than a tutorial.
| Page type | H1 | H2 pattern | H3 usage |
|---|---|---|---|
| Long-form blog post | Article title | Major topics or argument steps | Subsections under each H2, often one to three |
| Product page | Product name | Specs, fit, comparison, FAQ | Sparse, only when a section needs internal divisions |
| FAQ page | Topic of the collection | Each question as its own H2 | Rarely needed, since each answer is self-contained |
| Tutorial | The procedure being taught | Sequential steps or stages | Substeps within complex stages |
| Landing page | The offer or value proposition | Benefits, features, proof, FAQ | Usually shallow, favoring scannability |
| Documentation | Page topic | Conceptual then reference sections | Heavy, often several levels deep |
For a long-form post the H2s should read like the table of contents a curious reader would expect, with H3s dropping into specifics inside each. A 3,000-word article living entirely under H2s with no H3s is under-structured; one nested four or five levels deep is over-structured. For a product page the H2 pattern is functional rather than narrative, each H2 a section a buyer might jump to. For a FAQ page each question gets its own H2, worded the way users actually ask, because question-style headings are strong candidates for People Also Ask boxes and featured snippets. For documentation, deep nesting is expected, and the discipline is consistency: the same level should always mean the same kind of content.
How to check the outline #
Two lenses catch nearly every heading problem, and both are quick.
The accessibility lens rests on three WCAG criteria. 1.3.1 Info and Relationships (Level A) requires that structure conveyed visually also be available programmatically, so anything that looks like a heading must be marked up as one. 2.4.6 Headings and Labels (Level AA) requires that headings describe the topic or purpose of their section; “More Info” fails, “Shipping rates by region” passes. 2.4.10 Section Headings (Level AAA) is the strictest, recommending headings on all major sections. Tools like WAVE, axe DevTools, and Lighthouse flag most heading violations automatically, and the fixes they return, such as replacing bold paragraphs that act as headings with real heading elements or removing empty headings used for spacing, are usually one-line changes.
The search lens is about extractability, not ranking leverage. Heading hierarchy is not a major ranking factor; Mueller has been consistent that pages rank with no H1, one H1, or several. But a clean outline helps Google match queries to sections, which influences featured snippet selection, People Also Ask boxes, AI Overview extractability, and how Google maps which page handles which subtopic. Headings will not make a thin page rank, and treating heading order as a ranking lever is a mistake. What a good outline does is help a strong page get understood, extracted, and surfaced where structure is what gets you in the door.
Frequently asked questions #
Does my page need exactly one H1? No. One clear H1 is a sound default for accessibility and outline clarity, but Google explicitly allows zero, one, or multiple H1s without penalty, and HTML5 sectioning makes multiple H1s valid. Favor one because it helps screen reader users and keeps the outline clean, not because a rule requires it.
Do headings affect rankings directly? Not as a major factor. Google uses headings to understand structure and to match queries to sections, which affects snippets, PAA, and AI summaries. Keyword-stuffing headings does not raise rankings and hurts readability.
Can I ever skip a heading level? Only when closing a subsection. You may follow an H4 with an H2 that opens a new major section. You should never open an H3 or H4 before the level above it has appeared.
Should the title tag and H1 be identical? No. They serve different surfaces and can be worded differently, but they should point at the same topic so the page matches the searcher’s expectation.
The work is mostly invisible. One clear H1 that names the page, H2s that name real sections, H3s that nest under their parents, no skipped levels, no headings used for styling, and specific text instead of vague labels. Start with the read-the-headings-only test on your most important page, fix whatever reads like nonsense, and let the rest follow. The pages where this is done right never get noticed for their headings. The pages where it is not always do.