Site-wide `@graph` bundle

Organization, WebSite and Local business as one linked block, with each entity given an @id the others point at.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Marlow Road Coffee",
      "url": "https://example.com/",
      "legalName": "Marlow Road Coffee Ltd",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Marlow Road Coffee",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "LocalBusiness",
      "@id": "https://example.com/#local",
      "name": "Marlow Road Coffee",
      "url": "https://example.com/",
      "address": {
        "@type": "PostalAddress",
        "addressCountry": "GB",
        "addressLocality": "London",
        "postalCode": "SE15 5AA",
        "streetAddress": "14 Marlow Road"
      },
      "parentOrganization": {
        "@id": "https://example.com/#organization"
      },
      "telephone": "+44 20 7946 0912"
    }
  ]
}
</script>

@graph · 3 entities

Place this once, site-wide — the home page is the usual choice. Other pages reference these entities by @id instead of repeating them.

Why one block rather than three

Three separate script tags parse perfectly well. What they do not do is state any relationship: a consumer reading them sees an organisation, a website and a shop, with nothing saying they are the same business. A @graph with @id references says the website is published by the organisation, and the location is a branch of it.

The maintenance argument is the stronger one, though. Three blocks means the organisation name is written three times, and when it changes it gets updated twice. One definition referenced by @id has one place to edit.

Where it goes, and what references it

Once, site-wide — the home page is the usual choice. Repeating it on every page adds no signal and multiplies the number of places that can drift.

Other pages then reference these entities instead of restating them. An Article on this site would carry "publisher": { "@id": "https://example.com/#organization" } rather than a fresh Organization node with the name and logo copied in. Our checker resolves those references across blocks, so a page that points at an @id defined elsewhere is read as connected rather than as a dangling reference.

One caveat worth stating: an @id reference that points at a node which does not exist on the same page is not resolvable by a consumer reading that page alone. The bundle has to be present on the page doing the referencing, which in practice means site-wide placement, not home-page-only, if other pages reference it.

Online-only businesses

Turn the location off. If customers cannot visit you, there is no local business to describe, and a LocalBusiness entity with a registered-office address that no customer has ever been to describes something that is not true. Organization and WebSite are the right pair on their own.