Heading Hierarchy in SEO Articles: What H1, H2 and H3 Actually Do

A heading is not a font size. It is a structural claim: this is where a new section begins, and it sits underneath something above it. Browsers, screen readers and search parsers read that claim literally. A human sees bold text; a machine sees a node in a tree — and when those two pictures disagree, you get an article that reads well and parses badly.

This post covers what a correct heading hierarchy actually looks like, what search engines really do with it, where it breaks in practice, and how Smart-Copy.ai plans the structure before it writes a single sentence.

Headings are a tree, not a list

HTML gives you six levels, h1 through h6. The rule is boring and absolute: a lower level describes part of the level above it. An h3 only earns its place if it narrows the h2 it sits under.

Take an article about choosing a CRM for a small team. Correct:

• H1 — Choosing a CRM for a small sales team
• H2 — What a CRM actually stores
  • H3 — Contacts versus accounts
  • H3 — Pipeline stages
• H2 — Migration from spreadsheets
  • H3 — Cleaning the data first
  • H3 — What to leave behind
• H2 — Signs you have outgrown it

The broken version looks identical on screen and different in the markup: "Pipeline stages" promoted to h2 because the spacing looked better, "What to leave behind" demoted to h4 because a level got skipped, and "Signs you have outgrown it" shipped as a bold paragraph because the author did not want a big heading there. Visually, cosmetic differences. Structurally, three different documents.

One technical detail worth internalising: browsers do not compute a document outline for you. The HTML outline algorithm meant to infer structure was never implemented by any browser engine. The level you type is the level you get, and nothing downstream repairs a bad hierarchy on your behalf.

What search engines do with headings — and what is folklore

Headings attract more myth than almost any other on-page element. It helps to separate what Google says about itself from what the industry repeats.

Claim	Reality
Two H1 tags on a page will be penalised	No. Google's John Mueller has said plainly that their systems have no problem with multiple H1 headings — it is a common pattern on the web, and headings help them understand the context of different parts of a page.
The H1 is a strong ranking factor	Useful but not critical. Google's stated position is that its systems work with the HTML as they find it, including pages with no semantic headings at all.
So hierarchy does not matter	It matters — just not as ranking points. Hierarchy decides how your content gets split and labelled.
Every H2 needs the target keyword	No. A heading describes its section. A keyword forced into all of them degrades the description and adds nothing.

That last row is where the real stakes are now. Search systems and answer engines do not consume whole pages; they work on passages. A page gets chunked, and heading text serves as each chunk's label — what this block is about and what it belongs to. A section with a descriptive heading and a self-contained answer under it is easier to lift than the same sentence buried in the eighth paragraph of a wall of text. Heading order matters because the chunking tree is built from it.

Accessibility: same signal, different audience

Screen reader users navigate long pages by jumping between headings. It is the primary way of skimming a document without a mouse, and the level tells the user where they are in the hierarchy. A jump from H2 straight to H4 reads exactly as it looks: a signal that something in between was missed. Screen reader users say so directly — going from level 2 to level 5 raises the obvious question of what lives at 3 and 4.

Formally this is WCAG 1.3.1 (Info and Relationships) territory: structure conveyed visually must also be available programmatically. A bold paragraph pretending to be a heading is an unambiguous failure — visually a section, structurally absent. A skipped level is judged more leniently and is not always classed as a violation, but W3C guidance consistently advises against it. The useful part: parsers expect the same ordering. One decision, two audiences.

Five failures you will find in most articles

1. Two H1s by accident. Not by design — the CMS template renders the post title as an H1, and the pasted HTML brings its own H1 with the same words. Google will cope, but you have shipped a duplicated title for no reason.
2. Level chosen by size. The author wants tighter spacing, so an H3 goes in where an H2 belongs. Predictable, because in a WYSIWYG editor heading level is presented as a formatting option.
3. Generic headings. "Introduction", "Conclusion", "Final thoughts". Zero information for a reader skimming the page, and zero information for a parser that will use that string as a chunk label.
4. Headings that do not match their section. An H2 promises "What it costs" and delivers three paragraphs of background history. The reader bounces, and the passage is not quotable.
5. Flat structure on long articles. Fifteen consecutive H2s and no H3s. Technically valid, practically a sign that nobody decided which threads are primary.

How Smart-Copy.ai plans structure before writing

In Smart-Copy.ai, structure is not a by-product of writing. It is a separate, earlier stage, and you can watch it happen in the order statuses exposed by the API:

queued → researching → outlining → awaiting_outline_approval → writing → generating_image → completed

The sequence is the whole point. Research comes first — search results and competitor content, plus any sources you supply via source_urls and source_mode. Only then outlining, where the planning agent (Manager) builds the heading tree: what becomes an H2, what drops to H3, the order of sections and how much room each one gets. The writing model does not improvise structure paragraph by paragraph. It receives a finished plan and fills it section by section — which is why the writing status returns a section {current, total} counter against that plan.

This addresses the most stubborn failure mode in long-form generation: a model writing linearly with no plan drops a heading wherever it happens to change subject. The result has headings but no hierarchy.

Depth scaled to length

The plan is proportional to the requested length. Short pieces get a shallow tree and a single list; long ones get full H3 development and at least one table.

Requested length	Typical plan shape
~4,000 characters	4–5 H2 sections, H3s only where the topic genuinely branches, one list
~8,000 characters	6–8 H2 sections with H3 development, several lists, usually a comparison table
15,000 characters and up	Full two-level tree, multiple lists and tables — otherwise it reads as one continuous block

The outline as a checkpoint

To review the plan before any prose exists, set outline_approval: true. The order pauses at awaiting_outline_approval and you receive an outline.ready webhook. You then fix a dozen lines of outline instead of restructuring a finished 9,000-character draft. On autoblog series, that single flag decides whether you are steering the structure of a topic cluster or just receiving whatever arrives.

Validated output, not good intentions

After writing, the HTML goes through an output check: whether heading levels stayed consistent and whether the planned elements are actually present. That asymmetry is deliberate: the system does not assume the model followed instructions, it verifies the result. The same approach drives internal linking, covered in how SEO optimization actually works inside Smart-Copy.ai and in the guide to automated internal linking.

One publishing trap: the second H1

The API response includes an html field with the full body — H1 included. That is correct behaviour when you are dropping the text into a template that does not render the title itself. Most WordPress themes do render the post title as an H1 automatically. Paste the HTML in and you get two H1s in a row carrying the same words.

Two ways out. Publish through wp_site_id or the WordPress plugin, where title and body are mapped on the integration side. Or, in a custom pipeline, strip the leading H1 from the returned HTML before saving if your template already prints the title.

Checklist: how to format an SEO article

• One H1 per page, matching the topic — and check whether the template is already adding one.
• Levels descend in order: H2 → H3. No jumps to H4.
• Level chosen by relationship to the parent section, never by font size.
• Each heading describes its section specifically enough to work out of context.
• No bold paragraphs impersonating headings.
• Keywords placed where they fit naturally — selection is covered in the guide to choosing keywords.
• Every section closes one thread and can be quoted on its own.
• Tree depth proportional to article length.

Structure is not cosmetics applied to finished prose. It is a decision you make before writing: which questions the article closes, and in what order. That is why Smart-Copy.ai produces the plan first and the text second.