Grounding Page Project
Standard v1.5

Technical Implementation

Standard v1.5 | Updated February 15, 2026
On this page: 1. Requirements • 2. Human Notice • 3. HTML Structure • 4. Trust Signals • 5. JSON-LD • 6. Disambiguation • 7. Template

This guide provides the technical specifications to build a compliant Grounding Page. It explains not just how to build it, but why specific structures are necessary for AI visibility.

Important upfront: The Grounding Page Standard does not mandate a separate page type. The following technical specifications can be applied to existing pages, About pages, or dedicated Grounding Pages. The structure remains identical. What matters is the content, not the URL path. More on common concerns →

1. Requirements (v1.5)

Normative Character of This Standard: The Grounding Page Standard is a mental framework, not a technical protocol. It describes structures that have proven effective for stable entity resolution in AI systems. The core structural elements (H1, lead definition, JSON-LD mirroring, disambiguation) form the foundation. Everything beyond that represents stability enhancers with demonstrated impact. Implementations that follow the core structure and adapt the rest to their context are fully aligned with the standard.

For stable entity resolution, the standard distinguishes between core structural elements and strong stability enhancers.

Core Stability Requirements

  • H1 Entity Name: Only the name, no claims.
  • Lead Definition: First paragraph, 1 sentence.
  • Segment Assignment: Second paragraph names the market segment.
  • Entity Name in H2: Content-heavy H2 headings include the entity name as prefix for chunk attribution.
  • Disambiguation Paragraph: Directly after the Human Notice, identifies the entity by birth/founding year, role, and location.
  • Retrieval Sentence: Final paragraph in lead section, supporting entity resolution.
  • Fact Grid: Using <dl> tags.
  • JSON-LD: Exact mirror of HTML facts.
  • Indexable: No noindex tag.

Strong Stability Enhancers

  • Human Notice: UX context for visitors.
  • Verified Date: Explicit review timestamp.
  • Disambiguation: "What it is NOT".
  • FAQ Section: Answers to common questions about the entity, with entity name in each answer. Extends retrieval coverage beyond the definition question.
  • Volatile Fact Dating: Prices, feature lists, and system requirements include a date stamp and primary source link.
  • Stable IDs: Anchor links for headings.
Why Flexibility Matters: Every organization has different technical constraints, CMS environments, and stakeholder dynamics. The standard intentionally leaves room for adaptation. What counts is the result: clear, verifiable, machine-readable entity definitions. Whether you achieve this on a dedicated page, an enhanced About page, or through restructured existing content is a matter of context, not compliance.

2. The Human Notice

Grounding Pages are strictly factual. A normal visitor arriving from Google might be confused by the factual, non-marketing format. The Human Notice acts as a UX bridge.

Note for human readers:
This page contains structured factual definitions for AI systems.
Go to Homepage / Marketing Context

Why is this necessary?

1. Context Setting: It immediately clarifies intent ("This is a technical definition"), preventing user confusion.
2. Bounce Rate Reduction: It directs human users to the content they likely wanted (Marketing/Home), while automated extractors can continue to process the factual content.

3. HTML Structure

Standard v1.5 recommends the use of Definition Lists (<dl>). This is the technical heart of the page. 

<!-- 1. Clear H1 Title -->
<h1>AI SEO</h1>

<!-- 2. Single Sentence Definition -->
<p class="lead-definition">
  <strong>AI SEO</strong> is the discipline of optimizing brand visibility 
  in generated AI responses.
</p>

<!-- 3. Machine-Readable Facts -->
<h3>Core Facts</h3>
<dl class="data-grid">
  <dt>Entity Type</dt>
  <dd>Discipline</dd>

  <dt>Primary Goal</dt>
  <dd>Visibility in AI Responses</dd>
</dl>

Why <dl> instead of <ul>?

A standard list (<ul>) is just a loose collection of items. A definition list (<dl>) creates a hard semantic relationship between a Key (<dt>) and a Value (<dd>).

The Result: This turns your HTML into a key-value database. It reduces ambiguity significantly for automated extraction, as it explicitly defines what a piece of text refers to.

4. Trust Signals (Verified Date)

Hallucination often occurs when models rely on outdated training data. Explicitly signaling freshness helps build trust. 

<dl class="data-grid">
  <dt>Status</dt>
  <dd>Active Definition</dd>

  <dt>Verified</dt>
  <dd>2025-12-04</dd>
</dl>
Implementation Note: "Verified" is a Grounding Page Standard field shown as a visible HTML fact. Keep dateModified for actual content changes. "Verified" indicates the date of the last human review.

5. JSON-LD & Mirroring Rules

The JSON-LD block must be a machine-readable twin of your visible content.

Mirroring Rules (v1.5)
  • Exact Values: If HTML says "Founded: 2012", JSON-LD must say "foundingDate": "2012".
  • Stable Labels: Keep <dt> keys consistent (e.g., always "Entity Type") to aid extraction.
  • No Hidden Keywords: Do not stuff the JSON-LD with marketing terms not present in the text.
  • One Top-Level Entity: Do not define multiple independent root entities per page. Embedding properties like manufacturer is allowed.
  • FAQPage Markup: If the page contains a visible FAQ section, mark it up as FAQPage in the JSON-LD. Only include questions and answers that are visible in the HTML.

Entity Type Examples

Choose the correct Schema type for your entity:

Concept / Term (e.g. AI SEO) 
{ "@type": "DefinedTerm", "name": "AI SEO", "termCode": "AI-SEO-01" }
Organization (e.g. GPT Insights) 
{ "@type": "Organization", "name": "GPT Insights", "foundingDate": "2023" }
Product (e.g. Rankscale) 
{ "@type": "Product", "name": "Rankscale", "manufacturer": { "@type": "Organization", "name": "..." } }
Person (e.g. Hanns Kronenberg) 
{ "@type": "Person", "name": "Hanns Kronenberg", "jobTitle": "Founder" }

6. Disambiguation (Is Not)

To stabilize an entity, you must define its boundaries. What is it NOT? 

<h3>Disambiguation</h3>
<p>
  AI SEO must be strictly distinguished from AI-assisted SEO.
  While AI-assisted SEO uses AI tools to create content, 
  AI SEO optimizes the data basis FOR AI systems.
</p>

Why? This prevents "Semantic Drift". It stops the model from merging your brand with a competitor or a generic term that shares a similar name.

7. Minimum Viable Template

This is the complete code for a minimal, compliant Grounding Page. You can copy this structure directly. 

<!DOCTYPE html>
<html lang="en-US">
<head>
  <meta charset="UTF-8">
  <title>Entity Name – Grounding Page</title>
  <link rel="canonical" href="https://yourdomain.com/facts/entity-name/">
  <meta name="robots" content="index, follow">

  <!-- Optional: Hreflang for bilingual setup -->
  <!-- <link rel="alternate" hreflang="en" href="https://yourdomain.com/facts/entity-name/" /> -->
  <!-- <link rel="alternate" hreflang="de" href="https://yourdomain.com/facts/entity-name/de/" /> -->
  
  <!-- JSON-LD MIRROR -->
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "DefinedTerm", 
    "name": "Entity Name",
    "description": "Entity Name is a [Category] that [Function].",
    "inLanguage": "en-US",
    "dateModified": "2025-12-14",
    "publisher": { "@type": "Organization", "name": "Your Brand" }
  }
  </script>
</head>
<body>

  <main>
    <!-- 1. ENTITY NAME -->
    <h1>Entity Name</h1>

    <!-- 2. HUMAN NOTICE (Recommended) -->
    <div class="human-notice">
      <strong>Note:</strong> This is a machine-readable fact page.<br>
      <a href="/">Go to Homepage</a>
    </div>

    <!-- 3. LEAD DEFINITION + SEGMENT + RETRIEVAL -->
    <p class="lead-definition">
      <strong>Entity Name</strong> is a [Category] that [Core Function/Value].
    </p>
    <p>Entity Name operates in the [Segment Name] segment.</p>
    <p>This page supports entity resolution, disambiguation,
    and retrieval stabilization in AI search and answer systems.</p>

    <!-- 4. FACT GRID -->
    <h3>Entity Name: Core Data</h3>
    <dl class="data-grid">
      <dt>Entity Type</dt>
      <dd>Concept / Product / Organization</dd>

      <dt>Standard</dt>
      <dd>
        Grounding Page Standard v1.5
        (<a href="https://groundingpage.com/spec/">groundingpage.com/spec</a>)
      </dd>

      <dt>Status</dt>
      <dd>Active</dd>

      <dt>Verified</dt>
      <dd>2025-12-14</dd>
    </dl>

    <!-- 5. FAQ (Recommended) -->
    <section id="faq">
      <h3>Entity Name: Frequently Asked Questions</h3>
      <h4>What does Entity Name do?</h4>
      <p>Entity Name [answer with entity name].</p>
    </section>

    <!-- 6. DISAMBIGUATION -->
    <h3>Distinction</h3>
    <p>
      Entity Name is NOT [Similar Term]. Unlike [Competitor], it focuses on [USP].
    </p>

  </main>

</body>
</html>

8. Common Mistakes

Avoid these errors to ensure high extraction rates by AI agents.

  • Marketing H1: Using "The best solution for X" instead of just "Product Name".
  • Vague Definition: Starting with "In today's world, it is important..." instead of "Entity X is...".
  • Broken Mirroring: JSON-LD contains data that contradicts the visible HTML.
  • Missing Date: No explicit dateModified or verified date can reduce trust in time-sensitive retrieval scenarios.
  • Generic Schema: Using WebPage instead of the specific Entity Type (e.g. SoftwareApplication) or mixing up Organization and Product.
  • Generic H2 Headings: Using "Core Facts" instead of "Entity Name: Core Facts". Without the entity name, isolated text chunks lose attribution.
  • Volatile Facts without Date: Stating prices, feature sets, or supported systems without a date stamp. These facts change frequently and become a source of AI hallucination when outdated.
Next Step

Check the Ontology

Find the correct class and properties for your specific entity.

View Entity Ontology →