Generate JSON-LD schema from the page, with nothing in it that is not on the page
Writes JSON-LD from your actual page content, uses only properties that exist on schema.org, and omits any value it cannot find rather than inventing one.
- Works in
- ChatGPT, Claude, Gemini
- You need
- The visible text of the page you are marking up · The page URL and your organisation name
- Written for
- chatgpt prompt for schema markup
Scored by our own engine
This page, run through the audit we sell. Measured 4 August 2026.
Schema is the one part of a page written for machines, which means a mistake in it fails quietly. The prompt below generates JSON-LD from your page text and refuses to write any value that is not in it, then tells you what it left out and why.
The rule that keeps it valid
Use only properties that exist on schema.org, and omit anything you are not sure about. An invented property does not throw an error. It is parsed, not recognised, and dropped, so the block validates as JSON, appears in every viewer, and describes less than you believe it does.
This is the most common defect in generated markup and the hardest to notice, because nothing about the page looks wrong. The prompt handles it by naming the real properties for the common types up front, so the model has a list to work from rather than a memory to reach into, and by requiring anything outside that list to be flagged in the notes.
The values that get invented
Prices, ratings, author names and publish dates, in roughly that order. Asked to mark up a product page, a model with no price in front of it will produce a well formed Offer with a number in it, and the number came from nowhere.
Rule B is the fix: no value on the page, no property in the markup. Ratings get their own rule on top, because marking up a rating that is not visible breaches Google’s structured data guidelines whether or not the number is real, and that turns a fifteen minute job into a manual action.
The omissions then become the useful output. A notes list that says availability was left out because the page never states it is not a gap in the markup. It is a gap in the page.
One type, not five
Pick the type that describes the page, then add Organization or WebSite for identity and BreadcrumbList if you actually show a trail. That is it.
A page carrying Product, Service, FAQPage and HowTo because each is partially true is harder for a machine to resolve, not easier, and the extra types earn nothing.
Once it is published, read what the live page exposes with the structured data checker, which parses every JSON-LD block on the URL and lists the types it found. The common surprise is that your CMS was already emitting a block of its own, and yours is now the second one saying something different. Structured data is one of the 36 checks in the full audit, which is the place to see it alongside everything else the same page is doing.
You are writing JSON-LD structured data for one web page. I am pasting the
page. Generate markup that validates and that describes only what is
genuinely on it.
The two rules that matter most:
A. Use only types and properties that exist on schema.org. If you are not
certain a property exists, leave it out and list it at the end under
"omitted, not certain it exists". Never guess a property name because it
sounds plausible.
B. Every value must come from the text I pasted. If a value is not on the
page, omit the whole property. Do not write a placeholder, do not write
"example", and do not carry a value over from a similar page you have
seen. An omitted property is fixable. An invented one ships.
Further rules:
1. Choose one primary type for this page and say why in the notes. Do not
stack five types onto one page because they are all slightly true.
Organization or WebSite may be added alongside it, and BreadcrumbList
may be added if I pasted a breadcrumb trail.
2. Do not output aggregateRating or review unless real ratings are visible in
the text I pasted, with a real count. Marking up ratings that are not on
the page breaks Google's structured data guidelines regardless of whether
the numbers are true.
3. Mark up only content a reader can see on the page. If a property would
describe something present in your answer but not in the page, it does
not go in.
4. Output exactly one script tag containing one JSON-LD object or one @graph.
Valid JSON: double quotes, no trailing commas, no comments inside the
JSON, no ellipses. "@context" is "https://schema.org".
5. Dates go in ISO 8601 format. Prices are a string with a separate
priceCurrency and no currency symbol inside the number. availability uses
a full schema.org URL such as https://schema.org/InStock.
6. You cannot fetch this page, you cannot see my existing markup and you
cannot see how Google currently renders it. Do not claim the output will
produce any particular rich result. Say what type you produced and leave
the eligibility question to a validator.
These properties exist and are the ones worth using. Anything outside this
list, check on schema.org before you use it:
Organization: name, url, logo, description, sameAs, address, contactPoint
Article, BlogPosting: headline, description, image, datePublished,
dateModified, author, publisher, mainEntityOfPage
Product: name, image, description, sku, brand, offers
Offer: price, priceCurrency, availability, url, priceValidUntil
FAQPage: mainEntity, each a Question with name and acceptedAnswer, each
acceptedAnswer an Answer with text
BreadcrumbList: itemListElement, each a ListItem with position, name, item
LocalBusiness: name, address, telephone, openingHoursSpecification,
priceRange, geo
PostalAddress: streetAddress, addressLocality, addressRegion, postalCode,
addressCountry
Output, in this order:
1. The JSON-LD, in one fenced code block, and nothing else inside that block.
2. NOTES, as plain lines, after the block:
- Primary type chosen, and why.
- Types considered and rejected, one clause each.
- Properties omitted because the value is not on the page, with the
property named and what I would have to add to the page to include it.
- Properties omitted because you were not certain they exist.
- Anything in the page text you could not decide about.
The page URL: [THE EXACT URL, WITH https://]
My organisation name and homepage: [NAME AND URL]
The page: [PASTE THE VISIBLE TEXT, INCLUDING HEADINGS, PRICES AND DATES]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[THE EXACT URL, WITH https://]- The canonical URL of the page, with the protocol and no tracking parameters. It becomes mainEntityOfPage on an Article and the url on an Offer, and both have to match the URL you actually publish. A trailing slash mismatch here is a real inconsistency, not a cosmetic one.
[NAME AND URL]- Your legal or trading name exactly as it appears elsewhere, plus your homepage. This fills the publisher on an Article and the brand on a Product. Use the same string every time across the site, because the whole point of an Organization entity is that a machine can join it up.
[PASTE THE VISIBLE TEXT, INCLUDING HEADINGS, PRICES AND DATES]- The text a reader sees, headings included, with the price, the publish date, the author name and the address if the page shows them. Rule B is read against this paste, so anything missing from it is simply omitted from the markup. That is the intended behaviour: it makes the notes section a list of things to add to the page.
How to run it
- 01Decide what the page is before you paste it
One page, one primary type. A product page is a Product, an article is an Article, a page of questions is an FAQPage. If you cannot say which in one word, the page is probably doing two jobs and the markup will be the least of the problems. The prompt will still pick one and tell you what it rejected.
- 02Paste the visible text, not the HTML
Copy what a reader sees, headings and all. HTML gives the model markup to mimic and a lot of navigation text to wade through, and it makes rule 3 harder to enforce because hidden elements are in there too. Keep the price, the date, the author and the address exactly as they appear.
- 03Read the notes before you read the JSON
The notes list every property that was left out because the value is not on your page. That list is usually more useful than the markup: it says a product page has no visible availability, or an article has no author name. Add those to the page and rerun, rather than adding them only to the markup.
- 04Paste the output into a JSON validator first
Before anything else, confirm it parses. A single trailing comma silently disables the whole block, and a block that fails to parse is worse than no block because you get the confidence of having done the work and none of the effect. Any JSON linter settles it in seconds.
- 05Check every property you do not recognise
Search schema.org for any property name that is new to you. An invented property does not throw an error, it is simply ignored, so the markup looks fine and quietly describes less than you think. This is the single most common defect in generated JSON-LD and it is invisible without the check.
- 06Deploy it and read what your page actually exposes
Put the script tag in the head, publish, then run the URL through the structured data checker, which parses every JSON-LD block on the live page and lists the types it found. This catches the case where a plugin was already emitting its own block and yours is now the second, contradictory one.
Questions people ask
What is the best ChatGPT prompt for schema markup?
One that constrains the property names and the values separately. Property names have to exist on schema.org, and values have to come from your page. Without the first constraint you get plausible looking properties that are silently ignored. Without the second you get a price, a rating or an author that nobody wrote.
Why does generated JSON-LD fail validation?
Usually one of three things: a property that does not exist on the type, a value in the wrong format such as a date written as "March 2026", or invalid JSON from a trailing comma. The first is the dangerous one because nothing fails loudly. The block parses, the property is dropped, and the page describes less than you think.
Can I mark up a rating or a review with this?
Only if real ratings are visible on the page, with a real count, and the prompt refuses otherwise. Ratings that are not on the page breach Google's structured data guidelines, and an invented rating is the fastest way to turn a small technical task into a manual action against the site.
How many schema types should one page have?
One primary type that describes the page, plus Organization or WebSite for identity and BreadcrumbList if you show a breadcrumb trail. Stacking Product, Service, FAQPage and HowTo onto one page because each is partly true makes the page harder to interpret, not easier, and none of it earns anything.
Where does the JSON-LD go on the page?
In a script tag with type application/ld+json, in the head, on the page it describes. It does not have to sit next to the content it marks up, which is the main practical advantage of JSON-LD over microdata: a template change cannot break it by moving an element.
Unsubscribe in one click. We never pass your address on.