Schema markup: connect real entities, do not invent signal.

Does there have to be only one script block?

The three rules that matter more than the number of blocks: markup describes the content of the page it sits on; you never add a price, rating, author, image or identity that is not real and verifiable; and you validate syntax with the Schema Markup Validator and eligibility with the Rich Results Test.

Which nodes do we connect?

What does a cohesive graph look like in practice?

The difference is easiest to see in an example. This is a common pattern that creates duplicates:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "publisher": {
    "@type": "Organization",
    "name": "Example Ltd",
    "logo": "https://example.com/logo.png"
  }
}

If that object is repeated on every page, each copy is a separate, unconnected description. When one detail changes you have to change it everywhere, and you will miss one. The cohesive version looks like this:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Ltd",
      "url": "https://example.com/",
      "logo": { "@id": "https://example.com/#logo" }
    },
    {
      "@type": "ImageObject",
      "@id": "https://example.com/#logo",
      "contentUrl": "https://example.com/logo.png",
      "width": 512,
      "height": 512
    },
    {
      "@type": "Article",
      "@id": "https://example.com/article/#article",
      "headline": "Article title",
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": { "@id": "https://example.com/article/#webpage" }
    }
  ]
}

The organisation is described once. The logo is a full ImageObject with dimensions rather than a bare URL. The article is tied to its page and to its publisher by reference, not by copy.

How are identifiers written?

A fragment must not contain a date, a version or a title. #article-2026-august breaks the moment the text is updated, and every change to an @id severs all references pointing at it.

Which types are most used, and when?

The most frequent error in this table is Product on a page that describes a service. If there is no stock, no shipping and no returns, it is a Service. The second is LocalBusiness on a site with no physical location — an aggregator or an online-only service does not belong there.

How is an entity connected to external sources?

Name matching is unreliable. “Precise Search SEO” is distinctive, but “Delta” or “Metro” are not. Where a stable external identifier exists, the connection stops being guesswork.

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://en.wikipedia.org/wiki/Example",
    "https://www.linkedin.com/company/example",
    "https://www.crunchbase.com/organization/example"
  ]
}

The same principle applies to authors, with one extra obligation: a Person node only makes sense when the author has a visible biography on the site and verifiable presence off it. On this site we removed the Person node for that reason and attached all attribution to the organisation — one verifiable entity is stronger than two weak ones.

What if the same entity exists on several domains?

The situation is common: an agency has its own site, a client project and a profile on a third-party platform. If each defines its own Organization node with its own @id, you end up with three entities instead of one.

// On the secondary domain — a reference, not a new definition
{
  "@type": "WebPage",
  "@id": "https://second-domain.com/page/#webpage",
  "publisher": { "@id": "https://primary-domain.com/#organization" }
}

In addition, both domains should list one another in the sameAs array of the primary entity. The connection is then bidirectional and does not depend on the search engine matching two names on its own.

Which mistakes do we see most often?

How is it validated?

1. Schema Markup Validator for syntax and graph structure. It reports errors Google does not have to report.
2. Rich Results Test for eligibility for specific displays. Eligibility is not a guarantee of display.
3. Search Console reports for the state of the whole site over time.
4. A manual check that every value in the markup also exists in the visible content. No tool does this step for you.

Implementation order on a new site

1. Organisation and website. Two nodes with stable @id values at the domain root. Everything else attaches to them later.
2. The logo as a full ImageObject with dimensions, not as a string.
3. Page and article per document, with the mainEntityOfPage relation in both directions.
4. The path as a BreadcrumbList with consecutive positions.
5. The business-specific type — Service, Product or LocalBusiness — only once the first four are stable.
6. sameAs references last, once the external profiles genuinely exist.
7. FAQ and images only where the visible content is already there.

The order is not arbitrary. Each step references the previous one, so skipping ahead means changing @id values later — and every such change severs the references pointing at them.

Frequently asked questions