Review article headings as a usable outline

Read the outline without the body

The deliverable lists the current heading, problem, proposed wording and review result. Temporarily hide the body and ask whether the outline explains the task and sequence. Repeated labels such as features, tips and summary give little help to someone looking for a specific condition.

Prefer a label that identifies the work, such as checking duplicate IDs before importing a CSV. Keep it compact enough to scan. A heading should guide the reader to the explanation, not carry every qualification that belongs in the following paragraphs.

Separate visual styling from document structure

Large or bold text is not necessarily a semantic heading. Conversely, making every note a heading can turn the outline into an unhelpful list of fragments. Compare actual heading elements, their rendered appearance and the generated table of contents.

Sections at the same level should represent comparable units. Avoid placing a broad chapter beside a very narrow sub-step as though they were peers. Check wrapping at a small width, but do not force a one-line appearance by shrinking the text until it becomes difficult to read.

Check the promise of each section

Extract the outline and inspect what each section actually contains: purpose, prerequisite, action or decision. A section named “calculate the cost” should explain a calculation, not merely show a price list. Add the missing worked example or rename the section truthfully. Check for empty headings as well.

When neighbouring headings sound similar, establish their distinction. Merge overlapping material where appropriate. If the sections are genuinely different, make the distinction visible through timing or purpose, such as checks before registration versus checks after publication.

Example: revising an integration guide outline

Consider a fictional guide with the headings Preparation, Setup, Check and Caution. Its actual sections cover required columns, field mapping, duplicate creation and retry after failure. Replace the vague labels with those concrete subjects.

Also confirm the order: prerequisites come before mapping, then a trial and its acceptance checks. If the site derives anchor IDs from heading text, renaming may change section addresses. Recheck the table of contents and any important saved section links rather than assuming the text edit affects only appearance.

Test navigation after the revision

Before release, use every table-of-contents link and confirm that the intended heading remains visible. Check fixed-header overlap, duplicate IDs and language variants that lead to the wrong section. These are navigation failures, not editorial wording problems, but readers experience them together.

At a phone width, inspect long labels and wrapping in both the outline and body. Clear structure still needs readable contrast. Review headings, body and links, and separately check any text positioned over an image where the background may change legibility.

Evaluate usefulness rather than a heading quota

You can begin by comparing the outline with the text without another subscription. If extracting headings across the site with Screaming Frog, do not judge quality solely by tag counts or character length. Read representative articles and test whether the labels help locate actual answers.

There is no guaranteed ranking improvement from reaching a particular heading count. Separate extraction work from editorial review and prioritise important entry pages or long procedures. Acceptance means readers can find the relevant section and receive the explanation that its heading promises.

• Write an evidence-led SEO article brief that an editor can verify
• Internal-link audits: broken paths, isolated pages and irrelevant recommendations
• SEO release acceptance: URLs, exclusion rules and language versions