Webpage Schema Generator

WebPage schema is structured data that describes a web page itself rather than the content on it. While types like Product, Article, or Recipe describe what a page is about, WebPage describes the page as a document. It defines properties like the page name, URL, description, when it was published and last modified, who published it, what language it's in, and where it sits in your site's hierarchy.

Think of it as metadata about the container rather than the contents. A recipe page might have both Recipe schema describing the dish and WebPage schema describing the page that holds that recipe. They serve different purposes and provide search engines with different layers of context.

WebPage schema is part of the CreativeWork hierarchy in Schema.org, and it serves as a parent type for several more specific subtypes that let you classify pages by their function on your site.

Schema.org defines several subtypes under WebPage, each designed for a specific kind of page. Using the right subtype gives search engines a clearer signal about what role a page plays on your site.

• AboutPage. For your "About Us" or company information page. Tells search engines this page describes the organization or person behind the site rather than offering a product or service.
• ContactPage. For your contact or "Get in Touch" page. Signals that this page exists for users to reach out, which helps search engines understand your site's navigational structure.
• FAQPage. For pages built around frequently asked questions. Note that FAQPage has its own rich result format with expandable questions in the SERP, so if your primary goal is earning FAQ rich results, you'll want to use FAQPage schema with proper Question and Answer markup rather than generic WebPage.
• CollectionPage. For pages that aggregate or list other items, like a blog index, a product category page, or a portfolio gallery. This tells search engines the page's value comes from curating links to other pages rather than presenting standalone content.
• ItemPage. For pages focused on a single specific item, like an individual product page or a single listing in a directory. This is a general-purpose subtype for detail pages.
• SearchResultsPage. For your internal search results pages. Marking these appropriately helps search engines understand that these are dynamically generated index pages, not unique content pages.
• CheckoutPage. For pages in your purchase flow. This signals transactional intent and helps search engines map your site's conversion funnel.
• ProfilePage. For user profile pages on platforms and communities. Useful for social sites, forums, and membership platforms where individual users have public-facing pages.

WebPage schema doesn't generate flashy rich results the way Product or Recipe schema does. Its value is more foundational. It helps search engines build a more complete and accurate model of your site, which can influence how your pages are crawled, indexed, and presented across different search features.

• Site structure signals. By defining breadcrumbs, parent pages, and page types across your site, you help search engines understand your information architecture. This clarity can improve how your sitelinks appear in search results and how efficiently bots crawl your pages.
• Publisher and authorship context. WebPage schema lets you connect each page to its publisher (your organization) and, where applicable, its author. This establishes entity relationships that feed into Google's understanding of who creates and stands behind your content, which matters for E-E-A-T signals.
• Freshness signals. The datePublished and dateModified properties give search engines explicit timestamps for when content was created and last updated. For time-sensitive topics, these signals can influence how prominently your page is ranked relative to newer or older competing content.
• Canonical and language targeting. Properties like url and inLanguage reinforce your canonical URL preferences and help search engines serve the right version of your page to the right audience. This is especially useful for multilingual sites or sites with duplicate content concerns.

The generator supports all commonly used WebPage properties. Here's what matters most and when to include each one.

• Name. The title of the page. This should match your title tag or the primary heading on the page. Keep it descriptive and specific to the page's content or purpose.
• Description. A brief summary of the page, similar to your meta description. This gives search engines another data point for understanding the page's topic and intent.
• URL. The canonical URL of the page. Use the full absolute URL including the protocol. This reinforces which URL you consider the authoritative version, which is particularly useful if your page is accessible through multiple URL paths.
• datePublished and dateModified. Use ISO 8601 format for both. datePublished is when the page first went live. dateModified is the most recent meaningful update. Don't update dateModified for trivial changes like fixing a typo. Reserve it for substantive content updates that actually change what the page offers.
• inLanguage. The language of the page content using an IETF language tag like "en" for English or "es" for Spanish. Essential for multilingual sites and helpful even for single-language sites as an explicit signal.
• isPartOf. Links the page to a parent WebSite entity, which helps define the relationship between individual pages and the broader site. This is especially useful when combined with a WebSite schema block on your homepage.
• Breadcrumb. Defines the page's position in your site hierarchy as a BreadcrumbList. Breadcrumb schema can also be implemented independently, but nesting it inside WebPage schema keeps all your page-level structured data organized in one block.
• Publisher. An Organization or Person entity representing who published the page. Include at minimum the publisher name and logo. This property ties your content back to a known entity and supports E-E-A-T signals.
• primaryImageOfPage. The main image associated with the page. This helps search engines identify which image is most representative of the page's content, which can influence image search results and how thumbnails appear in various search features.

WebPage and WebSite are complementary types that describe different levels of your site's structure. WebSite describes the site as a whole, while WebPage describes individual pages within that site. Together, they give search engines a hierarchical model of your entire web presence.

A typical setup has one WebSite schema block on your homepage defining the site name, URL, publisher, and search action (for sitelinks search boxes). Then each page across the site has its own WebPage schema block that references the parent WebSite using the isPartOf property.

This parent-child relationship helps search engines understand that all your pages belong to the same site and share the same publisher. It also supports the generation of sitelinks, breadcrumb displays, and other search features that rely on understanding your site's structure.

You don't need WebSite schema for WebPage schema to be valid, and vice versa. But implementing both creates a more complete picture that benefits your site's overall search presence.

Yes, and in most cases you should. WebPage schema describes the page as a document, while other schema types describe the content on that page. They coexist without conflict.

A blog post might have both an Article schema block describing the post content and a WebPage schema block describing the page itself. A product page might combine Product schema with an ItemPage schema block. A how-to guide could have HowTo schema alongside a WebPage block.

There are two common approaches for combining them. You can use separate JSON-LD script tags for each type, which keeps things modular and easy to manage independently. Or you can nest the content schema inside the WebPage schema using the mainEntity property, which explicitly tells search engines that the Article, Product, or other type is the primary content of that page.

The mainEntity approach is technically more precise and can help search engines disambiguate pages that contain multiple types of content. If a page has a product listing and a set of FAQs, nesting the Product as the mainEntity of an ItemPage makes it clear which content is primary.

Ideally, yes. Every page on your site is a web page, and every page benefits from explicit structural metadata. That said, the practical priority depends on your site size and resources.

Start with your most important pages: the homepage, primary landing pages, key category pages, and high-traffic content pages. These are the pages search engines interact with most and where clear structural signals matter most.

For larger sites, dynamic schema generation through your CMS or templating system makes site-wide implementation practical without manual effort on each page. Most modern CMS platforms and SEO plugins can generate WebPage schema automatically based on page type, publish date, and other fields already in the system.

Pages you can deprioritize include thin utility pages like privacy policies, terms of service, and login screens. These pages still benefit from schema, but the SEO impact is minimal since they rarely compete in search results.

• Using the generic WebPage type when a subtype fits. If your page is clearly an About page, Contact page, or FAQ page, use the corresponding subtype. The generic WebPage type works as a fallback, but subtypes provide more specific signals that search engines can act on.
• Setting dateModified to the current date on every page load. Some CMS configurations dynamically update the modification date whenever the page is served, even if the content hasn't changed. This dilutes the value of the freshness signal and can make search engines distrust your timestamps. Only update dateModified when the page content actually changes.
• Duplicating information already in other schema blocks. If you already have Article schema with a datePublished and author, you don't need to repeat those same properties in a separate WebPage block unless you're specifically trying to describe the page versus the article. Redundancy isn't harmful, but unnecessary complexity increases the chance of mismatches.
• Omitting the URL property. Without an explicit URL, search engines have to infer which URL represents the page. This is usually fine, but being explicit eliminates ambiguity, especially on sites with parameter-heavy URLs, trailing slash inconsistencies, or multiple access paths to the same content.
• Using WebPage schema on non-page resources. PDF files, images, and other non-HTML resources aren't web pages. Don't apply WebPage schema to them. Use the appropriate Schema.org type for the resource, like ImageObject or DigitalDocument.
• Ignoring the breadcrumb property. Breadcrumb markup nested inside WebPage schema is one of the easiest wins in structured data. It helps search engines understand your site hierarchy and can generate breadcrumb trails in search results that replace your raw URL string with a clean, navigable path. If your site has any depth at all, include breadcrumbs.