organization-website-schema 1.0.0

Organization / WebSite Schema Check v1.0.0

Status

Version: 1.0.0

Check identifier: organization-website-schema

Input contract: [email protected]

Output contract: [email protected]

Scope: page-level Schema.org identity graph discovery for the scanned site.

Abstract

This check verifies that a page exposes a durable structured identity for both the publisher entity and the website entity. A passing implementation includes an Organization node, a WebSite node, useful identity fields, a clear WebSite.publisher relationship, and trust signals such as logo, sameAs, or contact evidence.

The check is stricter than generic structured-data presence. A bare Organization type or a bare WebSite type is useful evidence, but it is not enough for a full pass because agents need a stable relationship between the site and the organization behind it.

Motivation

Organization and WebSite schema help search systems, answer engines, and agents identify who publishes a site, which website the current page belongs to, which brand or legal entity should receive attribution, and which external profiles help reconcile that identity.

For agent-readiness, the important outcome is not rich-result decoration. The important outcome is a durable identity graph:

• The organization has a name, canonical URL, and stable identifier.
• The website has a name and canonical URL.
• The website points to the organization as publisher.
• The organization exposes trust and reconciliation signals such as logo, sameAs, and contact fields.

Normative Model

The page SHOULD include Schema.org structured data containing an Organization node or a recognized Organization subtype.

The page SHOULD include a WebSite node for the scanned site.

Both nodes SHOULD use stable @id values. Common examples are https://example.com/#organization and https://example.com/#website.

The Organization node SHOULD include name and url.

The WebSite node SHOULD include name and url.

The WebSite node SHOULD include publisher, and publisher SHOULD reference the Organization node. An @id reference is preferred because it is stable and unambiguous.

The Organization node SHOULD include logo.

The Organization node SHOULD include sameAs links where authoritative external profiles exist.

The Organization node MAY include contactPoint, telephone, email, address, legalName, description, founder, foundingDate, parentOrganization, or other truthful Schema.org properties when relevant.

The identity URLs SHOULD use absolute URLs and SHOULD match the scanned origin unless the site intentionally represents a different canonical organization or parent brand.

Supported Syntaxes

This check accepts Organization and WebSite entities expressed as JSON-LD, Microdata, or RDFa. The runtime normalizes all three syntaxes before evaluating identity fields, publisher linkage, and trust evidence.

• In JSON-LD, the preferred pattern is a single @graph containing linked Organization and WebSite nodes. Stable identifiers come from @id; publisher linkage is strongest when WebSite.publisher references the Organization @id.
• In Microdata, Organization and WebSite entities are read from itemscope elements whose itemtype resolves to Schema.org types. Fields such as name, url, logo, sameAs, and publisher are read from descendant itemprop attributes; stable identifiers may come from itemid.
• In RDFa, Organization and WebSite entities are read from typeof subjects. Fields are read from descendant property attributes; stable identifiers may come from resource or about.

JSON-LD is recommended for new identity graphs because it can express cross-node references without coupling entity data to layout. Microdata and RDFa are still accepted when they expose the same required identity fields and a clear Organization/WebSite relationship.

The same site identity SHOULD NOT be duplicated with conflicting values across syntaxes. If JSON-LD declares one Organization name and Microdata or RDFa declares a different name for the same identifier or URL, the general structured-data check reports the conflict and this check may lose identity or linkage evidence.

Pass, Warning, and Fail Criteria

The check passes when all weighted steps pass:

1. An Organization entity or recognized Organization subtype is present.
2. A WebSite entity is present.
3. Both entities expose required identity fields: Organization.name, Organization.url, WebSite.name, and WebSite.url.
4. WebSite.publisher clearly references the Organization entity.
5. The Organization exposes trust evidence through logo plus sameAs or contact evidence.

The check returns a warning when partial identity evidence exists, such as only one entity, missing identity fields, an ambiguous publisher link, or partial trust fields.

The check fails when neither Organization nor WebSite identity is usable, or when the missing pieces prevent the site identity from being reconstructed.

Evidence Model

The check emits structured evidence for the report and downstream remediation.

Top-level evidence fields:

• score: weighted score from the check's internal steps.
• steps: step-level status, issue, guidance, and evidence.
• allTypes: all normalized Schema.org types found in parsed structured data.
• found.organization: whether an Organization or recognized subtype was found.
• found.website: whether a WebSite node was found.
• found.organizationTypes: Organization-family types observed.
• found.websiteTypes: WebSite types observed.
• organization: selected best Organization-family node summary.
• website: selected best WebSite node summary.
• linkage: extracted WebSite.publisher evidence.
• origin: scanned origin.

Organization evidence fields:

• present
• types
• id
• name
• legalName
• url
• urlMatchesOrigin
• logo
• sameAsCount
• sameAs
• hasContactPoint
• hasAddress
• hasTelephone
• hasEmail
• hasDescription

WebSite evidence fields:

• present
• types
• id
• name
• alternateName
• url
• urlMatchesOrigin
• publisher
• hasSearchAction

Publisher evidence fields:

• present
• id
• name
• url
• matchesOrganization

Organization Entity

The preferred type is Organization, but recognized subtypes may also be valid when they accurately describe the publisher. Examples include Corporation, LocalBusiness, NewsMediaOrganization, NGO, EducationalOrganization, GovernmentOrganization, MedicalOrganization, ResearchOrganization, and SportsOrganization.

Minimum useful fields:

• @type
• @id
• name
• url

Recommended trust fields:

• logo
• sameAs
• contactPoint
• telephone
• email
• address
• legalName
• description

WebSite Entity

The WebSite entity represents the website itself, not the organization. It should normally include:

• @type: WebSite
• @id
• name
• url
• publisher
• alternateName when the site has common abbreviations or alternate brand names

Google's site-name guidance uses WebSite structured data to help identify a preferred site name and optional alternate names.

Publisher Linkage

The strongest linkage is an @id reference:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Inc.",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Example",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Name or URL matching can provide weaker evidence, but @id linkage is preferred because it survives name formatting differences and graph merging.

SearchAction

WebSite.potentialAction with SearchAction is a Schema.org pattern for declaring internal site search. It can be recorded as evidence, but it is not required for this check.

Google retired the sitelinks search box visual feature in November 2024, so SearchAction should not be treated as a required rich-result optimization. It may still be useful structured data when the site genuinely has internal search.

Non-Goals

This check does not validate all possible Organization subtype fields.

This check does not decide whether a site is eligible for Google rich results.

This check does not verify every sameAs profile externally.

This check does not require SearchAction.

This check does not replace LocalBusiness, Product, Article, FAQ, Breadcrumb, or other specialized schema checks.

Scoring Steps

1. Organization entity: weight 0.25.
2. WebSite entity: weight 0.25.
3. Identity fields: weight 0.25.
4. WebSite publisher linkage: weight 0.15.
5. Organization trust fields: weight 0.10.

The assessment suite owns category, maturity, and aggregate check weight. This package owns the internal step weights and evidence definitions for this check version.

References

• schema.org/Organization
• schema.org/WebSite
• schema.org/sameAs
• developers.google.com/search/docs/appearance/structured-data/organization
• developers.google.com/search/docs/appearance/site-names
• example.com/#organization
• example.com/#website
• schema.org/
• example.com/
• example.com/logo.png
• www.linkedin.com/company/example
• html.spec.whatwg.org/multipage/microdata.html
• www.w3.org/TR/rdfa-core
• www.w3.org/TR/json-ld11
• schema.org/SearchAction
• developers.google.com/search/docs/appearance/structured-data/sd-policies
• developers.google.com/search/blog/2024/10/sitelinks-search-box

organization-website-schema v1.0.0 Changelog

Initial versioned package for organization-website-schema.

Documentation and evidence model

• Defines weighted scoring for Organization entity, WebSite entity, identity fields, publisher linkage, and trust fields.
• Records rich evidence for Organization/WebSite identity fields, origin matching, publisher linkage, sameAs, logo, and contact signals.
• Documents Schema.org, Google Organization structured data, Google site-name guidance, and SearchAction handling after sitelinks search box retirement.