WebSite Schema

Meaning and scope

The Schema.org WebSite type can express a site's name, URL and related information in structured data. It is a vocabulary, not a promise that a search engine will show a particular feature. Google decides how, when and whether to use structured data in search presentation, and it can change support for features over time.

zoom_in

Practical workflow

Model only facts that are stable and visible or otherwise verifiable. Use the canonical home-page URL, the name users see, and relationships to an Organisation only when they accurately describe the same entity. JSON-LD is a common transport format, but a syntactically valid graph can still be misleading if it combines facts from different sites or outdated settings.

What to inspect

Inspect the rendered page source and parse the graph after deployment. Confirm that identifiers resolve as expected, values match visible site identity and there is no duplicate or conflicting site-level graph. Validate vocabulary and syntax, then use the relevant Google documentation to check current feature support rather than relying on old tutorials.

Limits and common mistakes

Do not add SearchAction to chase a retired or unsupported display feature, and do not make up alternate names, publisher relationships or a search endpoint. Structured data should clarify existing facts; it cannot repair weak content, inaccessible pages or a confused canonical setup.

Model the WebSite entity carefully

Start with the home page that users and crawlers actually reach after redirects. Record its final canonical URL, visible site name, any visible alternate name and the Organisation relationship only if both describe the same public entity. A WebSite graph should not repeat a different host, staging name or old legal identity merely because those values remain in a CMS setting. Stable identifiers are more useful than a large graph with contradictory nodes.

{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }

Inspect the rendered HTML rather than an editor preview. Parse every JSON-LD script, list @id, @type, name, url, alternateName and connections to Organisation or WebPage nodes, then compare these fields with visible page facts. Validation tools can catch syntax or vocabulary problems, but they cannot know whether an old site name, a stale URL or an unsupported promise reflects the business.

Test the graph across the home page, language variants and major templates. Site-level markup is often injected globally, so a change can duplicate a node or give each locale a conflicting URL. If regional or language sites are distinct entities, document the relationship deliberately instead of copying one WebSite declaration unchanged. Confirm that canonical URLs in the graph resolve directly and consistently.

Do not add a property simply because an old tutorial says it triggers a search feature. Schema.org defines vocabulary, while Google separately documents which structured-data features it currently supports and may change. A valid WebSite entity can improve machine-readable consistency, but it does not guarantee a displayed site name, sitelinks or any search enhancement.