What the HowTo Schema Validator does
This validator fetches a live URL, finds any HowTo structured data on the page, and checks that block against the rules a parser actually applies. Unlike a generator, which builds markup from fields you type, the validator works in the opposite direction: it reads the JSON-LD that is already published on your page and tells you whether it is well formed, whether its required and recommended properties are present, and whether the ordered steps inside it make sense as a real procedure. You give it the address of a tutorial or step-by-step page, and it returns a verdict on the HowTo object exactly as a machine would encounter it in the wild.
The reason a dedicated validation pass matters is that HowTo markup is easy to author incorrectly and almost impossible to eyeball once it is embedded in a page's source. A single missing brace, an at-type that is misspelled, a step array that is empty, or a totalTime written as plain English instead of a duration string can all quietly break the block, and nothing on the rendered page will warn you. This tool surfaces those problems by parsing the actual response your server returns, including any markup injected by a tag manager or a content management plugin, so what you test is what a crawler genuinely sees rather than what you hoped you published.
What the validator actually checks
The first thing it confirms is that the page contains a parseable JSON-LD script block and that the block declares an at-type of HowTo. If the JSON itself will not parse, because of a trailing comma, an unescaped quote, or a smart-quote character pasted in from a word processor, the validator stops there and reports a syntax failure, because nothing downstream can run until the document is valid JSON. Assuming it parses, the tool then walks the HowTo object and verifies the structural backbone: a name describing the overall task and a step property that is an ordered array of HowToStep items, each carrying instructional content through its text or through nested HowToDirection entries.
Beyond the bare minimum, the validator inspects the recommended properties that make a HowTo complete and trustworthy. It looks for a totalTime expressed as an ISO 8601 duration rather than a phrase like about ten minutes, for tool and supply arrays that correctly separate reusable implements from consumed materials, and for per-step images, names, and anchor URLs. It flags steps that have a heading but no instruction, steps that are empty placeholders, and a HowTo that collapses an entire procedure into one giant step instead of the discrete actions a reader follows. Each of these is something a generator would have prevented at authoring time, but a validator must catch after the fact on pages that were hand-coded or assembled by a plugin.
How to read the validation output
Read the output as a layered report. At the top you will see whether HowTo markup was found at all and whether it parsed; if either of those fails, fix that first, because every property check below depends on having a valid object to inspect. Below that you will see the required-property results, which tell you whether the name and the step array exist and whether each step carries content. A pass here means the block is technically a valid HowTo; it does not yet mean the block is good. The recommended-property results round out the picture, showing which optional but valuable fields are missing so you can decide what is worth adding.
Pay closest attention to anything the validator reports about step order and step count, because those are the failures that most damage how an answer engine reproduces your instructions. If the validator says you have four HowToStep objects but your page visibly shows five numbered steps, the markup and the content have drifted apart, and a machine reading only the markup will hand users an incomplete procedure. Treat a warning about a totalTime that is not a valid duration, or a tool that is really a supply, as a correctness issue rather than a cosmetic one, since these misdescribe the task even when the JSON technically parses.
Why HowTo validation matters in 2026
The context for HowTo has shifted, and validating it has to be understood in that light. Google deprecated the visible HowTo rich result, the expandable step carousel that once appeared in standard search, so a clean validation pass will no longer earn that classic snippet for the general web. What a valid HowTo block does earn now is reliable machine comprehension. When an AI Overview, a chatbot, or a voice assistant is asked to walk a user through the exact task your page covers, a correctly structured, ordered set of steps is far easier to lift faithfully than steps buried in prose, and a broken or contradictory HowTo block is actively misleading to those systems.
That is precisely why validation, rather than mere generation, is the relevant exercise today. Many sites added HowTo markup years ago to chase the old rich result and have not touched it since, even as the page content changed underneath it. The markup may now reference steps that were edited, removed, or reordered, leaving a stale procedure encoded in the page that any AI system will read literally. Running the validator against your existing pages tells you whether the structured data still reflects reality. Keeping it accurate is the difference between handing assistants a clean procedure to reproduce and handing them a confident, well-formed description of the wrong steps.
Common errors the validator catches
The most common failure is invalid JSON, almost always from a stray comma, an unescaped character, or curly quotes introduced when the snippet was edited in a non-code editor. The validator catches these immediately, and they are worth fixing first because they take the entire block offline for every consumer. The next tier of errors is structural: a HowTo with a name but an empty or missing step array, steps that contain no instructional text, or a procedure jammed into a single step. These pass as JSON but fail as a usable HowTo, and the validator separates them from pure syntax problems so you know whether you are fixing the markup's shape or its content.
A subtler class of error the validator surfaces is mismatch between the markup and the visible page. Structured data must describe content the reader actually sees, so steps that exist only in the JSON, or page steps that never made it into the markup, are violations even when both sides are individually valid. The tool also catches the type-confusion mistakes that plague this vocabulary: marking up a recipe as a HowTo when Recipe is the correct and still-rich type, marking up a listicle or a buying guide as a HowTo when it is not a sequential task at all, and swapping the tool and supply roles. None of these throws a hard parser error, which is exactly why a validator that names them is valuable.
Validator versus generator versus Rich Results Test
It helps to know where this tool sits among the others you might reach for. A HowTo generator is an authoring aid: you feed it fields and it emits a correct block, which means its output is valid by construction. This validator is an inspection aid for markup that already exists on a live URL, where no such guarantee holds, which is the situation that produces the real-world errors above. Google's Rich Results Test overlaps with this validator on syntax, and it remains a useful independent second opinion, but it now reports HowTo as valid structured data without promising a visible result, because that result is retired. Use this validator to audit your published pages in bulk and to catch drift, then use the Rich Results Test for a final, authoritative syntax confirmation.
Where the validator is uniquely helpful is in distinguishing won't-parse from parses-but-wrong. A generator never produces the second category, and a quick syntax checker often passes it, yet parses-but-wrong is where most live HowTo blocks fail: technically valid JSON describing a procedure that no longer matches the page. Treat the validator as the tool that answers a different question than the generator does. The generator asks how do I write this correctly, and the validator asks is what I already published still correct, which is the question that matters once content has shipped and been edited.
What to do after you validate
If the validator reports a syntax failure, fix the JSON first and re-run, because no other result is trustworthy until the block parses. Once it parses, work through the required-property failures so the block is a genuine HowTo, then add the high-value recommended properties the report flags as missing, especially per-step images and a properly formatted totalTime. After every change, re-validate against the live URL rather than against your local draft, since plugins and tag managers can alter what actually ships. Finish with a pass through Google's Rich Results Test for an independent syntax confirmation.
Then step back and ask whether HowTo is the right type for the page at all, because the validator can confirm a block is well formed without confirming it should exist. If the page is a recipe, move to Recipe, which still earns visible enhancements and carries food-specific properties. If the page is a listicle, a comparison, or a general explainer rather than a sequential task, the most honest fix is to remove the HowTo markup, since a perfectly valid block on non-procedural content still misrepresents the page to every machine that reads it. For genuine task tutorials, keep the markup, keep it in sync with the visible steps, and re-validate whenever the instructions change so the structured procedure and the page never drift apart again.