AI Schema Markup Generator: Validate Client Structured Data Before Launch

Give the AI only the facts visible on the client's page and ask for JSON-LD that uses nothing else. Before launch, check the syntax, run the Schema Markup Validator, test eligible features in Google's Rich Results Test, compare every value with the visible page, and watch Search Console afterwards. Passing the tools does not prove the markup is true.

A generator's weak spot is invention, not syntax. Drafts add ratings nobody wrote, coordinates nobody measured and types that do not exist. A validator catches the last of those and waves the first two through. Two facts frame the work: Google says no special schema.org markup is needed for its AI features, and it ended FAQ rich results on 7 May 2026. Drafting a block takes minutes; the checking is where an agency earns its fee.

Follow me on Instagram@sagnikteaches

Prompt rules that stop a generator inventing data

Most invention comes from asking for markup without supplying facts. Paste the visible page content, name the type, and make leaving a property out the default. Keep this prompt in the agency's shared notes so every drafter starts from the same rules.

Connect on LinkedInSagnik Bhattacharya

You are generating JSON-LD structured data for one web page.
Use ONLY the PAGE FACTS below. If a fact is missing, leave the property out.
Never guess, estimate or use typical values.

PAGE URL: [absolute URL]
SCHEMA TYPE: [Organization / LocalBusiness or a schema.org subtype /
Article or BlogPosting / Product / Event / BreadcrumbList]

PAGE FACTS (copied from what is visible on the page):
[name, address, phone, opening hours, prices, dates, author, headline...]

RULES
1. Output one JSON-LD block and nothing else inside it. No comments.
2. Use absolute URLs. Dates in ISO 8601 with a time zone offset.
3. No aggregateRating or review unless I pasted the review data and its source.
4. No invented coordinates, social profiles, logo files or identifiers.
5. Use only types and properties that exist on schema.org. If unsure a type
   exists, use its parent type.
6. After the block add two lists. UNUSED FACTS: facts you left out and why.
   MISSING: properties Google lists as required or recommended for this type
   that the facts did not cover.

The MISSING list does quiet work. Asked what Google requires, the assistant will say that a local business block needs an address and the pasted facts had none, which is cheaper to learn at the drafting stage than in a test report. Follow up with a second prompt that produces a parity table: For each property in the JSON-LD above, quote the exact line from PAGE FACTS that supports it, or write NONE. Every NONE is a deletion. The assistant's table is a triage aid, not proof, because the real check is a person looking at the live page.

Subscribe on YouTube@sagnikteaches

Which types to generate, and what Google asks for

Agencies tend to generate everything a generator offers. The shorter list below covers most client sites, with the requirements as Google's documentation states them on 1 November 2026.

Retired features are the trap. Google's changelog says the FAQ rich result stopped appearing in Search from 7 May 2026, and the documentation was removed on 15 June 2026. In September 2025 it removed documentation for course info, estimated salary, learning video, special announcement and vehicle listing because they no longer appear in results, and in January 2026 it did the same for practice problems. The 25 features in Google's current gallery are the working list. A type outside it can still be valid schema.org, but Google is not promising a feature for it, so do not bill a client for markup that cannot show anything.

When not to generate markup at all

Check what the site already prints before drafting anything. Many themes and SEO plugins output organisation, breadcrumb and article blocks by default, and a second hand-made block describing the same thing creates the conflicts described in step 5 of the validation pass below. View the rendered source of one page per template, search it for application/ld+json, and read what is there. Where an existing block is correct, leave it alone. Where it is wrong, fix it at the source, usually a plugin setting or a theme field, instead of layering a new block on top.

AI earns its place on the custom pieces: an event page, a product page with unusual fields, local business details that a plugin template cannot express. It is the wrong tool for a standard breadcrumb trail that the CMS already builds correctly, and using it there only adds another place for the data to drift.

A yoga studio's local business block: first draft and fixes

Take a yoga studio with a 24-page website that wants local business markup on its contact page. The page shows the studio name, a footer address, a phone number, opening hours of Monday to Friday 07:00 to 20:00 and Saturday 08:00 to 13:00 (closed Sunday), and no reviews. The drafter pasted the name and phone number but forgot the footer. This is the sort of first draft that comes back, with the studio name and URL as placeholders:

{
  "@context": "https://schema.org",
  "@type": "YogaStudio",
  "name": "Example Yoga Studio",
  "url": "/",
  "image": "/images/studio.jpg",
  "telephone": "[number as on the contact page]",
  "geo": { "@type": "GeoCoordinates", "latitude": 12.3456, "longitude": 65.4321 },
  "openingHours": "Mo-Su 06:00-21:00",
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.9", "reviewCount": "212" }
}

It is a ten-line block with six problems, and the validators reliably catch only two of them.

Problems 4, 5 and 6 are all syntactically perfect, which is why a validator-only routine would have shipped three false statements about the studio. The corrected block, with bracketed values to be copied from the live page, looks like this:

{
  "@context": "https://schema.org",
  "@type": "SportsActivityLocation",
  "@id": "https://www.example.com/#studio",
  "name": "Example Yoga Studio",
  "url": "https://www.example.com/",
  "image": "https://www.example.com/images/studio.jpg",
  "telephone": "[number as on the contact page]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "[as in the footer]",
    "addressLocality": "[town]",
    "postalCode": "[postcode]",
    "addressCountry": "[ISO country code]"
  },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "07:00", "closes": "20:00" },
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday", "opens": "08:00", "closes": "13:00" }
  ]
}

Choosing the subtype is a human judgement. Pick the most specific one that genuinely fits, and use LocalBusiness itself when none does. My tutorial on AI SEO tools for local SEO covers keeping the same name, address and phone details consistent across listings, which is what stops the markup contradicting the rest of the client's footprint.

The validation pass, in the order that saves time

1. Syntax. Paste the block into a JSON checker or the Schema Markup Validator first. A missing comma or a stray quote means the block cannot be parsed, and nothing downstream matters until it can.
2. Vocabulary. The Schema Markup Validator is the schema.org community's checker, which took over from Google's retired Structured Data Testing Tool. It tests markup against the schema.org vocabulary whether or not Google uses the type for a feature, so it catches invented types and properties, such as problem 1 above.
3. Google eligibility. The Rich Results Test describes itself as a way to test a publicly accessible page to see which rich results its structured data can generate. It has a URL tab and a code tab, with a choice of the smartphone or desktop inspection tool. Fix every error it reports before launch, read each warning and decide whether the page has the data to fill it, and remember that a passing result means eligible, not guaranteed.
4. Parity with the page. Google's guidelines say not to mark up content that is not visible to readers and that structured data must be a true representation of the page content. Go through every property with the parity table and the live page open side by side.
5. Duplicates and conflicts. Many sites already output markup from an SEO plugin or the theme. View the rendered source and look for two blocks describing the same business with different phone numbers, names or hours. Keep one source of truth.
6. Crawl-level check. For templates repeated across many pages, crawl the site rather than testing page by page. Screaming Frog's SEO Spider does not extract structured data by default, but once JSON-LD extraction is switched on it can validate against schema.org and against Google's rich result requirements, with required-property problems as errors and recommended ones as warnings. Its pricing page lists structured data validation in both the free and paid versions, with the free one capped at 500 URLs and a licence at $279 a year.
7. After launch. Google's introduction to structured data says to use the URL Inspection tool to confirm that Google has found the markup, and to check the rich result status reports after deployment to monitor validity.

What a pass does and does not tell you

Each tool answers one question, and agencies get into trouble by treating a pass as the answer to a different one.

Look at the right-hand column. Every tool in the table passes false statements as long as they are well formed. That is why parity with the visible page is a separate step with a named person attached to it.

Staging sites and the Rich Results Test code tab

Most agency launches start on a staging site that is closed to the public, which means the URL tab has nothing to fetch. Do not remove the login or the noindex setting just to run a test. Paste the generated block into the code tab instead; it tests the markup on its own, and you handle the match with the visible page by hand.

The workload shrinks if you test by template, not by page. For the studio's 24 pages there are five templates: home, contact, workshop page, shop product and news article. That is five Rich Results Test runs on staging, then a crawl of all 24 pages after launch to confirm that every page built from a template carries the same markup and no plugin has added a conflicting block. Without the template shortcut it would be 24 manual runs for the same information.

Product and event blocks: the mistakes generators repeat

Two more templates on the same site show how the errors differ by type. The shop sells yoga mats. A draft product block often comes back with a price written as "$39.00" inside the price field, an availability of "In stock" as plain text, a priceValidUntil date copied from an old template and no image at all. Google's merchant listing documentation asks for a name, an image and an offer with a price above zero and a three-letter currency code, its example uses a bare number such as 39.99 with the currency in its own field, and it recommends availability as a schema.org URL such as https://schema.org/InStock. It also warns that a listing may not display if priceValidUntil is in the past. That is four fixes from one block, and the Rich Results Test will flag some but not all of them. My tutorial on WooCommerce SEO with AI, meta descriptions and schema checks goes through the shop side in more depth.

The studio's workshop page is the event example. A typical draft writes the date as "14 June, 6pm", or as a midnight placeholder, leaves out the address, or marks up "Book now and save 10% this week" as an event. Google asks for a start date in ISO 8601, ideally with a UTC offset, tells you to avoid placeholder midnight times, requires a location with an address, wants one event per page with its own URL, and lists short-term discounts and purchase prompts among the things not to mark up as events. A weekly timetable is a list of classes, not an event page, so leave it without event markup.

Article blocks in bulk: the same modified date on sixty pages

Agencies often ask for article markup in bulk, and a generator given sixty headlines and one instruction will happily stamp the same dateModified, usually the day it ran, on every block. No validator objects, because a date is a date. The parity check does: the visible updated dates differ from page to page, and so do the publication dates. Take dates only from the page facts, say so in the prompt, and let the template fill them from the CMS fields when you can.

Google's article documentation lists no required properties, so the failures here concern truth, not eligibility. Three recur: a headline that differs from the visible title, an author written as the agency instead of the named writer, and an image that is not the one on the page. My rule is to sample five of the sixty against the live pages, and to check all sixty if two of the five fail.

Ratings and reviews are where generated markup turns risky

The invented 4.9 rating in the studio draft is a pattern to watch for, not a one-off. Generators often add stars to a local business block unprompted, so look for them in every draft. Google's review snippet documentation says pages are ineligible for the star feature when the entity being reviewed controls the reviews about itself, under LocalBusiness or any other organisation type, and that ratings must be sourced directly from users. Its general guidelines name fake reviews as misleading markup and warn that a structured data issue can lead to a manual action. Per Google, a manual action costs the page its rich result eligibility, and it does not change how the page ranks in ordinary web search.

The working rule for agencies is simple. A rating property goes in only when the reviews are real, visible on the same page, written by users and eligible for the type. Anything else the generator adds gets deleted at the parity check, and the client is told why.

What to tell the client about AI search and FAQ markup

Clients ask whether schema will get them into AI answers, and the honest reply is shorter than the sales pages suggest. Google's guidance on AI features says there is no special schema.org structured data to add, that a page must be indexed and eligible for a snippet in Search, and that it has no additional technical requirements. It lists matching structured data to the visible text as a best practice. I have not found vendor documentation showing that other assistants read JSON-LD to answer questions, so treat claims that they do as unproven. My tutorials on what to tell clients about llms.txt and on a client audit checklist for AI search take the same plain approach.

A paragraph you can adapt for the report: "We added structured data so search engines can read your business details accurately, and we validated it before launch. Google's own documentation says no special markup is needed to appear in its AI features, so we are not promising AI visibility from schema. What we can promise is accurate data and eligibility for the rich results Google supports." Pair it with the reporting limits in my tutorial on Search Console and AI Overviews reporting, so the numbers in the monthly report do not oversell either.

A launch-day sign-off sheet and the week-after check

One sheet per client closes the loop and gives the account manager something to point at. Here it is, filled in for the studio on launch day (illustrative).

After launch, run the URL Inspection tool on one page per template the same day and confirm that Google has found the markup. A week later, open the rich result status reports in Search Console and look for new errors or warnings by template. Repeat at one month, and log the dates on the sheet. If the site is rebuilt or a plugin is updated, the sheet is the thing you re-run, because the markup that passed last quarter is not the markup the new theme prints.

Markup drift: the block that was true at launch

Markup goes stale silently. Suppose the studio moves Saturday opening to 09:00 for the summer and updates the visible page the same afternoon, while the JSON-LD still says 08:00. Nothing breaks. The block validates, Search Console stays green and the wrong hours sit in the page source for months. Two habits prevent it. Feed the markup from the same data as the visible text, with template variables instead of pasted copies, so one edit changes both. And put a parity re-check on the calendar: quarterly for local businesses, and whenever hours, prices or addresses change. The sign-off sheet above doubles as the checklist.

Time and scope: pricing the check as its own line

On a five-template site my working budget is about 20 minutes a template: five to draft and read the MISSING list, five to run the validators and fix errors, and ten for the parity pass against the live page. That is 100 minutes, plus about 10 for the crawl and 20 for the sign-off sheet, so a little over two hours. Treat those as my estimates and time your own first few jobs.

Put the work in the proposal as a counted line, such as "structured data: draft, validate and sign off five templates", instead of "schema included", because the vague version invites a client to expect rich results. Add an exclusion in plain words: "No guarantee that Google will display rich results or AI features." My tutorial on an AI scope of work generator for agencies shows how to write counted deliverables and exclusions into a statement of work.

Questions agencies ask about AI-drafted schema

Do I need schema markup to appear in Google's AI Overviews?

No. Google's guidance on AI features says there is no special schema.org structured data you need to add. A page must be indexed and eligible to appear in Search with a snippet, and there are no additional technical requirements. Structured data still matters for the rich results Google supports, and it should match the visible text on the page.

Should I still add FAQ schema for clients?

Not for Google rich results. Google's changelog says the FAQ rich result stopped appearing from 7 May 2026, and the documentation was removed on 15 June 2026. FAQPage is still a schema.org type, but don't promise a visible result in Google. Spend the time on features still in Google's gallery, such as local business, product, article and breadcrumb.

Can the Rich Results Test check a staging site?

Only through its code tab. The URL tab is for publicly accessible pages, so a staging site behind a login is not a fit. Paste the JSON-LD into the code tab instead, then use the URL Inspection tool and Search Console's rich result reports on the live pages once the site has launched.

Does a passing Rich Results Test guarantee a rich result?

No. A pass means the markup is eligible for the features the tool detects, not that Google will show them. Google decides what to display. Markup that does not match the visible page can bring a manual action, which removes rich result eligibility, although Google says it does not affect ordinary ranking.

Can AI add review stars to a client's markup?

Only if the reviews are real, visible on the page and written by users. Google says pages where the business controls the reviews about itself are ineligible for star results under local business or organisation markup, and it lists fake reviews as misleading markup. If a generator adds a rating you did not supply, delete it.

Further reads

• How to Audit Your Website's SEO With AI in One Afternoon — Fit the schema check into a wider site audit.
• Scaled Content Abuse: An AI Content Checklist for SEO Agencies — The content-quality checks that sit beside markup.
• AI Keyword Clustering for SEO Agencies: Validate Clusters Before Sign-Off — Validate keyword clusters with the same sign-off habit.
• How to Monitor Brand Mentions in ChatGPT for a Client, Week by Week — Track what assistants say about a client after launch.
• How to Optimise Your Google Business Profile With AI — Keep the profile consistent with the LocalBusiness markup.
• Semrush AI Visibility vs Ahrefs Brand Radar: Which Suits an Agency? — Compare AI visibility tools before reporting on them.
• Consultant SEO for ChatGPT Search: Get Your Practice Recommended — Make a consulting practice easy for AI search to identify and cite: entity pages, case studies, reviews, schema and a fixed prompt test you rerun monthly.
• Content Refresh With AI: Update Old Articles and Track Rankings — A client-by-client method for choosing old articles, refreshing them with AI, and measuring the ranking change against pages you left alone.
• How to Improve AI SEO: Getting Your Firm Cited in AI Answers — A small-firm checklist for being cited in ChatGPT and Google AI answers, with checks you can do yourself and a way to test with prompts.
• SEO Agency AI: Which Jobs to Hand to AI and Which to Keep Human — A practical agency workflow showing where AI drafts help and where client judgement, evidence checks and approval stay with the team.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Google Search Central documentation (structured data gallery, general guidelines, introduction, AI features, and the local business, organisation, article, product, merchant listing, event, breadcrumb and review snippet pages), Google's search updates log, the Rich Results Test page and the Schema Markup Validator, Google's 2020 post on the Structured Data Testing Tool and schema.org's 2021 announcement of the Schema Markup Validator, and Screaming Frog's user guide and pricing page (all rechecked 4 November 2026).