Website Schema for SEO Site Identity

Website schema defines the site as a whole.

That sounds simple, but it plays an important role on a structured content site. It gives search engines a cleaner description of the website entity, the homepage, the site name, and the connection between site level markup and page level markup.

If you want the wider cluster first, start with Schema for SEO. If you want the syntax basics before the examples, read JSON LD Basics. If you want the closest related page type, go next to WebPage Schema.

What Website schema is

Website schema uses the WebSite type from Schema.org to describe the site level entity.

Think of it as the top layer of site markup. A page level type like WebPage describes one page. Organization describes the company or brand. WebSite describes the website itself.

On semantecseo.com, those three layers work best together:

• Organization Schema describes Semantec SEO as the brand or organization
• Website Schema describes semantecseo.com as the website
• WebPage Schema describes each individual page on the site

That split keeps the markup cleaner and easier to reason about.

Why Website schema belongs on this site

Semantec SEO is not a flat blog. It is built around product pages, use cases, docs, compare pages, templates, examples, and support hubs.

That kind of site benefits from a clear site level layer. Website schema helps frame the site as one coherent property, not just a loose set of pages.

It also fits neatly beside pages like Breadcrumb Schema, Organization Schema, and Entity Identity Across Pages.

What Website schema should cover

A clean Website schema block often includes:

• the canonical homepage URL
• the site name
• an alternate name if one is used
• the publisher or owning organization
• the internal site search action, if the site has real internal search
• the relationship between the site and the page level entities

The goal is clarity. Website schema is not a dumping ground for every possible property.

Website schema vs WebPage schema

This distinction is where a lot of implementations get messy.

Website schema describes the whole site.

WebPage schema describes one page.

For example:

• https://semantecseo.com/ can carry WebSite
• https://semantecseo.com/schema/website-schema/ can carry WebPage
• both pages can connect to the same organization entity

If you blur those layers together, the markup gets harder to maintain. That is why this page should be read alongside WebPage Schema and Organization Schema.

When to use Website schema

Use Website schema on the homepage or as the site level markup pattern that defines the site entity.

It is a strong fit for sites with:

• a clear homepage
• a defined brand
• multiple content clusters
• a stable canonical domain
• a structured site architecture

That makes it a good fit for semantecseo.com, where the homepage and product path connect into MIRENA, Use Cases, Docs, and the main authority hubs.

When not to overcomplicate it

Website schema should stay clean.

Do not turn it into a copy of page content. Do not force page specific properties into the site block. Do not add features the site does not really have.

A good implementation is compact, readable, and easy to maintain.

Example 1: simple Website schema in JSON LD

This is the cleanest starting point for a site level implementation.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://semantecseo.com/#website",
  "url": "https://semantecseo.com/",
  "name": "Semantec SEO",
  "publisher": {
    "@id": "https://semantecseo.com/#organization"
  }
}
</script>

This example keeps the site entity focused.

It names the website, defines the homepage URL, and connects the site to the organization entity. That is enough for many sites.

If you are building the wider schema layer around this, the next pages to read are Organization Schema and Schema Validation Workflow.

What each field is doing

@context points to the Schema.org vocabulary.

@type tells parsers that this is a WebSite.

@id gives the site entity a stable identifier.

url points to the canonical homepage.

name is the site name.

publisher connects the website to the publisher or organization entity.

That last link is important. It helps separate the website from the organization while still keeping them connected.

Example 2: Website schema with an alternate name

Some brands use a shorter public name or an alternate label. If that is part of the site identity, it can be included.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://semantecseo.com/#website",
  "url": "https://semantecseo.com/",
  "name": "Semantec SEO",
  "alternateName": "MIRENA by Semantec SEO",
  "publisher": {
    "@id": "https://semantecseo.com/#organization"
  }
}
</script>

This can help on sites where the product name and the brand name appear together across the site. On semantecseo.com, that relationship becomes clearer when paired with MIRENA and How MIRENA Works.

Example 3: Website schema with internal search

If the site has a real internal search function that users can access, the site block can include a search action.

Only add this if the search feature exists and works for users on the live site.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://semantecseo.com/#website",
  "url": "https://semantecseo.com/",
  "name": "Semantec SEO",
  "publisher": {
    "@id": "https://semantecseo.com/#organization"
  },
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://semantecseo.com/?s={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

This example should not be copied blindly. The search URL pattern needs to match the live site. If the site does not offer public search, leave this out.

How Website schema fits the rest of the schema stack

Website schema works best as one part of a wider markup system.

On semantecseo.com, the cleanest stack looks like this:

• Organization for the brand
• WebSite for the site
• WebPage for individual pages
• BreadcrumbList for page path
• page specific types where they fit

That makes these pages natural companions:

• Organization Schema
• WebPage Schema
• Breadcrumb Schema
• Entity Identity Across Pages
• Markup Prioritization

Common mistakes

Treating Website schema like a page schema block

Website schema is not the place for page headlines, article dates, or page specific descriptions.

Adding a search action when the site has no real search

If the site does not provide internal search for users, skip it.

Using inconsistent names across the schema stack

The site name, organization name, and page level labels should line up cleanly.

Forgetting the entity links

If the site, organization, and page all exist in markup but are not connected through stable IDs, the implementation gets weaker.

Creating duplicate site entities

Pick one clean site level entity ID and reuse it consistently.

A practical model for semantecseo.com

For this site, the homepage can define the WebSite entity.

Then individual pages can refer back to it through the site level ID.

That makes the markup easier to scale across:

• Compare
• Use Cases
• Docs
• Templates
• Examples
• the main topical clusters like Information Gain and Internal Linking

Validation workflow

A clean validation flow looks like this:

1. define the site level entity on the homepage
2. keep the site name and URL canonical
3. connect the site block to the organization entity
4. check that page level markup points to the right site level entity
5. review the implementation before publishing site wide

If you want the wider review process, pair this page with Schema Validation Workflow, Schema Debugging, and Publish Readiness Checks.

Website schema and site architecture

Website schema does not replace site architecture.

It reinforces it.

If the site structure is messy, the markup will not solve that. If the structure is clean, the markup helps define the site level context more clearly.

That is why this page connects naturally back to Site Architecture for Semantic SEO, Cluster Roles, and Docs Page Types.

Final take

Website schema is one of the cleanest site level schema blocks you can add.

It defines the website entity, connects the homepage to the broader markup system, and gives the rest of the site a stronger top level reference point. On semantecseo.com, it belongs beside Organization schema, WebPage schema, breadcrumb schema, and the broader validation workflow.

For the best next path through this cluster, read Organization Schema, WebPage Schema, and Schema Validation Workflow.

FAQ

What is Website schema?

Website schema is structured data that describes the website as a whole rather than one page.

Where should Website schema go?

In most cases, it belongs on the homepage as the site level entity block.

Is Website schema the same as WebPage schema?

No. Website schema describes the site. WebPage schema describes one page.

Should every site add a search action?

No. Only use a search action if the site has a real internal search feature.

What should I read after this page?

The best next reads are Organization Schema, WebPage Schema, and Schema for SEO.