JSON-LD Checker Example: Schema.org Structured Data Audit

There are three ways to put structured data on a page, and the choice is not really a choice any more:

The decisive advantage of JSON-LD is that it is decoupled from the presentation. Microdata is woven into your markup, so a designer restructuring the layout silently destroys the structured data — the attributes end up on the wrong elements, or get dropped entirely, and nothing warns anybody. JSON-LD survives a redesign because it does not live in the layout.

The price of that decoupling is the entire risk of the format: because the markup is separate from the page, it can say things the page does not. That is not a licence — it is the vulnerability that Google's structured data policies exist to police, and the source of every manual action ever issued for spammy markup.

Worth adding, and with one absolute condition attached.

Two further points the check does not make:

• It must match what the page displays. A dateModified of last week alongside a visible "Published January 2024" and nothing else is a contradiction. If you are claiming an update, show the update.
• ISO 8601, with a timezone. 2026-01-15T09:00:00Z, as datePublished correctly has here. A bare 15/01/2026 is ambiguous and will be misread.

And on the headline passing at 54 characters: Google's Article guidance asks for under 110. Longer headlines can cause the whole Article block to be ignored. Worth knowing, because a CMS that pipes a long H1 straight into headline will breach it without anyone noticing.

The report labels author.sameAs as an E-E-A-T signal. This label is everywhere in the SEO industry and it is misleading in a way that costs people real time.

There is no schema property that confers E-E-A-T. Experience, Expertise, Authoritativeness and Trust are concepts from Google's Search Quality Rater Guidelines — a description of what human raters are asked to assess when evaluating search quality. They are not fields, they do not have a score, and no markup grants them. You cannot add E-E-A-T to a page with a JSON property.

What author.sameAs genuinely does is entity disambiguation. It points at the author's other established profiles, letting Google connect the byline on your page to a person it already knows about. That is real and it is useful — and it only works if there is an entity to connect to.

Adding the missing publisher is where most pages quietly acquire a contradiction, so it is worth doing correctly the first time.

The naive fix is to paste an Organization object inside the Article's publisher property. Then the theme emits its own Organization block. Then an SEO plugin emits a third. You now have three statements about who publishes this site, with three slightly different names, and Google's response to contradictory claims about one entity is to trust the page less — not to average them.

Declare each entity once, with a stable @id, and reference it everywhere else. The Article's publisher is not a second copy of your Organization; it is a pointer to the one already declared:

Contradiction then becomes impossible by construction, because each fact is stated exactly once. This page's own markup uses that pattern — two blocks in a single @graph, sharing identifiers.

Before adding anything, check what is already there. Search the served page source for application/ld+json and count the blocks. More than one block is fine. More than one block describing the same entity never is.

"AEO citation signal" is a phrase that needs unpacking, because a great deal of confident advice in this area rests on inference rather than evidence.

What is not established: that answer engines rank or select citations on the presence or volume of structured data. No major provider has published such a criterion. Claims that a given system "preferentially cites pages with rich structured data" circulate widely and are not confirmed by anyone who would know.

What is defensible, and it is not a small thing:

• Retrieval systems parse; most do not render. Whatever is in the served HTML is what they see. JSON-LD, being in the served HTML, is available to them in a way that JavaScript-injected content is not.
• It removes ambiguity. "£279" in prose could be a price, a saving, or a competitor's price. "price": "279", "priceCurrency": "GBP" cannot be misread. Structured data is a machine-readable restatement of things your page already says — and a system that does not have to guess is a system that gets you right.
• It names the entities. Who wrote this, who published it, what it is about, when it was updated — stated as facts rather than inferred from layout.

The distinction is worth holding on to. Structured data helps because it disambiguates, not because there is a lot of it. Adding markup to a thin page does not make it citable — it makes an unhelpful page unambiguously unhelpful. The content still has to be worth quoting.

What is JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) is Google's preferred method of adding structured data to web pages. It sits in a script tag in the page head and describes the page content in a machine-readable format. Google uses it to power rich results such as star ratings, product prices, recipe cards, event listings and breadcrumb trails. Note that the supported types change over time — FAQ rich results were restricted in 2023 to a small set of authoritative government and health sites, and HowTo rich results were removed entirely — so check Google's current documentation before building markup for a specific feature.

What makes a page rich result eligible?

Rich result eligibility requires all required properties for that schema type to be present and correctly formatted. For example, Product schema needs name, image and either offers, review or aggregateRating to be eligible for product rich results. The JSON-LD Checker shows exactly which required properties are missing.

How does JSON-LD help AEO?

Be careful with the common claim that AI search engines preferentially cite pages with rich structured data — no major provider has published such a criterion, and assertions to that effect are inference rather than confirmation. What is defensible is narrower and still worth having. Retrieval systems parse rather than render, so JSON-LD in the served HTML is available to them when JavaScript-injected content is not. And it removes ambiguity: a marked-up price cannot be misread as a saving, and the author, publisher and subject are stated as facts rather than inferred from layout. Structured data helps because it disambiguates, not because there is a lot of it.

Does author.sameAs improve my E-E-A-T?

No schema property confers E-E-A-T. Experience, Expertise, Authoritativeness and Trust are concepts from Google's Search Quality Rater Guidelines — a description of what human raters assess, not fields with a score attached. What author.sameAs actually does is entity disambiguation: it connects the byline to profiles Google already knows. That only works if there is an entity to connect to. Adding sameAs to an anonymous byline with no author page, no body of work and no established presence resolves to nothing. Build the entity first; the markup is the last step.

Should I add dateModified?

Yes, but only if it is true. A CMS that stamps today's date on every article on every rebuild is not signalling freshness — it is signalling that the field is meaningless, and Google stops using it. Once your dates are established as unreliable you have permanently lost the ability to signal a genuine update. It must also match what the page displays, and use ISO 8601 with a timezone.

How should I add the missing publisher?

By reference, not by copy. Pasting an Organization object inside the Article's publisher property is how pages acquire contradictions — the theme emits its own Organization block, a plugin emits a third, and Google's response to conflicting claims about one entity is to trust the page less rather than to average them. Declare each entity once in a single @graph with a stable @id, then point at it. Check the served page source for existing application/ld+json blocks before adding anything.

Will adding structured data get my page cited by AI systems?

Be careful with that claim. No major provider has published a criterion that ranks or selects citations on the presence or volume of structured data, and assertions that a given system prefers heavily-marked-up pages are inference rather than confirmation. What is defensible: retrieval systems parse rather than render, so JSON-LD in the served HTML is available to them when JavaScript-injected content is not; and it removes ambiguity, since a marked-up price cannot be misread as a saving. Structured data helps because it disambiguates, not because there is a lot of it — markup on a thin page just makes it unambiguously thin.

Both blocks on this page are valid, which means the hard part already went right. It very often does not — and the failures are not schema failures at all. They are transport failures, and a single bad character invalidates the entire block, not the offending line.

1. The CMS HTML-escaped it. The great one. A templating engine or rich-text editor that escapes its output turns every " into " and every & into & — inside the JSON. The block becomes unparseable, and it happens site-wide, at once, silently. Paste into a raw HTML or custom-code field, never a WYSIWYG editor.
2. Smart quotes. Round-trip the code through a document, an email or a chat window and straight quotes become typographic ones. JSON requires straight double quotes. It looks identical at a glance and fails completely.
3. A trailing comma after the last item of an object or array. Legal in JavaScript, illegal in JSON.
4. An unescaped quote inside a value. A headline containing a quoted phrase terminates the string early.
5. Injected by JavaScript. Google will usually pick it up on a later rendering pass, but that pass is delayed and not guaranteed — and consumers that parse rather than render, including many AI retrieval systems, will never see it at all. Server-render your structured data. A tag manager is a legitimate stopgap when you have no template access, and it should be treated as exactly that.