Subheadings announce content, not curiosity
Subheadings are signposts, not teasers
Your H2 or H3 exists to tell skimmers whether the section underneath is worth reading. Not to intrigue them. Not to build suspense. If someone has to read three sentences to figure out what the heading meant, the heading failed.
A good subheading works like a table of contents entry. It names the topic clearly enough that a reader can decide to skip it or stay. "Our approach" tells nobody anything. "We calculate shipping costs by weight and distance" does.
Start with the topic sentence, then cut
Write the first real sentence of your section. The one that actually explains what you're about to cover. That's your subheading in disguise.
Now trim it. Cut the preamble, the connector words, the politeness. What's left should still make sense on its own. If it doesn't, you cut the wrong words.
"When you're trying to decide which plan works best for your team" becomes "Which plan fits your team." Or just "Plan comparison." Both are better than "Finding the right fit."
Parallel structure isn't decoration
If your page has multiple subheadings at the same level, they should follow the same grammatical pattern. All questions, all noun phrases, all verb phrases — pick one and stick with it.
This isn't about aesthetics. It's about setting expectations. When headings share a structure, readers learn the pattern and can scan faster. A list that goes "How to export data," "Importing your files," "Sharing with your team" makes people work harder than "Export data," "Import files," "Share with your team."
You'll notice this the moment you try to write a table of contents. Mismatched headings look like different people wrote different sections. Maybe they did. Fix it anyway.
Front-load the keywords people scan for
Put the important word first. "Pricing for annual plans" beats "Annual plan pricing" if someone's searching the page for "pricing." "Keyboard shortcuts" beats "Using keyboard shortcuts" for someone looking for "keyboard."
This applies to heading hierarchy as much as word choice. Your H2s are the top-level scan points. If the critical information is buried in an H3 two levels deep, most readers won't find it.
Test your subheadings in isolation
Copy all your headings into a separate document, one after another, with no body text. Read just the headings. Do they make sense as a sequence? Could someone understand the page structure from headings alone?
If the answer is no, your subheadings are decorative. Rewrite them so they function as an outline.
This is the same test you'd use for link text that survives getting skimmed. Headings get skimmed even more ruthlessly than links. If yours don't work out of context, they don't work.
Questions work when the section answers them
A question as a subheading is fine if the next paragraph directly answers it. "How do refunds work?" followed by the refund policy is clear. "How do refunds work?" followed by three paragraphs about your company philosophy and then maybe the policy is bait.
If you're asking a question your content doesn't answer, you're writing a headline, not a subheading. Those are different jobs.
Don't repeat the parent heading
If your H2 is "Account settings," your H3s shouldn't be "Account security settings," "Account notification settings," "Account privacy settings." They should be "Security," "Notifications," "Privacy." The parent heading already established the context.
This is basic information architecture. Every heading level adds specificity. Repeating the parent's keywords is clutter.
Write them before you write the section
A subheading written after the fact is a summary. A subheading written first is a constraint. The constraint version is usually clearer because it forced you to decide what the section would cover before you started rambling.
Try writing the subheadings before you write the content. You'll notice which sections don't need to exist and which headings don't actually mean anything. Fix both problems before you write 200 words you'll have to delete.