You can, and the JSON it hands back will usually be valid. That is the trap. Schema markup fails in a way validators do not catch: perfectly formed code that states things about your business which are not true. AI is very good at the syntax and genuinely unreliable about the facts.
We use language models for structured data every week, so this is not a warning against the tool. It is a warning about which part of the job you are actually delegating. Writing JSON-LD by hand is tedious and error-prone, and handing that off is sensible. Deciding what your page claims about itself is not something to hand off.
The difference matters more with structured data than with almost any other kind of content, because schema markup is a set of formal assertions made directly to search engines.
Schema markup is structured data you add to a page so machines can understand what it contains. It uses the schema.org vocabulary, usually written as JSON-LD in a script tag. It does not change what a visitor sees. It tells search engines that this number is a price, this text is a job title, this block is a review.
The vocabulary is large and it moves. Schema.org publishes versioned releases, and version 30.0 was dated 19 March 2026, adding things like a Credential class and equivalence mappings to GS1 and Dublin Core. So a model trained months ago may not know the current shape of the vocabulary you are asking it to use.
Search engines only act on part of it. Google's structured data gallery documents 31 supported features, covering types such as Article, Product, Breadcrumb, Event, Job posting, Local business, Organization, and Video. Marking up something outside that set is not wrong, but it will not produce a rich result. We covered the fundamentals in our guide to what schema markup is and how it boosts your SEO.
Structure. A capable model will produce well-formed JSON-LD with correct nesting, sensible property names, and the right overall shape for a common type. For an Article, a BreadcrumbList, or an Organization block, the skeleton it gives you is usually close to what you would have typed yourself.
It is also fast at the boring parts. Converting a page outline into a first draft of markup, adapting one template across twenty pages, or translating between two schema types are all mechanical jobs where a model saves real time and makes few structural mistakes.
It handles the awkward corners of the format well too. Nested objects, arrays of authors, date formatting, and the difference between a plain string and a linked entity are the things people get wrong by hand and models get right by pattern. That is genuine value.
Where we have found it consistently useful is as a second reader. Pasting existing markup in and asking what is missing or inconsistent surfaces gaps quickly, and the failure mode there is a wasted suggestion rather than a false claim on a live page.
It fills in blanks. Asked to write Product markup, a model will happily produce an aggregateRating with a plausible score and review count, because that is what Product markup usually looks like. Nothing about the request told it those reviews exist, and nothing in the output signals that it guessed.
The same thing happens with opening hours, price ranges, founding dates, author names, and event locations. Each invented value looks reasonable in isolation. Together they turn a page into a set of confident statements about a business that nobody at that business ever made.
Models also drift toward outdated types. Structured data guidance changes, and support for particular rich results has been narrowed over the years. A model reproducing patterns from older content can suggest markup for a feature that no longer produces anything, which wastes effort even when the data is honest.
The last failure is subtler. A model asked for schema will often mark up content that is not actually on the page, because it is working from your description rather than from your HTML. Google's structured data policies are direct about this, stating that you should not mark up content that is not visible to readers of the page.
Because Google treats misleading markup as a policy violation, not a mistake. The structured data general guidelines say plainly not to use structured data to deceive or mislead users, and not to mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.
The consequence is specific. Google's documentation explains that a structured data manual action means a page loses eligibility for appearance as a rich result, and notes that it does not affect how the page ranks in Google web search. So the punishment is targeted: you keep your rankings and lose the enhanced listings you added the markup to get.
That framing is worth sitting with. Every hour spent on structured data is spent chasing rich results. A manual action removes exactly that payoff while leaving the work in place. It is the least useful outcome available.
There is a plainer reason too. Publishing a rating your product never received is a false claim about your business, sitting in your own source code, with a timestamp. No amount of automation efficiency is worth that.
Run it through two different checks and then read it yourself. Google's Rich Results Test shows whether a page is eligible for a specific feature, and Google states that you can preview most features with it. The Schema Markup Validator at schema.org checks the markup against the vocabulary itself rather than against Google's requirements.
Neither tool answers the question that actually matters. Both confirm the code is well formed and eligible. Neither knows whether your business really has that many reviews, or whether the article was published on the date in the markup. Validation is a syntax check, and the risk here is semantic.
So the human step is a claim-by-claim read. Take every value in the JSON-LD and find it on the rendered page. If a number, name, date, or rating in the markup does not appear in the visible content, it either needs to be added to the page or removed from the schema. That single pass catches almost everything.
The habit is the same one we apply to any machine-written output. We wrote about the general version of it in our guide to fact-checking AI-generated content before you publish, and structured data is the case where the checking matters most, because the claims are machine-readable and permanent.
Anything that asserts a number about the real world. Review and aggregateRating markup, Product pricing and availability, Event dates and venues, JobPosting salaries, and LocalBusiness opening hours all describe verifiable facts. If the model gets one wrong, you have published a false statement to a search engine.
Review markup is the sharpest case. Google's policies name fake reviews specifically as an example of misleading content, and review data is exactly the field a model is most likely to fabricate, because Product examples in its training data almost always include one.
At the other end, the safe types are the ones that describe structure rather than substance. BreadcrumbList reflects your URL hierarchy. WebSite and Organization describe things you already know. Article markup mostly restates a headline and a date that are already on the page. Those are fine to draft with a model and verify quickly.
Our rule is simple enough to remember. If a wrong value in that field would embarrass you in front of a customer, a human confirms it. If a wrong value would only be untidy, a validator is enough.
We give the model the page, not a description of the page. Pasting the actual rendered content and asking for markup of only what is present removes most of the invention problem, because the model has nothing to guess from. Asking it to write schema for a page it cannot see is where things go wrong.
We also ask it to flag rather than fill. A prompt that says to leave a property out when the value is not in the source, and to list what it left out, turns the model's uncertainty into something visible. What you get back is markup plus a short list of gaps, which is far more useful than confident completeness.
The final step is always a person comparing the JSON against the live page. This is the same review discipline we apply to machine-written code, described in our piece on reviewing AI-written code before it ships. Structured data is code, it goes into production, and it should not skip review because it looks like configuration.
It helps indirectly, and less than people claim. Structured data makes the meaning of a page explicit, which is useful to any system parsing it. But no major answer engine publishes a documented promise that schema markup increases citation, and we are not going to invent one on their behalf.
What we can say is that the underlying work overlaps. Clear entity definitions, consistent naming, accurate dates, and explicit relationships between things help both traditional rich results and any machine trying to summarise your page. Schema is one way of doing that work, not a separate trick.
Our honest position is that schema markup is worth doing for the rich results Google documents, and that any AI visibility benefit is a bonus you should not build a business case on. Anyone selling schema as an AI ranking lever is describing a mechanism nobody has published. We took a similar line when we asked whether FAQ schema is still worth adding at all.
Yes, for drafting and for review, with a human confirming every factual value before it goes live. Used that way it removes the tedious part of structured data and keeps the part that carries risk in human hands. Used as a fully automated pipeline, it will eventually publish something false.
The workflow that survives contact with reality is unglamorous. Feed the model the real page, tell it to omit anything it cannot see, validate with both tools, then read every value against the page. That takes minutes and it is the difference between a time saver and a liability.
If you want a second opinion on the structured data currently on your site, or help setting up a process your team can actually follow, we are happy to walk through it. Reach out at phoenix.studio and send us a URL.
Tell us where you want to go. We'll tell you how we'd get you there.