Can AI Tell Who Runs Your Site? The Understand Pillar Explained

You can have valid schema markup on every single page of your site and still fail this one badly.

That sounds wrong, and it is the most useful thing to understand about the third pillar. Understand asks whether an AI system can work out who runs this business and how everything on the site connects to everything else. It is worth 45 of the 100 points in an AI Readiness score, more than the other three pillars put together, and it is the one that most sites with "good schema" quietly lose points on.

The reason is that valid markup and a connected graph are different achievements. Validity is a property of one block on one page. Connection is a property of your whole site. A page can pass every validator ever written while sitting there as an isolated island, describing itself to nobody, referencing nothing, referenced by nothing.

Discover asked whether a crawler could reach you. Read asked whether it could make sense of the page once it arrived. Understand asks the harder question that comes next: having read all of it, does the machine know who you are?

What Understand Actually Checks

Four things, and only the first is what most people expect.

Whether your business is identified at all. Is there an Organization or LocalBusiness declared anywhere on the site, with a real name, contact details, and the identifiers that pin it to a specific company rather than a generic one? This is the part most schema plugins do.

Whether the pieces reference each other. This is the graph, and it is the heart of the pillar. Does your Article declare a publisher, and does that publisher point at the same organization your homepage declares? Does your Service say who provides it? Does your Product name a brand? Every one of those is a link, and a site is a graph or a pile depending on whether they exist.

Whether the relationships that should exist for your kind of business actually do. A Product with no linked Brand or Offer. An Organization with no founder. An Article with no publisher. These are not validation errors, nobody's tool flags them red, and every one is a hole where a fact should be.

Whether there are trust pages. About, contact, privacy, terms, author pages. Unglamorous, and genuinely part of "who are you," because a business with no about page and no contact page has declined to answer the question in the most human way available.

The Graph Problem: A Pile of Blocks Is Not a Graph

Here is the failure that costs the most points and is almost never visible from looking at a single page.

Most schema output in the wild is per-page and self-contained. Your blog post has an Article block. Your homepage has an Organization block. Your service page has a Service block. Each one validates. Each one is correct. And each one is a separate statement floating in space, with nothing tying them together.

What makes them a graph is identifiers. In JSON-LD, @id is a node identifier: a stable URI that names a thing, so that other places can point at it rather than describing it again. Your homepage declares your organization once, with an @id. Every Article on the site then names that same @id as its publisher, instead of repeating a copy of your company details.

The difference this makes is not cosmetic. In the pile version, a machine reading your site finds forty separate mentions of your company name and has to guess whether they are forty companies or one. In the graph version, it finds one company that forty pages point at. The second is a fact. The first is an inference, and inferences are where AI systems get you wrong.

This is why the @graph output format matters more than it sounds: one block per page containing every entity on that page, cross-referenced by ID rather than duplicating data inline. It is a long-established pattern in schema implementations that take connectivity seriously, and it is the only way any of this works at all.

What that looks like in the markup

Stripped to the bones, the pile version has your blog post saying this:

{
  "@type": "Article",
  "headline": "How to Repipe a Victorian Terrace",
  "publisher": { "@id": "https://example.com/#organization" }
}

and your homepage saying this:

{
  "@type": "Organization",
  "name": "Example Plumbing"
}

Those two look fine individually and every validator will pass them. But the homepage never declares an @id, so the publisher reference on the article points at an identifier that exists nowhere. The article promises a publisher and delivers nothing.

The graph version changes one line. The homepage declares its identifier:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Plumbing"
}

Now the reference resolves, and every article on the site that uses the same @id inherits a real, single, named publisher. One line, and forty floating mentions of a company name become forty pointers to one company.

The Four Ways a Graph Breaks

When the engine resolves every @id reference across a site, four specific problems turn up over and over.

A dangling reference. A node points at an @id that does not exist anywhere on the site. Your Article claims a publisher; nothing declares that publisher. The reference looks like an answer and resolves to nothing. This is the worst of the four, for reasons in the next section.

An orphaned entity. An entity is declared and nothing ever references it. Your Person node for the author exists, correctly, on its own page, and no article ever names it. The data is real, and it is doing no work, because nothing connects it to the content it was meant to explain.

A duplicate entity. The same real-world thing declared multiple times with different identifiers. Three different @id values for one organization, usually because three different plugins or templates each emitted their own. A machine now has three companies with the same name and no way to know they are one.

A missing relationship. No error, no broken link, just an absent connection that should be there for this kind of business. The Service with no provider. The Product with no brand. The Recipe with no author. Nothing is wrong; something is simply not said.

Only the first of those looks like a problem in any validator. All four cost you.

Why a Dangling Reference Is Worse Than Saying Nothing

There is one rule underneath all of this that is worth stating on its own, because it inverts what most people assume:

A fabricated or dangling reference scores worse than omitting the property entirely.

A half-true claim is treated as worse than an honest gap. If your Article simply has no publisher, a machine knows it does not know, and can go looking. If your Article claims a publisher that resolves to nothing, the machine has been handed something that looks like an answer and is not one. The first is a gap. The second is misinformation with good manners.

This is the same principle behind entity grounding, where a correct-sounding answer with nothing backing it is treated as a failure rather than a success. The pattern repeats at every level of this work: being reliably silent beats being unreliably confident.

It also has a practical consequence that surprises people. When you find a dangling reference, deleting it is a legitimate fix. You do not have to build the missing entity today. Removing a promise you are not keeping improves the picture immediately.

Trust Pages: The Unglamorous Half

Schema is not the only evidence of who you are, and the engine deliberately looks for the plainest possible signals: an about page, a contact page, a privacy policy, terms, author pages.

There is no clever mechanism here. These pages exist on essentially every legitimate business site and are frequently missing on sites that are thin, abandoned, or pretending. Their presence is weak evidence on its own and meaningful evidence in aggregate, which is exactly how a machine reading a stranger's website should treat them.

If you are missing a contact page with real contact details on it, that is a twenty-minute fix that improves both this pillar and the experience of every human who wanted to reach you.

Why This Pillar Carries 45 of 100

The weighting is deliberate and worth explaining, because it looks lopsided until you see the reasoning.

Discover and Read are table stakes. They are real, they matter, and a competent developer can fix most of their failures in a week. A blocked robots.txt is one line. A missing H1 is one tag. These are checklists.

Graph connectivity is not a checklist. Resolving @id references across a whole site, catching orphaned and duplicate entities, and knowing which relationships should exist for a plumber versus a podcast versus a SaaS company is accumulated domain knowledge about how schema.org actually models the world. It cannot be shortcut, and it is where the difference between a correct site and a merely valid one lives.

That last part deserves emphasis, because it is where generic schema output falls down hardest. Knowing that a Product should have a Brand and an Offer, that a Service should have a provider, that a LocalBusiness in one industry needs a service area while another needs a street address, is a different kind of knowledge from knowing how to emit valid JSON-LD. The first is why two sites with identical validator results can score forty points apart.

Common Mistakes

Assuming a green validator means a connected site. Validators check one block against a spec. They do not resolve references across your site, and they will happily pass a page whose publisher points at nothing.

Letting three plugins each emit their own organization. The single most common source of duplicate entities. If your SEO plugin, your theme, and your schema plugin all describe your business, a machine sees three businesses. Pick one source of truth and suppress the rest.

Building entity data on the homepage and stopping. A perfect Organization block that no other page references is an orphan with good credentials. The value is in the references, not the declaration.

Treating a missing relationship as harmless because nothing turned red. Most of what costs points in this pillar produces no error anywhere. Absence is not flagged; it is just absent.

Adding sameAs links to profiles you do not control. Worth its own warning, and sameAs rules are easy to break in ways that hurt rather than help.

Fabricating a founder, an address, or a founding date to fill a field. Never do this. An empty field is a gap. A wrong field is a false statement that other systems may cross-check against reality and find wanting.

Confusing this with visibility. A strong Understand score means AI systems can correctly describe you. It does not mean they will choose to mention you, and that distinction is the whole point of readiness versus visibility.

How to Check and Fix Understand Issues on Your Own Site

1. Find out how many organizations your site declares. View the source of your homepage and search for "@type": "Organization" and "@type" values ending in the local business types. If you find more than one describing the same company, you have a duplicate entity problem, and it is usually two plugins both trying to help.

2. Pick one @id for your business and check that it never changes. Every page that references your organization should use the same identifier, character for character. A trailing slash difference is a different entity as far as a machine is concerned.

3. Take one blog post and trace its publisher. Find the publisher reference in its JSON-LD, then go looking for where that @id is actually declared. If you cannot find it, you have found a dangling reference, and you have found the single most common one on the web.

4. List the relationships your business type should have, then check for each. A product site: does every Product name a Brand and carry an Offer? A service business: does every Service name a provider? A publisher: does every Article name an author and a publisher that both resolve?

5. Delete what you cannot back up. Any reference pointing at nothing should either be given a real target or removed. Removing it is a real fix, not a cop-out.

6. Check your trust pages exist and are reachable. About, contact, privacy, terms. Not linked only from a footer image, not behind a form, just present and crawlable.

7. Fill in the identity fields you genuinely have. Legal name, founding date, contact details, the profiles you actually control. Building the entity profile properly is its own piece of work and the highest-return thing you can do after the graph is connected.

Steps 1 through 3 are the ones worth doing today. They take about twenty minutes on one page and they tend to reveal whether you have a graph or a pile.

Want to see whether your site is a graph or a pile? Run a free AI readiness check and get your entity graph resolved, with dangling references, orphans and duplicates listed by name.