Why structured data is worth the ten minutes
Schema markup does not change what your page says to a human visitor. It changes what a search engine's parser can extract from that same page without guessing. A recipe page with no markup forces Google to infer, from surrounding text, whether a block of text is an ingredient list or a paragraph. A recipe page with Recipe schema tells Google exactly which lines are ingredients, which are instructions, and how long the dish takes to cook, in a format the parser does not have to interpret. That distinction is why structured data is one of the few SEO levers that is entirely mechanical: either the JSON-LD is present, valid, and matches the visible page, or it is not, with no ambiguity about whether you "did it right."
Google's own developer documentation is direct about the payoff and its limits: structured data makes a page eligible for a richer presentation, an FAQ dropdown, a recipe card with a star rating and cook time, a product listing with price and availability, but eligibility is not a guarantee of display. Google's ranking systems still decide independently whether to show the enhanced result for any specific query, and they revalidate the markup against your live page on an ongoing basis, not just at first crawl.
The 15 types this tool supports, and when to use each
Article covers blog posts, news pieces, and long-form editorial content; Google requires a headline, image, author, publisher, and both a publish and a last-modified date for full eligibility. Product is for a page selling one specific item and needs an image plus either pricing (an Offer) or real review data. LocalBusiness fits a brick-and-mortar location or service-area business and centers on a verified physical address. FAQPage applies only when the questions and answers are genuinely visible and expandable on the page itself, not hidden markup describing content nobody sees. HowTo is for a numbered sequence of steps someone could actually follow to complete a task.
Organization and Person describe entities rather than content, an "about us" page or an author bio, and both support a sameAs field linking out to verified social profiles, which feeds into how Google's Knowledge Graph consolidates an entity's identity across the web. Event needs a start date and a location at minimum. Recipe requires an image, ingredients, and instructions, and is one of the few types where the omission of any required field silently disqualifies the whole page from the recipe carousel, not just degrades it. VideoObject needs a thumbnail, upload date, and description. BreadcrumbList mirrors your site's navigation hierarchy and needs at least two levels to mean anything. Review must describe a real review with a real rating and real author, never a synthetic one. JobPosting needs a posting date, hiring organization, and location, and Google actively expires listings past their stated close date. SoftwareApplication fits an app or web tool page. WebSite, paired with a SearchAction, is what enables the sitelinks search box some brands get directly under their homepage result.
The failure mode a JSON validator will never catch
Most schema bugs in the wild are not syntax errors, they are template-variable-injection failures: a page built from a CMS template where a merge field failed to populate, so the rendered JSON-LD contains the literal string "undefined", "null", or an empty value instead of real data. A plain JSON validator sees this as perfectly valid JSON, because it is; the string "undefined" is a legal JSON value. Only a check that understands schema.org semantics catches that an Article.datePublished field literally containing the text "undefined" is not a real date. This is exactly the class of bug the "check existing schema" mode above is built to catch, and it is common enough on programmatically generated pages (product feeds, category pages, paginated archives) that it is worth running this checker even on schema you did not write by hand.
Common mistakes that get schema markup penalized, not just ignored
Marking up content that is not visible to a user is the most consequential mistake, not the most common one. Google's structured data general guidelines are explicit that markup must describe content the user can actually see and interact with on the page; using FAQPage markup to stuff answers to questions that appear nowhere in the visible page, or Review markup describing reviews collected nowhere real, is treated as spam, and repeated violations have led to sitewide loss of rich-result eligibility, not just for the offending page. Fabricated review counts or star ratings sit in the same category and carry the same risk.
A second common mistake is shipping the same JSON-LD template across every page in a cluster with only the product name swapped, while leaving optional-but-expected fields (image, price, availability) empty or static across every variant. Google's crawlers re-check structured data against the live page on an ongoing basis; a Product block that always claims "InStock" regardless of actual inventory is the kind of drift that erodes trust in a domain's markup over time, even without triggering a formal action.
A third: using FAQPage or HowTo markup as a substitute for actual on-page content, hiding the real answers behind a "read more" link or an accordion that never renders the text into the DOM at all. Google has tightened FAQ rich-result eligibility specifically in response to this pattern; if the content is not genuinely present and readable, the safest assumption is that the rich result will not render, independent of whether the JSON-LD is technically valid.
A worked example: turning a plain blog post into an Article
Take a typical company blog post: a headline, a hero image, an author byline, and a publish date already visible on the page. Selecting Article above and filling in those same four values, plus a publisher name and logo URL, produces a JSON-LD block where author is a nested Person object with a name field, not a bare string. This distinction matters more than it looks: Google's own schema validator explicitly flags an author value written as plain text ("By Jane Smith") instead of a proper Person or Organization object as a structural error, because the Article type's specification defines author as an entity reference, not a caption. Hand- written JSON-LD is where this mistake shows up most often, since it is easy to type a string where the spec expects an object and have the page still "look right" to a human skimming the markup.
The same logic applies to dateModified: if you leave it blank, this tool defaults it to match datePublished rather than omitting it, because Google's Article guidelines list both dates as required for full rich-result eligibility, and a missing dateModified is a more common silent failure than a missing datePublished, since publish date is usually set once at creation while the modified date is easy to forget to update on a template.
How this differs across CMS platforms
WordPress sites frequently already ship some Article or Organization schema through an SEO plugin (Yoast, RankMath, All in One SEO); before pasting a second copy generated here, check your page source for an existing application/ld+json block first (the "check existing schema" mode above will find it), since two competing Article blocks describing the same page is a duplicate-markup problem, not additional signal. Shopify's theme editor exposes a "custom liquid" section on product and page templates where a generated block can be dropped directly; for a Shopify store, Product schema generated here should generally be treated as a manual override only where the theme's own automatic product schema is missing required fields, which happens on older or heavily customized themes. Static site generators and hand- coded HTML have no competing markup to worry about, so the block goes straight into the page's <head>.
What "required" actually means for each field
This tool marks fields required based on what Google's structured-data documentation lists as necessary for an item to be eligible for a rich result at all, not merely what schema.org's own base vocabulary permits. Schema.org itself is permissive by design, almost every property on almost every type is technically optional at the vocabulary level, since schema.org serves search engines, browsers, and countless other consumers of structured data with different needs. Google layers its own, stricter eligibility requirements on top of that base vocabulary for each rich-result type, and those Google- specific requirements are what this tool enforces, because passing schema.org's permissive validation while failing Google's eligibility bar produces markup that is technically "valid" and functionally useless for search appearance.
How to verify what you generated actually works
Generating valid JSON-LD is step one, not the finish line. After pasting the script tag into your live page, run the URL through Google's own Rich Results Test, which checks the markup against Google's actual current eligibility requirements for each rich-result type, not just generic JSON-LD syntax. It will tell you specifically which fields are missing for full eligibility versus which are present but non-critical. For a broader structured-data health check across an entire site, Google Search Console's Enhancements reports surface which pages have valid, invalid, or partially valid markup at scale, and flag drops in valid-page count over time, useful for catching a templating bug that silently broke schema across a whole category after a site redesign.
Frequently asked questions
What is JSON-LD and why does Google want it?
JSON-LD (JavaScript Object Notation for Linked Data) is the structured-data format Google explicitly recommends over the two alternatives, Microdata and RDFa, because it lives in a single self-contained <script type="application/ld+json"> block rather than being woven through your visible HTML attributes. Google's own developer documentation states JSON-LD is its preferred syntax specifically because it is easier to add and maintain without touching the rendered page. Search engines parse this block to understand what a page actually is, an article, a product, a local business, a recipe, which can unlock rich results (star ratings, FAQ dropdowns, breadcrumbs, event dates) directly in the search results page.
Does adding schema markup guarantee a rich result in Google Search?
No. Google is explicit on this: valid structured data is a prerequisite Google may use to generate a rich result, never a guarantee. Google's automated systems still decide independently whether the enhanced result is worth showing for a given query, and they periodically re-crawl and re-validate the markup against your visible page. Marking up content that is not actually visible to users on the page is treated as a policy violation, not a bonus, and can trigger a manual action.
Which schema type should I use for my page?
Match the type to what the page fundamentally is, not what you want it to rank for. A blog post or news piece is Article. A page selling one item is Product. A brick-and-mortar or service-area business is LocalBusiness. A page with 3 or more visible, expandable Q&As is FAQPage. A numbered set of instructions is HowTo. If a page genuinely has more than one of these (a recipe post that is also an article), you can ship multiple JSON-LD blocks on the same page, one per type, as long as each one accurately describes something really present on the page.
Can I fake reviews or ratings to get star ratings in search results?
No, and Google actively polices this. Review and AggregateRating markup must reflect real, verifiable reviews collected through a genuine review mechanism, not review counts invented to make a product look more popular. Google's structured data guidelines classify fake or incentivized review markup as spam, and sites caught doing it at scale have had review-rich-result eligibility revoked sitewide, not just on the offending page.
Why did my schema markup pass a JSON validator but still not produce a rich result?
Valid JSON syntax and valid structured data are two different bars. A JSON validator only confirms the braces and quotes are well-formed; it does not check whether you supplied every field Google's specific rich-result eligibility requirements demand (for Product, that includes an image and either an offer or a review; for Article, a headline, image, and both publish and modified dates). Run your markup through Google's own Rich Results Test after generating it here, since that is the tool that checks against Google's actual eligibility requirements, not just JSON syntax.
Do I need a developer to add this to my site?
For most site builders, no. The output here is a single, self-contained <script type="application/ld+json"> block. WordPress, Shopify, Webflow, and most CMS platforms have a "custom code" or "additional scripts" field in the page or theme settings where this can be pasted directly, with no other code required. For a hand-coded site, it goes anywhere inside the <head> or <body> of the specific page it describes.
What does the "check existing schema" mode actually detect?
Paste the HTML source of a live page (View Source, then copy everything) and the checker extracts every <script type="application/ld+json"> block, parses it, and flags three common failure classes: syntax errors that make the JSON unparseable, a missing "@context" or "@type", and template-variable-injection bugs, fields that literally contain the string "undefined", "null", or an empty value because a templating system failed to fill them in. This last one is a surprisingly common, invisible failure on programmatically generated pages.
Building a compliance-heavy product page?
If your structured data needs to describe regulated claims, product safety information, or import compliance status, EntryProof and TariffWatch handle the regulatory side directly rather than treating it as generic page markup.
Primary sources: Google Search Central — Intro to structured data; Google Search Central — Structured data general guidelines; Schema.org — full type hierarchy; Google Rich Results Test.