How to Create WebSite Schema: A Complete 2026 Guide

Chapter 1. Before you start

WebSite schema is the entity record for your domain. It defines the canonical name of the site, the publisher behind it, and (optionally) the actions a user can take from search results. Combined with Organization schema, it forms the foundation every other schema on your site references.

• Your Organization schema already published. WebSite references the Organization via publisher; without that publisher schema in place, the reference goes nowhere.
• The canonical name you want search engines to use for the site. Often the same as the brand name, but not always (e.g., "Capconvert Blog" vs "Capconvert").
• Your apex URL with the correct protocol and host variant. Match exactly what your canonical tags use.
• (Optional) A search-results URL pattern if your site has its own internal search and you want to ship the SearchAction for Bing visibility.

Chapter 2. What does WebSite schema actually do in 2026?

Less than it used to, but still enough to ship. The headline feature - the sitelinks search box rendered in Google SERPs - was deprecated in November 2024 per Google's official announcement. Google no longer displays the search box even when valid SearchAction markup is present.

What WebSite schema still does in 2026:

• Anchors the publisher entity. Article, BlogPosting, Product, and other schemas reference WebSite via isPartOf, linking individual pages to the site as a whole.
• Feeds AI engines and LLMs. ChatGPT, Perplexity, and Gemini parse the WebSite block to associate URLs with the brand entity.
• Supports Bing and other engines. Bing still renders the sitelinks search box from SearchAction markup, which means Microsoft Copilot benefits.
• Validates site-level metadata: name, alternate names, language, in-language alternates for international sites.

Chapter 3. Required and recommended properties

Per Schema.org, WebSite requires only @type, url, and name. The recommended floor we ship on every client is below.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.com/#website",
  "url": "https://www.example.com",
  "name": "Example Brand",
  "alternateName": "Example",
  "publisher": { "@id": "https://www.example.com/#organization" },
  "inLanguage": "en-US",
  "description": "One-sentence description of what the site does or sells.",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://www.example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

The publisher reference points at your Organization schema's @id. The potentialAction block is the SearchAction that historically enabled the sitelinks search box; ship it for Bing visibility even though Google no longer renders it.

Chapter 4. Should you still ship the sitelinks search box action?

Yes, even though Google no longer renders it. Three reasons:

1. Bing still uses it. Microsoft Copilot, ChatGPT search (Bing-backed), and Bing's organic results render the search box from valid SearchAction markup. Bing is roughly 8% of US desktop search and a meaningful share of AI-driven queries.
2. It's a 10-line addition to schema you're already shipping. The cost-to-keep is zero; the cost-to-rip-out is also zero. Bias toward keeping.
3. Future-proofing. Google deprecates features but occasionally restores them; the underlying structured data is stable regardless of which surfaces render it at any given time.

The opposite question - "should you build a SearchAction for the first time in 2026" - is more nuanced. If your site has its own working internal search at a stable URL pattern, ship it. If your search is broken or absent, don't ship SearchAction pointing at a URL that 404s; that creates a worse user experience than no SearchAction at all.

Chapter 5. Publisher reference and language alternates

The publisher property links the WebSite to the brand entity. Use @id to reference the Organization schema you published on the homepage (see post #5 in this cluster, the Organization schema guide). This creates a clean entity graph: pages reference WebSite, WebSite references Organization, all three form one coherent record.

For international or multilingual sites, add inLanguage as a BCP47 code (en-US, fr-CA, de-DE). If you have multiple language variants, ship one WebSite schema per variant on each language's homepage with the appropriate inLanguage value. Do not ship multiple inLanguage values inside a single WebSite block.

Chapter 6. Validate and deploy

Same two-validator pattern as Organization schema. Run both before shipping a single line to production.

1. Paste the JSON-LD into validator.schema.org to verify vocabulary compliance.
2. Paste the same code into the Google Rich Results Test to verify Google-specific eligibility (even though sitelinks search box no longer renders, the validator still parses the markup).
3. Fix every critical error before deploying.
4. Deploy by inserting the JSON-LD inside a <script type="application/ld+json"> tag in the homepage's <head>. One block per page, homepage only.

Chapter 7. The breakages we see most often

Ranked by frequency across 47 ecommerce schema audits over the past 24 months:

• No WebSite schema at all: entity graph missing its root anchor. 29 of 47 audited stores.
• WebSite schema present but no publisher reference: site not linked to brand entity. 12 of 47.
• WebSite schema duplicated sitewide instead of homepage only: conflicting entity records. 9 of 47.
• SearchAction target URL returns 404: bad UX on the small share of engines that still render the search box. 7 of 47.
• No alternateName: search engines can't reconcile "Example Brand" with "Example" or "Example Inc.". 5 of 47.
• SearchAction query-input field malformed: schema validator throws error, sitelinks search box (where supported) breaks. 4 of 47.

We monitor schema completeness through our Sentry product; the structured-data rule set surfaces every breakage above on running sites.