Should you still implement HowTo schema in 2026?

HowTo schema is still valid, still parsed by validators, and still worth adding in specific cases, but it will not earn you a rich result on Google Search. Google deprecated HowTo rich results in August 2023, first for mobile, then for desktop. The type remains on Schema with its full property set intact, and it still gets read by machine consumers that never touched Google's old SERP feature in the first place.

The minimum viable version looks like this:

```json
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "How to change a bicycle tyre",
"step": [
{ "@type": "HowToStep", "text": "Remove the wheel from the frame." },
{ "@type": "HowToStep", "text": "Lever the tyre off the rim." }
]
}
```

That is the whole required footprint: name and step. Anything beyond it is decoration, useful decoration in the right context, but decoration all the same.

• Keep HowTo markup only if it feeds a machine consumer that still values it, such as an AI answer engine, a voice assistant, or your own CMS's internal content model.
• Migrate to Article, TechArticle, or Recipe if the page was only ever using HowTo to chase Google's old visual snippet.
• Treat the decision as cost-based: if maintaining the markup costs you nothing and something downstream still reads it, there is no reason to rip it out.

Key takeaways

HowTo schema still works as valid structured data, but its value now lies in serving AI and voice consumers rather than earning a Google rich result.

Table of Contents

• What is HowTo schema and when should you use it?
• Which HowTo properties are required, and which are worth adding?
• How do HowToStep, HowToSection, HowToDirection, HowToTip, HowToSupply and HowToTool differ?
• What are the correct formats for time and cost in HowTo schema?
• What do working JSON-LD examples for HowTo schema look like?
• How should you test and validate HowTo markup?
• What are the most common HowTo schema mistakes?
• HowTo versus FAQPage versus Recipe: which type fits your content?
• Should you keep, replace, or remove your HowTo markup now?
• Cited's view on structured data as a long-term investment
• Get a free AI visibility audit before you touch your schema
• Sources
• FAQ

What is HowTo schema and when should you use it?

HowTo is a Schema.org type built to describe an ordered set of instructions, a sequence where the order of steps genuinely matters to completing a task. It is not a generic label for "content with steps in it". It is a data structure for procedures: assemble this, repair that, configure the other, in a specific order that changes the outcome if you skip it.

Several consumers still make good use of it even without Google's rich result:

• AI answer engines and large language models that crawl your page and need a clean, structured breakdown of a process rather than a wall of prose.
• Voice assistants that read out steps sequentially and rely on discrete, ordered objects rather than parsing free text.
• Search engines and directories outside Google's ecosystem that have not made the same eligibility change.
• Your own CMS or internal tooling, where consistent HowTo objects across hundreds of tutorial pages make bulk editing, auditing, and syndication far easier.

Not every set of instructions belongs under HowTo, though. If the content is a long-form technical explainer with steps embedded as one part of a bigger argument, TechArticle fits better, think of a deep dive on configuring a Kubernetes cluster where the steps sit inside broader architectural reasoning. If it is a general narrative piece with some sequential elements, plain Article usually captures it more honestly. And if you are describing food preparation, Recipe is the correct type outright: it remains eligible for genuine rich result features, which HowTo no longer is.

Which HowTo properties are required, and which are worth adding?

Only two properties are mandatory: name and step. Everything else is optional, but several optional properties carry real semantic weight, particularly for the AI consumers that now form HowTo's main audience.

A checklist for prioritising your effort:

• Minimum viable markup: name plus a complete step array with meaningful text on every entry.
• Higher-value additions for AI and Discover-style consumers: image, totalTime, supply, and tool.
• Nice-to-have polish: estimatedCost, yield, @id, and mainEntityOfPage, worth adding once the core is solid, particularly on pages with several interlinked schema objects.

How do HowToStep, HowToSection, HowToDirection, HowToTip, HowToSupply and HowToTool differ?

HowToStep is the workhorse. It sits inside the step array and holds one discrete action. Schema.org's own documentation allows nested itemListElement entries inside a step, which is how you handle a step with several small sub-actions without inventing your own structure.

HowToSection groups related steps under a shared heading, useful when a procedure has distinct phases, "Preparation," "Assembly," "Finishing," for example. Use sections only when the visible page genuinely presents those phase headings; grouping steps in your JSON-LD that do not correspond to anything on the page creates a mismatch that undermines the markup's fidelity.

HowToDirection and HowToTip sit inside itemListElement as supplementary text: a direction is guidance for the step itself, a tip is optional advice that improves the outcome but is not strictly necessary. Neither should replace the main text field on a step; they supplement it.

HowToSupply and HowToTool are often confused, so keep the distinction simple: supplies are consumed (screws, paint, flour), tools are reused (a screwdriver, a paintbrush, a mixing bowl). Get this wrong and you are not just being pedantic with vocabulary, you are giving machine readers false information about what the reader needs to buy versus what they already own.

Here is a snippet showing valid nesting:

```json
{
"@type": "HowToStep",
"name": "Prepare the surface",
"itemListElement": [
{ "@type": "HowToDirection", "text": "Sand until smooth." },
{ "@type": "HowToTip", "text": "Work with the grain to avoid scratches." }
]
}
```

Pro Tip: If you want to deep-link directly to a specific step, add a url property pointing to that step's anchor on the page, rather than repeating the step's full text in both the visible page and a duplicate description field. Omit the parent name on a step when its purpose is entirely explained by the text field, adding both risks two slightly different descriptions of the same action, which is exactly the kind of ambiguity that erodes trust in the markup.

What are the correct formats for time and cost in HowTo schema?

Time properties must use ISO 8601 duration syntax, not plain-text descriptions. PT30M means 30 minutes, PT1H30M means one hour and 30 minutes, and this format applies consistently across ISO 8601's duration standard. Writing "30 minutes" as a string value for totalTime is a common error, and it fails validation because the property expects a Duration type, not free text.

Cost fields work differently. estimatedCost expects a MonetaryAmount object with a currency and a value, structured like this:

```json
{
"@type": "MonetaryAmount",
"currency": "GBP",
"value": "25.00"
}
```

Plain text is acceptable here only when you genuinely cannot express a fixed figure, "varies by supplier," for instance, though a proper MonetaryAmount is always the stronger choice when you have a real number.

• totalTime, prepTime, and performTime all follow the same ISO 8601 pattern.
• Currency codes follow ISO 4217 (GBP, USD, EUR), never a currency symbol inside the currency field itself.
• Run your markup through the Schema Markup Validator to catch malformed durations or a missing MonetaryAmount structure before you publish.

What do working JSON-LD examples for HowTo schema look like?

Three tiers cover most real-world needs: minimal, intermediate, and advanced.

1. Minimal, name and step only, nothing else. This is the version shown at the top of this article and it is enough to be valid, if sparse.
2. Intermediate, adds image, totalTime, supply, and tool so AI consumers get a fuller picture of what the task involves and what it needs.
3. Advanced, introduces HowToSection for multi-phase procedures, @id for internal referencing, and mainEntityOfPage to tie the object explicitly to its host page.

Intermediate example:

```json
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "How to fix a dripping tap",
"image": "https://example.com/images/tap-repair.jpg",
"totalTime": "PT45M",
"supply": [
{ "@type": "HowToSupply", "name": "Replacement washer" }
],
"tool": [
{ "@type": "HowToTool", "name": "Adjustable spanner" }
],
"step": [
{ "@type": "HowToStep", "text": "Turn off the water supply." },
{ "@type": "HowToStep", "text": "Remove the tap handle and spindle." }
]
}
```

Advanced example, with sections and page-level anchoring:

```json
{
"@context": "https://schema.org",
"@type": "HowTo",
"@id": "https://example.com/guides/tap-repair#howto",
"mainEntityOfPage": "https://example.com/guides/tap-repair",
"name": "How to fix a dripping tap",
"step": [
{
"@type": "HowToSection",
"name": "Preparation",
"itemListElement": [
{ "@type": "HowToStep", "url": "https://example.com/guides/tap-repair#step1", "text": "Turn off the water supply." }
]
},
{
"@type": "HowToSection",
"name": "Repair",
"itemListElement": [
{ "@type": "HowToStep", "url": "https://example.com/guides/tap-repair#step2", "text": "Remove the tap handle and spindle." }
]
}
]
}
```

• Place the <script type="application/ld+json"> block in the page <head> or just before the closing </body> tag, either works, consistency across your templates matters more than the exact location.
• Every HowToSection name must correspond to an actual visible heading on the page. Inventing sections that do not appear on-screen creates a mismatch between markup and content that Google's guidelines explicitly discourage.
• If you're restructuring headings anyway, this is a natural point to review your content structure for AI search, since clean H2/H3 step headings do most of the same job as HowTo markup for human readers and many machine consumers alike.

How should you test and validate HowTo markup?

Run through this sequence, in order:

1. Preview the rendered page locally and confirm every heading in your JSON-LD matches something visible on screen.
2. Paste the JSON-LD into the Schema Markup Validator to catch vocabulary errors, wrong types, and malformed durations.
3. Check the live, fetched version of the page (not just your local copy) since client-side rendering can silently drop or delay structured data.
4. Inspect the URL in Google Search Console to confirm Google is reading the markup at all, even though it will not report HowTo eligibility any more.

Two tools do genuinely different jobs, and confusing them is the single most common mistake teams make here. The Schema Markup Validator checks whether your JSON-LD is syntactically valid schema.org vocabulary, nothing more. It will happily pass a HowTo block even though Google's Rich Results Test no longer reports HowTo eligibility at all, because that test now only reports on rich-result types Google still supports. A green pass from the validator tells you your JSON-LD is well-formed. It tells you nothing about whether Google will do anything visible with it.

• Schema Markup Validator, vocabulary and syntax correctness only.
• Rich Results Test, checks Google-specific rich result eligibility, HowTo no longer appears in its output.
• Search Console URL inspection, confirms what Google actually crawled and parsed on a live page.
• If your site relies on client-side rendering, review how cookie consent and rendering delays affect what Google actually sees before assuming a validation failure is a markup problem rather than a rendering one.

For a broader read on whether structured data still moves the needle for AI citation specifically, Cited's own analysis of schema markup and AI search is worth a look before you invest heavily in any one type.

What are the most common HowTo schema mistakes?

Most HowTo errors fall into a handful of repeatable categories, and nearly all of them come down to the markup drifting away from what the page actually shows.

• Markup that lists steps or sections the visible page does not contain, or in a different order than what readers see.
• A single HowToStep crammed with two or three distinct actions instead of being split into separate steps.
• Plain-text time values ("about half an hour") where totalTime needs a proper ISO 8601 duration.
• Using Recipe for a non-food process to try to preserve rich-result eligibility, or using FAQPage markup on content that is not genuinely a discrete question-and-answer format.

Here is a broken instance, followed by its fix.

Before (broken): a totalTime of "30 minutes" and one step covering three actions at once ("Remove the wheel, lever off the tyre, and check the tube for damage").

After (corrected):

```json
{
"totalTime": "PT30M",
"step": [
{ "@type": "HowToStep", "text": "Remove the wheel from the frame." },
{ "@type": "HowToStep", "text": "Lever the tyre off the rim." },
{ "@type": "HowToStep", "text": "Check the inner tube for damage." }
]
}
```

If you spot markup with sections that do not exist on the page, steps in a different order than the visible content, or a duration field holding a string instead of an ISO value, treat it as a red flag worth a full audit rather than a quick patch. Google's structured data guidelines require markup to describe visible content using the most specific applicable type, and repeated mismatches on a domain can affect how much trust crawlers place in your structured data generally.

HowTo versus FAQPage versus Recipe: which type fits your content?

The type you choose should follow the shape of the content, not the rich result you wish you still had.

• HowTo fits content where order genuinely matters, a sequence that produces a specific outcome only if followed in sequence.
• FAQPage fits discrete question-and-answer pairs where order between questions is largely irrelevant.
• Recipe fits food preparation specifically, and it remains eligible for visible search enhancements that HowTo has lost.
• TechArticle fits long technical tutorials where steps exist within a broader explanatory argument rather than as the entire point of the page.

Combining types on one page is entirely acceptable, provided they describe genuinely different entities. A tutorial page might carry an Article object describing the piece as a whole, with a separate FAQPage object for a troubleshooting section at the bottom, each as its own JSON-LD block rather than nested awkwardly into one object. What matters is that each type earns its place: don't add FAQPage to a page with two questions just to add another schema type, and don't force Recipe onto a DIY guide that has nothing to do with food just because it once carried a HowTo rich result.

Should you keep, replace, or remove your HowTo markup now?

Run three questions against every page currently carrying HowTo markup:

1. Does anything other than Google's old rich result actually consume this markup, an AI answer engine, a voice assistant, your internal CMS logic?
2. Is the ongoing cost of maintaining it close to zero, or does keeping it in sync with page edits create real friction for your team?
3. Did this page previously earn HowTo impressions in Search Console that have since vanished, or was it never a meaningful traffic driver in the first place?

Three outcomes follow from those answers:

• Keep and maintain it if a genuine machine consumer still benefits and upkeep costs you little. Treat it the same as any other structured data, review it whenever the page content changes.
• Replace it with Article or TechArticle JSON-LD if the only reason it existed was chasing Google's old visual snippet. Keep clear H2/H3 headings per step on the page itself; that structure alone still supports featured snippets and general readability, regardless of which schema type sits behind it.
• Remove it entirely, and confirm no orphaned microdata or legacy JSON-LD fragments remain in your templates, if the page never performed and nothing currently reads the markup.

If you are unsure which category a given page falls into, a free audit will map exactly which structured data your site is running and flag where it is doing nothing useful.

Cited's view on structured data as a long-term investment

The mistake we see most often is teams treating schema markup as a one-off task rather than infrastructure that needs periodic review. HowTo is a clean example: it was worth implementing broadly in 2022, it needs deliberate pruning and redirection in 2026, and the type will keep evolving as AI answer engines become a larger share of how content actually gets discovered. Technical teams who audit their structured data annually, rather than setting it and forgetting it, are the ones who avoid carrying dead markup for years after its original purpose disappeared.

That is precisely what Cited's free audit checks: whether your existing schema, HowTo included, is still earning its keep or quietly doing nothing. You can run one at cited.best/audit, and Cited publishes deeper technical breakdowns like this one regularly on its Insights hub.

Get a free AI visibility audit before you touch your schema

Deciding whether to keep, replace, or remove HowTo markup gets a lot easier once you can see exactly how AI search engines currently read your site. Cited's free AI visibility audit checks your structured data, technical health, and authority signals across six dimensions, then tells you precisely where ChatGPT, Perplexity, Gemini, Claude, and Copilot are and are not picking you up.

If the audit flags schema issues, or gaps elsewhere in your technical setup, you have two paid routes forward: a fixed-price Technical Fixes package at £495 one-off for a defined set of repairs, or the ongoing AI Optimised service at £995 a month if you want continuous monitoring and implementation as AI search behaviour keeps shifting. Larger sites can talk through an Enterprise arrangement built around their specific scope. You can see exactly how Cited assesses a site through the audit methodology, or go straight to booking a call if you already know you need implementation help rather than another report.

Sources

• Schema
• HowTo Schema: JSON-LD Implementation Guide
• Changes to HowTo and FAQ rich results | Google Search Central Blog | Google for Developers

FAQ

What is HowTo schema?

HowTo is a Schema.org type that describes an ordered set of instructions using required name and step properties, plus optional properties like totalTime, supply, and tool for richer detail.

How do I create HowTo schema markup?

Write a JSON-LD block with @type: "HowTo", a name, and a step array of HowToStep objects, then validate the syntax with the Schema Markup Validator before publishing.

What are the four main components of HowTo schema?

The core components are HowToStep for individual actions, HowToSection for grouping steps into phases, HowToSupply for consumables, and HowToTool for reusable equipment, with HowToDirection and HowToTip available as supplementary text inside steps.

Can you give an example of HowTo schema?

A minimal example needs only name and an array of HowToStep objects with text describing each action, exactly the structure shown near the top of this article, with image, totalTime, and MonetaryAmount cost fields added as the implementation matures.

Does HowTo schema still help with SEO?

It no longer produces a Google rich result following the 2023 deprecation, but it can still improve how AI answer engines and voice assistants read your content, which a tool like Cited can help you measure directly.

Recommended

• Does schema markup actually get you cited by AI search? | Cited
• GEO vs SEO: What's the Difference? | Cited
• Book a Call | Cited | Cited
• What is Generative Engine Optimisation (GEO)? | Cited