Skip to content
pageinspection

HowTo schema after the rich result: what it is still good for

Google spent years asking people to mark up their instructions, then retired the result that markup was written for. Nothing about the JSON-LD became invalid. It became unrewarded, which is a different problem with a different answer, and the answer is not automatically to delete it.

The short answer

Google retired HowTo rich results in 2023, so the carousel is gone. The markup still carries something no prose does: an explicit ordered sequence of steps, each with its own name and text. For an assistant reconstructing a procedure, that ordering is the payload, and it is the reason the type stays worth writing on genuine step-by-step pages.

ImportantAudit check · HowTo Schema

What Google actually took away

During 2023 the HowTo rich result, the expandable step list with thumbnails that used to sit under a search result, was first restricted and then dropped. The enhancement report for it left Search Console. The documentation went with it. What remains is a schema.org type that still exists, still parses, and no longer buys you a presentation on Google.

Be precise about what that removed, because the vaguer version of the news has talked people into stripping working markup out of their documentation. It removed one rendering on one results page. It did not remove the type from schema.org, did not make existing blocks invalid, and did not stop any other consumer from reading them.

If the thumbnail strip was your only reason for writing HowTo, that reason is gone and you should not start now.

Why a retired rich result is still rated Important

The obvious objection is that a check for a dead feature should be deleted rather than rated. It survives because the rating was never measuring the feature. It measures whether a page documenting a procedure states in machine-readable form that it is a procedure, that it has this many steps, and that they run in this order. That statement outlived the thing that used to reward it.

It sits below Critical for the same reason every additive markup check does: a step-by-step page with no HowTo still ranks, still reads and still gets crawled. It clears Refinement because the alternative to declaring the sequence is having a parser infer it, and sequence is the one property of a procedure that cannot be repaired downstream when the inference is wrong. A missing heading produces a vague page. Reordered instructions produce confidently wrong ones. The scale itself is defined on the audit page.

A HowTo that validates, with the properties that carry weight

Two properties are load-bearing: name, the task, and step, an ordered array of step objects. The rest are optional and most are worth writing anyway, because the optional properties hold the things a parser cannot recover from your prose.

howto.html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to rotate an API key without downtime",
  "description": "Issue a second key, move traffic onto it, then revoke the first.",
  "totalTime": "PT15M",
  "estimatedCost": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": "0"
  },
  "tool": [
    { "@type": "HowToTool", "name": "Dashboard access with the owner role" }
  ],
  "supply": [
    { "@type": "HowToSupply", "name": "The key currently in production" }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "Issue a second key",
      "text": "Open Settings, then API keys, then Create key.
               Name it with today's date so the older key is
               obvious in a month.",
      "url": "https://example.com/docs/rotate-keys#issue",
      "image": "https://example.com/img/rotate-issue.png"
    },
    {
      "@type": "HowToStep",
      "name": "Move traffic onto the new key",
      "url": "https://example.com/docs/rotate-keys#cutover",
      "itemListElement": [
        {
          "@type": "HowToDirection",
          "text": "Set the new key in staging and confirm one
                   authenticated request succeeds."
        },
        {
          "@type": "HowToDirection",
          "text": "Set it in production and redeploy."
        },
        {
          "@type": "HowToTip",
          "text": "Leave both keys live for a full billing
                   cycle. Revoking early is what turns a
                   rotation into an incident."
        }
      ]
    },
    {
      "@type": "HowToStep",
      "name": "Revoke the old key",
      "text": "Check that the last-used timestamp on the old
               key is older than your longest cache window,
               then revoke it.",
      "url": "https://example.com/docs/rotate-keys#revoke"
    }
  ]
}
</script>

Three details there decide whether it validates. totalTime is an ISO 8601 duration, so PT15M passes and 15 minutes does not. supply is what the procedure consumes and tool is what the reader still has afterwards, which is why an access role is a tool and the outgoing key is a supply. And estimatedCost is an object with a currency, never a bare string, even when the value is zero.

Check one page for HowTo markup

Paste a URL. This reports which schema types the page declares and whether HowTo is among them. It cannot tell you whether the steps in the markup match the steps on the page, which is the part that needs your eyes.

Check one page for HowTo markup

No signup required. Each free search audits one page, paste any URL to see it in action.

The step object is where implementations go wrong

A step is an entity, not a string. That one fact accounts for most broken HowTo blocks, because a generator mapping your ordered list onto an array of sentences produces something that parses and says almost nothing.

  • One step holding the whole procedure. The most common failure by a wide margin: a single HowToStep whose text runs to nine sentences. It validates, and it has declared that your nine-step task has one step.
  • name repeated as text. The name is a short label, the text is the instruction. Setting both to the same sentence gives you a step titled with its own body.
  • Numbering written into the names.Do not write "Step 1: issue a key". Array position is the number, and hardcoding it means inserting a step in the middle forces you to renumber every one after it.
  • url pointing at the page instead of the step. It is meant to be a fragment that resolves to that step, which means the heading or list item needs an id for the fragment to land on. A step url with no matching anchor is a link to the top of the page dressed as a deep link.
  • Neither text nor directions. A step carries text, or an itemListElement of HowToDirection and HowToTip objects as in the second step above. A step with only a name is an empty declaration.

For a long procedure with distinct phases, HowToSection groups steps under a named heading and holds its own itemListElement. Reach for it when the page already shows those subheadings, not to invent structure the reader never sees.

Two cases where HowTo is the wrong type

A recipe is not a HowTo. Recipes have their own type, and the instructions belong in recipeInstructions on Recipe, which itself accepts HowToStep and HowToSection objects. Declaring a recipe page as HowTo forfeits the recipe result, which unlike the HowTo result is still very much alive. That makes it the most expensive mistake available here: it trades a live feature for a retired one.

A list of options is not a sequence. "Seven ways to reduce your bill" is seven alternatives and the reader picks one. HowTo asserts that step three follows step two, so applying it to independent choices states something false about your own content. If the items are interchangeable you have a list, and choosing the right shape for it is the real fix.

Everything in the markup has to be on the page.

The visibility rule that governs every other type governs this one, and HowTo makes it easy to break by accident. A generator pulling step text from a CMS field will happily describe a tenth step that never got published, or keep describing one an editor deleted last month. Nine visible steps and ten declared ones is markup contradicting its own page.

Validating it now that the Rich Results Test ignores it

Here is the trap unique to this check. Google's Rich Results Test only reports types tied to a feature it still supports, so a correct HowTo block now comes back with nothing detected. That is not a validation failure, and reading it as one is exactly how good markup gets deleted. Use the Schema Markup Validator at validator.schema.org instead, which reports every type it can parse regardless of who renders it.

Then do the two checks no validator performs. Count the steps in the JSON-LD against the steps on the rendered page and confirm both the count and the order agree. Then fetch the page with curl and confirm the script tag is in the server response rather than injected after hydration. No Search Console report exists to catch either mistake for you any more, so the parse check plus that diff is the entire verification loop. If the JSON-LD is failing to parse outright, the validation check catches it across every page at once.

Questions this check raises

Is HowTo schema still useful?
For the Google rich result, no, it was removed. For anything reconstructing a procedure from your page, yes: the step objects state the order explicitly rather than leaving it to be inferred from heading positions, which is exactly what an assistant needs to give someone accurate instructions.
When should I not use HowTo?
When the page is not a procedure. A page explaining what something is, with a fix at the end, is an article with a section, not a HowTo. The other wrong case is a recipe, which has its own type with properties HowTo does not carry.
What goes in a HowTo step?
A name that reads as the step and text that says what to do, at minimum. Steps whose text repeats the name carry nothing, and a step list generated from headings alone tends to produce exactly that. An image or a URL per step is optional and useful where the step is hard to describe.