HowTo schema

What HowTo markup actually describes

A HowTo object in the Schema.org vocabulary describes a procedure that produces a result. Not a list of tips, not a buyer guide with numbered subheadings, a task with a defined end state. The type carries a name, a description, an optional totalTime expressed as an ISO 8601 duration, an estimatedCost, and above all an itemListElement array holding the ordered steps. Each entry in that array is a HowToStep with its own name, its text, a url that should point at the anchor of that step on the page rather than at the page root, and an image when the step is genuinely visual.

Below the step level the vocabulary gets more precise than most implementations bother with. A HowToStep can itself carry an itemListElement of HowToDirection objects, each one an atomic instruction, and HowToTip objects, which is advice a reader can skip and still finish the task. HowToSupply and HowToTool separate consumables from instruments, which matters for a repair guide and matters not at all for a software tutorial. HowToSection groups steps into phases when a procedure runs long enough that a flat list of twenty steps would be unreadable. That nesting is the only part of HowTo that requires real thought, and it is the part almost every implementation skips.

Two serialisation formats exist. The first is JSON-LD in a script block in the head or body, which keeps the data in one place and survives template refactors. The second is microdata, where itemtype declares the object on a container element and every itemprop attribute binds a fragment of visible HTML to a property. Microdata is what a large share of older WordPress themes still emit, and it is the reason so many procedural pages carry markup nobody has looked at since 2019: an itemprop binding breaks silently the day a designer moves a div. If you are still maintaining microdata on instructional content, migrating to a single JSON-LD block per page is the cheapest structured-data win available.

HowTo is also routinely confused with three neighbours. Recipe is not a HowTo subtype dressed differently, it has its own required properties and, unlike HowTo, still produces a Google rich result. FAQPage markup answers questions and does not model an order of operations. ItemList is what a ranked listicle actually needs. Marking up a listicle as HowTo because the H2 headings happen to be numbered is the single most common misuse of the type, and it makes the page misdescribe itself to every machine that reads it.

2026 status: valid vocabulary, dead SERP feature

The timeline matters because it determines how you should talk about HowTo in a client audit. Google removed HowTo rich results from mobile results in August 2023 and from desktop in September 2023. The vocabulary stayed valid at Schema.org, the feature simply stopped rendering. Then in May 2026 Google removed the How-to structured data documentation and its case study from Search Central entirely, on the stated grounds that the feature is no longer shown on either desktop or mobile Search (Google Search Central documentation updates, May 2026). There is no Search Console enhancement report for it, no Rich Results Test coverage, and no ranking effect.

That deletion did not happen in isolation. On 5 November 2025 Google announced it was simplifying the search results and would drop support for a set of structured-data types from Search Console and its API starting in January 2026, naming Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement, Vehicle Listing and Practice Problem, with low usage or insufficient user value as the rationale. Then Google removed FAQ rich results across Search on 7 May 2026, with Search Console and Rich Results Test support scheduled to follow in June and API support in August. Read together, the direction is unambiguous: Google is retreating from instructional and question-shaped SERP embellishments, and HowTo was simply first in that queue.

The stance that follows is blunt. In 2026, adding HowTo JSON-LD in order to obtain a Google rich result is indefensible, and any agency still selling it on that basis is selling a feature that has not existed for close to three years. The corollary is just as important for audit hygiene: deprecated markup is ignored, not penalised. When a site lost its HowTo rich result, it did not lose rank. If a traffic decline coincides with a deprecation date, the deprecation is not the cause, and writing it into a report as an algorithmic hit sends the client chasing a phantom while the actual problem stays open.

Does schema move AI citations? The data says barely

The fallback pitch for structured data since 2024 has been that even if Google stopped rendering the feature, machines still parse it, so schema buys visibility in generative surfaces. That claim now has data against it. Ahrefs published a matched study on 9 June 2026 tracking 1,885 pages that added JSON-LD between August 2025 and March 2026 against 4,000 control pages, measured across AI Overviews, AI Mode and ChatGPT. Adding schema produced no major citation uplift, and AI Overview citations actually fell 4.6% relative to controls, though the authors note those pages were already on a downward citation trend.

The counter-evidence is thinner than the hype suggests. Search Engine Land ran a controlled experiment reported on 23 September 2025 with three substantially similar pages, in which only the page with well-implemented schema surfaced in an AI Overview and ranked for six keywords, reaching position 3. That is suggestive, and it tests schema quality in general rather than HowTo specifically, on a sample too small to generalise. Meanwhile Google's own May 2026 generative-AI optimisation guidance states plainly that no special Schema.org markup is required for its generative features, and points instead at clear headings, sectioned content, unique material and crawlable pages.

What does correlate with citation is coverage. Ahrefs research in 2026 found that pages ranking for related follow-up queries were 161% more likely to be cited than pages ranking only for the primary query, with a reported Spearman correlation of 0.77. That points every procedural page at the same job: answer the whole task including prerequisites, alternatives, failure modes and the questions that come after, which is exactly what the way modern engines expand a single query into a bundle of sub-queries rewards. The markup describes the page. It does not make the page more complete.

Where HowTo still earns its keep

Three situations still justify the maintenance cost. The first is a non-Google consumer that actually reads your JSON-LD: an internal knowledge graph, a documentation pipeline that syndicates procedures to a help centre or an in-product assistant, a partner feed, or a support bot fed from crawled structured data. If you can name the parser, keep the markup. If you cannot name it, you are maintaining decoration.

The second is discipline. Writing valid HowTo forces the page to admit whether it is really a procedure. If you cannot fill totalTime, cannot list a supply or a tool, and cannot phrase step three as an instruction rather than a paragraph of context, the page is a guide pretending to be a tutorial. That diagnostic is worth something even if you never publish the resulting markup, and it is a faster structural audit than reading the copy end to end.

The third is the linking angle, and it needs stating clearly because it is where the most money gets wasted. Markup does not create backlinks and does not transfer authority. A procedural page earns links when it contains something nobody else has: original screenshots, a tested measurement, a teardown, a failure the author actually hit. Across the French editorial media Nautilinks runs in-house, the instructional pieces that attract editorial coverage are always the ones with first-hand material, never the ones with the tidiest structured data. Treat a HowTo page as a linkable asset and promote it as one, then decide separately what an editorial placement is actually worth paying for. Schema is the label on the box, not the contents.

What we see go wrong in audits

The failure that matters most is markup that disagrees with the visible page. Steps present in the itemListElement but absent from the HTML, step text rewritten to read better in the markup than on the page, an image property pointing at a stock asset the reader never sees. Google's guidance on content matching markup has never changed, and even for a deprecated type, an entity graph that contradicts the rendered page is a liability for every other machine reading the site.

Then come the mechanical faults. A HowTo applied to a listicle or a product page where ItemList or Product belongs. Steps with a name and no text, or a text field carrying raw HTML including anchors and list tags. The url property on every step pointing at the page root, which makes the property useless since its entire purpose is deep-linking into the procedure. Images passed as a bare string when an ImageObject with width and height is what downstream consumers can actually use. And the duplicate-entity problem: a theme emitting microdata with itemtype and itemprop attributes while an SEO plugin injects a JSON-LD block for the same page, so parsers see two HowTo objects with different step counts and no way to arbitrate.

Validation habits need updating too. The Schema Markup Validator at validator.schema.org still checks HowTo against the vocabulary and remains the right tool. The Rich Results Test no longer reports it, and reading that silence as a syntax error sends teams on a debugging hunt for a bug that does not exist. Enhancement dashboards should have had their HowTo monitoring stripped out in 2023. Finally, plugin capability is not platform support: 2026 third-party pricing reports list Rank Math exposing HowTo among roughly 18 schema types on its free WordPress tier, with Pro around €7.99 per month billed annually. Buying a licence for HowTo output specifically buys nothing Google will render.

The 2026 playbook for procedural pages

Keep HowTo where a genuine procedure exists and a named consumer parses it. Everywhere else, ship Article plus BreadcrumbList and Organization, which is the boring stack that still maps to live features, and spend the saved effort on the page itself. That means descriptive headings that match how people phrase the sub-tasks, an explicit prerequisites block, a troubleshooting section covering what goes wrong at each stage, alternatives when the main method does not apply, and internal links to the adjacent procedures so the cluster reads as a whole rather than a set of orphans.

Measure it through query coverage in Search Console rather than through enhancement reports that no longer exist: count how many distinct sub-queries the page ranks for over a quarter, not just the head term. That number is the one the fan-out research ties to citation, and it moves when you extend the page, not when you extend the JSON-LD. And when a procedural asset is good enough that other publishers would reference it, put it in front of them rather than waiting: whether you handle that yourself or work from a catalogue of media you can browse before committing to anything, the acquisition work is what turns a well-structured page into a page with authority. Structured data has never done that job and, on the current evidence, is not about to start.