A how-to page answers a question with a sequence, and a sequence is fragile. Lose the order and the answer is wrong. Lose the step boundaries and three actions merge into one. Lose the prerequisite and step one fails for half the readers. A how-to that reads well on screen can come out of an extractor as a paragraph of instructions with no numbers. Or it comes out as one step lifted on its own that says “Repeat the above for each user.”
This post covers how to build procedures that keep their shape: ordered lists in the markup, one action per step, prerequisites before the first step, an outcome after each one, and steps that make sense when read alone. It also covers what happened to HowTo rich results, because that changes the case for the markup. It sits under Answer Engine Optimization: a page-level guide.
Why do procedures break in extraction?
Procedures break because their structure is usually carried by styling, not markup, and extraction keeps the text and discards the styling. Four patterns cause most of the damage:
| Pattern | On screen | After extraction |
|---|---|---|
Steps as styled paragraphs or <div>s with CSS counters | Numbered steps | Unnumbered paragraphs; the numbers were never text |
Steps as <h3>s with prose under each | Clear stages | Headings and prose, with no signal that order matters |
| Steps in tabs or accordions loaded on click | A tidy stepper | Only the first step, or nothing, in the raw HTML |
| Steps as screenshots | Visual instructions | An image with, at best, alt text |
The third and fourth decide whether the steps exist in the response at all. Check them first. JavaScript content and what never makes the trip covers the general case of content loaded on interaction.
Why must steps be an ordered list?
Steps must be an <ol> because that is the only markup whose defined meaning is “these items are in an order that matters.” The HTML standard says the ol element “represents a list of items, where the items have been intentionally ordered, such that changing the order would change the meaning of the document,” and the ul element is the case “where the order of the items is not important” (WHATWG HTML). Anything that converts HTML to text or Markdown can preserve that distinction, because it is in the document. A CSS counter is not.
Tables and lists that survive extraction covers list markup in general. For procedures, four details matter:
- Numbers come from the
<ol>, not from the text. Don’t type “1.” into an<li>inside an<ol>. A converter that numbers the list itself will print the number twice. - Sub-steps nest inside their parent
<li>as their own<ol>, not as a separate list after it. - A procedure split by a note or image continues its numbering with
<ol start="4">rather than restarting at 1. - Headed steps can stay headed. If each step needs a heading and several paragraphs, use an
<h3>per step and put the step number in the heading text (“Step 3: Configure the webhook”). The order is then in the words, where it survives.
What makes a good step?
A good step is one action, stated as an instruction, that a reader can complete and confirm before moving on. Most broken procedures fail on the “one action” part.
One action per step. “Open Settings, choose Integrations, and paste the key into the API field” is three steps. Merged, they are harder to follow and harder to lift. A question like “where do I paste the API key?” is answered by the third clause of a sentence whose first two clauses are about something else.
Start with the verb. “Click Save,” “Run the importer,” “Set the timeout to 30 seconds.” The instruction is the first word, so a reader skimming the list, or a system lifting a single step, gets the action immediately.
Name things exactly. Use the label the interface shows, in the same case, and format it consistently. “Click Save changes” beats “save your work.” Exact labels are what make a step usable without a screenshot.
Put conditions before the action. “If you use SSO, skip to step 6” belongs at the start of the step, not after an instruction the SSO user has already followed.
State the outcome. End the step with what the reader should see: “The status changes to Connected.” The outcome lets a reader confirm the step worked. It also makes the step a complete unit (action plus result) when it travels without its neighbors.
What goes before step one?
Before step one goes a short answer, the prerequisites, and the end state, in that order.
- The answer. One or two sentences that state what the procedure does and roughly what it involves: “To connect Acme to your CRM, create an API key in Acme, then paste it into the CRM’s integration settings. It takes about five minutes” (a fictional example). That is the passage most likely to be lifted when the question is “how do I connect X to Y?”, so it should be complete on its own. The 40–60 word answer block covers how to write it.
- Prerequisites as a list. Accounts, permissions, versions, and anything to have open. “You need admin access to both accounts” stated up front prevents the failure at step 4 that the reader can’t recover from.
- The end state. What will be true when they finish. This is the reader’s check that they are on the right page.
Use a question heading for the procedure itself, such as “How do I connect Acme to a CRM?”, so that the heading names the task the list completes. Question headings vs. keyword headings covers why.
Can a single step stand alone?
A step should make sense if it is the only thing a reader sees, because sometimes it will be. Retrieval systems split pages into passages, and a long procedure can be split mid-list. Chunking: why passages have to stand alone covers how that happens. The steps that fail are the ones that lean on their neighbors:
| Leans on context | Stands alone |
|---|---|
| Repeat the above for each user. | For each additional user, repeat steps 3 to 5: create a key, copy it, and paste it into that user’s profile. |
| Now paste it in. | Paste the API key into the API key field. |
| Use the same value as before. | Set Region to the region you chose in step 2. |
| Do this on the other server too. | Run the same command on the replica server. |
The fix costs a few words per step, and it also helps the reader who scrolled back up and lost their place.
Is HowTo markup still worth adding?
HowTo markup no longer produces a rich result in Google Search, so any case for it has to rest on describing the content, not on a search feature. Google limited How-to rich results to desktop in August 2023, then on 13 September 2023 stopped showing them on desktop too, “which means this result type is now deprecated” (Google Search Central). Its changelog records that the How-to documentation was removed “as this rich result is no longer shown in search results, on both desktop and mobile devices” (Google Search Central).
Google is equally clear that AI features need no special markup. Its AI features page says “there’s also no special schema.org structured data that you need to add” to appear in AI Overviews or AI Mode (Google Search Central). No other answer engine documents using HowTo.
So the honest position is this: HowTo is still a valid schema.org type that describes a procedure, its steps, its tools, and its time in machine-readable form. If your CMS emits it accurately from the same content the reader sees, leave it. If it would take engineering time, spend that time on the <ol> and the step wording first. Those reach every reader, and the markup reaches whoever chooses to read it. The schema stack that matters for AEO and GEO puts HowTo in context with the other types.
How do you check procedures across a site?
Without a terminal, a crawler’s custom extraction finds the procedures that aren’t built as lists. Add rules scoped to your main content element:
- Ordered lists:
count(//main//ol). - List items in ordered lists:
count(//main//ol/li). - Step-like headings or paragraphs:
count(//main//*[self::h2 or self::h3 or self::h4 or self::p][starts-with(normalize-space(), 'Step ')]). - Images inside list items:
count(//main//ol/li//img), a rough flag for screenshot-led steps.
Export to a spreadsheet. With step-like elements in C and ordered lists in D, =AND(C2>0, D2=0) flags pages that talk in steps but have no ordered list. Those are the pages to rebuild first. For docs sites, filter to the URL paths where procedures live, such as /docs/, /help/, and /guides/. AEO for documentation sites covers that template in more depth.
By hand, for one page: open view-source: and search for <ol. Then open the page with JavaScript disabled and confirm every step is visible without a click.
In a terminal, the same first check for one URL:
curl -s "$URL" | grep -c '<ol'
curl -s "$URL" | grep -oiE '>\s*Step [0-9]+' | wc -lA page with a step count above zero and no <ol> is the same finding as in the spreadsheet.
GEOBee’s AEO lens scores lists and tables as their own signal (10 of 100), and counts HowTo among the answer-relevant schema types it detects (the three lenses lists both weights). It sees whether a page has real lists. It can’t judge whether each step is one action or whether step 7 makes sense on its own. That is a reading job, and the table above is the checklist for it.
To find the pages on your site that carry procedures without real list markup, download GEOBee and crawl your help and docs sections.