WebSite JSON-LD Template

What this describes

Use WebSite for the website represented by a home page and connect it to the publisher. It is distinct from the Organization that publishes it, even when their names match. Define a stable site entity and reference it from pages with isPartOf where that relationship is useful.

Copyable template

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.com/#website",
  "url": "https://www.example.com/",
  "name": "Example Site",
  "description": "A concise description that matches the website.",
  "inLanguage": "en-US",
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}

Customize it

• Use the canonical home-page URL and public site name.
• Use a BCP 47 tag that matches the site’s primary language.
• Point publisher to a separately defined Organization or Person entity.
• Keep @id stable and use it from a WebPage only when both nodes identify the same website.
• Keep page titles, page authors, and page subjects on their page or content entities.

Locale and translation modeling

Model the actual site architecture first. A domain, subdomain, or subdirectory can be part of one broader website graph when that is what the URLs and ownership represent; there is no general requirement to create a new WebSite entity for every locale path. inLanguage describes the language of the entity you are modeling.

Schema.org does provide inherited CreativeWork relationships, including translationOfWork and workTranslation, which WebSite can use. They can express a genuine translation relationship when the two modeled works and their direction are clear. Their availability does not establish that a particular search engine consumes the relationship, and it does not replace hreflang for alternate-page discovery and language targeting. (Schema.org: translationOfWork)

Google’s site-name feature is a separate consumer rule. Google says its site names apply to domain-level and subdomain-level sites, and the WebSite object for that feature belongs on the domain or subdomain root home page, not a subdirectory such as /de/. That limitation is about Google’s site-name feature; it does not prescribe every Schema.org graph decision for localized content. (Google: site names in Search)

Optional SearchAction compatibility note

Google retired its sitelinks search box feature, so do not add SearchAction to pursue that display. SearchAction remains Schema.org vocabulary, but no broadly documented AI-agent convention makes it a dependable site-search interface.

Keep or add it only when an identified consumer, integration, or first-party automation reads it and the search endpoint is maintained. In that case, test a real query against the target URL and include only the working pattern:

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.com/#website",
  "url": "https://www.example.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

Otherwise, omit it. Crawlable navigation, descriptive links, and a working visible search form provide more dependable access than an unsupported action declaration.

Validate it

Use the live-page JSON-LD validation tutorial on the deployed home page. Confirm the site name and home URL match the page, the publisher @id identifies the intended entity, and page markup does not refer to a different WebSite identity by mistake.

Official references

• Google Search Central: site names in Search
• Google Search Central: phasing out the sitelinks search box
• Schema.org: WebSite
• Schema.org: SearchAction
• Schema.org: translationOfWork