WebSite and WebPage schema markup generator
WebSite and WebPage markup describe the site and the page rather than a thing on the page. Neither produces a rich result on its own, and both are still worth having — for reasons that are easy to state and rarely stated.
Google Search features this type can produce
From the registry| Feature | Status | Surface | Last verified |
|---|---|---|---|
| Sitelinks search box (opens in a new tab) Google announced it stopped using this markup. WebSite markup itself remains useful for other reasons; the search box feature is gone. Effective date must be confirmed before display. | REMOVED | search | 2026-08-29 |
Meeting a feature’s documented requirements does not guarantee that the feature appears. No tool can promise that, and any that does is describing something it cannot know.
Generate the markup
Runs in your browser<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Marlow Road Coffee",
"description": "A coffee roaster and cafe in south London.",
"url": "https://example.com/",
"inLanguage": "en-GB",
"publisher": {
"@type": "Organization",
"name": "Marlow Road Coffee Ltd",
"url": "https://example.com/"
}
}
</script>Paste this into the <head> of the page it describes. Markup that describes a page must live on that page.
What website schema is for, now that the search box is gone
For years the reason people added WebSite markup was the sitelinks search box: the little site-search field that appeared under a brand’s result. Google stopped using that markup, and a great deal of published advice still tells you to add a SearchAction to get it. That advice is now describing something that does not happen.
What WebSite markup still does is state, in machine-readable form, that this collection of pages is one site with one name and one publisher. That sounds thin until you consider what a consumer otherwise has to infer: a site name from the title tag, a publisher from a footer, and a relationship between the two from nothing at all. Naming them explicitly, once, is cheap and unambiguous.
The practical value shows up in two places. The site name is used by Google in place of a domain in some result formats, and giving it explicitly is more reliable than hoping a title tag is parsed the way you intended. And a WebSite node with an @id gives every other entity on the site something to point at — an Article that names its publisher by reference rather than repeating the organisation’s name and logo on every post.
WebSite and WebPage are different things
WebSite describes the whole site: one entity, one name, one URL, placed once. WebPage describes a single page: its title, its language, its position in the site, when it was updated. Confusing the two produces a site where every page claims to be the website, which is the most common way this markup goes wrong.
WebPage is the more interesting of the two and the less used. It has subtypes that carry real meaning — AboutPage, ContactPage, CollectionPage, FAQPage, ProfilePage, CheckoutPage, ItemPage — and declaring the right one tells a consumer what kind of page it is looking at before it reads a word of the content. A contact page marked ContactPage is unambiguous in a way that a page titled “Get in touch” is not.
Neither type produces a rich result by itself. If you are adding WebPage expecting a visible change in the results, you will not get one. Add it because it describes the page correctly, and because subtypes like CollectionPage and ItemPage help a consumer tell a category listing from a product.
The mainEntity property is the one that earns its place
A WebPage can name the thing it is primarily about. A product page is a WebPage whose mainEntity is the Product; an author bio is a ProfilePage whose mainEntity is a Person. This is the property that turns a page-level node from decoration into structure, because it states which of the several entities on a page is the subject and which are supporting detail.
Most pages carry more than one entity — a Product, an Organization, a BreadcrumbList, maybe a few Offers — and nothing in that collection says which one the page is for. mainEntity says it. On a page whose markup is otherwise ambiguous, it is the single most useful property you can add.
The related property, mainEntityOfPage, points the other way: it goes on the entity and names the page that is primarily about it. Either direction works. Using both, pointing at each other, is redundant rather than twice as good.
Use one @graph rather than three script tags
WebSite, Organization and the page-level entity belong together, and the way to express that is one @graph block where each node has an @id the others reference. Three separate script tags parse equally well and state no relationship at all — a consumer sees an organisation, a website and a page with nothing connecting them.
The maintenance argument is the stronger one. Three blocks means the site name is written three times, and when it changes it gets updated twice. One definition referenced by @id has one place to edit and cannot drift.
Our bundle generator builds that linked block for you, with the @id references already wired between the entities.
Mistakes worth avoiding
Adding a SearchAction expecting a search box
Google stopped using sitelinks search box markup. The property is still valid schema.org and still describes a real thing about your site, but it will not produce the feature the guides you have read were written about.
WebSite markup on every page
There is one website. Injecting the WebSite entity site-wide through a template or tag manager means every page declares itself the site. Place it once, and reference it by @id from elsewhere.
WebPage with nothing on it
A WebPage node carrying only a name and a URL restates the title tag and the canonical. It is not wrong, it just does no work. If you are adding WebPage, add mainEntity, a subtype, or dateModified — something the page does not already say.
A site name that is not the site name
The name property should be what people call the site, matching what you would want shown in a result. A tagline, a legal entity name, or a keyword-stuffed variant all describe something other than what visitors call you.
inLanguage missing on a multilingual site
If you serve the same page in several languages, saying which one this is costs one property and removes real ambiguity. It matters more here than on most types, because WebPage is the natural place to state it.
Check what you already have
If the page you are marking up already carries structured data, audit it before adding more. Duplicate entities from a theme and a plugin are the most common finding on established sites, and adding a third block makes it worse rather than better.