WebSite Schema

Element Code: RI-019

What WebSite schema actually does

WebSite schema is a structured data type from schema.org that describes your site as a whole: its name, its canonical URL, and optionally an alternate short name. You publish it as a JSON-LD script on the homepage, and search engines read it to understand what to call your site.

That last part is the whole game. Since Google introduced site names in search results in October 2022, the name shown above your URL in a mobile result is not necessarily your title tag. Google picks it from several signals, and its own documentation lists WebSite structured data as the preferred one. If you have ever watched Google label a client's site with some stale, half-wrong name pulled from an old og:site_name or a directory listing, you know why you want to hand Google the answer explicitly rather than let it guess.

I treat this check as cheap insurance. It will not move rankings on its own, and anyone who tells you WebSite schema is a ranking factor is selling something. What it does is control presentation: the site name and, in some cases, how Google understands the relationship between your homepage and the entity behind it when you link it to Organization schema.

The sitelinks search box is gone, so stop chasing it

Older guides, and honestly older versions of most audit tools, pitched WebSite schema mainly as the way to get a sitelinks search box: that inline search field Google sometimes showed under a brand's homepage result. That feature is dead. Google announced in October 2024 that it was retiring the sitelinks search box due to declining usage, and it stopped appearing in November 2024. The announcement is on the Google Search Central blog if you want the receipt.

Two practical consequences. First, the potentialAction SearchAction block that everyone copy-pasted for a decade no longer produces any visible feature in Google. Second, Google explicitly said the markup does not cause problems if you leave it in place. So do not rip it out in a panic, but also do not add it to new builds expecting anything in return from Google. I still include it when the site has a real internal search endpoint, because the markup is harmless, other consumers can read it, and removing things that cost nothing is busywork.

What Google reads from it

Here is how the homepage markup maps to what actually shows up in a search result.

How to implement it correctly

One block, homepage only, in the head or body, as JSON-LD. Here is a version that covers everything Google actually consumes:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.com/#website",
  "url": "https://www.example.com/",
  "name": "Example Brand",
  "alternateName": "EB",
  "inLanguage": "en-US",
  "publisher": { "@id": "https://www.example.com/#organization" }
}
</script>

Step by step:

1. Set url to the exact canonical homepage URL, matching protocol, host, and trailing slash. If your canonical is https://www.example.com/, do not write the non-www version here.
2. Set name to the name you want displayed in search results. Google says to use a concise, commonly recognized name. Keep marketing taglines out of it.
3. Add alternateName only if people genuinely use a short form or acronym for your brand. Do not stuff a keyword in there; it is a name field, not a targeting field.
4. Reference your Organization node via publisher using an @id so the two nodes connect instead of duplicating data. Most SEO plugins (Yoast, Rank Math) build this graph for you.
5. Deploy on the homepage. Google states it uses WebSite markup from the homepage for site names, so you gain nothing by injecting it sitewide, though plugins that do so are not hurting anything.

How to check what you currently have

Do not assume your plugin already handles this. Verify:

• View source: load the homepage, search the HTML for "WebSite". Fastest first pass.
• Schema Markup Validator (validator.schema.org): shows every node on the page. Use this instead of the Rich Results Test for WebSite markup, because the Rich Results Test only reports types tied to rich result features and will not flag a broken WebSite node.
• Screaming Frog: enable structured data extraction under Config, then crawl. The Structured Data tab shows validation errors at scale and catches the classic problem of two plugins each emitting their own conflicting WebSite node.
• Search results themselves: search your brand name and look at the site name Google displays. If it is wrong, the site names documentation from Google lists WebSite markup as the first thing to fix.

Reference: the properties that matter

Where sites screw this up

The failure modes I actually see in audits, in rough order of frequency: two or three competing WebSite nodes because the theme, an SEO plugin, and a hand-coded snippet each output one; a url pointing at the http or non-www variant while the canonical is https www; a name field stuffed with "Brand | Keyword Keyword City" because someone treated it like a title tag; and markup pasted on the homepage of the staging domain but never migrated to production. None of these throw errors you will notice day to day. All of them make Google fall back to guessing your site name from weaker signals.

FAQ