Schema Markup Generator: JSON-LD That Google Will Actually Use
Structured data is how a page tells a search engine what it is rather than leaving it to be inferred from the text. The gap most generators leave open is that schema.org accepts almost anything, while Google refuses to show a rich result unless a much shorter and stricter set of properties is present. This generator validates against the second list, separates what is required from what is merely recommended, drops every empty property rather than emitting a key with nothing behind it, and covers eleven types. Everything runs in your browser.
Table of Contents
What Structured Data Does
It states facts a machine cannot reliably infer. A price, a rating, an event date and an author are all obvious to a reader and ambiguous to a parser. Structured data removes the guesswork.
It is what rich results are built from. Star ratings, prices, event dates, recipe times and breadcrumb trails in search results all come from this markup and from nothing else.
It is not a ranking factor by itself. Adding markup does not move you up the page. What it changes is how much space your result occupies and how informative it looks, which affects how often it is clicked.
It matters increasingly beyond search. Assistants, answer engines and any system trying to read the web at scale lean on structured data precisely because it is unambiguous.
How to Use This Generator
Pick the type that matches the page. One page, one primary type. A blog post is an Article, a product page is a Product, and a page trying to be both is usually neither.
Fill the red badges first. Those are the properties Google requires. Until every one is present the validation panel stays red, because until then there is no rich result regardless of what else you add.
Then work through the amber ones. Recommended properties are valid to omit and each one you add gives the result more to show.
Copy the script tag and paste it into the page. Head or body both work. Then test the live URL with Google's Rich Results Test, because only that shows what Google sees after rendering.
Why JSON-LD and Not the Others
Google recommends JSON-LD explicitly. Of the three supported formats it is the one the documentation points at, which is reason enough on its own.
It sits apart from your markup. Microdata and RDFa interleave attributes through your HTML, so a template change can silently break the data. A JSON-LD block is one self contained script that redesigns do not touch.
It can be generated server side in one place. Building one object is far simpler than threading attributes through a component tree, and far easier to test.
Google renders JavaScript, but do not rely on it. Injecting the block client side does usually work, and shipping it in the initial HTML removes an entire class of problem.
Which Type Your Page Needs
Article for anything editorial. Blog posts, news and guides. It is the most widely applicable type and the one most sites should start with.
Product where something is for sale. Price and availability in the result are worth real money, and the requirements are correspondingly strict.
LocalBusiness for a place customers visit. Name, address and phone should match your Google Business Profile character for character, since inconsistency undermines the signal.
Breadcrumbs almost everywhere. They are cheap to generate, they apply to nearly every page, and they replace an ugly URL with a readable trail in the result.
Required Against Recommended
Required means no rich result without it. Google will parse your markup, find a missing property and decline to use any of it. There is no partial credit.
Recommended means valid but thinner. The result still appears, with less in it. A product without a rating is a perfectly good product result.
schema.org validity is a lower bar than Google's. A document can be entirely valid schema.org and still produce nothing in search, which is why this tool validates against the stricter list.
Requirements change. Google adjusts what it needs, and has removed whole rich result types before. Retest occasionally rather than assuming markup written two years ago still qualifies.
The Policy Rules That Get Sites Penalised
The markup must describe what is on the page. Marking up an FAQ that does not appear in the visible content is the single most common structured data violation, and it can earn a manual action.
Reviews must be genuine and independent. Ratings you wrote about yourself, or aggregate ratings assembled from nothing, are explicitly against the guidelines.
One page, one subject. Product markup for items not on the page, or an event that lives on a different URL, both count as misrepresentation.
Hidden content does not count as present. Content in a collapsed accordion is acceptable because a user can reveal it. Content that is not in the page at all is not.
Combining Several Types on One Page
Several blocks on a page are fine. An article page can carry Article, BreadcrumbList and Organization at once, and each in its own script tag is the simplest way to do it.
Or use one array. A single script containing an array of objects is equally valid and keeps everything in one place.
Organization belongs on one page. The home page or an about page. Repeating it site wide adds nothing and makes it harder to change later.
Do not contradict yourself. Two blocks stating different authors or different dates for the same page is worse than one block, because now nothing can be trusted.
Testing and Monitoring
The Rich Results Test is the one that counts. It reports what Google can actually use, which is a narrower question than whether the JSON is valid.
The schema.org validator checks a different thing. It confirms the vocabulary is used correctly and says nothing about whether a rich result will appear.
Search Console reports it over time. Its enhancement reports show errors across your whole site, which catches a template change that broke markup on ten thousand pages at once.
Valid markup is not a promise. Google decides whether to show a rich result for any given query, and correct markup makes it possible rather than certain.
Common Mistakes to Avoid
Marking up content that is not visible. The fastest route to a manual action, and completely avoidable.
Relative image URLs. Every URL in structured data must be absolute. A relative path resolves against nothing useful when a crawler reads it.
Dates without a time zone. An event at 18:00 with no offset shows at the wrong time for most of the world. The validation above flags exactly this.
Ratings with no review count. Google ignores an aggregate rating that does not say how many reviews it aggregates, so you lose both properties rather than one.
Frequently Asked Questions
Always test the live page: this generator validates the properties Google requires, but only Google's Rich Results Test run against your published URL shows what Google itself sees after rendering.