Writing clear explanations
Order the explanation around what the reader needs next.
Headings identify the job of each content block. Content order connects those jobs so readers encounter definitions, conditions, evidence and decisions when they need them. Use a hierarchy that reflects the explanation, not a prescribed number or pattern of headings.
Free learning from Semantec SEO.
Start with the task and its dependencies.
Write down what the reader should be able to understand or decide after the page. Then list the questions that stand between the reader and that outcome. A topic list names subjects; an ordered explanation also states why each subject appears and what the reader needs before reaching it.
A dependency is information needed to interpret a later block. A comparison may depend on definitions of its criteria. A process may depend on a permission check. An exception may change the meaning of the default rule, so leaving it until after an apparently unconditional instruction can mislead the reader.
This is not an instruction to put every basic concept first. An experienced reader may already know them. Provide a short orientation or a link when that is enough. Bring necessary context into the page when the central explanation would otherwise depend on knowledge the intended audience is unlikely to have.
For each planned block, record its reader question, role, dependency, evidence and next route. These fields preserve the reasoning behind the sequence and help an editor distinguish useful depth from a collection of adjacent topics.
Make the heading hierarchy reflect the content.
The page title names the page’s task. Major headings introduce the main parts of that task. A subheading belongs inside the part it develops. If two headings sit at the same level, their relationship should make sense as peers rather than one quietly containing the other.
Choose heading elements for structure rather than their default visual size. Styling can change presentation; the markup should preserve the relationships. WCAG 2.2 addresses programmatically available information and relationships, meaningful sequence, and headings that describe topic or purpose. A heading outline is one useful inspection, not a complete accessibility audit.
Google’s introductory SEO documentation encourages readable organization and headings that help navigation. It also says there is no ideal quantity of headings for every page. Do not invent a rule requiring a fixed number of H2 elements, a question in every heading or a keyword in every subheading.
A heading should let a reader predict the block beneath it. “Check the input before conversion” is more informative than “Getting started” when the block concerns prerequisites. Avoid labels so broad that every part of the page could sit beneath them.
Give each block a distinct job.
A definition establishes meaning and boundaries. A process explains actions in order. A comparison holds criteria consistent across options. Evidence supports a claim. An example demonstrates application. An exception changes the default case. A next route sends the reader to a distinct task that the current page does not own.
One block can perform closely related jobs, but the relationship must remain clear. A definition followed by a short example can work well. A paragraph that defines a term, recommends a product, introduces a different topic and asks for a purchase often has too many competing purposes.
Repetition is not always duplication. Restating a qualification beside a decision may be necessary. Repeating the same setup beneath three headings usually is not. Review the information added by each block and preserve the qualification while removing repeated introduction.
Worked example: reorder a resource about file formats.
This is an invented editorial exercise. The resource helps a beginner decide how to present a small tabular dataset for another person. It is not a specification for a particular software product, and any compatibility claim in a real page would need the relevant product documentation.
The weak order is: export troubleshooting; history of data files; a recommendation to use CSV; a definition of columns and rows; a discussion of recipient requirements; then a warning that the intended recipient may need formatting the chosen file cannot retain. The recommendation arrives before the criterion that could overturn it.
A better order begins with the decision: choose a format that preserves the information the recipient needs and can open. Next explain the relevant terms, then identify required information, then compare appropriate options using those criteria. A worked example demonstrates the choice. Limits and troubleshooting follow where their prerequisites have been introduced.
The change is not “definitions always come first.” The opening gives a useful answer before the detailed terms. The terms are introduced only as far as the following comparison needs them. If the audience already knows those terms, the explanation can be shorter or linked to a separate introduction.
The reordered plan below records the reason for every move. It makes the recommendation conditional on the recipient’s needs rather than treating an export format as universally correct.
Check the worked example.
| Position | Block job | Dependency or reason |
|---|---|---|
| Opening | State the decision and scope | Recipient needs control the choice |
| Terms | Explain only the concepts used next | Reader can interpret the criteria |
| Criteria | Identify information that must survive | Comparison now has a basis |
| Comparison | Check options against the same criteria | Unknown compatibility stays unknown |
| Example | Apply the criteria to a fictional case | Shows the decision rather than repeating terms |
| Limits and route | Explain exceptions and further work | Does not hide a prerequisite after the action |
Use transitions to explain relationships.
A useful transition tells the reader why the next block follows. “Now that the recipient’s required information is clear, compare the formats against it” carries a logical dependency. A decorative phrase that merely announces another topic does not establish a relationship.
Use the correct relationship: an example illustrates; evidence supports; a contrast distinguishes; a condition limits; a consequence follows only when the cause is supported. Do not assert that one event causes another when the preceding passage has not established that relationship.
A transition cannot repair a missing explanation. If the move from a definition to an action step feels abrupt, check for a missing prerequisite or decision criterion. Adding a smoother sentence may conceal the gap without resolving it.
Keep entity references stable across the boundary. If the preceding block discusses both an input file and an output file, name the file meant by “it” in the next block. The first sentence beneath a heading should remain understandable with that heading and the local context.
Handle alternative routes without breaking the order.
A resource can serve more than one starting state. Provide descriptive local navigation or a short route sentence when readers may need different parts. Keep the explanation’s main sequence intact for readers following it from the beginning.
A block of questions and answers does not automatically belong at the end. Place a question near the decision it resolves when moving it later would leave the main explanation incomplete. Reserve a separate collection for genuinely related follow-up questions rather than using it as a place to hide prerequisites.
For a comparison, explain the criteria before the verdict, or place them beside the comparison when that is clearer. For a process, state the stop condition before the action it blocks. For a troubleshooting page, the symptom may come first and background can follow after the diagnostic route.
Read the heading outline without the paragraphs, then read the page without the headings. The outline should show progression; the prose should still establish the relationships. Check the rendered reading order, keyboard route and narrow layout as separate reviews. Passing an editorial outline review does not prove those interface checks.
Sources and the next writing decision.
Read Google’s introductory SEO documentation and WCAG 2.2. The worked examples and review records are Semantec SEO teaching material. They do not report a client outcome, live experiment or measured search effect.
Continue with passage context and reference clarity. Return to the writing and content composition overview or the semantic SEO learning overview.