When a check cannot see the markup you wrote

By Matt Kerr·Published 18 September 2026

The worst finding an audit can produce is not a wrong one. It is one that is wrong specifically about the people who did the work properly — where doing the job carefully is the thing that trips it. This is that finding, and the cause is a single word being compared as a word.

Seven profile links, and a report saying none

A consultancy publishes business markup on its site with seven sameAs entries in it, including the professional profiles anyone would name first. Good markup, done deliberately, of exactly the kind every guide asks for.

The report said:

Your Organization schema does not link out to any external profile.

That sits near the top of the action plan, so it is among the first things a reader sees — a flat contradiction of their own file, in the section that says what to do first.

The check was looking for a word, not a thing

Schema.org types inherit. A ProfessionalService is a LocalBusiness, which is an Organization. That is not a resemblance; it is the structure of the vocabulary, and anything that understands it treats the specific type as the general one wherever the general one is expected.

Our check asked for three type names and compared the declared type against those strings. A site declaring the accurate, more specific type matched none of them — and there are dozens of such subtypes.

Read that against who it hits. A site with no business markup at all got a true finding. A site that marked its business up precisely got told it had done nothing. The more exactly somebody followed the vocabulary, the more certainly the check went blind.

Two checks in one product, disagreeing about one site

The structured-data lane asks the same question — does this site declare a business identity? — and got it right on the same file. It consults a shared list of identity types whose own comment states the rule plainly: every subtype qualifies, because each one is the base type by inheritance.

That list had existed all along, in the same codebase, for exactly this purpose. The check above it simply did not read it. The knowledge was not missing; it was in another file.

The deliberate half, which looks identical and is the opposite

Worth separating, because "two checks are about the same thing" is not automatically a fault.

When no business identity is found at all, this check now says nothing. Not because it has no view, but because the structured-data lane already reports that at high severity, and reporting the same defect twice would take two bites out of one score for one fix. That deference is designed.

Two checks overlapping is fine. Two checks disagreeing is the bug. If a report describes the same page two different ways, one of them is reading something the other is not, and that is the thing to chase — see when the numbers add up to more than your site → for the arithmetic version of the same problem.

This is not the same as declaring the wrong type

Elsewhere we make the case that a schema type is a factual claim about what you are →, and that picking a type you do not have is a real error. Both are true and they point in opposite directions for a tool:

• Choosing your type: be accurate, and prefer the specific one that genuinely describes you.
• Reading someone's type: accept every type that inherits from the one you were looking for, because the specific one is the general one.

The failure here was the second, caused by people doing the first correctly.

Checking your own report

1. When a finding says your markup lacks something you can see, look at the type first. If you declared a specific business type and the finding names the generic one, that is the signature.
2. Search your markup for the property, not for the type name. The property is what matters; the type is what the tool was matching on.
3. Look for the same question answered elsewhere in the report. If one lane says you have business markup and another says you do not, you have found a disagreement rather than a defect.
4. Validate with the search engine's own testing tool. It resolves inheritance, because it is the parser that actually decides.

When the finding is real

Keep the weight where it belongs. If sameAs genuinely is absent, a model has a string where it could have had a resolved entity — it cannot connect your site to the business it already knows about from a professional profile or a reference database. It is among the cheapest things on any list to fix, which is exactly why a false version of it is expensive: it spends the credibility of a finding people would otherwise act on.

The fixes that make it worse

• Changing your accurate specific type to the generic one to satisfy a tool. You would be making your markup less true so a report goes quiet. The tool is the thing that is wrong.
• Adding a second, generic node beside the specific one. Now two blocks describe one organisation, and anything reading them has to decide which you meant.
• Filling the array to clear the line. Profiles you do not control are a claim about somebody else's accounts — whose accounts are in your sameAs →.

How to satisfy this check without being findable

Put any plausible URLs in the array. Nothing in a crawl verifies that a profile is yours, so the finding clears on the presence of links rather than on the existence of an entity. The check can see that you pointed somewhere; it cannot see whether anything points back. Which is the actual job — the value is in the profiles being real, being yours and carrying the same name, and no audit can confirm any of that from your markup alone.

Where this sits in an audit

The registered check is ai.entity, which asks whether a model can resolve your site to a business it already knows. For what the property does and which URLs belong in it, see sameAs and entity signals →. For the type declaration itself, see a schema type is a claim about what you are →.

Common questions

Why does an audit say I have no Organization schema when I do?

Check which type you declared. Schema.org types inherit, so a specific business type is an Organization — but a tool comparing the declared type against a list of names will miss every subtype. Declaring the accurate type is what trips it.

Should I change my schema type to Organization so tools recognise it?

No. That makes your markup less accurate so a report goes quiet. The specific type is correct and carries the same properties; the tool is what needs fixing.

Two findings in one report disagree about my site. Which is right?

Whichever one is reading more of your markup. A disagreement means the two checks match on different things — usually one accepts inherited types and the other compares names. Validate with the search engine's own tool, which resolves inheritance.

Is it a problem that two checks cover the same thing?

Overlap is fine and often deliberate: one of ours stays silent when another lane already reports the same defect, so a single fix does not cost the score twice. Disagreement is the problem, not overlap.

Does a full sameAs array prove anything?

Not by itself. Nothing in a crawl checks that a profile is yours or that it points back, so the finding clears on the presence of links. The value comes from the profiles being real, being yours and carrying the same name.