No WebPage schema
What is this issue?
This issue reports a page that declares the literal WebPage schema type with no
name — the only property this check requires. It does not report a page with no
WebPage schema at all.
What this issue is not:
- It does not run against every crawled page looking for a missing
WebPagedeclaration — only a page that has actually declared this type is examined. - It does not currently recognise WebPage subtypes declared on their own.
AboutPage,ContactPage,ProfilePage,SearchResultsPageandCheckoutPageare schema.org subtypes ofWebPageand are commonly declared by themselves (the page does not also need to listWebPage) — but this check only looks for the literal stringWebPage, so a page declaring onlyContactPage, for instance, is not evaluated by this rule either way.FAQPageis checked separately, under its own issue (#94), regardless. isPartOf,breadcrumband using a more specific subtype than genericWebPageare recommended, not checked.
Why it matters
WebPage schema is important for page classification and context:
- Page classification: Helps search engines understand the page's purpose and content type
- Rich results eligibility: Enables rich results specific to page types (e.g., contact page rich results)
- AI search context: AI engines use WebPage schema to understand page intent
- Site structure: Links pages to the parent WebSite entity via
isPartOf - Breadcrumb context: Embeds breadcrumb navigation context via
breadcrumb - User experience: Helps search engines serve the right page for the right query
Resolving this issue improves your SEO health score by ensuring pages are properly classified and contextualized.
How to fix it
If this issue was raised, your page already declares the literal WebPage type with
no name — that is the only property this check requires. The steps below are for a
page that declares no WebPage schema yet, and for choosing a more specific
subtype — both worthwhile, and neither ever reported as a defect either way: a page
that declares a subtype (AboutPage, ContactPage, etc.) on its own, without also
listing the literal WebPage type, is not currently examined by this check at all —
it is simply outside what this rule looks at today, not a pass or a fail.
Identify the correct WebPage subtype for each page:
Page Type Recommended Schema Type About Us AboutPageContact ContactPageFAQ FAQPageSearch Results SearchResultsPageUser Profile ProfilePageCheckout CheckoutPageGeneric page WebPageAdd WebPage JSON-LD structured data to each page's
<head>or before</body>:{ "@context": "https://schema.org", "@type": "AboutPage", "name": "About Us — Example Corp", "url": "https://www.example.com/about", "description": "Learn about our mission and team.", "isPartOf": { "@type": "WebSite", "url": "https://www.example.com" }, "breadcrumb": { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.example.com" }, { "@type": "ListItem", "position": 2, "name": "About Us", "item": "https://www.example.com/about" } ] } }Include recommended properties:
name: Page titleurl: Canonical URL of the pagedescription: Page descriptionisPartOf: Link to parent WebSite entitybreadcrumb: BreadcrumbList for pages with navigation hierarchy
Use the most specific subtype that matches your page (don't use generic WebPage if a subtype exists) — this is good schema.org practice, but note that PixyScan's own check does not currently verify a subtype declared alone; only the literal
WebPagetype is examinedValidate with Google's Rich Results Test
Examples
Example 1: No Schema Declared — Not This Issue
<!-- About page with full copy, but no WebPage schema -->
<html>
<head>
<title>About Us - Example Corp</title>
</head>
<body>
<h1>About Us</h1>
<p>Learn about our mission and team.</p>
</body>
</html>Nothing is reported.
Example 2: A WebPage Subtype Declared Alone — Not Currently Checked Either Way
{
"@context": "https://schema.org",
"@type": "AboutPage",
"url": "https://www.example.com/about",
"description": "Learn about our mission and team.",
"isPartOf": { "@type": "WebSite", "url": "https://www.example.com" }
}Nothing is reported here — not because it passes, but because this check only
recognises the literal type WebPage. AboutPage (like ContactPage,
ProfilePage, SearchResultsPage and CheckoutPage) is a real schema.org subtype
of WebPage and is commonly declared alone, exactly as shown, with no name
property at all. This check does not currently examine it either way.
Example 3: The Literal WebPage Type (passes)
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "About Us — Example Corp",
"url": "https://www.example.com/about",
"description": "Learn about our mission and team.",
"isPartOf": { "@type": "WebSite", "url": "https://www.example.com" }
}name is present on the literal WebPage type, so this passes.
Example 4: The Literal WebPage Type Missing name (fails)
Problematic state:
{
"@context": "https://schema.org",
"@type": "WebPage",
"url": "https://www.example.com/contact",
"description": "Get in touch with our team."
}Reported: name missing.
Corrected state:
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Contact Us",
"url": "https://www.example.com/contact",
"description": "Get in touch with our team."
}Example 5: A Declared FAQPage — See Issue #94, Not This One
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": []
}FAQPage is checked under its own dedicated issue (#94, which requires
mainEntity, not name) — it is never evaluated by this WebPage check, whether or
not it also happens to carry a name.
How PixyScan detects this
Read the declared structured data: every JSON-LD block is parsed, and
@graphwrappers are flattened.Select declared
WebPageentities: the schema's type is read from its@typearray (the first value found). Only the literal typeWebPageis recognised — there is no subtype expansion here (unlike, say,LocalBusiness's ~70 recognised subtypes for #89/#96). A page whose sole declared type is a WebPage subtype such asAboutPage,ContactPageorProfilePage— a common way to write this schema, and schema.org's own recommended shorthand — is not currently examined by this check at all: it is neither required to havenamenor exempted from having it, it is simply invisible to this rule.FAQPageis the one exception: it is a distinct, separately-checked type under its own issue (#94), not a WebPage subtype for this check's purposes.Check the required property: a declared
WebPage(the literal type) must have aname.This is reported when: the page declares the literal
WebPagetype missingname. A page with noWebPageschema at all is never reported, and — see above — nor is a page that only declares a WebPage subtype by name.isPartOf,breadcrumband choosing a more specific subtype are recommended but are not checked.
What we store
Storage Level
Page Level — This issue is evaluated for each individual URL that contains structured data.
Database Table / Prisma Model
PageStructuredData
Stored Fields
| Field | Type | Description |
|---|---|---|
| schemaType | SchemaType | The type of schema (e.g., Organization, Person) |
| schemaFormat | SchemaFormat | The format of the schema (JSON-LD, Microdata, RDFa) |
| schemaIdentifier | String? | Unique identifier for the schema |
| rawJson | Json? | The raw JSON-LD or structured data content |
| schemaErrors | Json? | Array of validation errors found in the schema |
| isValidSchema | Boolean? | Whether the schema is valid according to validation |
| missingFields | Json? | Reserved for future use — the crawler always writes null here today; no check currently populates it |
Detection Dependencies
- The following data sources are required to evaluate this issue:
- HTML Document — The crawler parses the HTML to find structured data (JSON-LD, Microdata, RDFa)
- Structured Data Validation — The extracted schema is validated against Schema.org definitions
- Schema Parser — JSON-LD scripts, Microdata attributes, and RDFa markup are parsed