Invalid schema markup earns no rich results and generates errors in Search Console. The Schema Debugger validates your JSON-LD against schema.org specifications and Google's rich results requirements, showing exactly what is wrong and how to fix it.
Every schema type has required properties that must be present for the schema to be valid. Product requires name and at least one of offers, review or aggregateRating. FAQPage requires at least one Question with an acceptedAnswer. The debugger shows exactly which required properties are missing.
Some properties require specific value formats. Price must be a decimal number — "29.99" not "£29.99". Date must be ISO 8601 format — "2026-05-15" not "15 May 2026". URL properties must be absolute URLs with the https:// prefix.
@type values must exactly match schema.org type names. "FAQ" is wrong — it must be "FAQPage". "Local Business" is wrong — it must be "LocalBusiness" (no space, capital B). The debugger flags invalid type names.
A missing comma, unclosed bracket or unescaped quote character will break the entire JSON-LD block. The debugger shows the exact line and character where the JSON syntax error occurs.
Almost every misunderstanding about schema debugging collapses into one confusion: treating validation as an outcome. It is not. There are three distinct states, and passing the first tells you very little about the third.
Valid means the JSON-LD parses and the properties exist in the schema.org vocabulary. This is a syntax check. A page can be perfectly valid and useless.
Eligible means the markup satisfies Google's requirements for a specific rich result — which are narrower than schema.org's, and which mandate properties that schema.org treats as optional. Schema.org will happily accept a Product with no price. Google will not show a product rich result without one.
Shown means Google actually displayed the enhancement, which it decides per query, per page, and frequently declines to do. Eligibility is a precondition, not a promise.
The practical consequence: a validator that reports "no errors" has told you that you have not made a mistake. It has not told you that anything will happen. Sites routinely celebrate a clean validation and then wait indefinitely for a rich result they were never eligible for.
An error means a required property is missing. The rich result will not appear. This is unambiguous and must be fixed.
A warning means a recommended property is missing. The rich result may still appear — but it will be less complete, less prominent, and it will lose to a competitor whose markup is fuller.
Warnings are routinely dismissed as cosmetic, and this is a mistake. Two pages both eligible for a product rich result, one with price, availability, rating and review count, the other with price alone, do not receive the same treatment. The richer result occupies more space and carries more information at the moment of decision. The warning was the difference.
The most common error and the easiest to fix. Google publishes the required set per type, and it is not always intuitive: Recipe requires image; Product requires either offers, review or aggregateRating; Article requires headline. Missing any of them makes the page ineligible entirely, not merely diminished.
Properties like availability take a fixed set of values from a schema.org enumeration. "availability": "In stock" is invalid. "availability": "https://schema.org/InStock" is what was meant. This error is common because the invalid version looks obviously correct to a human, and it fails silently.
A price expressed as "£24.99" rather than "24.99" with a separate priceCurrency. A date written as "12 March" rather than in ISO 8601. Dates are the biggest offender here — schema.org expects 2026-03-12, and anything else is discarded.
Markup that declares an Organization and an Article with no relationship between them. The pieces are individually valid and collectively meaningless. Use @id to link them — the Article's publisher should reference the Organization's @id rather than restating it.
A CMS adds schema. A plugin adds schema. A theme adds schema. The page now carries three Organization declarations with different names, and Google has to pick. This is one of the most common problems on WordPress sites and it is invisible unless you look at the source.
Every validator checks whether your markup is well-formed. None of them check whether it is true.
Markup must describe content that is actually visible on the page. Six FAQ questions in the JSON-LD and three on the screen will validate cleanly, will pass the Rich Results Test, and is a structured-data violation that can trigger a manual action — which removes rich results across the entire site, not merely the offending page.
This is the single most dangerous gap between "the tool says it is fine" and "the markup is fine", because every automated check will pass while the site accumulates risk.
The failures are usually accidental rather than deliberate:
The most frustrating case: clean validation, correct type, no rich result. Work through this in order.
Run the Rich Results Test, not only a schema.org validator. They answer different questions, and a page can pass the vocabulary check while failing Google's requirements entirely.
If the JSON-LD is injected by JavaScript, Googlebot's first pass will not see it — rendering happens later, from a separate queue, and can take days. Use the URL Inspection tool to view the rendered HTML Google actually holds. Markup that only exists after JavaScript runs is markup that is not reliably read.
An unindexed page cannot show a rich result. This sounds obvious and it is the answer surprisingly often, particularly on large sites where a substantial fraction of pages are crawled and never indexed.
If rich results have disappeared across the whole site rather than on one page, this is the signature. Search Console reports it directly.
Google shows rich results more readily to sites it already trusts. A newer domain with immaculate markup will wait longer than an established one with sloppy markup, and there is no lever for this beyond the slow accumulation of authority.
A page whose schema never produces a visible enhancement in Google has not wasted the work, and the reason has become more important than the original one.
Answer engines read the page directly. When ChatGPT, Perplexity or an AI overview uses your content, it is parsing your HTML rather than querying an index that has already understood it. Structured data is the only part of a page that states unambiguously what a thing is — this is the price, this is the question, this is the answer, this rating is out of five. Everything else must be inferred from prose, and inference is where models make mistakes: quoting a struck-through price, inventing an opening time, attributing a competitor's review to you.
Being cited incorrectly is worse than not being cited. Markup that Google declines to display can still be the reason an answer engine quotes you accurately — which makes clean, honest structured data worth maintaining regardless of whether it ever produces a star rating in a search result.
Schema.org defines several hundred types arranged in a hierarchy, and the instinct when uncertain is to reach for the general one. That instinct is wrong, and it costs you.
The more specific type always carries more meaning and permits more properties. LocalBusiness is better than Organization. Dentist is better than LocalBusiness. A Dentist can express things a generic Organization cannot, and both search engines and answer engines can do more with the richer declaration.
The opposite error is worse: choosing a type because of the rich result it produces rather than because it describes the page. Marking a product page as a HowTo to obtain numbered steps, or an ordinary article as a Recipe, is a violation regardless of whether the markup validates. The type must be what the page is.
Where a page is genuinely several things — an article that reviews a product, a page that is both a local business and a service — declare both in an @graph and link them by @id. That is what the graph structure exists for, and it is more accurate than forcing a page into a single type that only half fits.
Structured data does not stay right. It decays, silently, and the decay is invisible because nothing on the page looks broken.
The mechanism is always the same: the markup and the content it describes are maintained separately. Someone edits a price, a question, an author name, an opening time. The visible page updates. The JSON-LD does not, because it lives in a template, a plugin setting, or a block of hand-written script nobody remembers owning.
Generate the markup from the same source as the content. If the price on the page comes from a database field, the price in the markup must come from that same field — not from a value typed into a plugin a year ago. Hand-written markup describing dynamic content will always drift eventually; the only question is when, and how long it takes anyone to notice.
Validation only means the syntax is correct. Eligibility requires meeting Google's specific requirements, which are narrower than schema.org's. And even an eligible page may not be shown — Google decides per query and per page, and shows enhancements more readily to sites it already trusts.
An error means a required property is missing and the rich result cannot appear. A warning means a recommended property is missing — the result may still appear, but less completely, and it will lose to a competitor with fuller markup. Fix errors first, then warnings you have honest data for.
Yes, and it is normal. The problem is conflicting blocks — a CMS, a plugin and a theme each declaring a different Organization. Google then has to choose. Check your rendered source, because this is invisible otherwise.
It must be a schema.org enumeration URL, not plain text. "In stock" is invalid; "https://schema.org/InStock" is correct. The invalid version looks right to a human, which is why it survives review.
Not directly. It determines eligibility for rich results, which change how your result is displayed rather than where it sits — and it determines how accurately AI answer engines can read and cite your page. Both are valuable; neither is a ranking boost.
Run the Schema Debugger and get results in minutes. Pay as you go.
Debug Schema →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.