H1 tags and heading structure: a practical guide

The H1 tag attracts more advice than it deserves. It is not a magic ranking lever. It is a document outline element that tells a browser, a screen reader, and a search engine what the page is about. Get the outline right and everything downstream gets easier. Get it wrong and you create confusion that no keyword repetition can fix.

The useful question is not "how many keywords go in the H1". It is "does the heading structure describe the page accurately".

One H1 per page, as a default

A page should have a single H1 that names the page. On an article, that is the article title. On a product page, it is the product name. On the homepage, it is the positioning statement.

Multiple H1s are technically valid HTML. The old rule that more than one H1 breaks SEO is overstated. But a single H1 is still the clearest signal and the simplest convention to enforce across a template. When a page has three H1s, it is usually because a component was reused, not because the author made a deliberate outline choice.

If you have a strong reason to use more than one, keep the first one as the page title and make the rest genuinely section-level. Do not use H1 as a styling shortcut.

The hierarchy should descend in order

Headings form an outline. H2s are the main sections, H3s are subsections of those, and H4s are subsections of the H3s. Skipping from H1 to H3 is not fatal, but it breaks the outline and makes the page harder to navigate.

A good structure looks like this:

H1  Technical SEO audit
  H2  Crawlability
    H3  Robots.txt
    H3  Sitemaps
  H2  Indexation
    H3  Canonicals
  H2  Performance

A bad structure looks like this:

H1  Technical SEO audit
  H4  Why audits fail
  H2  Crawlability
  H5  Robots.txt
  H2  Performance

The second version uses heading levels as font sizes. The visual result may look fine, but the outline is noise. Screen reader users navigate by heading level, and so do many search tools.

Headings are wayfinding, not keywords

Every heading should describe the content beneath it. A heading that says "Why this matters" is vague. A heading that says "Why canonical tags must point to a 200 page" is useful.

This matters for two reasons. First, people scan headings before they read. A page whose headings do not summarise the argument is harder to skim. Second, anchor links and tables of contents are built from headings. A heading that reads well out of context makes a better anchor.

Do not stuff the primary keyword into every heading. Use it where it is the natural name of the section, and use plain language elsewhere. Repetition reads as spam to humans first, and the machine signal is weaker than most people believe.

Common CMS mistakes

Most heading problems are template problems, and they repeat on every page.

The logo wrapped in an H1. Some themes wrap the site logo in an H1 on every page. That makes the brand the page's main heading and pushes the actual title down to H2. Fix the template, not the content.

Card titles as H3 or H4. A card grid on the homepage often uses H3 for each card title with no H2 above it. The result is a page with a heading hierarchy that starts at H3. Use a visually hidden H2 for the section, or make the card titles H2 if the section has no other heading.

Widget headings as H1. A related-posts widget or a newsletter block can accidentally ship an H1. Audit the rendered DOM, not the CMS field names.

Bold text instead of headings. Editors sometimes use bold paragraphs to create visual sections because the heading style is ugly. That produces a page with no outline at all. Fix the heading styles so the correct markup is also the easy choice.

Duplicate titles across languages. On a multilingual site, the H1 should be in the page's language, not copied from the default locale.

The accessibility overlap

Heading structure is one of the few areas where SEO and accessibility want exactly the same thing. Screen reader users can list all headings on a page and jump between them. A logical outline makes that navigation useful. A page built from styled divs makes it impossible.

The practical overlap:

• Use real heading elements, not div with a class.
• Keep one H1 that names the page.
• Do not skip levels for visual reasons.
• Do not use headings for text that is not a heading, such as a button label.
• Make sure headings are visible; hidden headings are acceptable only when they label a section for assistive technology.

If the page passes an accessibility audit for heading order, it is almost certainly in good shape for SEO.

Examples of good and bad structure

A well-structured article:

<h1>H1 tags and heading structure</h1>
<p>Intro paragraph.</p>
<h2>One H1 per page</h2>
<p>...</p>
<h2>The hierarchy should descend in order</h2>
<h3>Why order matters</h3>
<p>...</p>
<h3>How to check it</h3>
<p>...</p>
<h2>Common CMS mistakes</h2>

The same content with a broken outline:

<h1>H1 tags and heading structure</h1>
<h4>One H1 per page</h4>
<h2>The hierarchy should descend in order</h2>
<h5>Why order matters</h5>
<h2>Common CMS mistakes</h2>

The words are identical. The outline is not. The second version forces a reader navigating by headings to guess the structure, and it makes the table of contents unreliable.

A short checklist

Before publishing, check the rendered page:

1. Exactly one H1, and it matches the page's purpose.
2. No heading levels skipped in the main content.
3. Every H2 is a real section, not a styling wrapper.
4. Headings describe their section without keyword stuffing.
5. The table of contents, if you have one, matches the visible headings.
6. No widget or card injects an unexpected H1.
7. Heading text is readable out of context, because that is how anchors and search snippets use it.

None of this is exotic. It is the difference between a page that can be outlined and one that merely looks structured. For the rest of the technical picture, read the technical SEO audit checklist or the guide to the Lighthouse SEO score. If you want the rendered DOM checked for you, run a free audit on a site you own.