Your structured data can be valid and still fail to connect

A page might contain schema for:

• an Organization;
• a WebSite;
• a WebPage;
• a Person;
• a BlogPosting;
• and a SoftwareApplication.

Each individual entity can be accurate.

The organisation can have the right name, logo and social profiles. The article can have the right headline and date. The software can have the right category and operating system.

But accurate entities are only part of the picture.

The markup should also be able to express that:

• the organisation publishes the website;
• the webpage belongs to that website;
• the organisation provides the software;
• the person authored the article;
• and the organisation publishes the article.

Those relationships turn separate descriptions into a coherent graph.

Without them, a machine can still read the individual facts, but it may be left to infer which entities belong together.

In JSON-LD, @id gives an entity a stable identifier.

For example:

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

Other entities can then use that identifier when declaring a relationship to the organisation:

{
  "@type": "BlogPosting",
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

That reference makes it explicit that the publisher of the article is the same organisation already described elsewhere in the structured data.

This is one of the most useful things about @id: it lets several parts of a graph refer to one identified entity without creating a fresh, potentially separate description each time.

Many schema checks stop at a simpler question:

Does this entity have an @id?

That is a useful check. Stable identifiers are particularly helpful for important entities such as organisations, websites, people, products and services.

But the presence of an identifier does not tell you whether anything else in the graph uses it.

A page might give its Organization, WebSite, WebPage and SoftwareApplication entities separate @id values while never using those identifiers to express a relationship.

The page then contains several identified entities, but the markup may not clearly establish how they fit together.

That is the gap SiteVitals now looks for.

It is important not to overstate this.

An @id without an incoming reference is not automatically an error.

Some entities act as the starting point of a graph. A root Organization, for example, might point outwards to several other entities without anything pointing back to it.

Other entities may legitimately stand alone.

So the useful question is not simply:

Does every @id have something pointing to it?

It is:

Are there relationships that should have been expressed using the identifiers already declared on the page?

An unreferenced @id is therefore something to inspect, not proof that the structured data is broken.

We have written before about entity disambiguation : properties such as sameAs and knowsAbout that help describe who an entity is and what it is associated with.

Our data showed that 98% of the URLs we surveyed had not implemented the full combination.

That is a real and important gap.

But entity disambiguation and graph cohesion answer different questions.

An Organization can have excellent sameAs references and detailed knowsAbout properties while remaining separate from the WebSite, WebPage, BlogPosting or SoftwareApplication declared alongside it.

sameAs helps identify an entity.

Properties such as publisher, author, provider, brand, mainEntity and parentOrganization help connect it to other entities.

A page can do the first well and still miss the second.

Our own homepage gave us a useful example.

It contained six schema entities:

• two Organization entities;
• a SoftwareApplication;
• a WebSite;
• a WebPage;
• and an FAQPage.

Five of the six had an @id.

Both organisations had verified sameAs links to profiles including LinkedIn, Crunchbase and Trustpilot. Between them, they also had fifteen knowsAbout topics.

By the schema checks we already had, the page was in very good shape.

But none of those entities referred to another entity's @id.

The software did not identify the organisation that provided it. The page did not identify the website it belonged to. The entities were individually described, but the identifiers already present were not being used to express their relationships.

That was the gap we wanted SiteVitals to expose.

The new check is called entity_graph_cohesion.

It runs after the structured data on a page has been parsed and validated.

For each @id declared on the page, it looks for references through relationship properties such as:

• author
• publisher
• provider
• organizer
• brand
• mainEntity
• parentOrganization
• and other relevant properties used by particular schema types.

If a BlogPosting points to a Person entity through that person's @id, that is an explicit connection.

If a SoftwareApplication identifies an Organization as its provider using the organisation's existing @id, that is another.

The check highlights identifiers that are declared but not referenced elsewhere on the page, so you can review whether a meaningful relationship may have been missed.

It does not assume that every unreferenced identifier is wrong.

Consider an article that declares its publisher like this:

"publisher": {
  "@type": "Organization",
  "name": "SiteVitals",
  "url": "https://www.sitevitals.co.uk"
}

Elsewhere on the same page, there might already be a fuller organisation entity:

{
  "@type": "Organization",
  "@id": "https://www.sitevitals.co.uk/#organization",
  "name": "SiteVitals",
  "url": "https://www.sitevitals.co.uk",
  "sameAs": [
    "https://www.linkedin.com/company/sitevitals"
  ]
}

Those descriptions may clearly look like the same organisation to a person.

But without a shared identifier, the structured data does not explicitly establish that they are the same node.

The article can make that relationship clearer:

"publisher": {
  "@id": "https://www.sitevitals.co.uk/#organization"
}

The complete organisation description remains elsewhere in the page's markup, while the BlogPosting points to the same identified entity.

This also reduces duplication.

When an organisation's name, URL, logo and social profiles are copied into several schema objects, those copies can drift apart. One may contain an old logo, another an outdated name, and another a different URL.

Using a stable identifier makes it easier to maintain one consistent representation of the entity.

Yes.

This is valid JSON-LD:

"publisher": {
  "@id": "https://www.sitevitals.co.uk/#organization",
  "@type": "Organization",
  "name": "SiteVitals"
}

The properties are contributing information about the same identified entity.

That is not inherently wrong.

However, repeatedly asserting the same properties in several parts of the markup can create a maintenance risk if those descriptions later conflict.

A common pattern is therefore:

1. include one fuller description of the entity within the page's graph;
2. give it a stable @id;
3. reference that identifier from the other nodes that relate to it.

No.

An @id is particularly useful where an entity:

• appears in several places;
• is referred to by other entities;
• represents an important person, organisation, website, product or service;
• needs to be distinguished from similar entities;
• or should remain consistently identified across multiple pages.

A small nested entity that is used only once may not need its own identifier.

The aim is not to add an @id everywhere simply to satisfy a check. It is to use stable identifiers where they make the graph clearer and more consistent.

Also no.

Some entities are legitimate root nodes. Some have outgoing relationships rather than incoming ones. Others are deliberately independent.

That is why SiteVitals treats this as a structural finding to review rather than a basic validation error.

The detail panel shows which declared identifiers are not referenced elsewhere on the page, so you can decide whether:

• the entity is correctly acting as a root;
• the entity is genuinely standalone;
• a relationship is missing;
• or the same real-world entity has been described more than once without being consolidated.

Most structured-data testing tools focus on one or more of these questions:

• Is the JSON-LD syntactically valid?
• Are the Schema.org types and properties recognised?
• Are required fields present?
• Is the page eligible for a particular rich result?
• Are there warnings in a search engine's interpretation of the markup?

Those are all important checks.

But a page can pass syntax validation and rich-result requirements while still containing weak or ambiguous relationships between its entities.

Entity graph cohesion is a different layer of quality.

It asks whether the markup merely contains valid entities, or whether those entities are connected in a way that reflects the real relationships represented by the page.

This check validates the structure of the page's own structured data.

It does not prove that:

• an AI platform will use the relationships;
• a search engine will rank the page differently;
• the page will receive more citations;
• or a language model will retrieve the business more often.

We do not have visibility into every system's indexing and retrieval process, and we are not going to pretend otherwise.

What we can check precisely is whether the markup supplies a coherent set of identifiers and relationships for a machine consumer to process.

A connected graph gives those systems clearer information to work with.

A collection of repeated or isolated entity descriptions leaves more interpretation to the consumer.

SiteVitals already had a check called schema_graph_linking, which looks at whether schema entities declare an @id.

We have kept entity_graph_cohesion separate because it measures something different.

A page can pass the first check and still have possible missed relationships. Our own homepage did.

Combining the two would hide that distinction. It would also alter existing scores without making clear what had changed.

The new check therefore appears separately under Schema & Structured Data, with its own status and detail panel.

It does not currently affect the AI Visibility score.

We would rather show you the finding clearly and let you decide whether the relationships need improving than quietly move a score without explanation.