What are WebSite and SearchAction in Schema.org?

If you open the source code of your store's homepage and find a "@type": "WebSite" node with a potentialAction inside, chances are someone put it there for the sitelinks search box: the box that appeared under the result of some big sites and let you search within them without leaving Google. That box no longer exists. What is left of the markup is less flashy and more useful than it looks: the name Google uses to present your store above each result. WebSite and SearchAction are two Schema.org types, and they live in the page's structured data, normally in a JSON-LD block.

What each piece is

Schema.org defines WebSite as a set of related web pages and other items, typically served from a single web domain and accessible via URLs. It is a subtype of CreativeWork, which in turn is one of Thing, and it inherits almost everything it carries: name, url, alternateName and potentialAction come from Thing, and publisher or isPartOf, from CreativeWork. The only property of its own is issn, for serial publications. Schema.org estimates that more than ten million domains use it, with data from Google's index as of August 2026.⁠^{[1]Schema.org. WebSite}

SearchAction is something else: it doesn't describe an object but an action, the act of searching for something, and descends from Action. Its own property is query, the query used in that action.⁠^{[2]Schema.org. SearchAction} It attaches to the site with potentialAction, which according to the vocabulary indicates a possible action in which the described thing would play the role of object. Schema.org's example shows the whole combination: a WebSite whose potentialAction is a SearchAction with a URL template, http://example.com/search?&q={query}, where {query} is the slot that takes whatever the person types.⁠^{[1]Schema.org. WebSite}

The idea was for a search engine to know how to launch a search within your store without going through your homepage. Google used it for that for more than ten years.⁠^{[3]Google Search Central Blog. Farewell, Sitelinks Search Box}

What it does today in Google

On October 21, 2024, Google announced on its blog that it was retiring the sitelinks search box: it had been in Search for more than ten years, its use had dropped and it wanted to simplify results. It stopped being shown from November 21, 2024, in all languages and countries. The announcement clarified that the change doesn't affect ranking or other site links, and that Google would remove that feature's rich results report from Search Console and stop flagging the markup in the Rich Results Test.⁠^{[3]Google Search Central Blog. Farewell, Sitelinks Search Box} On November 29, 2024 it deleted the feature's documentation and archived the nositelinkssearchbox rule.⁠^{[4]Google Search Central. Latest documentation updates}

Two sentences from the announcement are still the ones that matter to a store. First: you can remove that markup, but you don't have to, because unsupported structured data causes no problems in Search or errors in Search Console reports. Second: if you do remove it, careful, because site names use a variant of the same WebSite markup, and that one still works.⁠^{[3]Google Search Central Blog. Farewell, Sitelinks Search Box}

The site name is what WebSite does today in Google. It is the name of the website that appears on each result. Google generates it automatically, from the homepage's content and references to it around the web, and doesn't change it by hand. To indicate your preference, Google asks for WebSite markup on the homepage; it also looks at og:site_name, the <title> and headings, but it says WebSite markup is the most important.⁠^{[5]Google Search Central. Site names on Google Search} The rules, according to its documentation, updated on December 10, 2025:⁠^{[5]Google Search Central. Site names on Google Search}

• Two properties are required: name, the name, and url, the canonical homepage of the domain or subdomain. alternateName is optional and offers alternatives, such as an acronym or a shorter name.
• The markup goes only on the homepage, the root of the domain or subdomain. It isn't needed on the other pages.
• One name per site. Domains and subdomains are accepted (www and m count as the domain), but not subdirectories: example.com/news cannot have a name of its own. If a subdomain has no markup, it may inherit the domain's name.
• The homepage has to be crawlable. If there are duplicate homepages (with and without www, http and https), they all carry the same markup.
• If you already have a WebSite node, add the name in that same node instead of creating another block.

In a store

A made-up example. The homepage of Calella, an invented linen shirt store, with the WebSite node an agency left years ago:

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://www.example.com/#website",
  "name": "Calella",
  "alternateName": "Calella Linen",
  "url": "https://www.example.com/",
  "publisher": { "@id": "https://www.example.com/#organization" },
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.example.com/search?q={query}",
    "query": "required"
  }
}

It reads like this. name and url are the two properties Google asks for, and alternateName offers it a second option. publisher doesn't describe the company: it points by its @id identifier at the Organization node, which is elsewhere on the page. The potentialAction is the legacy of the search box: it does no harm, and Google no longer does anything with it. If Calella had its Spanish version at example.com/es/, that folder would share the domain's name, because Google doesn't give names to subdirectories.

The WebSite node also appears outside the homepage, as a piece of the graph. A product page published with Clione, for example, carries a single @graph with Organization, WebSite, BreadcrumbList and Product, plus FAQPage when it has questions. On a product page, the site name isn't decided (Google only reads it on the homepage), but the node gives the other pieces something to point at.

How to check it

1. Open the source code of your homepage (not the inspector) and search for "WebSite". There should be a single node; if there are two, the name has to go in the same one.⁠^{[5]Google Search Central. Site names on Google Search}
2. Compare name with what the homepage shows: the <title>, og:site_name and the headings. Google takes all of that into account and asks you to use the name consistently across the homepage.⁠^{[5]Google Search Central. Site names on Google Search}
3. Look at url: it has to be the canonical homepage of your domain or subdomain. If your homepage is served with and without www, check that both versions carry the same markup.⁠^{[5]Google Search Central. Site names on Google Search}
4. If there is a SearchAction, decide at your leisure whether to remove it. It does no harm, and the Rich Results Test no longer flags it.⁠^{[3]Google Search Central Blog. Farewell, Sitelinks Search Box}
5. Search for your brand in Google and look at the name that appears above your homepage result. If it isn't the one you want, review the previous steps and add an alternateName: Google doesn't change the name by hand, but it takes alternatives into account if your first choice doesn't get picked.⁠^{[5]Google Search Central. Site names on Google Search}

Related concept: Organization

WebSite and Organization get confused because, in a small store, the site and the company are usually called the same. But they are two things: WebSite describes the website; Organization, the company behind it. The property that links them is publisher, which WebSite inherits from CreativeWork and which accepts an organization or a person.⁠^{[1]Schema.org. WebSite} The clean approach is to declare each one only once, with its own @id, and have the site point to the company instead of repeating it. The Organization entry explains which company data goes in its node.

To go further, the structured data reading path orders the rest of the terms, and ItemList explains the markup that does make sense on a category page.