What Are Headings In Writing

Understanding How Headings Actually Function in Document Structure

Headings are structural labels that organize content into hierarchical tiers. They tell both machines and humans where sections begin and how they relate to one another. The concept seems straightforward until you start working with content management systems or accessibility tools, and that is usually where things go wrong. I spent years managing technical documentation for enterprise software releases. We had a style guide that specified heading usage down to the decimal, and still, about a third of our published pages had broken heading trees. The issue was never a lack of knowledge. It was a lack of enforcement and tooling. When you open an HTML file or a WordPress editor and someone slaps an H3 after an H1 without an H2 in between, screen readers get confused. Automated parsers assume a section that does not exist. That creates real problems for users with assistive technology.

What Are Headings In Writing and Why Structure Matters More Than Styling

There is a persistent misconception that headings are primarily a visual styling choice. They are not. Bold text at the top of a paragraph does not make a heading. A heading is a semantic element. The HTML h1 through h6 tags carry meaning. CSS can make an H6 look like an H1. That does not change what the element represents. Search engines read the semantic structure, not the rendered appearance. This is why you will see sites with impressive SEO rankings that have complete heading garbage beneath the surface. The hierarchy works like a table of contents. H1 is the document title. H2 is a major section. H3 is a subsection within that section. H4 drops deeper. Most practical writing never needs to go past H4. I have published documents that went to H5 and H6, and every single time it felt like a mistake. The content was too granular to justify nested heading levels. The fix was almost always to convert those deep headings into bullet points or a list structure instead. One edge case I ran into repeatedly involved long-form reports where stakeholders wanted to export a table of contents automatically. The export tool broke because someone had used H3 tags for callout boxes that were not actually subsections. They were stylistic containers. The workaround I ended up using was a simple rule: if the content inside a heading-level element could be summarized in a single short phrase without losing meaning, it belongs in the heading tree. If it is more of a label or a visual flag, use a class-based span or a paragraph with strong emphasis instead. That kept our TOC generation clean across three separate reporting pipelines.

The Practical Rules No One Taught You

Start every document with a single H1. Not two, not zero. One. Search engines and most accessibility tools expect a single primary heading per page. If you are building a landing page with multiple product sections, do not give each section its own H1. Use H2s for those. The H1 is reserved for the page itself. Never skip a level. Going from H2 to H4 is a common mistake when writers get lazy or when template systems force a particular structure. It looks fine on screen. It reads like a broken outline to a parser. The fix is simple: insert the missing H3 even if it feels redundant. An empty H3 is better than a skipped level. Keywords in headings are useful but they are not magic. I once worked on a rewrite where the original team had stuffed H2s with every variation of a target keyword. "Best running shoes for men 2024" followed by "Top rated running shoes for men 2024" and "Men running shoes best 2024 edition." Google does not penalize this outright anymore. But it makes the content harder for a human to scan. More importantly, it does not move the needle the way people think it does. Headings are for structure and readability first. Keyword alignment is secondary.

Another thing people miss is that headings should function as a standalone summary. If someone reads only your H2s and H3s, they should understand the shape of the entire piece. I test this myself on every long document I write. I strip out all body copy and leave only the headings. If the resulting outline is gibberish, the headings need work. This usually takes about five minutes and catches issues that would otherwise require a full edit pass.

Common Pitfalls and Where the Method Breaks Down

Heading management falls apart completely in environments where multiple contributors use different tools. A Markdown file converted to HTML may render headings differently than a Word document exported to the same format. I have seen this cause duplicate H1s on every page of a converted site because the tool added its own title element on top of the author's existing H1. The solution was to strip the author H1s during export and let the template inject a single H1 dynamically. That is a pipeline decision, not a writing decision, but writers need to know it exists. Accessibility testing tools also have limits. Many automated checkers will flag a missing H1 or a skipped level, but they will not catch heading content that is meaningless. "Introduction," "Overview," "Additional Information" — these are technically valid headings. They are also virtually useless. A screen reader user navigating by heading lands on each one and hears nothing informative. Spend more time on heading text than most people do. Every heading should be specific enough to stand alone. For sites that rely heavily on dynamic content generation, like news aggregators or product listings, maintaining proper heading hierarchy becomes significantly harder. The templates often cannot predict how many subsections a given item will have. In those cases, I recommend a fallback strategy: use a consistent H2 pattern for the main categories and let H3 handle whatever depth the content demands, but validate the output structure programmatically before it goes live. Even a simple script that scans the DOM and flags skipped levels caught about 80 percent of the heading issues we had in production. The remaining 20 percent required manual review of individual pages, but the volume dropped from hundreds per week to maybe six or eight.

Bottom line: headings are a structural system, not a decoration. Treat them like one and you save yourself a lot of downstream pain.