Does Heading Hierarchy Still Matter for SEO?

Does heading hierarchy still matter for SEO?

Less than most people think for Google, and more than most people think for everything else. Google's SEO starter guide says having headings in semantic order is fantastic for screen readers, but from a Google Search perspective it does not matter if you use them out of order. That is about as clear as a search engine gets.

So the ranking argument for clean heading structure is weak. The argument from accessibility, from how answer engines chunk a page, and from plain readability is strong. Those three reasons are enough, and they point the same way.

This is a short, practical walkthrough of what to do with headings on a marketing site or a blog, and which rules are real rules rather than inherited habit.

What does Google actually say about heading order?

It says order is not a ranking concern. The exact wording in the starter guide is that semantic order is fantastic for screen readers, but from Google Search's perspective it does not matter if you are using them out of order. Google treats headings as a way to help people navigate, not as a hierarchy it grades.

Google is similarly relaxed about quantity. The same guide says there is no magical, ideal amount of headings a given page should have, then adds a line we like a lot: if you think it is too much, then it probably is. That is a judgement call, deliberately.

What Google does push is purpose. Its advice is to break up long content into paragraphs and sections and provide headings to help users navigate your pages. The job of a heading is to tell a reader what comes next. Everything else is secondary.

Why does heading order still matter, then?

Because people navigate by it. The W3C Web Accessibility Initiative tutorial on page structure says browsers, plug-ins, and assistive technologies can use headings to provide in-page navigation. For a screen reader user, the heading list is the table of contents, and a broken list is a broken map.

The W3C guidance is to nest headings by rank, with rank 1 the most important and rank 6 the least, and it says skipping heading ranks can be confusing and should be avoided where possible. It gives a concrete example: an h2 should not be followed directly by an h4.

So the rule survives, just for a different reason than the one most teams were given. You are not keeping heading order tidy to please a crawler. You are keeping it tidy because a real person uses it to move around your page. Our notes on why semantic HTML matters make the same argument across other elements.

Should a page have only one top level heading?

One is the safe default. MDN's reference on heading elements says that while using multiple h1 elements on one page is allowed by the HTML standard, as long as they are not nested, this is not considered a best practice, and that a page should generally have a single h1 that describes the content of the page.

In practice this is less of a dilemma than it looks. On almost every marketing page there is exactly one thing the page is about, and that belongs in the single top level heading. If you genuinely have two equal subjects on one page, the harder question is whether it should be two pages.

Blog templates are where this breaks most often. A site-wide logo wrapped in a top level heading, plus the article title also as a top level heading, gives you two. It is valid HTML and it still reads as sloppy to anyone auditing the page. Fix the template, not the article.

What happens when you skip a heading level?

Navigation gets confusing and nothing else breaks. MDN's guidance is direct: do not skip heading levels, always start from h1, followed by h2, and so on. It frames the reason as accessibility, since screen reader users moving by heading lose the sense of where they are.

No search penalty follows from a skipped level. Google has told us order does not matter to Search. If someone audits your site and reports skipped headings as an SEO error, they are using the wrong label for a real but different problem.

The common cause is styling. A designer wanted smaller text, so someone reached for a lower heading level. MDN addresses this too: do not use heading elements to resize text, use the CSS font size property instead. The structure and the visual size are two separate decisions, and conflating them is where most broken hierarchies start.

How do headings help AI answer engines parse a page?

By marking where one answer ends and the next begins. Google says there are no additional requirements to appear in AI Overviews or AI Mode, and no special optimizations necessary. It also says you do not need to create new machine readable files, AI text files, or markup, and that there is no special schema.org structured data you need to add.

That is worth reading carefully, because it cuts both ways. There is no secret format to adopt. There is also nothing stopping clear structure from helping, since a system extracting a passage still has to decide where the passage starts. Google describes using a query fan-out technique to find supporting pages, which it says surfaces a wider and more diverse set of helpful links.

Our working view is that headings earn their keep as boundaries. A section that opens with a direct answer under a heading phrased as a question is easy to lift as a unit, whether the thing lifting it is a person skimming or a retrieval system chunking. We go further into that in our piece on how pages get chunked for AI retrieval.

How many headings should a page have?

Enough that the heading list alone tells the story. Google explicitly declines to give a number and says there is no ideal amount. We aim for a heading roughly every two to four paragraphs on long-form pages, which usually lands between eight and twelve on a two thousand word article.

The test we use is to strip the page down to just its headings and read them in order. If that list reads like a sensible outline of the subject, the structure is doing its job. If it reads like a list of vague labels, the headings are decoration.

Too many headings is a real failure mode, not just a theoretical one. A heading above every paragraph removes the hierarchy entirely, because nothing is grouped. Google's line applies well here: if you think it is too much, then it probably is.

Should headings be phrased as questions?

Often, yes, on informational pages. A question heading forces you to answer it in the next sentence, which is good discipline regardless of who is reading. It also matches how people phrase things when they search or ask an assistant, which makes the section easier to match to an intent.

It is not a universal rule. On a product or pricing page, a question heading can feel evasive where a direct statement is stronger. The underlying principle is that the heading should set a specific expectation the section then meets, and a question is one reliable way to do that.

What does not work is a question heading followed by three paragraphs of background before the answer. If the heading asks something, the first forty to sixty words should answer it. That is the whole value of the format, and it is the part teams skip.

How do you check your heading structure in five minutes?

Pull the headings out and look at them. Most browsers' accessibility inspector will show you a heading tree, and any crawler will export heading levels per page. You are looking for three things: more than one top level heading, a skipped level, and headings whose text does not describe the section.

Then do the harder check, which no tool does for you. Read each heading and the first sentence under it as a pair. If the sentence does not answer the heading, you have found a real problem that no audit score will flag.

The accessibility side deserves an actual test rather than a tool score. Tabbing through a heading list in a screen reader takes a couple of minutes and tells you more than a report. Our guide to screen reader testing covers how to do that without specialist setup.

What goes wrong with headings on the sites we inherit?

Usually the template, not the writing. The most common pattern we see is a page where the visible headline is styled text in a div, and the real heading elements are on the section labels further down. The page looks fine and its structure is meaningless.

The second pattern is heading levels chosen by size. A site ends up using one level for every large heading and another for every small one, anywhere on any page, because those were the two styles in the design system. The structure then encodes type scale instead of meaning.

Both are template problems with cheap fixes, which is why we look at them early on any inherited site. They also tend to travel with other accessibility gaps worth catching at the same time, which our WCAG guide covers in more depth.

Where is heading structure heading next?

Towards being read by more things, not fewer. Google has said order does not matter to Search and that no new markup is needed for its AI features, so the pressure to add special structure is off. The pressure to be genuinely well structured is up, because more systems now lift sections out of pages rather than linking to whole pages.

Our bet is that the teams who treated headings as a semantic outline all along will not have to do anything. The ones who treated them as a type scale will spend a sprint fixing templates. That is a cheap problem to avoid and an annoying one to inherit.

If you want a second pair of eyes on how a site is structured, and a plain answer on what is worth fixing, we are happy to look. We are at phoenix.studio.