Schema Markup Generator

What This Tool Does, And Who It Is For

Pick a schema type, fill in the fields, and this generator hands back a JSON-LD block you can paste into a page. It is for the person who has been told to "add schema" and wants a valid starting block rather than a plugin, a subscription, or a course.

It is worth saying up front what changed, because it changes what this tool is for. Until recently the honest pitch for a schema generator was rich results: add the markup, get a badge in the search listing, win the click. That pitch has been quietly shrinking for three years and it lost a big piece of ground this year. FAQ rich results stopped appearing in Google Search on 7 May 2026. Google removed the FAQ documentation entirely on 15 June 2026, and support for the FAQ rich result in the Search Console API is being removed this month. HowTo went the same way earlier: its documentation was pulled on 14 September 2023 because the rich result was, in Google's words, no longer shown in search results on either desktop or mobile.

So this page does two things. It generates the markup, and it tells you honestly which types still buy you something visible, which ones are now just machine-readable description, and why the second category is still worth writing.

How To Read The Output: An Audit Of This Page's Own Promises

Here is the worked example, and it is an audit of this tool rather than of somebody else's.

The previous version of this page carried a table headed "Rich Results You Can Earn With Schema" listing eight types: FAQPage, HowTo, Article, Product, LocalBusiness, Person, Event and BreadcrumbList. On 22 August 2026 I checked all eight against Google's own list of every structured data feature it documents, the page it calls "All structured data features", last updated 15 June 2026. That list currently contains 25 features:

Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental, Video.

Scoring the eight against that list:

Three of the eight are gone. Five survive. That is a 37.5% failure rate on a table that a lot of schema tools, this one included, were still publishing months after the fact.

Run the same test on the seven types this generator actually offers: FAQPage, Article or BlogPosting, Service, Person, LocalBusiness, SoftwareApplication and HowTo. Of those, three map to a live documented feature: Article, Local business and Software app. FAQPage and HowTo are retired. Person is not a feature. Service has never been one; it is a perfectly real schema.org type that Google does not turn into a search appearance.

Three out of seven is the number that matters, and it is the number to hold in your head when a plugin advertises "supports 30+ schema types". Type count is not a feature. Most schema types have never produced a rich result and were never going to.

Why The Other Four Are Still Worth Writing

If a type earns no badge, the reasonable question is why bother. There are two answers and only one of them is solid.

The solid one is entity clarity. Schema is the cheapest way to state, unambiguously and in a machine-readable form, who wrote this, what organisation stands behind it, what this page is about, and which other identities on the web are the same identity. An Organization or Profile page node carrying sameAs links to your real profiles turns a byline from an unresolvable string into something a machine can connect to a verifiable identity. Nothing else on a page does that job. It costs a few hundred bytes.

The weaker answer is AI citation, and here the evidence is thinner than the industry implies. Google's own guidance on optimising for its generative AI features, last updated 10 July 2026, addresses this directly and unhelpfully for anyone selling schema as an AI tactic: structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add", though it remains "a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results". Read that as written. Not required, no special markup, still worth having for the ordinary reason.

The same document is blunter about the adjacent tactics. On llms.txt and similar files: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them." On breaking content into small pieces: no requirement, and "there's no ideal page length". On writing differently for machines: not needed, because the systems understand synonyms and intent.

What Google does say drives visibility in its AI features is the thing schema cannot fake. It names two mechanisms, retrieval-augmented generation and query fan-out, both of which pull from the ordinary Search index, and then puts the weight on content that is not commodity. Its own contrast is worth quoting because it is a better brief than most content strategies: "7 Tips for First-Time Homebuyers" is commodity; "Why We Waived the Inspection & Saved Money: A Look Inside the Sewer Line" is not.

There is also a gate that has nothing to do with markup. A page must be indexed and eligible to appear with a snippet, and the site must be included in Search generative AI features in Search Console. If that box is not ticked, no amount of JSON-LD changes anything.

The Method: What A Valid Block Actually Requires

Strip the mystique and JSON-LD is three obligations.

One: it has to be valid JSON, inside a script tag, with the right type attribute. That is <script type="application/ld+json">. Not text/javascript, not application/json. Placement can be in <head> or <body>; both work.

Two: @context and @type on every node. "@context": "https://schema.org" once at the top level, and an @type on every object. Google reads the vocabulary, not your intentions.

Three: the required properties for the feature you want. Required means required. Recommended properties add detail and can improve how the result looks, but omitting them does not disqualify you; omitting a required one does. FAQ, while it lasted, was a good example of how small that list usually is: FAQPage required exactly one property, mainEntity, holding an array of Question items; each Question required name and acceptedAnswer; each Answer required text. Four required properties for the whole feature. Everything else the generators emitted was decoration.

One detail from that same spec is worth keeping because it generalises. Google listed the HTML tags it would render inside an Answer.text value: h1 to h6, br, ol, ul, li, a, p, div, b, strong, i and em, and said all other tags are ignored. Which means values are frequently not plain text, and that is exactly where the next section starts.

The Failure Nobody Validates For: Closing Your Own Script Tag

Here is a bug I can measure rather than assert. Put the literal characters </script> inside a JSON-LD string value, which happens the moment you write about HTML, and the block dies. Not because the JSON is wrong, but because an HTML parser does not know or care that it is inside a JSON string.

I ran a small FAQPage block whose answer text contained the sentence "Use the </script> tag to close a script block", embedded it in a minimal HTML document, and parsed it with html5lib, a spec-compliant HTML5 parser. Then I ran the same block with the sequence escaped as <\/script>, which JSON permits and which parses back to the identical string.

The visible page body of the naive version began, before the h1, with this:

tag to close a script block."
      }
    }
  ]
}Real page heading

That is 59 characters of JSON braces rendered as body copy above the heading, and a structured data block that no consumer can read. One character of escaping fixes both, and the escaped JSON deserialises to exactly the same string, so nothing is lost by defaulting to it. Any generator worth using escapes </ in string values automatically. Test yours with the word "script" before you trust it.

Common Mistakes

Marking up something the page does not show. The oldest rule in structured data and still the most commonly broken one. Google's FAQ guidelines required all FAQ content to be visible to the user on the source page, and were explicit that an answer hidden behind an expandable section is fine while an answer that exists only in the markup is not. The same principle runs through every feature. Markup describes the page; it does not extend it.

Marking up the same content on every page. Google's guidance was to mark up one instance of a repeated question for the whole site. A footer FAQ duplicated across 200 pages is 200 copies of the same node, which is at best wasted crawl and at worst a duplication signal.

Chasing type count. Covered above, and worth repeating because it is what sells plugins. Three of this generator's seven types map to a live feature. A tool advertising thirty types is advertising the schema.org vocabulary, not a capability.

Assuming valid means eligible. The Rich Results Test checks syntax. It cannot tell you that your site is not a well-known authoritative government or health site, which is what FAQ eligibility narrowed to in September 2023 before the feature was withdrawn altogether. Nor can it tell you that you have used FAQPage on a page where users submit their own answers, which needed QAPage instead. Google says this plainly: the issue may not be a syntax issue, and so the Rich Results Test will not identify it.

Double-encoding the JSON on the way into a template. If your CMS stores the block as a string and your template escapes it again, you ship "[{\"@context\"..." and every validator that checks for valid JSON will happily tell you it is valid, because a JSON-encoded string is valid JSON. Check the shape, not the validity. This one has bitten this very site.

Leaving the markup behind when the page changes. Structured data is the part of a page nobody re-reads. Prices, dates, availability and author names drift out of sync with the visible content, and stale markup is worse than none because it is a machine-readable claim that is now false.

Frequently Asked Questions

Should I remove the FAQ schema I already have?

There is no penalty for leaving it, and Google has not asked anyone to remove it. It will simply do nothing in Google Search: no rich result since 7 May 2026, no reporting after the API support goes this month. If the markup accurately describes questions and answers that are genuinely visible on the page, leaving it costs you a few hundred bytes and keeps the page machine-readable for other consumers, several of which still parse schema. If it describes questions that are not on the page, remove it, and that was true before the deprecation too.

Does adding schema help me get cited in AI answers?

Not on its own, and not in the way it is usually sold. Google's guidance is explicit that structured data is not required for its generative AI features and that there is no special markup to add for them, while still recommending it for ordinary rich result eligibility. Treat schema as a clarity measure, not a citation lever. The things Google does point at are unique first-hand content, a crawlable and indexable page, and a site enabled for generative AI features in Search Console. Anyone telling you a particular schema type gets you into AI Overviews is selling something Google's own documentation does not support.

Do I need an llms.txt file?

Not for Google. Its documentation states that Google Search does not use llms.txt or similar files, that creating one will neither harm nor help visibility or rankings in Google Search, and that it is fine to maintain one for other services that do use it. That is an honest description of the situation: adoption is real but partial, and the largest search system explicitly ignores the file. Treat it as optional housekeeping rather than a ranking tactic.

Where should the script tag go, head or body?

Either works. Google's own examples put it in <head>, and that is the convention worth following simply because it keeps the markup with the rest of the page metadata rather than buried in content. What matters far more is that it is present in the HTML the crawler receives. If the block is injected by client-side JavaScript after load, you are relying on the crawler executing that JavaScript, which Google generally does and many other consumers do not.

How many schema nodes should one page have?

As many as honestly describe it, and no more. A typical article page carries two or three: the Article or BlogPosting node, a BreadcrumbList, and often an Organization or Profile page node for the author identity. There is no bonus for volume. Every node is a factual claim about the page, so each one is a maintenance liability as well as a signal.

Is Microdata or RDFa ever the better choice?

Rarely, now. Google supports all three formats and documents Microdata alongside JSON-LD, but JSON-LD keeps the data in one block instead of scattering attributes through your markup, which makes it far easier to generate from your data layer and far easier to review. The main case for Microdata is a template you cannot add a script tag to. If you have the choice, take JSON-LD.

Why does my markup validate but show no rich result?

Because validation and eligibility are different tests, and because Google does not guarantee a rich result even when everything is correct. Its own troubleshooting guidance lists the reasons: the page may not be indexed, the content may not meet the feature's content guidelines, the site may have a structured data manual action, or the feature may simply not be shown for that query. Check Search Console's rich result status report rather than the validator, and allow days rather than hours for recrawling.

When A Generator Stops Being The Right Tool

This generator emits one block for one page, which is exactly the right shape for a handful of important URLs and exactly the wrong shape for a site.

The moment schema needs to be correct across every page, correct after every edit, and generated from the data that is already in your database, it stops being a copy-and-paste job and becomes a code change. That means a function in your templates that builds the node from the same fields the page renders, so the markup cannot drift out of sync with the visible content, and an escaping rule applied once in that function rather than remembered per page. It is not difficult work. It is just work that lives in the codebase rather than in a text box, and it is the difference between schema that stays true and schema that was true on the day someone pasted it.

That is the kind of thing I build. Most of my work is automation and AI systems, and a fair amount of it is this: taking something a client is doing by hand, once per page, and turning it into a small piece of code that does it every time and cannot forget. If you have a site where the markup has drifted, or a template that needs to generate it properly, tell me what you are working with and I will tell you whether it is an afternoon or a project.

For the rest of the page, the On-Page SEO Auditor and the SEO Meta Tag Analyzer cover the parts schema does not, and the Meta Title & Description Length Checker catches the truncation that costs more clicks than any missing rich result ever did. If the reason you are here is AI visibility, the retrieval mechanism Google names is the one worth understanding: how to build a RAG system walks through how retrieval-augmented generation actually selects and grounds source material, which is a more useful mental model than any markup checklist.