Skip to content
Issue docs

No WebPage schema

Importantwebpage_schema_missingIssue 112

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 WebPage declaration — 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, SearchResultsPage and CheckoutPage are schema.org subtypes of WebPage and are commonly declared by themselves (the page does not also need to list WebPage) — but this check only looks for the literal string WebPage, so a page declaring only ContactPage, for instance, is not evaluated by this rule either way. FAQPage is checked separately, under its own issue (#94), regardless.
  • isPartOf, breadcrumb and using a more specific subtype than generic WebPage are 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.

  1. Identify the correct WebPage subtype for each page:

    Page Type Recommended Schema Type
    About Us AboutPage
    Contact ContactPage
    FAQ FAQPage
    Search Results SearchResultsPage
    User Profile ProfilePage
    Checkout CheckoutPage
    Generic page WebPage
  2. Add 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"
          }
        ]
      }
    }
  3. Include recommended properties:

    • name: Page title
    • url: Canonical URL of the page
    • description: Page description
    • isPartOf: Link to parent WebSite entity
    • breadcrumb: BreadcrumbList for pages with navigation hierarchy
  4. 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 WebPage type is examined

  5. Validate 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

  1. Read the declared structured data: every JSON-LD block is parsed, and @graph wrappers are flattened.

  2. Select declared WebPage entities: the schema's type is read from its @type array (the first value found). Only the literal type WebPage is 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 as AboutPage, ContactPage or ProfilePage — 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 have name nor exempted from having it, it is simply invisible to this rule. FAQPage is the one exception: it is a distinct, separately-checked type under its own issue (#94), not a WebPage subtype for this check's purposes.

  3. Check the required property: a declared WebPage (the literal type) must have a name.

  4. This is reported when: the page declares the literal WebPage type missing name. A page with no WebPage schema at all is never reported, and — see above — nor is a page that only declares a WebPage subtype by name. isPartOf, breadcrumb and 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

Further reading