Organization and WebSite Schema: A Sitewide Identity Model

A practical guide to building a consistent JSON-LD identity model with stable Organization, WebSite and page-level references across templates.

Many websites do not have a Schema.org vocabulary problem. They have an identity consistency problem.

The same publisher may appear under slightly different names across templates. One logo URL is used on the homepage, another on articles and a third in a CMS component. Some pages reference a website; others create a new one. A service page may even be described as an Organization because its template copied the homepage markup.

These inconsistencies make a graph harder to maintain and audit. They also obscure which nodes are intended to represent the same organisation, website and page-level subject.

This article sets out a practical implementation model: define canonical Organization and WebSite nodes, give durable entities controlled @id values, reference those nodes from page-level graphs and govern the relationships across templates and releases. It is an implementation pattern, not a Google requirement or a promise of rankings or enhanced search features.

Model identity once, then reference it consistently

JSON-LD describes a graph. A node can be given an IRI through @id, and another node can refer to it with an object containing only that @id. A page therefore does not need to recreate the full description of its publisher every time it references that publisher.

For a typical corporate website, the graph should distinguish at least four things:

• Organization: the organisation responsible for publishing or operating the site.
• WebSite: the collection of related pages served as a website.
• WebPage: the individual page being described.
• Page-level subject: the principal thing the page is about, such as an Article, Service or Product.

Schema.org defines WebSite as a set of related web pages and other items typically served from a single web domain. Its vocabulary also supports page relationships such as isPartOf, mainEntity and publisher. The practical implication is that these nodes can be connected without treating them as interchangeable.

A service page is not an Organization because the company provides a service. An article is not a WebSite because it sits within the site. Each node should represent the thing it actually describes.

A worked identity model

Consider a fictional software company, Northstar Cloud Ltd. It publishes a website at https://www.northstarcloud.example/, containing product and service pages alongside a learning centre.

Its controlled identity register might define these durable identifiers:

• https://www.northstarcloud.example/#organization for Northstar Cloud Ltd.
• https://www.northstarcloud.example/#website for the main Northstar Cloud website.
• https://www.northstarcloud.example/platform/#webpage for the platform page.
• https://www.northstarcloud.example/platform/#service for the service or product subject represented on that page.
• https://www.northstarcloud.example/learning/data-security-guide/#webpage for the guide page.
• https://www.northstarcloud.example/learning/data-security-guide/#article for the article represented on that page.

This fragment convention is not required by Schema.org or Google. It is a readable implementation choice that keeps identifiers under a domain controlled by the organisation. A different durable IRI scheme can work just as well if it is documented and applied consistently.

A simplified sitewide graph could look like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.northstarcloud.example/#organization",
      "name": "Northstar Cloud Ltd",
      "url": "https://www.northstarcloud.example/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://www.northstarcloud.example/#logo",
        "url": "https://www.northstarcloud.example/assets/logo.svg"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://www.northstarcloud.example/#website",
      "url": "https://www.northstarcloud.example/",
      "name": "Northstar Cloud",
      "publisher": {
        "@id": "https://www.northstarcloud.example/#organization"
      }
    }
  ]
}
</script>

The Organization and WebSite are separate nodes. The WebSite points to its publisher rather than duplicating a second, slightly different Organization object. The logo also has a controlled reference, helping prevent templates from silently switching between logo assets.

Connect a page to the sitewide identity

Now add the platform page. The page itself is a WebPage, while its main subject is a Service. The example uses isPartOf to connect the page to the website, publisher to identify the publishing organisation and mainEntity to identify the page’s principal subject.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://www.northstarcloud.example/platform/#webpage",
      "url": "https://www.northstarcloud.example/platform/",
      "name": "Cloud Data Platform",
      "isPartOf": {
        "@id": "https://www.northstarcloud.example/#website"
      },
      "publisher": {
        "@id": "https://www.northstarcloud.example/#organization"
      },
      "mainEntity": {
        "@id": "https://www.northstarcloud.example/platform/#service"
      }
    },
    {
      "@type": "Service",
      "@id": "https://www.northstarcloud.example/platform/#service",
      "name": "Cloud Data Platform",
      "provider": {
        "@id": "https://www.northstarcloud.example/#organization"
      }
    }
  ]
}

This relationship design is a Liquid Silver implementation recommendation based on the available Schema.org vocabulary. It does not mean every page must emit every possible relationship, or that Google requires the complete graph to be repeated in every template.

For the learning-centre guide, the page-level subject would instead be an Article:

{
  "@type": "Article",
  "@id": "https://www.northstarcloud.example/learning/data-security-guide/#article",
  "headline": "A Practical Guide to Data Security",
  "mainEntityOfPage": {
    "@id": "https://www.northstarcloud.example/learning/data-security-guide/#webpage"
  },
  "publisher": {
    "@id": "https://www.northstarcloud.example/#organization"
  },
  "author": {
    "@id": "https://www.northstarcloud.example/#organization"
  }
}

Use the Organization as author only if it genuinely authored or owns the editorial responsibility for the article. If an individual wrote it, model that person as a Person with their own accurate identity and relationship. Domain ownership alone does not establish authorship.

What should remain stable?

An @id identifies a modeled node; it is not a hash of the current copy. If the underlying entity remains the same, its identifier should normally survive changes to:

• page title or descriptive copy;
• navigation labels and site taxonomy;
• component design and template structure;
• the order of properties in the JSON-LD;
• the page’s internal links;
• the logo file, provided it is still the same governed organisation logo.

For example, changing the platform page from “Cloud Data Platform” to “Northstar Data Platform” does not create a new service if the real-world offering is unchanged. Its page and service identifiers can remain stable while the governed name is updated.

That rule has a clear boundary: identifiers should not be retained merely because changing them is inconvenient. A genuine change in the modeled entity may require a new node. An acquisition, demerger, transfer of publishing responsibility or creation of an independent subsidiary needs a deliberate migration decision.

A rebrand of the same organisation will often justify retaining the Organization identifier and updating the name, logo and supporting properties. A legally or operationally distinct organisation will often need its own Organization node. The correct decision depends on the real business relationship; Schema.org does not provide a universal test for every corporate structure.

Govern name, logo, URL and type centrally

Identity properties should not be assembled independently by each template. Maintain a controlled source for at least:

• the canonical Organization @id for each genuinely shared organisation;
• the governed organisation name and public-facing name where they differ;
• the canonical website @id and URL;
• the website name;
• the approved logo URL or ImageObject;
• the relationship between the website and publisher;
• the rules for regional, brand, subsidiary and editorial entities.

Schema.org allows logo to be represented by a URL or an ImageObject. In either case, the asset should be the approved logo, accessible to crawlers and consistent with the visible identity on the relevant site. Structured data must accurately represent visible page content. Google warns against misleading markup and does not guarantee a rich result or other search appearance from valid markup.

For Google’s site-name use case, Google documents WebSite structured data on the home page and identifies name and canonical url as required properties for that specific implementation. Its guidance treats domains and subdomains as site-name boundaries and does not support separate site names at subdirectory level. That search-display guidance should not automatically be treated as the complete organisational model for a complex enterprise estate.

Google also recommends Organization structured data on the home page or a page describing the organisation, and states that the information does not need to be included on every page. A sitewide identity model therefore does not require a full Organization object in every template. A page-level publisher reference can be appropriate where the relationship is accurate, while the canonical Organization description remains concentrated on the relevant identity page.

Brands, subsidiaries, authors and regional variants

Large sites often have more than one legitimate identity. The answer is neither to force every name into one Organization node nor to create a new publisher for every marketing label.

• Brand: model a distinct brand when it has an independent, relevant identity. Keep the operating or publishing organisation as the publisher where that is the factual relationship, and connect the brand through the appropriate property.
• Subsidiary: use a separate Organization when the subsidiary is a real organisation with its own role. Describe its relationship to a parent rather than replacing the parent everywhere.
• Author: use a Person for an individual author, or an Organization where an organisation genuinely authored the work. Do not infer authorship from the domain alone.
• Regional site: decide whether the regional property represents the same website, a separate website or a local organisation. Domain and subdomain boundaries may matter for Google site-name treatment, but they do not answer every internal governance question.
• Editorial imprint: keep an imprint distinct if it is a meaningful publishing entity, then document whether it is the author, publisher or brand for each content type.

The governing principle is factual accuracy. A repeated ID does not prove that two descriptions refer to the same real-world entity. If one template attaches “Northstar Cloud Ltd” and another attaches “Northstar Cloud US Inc.” to the same Organization ID, the graph has become contradictory rather than more authoritative.

Implementation sequence

1. Define the identity boundary

Document which organisation publishes the site, which website is being modelled and where brands, subsidiaries, regional sites and editorial imprints sit in relation to those nodes. Resolve uncertainty before writing template logic.

2. Create an entity register

List the canonical Organization, WebSite, logo, key people, brands and page-level entity patterns. Record the preferred name, URL, type, owner and relationship for each. This register becomes the source for implementation and review.

3. Establish ID rules

Choose a durable IRI convention. Define which IDs are sitewide, which are page-specific and what event triggers a new identifier. Make the policy explicit for rebrands, migrations, acquisitions and changes in publishing responsibility.

4. Build a shared identity layer

Generate the canonical Organization and WebSite nodes from one controlled configuration rather than separate hard-coded snippets. Decide which templates need full nodes and which need references only.

5. Add page-specific relationships

For each template, identify the WebPage, its website, its publisher and its principal subject. Add Article, Service, Product or another type only when it accurately describes the visible purpose of the page. Do not add a type because a template happens to support it.

6. Test source and rendered output

Check both the HTML source and the rendered page. Google can process dynamically generated JSON-LD, but JavaScript failures, consent logic, timing, duplicate injection and rendering differences can change what is available to crawlers. A page that passes in a development browser is not automatically equivalent to the deployed output.

7. Add relationship tests to release governance

Test for the expected canonical Organization ID for each shared organisation, the expected WebSite ID for each modeled website, valid publisher references, correct isPartOf links, accurate page-level types, consistent names and logos, and URLs that match the canonical page. For a large RDF implementation, SHACL can express graph constraints. For many sites, lightweight custom tests are more proportionate.

These checks complement, rather than replace, syntax and vocabulary validation, Google-facing tests where relevant and manual review of visible content. A valid JSON-LD result does not prove that the graph is semantically correct.

Definition of done

An identity model is ready for release when:

• the organisation and website boundaries are documented;
• canonical Organization IDs are defined for genuinely shared organisations, and WebSite IDs are defined for the websites being modelled;
• names, URLs and logo references come from governed data;
• page-level IDs distinguish the WebPage from its main subject;
• page-level entities reference the website and publisher only where those relationships are accurate;
• brands, subsidiaries, authors and regional entities have documented modelling rules;
• IDs remain stable through ordinary copy, navigation and template changes;
• genuine entity changes have a migration process rather than an automatic ID reset or silent ID reuse;
• JSON-LD is checked in source and rendered output;
• custom relationship tests run against representative templates and releases;
• visible branding, about information, canonicalisation, crawlability and logo accessibility support the claims made in the graph; and
• ownership is clear for future changes to names, logos, templates and publishing relationships.

Sitewide identity checklist

• Have you identified the real publisher for each page type?
• Is there one controlled Organization ID for each genuinely shared organisation?
• Is the WebSite node distinct from the Organization node?
• Does each page have a page-specific ID rather than reusing the site or organisation ID?
• Does the page’s main entity reflect its visible purpose?
• Do publisher, website and logo references resolve to the intended canonical nodes?
• Are public brand names, legal names, website names and editorial imprints kept distinct where necessary?
• Would the identifiers survive a copy, navigation or template change?
• Are source and rendered JSON-LD outputs both tested?
• Would a human reviewer find the organisation, website and page relationships accurate from the visible site?

The proportionate next step is to audit a small representative set of templates: the homepage, an organisation or about page, a service or product page, an article, and any regional or branded variant. Compare their source and rendered graphs against the identity register, then fix the shared model before expanding coverage. For implementation support, see technical SEO and SEO implementation. For a separate production-governance perspective, see our structured data drift QA framework.

The important distinction is between a stable reference and a proven real-world identity. Stable IDs make a graph easier to connect, test and govern; they do not establish that the underlying entity is genuine, nor do they replace clear branding, authoritative about information, crawlable pages, accurate canonicalisation or other corroborating signals. Treat the model as an identity-governance layer and its value is operational: fewer contradictory nodes, clearer template logic and safer changes over time.