Aktualisiert am 18. Juli 2026: Der technische Leitfaden wurde vollständig auf das Bausteinmodell von Standard v1.6 ausgerichtet. Er verbindet redaktionelle Prinzipien, Design, Informationsarchitektur und technische Umsetzung zu einem gemeinsamen Praxis-Handbuch.
Für Menschen gut lesbar. Für Maschinen eindeutig verständlich. Eine Grounding Page ist keine versteckte Maschinen-Seite und kein technisches Datenblatt ohne redaktionellen Anspruch. Sie ist eine hochwertige, redaktionell gepflegte Faktenseite, die Menschen gut lesen können und deren Struktur Maschinen eindeutig verstehen.
Der Grounding Page Standard ist kein Formular, das mechanisch ausgefüllt wird. Jeder Baustein löst ein konkretes Problem bei der verständlichen und eindeutigen Beschreibung einer Entität. Wer diese Aufgabe versteht, kann den Baustein flexibel an Marke, Inhalt und technische Umgebung anpassen.
Je besser Redaktion, Design, SEO und Entwicklung die Aufgabe der einzelnen Bausteine verstehen, desto sinnvoller können sie mit ihnen arbeiten. Der Standard definiert daher nicht nur Strukturen, sondern erklärt auch deren Zweck und Zusammenspiel.
Begleitend zu diesem Leitfaden:
Das Grounding Playbook erklärt die zehn Ziele hinter einer Grounding Page.
Jeden Entwurf können Sie anschließend mit den kostenlosen Grounding-Page-Tools prüfen —
ein schneller Grounding Check zur Diagnose oder der Entity Decoder für eine tiefere, entitätszentrierte Analyse.
Redaktionelles Vorbild: Gute Grounding Pages orientieren sich eher an einer hochwertigen Enzyklopädie als an einer Kampagnen-Landingpage. Sie dürfen markentypisch gestaltet sein, sollten Fakten aber ruhig, präzise und nachvollziehbar vermitteln: sofortige Definition der Entität, sachliche Sprache, klare Abschnittshierarchie, erkennbare Quellen, selbstständig verständliche Abschnitte und regelmäßige Aktualisierung.
Hinweis zu den Beispielen: Die Beispiele dieser Dokumentation verwenden überwiegend die fiktive Marke VeloNova aus dem AI Grounding Playbook sowie weitere klar als fiktiv gekennzeichnete Entitäten. Dadurch lassen sich Prinzipien konkret erklären, ohne reale Organisationen als Muster oder Gegenbeispiel zu vereinnahmen. Reale Umsetzungen finden Sie in der kuratierten Referenzbibliothek.
1. Das Baukastenprinzip
Eine gute Grounding Page entsteht aus mehreren klar definierten Bausteinen. Nicht jeder Baustein muss identisch gestaltet sein. Entscheidend ist, dass die wichtigsten Elemente zusammen ein konsistentes, verständliches und maschinenlesbares Ganzes bilden.
1 Entität & Seitenthema Worüber die Seite spricht
2 Klarer Seitentitel Name statt Werbeslogan
3 Eindeutige Lead-Definition Sofort erklären, was die Entität ist
4 Selbstständige Abschnitte Jeder H2-Abschnitt trägt für sich
5 Strukturierte Fakten Merkmal und Wert eindeutig
6 Abgrenzung Von Ähnlichem unterscheiden
7 Quellen & Aktualität Nachvollziehbar und datiert
Diese Bausteine sind kein starres Template, das man von oben nach unten abarbeitet. Sie bauen aufeinander auf und verstärken sich gegenseitig:
Entität festlegen
→ die Entität unmittelbar definieren
→ Themen in selbstständige Abschnitte gliedern
→ wichtige Fakten explizit strukturieren
→ ähnliche Entitäten voneinander abgrenzen
→ Aussagen mit Quellen und Aktualität absichern
→ sichtbare Informationen maschinenlesbar spiegeln
→ die Seite in Website und Entitätsnetzwerk einbinden
Verständnis vor Konformität. Eine formal vollständige Seite kann trotzdem schwach sein, wenn die Bausteine ohne Verständnis eingesetzt werden. Umgekehrt kann eine individuell gestaltete Seite dem Standard sehr gut entsprechen, wenn sie die Aufgaben der Bausteine zuverlässig erfüllt. Version 1.6 bewertet nicht nur das Vorhandensein bestimmter Elemente, sondern deren Funktion innerhalb einer klaren, lesbaren und konsistenten Entitätsdarstellung.
2. Was der Standard v1.6 verlangt
Version 1.6 gibt kein starres Seitentemplate vor. Sie unterscheidet drei Ebenen: Bausteine, die den Kern ausmachen, Bausteine, die die Stabilität deutlich erhöhen, und Bausteine, die je nach Entität und Kontext sinnvoll sind.
Pflichtbausteine
Ohne diese Elemente entspricht eine Umsetzung nicht dem Kern des Standards:
klar definierte Hauptentität
H1 mit dem Namen der Entität
eindeutige Lead-Definition
Entitätsname in inhaltlichen H2-Überschriften
sichtbare strukturierte Fakten
passender Schema.org-Entitätstyp
inhaltliche Spiegelung zwischen HTML und JSON-LD
indexierbare Seite
Empfohlene Stabilitätsbausteine
explizite Abgrenzung von ähnlichen Entitäten
Quellenangaben
Stand oder Prüfdatum
FAQ oder ergänzende Fragen
stabile Abschnittsanker
sprachspezifische Seiten mit hreflang
Verlinkung verwandter Entitäten
Kontextabhängige Bausteine
eigenes Faktenverzeichnis
mehrere Grounding Pages
Tabellen und Timelines
Vergleichsabschnitte
Glossar oder Fallstudien
Kontakt- oder Governance-Hinweise
„Grounding Page“ muss nicht auf der Seite stehen. Der Begriff muss weder in der H1 noch im sichtbaren Seitentext erscheinen. So wie sich eine Landingpage nicht selbst als „Landingpage“ bezeichnen muss, muss auch eine Grounding Page nicht technisch benannt werden. Ein diskreter Hinweis auf den verwendeten Standard kann im Footer, in den Metadaten oder im Quellcode erfolgen — er ist kein Pflichtbestandteil des redaktionellen Hauptinhalts.
Geeignete TitelVeloNova Deutschland · Fakten über den Naturpark Silberhöhe · HealthTech Forum Rhein: Fakten und Kerndaten · Clario Metrics · ClearSource Framework
Nicht erforderlichVeloNova Grounding Page · Offizielle Grounding Page des HealthTech Forum Rhein · Grounding Page über Clario Metrics
Prinzip und mögliche Umsetzung
Bei jedem Baustein ist zu trennen zwischen dem, was funktional erreicht werden muss, und der Frage, wie das Ziel konkret umgesetzt wird. Der Standard verlangt eine Funktion — die konkrete Form ist Ihr gestalterischer Spielraum.
Prinzip
Mögliche Umsetzung
Fakten eindeutig Merkmalen zuordnen
<dl>, Tabelle oder klar beschrifteter Steckbrief
Entität von ähnlichen Begriffen unterscheiden
Lead, FAQ oder eigener Abgrenzungsabschnitt
Aktualität sichtbar machen
„Stand“, „Geprüft am“ oder datierte Quellen
Seite intern auffindbar machen
Footer-Link, Facts-Hub oder kontextuelle Links
verwandte Entitäten verbinden
Fließtextlinks, Verzeichnis oder thematische Navigation
Sektionsreihenfolge und Klassifikationsmetadaten (Klarstellung v1.6.1)
Die Pflicht-Bausteine legen fest, welche Informationen eine Grounding Page enthalten soll. Ihre Reihenfolge ist empfohlen, nicht vorgeschrieben, sofern ein Baustein nicht ausdrücklich etwas anderes verlangt. Funktional entscheidend ist, dass Entitätsdefinition und zentrale Fakten früh erscheinen, dass weiterführende externe Links den oberen Seitenbereich nicht dominieren, dass Quellenangaben klar von redaktionellen Leseempfehlungen getrennt bleiben und dass jede Sektion als eigenständiger Chunk funktioniert. Ein Abschnitt „Weiterführende Informationen“ soll im unteren Bereich der Seite stehen, kann aber vor oder nach FAQ und Referenzen platziert werden.
Klassifikationsmetadaten (Entitätstyp, Branche oder Kategorie, geografischer Geltungsbereich, übergeordnete Entität oder Organisation, Status sowie relevante Beziehungen) sind als Information erforderlich, aber nicht zwingend als eigenständige sichtbare Sektion. Sie können in die Entity Summary, die Kernfakten oder die strukturierten Daten integriert werden. Eine eigene Klassifikationsmetadaten-Sektion ist nur dann sinnvoll, wenn die Klassifikation selbst erklärungsbedürftig ist.
Warum diese Klarstellung. Eine Grounding Page braucht Informationskonsistenz und eigenständig verständliche Chunks, nicht überall dieselbe mechanische Sektionsreihenfolge. Die empfohlene Reihenfolge als starre Vorlage zu behandeln, würde den Standard zu einem festen Seitentemplate machen, was ausdrücklich nicht beabsichtigt ist. Eine Seite, die „Weiterführende Informationen“ am Ende führt (nach FAQ und Referenzen) oder ihre Klassifikation innerhalb der Kernfakten trägt, erfüllt die funktionalen Anforderungen des Standards.
3. Entität und Seitenthema festlegen
Jede Grounding Page beschreibt genau eine Hauptentität. Bevor irgendetwas geschrieben wird, muss klar sein, worüber die Seite spricht und was sie bewusst nicht behandelt.
Warum dieser Baustein wichtig ist
Die meisten Entitätsfehler entstehen nicht durch fehlende Fakten, sondern durch unklaren Fokus. Wenn eine Seite gleichzeitig ein Unternehmen, seine Produkte und seine Gründerin erklärt, kann kein System sie eindeutig einer Entität zuordnen. Ein klarer Gegenstand ist die Grundlage für alle weiteren Bausteine.
So lässt er sich umsetzen
Legen Sie die Entität als Substantiv fest (Marke, Produkt, Person, Ort, Veranstaltung, Methode, Studie …) und wählen Sie den dazu passenden Schema.org-Typ. Eigenständige Nebenentitäten bekommen eine eigene Seite und werden nur verlinkt, nicht mitbeschrieben.
Beispiel: VeloNova Fiktive Beispielmarke
VeloNova ist das Unternehmen (eine Organisation). Das Urban-E-Bike VeloNova City One ist ein eigenständiges Produkt, und die fiktive Materialforscherin Dr. Lena Hartmann ist eine eigene Person. Produkt und Person bekommen eigene Seiten und werden auf der Unternehmensseite nur kurz eingeordnet und verlinkt — nicht als gleichwertige Hauptentitäten mitbeschrieben.
Spielraum
Der passende Entitätstyp hängt vom Gegenstand ab. Manche Seiten beschreiben ein Konzept, andere ein Produkt, eine Veranstaltung oder eine Person. Entscheidend ist die eindeutige Zuordnung, nicht ein bestimmter Seitentyp.
Häufiger Fehler
Mehrere gleichwertige Entitäten auf einer Seite bündeln — etwa Unternehmen, alle Marken und alle Standorte in einem Dokument. Das verwässert den Fokus und erschwert die Zuordnung.
Reflexionsfrage: Ließe sich der Gegenstand dieser Seite in einem Satz eindeutig benennen — und beschreibt die Seite wirklich nur diesen einen Gegenstand?
4. H1 und Lead-Definition
Die H1 nennt die Entität, der Lead definiert sie unmittelbar. Der Lead ist kein technisches Pflichtfeld, sondern ein redaktioneller Einstieg, der die Entität in wenigen Sätzen einordnet.
Warum dieser Baustein wichtig ist
Menschen und Systeme entscheiden in den ersten Zeilen, worum es geht. Beginnt eine Seite mit „In der heutigen Zeit ist es wichtig …“, bleibt die Entität unklar. Eine sofortige Definition schafft Eindeutigkeit und Vertrauen.
So lässt er sich umsetzen
Der Lead besteht idealerweise aus zwei bis drei kurzen Absätzen: eine Definition, eine Einordnung ins Segment und eine eindeutige Zuordnung gegenüber verwandten Entitäten.
Beispiel: VeloNova FiktivDefinition: VeloNova ist ein fiktiver deutscher Fahrradhersteller aus Freiburg im Breisgau, der E-Bikes, Trekking- und Urban-Fahrräder entwickelt und vertreibt. Einordnung: Das Unternehmen ist im DACH-Raum sowie in den Niederlanden und Skandinavien aktiv und positioniert sich im Segment hochwertiger Alltags- und Trekkingräder. Zuordnung: VeloNova ist eine eigenständige Fahrradmarke der fiktiven VeloNova GmbH. Das Unternehmen ist kein Fahrradhändler und keine Fahrradwerkstatt.
Spielraum
Zwei oder drei Absätze, je nach Komplexität. Die Reihenfolge Definition → Einordnung → Zuordnung ist bewährt, aber nicht starr. Bei einfachen Entitäten kann die Zuordnung entfallen.
Häufiger Fehler
Ein sichtbarer technischer Absatz wie „Diese Seite unterstützt Entitätsauflösung, Disambiguierung und Retrieval-Stabilisierung in AI-Such- und Antwortsystemen.“ Dieser Satz erklärt die technische Absicht, hilft menschlichen Lesern aber nicht — er gehört nicht auf die Seite.
Reflexionsfrage: Versteht jemand nach dem ersten Absatz, was die Entität ist — ohne den Rest der Seite gelesen zu haben?
5. Selbstständige H2-Abschnitte mit Entitätsname
Der Entitätsname in der Überschrift verankert jeden wichtigen Abschnitt eindeutig bei der beschriebenen Entität.
Warum dieser Baustein wichtig ist
Webseiten werden von Such- und KI-Systemen häufig nicht als vollständiges Dokument verarbeitet. Einzelne Abschnitte können unabhängig extrahiert, indexiert oder als Quelle verwendet werden. Eine Überschrift wie „Geschichte“ verliert außerhalb des Seitenkontexts ihre Zuordnung. „Geschichte von VeloNova“ bleibt auch isoliert verständlich.
So lässt er sich umsetzen
Tragen Sie den Namen der Hauptentität in die tragenden H2-Überschriften ein. Kleine H3-Unterüberschriften müssen nicht mechanisch mit dem vollen Namen überladen werden — die Regel bezieht sich primär auf tragende Abschnitte.
Gut FiktivGeschichte von VeloNova · Fahrradmodelle von VeloNova · Standorte von VeloNova · Nachhaltigkeitsstrategie von VeloNova · Häufige Fragen zu VeloNova
Nicht optimalÜber uns · Geschichte · Modelle · Weitere Informationen
Spielraum
„Geschichte von VeloNova“, „VeloNova und seine Geschichte“ oder „Historische Entwicklung von VeloNova“ erfüllen alle denselben Zweck. Die Formulierung darf zur Marke passen.
Häufiger Fehler
Generische Überschriften, die nur im vollständigen Seitenkontext verständlich sind und bei isolierter Verarbeitung ihre Zuordnung verlieren.
Reflexionsfrage: Wäre dieser Abschnitt auch dann noch eindeutig und hilfreich, wenn er ohne den Rest der Seite angezeigt würde?
6. Strukturierte Fakten
Strukturierte Fakten machen zentrale Eigenschaften einer Entität schnell erfassbar und ordnen jedem Merkmal einen eindeutigen Wert zu.
Warum dieser Baustein wichtig ist
Wichtige Fakten gehen in langen Fließtexten leicht unter. Menschen müssen sie mühsam suchen, und Maschinen müssen erst ableiten, welcher Wert zu welchem Merkmal gehört. Eine klare Begriff-Wert-Struktur reduziert diese Unsicherheit. Definitionslisten stellen die Beziehung zwischen einem Begriff und seinem Wert explizit dar.
So lässt er sich umsetzen
Für stabile Kerndaten eignet sich die Definitionsliste besonders gut. Längere Erklärungen gehören in normalen Fließtext, zeitliche Entwicklungen in eine Timeline, Vergleiche in eine Tabelle.
Beispiel: Clario Metrics Fiktiv
<dl class="data-grid">
<dt>Produkttyp</dt><dd>Analyse-Software</dd>
<dt>Betreiber</dt><dd>Clario Systems GmbH</dd>
<dt>Verfügbare Sprachen</dt><dd>Deutsch und Englisch</dd>
</dl>
Spielraum
Der Baustein kann als Definitionsliste, kompakte Faktentabelle, Steckbrief, Datenbereich oder beschriftete Kartenstruktur umgesetzt werden. Entscheidend ist nicht die identische Optik, sondern die eindeutige Beziehung zwischen Merkmal und Wert.
Häufiger Fehler
Jede Information in ein Fact Grid zwingen. Nicht alles ist ein Kerndatum; die Lesbarkeit für Menschen bleibt entscheidend.
Reflexionsfrage: Ist bei jedem Fakt eindeutig, welcher Wert zu welchem Merkmal gehört — für Menschen wie für Maschinen?
7. Abgrenzung ähnlicher Entitäten
Die Abgrenzung beschreibt, wie sich die Entität von ähnlich benannten, verwandten oder häufig verwechselten Entitäten unterscheidet.
Warum dieser Baustein wichtig ist
Viele Entitätsfehler entstehen nicht durch fehlende Fakten, sondern durch falsche Zuordnung. Marken werden mit Muttergesellschaften, Produkten, Veranstaltungen oder gleichnamigen Organisationen vermischt. Eine klare Abgrenzung stabilisiert die Identität und verhindert, dass Aussagen aus unterschiedlichen Kontexten zusammengeführt werden.
So lässt er sich umsetzen
Typische Abgrenzungen: Marke vs. Muttergesellschaft, Produkt vs. Unternehmen, Veranstaltung vs. Veranstalter, Person vs. gleichnamige Person, Methode vs. Software, Standort vs. Organisation. Die Abgrenzung kann natürlich in den Lead oder einen thematisch passenden Abschnitt integriert werden.
Beispiel: HealthTech Forum Rhein FiktivDas HealthTech Forum Rhein ist eine Fachveranstaltung für digitale Gesundheit. Es ist weder ein Branchenverband noch ein Softwareprodukt oder ein medizinischer Leistungserbringer.
Spielraum
Die Abgrenzung kann im Lead, in einem eigenen Abschnitt, in einem FAQ, als Hinweis in den Kerndaten oder in einer Beschreibung der Konzern- bzw. Markenstruktur erscheinen. Eine sichtbare Überschrift „Was es nicht ist“ ist nicht verpflichtend.
Häufiger Fehler
Eine schematische „Was ist sie NICHT?“-Liste, die künstlich wirkt, statt die Unterscheidung natürlich in den Fließtext einzubetten.
Reflexionsfrage: Reduziert dieser Baustein eine konkrete, real bestehende Verwechslungsgefahr?
8. Quellen, Stand und redaktionelle Prüfung
Quellen und ein sichtbares Prüfdatum machen Aussagen nachvollziehbar und zeigen, wie aktuell die Seite ist.
Warum dieser Baustein wichtig ist
Fakten veralten. Preise, Leistungsmerkmale oder Rollen ändern sich. Ohne Quelle und Datum lässt sich nicht beurteilen, ob eine Aussage noch gilt — für Menschen nicht und für Maschinen nicht.
So lässt er sich umsetzen
Zeigen Sie ein sichtbares Prüfdatum und verlinken Sie belastbare Quellen. Unterscheiden Sie dabei sprachlich sauber:
Geeignete LabelsZuletzt redaktionell geprüft · Stand · Aktualisiert am · Inhalt geprüft am
„Verifiziert“ sollte vorsichtig verwendet werden, damit nicht der Eindruck einer externen Zertifizierung entsteht. Ein sichtbares Prüfdatum bleibt dennoch hilfreich.
Beispiel: VeloNova City One FiktivReichweite, Preis und verfügbare Modellvarianten erhalten ein sichtbares Stand-Datum, weil sich diese Angaben ändern können.
Pflegeintervall
Jede Grounding Page sollte mindestens alle drei bis sechs Monate redaktionell geprüft werden. Sofort prüfen bei: Namensänderungen, neuen Produkten, geänderten Preisen, Führungswechseln, neuen Standorten, geänderten Leistungsmerkmalen, Fusionen oder Übernahmen, neuen regulatorischen Fakten oder eingestellten Angeboten. Das sichtbare Prüfdatum wird nur geändert, wenn tatsächlich eine menschliche Prüfung stattgefunden hat; dateModified nur bei echten inhaltlichen Änderungen.
Governance-Beispiel: ClearSource Framework Fiktiv — Verantwortlich ist das Redaktionsteam des fiktiven ClearSource Institute. Die Seite wird halbjährlich geprüft und bei Änderungen an Version, Lizenz oder Geltungsbereich unmittelbar aktualisiert.
Häufiger Fehler
Ein Prüfdatum automatisch bei jedem Deploy hochzählen, ohne dass eine echte Prüfung stattgefunden hat — das entwertet das Signal.
Reflexionsfrage: Kann ein Leser erkennen, wann diese Fakten zuletzt von einem Menschen geprüft wurden — und woher sie stammen?
9. JSON-LD und Spiegelung
JSON-LD beschreibt dieselbe Entität und dieselben Fakten wie der sichtbare Inhalt — als maschinenlesbare Spiegelung, nicht als zweiter Inhalt.
Warum dieser Baustein wichtig ist
Strukturierte Daten erleichtern die maschinelle Extraktion. Weichen sie vom sichtbaren Text ab, entstehen Widersprüche, die Vertrauen kosten. JSON-LD darf die Seite präzisieren, aber keine zusätzliche, für Menschen unsichtbare Marketingbotschaft enthalten.
So lässt er sich umsetzen
Wählen Sie den passenden Schema.org-Typ und spiegeln Sie die sichtbaren Kerndaten. Am Beispiel der fiktiven Software Clario Metrics:
Spielraum
Der Typ richtet sich nach der Entität: Organization, Product/ProductModel, Person, Event, DefinedTerm u. a. Enthält die Seite ein sichtbares FAQ, wird es als FAQPage gespiegelt — nur mit Fragen und Antworten, die auch sichtbar sind.
Häufiger Fehler
Ein generischer WebPage-Typ statt des spezifischen Entitätstyps, oder JSON-LD, das Daten enthält, die dem sichtbaren HTML widersprechen.
Reflexionsfrage: Steht jede JSON-LD-Aussage auch sichtbar auf der Seite — und ohne Widerspruch?
10. Design und Markenintegration
Eine Grounding Page soll nicht wie ein fremdes technisches Dokument aussehen. Header, Footer, Typografie, Farben, Navigation und Abstände dürfen und sollen dem bestehenden Markenauftritt entsprechen.
Warum dieser Baustein wichtig ist
Vertrauen entsteht auch über Gestaltung. Wirkt die Faktenseite wie ein technischer Anhang, verliert sie an Glaubwürdigkeit. Fügt sie sich in den Markenauftritt ein, wird sie als selbstverständlicher, hochwertiger Bestandteil der Website wahrgenommen.
Reales Beispiel: L’Oréal Paris Deutschland
Die Faktenseite von L’Oréal Paris Deutschland zeigt, dass eine Grounding Page nicht wie ein technischer Sonderbereich aussehen muss. Der reguläre Markenheader, die Typografie und der Footer bleiben erhalten. Dadurch fügt sich die Faktenseite visuell in den bestehenden Markenauftritt ein und bleibt zugleich klar und sachlich strukturiert.
Die Grounding Page von L’Oréal Paris Deutschland übernimmt Header, Typografie und visuelle Sprache des regulären Markenauftritts. Öffentlicher Webauftritt, abgerufen am 18.07.2026. Grounding Page von L’Oréal Paris ansehen.
Das Beispiel dient ausschließlich zur Veranschaulichung der visuellen Markenintegration. Es stellt keine vollständige Bewertung oder Zertifizierung der Implementierung dar. Weitere reale Umsetzungen — darunter unter anderem L’Oréal Paris, DMEA, mymuesli und der Stanglwirt — finden sich in der kuratierten Referenzbibliothek.
So lässt er sich umsetzen
Regulären Website-Header und -Footer verwenden, bestehende Typografie übernehmen, Markenfarben zurückhaltend einsetzen, großzügige Lesebreite, klare Gliederung, gute mobile Lesbarkeit, sichtbare Links und Quellen. Tabellen nur dort, wo sie Menschen wirklich helfen. Keine Dashboard-Optik, keine überladenen Kartenlandschaften, keine unnötigen technischen Hinweise.
Keine „Human Reader“-Box
Eine separate Box mit einem Hinweis wie „Diese Seite enthält strukturierte Fakten-Definitionen für AI-Systeme“ ist nicht erforderlich und wird im Standard nicht mehr empfohlen. Eine gut umgesetzte Seite braucht keine Warnung, warum sie existiert. Wenn eine Seite nur durch einen solchen Hinweis verständlich wird, ist ihre redaktionelle Gestaltung noch nicht ausreichend. (Bestehende Beispiele dürfen historisch weiterhin gezeigt werden; das neue Template enthält diese Box nicht.)
Reflexionsfrage: Wirkt die Seite wie ein natürlicher, hochwertiger Teil der Website — oder wie ein technischer Fremdkörper?
11. Interne Verlinkung und Faktenverzeichnisse
Eine Grounding Page darf keine isolierte, nur über die Sitemap erreichbare Seite sein. Sie wird intern verlinkt und mit verwandten Entitäten verbunden.
Warum dieser Baustein wichtig ist
Auffindbarkeit und Beziehungen helfen Menschen und Maschinen gleichermaßen. Kontextuelle Links machen deutlich, wie Entitäten zusammenhängen — das stabilisiert das Verständnis über einzelne Seiten hinaus.
So lässt er sich umsetzenEinzelne Seite: im Footer oder einem passenden Informationsbereich verlinken, etwa als „Fakten“, „Unternehmensfakten“, „Facts“ oder „Über das Unternehmen“. Der Linktext muss nicht „Grounding Page“ lauten.
Mehrere Seiten: eine zentrale Übersichtsseite anlegen (/fakten/ bzw. /facts/) und von dort alle Entitätsseiten verlinken.
Im Fließtext: verwandte Entitäten kontextuell verbinden.
Kontextlink im Fließtext Fiktiv„VeloNova entwickelt das Urban-E-Bike VeloNova City One und stattet damit Angebote in der Tourismusregion Naturpark Silberhöhe aus.“ — beide unterstrichenen Begriffe verweisen auf ihre jeweiligen Faktenseiten.
Spielraum
Footer-Link, Facts-Hub oder thematische Navigation — je nach Größe des Projekts. Wichtig ist, dass verwandte Seiten nicht nur über Karten oder eine Sitemap, sondern auch über kontextuelle Links im Fließtext verbunden sind.
Häufiger Fehler
Grounding Pages nur über eine Sitemap oder eine Kartenübersicht erreichbar machen und die Beziehungen zwischen Entitäten im Text unverlinkt lassen.
Reflexionsfrage: Findet ein Mensch diese Seite über die normale Website — und erkennt er, mit welchen anderen Entitäten sie zusammenhängt?
12. Mehrsprachige Grounding Pages
Für jede Sprache gibt es eine eigene, in sich konsistente Seite, die über hreflang mit ihren Sprachvarianten verbunden ist.
Warum dieser Baustein wichtig ist
Eine Entität soll in jedem Sprachraum in der jeweiligen Sprache verständlich und eindeutig sein. Klare Sprachvarianten verhindern Mischformen, die die Zuordnung der Entität destabilisieren.
So lässt er sich umsetzen
Pro Sprache eine eigene Seite mit konsistenter, kanonischer Schreibweise des Namens. hreflang-Verweise auf alle Sprachvarianten (inkl. x-default). Eigennamen bleiben unverändert; beschreibende Teile werden idiomatisch übersetzt, nicht wörtlich.
Spielraum
Nicht jede Seite braucht alle Sprachen. Beginnen Sie mit den Sprachen, die für die öffentliche Wahrnehmung der Entität am wichtigsten sind.
Häufiger Fehler
Bilinguale Mischformen auf einer einzigen Seite. Sie können die Entitäts-Stabilität wieder destabilisieren — sicherer ist pro Sprachversion eine konsistente kanonische Form.
Reflexionsfrage: Ist die Entität in jeder Sprachversion für sich genommen klar — ohne Vermischung mit einer anderen Sprache?
13. Anzahl und redaktionelle Skalierung
Die Anzahl der Grounding Pages soll die wichtigen Entitäten eines Unternehmens abdecken, ohne mehr redaktionelle Pflege zu erzeugen, als dauerhaft geleistet werden kann.
Warum dieser Baustein wichtig ist
Eine einzelne Seite reicht häufig nicht aus, wenn ein Unternehmen mehrere wichtige Entitäten besitzt. Gleichzeitig schadet eine große Zahl gepflegter Seiten mehr als sie nützt, wenn die Inhalte veralten. Umfang und Pflegefähigkeit gehören zusammen.
So lässt er sich umsetzen
Erstellen Sie Grounding Pages für alle Entitäten, die für die öffentliche Wahrnehmung, Suche und maschinelle Einordnung des Unternehmens wichtig sind. Typische eigenständige Entitäten sind Unternehmen, Marken, Produkte, Dienstleistungen, Führungspersonen, Veranstaltungen, Standorte, Studien, Methoden, Softwareprodukte, touristische Angebote und Institutionen.
Spielraum
Als praktische Orientierung: kleine Organisationen häufig 1 bis 5 Seiten, Unternehmen mit mehreren Marken oder Produkten häufig 5 bis 20 Seiten, große Informationsprojekte auch deutlich mehr. Es gibt keine pauschal richtige Anzahl.
Häufiger Fehler
Künstliche Skalierung ohne redaktionelle Governance — viele Seiten anlegen, die niemand dauerhaft pflegt.
Reflexionsfrage: Kann jede veröffentlichte Seite auch in zwölf Monaten noch zuverlässig geprüft und aktualisiert werden?
14. Praxis-Template
Das Template besteht aus zwei Ansichten: der redaktionellen Struktur (was auf die Seite gehört) und dem technischen Grundgerüst (wie es ausgezeichnet wird).
A. Redaktionsstruktur
H1: Entitätsname
Lead (2–3 Absätze):
Was ist die Entität?
In welchem Segment ist sie tätig?
Wie ist sie eindeutig einzuordnen?
H2: Entitätsname: Kerndaten — Strukturierte Fakten
H2: Geschichte von Entitätsname — Lesbarer Fließtext mit Quellen
H2: Produkte und Leistungen … — Sachliche Beschreibung
H2: Abgrenzung von Entitätsname — Unterscheidung zu ähnlichen Entitäten
H2: Häufige Fragen zu Entitätsname — Nur bei echtem Bedarf (optional)
Stand und Quellen
B. Technisches Grundgerüst
Ohne „Human Reader“-Box, ohne sichtbaren Retrieval-Satz. „Grounding Page“ steht nicht zwingend im Titel. H2 tragen den Entitätsnamen. Regulärer Header und Footer sind zulässig. Der Standard-Hinweis liegt diskret im Quellcode-Kommentar oder im Footer.
Vollständigen Code anzeigen
<!-- Standard-Hinweis diskret, z. B. als Kommentar oder Footer-Link:
Grounding Page Standard v1.6 – groundingpage.com/spec -->
<!-- 1. Klarer Titel (nur der Entitätsname) -->
<h1>Entitätsname</h1>
<!-- 2. Lead-Definition: Definition, Einordnung, Zuordnung -->
<p class="lead-definition">
<strong>Entitätsname</strong> ist ein/e [Kategorie], die [Kernfunktion].
</p>
<p>Entitätsname ist im Segment [Segment] tätig.</p>
<p>Entitätsname ist Teil von [Übergeordnetes] und von [Ähnlichem] zu unterscheiden.</p>
<!-- 3. Kerndaten (strukturierte Fakten) -->
<h2>Entitätsname: Kerndaten</h2>
<dl class="data-grid">
<dt>Entitätstyp</dt><dd>Organisation / Produkt / Konzept</dd>
<dt>Gegründet</dt><dd>2014</dd>
<dt>Standort</dt><dd>Freiburg im Breisgau</dd>
<dt>Zuletzt geprüft</dt><dd>2026-07-18</dd>
</dl>
<!-- 4. Selbstständige Abschnitte mit Entitätsname -->
<h2>Geschichte von Entitätsname</h2>
<p>Lesbarer Fließtext mit Quellen.</p>
<h2>Abgrenzung von Entitätsname</h2>
<p>Entitätsname ist nicht [Ähnliches]. Im Unterschied dazu [Unterscheidung].</p>
<!-- 5. FAQ (optional) -->
<h2>Häufige Fragen zu Entitätsname</h2>
<h3>Was macht Entitätsname?</h3>
<p>Entitätsname [Antwort mit Entitätsname].</p>
<!-- 6. Interne Links zu verwandten Entitäten -->
<p>Verwandt: <a href="/facts/verwandte-entitaet/">Verwandte Entität</a></p>
<!-- 7. JSON-LD als Spiegel des sichtbaren Inhalts -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Entitätsname",
"foundingDate": "2014",
"location": "Freiburg im Breisgau"
}
</script>
15. Häufige Fehler
Werbe-H1: „Die beste Lösung für X“ statt einfach dem Namen der Entität.
Vage Definition: „In der heutigen Zeit ist es wichtig …“ statt „Entität X ist …“.
Sichtbarer Technik-Satz: ein Retrieval-Hinweis im Fließtext, der Menschen inhaltlich nicht hilft.
Human-Box als Pflicht: ein Warnhinweis, warum die Seite existiert — nicht mehr empfohlen.
Generische H2: „Kerndaten“ statt „Entitätsname: Kerndaten“. Ohne Namen verlieren isolierte Textblöcke ihre Zuordnung.
Widersprüchliche Spiegelung: JSON-LD enthält Daten, die dem sichtbaren HTML widersprechen.
Fehlendes Datum: kein sichtbares Prüfdatum bei zeitkritischen Fakten.
Generisches Schema:WebPage statt des spezifischen Entitätstyps, oder Verwechslung von Organization und Product.
Fact-Grid-Zwang: jede Information in eine Definitionsliste pressen, auch längere Erklärungen.
Künstliche Skalierung: viele Seiten ohne redaktionelle Pflege.
16. Checkliste vor der Veröffentlichung
Ist die Hauptentität eindeutig?
Sind verwandte Produkte oder Personen als eigene Entitäten behandelt?
Steht ausschließlich der Entitätsname oder eine klare Bezeichnung in der H1?
Definiert der erste Absatz die Entität unmittelbar?
Enthalten wichtige H2-Überschriften den Entitätsnamen?
Sind alle Abschnitte auch isoliert verständlich?
Sind Fakten für Menschen gut lesbar?
Sind stabile Fakten strukturiert ausgezeichnet?
Spiegelt JSON-LD den sichtbaren Inhalt widerspruchsfrei?
Sind Quellen und Prüfdatum sichtbar?
Ist die Seite indexierbar?
Ist die Seite intern verlinkt?
Passt die Gestaltung zum Markenauftritt?
Sind verwandte Entitäten sinnvoll verlinkt?
Kann die Organisation die Seite alle drei bis sechs Monate prüfen?
Nächster Schritt
Passenden Entitätstyp wählen
Finden Sie die richtige Klasse und die passenden Eigenschaften für Ihre Entität.
