What this tool does
Structured data written by hand is easy to get subtly wrong: a missing author, an image that isn't a full URL, a rating without a reviewCount, an event date in the wrong format. Google's Search Central docs specify, per rich result type, which properties are strictly required and which are merely recommended — this tool encodes that split so the red/green checklist you see matches what actually blocks eligibility, not schema.org's looser rules. It supports the nine types people ask for most: Article/BlogPosting, Product (with Offer and AggregateRating), FAQPage, BreadcrumbList, Organization, LocalBusiness, Event, Recipe, and WebSite (with Sitelinks Searchbox). Every field you type stays in your browser; the JSON-LD object is assembled with plain JavaScript and nothing is sent anywhere.
Which rich result each type unlocks
| Schema type | Google rich result | Required fields |
|---|---|---|
| Article / BlogPosting | Top stories carousel, article rich result | headline, image, datePublished |
| Product | Product snippet with price & rating stars | name, offers (price, priceCurrency, availability) |
| FAQPage | Expandable FAQ dropdown in search | ≥1 Question with name + acceptedAnswer text |
| BreadcrumbList | Breadcrumb trail instead of raw URL | itemListElement with position, name, item |
| Organization | Knowledge panel logo & sameAs links | name, url, logo |
| LocalBusiness | Local pack details, map card | name, address, and one of telephone/url/image |
| Event | Event rich result with date & venue | name, startDate, location |
| Recipe | Recipe card with photo, time, rating | name, image, and one of author/datePublished/description |
| WebSite | Sitelinks Searchbox under your homepage | name, url, potentialAction (SearchAction) |
How to use it
- Click the tab matching the content you're marking up — a blog post uses Article, a storefront listing uses Product, a support page uses FAQPage.
- Type into each field on the left; the JSON-LD preview on the right regenerates instantly as you type, with no submit button and no page reload.
- Watch the validation panel: a red dot means a field Google's guidelines mark as strictly required is still empty, while an amber dot flags something merely recommended for a stronger appearance.
- For repeatable sections — FAQ questions, breadcrumb trail steps, recipe ingredients, instruction steps — use the "+ Add" button to append another entry and the small remove control to delete one.
- Once the summary line turns green, copy either the bare JSON object or the wrapped script tag, or download a standalone .json file for your own build pipeline.
- Paste the result into your page template, then confirm it with an external validator such as Google's Rich Results Test or the Schema Markup Validator before you rely on it in production.
Common mistakes this catches
Most structured-data failures aren't exotic — they're the same handful of slip-ups repeated across thousands of sites, and each one quietly disqualifies a page from the rich result it was aiming for.
- Relative image paths. Google requires a fully-qualified image URL beginning with https://; a path like /img/photo.jpg without the domain will silently fail crawling even though it renders fine in a browser.
- Ratings without a review count. An AggregateRating with only a ratingValue and no reviewCount looks incomplete to Google and is commonly rejected as unverifiable, since a single anonymous score carries no evidentiary weight.
- Wrong date formats. datePublished, startDate and similar fields need ISO 8601 formatting; a locale-formatted string like "06/02/2026" is ambiguous between month-first and day-first conventions and often gets discarded.
- Duplicated or conflicting types on one page. Marking the same content as both Article and Product confuses which rich result Google should attempt, and can suppress both rather than granting either.
- Currency codes instead of symbols. priceCurrency expects an ISO 4217 code such as USD or EUR, not a symbol like $ or €, which is not machine-parseable across locales.
- Content mismatch. Structured data must describe what a visitor can actually see on the rendered page; inventing a rating, price or FAQ answer that isn't shown to users violates Google's spam policies and can trigger a manual action.
Two worked examples
Example 1 — Article input → output
Input: headline "How Tide Pools Recover After a Storm", image URL, author "Wayne Kessler", publisher "waynetools" with a logo URL, published 2026-06-02.
Output
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How Tide Pools Recover After a Storm",
"image": ["https://example.com/img/tide-pool.jpg"],
"author": { "@type": "Person", "name": "Wayne Kessler" },
"publisher": {
"@type": "Organization",
"name": "waynetools",
"logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
},
"datePublished": "2026-06-02"
}Example 2 — Product input → output
Input: name "Titanium Trail Spork", price 18.50 USD, in stock, rating 4.6 from 212 reviews.
Output
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Titanium Trail Spork",
"offers": {
"@type": "Offer",
"price": "18.50",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "212"
}
}Why structured data matters beyond classic search
Rich results in the traditional blue-link search page are only part of the payoff. Large-language-model answer engines — the kind that summarize a query instead of listing ten links — lean heavily on structured data because it removes ambiguity: a price wrapped in an Offer object is unambiguously a price, not a stray number in a paragraph that might be a phone extension or a model year. Sites that expose clean JSON-LD tend to get cited more precisely and more often by these systems, since the extractor doesn't have to guess at meaning from surrounding prose. This is sometimes called generative engine optimization, and it rewards exactly the same discipline this tool enforces: complete, accurate, non-misleading markup that matches the visible page.
Who this tool is built for
Independent developers shipping a landing page who don't want to memorize nine different schema.org vocabularies. Content teams publishing recipes, articles or events who need markup a non-technical editor can fill in without touching raw JSON. Agencies auditing a client site who want a fast way to produce a corrected block instead of hand-editing broken markup line by line. Anyone maintaining a WebSite homepage who wants the Sitelinks Searchbox without wiring a full CMS plugin.
Frequently asked questions
What is JSON-LD and why does Google want it?
JSON-LD (JSON for Linked Data) is a script block placed in a page's head that describes the page's content using schema.org vocabulary in a machine-readable way. Google, Bing and other engines parse it to understand entities like articles, products, FAQs and events well enough to show rich results — star ratings, FAQ dropdowns, breadcrumbs, event dates — directly in search, and increasingly to feed AI answer engines that cite structured facts over guessed ones.
Which schema type should I use for a blog post?
Use Article for general articles or BlogPosting for blog content; Google treats both the same way for rich results eligibility. Required fields are headline, image and datePublished; author and publisher (with a logo) are strongly recommended because Google's own documentation flags their absence as a common reason Article rich results don't appear.
Does adding JSON-LD guarantee a rich result in Google Search?
No. Valid, complete structured data makes a page eligible for a rich result, it does not force one. Google's algorithms still decide per query whether to render the enhanced result, and eligibility can be revoked if the marked-up content doesn't match what's visibly on the page. Use Google's own Rich Results Test after publishing to confirm the specific result type is being recognized.
Can I put more than one JSON-LD script on the same page?
Yes. It's normal and recommended to include several script blocks — for example Organization plus BreadcrumbList plus Article on the same page — each as its own separate <script type="application/ld+json"> tag, rather than trying to merge unrelated types into one @graph object by hand.
Why does the tool flag some fields as required and others as recommended?
Schema.org itself makes almost every property optional, but Google's Search Central documentation defines, per rich result type, which properties are required for eligibility and which are merely recommended to improve appearance quality. This tool mirrors Google's own required/recommended split for each type rather than schema.org's more permissive rules, so what it flags red is what actually blocks the rich result.
Does this tool upload my content anywhere?
No. Every field you type is only used in your browser to assemble the JSON-LD object with plain JavaScript; nothing is sent to a server, there is no analytics call on your input, and the page keeps working with the network disconnected. The only exception is an image URL you may reference for a rich-result preview thumbnail, which your own browser fetches directly from wherever you hosted it.
Where does the generated code go on my page?
Paste the full <script type="application/ld+json">...</script> block anywhere in your page's <head> or <body> — Google reads it regardless of position as long as it's valid HTML and valid JSON. Most sites place it in the head next to other meta tags for consistency.