Subheads as a Table of Contents Your Reader Skims

Here is an uncomfortable exercise. Open a long page on your own website, and read nothing but the subheadings. Ignore every paragraph. Just read the bold lines, top to bottom, as if they were the entire page. Now ask yourself: does this sequence of lines tell a visitor anything? Could someone who read only these lines walk away knowing what you offer, what it costs them, and what to do next?

For most pages the answer is no. The subheads read something like “Our Approach,” “Why It Matters,” “The Details,” “Going Further.” Each one is a label on a box, and the label says “box.” I’ve come to believe this is one of the most common and least noticed failures in web writing, and it matters because of a fact about behavior that’s easy to state and hard to internalize: the skim is not a degraded version of reading your page. The skim is the primary way your page gets read. The people who read every word are the exception. So when you write subheads, you are not decorating a document. You are writing the edition of your page that most of your audience will consume in its entirety.

Once you see it that way, the standard for a subhead changes completely. A subhead’s job is not to categorize the text below it. Its job is to deliver the point of the text below it, so that a reader who skips the text still gets the point. “Our Approach” delivers nothing. “We audit your site the way a first-time visitor sees it” delivers something. If the paragraph beneath it elaborates, fine. If the reader skips the paragraph, they still leave with the idea. The paragraph becomes optional depth rather than mandatory excavation.

The best mental model I know is to think of your subheads as a table of contents that happens to be interleaved with the content. A good table of contents in a book does two things at once: it lets you navigate, and it summarizes. You can learn a surprising amount about a book’s argument from its contents page alone. Your subheads should survive the same test. Extracted and stacked, they should read like an abstract of the page. This is testable in about thirty seconds, which is why I like it. Copy out just the headings and read them as a list. Where the list goes vague, that’s where a skimming reader falls into a gap.

There’s a technical dimension to this that reinforces the editorial one. In HTML, headings aren’t just big text. The h1 through h6 tags form an outline of the document, and software takes that outline seriously. Screen reader users routinely navigate by jumping from heading to heading; for them, your heading structure literally is the table of contents, the primary interface to the page. Search engines read the hierarchy to understand what the page covers, and increasingly lift well-written subheads directly into results. So a page whose headings are visually styled paragraphs, bolded text with no heading tag, or headings chosen for their font size rather than their level, is broken in a way sighted skimmers never notice but machines and assistive tech feel immediately. When GazeSite audits a page, this is one of the things it checks, and the outline it extracts from the raw HTML is often the first time a site owner has ever seen their page the way a screen reader presents it. The reaction is usually some version of: oh, that’s what my page says?

The main force pushing writers toward bad subheads is the desire to be clever. A subhead like “The Plot Thickens” or “Not So Fast” feels alive when you write it. But cleverness in a subhead is a bet that the reader will read the section to resolve the tease, and the skimming reader doesn’t take that bet. They read the tease, get nothing, and move on. Clever subheads are like labeled doors where every label is a riddle. In a magazine, where the reader has already committed to the article, riddles can be fun. On a web page, where the subheads are competing for the reader’s continued presence, each vague one is a small invitation to leave.

The other failure is spacing. Some pages have one subhead every twelve paragraphs, which means the skimmer’s map has one landmark per mile. On a phone this is worse than it sounds, because a paragraph that looked modest on your monitor becomes a full screen of gray on a five-inch display, and twelve of them is twelve swipes through unmarked territory. A useful rule is that a skimming thumb should never scroll more than a couple of screens without hitting a line that tells them where they are and what’s here. If a section can’t be summarized in one honest line, that’s usually a sign the section is actually two sections.

Writing subheads this way is harder than it looks, and I think the difficulty is the point. To write a subhead that states the point of a section, you have to know what the point of the section is. Sections written before their point was clear resist summary; the subhead comes out vague because the thinking underneath is vague. Which suggests a workflow that sounds backwards but works: write the subheads first, as a list of claims, and only then write the sections that support them. If the list of claims is compelling on its own, the page will be compelling. And if it isn’t, you’ve discovered that before writing a few thousand words, instead of after.

Your subheads are the page. Write them like it.