WebPage Schema

Element code RI-020. Most people mark up the thing on the page, the Article or the Product, and forget to mark up the page as a page. That is what WebPage is for. It is the schema.org type that says "this URL is a web page, here is its canonical identity, its name, its language, its primary image, and what it is part of." On its own it rarely triggers a flashy rich result, but it is the connective tissue that lets search engines resolve your other structured data into a coherent picture of the page.

What WebPage schema is

In the schema.org vocabulary, WebPage sits under CreativeWork and represents a single web page as an entity. It carries properties like name, url, description, inLanguage, primaryImageOfPage, datePublished, dateModified, breadcrumb, and isPartOf, which points to the WebSite the page belongs to. There are more specific subtypes worth knowing: AboutPage, ContactPage, CollectionPage, ItemPage, FAQPage, SearchResultsPage, and CheckoutPage. Using the right subtype tells engines the page's function, not just that it exists.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://example.com/guide/#webpage",
  "url": "https://example.com/guide/",
  "name": "Your page title",
  "inLanguage": "en",
  "isPartOf": { "@id": "https://example.com/#website" }
}
</script>

How WebPage ties the graph together

Why this matters for SEO

The value of WebPage is disambiguation. When your page also carries Article, Breadcrumb, and Organization markup, engines have to work out how those pieces relate. A WebPage node with a stable @id and explicit relationships (isPartOf the WebSite, breadcrumb the BreadcrumbList, primaryImageOfPage the hero image) hands them the map instead of making them infer it. That clean graph helps both classic crawlers and AI answer engines resolve entities correctly, which is exactly what you want as search shifts toward entity-based understanding. Note the exception: FAQPage is a WebPage subtype that does drive a specific rich result when it marks up real question-and-answer content, so use it where it genuinely fits.

Choosing the right subtype

How to detect it

Run the URL through Google's Rich Results Test and the Schema Markup Validator at validator.schema.org to see whether a WebPage node is present and how it links to your other types. At scale, Screaming Frog and Sitebulb extract and validate structured data during a crawl, so you can list every URL that is missing a WebPage entity or has a broken isPartOf reference. Search Console Enhancements reports will not list WebPage as its own report the way it does for FAQ or Product, so crawler-side validation is your main detection path here.

How to fix it, step by step

1. Add a WebPage (or the correct subtype) node to each template, with a stable @id such as the URL plus #webpage.
2. Fill url, name, description, and inLanguage so the identity is complete.
3. Link the graph: set isPartOf to your WebSite node, breadcrumb to the BreadcrumbList, and primaryImageOfPage to the hero image.
4. Reference the page's main content with mainEntity where it applies, for example the Article on a blog post.
5. Validate in the Rich Results Test, confirm no unresolved references, then deploy and re-crawl.

What good looks like

One WebPage node per URL, using the most specific accurate subtype, with a stable @id, a canonical url, and clean links to the WebSite, breadcrumb, primary image, and main entity. It validates without unresolved references, and it turns your scattered markup into a single connected graph that engines and AI models can read without guessing.

FAQ