Headings and structure are a content decision

The headings on a page — what each one says, and in what order they run — are decided by what the page has to communicate and in what sequence a reader needs it. They are not decided by a visual template with a fixed number of section slots. Treating heading structure as a design choice, filled in with whatever the design has room for, produces pages where a reader’s actual questions and the page’s actual sections do not line up.

Structure follows the argument, not the layout

Every useful page is making an implicit argument: here is what this is, here is why it matters to you, here is what it costs or how it works, here is what to do next. The headings on the page should be that argument’s outline, made visible.

When headings get chosen backwards

When the headings are chosen first by a designer sketching a template — three feature blocks, a testimonial section, a closing call to action — the content is then written to fill those slots. The argument gets bent to fit a shape that was decided before anyone knew what needed saying.

This is why structure belongs with the content decisions in a build, not the visual ones. A designer working from real headings produces a more coherent page than one working from placeholder labels.

Semantic hierarchy is a content fact, not a style choice: heading levels and HTML tags

A page’s heading levels — an H1 tag at the top, H2 tags for its main sections, H3 tags for the subheadings beneath those — describe the actual relationship between sections of content in the underlying HTML. This part of the page belongs under that heading; this heading is a sibling of that one. The HTML heading levels are what carry that relationship, not the visual size of the text.

Why styling a paragraph to look like a heading breaks the outline

Styling a paragraph with a larger font-size to look like a heading, or styling a genuine heading to look like ordinary text, breaks the HTML relationship for anyone using assistive technology to navigate the page by its heading outline. It breaks it regardless of how the page looks visually. Getting the heading levels right is close to free during writing. It is expensive to retrofit once a page is built, because it means going back through HTML markup that was never given real heading tags in the first place.

What decides the order

Question the reader has	Where it should sit in the structure
What is this, broadly	First — before anything else, even proof or credentials
Does it apply to my specific situation	Early — before general benefits or features
What does it cost, or what drives the cost	Named honestly, not buried near the bottom
What happens if something goes wrong	Rarely included at all; a genuine trust signal when it is
Why should I believe this business	Late — proof works better after the claim it supports, not before

A page that runs this order backwards — proof and credentials first, the actual offer buried in the middle, cost never mentioned — is usually a page where the headings were chosen to fit a design template rather than a reader’s actual sequence of questions.

One heading, one job

A heading that repeats a fact from an earlier section is a sign the page’s structure has drifted. It means the writer ran out of new things to say under a new label and reached backward for material that already had a home. Each heading should own a distinct piece of the argument. If two headings could be merged without losing information, they probably should be.

Where this connects to FAQs

A weak FAQ section is often a symptom of a structure problem rather than a content problem in its own right: questions get shoved into an FAQ block because they did not fit anywhere else in the page’s heading structure, rather than because an FAQ was genuinely the right place for them. FAQs that earn their place covers the distinction between a question that belongs in the body of the page, under its own heading, and one that genuinely belongs in a closing FAQ block.

Structure and the build process

Because heading structure is a content decision, it works best when it is settled before a designer starts laying the page out, and revisited only if the content itself changes. A design built around real, ordered headings is doing less guessing than one built around three generic content blocks waiting to be filled. Where structure fits alongside the rest of a build’s sequence, website design services sets out where content decisions like this one sit relative to design and development.

How many heading levels and subheadings is too many

There is no fixed number, but a useful check is whether each heading could be explained in one sentence to someone who has not read the page, without that sentence overlapping another heading’s explanation. A page with many short headings, each covering a sliver of a larger idea that would read better combined, is usually a sign the content was broken up to look thorough rather than because each section genuinely needed separating. The reverse failure — one long heading covering several distinct ideas — is just as common and just as fixable, by splitting it once the distinct ideas underneath it are identified.

Headings, ARIA attributes and assistive technology, specifically

Beyond general readability, a heading outline is how a screen reader user navigates a page directly to the section they need. They jump from heading to heading rather than reading the entire page in sequence. Where a genuine H1–H6 HTML tag genuinely cannot be used — inside some component libraries, for instance — an ARIA role="heading" with an aria-level attribute can recreate the same outline. A real HTML heading tag is simpler, though, and should be the default. A page with a correct, logical heading hierarchy is genuinely faster to use for that reader than one with the same content under visually-styled but non-semantic headings, even though both may look identical to a sighted visitor. This is one of the more mechanical, checkable parts of a page’s accessibility. It costs nothing extra to get the heading levels right during writing, compared to a genuine expense to retrofit once a page’s HTML markup already exists without proper heading tags.

What to do next: use headings and subheadings that read as an outline

Write out a page’s headings alone, with no body copy underneath, and read them in order as if they were the only thing a visitor saw. If that sequence does not answer their questions in a sensible order, the fix belongs in the outline before a single paragraph is written under any of them.