Was ist Grounding Page?

Dieser Beitrag wurde für den Groundingpage Standard V 1.4 erstellt, aber mittlerweile für den Standard V 1.6.1 aktualisiert (Stand 18.08.2026).

Was hat sich zwischen V 1.4 und V 1.5 geändert?

Version 1.5 betrifft ausschließlich Inhaltsstruktur und semantische Stabilität, nicht URL-Logik oder Routing.

Was hat sich zwischen V 1.5 und V 1.6 geändert?

V1.6 (15.05.2026) ist ein Update der Informationsarchitektur, kein Schema-Wechsel. Grounding Pages werden konsequent als Referenzseiten gedacht: Die Seite startet direkt mit der Entität, die einleitende Hinweisbox entfällt, externe Verweise wandern in einen eigenen Abschnitt weiter unten. Schema.org-Markup, Ontologie und Governance bleiben unverändert.

V1.6.1 (21.07.2026) ist eine Klarstellung, kein neuer Stand: Die Reihenfolge der Blöcke ist empfohlen, nicht verpflichtend. Wie schon bei V1.5 gilt, dass es sich um ein reines Content-Update handelt. An URLs, Canonicals oder hreflang ändert sich nichts.

Kurzantwort: Eine Grounding Page ist eine strukturierte, maschinenlesbare Faktenseite für eine Marke, Person oder ein Konzept. Sie liefert KI-Systemen ein stabiles, zitierfähiges Fundament, damit diese Entitäten korrekt interpretieren und wiedergeben. Das Ergebnis ist weniger Halluzinationen und zuverlässigere Antworten. Das Grounding Page Project wurde von Hanns Kronenberg entwickelt.

Grounding Pages sind ein offener Standard, entwickelt, um die typischen Schwachstellen moderner KI-Systeme zu adressieren: Halluzinationen, instabile Entitätsinterpretationen und Verzerrungen im Retrieval, zum Beispiel englisch-dominierte Retrieval-Pfade. Der Standard stellt eine klare Struktur und Vertrauenssignale bereit, sodass KI-Modelle Marken, Personen oder Konzepte verlässlich erkennen und zitieren können.

Tipp:

Dieser Beitrag dient als Kurzdefinition zum Thema Grounding Page. Zum ausführlichen Blogbeitrag zu Grounding Pages geht's hier.

Was gehört auf eine Grounding Page?

Eine Grounding Page ist absichtlich einfach und faktenorientiert. Version 1.6 beschreibt sie allerdings nicht mehr als Formular mit Pflichtfeldern, sondern als Baukasten aus elf Bausteinen. Jeder Baustein löst ein konkretes Problem bei der eindeutigen Beschreibung einer Entität. Wer die Aufgabe eines Bausteins verstanden hat, kann ihn flexibel an Marke, Entität und Technik anpassen. Der Standard unterscheidet dabei drei Ebenen.

Pflichtblöcke

Ohne diese Elemente entspricht eine Umsetzung nicht dem Kern des Standards:

• Genau eine klar definierte Hauptentität pro Seite
• Eine H1 mit dem Namen der Entität
• Eine eindeutige Lead-Definition aus Definition, Einordnung ins Marktsegment und Abgrenzung
• Der Entitätsname in inhaltstragenden H2-Überschriften
• Sichtbare strukturierte Fakten
• Ein passender Schema.org-Entitätstyp
• Inhaltliche Spiegelung zwischen HTML und JSON-LD
• Eine indexierbare Seite

Empfohlene Stabilitätsblöcke

Diese Elemente sind nicht verpflichtend, erhöhen die Stabilität aber deutlich:

• Explizite Abgrenzung zu ähnlichen Entitäten
• Quellenangaben
• Ein Status- oder Prüfdatum
• Eine FAQ oder ergänzende Fragen
• Stabile Abschnitts-Anker
• Sprachspezifische Seiten mit hreflang
• Verlinkung zu verwandten Entitäten

Kontextabhängige Blöcke

Diese Elemente ergeben je nach Entität und Projektgröße Sinn:

• Ein eigenes Faktenverzeichnis
• Mehrere Grounding Pages
• Tabellen und Zeitleisten
• Vergleichsabschnitte
• Glossar oder Fallbeispiele
• Kontakt- oder Governance-Hinweise

Die Reihenfolge ist nicht vorgeschrieben. Version 1.6.1 stellt ausdrücklich klar, dass die Pflichtblöcke definieren, welche Information auf die Seite gehört, nicht in welcher Abfolge. Funktional zählt: Definition und Kerndaten stehen früh, externe Verweise dominieren nicht den oberen Seitenbereich, Quellen bleiben von redaktionellen Leseempfehlungen getrennt, und jeder Abschnitt funktioniert für sich allein. Auch Klassifikationsmetadaten wie Entitätstyp, Branche, geografischer Geltungsbereich oder übergeordnete Organisation sind als Information verpflichtend, brauchen aber keinen eigenen sichtbaren Abschnitt. Sie dürfen im Lead, in den Kerndaten oder in den strukturierten Daten stehen. Der Hintergrund dieser Klarstellung ist eindeutig: Der Standard soll kein starres Seitentemplate werden.

Was in V1.6 weggefallen ist

Drei Elemente, die frühere Versionen noch vorgesehen haben, gelten nicht mehr. Wer eine Grounding Page nach V1.4 oder V1.5 gebaut hat, sollte hier nachziehen.

Die Human Notice. Die separate Hinweisbox für menschliche Leser wird nicht mehr empfohlen. Die Begründung des Standards ist unmissverständlich: Wenn eine Seite erst durch einen solchen Hinweis verständlich wird, ist die redaktionelle Umsetzung nicht gut genug. Dasselbe gilt für sichtbare Sätze, die den technischen Zweck der Seite erklären.

Die schematische „Was es NICHT ist"-Liste. Die Abgrenzung bleibt wichtig, die feste Überschrift dafür nicht. V1.6 führt die schematische Negativliste sogar als typischen Fehler und empfiehlt stattdessen, die Abgrenzung natürlich in Lead, Faktenblock, Abschnitt oder FAQ einzuweben.

Das sichtbare Compliance-Badge. Der Verweis auf den Standard gehört diskret in den Footer oder in einen Quelltext-Kommentar. Der Begriff „Grounding Page" muss weder im Seitentitel noch im sichtbaren Text vorkommen. Entscheidend ist die Funktion der Seite, nicht ihre technische Bezeichnung. Ein guter Titel lautet „Cyber Sour", nicht „Grounding Page von Cyber Sour".

Angepasst wurde außerdem die Wortwahl beim Prüfdatum. Der Begriff „verifiziert" soll sparsam verwendet werden, damit nicht der Eindruck einer externen Zertifizierung entsteht. Empfohlene Formulierungen sind „Zuletzt redaktionell geprüft", „Stand" oder „Aktualisiert am". Und das Datum wird nur geändert, wenn tatsächlich ein Mensch geprüft hat, nicht automatisch bei jedem Deployment.

Reference-First: Die Seite beginnt mit der Entität

Der obere Seitenbereich gehört seit V1.6 allein der Entität, ihrer Definition und den wichtigsten Fakten. Kontextreferenzen wandern nach unten. Das Vorbild ist explizit Wikipedia: Ein Nachschlagewerk erklärt zuerst den Gegenstand und liefert Verweise danach. Der Lead besteht idealerweise aus zwei bis drei kurzen Absätzen in der Reihenfolge Definition, Einordnung ins Segment, Abgrenzung.

Ergänzt wurde dafür ein neuer Abschnitt „Weiterführende Informationen" im unteren Seitenbereich. Dort werden externe Referenzen, offizielle Websites, verwandte Projekte und ergänzende Dokumentation gesammelt. Das trennt den kanonischen Entitätsinhalt von den Belegen. Die Gestaltung ist bewusst zurückhaltend: kleine Überschrift, einfache Liste, keine Karten-Optik.

Technische Umsetzung - das Wesentliche

Für die technische Struktur empfiehlt der Standard semantische HTML-Elemente, insbesondere Definitionslisten mit <dl>, <dt>, <dd>. Diese erzeugen eine klare Schlüssel-Wert-Beziehung zwischen Feldnamen wie Entitätstyp, Betreiber oder Prüfdatum und dem jeweiligen Wert. Das erleichtert die maschinelle Extraktion und Interpretation der Inhalte. Als Ausgangspunkt dient das Praxis-Template des Standards, das in zwei Ansichten vorliegt: einmal als redaktionelle Struktur, die zeigt, welche Inhalte auf die Seite gehören, und einmal als technisches Gerüst mit dem konkreten Markup.

Wichtig ist dabei eine Unterscheidung, die V1.6 explizit macht: Der Standard fordert eine Funktion, nicht eine bestimmte Form. Fakten müssen ihren Attributen eindeutig zugeordnet sein. Ob das über eine Definitionsliste, eine kompakte Faktentabelle oder eine beschriftete Profilbox geschieht, ist eine Gestaltungsentscheidung. Die Definitionsliste eignet sich für stabile Kerndaten besonders gut, ist aber nicht vorgeschrieben. Längere Erklärungen gehören ohnehin in normalen Fließtext, zeitliche Entwicklungen in eine Zeitleiste, Vergleiche in eine Tabelle. Alles in ein Faktenraster zu pressen, gilt als typischer Fehler.

Inhaltstragende H2-Überschriften sollten den Entitätsnamen enthalten. Dadurch bleiben einzelne Textabschnitte auch dann eindeutig zuordenbar, wenn sie isoliert extrahiert oder im Retrieval-Kontext ohne vollständigen Seitenrahmen verarbeitet werden. Kleinere H3-Unterüberschriften müssen dagegen nicht mechanisch mit dem vollen Namen überladen werden, die Regel gilt vor allem für die Hauptabschnitte.

Pro Seite wird genau eine Top-Level-Entität definiert, um Mehrdeutigkeit zu vermeiden. Eigenständige Unterentitäten wie einzelne Produkte oder Personen bekommen eine eigene Seite und werden nur verlinkt, nicht nebenbei mitbeschrieben. Empfohlen sind außerdem stabile IDs und Anker für die einzelnen Abschnitte, damit sich einzelne Fakten gezielt referenzieren lassen. Ein sichtbares Prüf- oder Statusdatum gehört ebenfalls dazu. Beim Wording rät der Standard inzwischen zur Zurückhaltung: Formulierungen wie „Zuletzt redaktionell geprüft", „Stand" oder „Aktualisiert am" sind der Angabe „verifiziert" vorzuziehen, damit nicht der Eindruck einer externen Zertifizierung entsteht.

Die im JSON-LD hinterlegten strukturierten Daten müssen die sichtbaren HTML-Fakten exakt spiegeln. Feldbezeichnungen, Werte und Schreibweisen dürfen nicht voneinander abweichen. Abweichungen zwischen HTML und strukturierten Daten gelten als Implementierungsfehler. Das JSON-LD ist ein Spiegel, keine zweite Inhaltsebene: Zusätzliche Marketingaussagen, die für Menschen nirgends sichtbar sind, untergraben die Funktion der Seite.

Entscheidend ist dabei der passende Entitätstyp. Ein generisches WebPage statt Organization, Product, Person, Event oder DefinedTerm gilt als Fehler, ebenso das Vermischen von Organisation und Produkt. Enthält die Seite eine sichtbare FAQ, wird sie als FAQPage gespiegelt, allerdings ausschließlich mit Fragen und Antworten, die auch tatsächlich auf der Seite stehen.

Die Grounding Page muss indexierbar sein und darf kein noindex-Tag enthalten, da sie als zitierfähige Referenzquelle für KI-Systeme fungieren soll. Für Entwicklungsteams enthält der technische Implementierungs-Guide des Standards konkrete Vorgaben zur strukturellen Umsetzung, inklusive Praxis-Template, Fehlerkatalog und einer Checkliste vor Veröffentlichung.

Gestaltung ist kein Nebenschauplatz mehr

Seit V1.6 gehört die gestalterische Einbindung ausdrücklich zum Standard. Eine Grounding Page soll nicht wie ein technisches Fremddokument wirken. Header, Footer, Typografie und Navigation der regulären Website bleiben erhalten, Markenfarben werden sparsam eingesetzt, die Lesebreite großzügig. Die Begründung ist pragmatisch: Vertrauen entsteht auch über Gestaltung. Wirkt die Faktenseite wie ein technischer Anhang, verliert sie an Glaubwürdigkeit. Was der Standard dagegen ablehnt, ist der Dashboard-Look mit überladenen Kartenlandschaften und unnötigen technischen Hinweisen.

Warum Grounding Pages wichtig sind

Grounding Pages lösen drei zentrale Probleme moderner KI-Systeme:

1. Halluzinationen
   Fehlende Fakten werden durch plausible, aber falsche Informationen ersetzt. Präzise, maschinenlesbare Angaben vermindern unsichere Ausgabe-Hypothesen.
2. Entitätsverwechselung:
   Ähnliche Namen, Kategorien, Wettbewerber oder generische Konzepte werden vermischt. Marken landen beim Mutterkonzern, Produkte beim Unternehmen, Personen bei Namensvettern.
3. Nicht-Nennung:
   Die Entität wird in relevanten Antworten gar nicht berücksichtigt, weil die Signale nicht stark, klar oder vertrauenswürdig genug sind.
4. Englisch dominierter Retrieval-Bias
   Viele Modelle führen interne Retrieval-Schritte auf Englisch aus, auch wenn der Prompt es nicht ist. Lokale Marken konkurrieren dadurch unsichtbar mit globalen englischsprachigen Inhalten.

Der Standard ist explizit für RAG-Systeme und Grounding-APIs optimiert, also genau für die Szenarien, in denen Unternehmen heute verlässliche Entitätsdefinitionen brauchen.

Hier seht Ihr ein Beispiel unserer Grounding Pages:

Zu den Grounding Pages

Grounding Page: Was die Daten zeigen

Das Grounding Page Project hat im Juli 2026 erstmals belastbare Zahlen veröffentlicht. Über 28 Tage wurden auf groundingpage.com rund 140 URLs gemessen: 434.777 Google-Impressionen bei 1.678 Klicks, gleichzeitig 40.723 Zugriffe von KI-Crawlern. Auf jeden menschlichen Google-Klick kommen also etwa 24 Bot-Zugriffe, rund 21 davon von ChatGPT-User. 86 Prozent dieser Zugriffe landen auf den Faktenseiten.

Die Klickrate von 0,4 Prozent wäre für eine klassische SEO-Landingpage ein Schwächesignal. Für eine Grounding Page ist sie ein Funktionssignal. Die Seite soll gefunden, abgerufen und als Referenz verwendet werden, nicht Traffic erzeugen.

Dazu kommt ein Vorher-Nachher-Fall aus einem umkämpften Umfeld. Für das Bio- und Wellnessresort Stanglwirt in Tirol gingen Ende Juni 2026 sechzehn Grounding Pages live, je acht auf Deutsch und Englisch (Direkt zu den Groundingpages des Stanglwirts). Gemessen wurde über markenfreie Suchanfragen, also Situationen, in denen Nutzer noch keinen konkreten Anbieter im Kopf haben. Die AI Visibility stieg um 36 Prozent, die Top-3-Sichtbarkeit um 55 Prozent, die Detection Rate um elf Prozentpunkte. Das Projekt selbst ordnet das vorsichtig ein: Ein Kausalitätsbeweis ist es noch nicht, auffällig ist aber, dass der Wendepunkt exakt mit dem Launch zusammenfällt.

Auch die Forschungslage stützt die Architektur. Eine Untersuchung von Volpini und Kollegen aus 2026 hat über 2.400 Auswertungen verschiedener Dokumentformate für RAG-Pipelines verglichen. Das Ergebnis ist für die Praxis entscheidend: JSON-LD allein bringt nur marginale Verbesserungen. Der große Effekt entsteht, wenn Entitätsfakten sichtbar und navigierbar im Seiteninhalt selbst stehen. Microsoft hat im Mai 2026 im Bing-Blog denselben Systemwechsel aus Sicht der Suchinfrastruktur beschrieben: weg vom Ranking von Seiten, hin zu Fakten, die eine Antwort belegen können.

Umsetzung in der Praxis - Schritt für Schritt

1. Entitäten auswählen
   Identifiziert die Marken, Produkte, Personen oder Konzepte, die stabile Definitionsseiten benötigen, zum Beispiel Unternehmensmarke, Produktlinien oder Forschungsprojekte.
2. Inhalte erstellen (faktenbasiert)
   Schreibt einen Lead aus Definition, Einordnung ins Segment und Abgrenzung. Ergänzt strukturierte Kerndaten, ein sichtbares Prüfdatum und Quellen für alles, was sich ändern kann.
3. Technische Struktur anwenden
   Nutzt das Praxis-Template als Basis und implementiert die Seite semantisch mit Definitionslisten, IDs und strukturierten Feldern.
4. Autorität signalisieren
   Verlinkt die Grounding Page zentral, etwa im Footer, im Impressum oder auf About- und Kontakt-Seiten, damit Suchmaschinen und AI-Systeme die Seite als autoritative Quelle erkennen.
5. Verifizierungs-Workflow etablieren
   Legt fest, wer die Seite verantwortet. Der Standard empfiehlt eine redaktionelle Prüfung alle drei bis sechs Monate. Sofort geprüft wird bei Namensänderungen, neuen Produkten, geänderten Preisen, Führungswechseln, neuen Standorten, Fusionen oder eingestellten Angeboten. Das sichtbare Prüfdatum ändert Ihr nur nach einer echten menschlichen Prüfung, dateModified nur bei tatsächlichen Inhaltsänderungen. Ein automatisch hochgezähltes Datum entwertet das Signal.
6. Monitoring und Referenzen
   Erfasst, ob und wie KI-Systeme die Seite als Quelle verwenden. Für eine schnelle Diagnose bietet das Grounding Page Project den kostenlosen Grounding Check, für eine tiefere entitätszentrierte Analyse den Entity Decoder. Für laufendes Sichtbarkeits-Tracking eignen sich Tools wie Brandzaps.
7. Englische Version ergänzen
   Für die wichtigsten Entitäten empfiehlt der Standard neben der Landessprache eine englische Fassung. Grund ist der englisch dominierte Retrieval-Bias: Die deutsche Seite erklärt die Entität im eigenen Markt, die englische macht sie im globalen Modellraum sichtbar. Wichtig sind dabei eine eigene Seite je Sprache, hreflang-Verweise inklusive x-default und eine konsistente Schreibweise des Namens. Zweisprachige Mischformen auf einer Seite destabilisieren die Zuordnung wieder.
8. Umfang realistisch planen
   Als Orientierung nennt der Standard ein bis fünf Seiten für kleinere Organisationen, fünf bis zwanzig für Unternehmen mit mehreren Marken oder Produkten. Die Grenze ist nicht die Anzahl, sondern die Pflegbarkeit. Viele Seiten, die niemand aktuell hält, schaden mehr als wenige gepflegte.

Was man vermeiden sollte

Der Standard definiert klar, was nicht auf eine Grounding Page gehört: Marketing-Claims, subjektive Interpretationen, dynamische oder Live-Daten sowie regulierte Beratung. Grounding Pages sind faktenorientierte Referenzseiten und keine Verkaufs- oder Kampagnenflächen.

Mit Version 1.5 wurde dieser Rahmen präzisiert und in mehreren Punkten verschärft. Neu hinzu kommt eine explizite Aussagenhygiene: Vage Definitionen, werbliche H1-Überschriften statt eines reinen Entitätsnamens sowie unklare oder mehrdeutige Formulierungen gelten nun als strukturelle Fehler. Ebenso darf eine Seite nicht mehrere Hauptentitäten vermischen, da dies die semantische Stabilität schwächt.

Darüber hinaus betont Version 1.5, dass sichtbarer HTML-Inhalt und JSON-LD-Markup exakt übereinstimmen müssen. Abweichungen oder zusätzliche, nicht sichtbare Inhalte in strukturierten Daten sind nicht standardkonform.

Wenn zeitabhängige oder potenziell veränderliche Fakten genannt werden, müssen diese klar datiert und eindeutig formuliert sein. Unpräzise oder nicht aktualisierte Angaben können zu instabilen oder veralteten KI-Antworten führen.

Fazit

Grounding Pages sind die moderne About- oder Identitätsseite für das AI-Zeitalter: präzise, strukturiert und maschinenlesbar. Wer heute stabile Entitätsdefinitionen bereitstellt, gewinnt an AI-Sichtbarkeit, reduziert Halluzinationen und liefert zuverlässigere Ergebnisse in RAG- und Retrieval-Systemen. Der Aufwand ist überschaubar und das Potenzial für zuverlässige KI-Interaktionen groß.

Quellen:

Zur Grounding Page Dokumentation

Häufige Fragen (FAQ)