Consistency beats completeness: schema for machines, not results

Most structured-data advice optimises for rich results. Agents do not care about rich results. Let’s look at what they read, and the three fields that do the work.

Let’s notice a habit that a decade of SEO has trained into all of us. When someone says structured data, we reach for completeness. Fill in every property the type allows, chase the rich result, and treat a green tick in the validator as the finish line. That instinct is not wrong for rich results. It is wrong for agents, and it can quietly do you harm.

Here is the principle that replaces it, and it is close to the opposite of what most guides teach: consistency is more valuable than completeness. A schema with five correct, stable, cross-page-consistent properties beats one with fifty where the entity name drifts, the sameAs links do not resolve, and the ID changes from page to page. The extra forty-five properties do not merely fail to help. If they contradict each other, they drop the system’s confidence in the whole entity. More markup is not automatically more signal. Sometimes it is more noise, of course.

The reason sits in what an agent is trying to do. When it parses a clean JSON-LD field, it reads a fact for almost nothing. When it has to infer that same fact from your prose, it spends on the order of a thousand times the compute — and it does not always succeed. Structured data is how you hand facts over cheaply and unambiguously. But only if the facts you hand over agree with each other and with the rest of the indexed web. Let’s dive into what that actually requires.

One canonical name, applied character-for-character

Start with the most boring and most common failure. The same entity appears on your site as Acme Corp in the organisation schema, Acme Corporation on the About page, and plain Acme in a sameAs target. To you these are obviously the same company. To a resolver they may be three different nodes, because there is no canonical form to match against, and the Knowledge Graph can end up fragmenting one company into several thin, competing entities. This is how a knowledge panel quietly falls apart.

The fix is direct and almost embarrassingly cheap. Pick one canonical name form. Write it into a style guide. Apply it character-for-character everywhere the entity is named — in schema, in prose, in metadata, on LinkedIn, on Crunchbase, in your Wikidata entry, and crucially in the display names on your sameAs targets, so the name your schema points to matches the name that renders on the page it points at. One decision, applied with discipline, and the fragmentation stops.

Valid is a floor, not a ceiling

Passing validation tells you your syntax is legal. It tells you nothing about whether the schema is useful, and the gap between those two things is where most implementations live. Let me show you the contrast with two organisation blocks that both pass the validator cleanly.

The first: type Organization, name Acme, description We are a company that does things, a URL. That is it. No ID, no sameAs. It validates. It is also useless — it disambiguates nothing, corroborates nothing, and could describe half the companies on earth. The second block has fewer aspirations and more spine: a stable ID, the name Acme Corporation matching Wikidata and LinkedIn exactly, a specific description, a URL, two sameAs links that actually resolve to pages whose names match, a founding date in ISO 8601, and employee count expressed as a QuantitativeValue range. Fewer showy fields, every one of them doing work. Passing validation is a floor. It is not a ceiling.

The three fields that do the interpretive work

If you audit only three properties, audit these, because they are the ones that turn valid schema into useful schema. First, the @id: a stable, resolvable URI — the convention I use is a hash fragment on the canonical URL plus the entity type — that must never change. It is the key everything else resolves to. Second, sameAs: manually verified external links, each opening to a page whose displayed name matches your canonical name exactly. A sameAs that resolves to a mismatched name is not a neutral omission; a failed corroboration signal is worse than an absent one, because now you have handed the system a contradiction to chew on.

Third, description: specific enough to classify the entity even if you deleted the type declaration entirely. Run the test on your own. We are a company that does things fails — strip the type and it classifies nothing. B2B inventory management software for mid-market manufacturers passes — strip the type and a system still knows exactly what it is looking at. These three fields are the difference between markup that is merely present and markup that resolves, corroborates and classifies.

The schema an agent never sees

Here is a failure that is invisible unless you know to look for it, and it catches a great many WordPress and Shopify sites. Many schema plugins inject their JSON-LD with JavaScript, after the page loads. A JS-rendering search engine executes that script and sees the schema. An agent doing a direct fetch of your raw HTML does not run your JavaScript, so it sees nothing — the markup you spent effort on simply is not there for the visitor that matters most in agentic retrieval.

So ship server-side-rendered JSON-LD in the head, present in the raw HTML before any script runs. And diagnose it with the right tool: browser View Source, which shows you the raw document, not dev tools, which show you the rendered DOM after JavaScript has already done its work. If your schema block appears in dev tools but not in View Source, it is client-side injected, and to a direct-fetch agent it does not exist. This one check separates schema that works from schema that only looks like it works.

Five errors that keep recurring

Across audits the same five mistakes come up again and again, and none of them are exotic. I will keep each one short, because the value is in recognising them, not in a long treatment:

1. Wrong type on the page. A CMS stamps Organization onto every URL, so your blog posts and product pages all claim to be the company. Match the schema type to what the page actually is.
2. Schema only on the homepage. One good block on the front page and nothing elsewhere. Target contextually appropriate schema on at least 80 percent of your indexed pages.
3. Broken or mismatched sameAs. A link that 404s or resolves to a different name. Verify every sameAs manually — a failed corroboration signal is worse than none.
4. The blank-node person. A Person nested as author or founder with a name but no ID is anonymous and unreferenceable. Give every named entity its own ID URI.
5. Aspirational schema. A job title of Senior AI Researcher in markup against Marketing Manager on LinkedIn. The cross-check fails and the whole record loses confidence. Schema should describe the verifiable record, not the aspirational one.

Schema removes ambiguity. It does not add authority.

That line is the guardrail for this entire topic. Schema helps directly with entity disambiguation and rich results, indirectly with getting into the Knowledge Graph, and partially with LLM citation. It does nothing for standard ranking — that is a confirmed non-signal — and it cannot manufacture topical depth, external corroboration, or credibility you have not earned. It cleans up the interpretation of what already exists. It does not invent standing. Which does not mean schema is optional. It means schema is the floor you build on, not the building.

Run the audit in under thirty minutes

You can pressure-test your own organisation schema conceptually in half an hour, and it is worth doing before you touch a single property. On your homepage, open the raw source and find the Organization block. Check four things: is there an @id, and is it a stable URI; does each sameAs open to a page whose name matches your canonical name exactly; does the description classify the org even with the type removed; and — this is the cross-page part people skip — is the entity name the identical string on a blog post, a product or service page, and a team page? Same name, same ID, everywhere.

When you do this, run every finding through the two tools honestly: Google’s Rich Results Test and the schema.org validator check syntax only, so read their output manually rather than trusting the green tick. Validation confirms your markup is legal. It does not confirm it is consistent, and consistency is the thing an agent is actually reading for.

Where this goes next

So the shift is this. You are not decorating pages for a rich result anymore. You are handing an agent a small set of facts it can resolve, corroborate and classify without guessing — and the discipline that makes that work is consistency, not volume. Five stable fields that agree with each other and with the outside world beat fifty that argue among themselves.

The half-hour audit above is enough to find your worst problems. Turning it into a repeatable, page-by-page pass — with the wrong-and-right code for each of the five errors, the description classification test, and the exact ID convention — is the worked version I give you inside the course. Schema removing ambiguity is only half the story, of course: the other half is the corroboration that supplies the authority schema cannot, which is exactly what trust isn’t a schema field is about. And once your structured data is stable, your audience is no longer only human covers designing the content itself so it survives extraction.