Schema Builder: Build Valid JSON-LD for Any Page Type

How the Schema Builder works

Select a schema type from the dropdown. The builder shows all available properties for that type — marking required fields in red and recommended fields in amber. Fill in the values and the JSON-LD code updates in real time. Copy the finished code and paste it into your page HTML.

The most important schema types for most sites

Before you build: the rule that makes schema legitimate

A builder will happily generate whatever you type into it. The single condition that separates useful markup from a liability is not syntactic, and no builder can enforce it for you:

This happens innocently far more often than deliberately. Somebody adds three extra questions to the schema "for the keywords" without adding them to the page. A template pulls eight FAQs from a database while the page renders only three. A plugin emits an aggregate rating from an average that is displayed nowhere.

The check to run on every page you mark up: take each value in the JSON-LD — every question, every answer, every price, every rating — and find it with Ctrl-F in the rendered page. If it is not there, either put it on the page or take it out of the markup. There is no third option.

Required, recommended, and what actually earns the result

The builder marks required fields in red. Filling only those produces markup that validates and frequently produces nothing at all, because Google's requirements for a rich result are stricter than schema.org's requirements for validity. These are different bars and they are routinely confused.

• Schema.org validity asks: is this well-formed, and are the types and properties real?
• Google rich result eligibility asks: are the specific properties Google needs for this specific feature all present?

The gap between them is where most disappointment lives. Product markup carrying only name and image is perfectly valid schema and earns nothing. To reach a merchant listing you need an offers block with price, priceCurrency and availability; to get stars you need aggregateRating or review.

The recommended properties that are not optional in practice

• Product: shippingDetails and hasMerchantReturnPolicy. These surface delivery cost and the returns window in the search result itself, answering the two questions that stop people clicking. They are the most under-used properties in ecommerce structured data.
• Article: datePublished, dateModified, a real author, a publisher. Without them you are ineligible for the news and freshness surfaces the type exists to reach.
• LocalBusiness: the most specific subtype available. Dentist, Plumber, Restaurant, AutoRepair all exist and all say more than the generic parent. Specificity is the entire point of a type system.
• Offers: priceValidUntil. Omit it and the price is liable to be treated as stale. Set it forward, and keep it moving.

The paste is where it breaks

The builder emits valid JSON. What arrives on the live page frequently is not, and the causes are the same handful every time. A single JSON syntax error invalidates the entire block — not the offending property — so one bad character and none of your markup exists.

1. Your CMS HTML-escaped it. This is the great one. A templating engine or a WYSIWYG editor that escapes its output will turn every " into " and every & into & — inside the JSON. The block is now unparseable, and it happens site-wide, all at once, silently. Paste into a raw HTML or "custom code" field, never into a rich text editor.
2. Smart quotes. Round-tripping the code through a document, an email, or a chat window converts " into typographic quotes. JSON requires straight double quotes. This looks identical at a glance and fails completely.
3. A trailing comma after the last item of an object or array. Legal in JavaScript, illegal in JSON.
4. An unescaped quote inside a value. An FAQ answer containing a quoted phrase terminates the string early. Escape it as \".
5. The type attribute is wrong or missing. It must be <script type="application/ld+json">. Without it the browser treats the contents as JavaScript, and it neither runs nor registers as structured data.

Duplicate and conflicting blocks: the plugin problem

Generated markup is added alongside whatever your platform is already emitting — and most platforms are already emitting something. On a typical WordPress site, an SEO plugin, the theme, a review plugin and an ecommerce plugin may each publish their own JSON-LD. The result is three Organization blocks with three different names, two BreadcrumbList blocks describing different paths, and a WebSite block nobody remembers installing.

Google's response to contradictory statements about the same entity is to trust the page less, not to average them. It is genuinely damaging, and it is invisible unless you go looking.

Before pasting anything, check what is already there

Search the served page source for application/ld+json and count the blocks. More than one is not automatically wrong. More than one describing the same entity always is.

Say each thing once, with @graph and @id

The clean pattern is a single JSON-LD block containing an @graph array, in which each entity is declared once with a stable @id, and everything else references that @id rather than repeating the entity. Your Article's publisher is not a second copy of your Organization; it is a pointer to the one already declared. Contradiction becomes impossible by construction, because there is only ever one statement of each fact.

Where to put it, and why server-rendering matters more than head-versus-body

Google reads JSON-LD from the head or the body — that part is genuinely flexible. The question that actually matters is whether the markup exists in the HTML your server sends, or only after JavaScript has run.

Google can execute JavaScript and will generally pick up injected structured data on a second pass. But that pass is delayed, it is not guaranteed, and — increasingly the point — a great many other consumers never render at all. Answer engines, AI retrieval systems and assorted crawlers fetch and parse. Schema injected by a tag manager or a client-side framework simply does not exist to them.

So: server-render your structured data. Paste it into the template, not into Google Tag Manager. The tag-manager route is a legitimate stopgap when you have no access to the templates, and it should be treated as exactly that — a stopgap, with a plan to replace it.

And keep dateModified honest. Bumping it on every deploy, on pages that have not changed, is a signal that stops meaning anything — and once Google concludes your freshness dates are unreliable, it stops using them.

Two validators, answering two different questions

The distinction matters. Google's test will ignore, or warn about, perfectly valid schema.org markup that Google happens not to use for any of its own features. That is not an error in your markup — it is Google telling you about Google. If you are marking up so that answer engines can parse your content unambiguously, the schema.org validator is the one that answers your question.

And Search Console's Enhancements reports are the only place you find out that the markup which validated beautifully in a test tool has been silently broken across four hundred live pages by a templating change nobody connected to it.

Frequently asked questions

What types of schema can I build?

The Schema Builder supports all major schema types including Article, BlogPosting, Product, LocalBusiness, Organization, Person, FAQ Page, HowTo, Recipe, Event, Review, AggregateRating, BreadcrumbList, VideoObject, Course, and JobPosting. Select the type, fill in the required and optional fields, and the builder generates valid JSON-LD code ready to paste into your page.

Where do I add JSON-LD schema to my page?

Add JSON-LD schema in a script tag with type='application/ld+json' anywhere in your HTML — in the head or body. Google can read it from either location. Best practice is to place it in the head section. Paste the generated code directly — no modification needed.

How do I know if my schema is working?

After adding schema to your page, validate it using the Schema Debugger tool. It checks the markup against schema.org specifications and Google's requirements for rich results. For live pages, use Google Search Console's Rich Results report to see which pages are eligible for rich results and whether any schema errors exist.

Can adding schema markup harm my site?

Yes, if the markup describes content that is not visible on the page. Questions in FAQ markup that appear nowhere a visitor can read them, review markup on a page with no reviews, or a marked-up price that differs from the displayed one can trigger a manual action for structured data spam — which suppresses rich results across the whole site until it is fixed and appealed. Check every value in the JSON-LD against the rendered page before publishing.

Why did my schema break after I pasted it into my CMS?

Almost always because the CMS HTML-escaped it. A templating engine or rich-text editor that escapes its output turns every double quote into " and every ampersand into & inside the JSON, which makes the block unparseable — and it happens across the whole site at once, silently. Paste into a raw HTML or custom-code field, never a WYSIWYG editor. Smart quotes introduced by copying through a document have the same effect, and look identical at a glance.

Is it a problem to have more than one JSON-LD block on a page?

More than one block is not automatically wrong. More than one block describing the same entity always is. SEO plugins, themes and ecommerce plugins each emit their own markup, producing several Organization blocks with different names or competing BreadcrumbList paths — and Google's response to contradictory statements about one entity is to trust the page less rather than to average them. Search the served page source for application/ld+json and count what is already there before adding more.

Should I add schema through Google Tag Manager?

Only as a stopgap. Google can execute JavaScript and will usually pick up injected structured data on a later pass, but that pass is delayed and not guaranteed — and many other consumers, including answer engines and AI retrieval systems, fetch and parse rather than render, so markup injected client-side does not exist to them at all. Server-render the structured data into the template wherever you have access to do so.

Related tools