22 of 30 sites leave AI guessing who they are

Twenty-two of the 30 homepages in the study declare no Organization, WebSite, Person or LocalBusiness entity at all. That is 73% of the sample, and it includes several companies whose names a model certainly knows, because knowing a name and being told which domain owns it are different problems.

Nineteen of the 30 — 63% — have neither an entity node nor asameAs list. For those pages, every consumer has to infer the brand from the visible text, and inference is the part that goes wrong quietly: a model can know the company perfectly and still not attach its name to your domain.

What counts as declaring an entity?

One parsed JSON-LD block containing an @type of Organization, WebSite, Person or LocalBusiness. That is the whole rule, worth four points.

It is deliberately shallow. The scanner reads the types that appear anywhere in a graph that parsed, including nested ones, so a Person node inside an article’s author property satisfies it without an Organization node existing anywhere on the page. The evidence line names the types that matched, so a pass says what it saw rather than asserting that a brand entity exists.

How many of the 30 declare one?

Eight declare an entity type, nine carry a sameAs, six do both, and nineteen do neither. The overlap is the interesting part: the two properties are often added together, and the sites that have one without the other are the ones worth looking at.

What do the passing and failing pages look like?

The pattern is not the one people expect. Some of the highest-scoring pages have an entity and no sameAs; some of the lower-scoring ones have sameAswithout an entity.

Two of those rows are instructive. Salesforce scores highest in the whole sample and has no sameAs: the entity node is doing the identification work, and the profile links were never added. Shopify passes sameAs while declaring no entity, so the profiles point at something the page never names — a join without an anchor.

What does a model actually do with this markup?

It uses it to resolve a string to one thing. Organization withname, url and sameAs is the shape that says “this name, this domain, these profiles are the same entity”.

Without it, a consumer resolving your brand has to use the page text and whatever it already believes. That is not nothing — a large document with the company name written plainly is not invisible — but it is inference, and inference has failure modes a declaration does not: the wrong namesake, an abbreviated name, a rebrand, or a model that knows the company and not the domain.

This is why the two rules are scored in different dimensions. The entity node is a machine-readability property: can the parser see a thing to point at. ThesameAs list is a trust property: does the thing point at accounts that exist elsewhere. The first is about this page, the second is about your brand in the world.

Does the check prove the entity is correct?

No, and the rule pages say so. Presence is all that is tested: nothing fetches thesameAs profiles, and nothing compares the declared name to the page title.

That limit is worth knowing before optimising for it. A page can pass by declaring a Person node whose name appears nowhere in the visible copy, and a model reading both will notice the disagreement. The rule is a floor for parsability, not a certificate of identity.

What is the smallest markup that passes both rules?

One Organization node, one WebSite node that references it, and asameAs array. Replace the placeholders; do not leave them.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://your-domain.com/#organization",
      "name": "Your Brand Name",
      "url": "https://your-domain.com",
      "sameAs": [
        "https://github.com/your-account",
        "https://www.linkedin.com/company/your-brand"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://your-domain.com/#website",
      "url": "https://your-domain.com",
      "name": "Your Brand Name",
      "publisher": { "@id": "https://your-domain.com/#organization" }
    }
  ]
}
</script>

Two things about that snippet are deliberate. The @id values are fragments on the real origin, so every page can reference the same node rather than restating the brand. And the array is not padded: two profiles that exist are worth more than six that do not, because the property is a claim a consumer can check.

Which is worth doing first?

The entity node, because it is scored twice over — once directly and once as the anchor that makes sameAs mean something.

1. Add the Organization node to every page, or to a layout that wraps every page. Both work; one file is easier to keep true.
2. Add sameAs with the profiles you actually maintain. A dead profile is a broken claim, and a claim a model can disprove costs more than an absent one.
3. Validate the block parses. A syntax error is indistinguishable from absent markup to a consumer, and worse than nothing to a reader who thinks they added it.
4. Re-run the scan. The evidence line names the types that matched, so a pass is observable rather than assumed.

The guide with the full walkthrough is the Schema.org JSON-LD guide, and the arithmetic behind the weights is on the methodology page.