JSON-LD that validates can still leave your entity graph broken

Every block can be correct and the family still not know who belongs to whom.

Listen, every block on a page can be correct and the page can still be wrong, the way every sentence in a family story can be true and the story still leaves out who married whom. In a knowledge-base pilot at AEO Content, the article written by reading the product end to end, from the admin setting to the screen a user actually sees, caught the admin page calling two-factor sign-in an authenticator app while the real sign-in screen sends a one-time code by text and email. Each screen made sense alone. Together they contradicted each other, and an article written from the documentation would have repeated the wrong one.

Schema does the same thing. So ask whoever set up your markup one question: which @id does our company have, and does every page use it? An AI engine like ChatGPT or Perplexity has to read the whole house.

Practitioners smelled this years ago, you know. In a 2018 r/SEO thread on how people use Schema.org, every commenter who named a format picked JSON-LD, mostly because it pastes neatly into a header, and one of them was already adding social sameAs links to steer Google's knowledge panels, with a warning that the same links had to appear in the visible HTML too. Further down, somebody asked whether adding JSON-LD on top of old inline markup would hurt. Nobody answered. Well, that question is still sitting there, and now the machines answer it for you, not always kindly.

What does a schema validator check, and what does it never look at?

A validator reads each JSON-LD block alone, for syntax and vocabulary. It never asks whether your article, your author and your company point at each other.

Before you trust a green result, look at three things on one page:

1. Count the script blocks. More than one usually means more than one copy of somebody.
2. Find every author and publisher. See whether each is a full object written out again or a pointer by @id.
3. Match every reference to a node. Each @id you point at should be declared on the page, with a type.

Listen, a validator is a proofreader, it is not a genealogist. One agency guide that sells this work says the validator catches a missing comma or an unescaped quote, and it does, and then it goes home. Lucian Ghinda's tutorial from 2025 is an honest picture of how most blogs do it: a WebSite block in one script, a BlogPosting in another, and the author written out in full inside the BlogPosting, like an uncle who comes to every wedding and introduces himself again each time. Only mainEntityOfPage carries an @id. Every block can pass. Nothing ties the man to the company. The same tutorial put JSON-LD use at around 30% of websites in 2025, citing Search Engine Journal, so this is not a corner case, this is the neighborhood.

Yoast does it the other way. It puts Organization, WebSite and WebPage nodes into one @graph array, gives each an @id, and the WebPage says isPartOf by pointing at the WebSite's @id instead of repeating it. Practitioners comparing plugin output have noticed that most generators still emit a single @type with its properties, and Yoast is the odd one out.

The common assumption is that a clean report means the entity work is done. It means the commas are right. An analysis of 5 sources behind this section shows the same split every time: validity is checked block by block, identity lives between the blocks, where nobody checks.

Even the vocabulary is forgiving about the small stuff. In schema.org GitHub issue #854, opened on Oct 28, 2015, the project aliased id and type so a publisher who forgets the @ does less damage. A forgotten @ can be forgiven. A link you never wrote cannot be, there is nothing there to forgive.

Alex and I bring a combined 40+ years of SEO and content infrastructure experience to AEO, and I would put it to any client plainly. A machine believes what you connect, not what you meant. If you want the basic terms first, our AEO FAQ on AI search walks through them. So a pass tells you the grammar is right, and the family tree, well, that is a separate document, and on most sites nobody has drawn it yet, which is how an author ends up an orphan on his own blog.

Does a broken entity graph hurt you if Google says AI Overviews need no special schema?

Maybe not for ranking, and nobody has proven schema earns citations. The damage is to attribution: a disconnected graph leaves machines guessing which company and which person said it.

I want to be fair to the skeptic here, because the skeptic has good material. Google says AI Overviews and AI Mode need no special schema.org markup, only a page that is indexed and eligible for a snippet. OpenAI, Anthropic and Perplexity have published no guidance on how their retrieval systems treat JSON-LD, according to one agency's roundup of the research. The same roundup reports a controlled test in which 1,885 pages that added JSON-LD showed no meaningful citation lift against 4,000 control pages, though every page in that test was already cited more than 100 times. So a page that was already famous got no richer. Fine. That says nothing about a page nobody has met yet.

On the other side of the table, Microsoft's Fabrice Canel said in March 2025 that schema markup helps Microsoft's language models understand web content for Copilot. Understand is the word. Not rank, not cite. Understand.

Now, listen, here is where I come down. Schema is a comprehension tool, and the graph is the part of it that carries identity. Jason Barnard said on the Search Engine Journal Show in 2021 that in his own experiment, building small child entities and linking them to the parent entity tripled the confidence score Google's Knowledge Graph held for that entity. He was talking about links, you understand, not more types, not more blocks. Links.

One AI-visibility vendor puts the failure in a sentence I keep thinking about: "The model has the fact but cannot attribute it to you, so it cites the aggregator that copied you." That is their pitch, and I hold it at arm's length. Still, it names the right fear. Your article says something smart, and the machine credits a stranger, and your author, who stayed up writing it, is nobody in particular.

A vendor's 2026 review of AEO tools also reports that Yoast added an opt-in Schema Aggregation feature in March 2026 that merges duplicate entities across a site. You do not build a merge button for a problem nobody has.

The honest position, then:

• Graph repair is not a ranking lever. Nothing here says it is.
• It is attribution insurance. It tells a machine the article, the person and the company are one family.
• It breaks quietly during rebuilds. A theme swap or a plugin change can rename every identifier while every block still validates.

That last one is why I tell anyone planning an AI-friendly website migration to diff their identifiers before and after launch, because the old @id for the company and the new one look alike to a person and nothing alike to a parser, and the question becomes how you would ever catch it.

How do you test JSON-LD as one connected graph instead of block by block?

Expand every block to full URIs, list each declared @id beside each reference, and fail the page when an author or publisher points at nothing.

Here are the five steps I would run on any page, in this order:

1. Collect every block from the raw HTML. View the source, not the browser inspector, and copy out each application/ld+json script, the plugin's, the theme's, the one somebody pasted in years ago and forgot.
2. Expand them. The JSON-LD Working Group's Best Practices note says expanded form is useful when validating that entity descriptions "say what the publisher means." Expansion turns a short term like familyName into http://schema.org/familyName, as the Linking Data in JSON Community Group's API note shows, so two blocks can no longer hide behind different shorthand.
3. Confirm one entry point. The same Working Group note says a document SHOULD be a single top-level object. A single @graph gives you that.
4. Make two lists and diff them. One list holds every @id declared as a node with a type. The other holds every @id referenced by author, publisher, isPartOf, worksFor and friends. Anything referenced but never declared is an orphan.
5. Repeat across three page types. Home, an article, an author page. The company's @id must be the same string on all of them.

That last step is the one people skip. A graph can be perfect on one page and split across the site, the home page calling the company one thing, the blog template calling it another, both valid, both lonely.

Now, a word on the rules themselves. The Working Group labels its note unofficial and says its SHOULD language is advisory. Nobody is going to arrest you. So you hold yourself to it, the way you hold yourself to calling your mother.

Two judgment calls come up every time. First, the identifier is not the thing. The Best Practices note warns that a Wikidata page for a person is a description of him, not the man himself, so I keep a profile URL in sameAs and mint the @id on a domain the company owns and controls. Linked-data practitioners have said the same for years: an identifier you own outlives the hosting deal you forgot to renew.

Second, the founder who is also the firm. A performer once described marking up both a Person and an Organization on one site, while the ticketing platform's own event markup left the performer out entirely. The link existed on one side only. If you are both, declare both and connect them, or a credential lands on the wrong one, or on neither, and you are a stranger at your own party.

This is the same discipline we bring to research-driven content built on evidence: you trace each claim to its source, and you trace each entity to its node. Then you run the diff again after the next plugin update, because the plugin, believe me, has not read this.

What should change the next time someone audits your schema?

Stop asking only whether each block is valid and start asking whether every author, publisher and page points to one declared @id. Then ask to see where each one is declared.

Here is where I think this goes. In a 2025 r/TechSEO thread, a poster noticed that most generators and plugins still emit a single @type per block, while Yoast wraps Organization, WebSite and WebPage into one @graph and has the page point at its site by @id instead of repeating it. One commenter said the point was to avoid defining the same Organization info in multiple places. Another called it a workaround for syntax. Well, both can be right. The family still has to sit at one table.

My bet is that the pasted, block-by-block habit fades over the next year or two and the connected graph becomes the ordinary way a site introduces itself. Maybe the validators catch up, maybe not. Until then, listen, the uncle keeps introducing himself at every wedding, and ChatGPT keeps wondering whether he's even related to you.