Updated July 18, 2026: The implementation guide has been fully aligned with the building-block model of Standard v1.6. It now combines editorial principles, design, information architecture and technical implementation in one practical guide.
Readable for people. Unambiguous for machines. A Grounding Page is not a hidden page for machines, and not a technical data sheet without editorial care. It is a high-quality, editorially maintained fact page that people can read well and whose structure machines interpret clearly.
The Grounding Page Standard is not a form to be filled in mechanically. Each building block solves a concrete problem in describing an entity clearly and unambiguously. Once you understand that task, you can adapt the block flexibly to your brand, content and technical environment.
The better editorial, design, SEO and engineering understand the purpose of each block, the more sensibly they can work with them. The Standard therefore defines not only structures, but also their purpose and how they work together.
Companions to this guide:
the Grounding Playbook explains the ten goals behind a Grounding Page.
You can then validate any draft with the free Grounding Page tools —
a quick Grounding Check for diagnosis or the Entity Decoder for a deeper, entity-centred analysis.
Editorial model: good Grounding Pages take their cue from a high-quality encyclopedia rather than a campaign landing page. They may be styled to match the brand, but they should convey facts calmly, precisely and verifiably: an immediate definition of the entity, factual language, a clear section hierarchy, recognizable sources, self-contained sections and regular updates.
About the examples: the examples in this documentation mostly use the fictional brand VeloNova from the AI Grounding Playbook along with other clearly fictional entities. This lets us explain principles concretely without co-opting real organizations as a model or counter-example. Real implementations can be found in the curated reference library.
1. The building-block principle
A good Grounding Page is assembled from several clearly defined building blocks. Not every block has to look the same. What matters is that the key elements together form a consistent, understandable and machine-readable whole.
1 Entity & page topic What the page is about
2 Clear page title The name, not a slogan
3 Unambiguous lead definition Explain the entity immediately
4 Self-contained sections Each H2 stands on its own
5 Structured facts Attribute and value, unambiguous
6 Disambiguation Distinguish from the similar
7 Sources & recency Verifiable and dated
8 JSON-LD mirroring Machine-readable like the text
9 Internal linking Findable and connected
10 Brand & page design Part of the website
11 Quality assurance & upkeep Kept current over time
These blocks are not a rigid template to be worked through top to bottom. They build on each other and reinforce one another:
Define the entity
→ define the entity immediately
→ break topics into self-contained sections
→ make key facts explicit and structured
→ distinguish similar entities from each other
→ secure claims with sources and recency
→ mirror visible information in machine-readable form
→ embed the page in the website and entity network
Understanding before conformance. A formally complete page can still be weak if the blocks are used without understanding. Conversely, an individually designed page can meet the Standard very well if it reliably fulfils the purpose of each block. Version 1.6 evaluates not just the presence of certain elements, but their function within a clear, readable and consistent entity description.
2. What the Standard v1.6 requires
Version 1.6 does not prescribe a rigid page template. It distinguishes three levels: blocks that form the core, blocks that clearly increase stability, and blocks that make sense depending on the entity and context.
Required blocks
Without these, an implementation does not match the core of the Standard:
a clearly defined main entity
an H1 with the name of the entity
an unambiguous lead definition
the entity name in content-bearing H2 headings
visible structured facts
a suitable Schema.org entity type
content mirroring between HTML and JSON-LD
an indexable page
Recommended stability blocks
explicit disambiguation from similar entities
source references
a status or review date
an FAQ or supplementary questions
stable section anchors
language-specific pages with hreflang
links to related entities
Context-dependent blocks
a dedicated facts directory
multiple Grounding Pages
tables and timelines
comparison sections
a glossary or case studies
contact or governance notes
“Grounding Page” need not appear on the page. The term does not have to appear in the H1 or in the visible text. Just as a landing page does not have to call itself a “landing page”, a Grounding Page does not have to be named technically. A discreet reference to the Standard can live in the footer, in the metadata or in the source code — it is not a required part of the editorial content.
Suitable titlesVeloNova Germany · Facts about Silberhöhe Nature Park · HealthTech Forum Rhein: Facts and Key Data · Clario Metrics · ClearSource Framework
Not requiredVeloNova Grounding Page · Official Grounding Page of HealthTech Forum Rhein · Grounding Page about Clario Metrics
Principle and possible implementation
For each block, separate what must be achieved functionally from how the goal is implemented concretely. The Standard requires a function — the concrete form is your room to design.
Principle
Possible implementation
Assign facts unambiguously to attributes
<dl>, a table or a clearly labelled profile box
Distinguish the entity from similar terms
Lead, FAQ or a dedicated distinction section
Make recency visible
“Status”, “Reviewed on” or dated sources
Make the page findable internally
Footer link, facts hub or contextual links
Connect related entities
Prose links, a directory or thematic navigation
Section order and classification metadata (v1.6.1 clarification)
The required blocks define the information a Grounding Page should contain. Their order is recommended, not mandatory, unless a block explicitly states otherwise. What matters functionally is that the entity definition and core facts appear early, that external references do not dominate the upper part of the page, that source references stay clearly separated from editorial reading suggestions, and that every section works as a self-contained chunk. A Further Reading section should appear in the lower part of the page, but may be placed before or after the FAQ and References sections.
Classification metadata (entity type, industry or category, geographic scope, parent entity or organization, status, and key relationships) is required as information, but not necessarily as a standalone visible section. It may be integrated into the entity summary, the core facts, or the structured data. A dedicated classification-metadata section is only warranted when the classification itself needs explanation.
Why this clarification. A Grounding Page needs information consistency and self-contained, understandable chunks, not a single mechanical section order applied everywhere. Treating the recommended order as a rigid template would turn the Standard into a fixed page template, which is explicitly not the intent. A page that keeps Further Reading near the end (after FAQ and References) or that carries its classification inside the core facts still meets the functional requirements of the Standard.
3. Define the entity and page topic
Every Grounding Page describes exactly one main entity. Before anything is written, it must be clear what the page is about and what it deliberately does not cover.
Why it matters
Most entity errors come not from missing facts but from an unclear focus. If a page explains a company, its products and its founder all at once, no system can assign it to a single entity cleanly. A clear subject is the basis for every other block.
How to implement it
Fix the entity as a noun (brand, product, person, place, event, method, study …) and choose the matching Schema.org type. Independent sub-entities get their own page and are only linked, not described in passing.
Example: VeloNova Fictional example brand
VeloNova is the company (an organization). The VeloNova City One urban e-bike is a separate product, and the fictional materials researcher Dr. Lena Hartmann is a separate person. The product and the person get their own pages and are only briefly placed in context and linked from the company page — not described as equal-rank main entities.
Room to adapt
The right entity type depends on the subject. Some pages describe a concept, others a product, an event or a person. What matters is the unambiguous assignment, not a specific page type.
Common mistake
Bundling several equal-rank entities on one page — a company, all its brands and all its locations in one document. This dilutes the focus and complicates assignment.
Reflection: Could the subject of this page be named unambiguously in a single sentence — and does the page really describe only that one subject?
4. H1 and lead definition
The H1 names the entity; the lead defines it immediately. The lead is not a technical mandatory field but an editorial opening that places the entity in a few sentences.
Why it matters
People and systems decide in the first lines what a page is about. If a page starts with “In today’s world it is important …”, the entity stays unclear. An immediate definition creates clarity and trust.
How to implement it
The lead ideally consists of two to three short paragraphs: a definition, a placement in the market segment, and an unambiguous distinction from related entities.
Example: VeloNova FictionalDefinition: VeloNova is a fictional German bicycle manufacturer from Freiburg im Breisgau that develops and sells e-bikes, trekking and urban bicycles. Placement: The company operates across the DACH region as well as the Netherlands and Scandinavia, positioned in the segment of high-quality everyday and trekking bikes. Distinction: VeloNova is an independent bicycle brand of the fictional VeloNova GmbH. The company is not a bicycle retailer and not a repair workshop.
Room to adapt
Two or three paragraphs, depending on complexity. The order definition → placement → distinction is proven but not rigid. For simple entities the distinction may be omitted.
Common mistake
A visible technical paragraph such as “This page supports entity resolution, disambiguation and retrieval stabilization in AI search and answer systems.” It explains the technical intent but does not help human readers — it does not belong on the page.
Reflection: After the first paragraph, does someone understand what the entity is — without having read the rest of the page?
5. Self-contained H2 sections with the entity name
The entity name in the heading anchors every key section unambiguously to the entity being described.
Why it matters
Web pages are often not processed by search and AI systems as a whole document. Individual sections can be extracted, indexed or cited independently. A heading like “History” loses its assignment outside the page context. “History of VeloNova” stays understandable even in isolation.
How to implement it
Put the name of the main entity into the load-bearing H2 headings. Small H3 sub-headings need not be mechanically overloaded with the full name — the rule applies primarily to the main sections.
Good FictionalHistory of VeloNova · VeloNova bicycle models · VeloNova locations · VeloNova sustainability strategy · FAQ about VeloNova
Not idealAbout us · History · Models · More information
Room to adapt
“History of VeloNova”, “VeloNova and its history” or “Historical development of VeloNova” all serve the same purpose. The wording may fit the brand.
Common mistake
Generic headings that are only understandable within the full page context and lose their assignment when processed in isolation.
Reflection: Would this section still be clear and useful if it were shown without the rest of the page?
6. Structured facts
Structured facts make an entity’s key attributes quick to grasp and assign an unambiguous value to each attribute.
Why it matters
Important facts get lost in long prose. People have to hunt for them, and machines first have to infer which value belongs to which attribute. A clear attribute-value structure reduces this uncertainty. Definition lists express the relationship between a term and its value explicitly.
How to implement it
For stable core data, the definition list is especially well suited. Longer explanations belong in normal prose, developments over time in a timeline, comparisons in a table.
Example: Clario Metrics Fictional
<dl class="data-grid">
<dt>Product type</dt><dd>Analytics software</dd>
<dt>Operator</dt><dd>Clario Systems GmbH</dd>
<dt>Available languages</dt><dd>German and English</dd>
</dl>
Room to adapt
The block can be a definition list, a compact fact table, a profile box, a data area or a labelled card layout. What matters is not identical styling but the unambiguous relationship between attribute and value.
Common mistake
Forcing every piece of information into a fact grid. Not everything is core data; readability for people remains decisive.
Reflection: For every fact, is it clear which value belongs to which attribute — for people and for machines alike?
7. Distinguishing similar entities
Disambiguation describes how the entity differs from similarly named, related or frequently confused entities.
Why it matters
Many entity errors come not from missing facts but from wrong assignment. Brands get mixed up with parent companies, products, events or same-named organizations. A clear distinction stabilizes the identity and prevents claims from different contexts being merged.
How to implement it
Typical distinctions: brand vs. parent company, product vs. company, event vs. organizer, person vs. same-named person, method vs. software, location vs. organization. The distinction can be integrated naturally into the lead or a thematically fitting section.
Example: HealthTech Forum Rhein FictionalHealthTech Forum Rhein is a trade event for digital health. It is neither an industry association nor a software product nor a medical service provider.
Room to adapt
The distinction can appear in the lead, in a dedicated section, inside an FAQ, as a note in the core data, or in a description of the group or brand structure. A visible “What it is not” heading is not required.
Common mistake
A schematic “What is it NOT?” list that feels artificial, instead of weaving the distinction naturally into the prose.
Reflection: Does this block reduce a concrete, real risk of confusion?
8. Sources, status and editorial review
Sources and a visible review date make claims verifiable and show how current the page is.
Why it matters
Facts age. Prices, feature sets or roles change. Without a source and a date, there is no way to judge whether a statement still holds — neither for people nor for machines.
How to implement it
Show a visible review date and link to reliable sources. Keep the wording precise:
Suitable labelsLast editorially reviewed · Status · Updated on · Content checked on
“Verified” should be used carefully so it does not create the impression of an external certification. A visible review date remains helpful nonetheless.
Example: VeloNova City One FictionalRange, price and available model variants carry a visible “as of” date, because these figures can change.
Maintenance interval
Every Grounding Page should be reviewed editorially at least every three to six months. Review immediately on: name changes, new products, changed prices, leadership changes, new locations, changed features, mergers or acquisitions, new regulatory facts, or discontinued offerings. The visible review date is only changed when a real human review has taken place; dateModified only for genuine content changes.
Governance example: ClearSource Framework Fictional — the editorial team of the fictional ClearSource Institute is responsible. The page is reviewed twice a year and updated immediately when the version, licence or scope changes.
Common mistake
Bumping a review date automatically on every deploy without an actual review — this devalues the signal.
Reflection: Can a reader see when these facts were last checked by a human — and where they come from?
9. JSON-LD and mirroring
JSON-LD describes the same entity and the same facts as the visible content — as a machine-readable mirror, not a second layer of content.
Why it matters
Structured data makes machine extraction easier. When it diverges from the visible text, contradictions arise that cost trust. JSON-LD may make the page more precise, but it must not contain additional marketing messages invisible to people.
How to implement it
Choose the right Schema.org type and mirror the visible core data. Using the fictional software Clario Metrics as an example:
Room to adapt
The type follows the entity: Organization, Product/ProductModel, Person, Event, DefinedTerm and others. If the page contains a visible FAQ, mirror it as FAQPage — only with questions and answers that are also visible.
Common mistake
A generic WebPage type instead of the specific entity type, or JSON-LD that contains data contradicting the visible HTML.
Reflection: Does every JSON-LD statement also appear visibly on the page — without contradiction?
10. Design and brand integration
A Grounding Page should not look like a foreign technical document. Header, footer, typography, colours, navigation and spacing may and should follow the existing brand presence.
Why it matters
Trust is also built through design. If the fact page looks like a technical appendix, it loses credibility. If it fits into the brand, it is perceived as a natural, high-quality part of the website.
Real example: L’Oréal Paris Deutschland
The fact page of L’Oréal Paris Deutschland shows that a Grounding Page does not have to look like a separate technical area. The regular brand header, the typography and the footer are retained. As a result the fact page fits visually into the existing brand presence while staying clearly and factually structured.
The Grounding Page of L’Oréal Paris Deutschland adopts the header, typography and visual language of the regular brand presence. Public web presence, retrieved 18 July 2026. View the L’Oréal Paris Grounding Page.
This example serves only to illustrate the visual brand integration. It is not a full assessment or certification of the implementation. Further real implementations — including L’Oréal Paris, DMEA, mymuesli and the Stanglwirt among others — can be found in the curated reference library.
How to implement it
Use the regular site header and footer, keep the existing typography, use brand colours sparingly, allow a generous reading width, a clear structure, good mobile readability, and visible links and sources. Use tables only where they genuinely help people. No dashboard look, no overloaded card landscapes, no unnecessary technical notices.
No “human reader” box
A separate box with a note such as “This page contains structured fact definitions for AI systems” is not required and is no longer recommended in the Standard. A well-executed page needs no warning about why it exists. If a page only becomes understandable through such a notice, its editorial design is not yet good enough. (Existing examples may still be shown for historical reasons; the new template no longer contains this box.)
Reflection: Does the page feel like a natural, high-quality part of the website — or like a technical foreign body?
11. Internal linking and facts directories
A Grounding Page must not be an isolated page reachable only through the sitemap. It is linked internally and connected to related entities.
Why it matters
Findability and relationships help people and machines alike. Contextual links make clear how entities relate to each other — which stabilizes understanding beyond a single page.
How to implement itSingle page: link it in the footer or a suitable information area, e.g. as “Facts”, “Company facts” or “About the company”. The link text need not read “Grounding Page”.
Multiple pages: create a central overview page (/facts/ or /fakten/) and link all entity pages from there.
In the prose: connect related entities contextually.
Contextual link in the prose Fictional“VeloNova develops the VeloNova City One urban e-bike and equips rental offers in the Silberhöhe Nature Park region with it.” — both underlined terms point to their respective fact pages.
Room to adapt
A footer link, a facts hub or thematic navigation — depending on the size of the project. What matters is that related pages are connected not only through cards or a sitemap, but also through contextual links in the prose.
Common mistake
Making Grounding Pages reachable only through a sitemap or a card overview, and leaving the relationships between entities unlinked in the text.
Reflection: Can a person find this page through the normal website — and can they see which other entities it relates to?
12. Multilingual Grounding Pages
For each language there is a dedicated, internally consistent page, connected to its language variants via hreflang.
Why it matters
An entity should be understandable and unambiguous in each language area, in that language. Clear language variants prevent hybrid forms that destabilize the entity’s assignment.
How to implement it
One dedicated page per language with a consistent, canonical spelling of the name. hreflang references to all language variants (including x-default). Proper names stay unchanged; descriptive parts are translated idiomatically, not word for word.
Room to adapt
Not every page needs every language. Start with the languages that matter most for the public perception of the entity.
Common mistake
Bilingual hybrid forms on a single page. They can re-destabilize entity stability — one consistent canonical form per language version is safer.
Reflection: Is the entity clear in each language version on its own — without mixing in another language?
13. How many pages and editorial scaling
The number of Grounding Pages should cover a company’s important entities without creating more editorial upkeep than can be sustained over time.
Why it matters
A single page is often not enough when a company has several important entities. At the same time, a large number of maintained pages does more harm than good if the content ages. Scope and maintainability belong together.
How to implement it
Create Grounding Pages for all entities that matter for the public perception, search and machine classification of the company. Typical independent entities include companies, brands, products, services, key people, events, locations, studies, methods, software products, tourism offerings and institutions.
Room to adapt
As practical guidance: small organizations often 1 to 5 pages, companies with several brands or products often 5 to 20 pages, large information projects significantly more. There is no universally correct number.
Common mistake
Artificial scaling without editorial governance — creating many pages that nobody maintains over time.
Reflection: Can every published page still be reliably reviewed and updated twelve months from now?
14. Practice template
The template comes in two views: the editorial structure (what belongs on the page) and the technical scaffold (how it is marked up).
A. Editorial structure
H1: Entity name
Lead (2–3 paragraphs):
What is the entity?
Which segment does it operate in?
How is it clearly distinguished?
H2: Entity name: Core data — Structured facts
H2: History of Entity name — Readable prose with sources
H2: Products and services … — Factual description
H2: Distinguishing Entity name — Distinction from similar entities
H2: FAQ about Entity name — Only where there is real need (optional)
Status and sources
B. Technical scaffold
No “human reader” box, no visible retrieval sentence. “Grounding Page” need not appear in the title. H2 headings carry the entity name. A regular header and footer are allowed. The Standard reference sits discreetly in a source-code comment or in the footer.
Show full code
<!-- Standard reference kept discreet, e.g. as a comment or footer link:
Grounding Page Standard v1.6 – groundingpage.com/spec -->
<!-- 1. Clear title (the entity name only) -->
<h1>Entity name</h1>
<!-- 2. Lead definition: definition, placement, distinction -->
<p class="lead-definition">
<strong>Entity name</strong> is a [category] that [core function].
</p>
<p>Entity name operates in the [segment] segment.</p>
<p>Entity name is part of [parent] and is to be distinguished from [similar].</p>
<!-- 3. Core data (structured facts) -->
<h2>Entity name: Core data</h2>
<dl class="data-grid">
<dt>Entity type</dt><dd>Organization / Product / Concept</dd>
<dt>Founded</dt><dd>2014</dd>
<dt>Location</dt><dd>Freiburg im Breisgau</dd>
<dt>Last reviewed</dt><dd>2026-07-18</dd>
</dl>
<!-- 4. Self-contained sections with the entity name -->
<h2>History of Entity name</h2>
<p>Readable prose with sources.</p>
<h2>Distinguishing Entity name</h2>
<p>Entity name is not [similar]. Unlike it, [distinction].</p>
<!-- 5. FAQ (optional) -->
<h2>FAQ about Entity name</h2>
<h3>What does Entity name do?</h3>
<p>Entity name [answer with entity name].</p>
<!-- 6. Internal links to related entities -->
<p>Related: <a href="/facts/related-entity/">Related entity</a></p>
<!-- 7. JSON-LD as a mirror of the visible content -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Entity name",
"foundingDate": "2014",
"location": "Freiburg im Breisgau"
}
</script>
15. Common mistakes
Marketing H1: “The best solution for X” instead of simply the entity name.
Vague definition: “In today’s world it is important …” instead of “Entity X is …”.
Visible technical sentence: a retrieval note in the prose that does not help people.
Human box as a requirement: a warning about why the page exists — no longer recommended.
Generic H2: “Core data” instead of “Entity name: Core data”. Without the name, isolated chunks lose their attribution.
Contradictory mirroring: JSON-LD contains data that contradicts the visible HTML.
Missing date: no visible review date on time-sensitive facts.
Generic schema:WebPage instead of the specific entity type, or mixing up Organization and Product.
Fact-grid forcing: pressing every piece of information into a definition list, including long explanations.
Artificial scaling: many pages without editorial upkeep.
16. Checklist before publishing
Is the main entity unambiguous?
Are related products or people treated as their own entities?
Does the H1 contain only the entity name or a clear designation?
Does the first paragraph define the entity immediately?
Do the important H2 headings contain the entity name?
Are all sections understandable in isolation?
Are the facts easy for people to read?
Are stable facts marked up as structured data?
Does the JSON-LD mirror the visible content without contradiction?
Are sources and a review date visible?
Is the page indexable?
Is the page linked internally?
Does the design fit the brand presence?
Are related entities sensibly linked?
Can the organization review the page every three to six months?
Next step
Choose the right entity type
Find the correct class and properties for your specific entity.
