WebSite Schema: What It Still Does After the Sitelinks Search Box, and the JSON-LD to Use

WebSite schema is WebSite structured data on your home page that tells Google what your site is called. Since the sitelinks search box was retired, stating your preferred site name is the one job Google documents for it.

This guide covers what changed, the two required properties, how alternateName works as a fallback list, the home page rule, how the WebSite node connects to your Organization node by @id, validated JSON-LD you can copy, the mistakes that stop Google using your name, and how to check which name Google actually shows.

Key takeaways

• One documented job. Google uses WebSite markup to pick the site name shown next to your results. The sitelinks search box it used to power was removed from results starting on November 21, 2024.
• Two required properties. name and url, where url is the canonical home page of the domain or subdomain. alternateName is the only recommended extra.
• Home page only, and one site name per domain or subdomain. Subdirectories such as /de/ or /news/ cannot have their own site name.
• alternateName is an ordered fallback list. You can list several names in order of preference, and your lowercase domain can go last as a safety net.
• The Rich Results Test does not check it. Validate with the Schema Markup Validator, then look at a live search result for your home page.

What WebSite schema does now

In schema.org’s definition, a WebSite is “a set of related web pages and other items typically served from a single web domain and accessible via URLs.” It is a CreativeWork, so in the vocabulary it can carry dozens of properties. Google reads very few of them.

For Google, the job is the site name. When a page appears in results, Google shows the name of the site it comes from, and its documentation is explicit that this is different from the per-page title link: the title link belongs to each page, the site name belongs to the whole site.

The site name system is automated. Google says it considers content from your home page and references to the site elsewhere on the web, including og:site_name, the <title> element and headings, “However, WebSite structured data is most important, if you want to specify a preference.” That sentence is the whole case for adding the markup.

Two things follow from it. First, the markup is a preference, not an instruction. Google says it can’t manually change automatically selected site names, and it may fall back to other sources or your domain if it is less confident in the name you gave. Second, the markup only works if the rest of the home page agrees with it, which is where most failures come from.

The sitelinks search box is gone, and the SearchAction with it

For years the standard WebSite snippet carried a potentialAction with a SearchAction and a urlTemplate. That block existed for one feature: the sitelinks search box, a search field shown under a brand’s result.

Google announced in October 2024 that it would remove the search box starting on November 21, 2024, citing falling usage, and that the change applied globally in all languages and countries. The same post said Google would remove the Search Console rich results report for it and stop highlighting the markup in the Rich Results Test. Google’s documentation update log records that the sitelinks search box documentation was removed on November 29, 2024, and that the nositelinkssearchbox robots rule was archived.

Do you need to strip the SearchAction out? No. Google’s announcement says there is no need to remove it: “Unsupported structured data like this won’t cause issues in Search, and won’t trigger errors in Search Console reports.” It is still valid schema.org vocabulary, as the WebSite type page shows in its own example.

My view as someone who maintains these templates: remove it the next time you touch the file, because dead markup invites someone to “fix” it later. But note the warning in the same Google post. Site names use “a variation of WebSite structured data, which continues to be supported.” Delete the potentialAction, not the whole WebSite node.

Required and recommended properties for site names

Google’s site name documentation lists exactly two required properties and one recommended property.

Property	Status	What Google says it must be
name	Required	The name of the website, following the guidelines for choosing a site name
url	Required	The URL of the home page, set to the canonical home page of the domain or subdomain, for example https://example.com/
alternateName	Recommended	An alternate name such as an acronym or shorter name; you can list more than one, in order of preference

Anything else you add, such as description, inLanguage or publisher, is valid schema.org and useful for describing your entity graph. It is not part of what Google documents for site names, so do not expect it to change what Google displays.

Choosing the name itself

Google’s guidelines for choosing your site name are short and worth following literally:

• Unique and not misleading. It must reflect the identity of the site and follow Search content policies.
• Concise and commonly recognised. Google’s own example is “Google” rather than “Google, Inc”. There is no length limit, but long names may be truncated on some devices.
• Not generic. A name like “Best Dentists In Iowa” is unlikely to be selected unless it is an extremely well-recognised brand.
• Consistent across the home page. The structured data name should match how the home page refers to the site in the other sources Google reads.

The consistency rule is the one that matters in practice. If your <title> says “Acme Software Ltd | Home”, your og:site_name says “Acme App” and your WebSite name says “Acme”, you have given Google three candidates and asked it to guess.

alternateName as an ordered fallback list

alternateName is where you give Google permission to use something other than your first choice. Google says it may not use your preferred name if, for example, two global sites would share the same name, or if the site is more commonly recognised by an acronym.

You can pass an array, most important first. Google’s own example is "alternateName": ["BT", "B-T", "Burnt Toast Shop"] for a site named “Burnt Toast”.

There is also a documented backstop. If your preferred name keeps being rejected, Google suggests adding your domain or subdomain as the last alternative, and it must be all lowercase (“example.com”, not “Example.com”) for the system to detect it as a site name preference. As a last resort, you can make the lowercase domain the name itself, which Google says its system will generally select.

The home page rule and what counts as a site

This is the section most “website schema” guides skip, and it is where multilingual and multi-brand sites go wrong.

The markup must be on the home page. Google defines the home page as the domain or subdomain level root URI. Its example is precise: https://example.com is the home page, https://example.com/de/index.html is not.

One site name per site. Google supports one site name per domain or subdomain. https://news.example.com can have its own site name. https://example.com/news cannot, because Google does not support site names at the subdirectory level. The www and m subdomains are generally treated as equivalent to the root domain.

You do not need it on every page. Google says you only need to add the markup to the home page. Putting the same node on every page is not an error. On this site, for example, the WebSite node sits in the shared @graph that every page carries, which keeps one definition in one place in the code. What matters for site names is that the home page has it.

Duplicate home pages need identical markup. If HTTP and HTTPS, or www and non-www, versions of the home page both exist, Google asks you to use the same structured data on all of them, not just the canonical one. The better fix is to redirect the duplicates and set a proper canonical tag, then keep the markup consistent anyway.

One WebSite node, not two. If a plugin already outputs WebSite markup, Google asks you to add the site name properties to that node rather than creating a second WebSite block on the home page. Two nodes with two different names is one of the easiest ways to confuse the selection.

The home page must be crawlable. If Google cannot reach the home page because it is blocked, it may not be able to generate a site name at all.

How WebSite connects to Organization with @id

A WebSite node and an Organization node describe two different things: the site, and the entity that runs it. They should be connected, and they should agree on the name.

Google’s Organization documentation asks you to use the same name and alternateName that you’re using for your site name. So the naming decision you make for WebSite is also the naming decision for Organization. If the registered company name differs, it goes in the organisation’s legalName, not in name.

The connection between the two nodes is made with @id. Give each node a stable identifier on the home page URL (the fragment convention #website and #organization is common and readable), then reference one from the other. Schema.org lists publisher as a property of WebSite that takes an Organization or Person, which is the natural link: the site is published by the organisation.

A note on what is and is not documented. Google’s site name page does not ask for @id at all. Its update log records an August 2023 change that “removed unneeded mention of @id” from the site names documentation. So @id is not a site name requirement. It is good graph hygiene: it lets your Article nodes, BreadcrumbList nodes and author entities point at one definition of the site and the publisher instead of repeating them.

The JSON-LD to use

Three versions, from minimal to complete. Each block below parses as valid JSON.

Minimal: the two required properties

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Acme",
  "url": "https://example.com/"
}
</script>

This is enough for Google’s site name system. The url ends in a slash because it should match your canonical home page URL exactly as you serve it.

With alternate names

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Acme",
  "alternateName": ["Acme Software", "example.com"],
  "url": "https://example.com/"
}
</script>

The order is the order of preference. The lowercase domain goes last as the documented backstop.

Complete: WebSite and Organization in one graph

This is the pattern I recommend: one @graph on the home page with both nodes, linked by @id, and the same name on both.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Acme",
      "alternateName": ["Acme Software", "example.com"],
      "description": "Deployment tooling for engineering teams.",
      "inLanguage": "en-GB",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Acme",
      "alternateName": "Acme Software",
      "legalName": "Acme Software Ltd",
      "url": "https://example.com/",
      "logo": "https://example.com/assets/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/acme",
        "https://github.com/acme"
      ]
    }
  ]
}
</script>

Everything outside name, alternateName and url on the WebSite node is descriptive rather than something Google documents for site names. I include inLanguage and publisher because they cost nothing and make the graph explicit for any consumer, including AI systems that parse the raw HTML. The broader case for that is in structured data for AI search. If you are new to writing these blocks by hand, the JSON-LD walkthrough covers placement and syntax.

Whatever you generate it from, render it on the server so it is in the HTML response. The home page is the one page where this markup has to be right.

Common mistakes

These are the mistakes that most often stop WebSite markup from doing its job, and each maps to a rule in Google’s documentation.

1. Deleting the whole node with the SearchAction. Teams read “sitelinks search box removed” and delete the WebSite block. Google’s own announcement warns that site names use a variation of WebSite markup that is still supported. Remove the potentialAction only.
2. Two WebSite nodes on the home page. Usually a theme plus an SEO plugin, or a plugin plus a hand-written block. Google asks you to nest the site name properties in the existing node. Pick one source and switch the other off.
3. A url that is not the canonical home page. http:// when the site is HTTPS, a missing www, or a tracking parameter. Google asks for the canonical home page of the domain or subdomain.
4. Trying to name a subdirectory. A WebSite node on /de/ or /blog/ with a different name will not create a separate site name, because subdirectories are not supported. If a section genuinely needs its own name in results, it needs its own subdomain.
5. A name nobody else uses. The markup says “Acme”, the title tag says “Acme Software Ltd | Official Site”, and the logo alt text says “AcmeApp”. Google checks the other sources on the home page, so align them.
6. A generic or keyword-stuffed name. “Acme | Best Deployment Tool UK” is not a site name. Google’s guidelines say generic names are unlikely to be selected.
7. Organization and WebSite disagree. The organisation’s name is the legal name while the site name is the brand. Google asks for the same name and alternateName on both. Move the legal name to legalName.
8. Validating in the Rich Results Test and concluding it is broken. The tool does not support site names, so a result that shows no WebSite item is expected, not a fault.

How to check which site name Google shows

Testing has three parts: syntax, crawlability and the live result. Google’s site name page describes the first two.

1. Validate the syntax. Use the Schema Markup Validator. Google’s documentation says plainly that site names aren’t supported in the Rich Results Test, so the Schema Markup Validator is the tool for this type. Paste the home page URL, confirm one WebSite item with the name and url you expect, and check that the publisher reference carries your Organization node’s @id.

2. Check what Googlebot sees. Run the home page through the URL Inspection tool in Search Console and confirm it is indexable and not blocked by robots.txt, noindex or a login. If the markup is injected client-side, check the rendered HTML in the inspection result too.

3. Look at a live result. Search for your brand or your home page and read the name shown above the title link. Check a few internal pages as well, because the site name applies to the whole site, not one page. If you have just changed the markup, request a recrawl of the home page and give it time: Google says crawling can take anywhere from several days to several weeks.

If Google shows the wrong name

Google’s troubleshooting sequence, in order:

• Confirm the name in the home page’s WebSite markup is really your preferred name, and that the markup has no errors.
• Confirm the other sources on the home page use the same name.
• Confirm you are not trying to name a subdirectory.
• Check redirects. If the home page redirects, the site name reflects the redirect target.
• Make sure every version of the site (HTTP and HTTPS, for example) uses the same name.
• Add or reorder alternateName, since Google says it “strongly considers” that option when it is not confident in your preferred name.
• Add the lowercase domain as the final alternative, and only as a last resort make it the name.

A site name problem is usually a symptom of a messy home page: duplicate versions, conflicting titles, or a rebrand that only reached half the templates. Those are the same issues a technical SEO audit picks up, and after a site migration or a rebrand, the site name is worth checking in the first week.

Where WebSite schema fits in the wider stack

WebSite is one node in a small identity graph. Organization says who runs the site. WebSite says what the site is called and who publishes it. Article, BreadcrumbList and author markup on inner pages point back to both by @id.

None of these produce a rich result in the traditional sense. The site name is a label, not a feature you can win. If you want the wider picture of which schema types still change what appears in results, I cover that in do rich snippets help SEO.

If you would rather have the identity graph (WebSite, Organization, author and article nodes) designed and shipped as part of a wider technical review, that is part of my technical SEO and GEO work.

Frequently asked questions

Is WebSite schema still useful after the sitelinks search box was removed?

Yes. Google removed the sitelinks search box from results starting on November 21, 2024, but it still uses WebSite structured data to choose the site name shown with your results. Its site name documentation says WebSite markup is the most important source if you want to state a preference.

What are the required properties for WebSite schema?

For Google’s site names, only name and url are required. The url must be the canonical home page of your domain or subdomain. alternateName is recommended if your site is also known by an acronym or shorter name.

Does WebSite schema need to be on every page?

No. Google says the markup must be on the home page and that you do not need it on every page. Including the same node sitewide is harmless, but only the home page counts for the site name.

Should I remove the SearchAction from my WebSite markup?

You can, but you do not have to. Google says unsupported markup like the sitelinks search box SearchAction will not cause issues in Search or trigger Search Console errors. If you remove it, delete only the potentialAction block and keep the WebSite node with name and url.

Can a subfolder like /de/ or /blog/ have its own site name?

No. Google supports one site name per domain or subdomain and does not support site names at the subdirectory level. A section that needs its own name in results would need its own subdomain, such as blog.example.com.

How do I test WebSite schema if the Rich Results Test does not show it?

Use the Schema Markup Validator for syntax, because Google states that site names are not supported in the Rich Results Test. Then use the URL Inspection tool to confirm Google can crawl and index the home page, and check a live search result to see which name Google displays.