What WebPage Schema Actually Does for AI Search
Most people think of schema markup as something that feeds Google's rich results. Tick that box, get a star rating in the SERPs, move on. But that framing completely misses what's happening right now with AI search engines like ChatGPT, Perplexity, and Gemini.
These systems don't browse your site the way a human does. They parse signals. They look for structured, machine-readable information that tells them what a page is, what it's about, who created it, and how it relates to everything else on your site. WebPage schema is one of the cleanest, most direct ways to supply that information.
At its core, WebPage is a Schema.org type that sits in the JSON-LD block of your HTML and explicitly describes the page as a named entity with a defined purpose. It can tell an AI model the page's name, its description, when it was last updated, what breadcrumb it belongs to, and even who the author is. That's not trivial. It's the difference between an AI model treating your page as anonymous content and treating it as a trustworthy, identifiable source.
Think of it like this: you wouldn't hand a journalist an unlabelled document with no byline and expect them to cite it confidently. WebPage schema puts the label on the document.
The WebPage Type Hierarchy and Which One to Use
Schema.org doesn't give you just one WebPage type. There's an entire hierarchy, and picking the right one matters more than most people realise.
WebPage (generic)
Use this as a fallback for pages that don't fit a more specific type. Landing pages, general service pages, and brand story pages often sit here. It works fine, but you're leaving signals on the table if a more specific type applies.
AboutPage
This is specifically designed for "about us" style pages. It signals to AI models that the page is a brand or identity statement, which feeds directly into how AI systems build their understanding of who you are. We've written in detail about how to use AboutPage schema to build brand trust in AI search if that applies to your site.
CollectionPage
Designed for pages that group other content, like a blog index, a product category, or a resource library. If you're trying to win category-level AI queries, this is the right type. You can read more about using CollectionPage schema to win AI category searches in a separate post.
ProfilePage
Used for pages that represent a person or entity profile. Think author pages, team member bios, or public-facing founder pages.
ItemPage
For individual item pages, which in e-commerce terms means a product detail page. Often paired with Product schema.
ContactPage, CheckoutPage, SearchResultsPage
These are highly functional types that signal exactly what the page does. A contact page marked as ContactPage gives AI models unambiguous clarity about where to send people with enquiries.
The key principle is to be specific. An AI model reading your schema and seeing WebPage on everything gets very little signal. One that sees AboutPage on your about page, CollectionPage on your category pages, and ItemPage on your products builds a proper mental map of your site architecture.
The Core Properties You Should Always Include
Let's get practical. Here are the properties that matter most when implementing WebPage schema, and why each one earns its place in the markup.
@type and @context
Always start with "@context": "https://schema.org" and the appropriate @type. That's table stakes.
name
This should match your page's H1 or title tag exactly, or very closely. It tells AI models the page's canonical name as an entity. Don't get creative here. Consistency is the signal.
description
Write a 1 to 2 sentence plain-language description of what the page covers. This is one of the properties AI language models are most likely to surface when constructing a summary or citation. Keep it factual and specific. Avoid vague phrases like "everything you need to know" and instead say what the page actually contains.
url
Include the canonical URL of the page. This anchors the schema to a specific web address and reduces any ambiguity about what's being described.
datePublished and dateModified
These properties matter more than they used to. AI models and the systems that feed them are increasingly sensitive to content freshness. Perplexity, for instance, actively surfaces recency signals. If your page was published in 2021 but updated in 2025, dateModified is how you communicate that. Use ISO 8601 format: 2025-04-15.
author
Link the page to a Person or Organization entity. This builds authorship signals and ties the page into a broader knowledge graph. At FlinnSchema, we see a consistent pattern: pages with clear author entities attached to them perform better in AI citation contexts than identical content without authorship markup.
breadcrumb
Nesting a BreadcrumbList inside your WebPage schema gives AI models a clear map of where the page sits in your site hierarchy. This is particularly useful for large e-commerce sites where a product page might sit four levels deep. The AI model doesn't have to guess the context; you're telling it directly.
isPartOf
Use this to reference the parent WebSite entity. Linking individual pages back to a WebSite schema creates a coherent connected graph rather than isolated floating documents.
primaryImageOfPage
Reference an ImageObject here to indicate the main image for the page. This feeds into visual search and AI-generated summaries that include imagery.
A Practical JSON-LD Example
Here's a real-world example for a product category page on an e-commerce site:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "CollectionPage",
"name": "Men's Running Shoes",
"description": "Browse our full range of men's running shoes, including road, trail, and track options from leading brands.",
"url": "https://example.com/mens-running-shoes",
"datePublished": "2023-01-10",
"dateModified": "2025-03-28",
"author": {
"@type": "Organization",
"name": "Example Store",
"url": "https://example.com"
},
"breadcrumb": {
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://example.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "Men's",
"item": "https://example.com/mens"
},
{
"@type": "ListItem",
"position": 3,
"name": "Running Shoes",
"item": "https://example.com/mens-running-shoes"
}
]
},
"isPartOf": {
"@type": "WebSite",
"name": "Example Store",
"url": "https://example.com"
}
}
</script>Notice that nothing here is redundant. Every property is doing a specific job. The breadcrumb tells AI models the hierarchy. The dateModified signals freshness. The author anchors brand identity. The description gives a plain-language summary the model can use directly.
Common Mistakes That Undermine WebPage Schema
Implementation errors are more common than people admit. Here are the ones we see most often.
Using generic WebPage on every page
If your CMS spits out "@type": "WebPage" for every page on the site, you're generating quantity over quality. Switch to the most specific applicable subtype. It takes more thought but the signal improvement is significant.
Mismatching the name property
If your page title says "Women's Leather Handbags" and your schema name says "Handbags Collection", you've created a discrepancy. AI systems are good at spotting inconsistency. Consistent naming across title tags, H1s, and schema is what builds entity clarity.
Omitting dateModified on updated pages
If you refresh a page's content but don't update the dateModified property, you're invisible to freshness signals. This is especially damaging in fast-moving product categories where recency is a trust indicator.
Orphaned schema with no parent WebSite reference
Individual pages floating without a isPartOf reference to a WebSite entity miss an important connective layer. The AI model has no way to understand how these pages relate to each other or to the brand as a whole.
Duplicating schema types unnecessarily
Some implementations stack three or four @type values on one page. Occasionally that's correct, but usually it's lazy. Pick the right type and implement it cleanly rather than hedging with multiple types that may contradict each other.
WebPage Schema in the Context of a Broader AI Visibility Strategy
WebPage schema doesn't work in isolation. It's one layer in a broader structured data architecture. The most effective AI-visible sites pair it with entity-level schema like Organization and Brand, product-level markup like Offer and AggregateRating, and supporting signals like OpenGraph metadata.
If you haven't mapped out how your schema types connect to each other, that's the right place to start. At FlinnSchema, we often find that e-commerce brands have reasonable on-page SEO but a completely fragmented schema implementation where page-level markup, product markup, and organisation markup never reference each other. From an AI model's perspective, that fragmentation makes the site harder to interpret with confidence.
A free AI visibility audit is a quick way to see exactly where the gaps are on your own site before you spend time implementing anything new.
Frequently Asked Questions
Does WebPage schema directly affect Google rankings?
Not in a direct, documented way. Google has said it doesn't use most WebPage schema properties as ranking factors. The value is primarily for AI search engines, knowledge graph building, and the machine-readability of your content. That said, properties like dateModified and breadcrumb do have indirect SEO benefits.
Should I add WebPage schema to every page on my site?
Yes, with the right subtype for each page. Homepage, about page, product pages, blog posts, category pages - all of them benefit from having at least basic WebPage schema with a meaningful name, description, url, and dateModified. Prioritise your highest-traffic pages first if you're implementing manually.
Can WebPage schema and Article schema coexist on a blog post?
Yes. It's common to use both Article (or BlogPosting) and a WebPage subtype on the same page. They describe different things: Article describes the content type and its journalistic properties, while WebPage describes the page as a web entity. Nest them thoughtfully or use separate JSON-LD blocks. Just make sure the properties don't contradict each other.
How do I know if my WebPage schema is working?
Use Google's Rich Results Test and Schema.org's validator to check for errors. Beyond that, monitor whether AI search tools like Perplexity start citing your pages when you query topics you cover. If you're being cited with accurate page names and descriptions, your schema is doing its job. If citations are absent or inaccurate, there's likely a gap in your structured data.