AI Summary
A JSON-LD generator produces syntactically valid structured data for a single page, which solves the easiest part of the job. What decides whether you actually earn a rich result is whether the markup carries the properties Google requires for that result type, and whether every value in it is visible on the page itself.
- Three gates, in order: does it parse, is it eligible, does it match the visible page.
- Markup describing content a user cannot see is a structured data policy violation, not a shortcut.
- Google restricted FAQ rich results in 2023 and removed HowTo rich results, so generator output for those types no longer produces the listing people expect.
- Generators do not scale. Production sites bind markup to template variables and connect entities with
@idinstead of repeating them.
A JSON-LD generator is a genuinely useful tool for a specific job: producing a correctly shaped block quickly, without hand writing braces, when you are marking up one page or learning the syntax. It removes typos and it teaches structure. What it cannot do is tell you whether the block you just generated will do anything, because that depends on the page it is going onto and on rules that live outside the syntax.
This page covers the part after the generator: which types are worth marking up in the first place, how to implement JSON-LD so it survives a template, and what determines whether markup converts into a visible result.
Schema Types and Applications
Schema.org defines a very large vocabulary. Google supports a much smaller subset for rich results, and that subset has been shrinking. Marking up a type Google does not support for enhanced display is not harmful, but it will not produce the listing change most people are hoping for. Choose types with the current eligibility rules in mind.
| Type | Use it on | Properties that carry the weight | Current display reality |
|---|---|---|---|
Product | Product detail pages | name, image, offers with price and priceCurrency, availability | Well supported. Price and availability can appear in the listing. |
Article | Editorial and news pages | headline, image, datePublished, author as a nested entity | Supported. Mostly affects eligibility for news surfaces rather than the standard listing. |
LocalBusiness | Location and contact pages | name, address, telephone, openingHoursSpecification, geo | Supported. Reinforces the business profile rather than replacing it. |
BreadcrumbList | Any page below the top level | itemListElement with position, name, item | Reliable and low effort. Replaces the URL path in the listing. |
FAQPage | Pages with genuine visible Q and A | mainEntity of Question with acceptedAnswer | Restricted since 2023 to well known authoritative government and health sites. Still worth emitting as machine readable structure, but expect no accordion. |
HowTo | Step by step instructions | step with HowToStep entries | Rich result removed by Google. Generator output for this type no longer earns a listing change. |
Organization | Home page or a single site wide node | name, url, logo, sameAs | No direct rich result, but it is the entity other markup should reference. |
The pattern worth extracting: the types that still reliably change a listing are the ones describing objective, verifiable facts about a thing (a price, a position in a hierarchy, an address). The types that described page structure rather than facts are the ones Google has pulled back. That is a reasonable predictor for anything new. Type specific requirements are covered in more depth in the Product schema guide and the LocalBusiness schema guide.
Implementation Best Practices
JSON-LD is the format Google recommends, and the practical reason is that it sits in one block rather than being woven through your HTML attributes, so it can be generated, tested and changed without touching the template's markup. Place it in a script tag with type="application/ld+json". It can go in the head or the body; neither position is preferred.
Beyond that, a handful of implementation decisions separate markup that survives a year from markup that quietly rots.
- Bind values to template variables, never to literals. A hard coded price is wrong the first time the price changes, and nobody notices because the page still looks correct. Every value that can change should come from the same source the visible page renders from.
- Use one
@graphper page and connect nodes with@id. Rather than repeating the organisation inside Article, Product and LocalBusiness, define it once with a stable@idand reference that identifier. This keeps the payload small and prevents three copies drifting apart. - Give every entity a stable, absolute
@id. Use the canonical URL with a fragment, such ashttps://example.com/#organization. Relative or changing identifiers break the connections between nodes. - Do not emit empty or placeholder properties. A property present with an empty string or a value of "N/A" is worse than an absent property, because it asserts something false.
- Check whether your CMS already emits markup. Most SEO plugins output Article, Organization and WebSite by default. Pasting generator output on top produces duplicate conflicting entities, which is one of the most common causes of validation warnings on WordPress sites.
- Validate the rendered page, not the snippet. If markup is injected by JavaScript or assembled by a tag manager, the only meaningful test is against the final rendered HTML.
The last point is where most generator workflows fail in production. Pasting a block into a validation form proves the block is well formed; it proves nothing about what the server sends. The full checking process is set out in validating and debugging structured data.
The three checks that actually gate a rich result
Run these in order. Each one catches a different class of failure, and passing the first two while failing the third is the scenario that causes real damage.
| Check | Question | Tool | Failure looks like |
|---|---|---|---|
| 1. Parse | Is it valid JSON and valid Schema.org? | Schema Markup Validator | A trailing comma, an unescaped quote, or a misspelled type name. The entire block is ignored. |
| 2. Eligible | Does it have the properties Google requires for this result type? | Rich Results Test | Valid markup that reports no eligible rich result, usually a missing required property. |
| 3. Match | Is every value in the markup visible on the page? | Reading the page | No tool flags it. It surfaces later as a manual action for structured data issues. |
The third check has no automation because it is a judgement about honesty. Marking up a rating that appears nowhere on the page, an offer that is not really available, or an author who does not exist is a policy violation regardless of how clean the syntax is. It is also the failure mode a generator makes easiest, because the form will happily accept whatever you type into it.
Rich Results Impact
Structured data does not make a page rank higher. What it does is change how a listing can be displayed, and a listing that shows a price, a rating or a breadcrumb path occupies more space and communicates more before the click. That is a click through effect rather than a position effect, and the distinction matters because it sets expectations correctly with stakeholders who will otherwise interpret schema work as a ranking initiative that failed.
Eligibility is also not a guarantee. Google decides per query and per result whether to render an enhancement, so correct markup can be present for months and appear inconsistently. The useful measurement is not whether markup exists but whether the search appearance data shows the enhancement being served, and how those impressions perform relative to plain listings. Search Console reports enhancements by type, and comparing performance filtered by search appearance is the closest thing to a clean read available.
Where markup earns its keep beyond rich results is machine readability generally. An explicit statement of what a page is about, which entity it concerns and how it relates to your organisation is useful to any system parsing the page, including AI answer engines that extract and attribute claims. That value does not show up in a rich results report, which is precisely why it tends to be undervalued. A broader survey of what to emit and where is collected in the schema and structured data tools section.
Errors that generators produce most often
| Error | Why it happens | Fix |
|---|---|---|
| Duplicate Organization or Article nodes | The SEO plugin already emits them; generated markup is added on top | Audit the rendered page first, then extend the existing graph rather than adding a second one |
| Price as a formatted string | A currency symbol or thousands separator is pasted in from the page | Use a plain number in price and put the currency in priceCurrency |
| Review markup on the business itself | The generator offers aggregateRating and it is tempting | Self serving reviews of your own organisation are not eligible. Mark up reviews of products, not of yourself |
| Dates without timezone or in the wrong format | A human readable date is typed into the form | Use ISO 8601, for example 2026-07-20T09:00:00+01:00 |
| Markup for content behind a tab or accordion | Assumed to be invisible to Google | Content in collapsed elements is fine as long as it is in the HTML. Content that is not on the page at all is not |
FAQ
For a handful of static pages, yes. For anything templated it is a starting point only, because generated blocks contain hard coded values that go stale the moment a price, date or title changes. Production implementations bind every value to the same data the visible page renders from.
Either the head or the body works, and Google states no preference. What matters is that it is present in the HTML that the crawler receives. If it is injected client side, verify it against the rendered page rather than assuming it arrives.
Not directly. It makes a page eligible for enhanced display, which can improve click through rate from the same position, and it makes the page's meaning explicit to any system parsing it. Framing schema work as a ranking initiative sets an expectation it will not meet.
Validation and eligibility are separate. The Schema Markup Validator checks the markup is well formed; the Rich Results Test checks whether Google's required properties for that result type are present. Beyond both, Google chooses per query whether to render an enhancement, so a correct implementation can still display inconsistently.
No. Structured data must describe content the user can see. Content inside tabs or accordions is acceptable because it is present in the HTML, but marking up a rating, price or review that appears nowhere on the page is a policy violation and can result in a manual action.
The FAQ rich result has been restricted since 2023 to well known authoritative government and health sites, so most sites will not see an accordion in the listing. Emitting it is still reasonable where the page genuinely has visible questions and answers, since it states the page's structure clearly for any system reading it. Just do not expect a display change.
Source: https://www.jamesdflynn.com/json-ld-schema-generator/
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
