Google's Structured Data Markup Helper: the twelve page types it still covers, the nine email ones, and what to do when your type is not on the list

Google's Structured Data Markup Helper is a point and click tagger. You choose a data type, paste a URL or the HTML of a page, highlight the title, the price, the author or the opening hours on the rendered page, and it writes the markup for you. It still answers at google.com/webmasters/markup-helper and it has two modes, one for web pages and one for HTML email. The thing to understand before you open it is that its type list is short and has not grown, so the first question is whether your page is one of the twelve types it knows. If it is not, the tool has nothing to offer you and a hand written block is the faster route.

The twelve web page types it offers

Exactly as listed in the tool today: Articles, Book Reviews, Data sets, Events, Films, Job postings, Local Businesses, Products, Question and Answer Page, Restaurants, Software Applications, and TV Episodes.

Read that list for what is missing rather than for what is there. There is no Organization, no Person, no FAQ page, no How-to, no breadcrumb, no recipe, no video, no course and no service. Several of those are among the most useful blocks a business can publish, and all of them have to be written rather than tagged.

The nine email types, which are a different job entirely

The second mode marks up HTML email: Bus Reservations, Car Rental Reservations, Event Reservations, Flight Reservations, Lodging Reservations, Orders, Parcel Delivery, Restaurant Reservations and Train Reservations.

Every one of those is a transactional confirmation, which tells you what the feature is for: letting a mailbox surface a flight time or a parcel status from the message itself. It is not a marketing feature and it has a gate in front of it, because Google asks senders to register before email markup is used in Gmail. Check that step in Google's own documentation before anybody spends a day tagging templates.

How it works, in four steps

• Pick the data type first. The tagging interface changes with the type, because each type has its own required and recommended properties.
• Give it a URL, or paste HTML. Pasting the source is the option that works for a page behind a login or one that is not published yet.
• Tag by highlighting. Select the text on the rendered page and choose which property it is. The tool keeps a running list of what you have tagged and what the type still expects.
• Take the generated markup. The output is the point of the exercise, and if the tool offers you a choice of format, take the JSON-LD one, because that is the format Google's own documentation recommends and it is the one that does not entangle markup with your page's layout.

The sentence in the tool that most people skip

Google's own description says the tool helps you add markup to a sample web page. That word is the whole limitation. What comes out is the markup for one page, filled with that page's values. A site with 400 products needs the block built by the template from the product record, not pasted in 400 times, so the Helper's real use on a large site is as a specification: tag one page, read the output, then hand that output to whoever edits the template as the shape to generate.

Markup pasted by hand into a single page ages exactly the way a hand written sitemap does, which is the argument in why a sitemap is a feed rather than a file: the version worth having is the one your system rebuilds when the data changes.

What the Helper does not do

Job	Does the Helper do it	What does
Write markup for a supported type	Yes, by tagging	This tool, or a hand written block
Write markup for an unsupported type	No	A copyable block, edited by hand
Check that your markup is valid	No	A validator, which is a separate tool
Tell you whether a rich result is eligible	No	Google's rich results testing, plus the eligibility rules for that result type
Put the markup on your site	No	You, your CMS, or a plugin
Report what Google read after it is live	No	Search Console's enhancement reports

Generating and validating being two different tools is the single most common confusion here. Which validator to use for the second step, and how to read what it says, is covered in the schema markup checker.

When your type is not on the list

This is the normal case for most businesses, and it is not a problem. A structured data block is a short piece of JSON that you copy and edit, so for the types the Helper never covered the work is ten minutes with a known good block in front of you.

• A company page. The Organization block, with the name, the URL, the logo and the list of official profiles. The correct version, and an honest account of what it does and does not change, is in the Organization schema block.
• A product page. Products are on the Helper's list, and the properties that matter plus the mismatch that breaks the result are set out in the product schema block, which is worth reading either way because the Helper will happily tag a page into an ineligible state.
• An FAQ. The markup is still worth publishing, but the rich result it used to earn stopped appearing in Google Search on 7 May 2026, so expect no Google box: see what FAQ markup is still for.
• Anything else. Start from schema.org's type page and Google's own documentation for the result you want, and keep the block to the properties the documentation calls required and recommended. What each of Google's documents actually settles is mapped in the documentation Google publishes itself.

A sensible order of work

• Decide what you want Google to understand, in one sentence, before opening any tool. Markup states facts; it does not argue.
• Check whether a rich result exists for that fact. Many useful blocks produce no visible change in the results and are still worth publishing, because they remove ambiguity about what the page is.
• Generate one page's markup, with the Helper if the type is supported and by hand if not.
• Validate it, and fix anything flagged as an error before publishing. Warnings are recommendations rather than faults.
• Template it, so every page of that type gets the block from the data rather than from a person.
• Watch Search Console for a fortnight, because the enhancement reports are where you find out what Google accepted rather than what you sent.

Questions about the Markup Helper

Is the Structured Data Markup Helper still available?

Yes. It answers at google.com/webmasters/markup-helper and it worked as described when this page was written on 20 October 2026. The address sits under the old webmasters path, which is a clue to its age rather than to its availability.

Does it support JSON-LD?

Take the JSON-LD output if the tool gives you the choice, since that is the format Google's documentation recommends and the one that survives a redesign, because it sits in a script block rather than being woven through the page's tags.

Why is my page type missing?

The list has stayed where it is while schema.org and Google's own rich result catalogue kept growing. For a missing type, copy a block and edit it, which is the route most people end up using anyway.

Does using it help my rankings?

Markup changes what a search engine can state about your page with confidence, and it decides eligibility for certain result types. Treat it as making the page legible rather than as a ranking lever, and spend the effort on the facts in the block being correct and matching what a visitor sees.

Is it the same as the Rich Results Test?

No. The Helper writes markup. The Rich Results Test reads markup that already exists and reports what it found. You normally use both, in that order.

What about the email markup?

It is for transactional confirmations such as orders, deliveries and reservations, and Google asks senders to register before it takes effect in Gmail. Read the registration requirements before building it into your templates.

The other reader of the same block

Structured data was built so that one search engine could state a fact about a page without guessing. There is now a second reader with the same problem: a buyer asks an assistant who to use or what to buy, and the answer names two or three companies with a line of description each, assembled from pages it has read. Clean facts in a machine readable form are part of what makes a page easy to quote correctly, and a block that contradicts the visible page is part of what makes it easy to quote wrongly. Worth reading the description that currently gets returned for your own business. AI Knows Us asks those buying questions across the main assistants and records which companies get named and what the answers were built from.