Grounding Page: Aufbau, Beispiel und Anleitung

Was ist eine Grounding Page und welches Problem löst sie?

Die Grounding Page ist eine Faktenseite, die erfundenen Angaben über eine Entität in KI-Antworten entgegenwirkt. Sprachmodelle rekonstruieren Fakten nämlich aus Wahrscheinlichkeiten und füllen Lücken mit plausibel klingenden Angaben. Genau dagegen richtet sich die Grounding Page, eine öffentliche HTML-Seite unter eigener URL, die eine einzige Entität in neutraler Sprache beschreibt, ähnlich einem Enzyklopädie-Eintrag. Auf ihr stehen Name, Rechtsform, Sitz, Gründungsjahr, Leistungen und verantwortliche Personen, jeder Satz trägt einen Fakt, Adjektive und Werbesprache fehlen.

Der Begriff „Grounding” stammt aus der KI-Forschung und bezeichnet das Zurückführen einer Antwort auf eine überprüfbare Quelle. Bei der Suchmaschinenoptimierung geht es um Dokumente und Suchbegriffe, bei der Faktenseite um eine Entität und deren stabile, korrekte Nennung. Beides ergänzt sich, weil KI-Systeme ihre Quellen überwiegend aus den organischen Suchergebnissen beziehen.

Grounding in Sprachmodellen: Wie RAG und Google-Suche als Faktenanker arbeiten

Retrieval-Augmented Generation, kurz RAG, beschreibt den Ablauf, mit dem KI-Systeme ihr internes Wissen um externe Dokumente ergänzen. Zuerst analysiert das System die Frage, dann sucht ein Retrieval-Schritt passende Seiten, anschließend erhält das Sprachmodell diese Treffer als Kontext und formuliert daraus die Antwort. Reicht das Modellwissen nicht aus, etwa bei Preisen, Ansprechpartnern oder jungen Unternehmen, greift dieser Umweg über das Web fast immer.

Google nennt dieselbe Technik in der Gemini-Dokumentation „Grounding with Google Search”, und die AI Overview arbeitet nach demselben Prinzip mit Quellen aus dem Suchindex. Beim Google AI Mode zerlegt das System eine Frage sogar in mehrere Teilsuchen, bevor es antwortet. Perplexity und ChatGPT verfahren vergleichbar, nur mit anderen Indizes. Damit wird die eigene Website zum Beleg, den ein System zitieren kann oder übergeht.

Die vier Risiken ohne klare Entitätsdefinition

Fehlt eine eindeutige Referenz, treten laut dem Grounding Page Project vier Muster auf. Am bekanntesten ist die Halluzination, bei der ein System ein Gründungsjahr oder einen Geschäftsführer erfindet, weil nirgends eine belastbare Angabe steht. Daneben steht die Entitätsverwechslung, die eine Marke mit der Muttergesellschaft, ein Produkt mit dem Hersteller oder ein Unternehmen mit einem Namensvetter vermischt. Drittens bleibt eine Entität in Antworten ganz unerwähnt, wenn ihre Signale zu schwach oder widersprüchlich sind. Das vierte Muster trifft deutsche Unternehmen besonders: Viele Modelle führen interne Suchschritte auch bei deutschen Fragen auf Englisch aus und bevorzugen dabei englischsprachige Quellen.

Gegen alle vier hilft dieselbe Maßnahme: Sie bündeln Definition, Abgrenzung und Kernfakten auf einer Seite und legen eine englische Fassung unter eigener URL an. Generative Engine Optimization fasst Arbeit dieser Art unter einem Begriff zusammen, im deutschsprachigen Raum ist auch KI SEO gebräuchlich. Welche der vier Muster bei einer Marke auftreten, klärt eine GEO Agentur vor dem Bau einer Seite anhand von Testfragen an die gängigen Systeme.

Wie grenzt sich die Grounding Page von Über-uns, llms.txt und Schema-Markup ab?

Anders als Über-uns-Seite, llms.txt und Schema-Markup definiert die Grounding Page eine Entität sichtbar für Menschen und KI-Systeme zugleich. Im Impressum steht die rechtliche Identität, die Über-uns-Seite baut Vertrauen bei Menschen auf, das Schema-Markup liefert Maschinen isolierte Datenfelder. Die Faktenseite füllt die Lücke dazwischen, indem sie die semantische Identität in lesbarer Prosa festhält und zugleich maschinell auswertbar bleibt. Verwechslungen entstehen vor allem mit der Über-uns-Seite und mit der llms.txt, weil beide auf den ersten Blick dasselbe zu leisten scheinen. In der Website Struktur steht die Faktenseite deshalb neben diesen Formaten, nicht anstelle davon. Pflegt ein Unternehmen mehrere dieser Formate parallel, muss es vor allem auf identische Angaben achten, weil widersprüchliche Werte für ein System schwerer wiegen als eine fehlende Seite.

Format	Zweck	Adressat	Sichtbar im Web	Pflegeaufwand
Grounding Page	Entität definieren, abgrenzen und belegen	Menschen und KI-Systeme	Ja, indexierbare HTML-Seite	Prüfung alle drei bis sechs Monate
Über-uns-Seite	Vertrauen, Werte, Positionierung	Menschen	Ja	Bei Marketingänderungen
Impressum	Rechtliche Identität nach Gesetz	Menschen, Behörden	Ja	Bei Änderung der Pflichtangaben
llms.txt	Inhaltsverzeichnis für Sprachmodelle	Crawler	Nur als Textdatei	Bei neuen Kernseiten
Schema.org-Markup	Datenfelder im Quellcode	Suchmaschinen, KI-Systeme	Nein, nur im Code	Mit jeder Seitenänderung
Wikidata, Knowledge Panel	Externer Eintrag im Wissensgraph	Suchmaschinen	Ja, auf Fremdplattform	Abhängig von Dritten

01

Schema.org gibt die Struktur, die Seite liefert den Inhalt

Strukturierte Daten nach Schema.org beschreiben eine Organisation, ein Produkt oder eine Person in festen Feldern wie Name, Gründungsdatum oder Adresse. Für isolierte Fakten ist das ideal, für Beziehungen, Geschichte und Abgrenzung fehlt der Platz, weil Felder keine Zusammenhänge ausdrücken. Im Feld foundingDate steht, dass eine GmbH 2014 gegründet wurde, aber nicht, dass sie aus einer Fusion zweier Vorgänger entstand und heute nur eine der beiden Marken führt.

Diesen Kontext liefert der sichtbare Text der Faktenseite, während das Markup dieselben Kerndaten in Maschinenform spiegelt. Auf Forschung, nach der sichtbarer Entitätstext in RAG-Pipelines genauer verarbeitet wird als Markup allein, verweist das Projekt selbst, ohne sie als Beleg für Faktenseiten zu werten. Beide Schichten gehören deshalb zusammen, das Markup als Skelett mit den nackten Werten und der Text als Fleisch mit Zusammenhang, Begründung und Quellen. Fehlt das Skelett, muss ein System Werte aus Prosa raten, fehlt der Text, kennt es die Werte ohne Zusammenhang.

02

Warum eine Über-uns-Seite selten als Faktenquelle taugt

Über-uns-Seiten erzählen eine Geschichte, transportieren Werte und sprechen in der Wir-Form. Für Menschen funktioniert das, für ein System bleibt offen, was das Unternehmen genau ist, welche Rolle es hat und wie es zu anderen Akteuren steht. Der Standard empfiehlt deshalb die dritte Person, einen Fakt pro Satz und den Verzicht auf Adjektive, alles Merkmale, die eine Marketingseite mit Absicht vermeidet. Vereint eine Seite beide Ziele, erreicht sie nach Erfahrung des Grounding Page Project häufig keines davon.

Vergleichbar ist das mit einem Presse-Kit, das neben der Produkt-Landingpage existiert und anderen Regeln folgt. Landingpage SEO optimiert auf Handlung, Emotion und Konversion, eine Faktenseite auf Referenzfähigkeit. Auch der Aufbau als SEO Content mit Zwischenüberschriften und kurzen Absätzen nützt beiden Seitentypen, nur mit unterschiedlicher Gewichtung von Argument und Fakt. Wie sachlich eine bestehende Über-uns-Seite bereits geschrieben ist, entscheidet darüber, ob sie als Faktenquelle ausreicht.

03

llms.txt versus Faktenseite: Inhaltsverzeichnis gegen Steckbrief

Die llms.txt liegt als reine Textdatei im Stammverzeichnis einer Domain, ähnlich der robots.txt, und listet die wichtigsten Seiten mit Kurzbeschreibung auf. Sie beschreibt also, wo etwas steht, nicht was das Unternehmen ist, welche Rolle es hat oder wie es sich von Namensvettern unterscheidet. Sprachmodelle erhalten daraus eine Art Sitemap im Textformat, aber keine Definition, keine Abgrenzung und keine belegten Kernfakten.

Hinzu kommt, dass Google Search die Datei nach eigener Aussage ignoriert. Diese Schwäche fehlt der Faktenseite, weil sie eine reguläre HTML-Seite ist, die jeder Crawler ohnehin liest und über den Footer-Link bei jedem Durchlauf findet. Beide Formate schließen sich nicht aus, sie beantworten nur verschiedene Fragen. Erst wenn die verzeichneten Seiten selbst belastbar sind, bringt das Verzeichnis Nutzen.

Was schreibt der Grounding Page Standard v1.6 vor?

Version 1.6 verlangt als Pflicht genau eine Haupt-Entität, eine H1 mit deren Namen, eine eindeutige Lead-Definition, sichtbare Fakten und gespiegeltes JSON-LD. Veröffentlicht hat das Grounding Page Project den Standard Ende 2025 als offenes Format und pflegt ihn seither, der Name ist als Marke eingetragen. Ganz neu ist die Idee einer zentralen Referenzseite für widersprüchliche Angaben nicht. Hinzugekommen sind der Fokus auf KI-Retrieval und die Ausformulierung als Regelwerk, das am 21. Juli 2026 in Version 1.6.1 erschienen ist. Seit dem 9. Oktober 2026 gilt Version 1.7, die zusätzlich verlangt, dass ein Mensch jede Seite vor der Veröffentlichung prüft und freigibt. Schema und Score-Schwellen sind gleich geblieben.

Der Standard versteht sich als Rahmen für faktische Disziplin mit gewöhnlichem HTML. Ein Protokoll wie HTTP ist er nicht. Zur Orientierung dient eine Ontologie mit achtzehn Entitätsklassen, von Organisation über Produkt bis Wissensgebiet, die als offener Rahmen und nicht als geschlossenes System gedacht ist. Version 1.6 unterscheidet drei Ebenen von Bausteinen, und nur die erste entscheidet darüber, ob eine Seite dem Kern des Standards entspricht.

Ebene	Bausteine	Folge bei Fehlen
Pflicht	Genau eine Haupt-Entität, H1 mit Entitätsname, eindeutige Lead-Definition, Entitätsname in tragenden H2, sichtbare strukturierte Fakten, passender Schema.org-Typ, Spiegelung zwischen HTML und JSON-LD, indexierbare Seite	Seite entspricht nicht dem Kern des Standards
Empfohlen (Stabilität)	Abgrenzung von ähnlichen Entitäten, Quellenangaben, Prüf- oder Statusdatum, FAQ, stabile Sprungmarken, Sprachversionen mit hreflang, Links zu verwandten Entitäten	Seite funktioniert, bleibt aber anfälliger für Verwechslung und Veralten
Kontext- abhängig	Fakten-Verzeichnis, mehrere Seiten, Tabellen und Zeitleisten, Vergleichsabschnitte, Glossar oder Fallstudien, Kontakt- und Verantwortlichkeitshinweise	Nur nach Bedarf der Entität

H1 und Lead-Definition: Der Name, dann zwei bis drei kurze Absätze

In die H1 gehört der Name der Entität oder eine klare Bezeichnung, kein Slogan und kein Zusatz wie „offizielle Faktenseite“. Darunter folgt der Lead in zwei bis drei kurzen Absätzen, zuerst die Definition, dann die Einordnung ins Marktsegment, zuletzt die Abgrenzung von verwandten Entitäten. Nach dem ersten Absatz muss jeder Leser wissen, was die Entität ist, ohne den Rest der Seite gelesen zu haben. Zur Veranschaulichung nutzt das Projekt die fiktive Marke VeloNova.

Deren Lead beginnt mit dem Satz, VeloNova sei ein Fahrradhersteller aus Freiburg, der E-Bikes, Trekking- und Stadträder entwickelt und verkauft. Laut Standard zählt ein sichtbarer Technik-Satz im Lead zu den häufigsten Fehlern, etwa der Hinweis, die Seite diene der Entitätsauflösung in KI-Systemen. Menschen erklärt so ein Satz nichts.

Faktenseite mit H1 als Name und drei Lead-Absätzen

Strukturierte Fakten mit Definitionslisten

Kerndaten wie Rechtsform, Sitz, Gründungsjahr oder Geschäftsführung gehören in eine Struktur, die jedem Attribut genau einen Wert zuweist. Die Typen und Felder dafür sind in schema.org definiert. HTML kennt dafür die Definitionsliste, bei der <dl> den Container bildet, <dt> den Begriff nennt und <dd> den Wert liefert. Daraus entsteht für ein System eine Schlüssel-Wert-Beziehung, die es nicht erst aus Prosa herauslesen muss, und für Menschen eine übersichtliche Datenzeile.

Ausdrücklich erlaubt der Standard auch eine Tabelle oder eine Profilbox, solange die Zuordnung eindeutig bleibt. Umgekehrt warnt er vor dem Zwang, jede Information in das Raster zu pressen, denn längere Erklärungen gehören in normale Absätze, zeitliche Entwicklungen in eine Zeitleiste. Saubere Auszeichnung dieser Art ist ein Teil von OnPage SEO, der auf Faktenseiten mehr Gewicht bekommt als anderswo.

Definitionsliste mit Attribut-Wert-Paaren und Quelltext

Entitätsname in jeder tragenden H2

Such- und KI-Systeme verarbeiten eine Seite selten als Ganzes, sondern zerlegen sie in Abschnitte, die einzeln indexiert oder zitiert werden. Steht über einem Abschnitt nur „Geschichte”, verliert er außerhalb des Seitenkontexts seinen Bezug. „Geschichte von VeloNova” bleibt dagegen auch isoliert verständlich. Deshalb verlangt der Standard den Entitätsnamen in den tragenden H2, während kleinere H3 nicht mechanisch überladen werden müssen. Wie der Name eingebaut wird, bleibt der Marke überlassen, ob „VeloNova und seine Geschichte” oder „Historische Entwicklung von VeloNova” ist zweitrangig. Jeder Abschnitt sollte so geschrieben sein, dass er ohne den Rest der Seite Sinn ergibt.

Abschnitt mit und ohne Entitätsname im isolierten Chunk

Abgrenzung von ähnlichen Entitäten ohne Schema-F-Liste

Viele Zuordnungsfehler entstehen durch falsche Verknüpfung vorhandener Fakten. Typische Paare sind Marke und Muttergesellschaft, Produkt und Hersteller, Veranstaltung und Veranstalter, Methode und Software oder zwei Personen gleichen Namens. Laut Standard muss die Seite diese Unterschiede benennen. Offen bleibt, ob das im Lead, in einem passenden Abschnitt, in der FAQ oder als Hinweis bei den Kerndaten geschieht.

Version 1.6 führt eine schematische Liste unter der Überschrift „Was es nicht ist” als Fehler, weil sie künstlich wirkt. Empfohlen wird stattdessen, die Abgrenzung in die Prosa einzuweben. Im Beispiel des Projekts liest sich das so, dass ein fiktives Gesundheits-Fachforum weder Branchenverband noch Softwareprodukt noch medizinischer Dienstleister sei. Jeder Abgrenzungssatz muss ein reales Verwechslungsrisiko verringern, sonst gehört er nicht auf die Seite.

Fünf Verwechslungspaare und Positionen der Abgrenzung

Prüfdatum, Quellen und Pflegeintervall

Fakten altern, Preise, Rollen und Standorte ändern sich. Ohne Datum und Quelle kann weder ein Mensch noch ein System beurteilen, ob eine Angabe noch gilt. Auf die Seite gehört darum ein sichtbares Prüfdatum, beschriftet etwa mit „Redaktionell geprüft am” oder „Stand”. Vorsicht gilt beim Wort „verifiziert”, damit nicht der Eindruck einer externen Zertifizierung entsteht. Quellen wie Handelsregister, Pressemeldungen oder Verbandsverzeichnisse werden verlinkt, was zugleich auf die Vertrauenswürdigkeit im Sinne von E-E-A-T einzahlt. Bei Gesundheits- oder Finanzentitäten, die Google als YMYL einstuft, wiegt diese Belegpflicht doppelt.

Alle drei bis sechs Monate soll eine redaktionelle Prüfung stattfinden, sofort bei Namensänderung, neuen Produkten, Preisänderungen, Führungswechsel, neuen Standorten oder Fusionen. Wird die Seite geprüft, ändert sich das Prüfdatum, bei echten Inhaltsänderungen zusätzlich dateModified, denn ein automatisch hochgezähltes Datum entwertet das Signal. Mit einer SEO Betreuung lässt sich dieser Rhythmus abdecken, wenn intern niemand die Verantwortung dafür übernimmt.

Zeitleiste des Prüfrhythmus mit Sofort-Anlässen

Warum muss JSON-LD den sichtbaren Inhalt spiegeln?

Aussagen, die nur im Markup stehen, kosten Vertrauen, darum beschreibt der JSON-LD-Block unter dem sichtbaren Text dieselbe Entität mit denselben Werten. Spiegel heißt, dass jede Aussage im Markup auch sichtbar auf der Seite steht, und zwar ohne Widerspruch. Steht in der Definitionsliste als Produkttyp „Analysesoftware”, gehört ins JSON-LD applicationCategory mit dem Wert BusinessApplication, nicht ein Slogan wie „beste Analysesoftware Europas”, der nirgends sichtbar ist.

Gewählt wird der Typ, der zur Entität passt, also Organization, Product, Person, Event oder DefinedTerm. Das generische WebPage verschenkt die Zuordnung. Enthält die Seite eine sichtbare FAQ, spiegelt der JSON-LD-Block sie als FAQPage, ausschließlich mit Fragen und Antworten, die auch im Text stehen. Zusätzliche Marketingbotschaften, die nur Maschinen sehen, verstoßen gegen das Prinzip und kosten Vertrauen.

HTML-Werte und JSON-LD-Felder Zeile für Zeile gespiegelt

Faktenseite vorher mit Hinweisbox, nachher ohne

Was hat v1.6 gestrichen?

Zwei Vorgaben fallen mit v1.6 weg, die KI-Hinweisbox auf jeder Seite und die Erwartung, „Grounding Page“ im Titel oder Text zu nennen. Frühere Versionen setzten oben auf jede Seite eine Box mit dem Hinweis, dass die Seite strukturierte Faktendefinitionen für KI-Systeme enthalte. Version 1.6 hat sie nach Rückmeldungen aus der Community und internen Tests entfernt, weil eine gut gemachte Seite keine Warnung braucht, warum sie existiert. Gestrichen wurde ebenso die Erwartung, dass „Grounding Page” im Titel oder im Text vorkommt, ein dezenter Verweis im Footer oder im Quellcode genügt.

Dahinter steht ein Qualitätstest des Projekts, bei dem man gedanklich jede Erwähnung von KI, LLMs, Retrieval und Grounding von der Seite entfernt. Bleibt danach wenig, was einem menschlichen Leser noch nützt, ist die Umsetzung zu schwach. Viele deutsche Faktenseiten würden diesen Test derzeit nicht bestehen, weil sie ihren Zweck im Titel tragen und den Leser gleich zu Beginn über ihre Funktion belehren.

Wie erstellen Sie eine Grounding Page in sechs Schritten?

Zuerst sichern Sie die Auffindbarkeit, danach folgen Entität, Fakten, HTML-Struktur und JSON-LD, zuletzt kommt die Verlinkung. Am häufigsten scheitert die Umsetzung an der Reihenfolge, weil viele Teams mit dem Text starten, bevor die Technik steht. Ist die Seite später nicht indexierbar oder für Crawler unerreichbar, war die redaktionelle Arbeit umsonst.

Technik bestimmt den Aufwand dabei weniger als die Frage, wer im Unternehmen die Fakten freigibt und später pflegt. Alle Schritte bauen aufeinander auf, Überspringen rächt sich meist beim Spiegeln von HTML und JSON-LD. Als Beispiel dient die fiktive Rugenberg Fensterbau GmbH aus Osnabrück, die Fenster und Haustüren für Privathaushalte und kleine Gewerbebetriebe fertigt und montiert.

Indexierbarkeit und Auffindbarkeit sichern

Die Seite darf nicht auf noindex stehen, und die robots.txt darf weder das Verzeichnis noch die Crawler aussperren, die sie lesen sollen. Sperrt sie Such-Crawler wie OAI-SearchBot, Claude-SearchBot oder PerplexityBot aus, taucht die Seite in den Suchantworten dieser Systeme nicht auf, egal wie gut sie geschrieben ist. Eine Sperre der Trainings-Crawler GPTBot und ClaudeBot verhindert dagegen nur, dass Inhalte in künftige Modelle einfließen.

Diese Grundlagen zählen zum Bereich technisches SEO, die vor dem ersten geschriebenen Satz geprüft sein sollten. Zur Kontrolle dient die Search Console, die zeigt, ob die URL erfasst wurde. Beim Sitemap erstellen wird die neue URL ergänzt, damit Suchmaschinen sie ohne Umweg über den Footer finden.

Entität festlegen und Schema-Typ wählen

Genau eine Haupt-Entität pro Seite, festgelegt als Substantiv, also Unternehmen, Produkt, Person, Standort oder Methode. Für die Rugenberg Fensterbau GmbH ist das die Organisation, ihre Produktlinie „RugTherm” und der Geschäftsführer wären eigene Seiten und werden nur verlinkt. Zur Einordnung bietet die Ontologie des Projekts achtzehn Klassen, Schema.org den passenden Typ, hier Organization oder genauer LocalBusiness.

Fakten sammeln und Quellen zuordnen

Rechtsform, Handelsregisternummer, Gründungsjahr, Sitz, Geschäftsführung, Leistungen, Standorte, Mitarbeiterzahl mit Stand und verifizierte Social-Profile bilden den Grundstock. Zu jedem Wert gehört eine Quelle, das Handelsregister, eine Pressemeldung, ein Verbandsverzeichnis oder die eigene Satzung.

Angaben, die niemand belegen kann oder die sich monatlich ändern, bleiben draußen, denn sie werden zur Fehlerquelle beim nächsten Review. Hinzu kommt der Abgleich mit dem, was bereits im Web steht, etwa im Google Unternehmensprofil, in Branchenverzeichnissen und auf Wikidata. Weicht dort ein Gründungsjahr ab, wird zuerst die Fremdquelle korrigiert, sonst konkurrieren zwei Wahrheiten.

HTML-Struktur bauen

H1 mit dem Entitätsnamen, Lead in drei Absätzen, dann die Definitionsliste mit den Kerndaten, danach Abschnitte mit dem Namen in der H2, etwa „Geschichte der Rugenberg Fensterbau GmbH” und „Leistungen der Rugenberg Fensterbau GmbH”. Abgrenzung, Quellen und Prüfdatum stehen im unteren Teil der Seite. Design, Header und Footer bleiben die der regulären Website, damit die Seite nicht wie ein Fremdkörper wirkt.

JSON-LD spiegeln und validieren

Der Block übernimmt die Werte aus der Definitionsliste unverändert und enthält kein Feld, das nicht auch sichtbar im Text steht. Getestet wird mit dem Rich-Results-Test von Google oder dem Validator von schema.org, danach mit dem Grounding Check des Projekts. Widersprüche zwischen Text und Markup fallen dabei sofort auf und müssen vor der Veröffentlichung verschwinden.

Verlinken: Footer, Fakten-Hub und Prosa

Über einen Footer-Link mit der Beschriftung „Fakten” oder „Über das Unternehmen” ist die Seite von jeder Unterseite aus erreichbar. Bei mehreren Entitäten bündelt ein Hub unter /fakten/ alle Seiten, und verwandte Entitäten verlinken sich gegenseitig im Fließtext. Ohne diese interne Verlinkung bleibt die Seite ein Dokument, das nur über die Sitemap erreichbar ist und das kein Crawler regelmäßig besucht.

Wie sieht das HTML-Skelett mit JSON-LD aus?

HTML-Skelett – grounding-page.html

<h1>Rugenberg Fensterbau GmbH</h1>

<p><strong>Rugenberg Fensterbau GmbH</strong> ist ein Handwerksbetrieb für Fenster und Haustüren mit Sitz in Osnabrück.</p>
<p>Das Unternehmen arbeitet für Privathaushalte und kleine Gewerbebetriebe in Niedersachsen und im Münsterland.</p>
<p>Rugenberg Fensterbau GmbH ist kein industrieller Fensterhersteller und kein Baumarkt.</p>

<h2>Rugenberg Fensterbau GmbH: Kerndaten</h2>
<dl>
  <dt>Rechtsform</dt><dd>GmbH</dd>
  <dt>Gründung</dt><dd>2013</dd>
  <dt>Sitz</dt><dd>Osnabrück, Niedersachsen</dd>
  <dt>Gründer und Geschäftsführer</dt><dd>Jan Rugenberg</dd>
  <dt>Handelsregister</dt><dd>Amtsgericht Osnabrück, HRB 00000</dd>
  <dt>Stand</dt><dd>2026-09-04</dd>
</dl>

<h2>Leistungen der Rugenberg Fensterbau GmbH</h2>
<p>Planung, Fertigung und Montage von Fenstern und Haustüren aus Holz, Kunststoff und Aluminium.</p>

JSON-LD – innerhalb von <script type="application/ld+json">

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Rugenberg Fensterbau GmbH",
  "legalName": "Rugenberg Fensterbau GmbH",
  "foundingDate": "2013",
  "founder": { "@type": "Person", "name": "Jan Rugenberg" },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Osnabrück",
    "addressRegion": "Niedersachsen",
    "addressCountry": "DE"
  },
  "url": "https://www.example.de/fakten/"
}

Jeder Wert im JSON-LD entspricht einer Zeile der Definitionsliste, foundingDate der Gründung, founder dem Gründer, address dem Sitz. Werte, die im sichtbaren Text fehlen, gehören auch nicht ins Markup. Umgekehrt braucht nicht jede sichtbare Angabe ein Feld, das Handelsregister etwa bleibt im Text und in der Quelle.

Prüfwerkzeug

JSON-LD vor dem Speichern prüfen

Ein einziges Zeichen hat auf seoagents.de das komplette JSON-LD der Grounding Page aus dem Quelltext genommen. In einer FAQ-Frage stand nach dem deutschen Anführungszeichen „ ein gerades " als Schlusszeichen. In JSON beendet dieses gerade Zeichen die Zeichenkette, der Rest der Frage macht den ganzen Block ungültig. Das Plugin SASWP speichert ungültiges JSON ohne Warnung.

Prüfschritt von SEO Agents: Prüfen Sie jedes JSON-LD vor dem Speichern. Kontrollieren Sie nach dem Speichern den Quelltext der Seite mit Strg+U: Der Block mit application/ld+json muss dort stehen.

Der Prüfer kontrolliert vier Punkte und listet die @type-Werte im @graph auf:

Der Code besteht die Prüfung mit JSON.parse. Bei einem Fehler nennt der Prüfer Zeile und Spalte und zeigt den Ausschnitt um die Fehlerstelle. Steht nach einem deutschen „ ein gerades " als Schlusszeichen, nennt er die Stelle eigens.
Fehler in Zeile 23, Spalte 54.
@context ist gesetzt, für Schema.org mit dem Wert https://schema.org.
Eine BreadcrumbList enthält mindestens zwei ListItem mit fortlaufenden Positionen ab 1. Google verlangt für Breadcrumbs mindestens zwei Einträge.
dateModified steht im ISO-Format, etwa 2026-10-08 oder 2026-10-08T15:51:59+02:00.

JSON-LD, mit oder ohne <script>-Hülle

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://www.seoagents.de/grounding-page/#webpage",
      "dateModified": "2026-10-08T15:51:59+02:00"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Startseite", "item": "https://www.seoagents.de/" },
        { "@type": "ListItem", "position": 2, "name": "SEO Blog", "item": "https://www.seoagents.de/blog/" },
        { "@type": "ListItem", "position": 3, "name": "Grounding Page: Faktenseite für KI-Systeme erklärt", "item": "https://www.seoagents.de/grounding-page/" }
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Muss der Begriff „Grounding Page" auf der Seite stehen?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Nein. Seit Version 1.6 empfiehlt der Standard ausdrücklich, weder im Titel noch im Text auf den technischen Zweck hinzuweisen. Passende Titel sind der Entitätsname oder „Fakten zur Muster GmbH“, ein dezenter Verweis auf den Standard gehört in den Footer oder den Quellcode."
          }
        }
      ]
    }
  ]
}
</script>

Beispiel: Ungültiges JSON in Zeile 23, Spalte 54. Hier fehlt ein Komma oder die schließende }. Ursache: Nach dem deutschen Anführungszeichen „ steht ein gerades " als Schlusszeichen (Zeile 23, Spalte 52). Ersetzen Sie es durch das deutsche Schlusszeichen “.

21 |         {
22 |           "@type": "Question",
23 |           "name": "Muss der Begriff „Grounding Page" auf der Seite stehen?",
24 |           "acceptedAnswer": {
25 |             "@type": "Answer",

Sie können auch den kompletten Quelltext einer Seite einfügen. Der Prüfer liest dann jeden Block vom Typ application/ld+json.

Wie gehen Sie mit URL, Fakten-Hub und mehreren Entitäten um?

Fakten-Hub mit drei Entitätsseiten, Footer-Link und URL-Regeln

Übliche Pfade für eine Grounding Page sind /fakten/ oder /facts/, bei mehreren Seiten /fakten/unternehmensname/, kurz und stabil nach dem Prinzip sprechender URLs. Nachträgliche Umzüge kosten Signale, deshalb sollte die URL der Grounding Page vor der Veröffentlichung feststehen. Wie viele Seiten ein Unternehmen braucht, richtet sich nach der Zahl seiner eigenständigen Entitäten. Kleine Organisationen kommen laut Projekt meist auf eine bis fünf, Mehrmarkenunternehmen auf fünf bis zwanzig.

Jede zusätzliche Grounding Page braucht auch in zwölf Monaten noch eine Prüfung, sonst entsteht Thin Content mit veralteten Angaben. Massenhafte Erzeugung von Seiten für Keyword- oder Kategorievarianten lehnt der Standard ab, weil daraus Brückenseiten für Retrieval-Systeme würden. Was Google als SEO Manipulation abstraft, dürfte bei KI-Systemen auf Dauer nicht anders enden, sobald deren Spam-Erkennung nachzieht.

Englische Version und hreflang für deutsche Unternehmen

Interne Suchschritte laufen bei vielen Modellen auf Englisch, deshalb konkurriert ein niedersächsischer Handwerksbetrieb im Retrieval unsichtbar mit englischsprachigem Material aus aller Welt. Mit einer englischen Fassung der Grounding Page unter /en/facts/rugenberg-fensterbau/ wird die Entität im globalen Modellraum sichtbar, ohne dass die deutsche Seite verwässert. Pro Sprache entsteht eine eigene, in sich konsistente Seite, verbunden über hreflang inklusive x-default, Eigennamen bleiben unverändert, beschreibende Teile werden idiomatisch übersetzt. Zweisprachige Mischformen auf einer Seite destabilisieren die Zuordnung eher, als dass sie helfen. Für Unternehmen, die sonst nichts mit dem Thema internationales SEO zu tun haben, ist das oft der erste und einzige Anlass für eine zweite Sprachversion.

Hype oder Pflicht: Was spricht für und was gegen Grounding Pages?

Faktenseiten passen zum Wandel der Suche hin zu belegbaren Einzelfakten, gegen einen Pflichtstatus spricht die fehlende Bestätigung durch Google und OpenAI. Kaum ein Vortrag auf der Campixx 2026 kam ohne Grounding Pages aus, und ebenso deutlich fielen die Gegenstimmen aus. Argumentiert wird auf beiden Seiten mit Beobachtungen, die sich nur teilweise überprüfen lassen, weil kein Anbieter offenlegt, wie sein Retrieval Quellen gewichtet. Google und OpenAI haben dem Format bislang keine besondere Rolle zugeschrieben, so wie sie es bei der llms.txt ebenfalls nicht getan haben.

Zugleich verändert sich die Suchinfrastruktur erkennbar in Richtung belegbarer Einzelfakten, was der Logik einer Faktenseite entgegenkommt. Zwischen diesen Polen liegt die Frage, ob ein Unternehmen mit einer Grounding Page etwas gewinnt, das eine sauber gepflegte Website nicht ohnehin liefert. Für eine Faktenseite sprechen Beobachtungen: KI-Systeme beziehen ihre Quellen überwiegend aus den Suchergebnissen, und die Bing Webmaster Tools zeigen, welche URLs als Quelle zitiert werden. Das Grounding Page Project verweist auf Forschung zu sichtbarem Entitätstext in RAG-Pipelines, wertet sie selbst aber nicht als Beleg für Faktenseiten. Gegen eine Pflicht sprechen der Pflegeaufwand und das Risiko veralteter Angaben, wenn niemand die Seite prüft.

Belege und Einwände zur Grounding Page mit Belegstand

Eigene Seite, Über-uns-Upgrade oder gar nichts: Was passt?

Junge oder verwechselbare Marken brauchen eine eigene Grounding Page, sachliche Über-uns-Seiten ein Upgrade, kleine eindeutige Marken ohne Pflegekapazität vorerst nichts. Nicht jedes Unternehmen braucht eine Grounding Page, und für manche ist sie sogar der falsche erste Schritt. Sinnvoll wird sie vor allem dort, wo im Web zu wenige oder widersprüchliche Angaben existieren. Typische Fälle sind junge Marken, ein Rebranding, Namensdoppler oder Konzernstrukturen mit mehreren Marken und Geschäftsführungen. Etablierte Organisationen mit Wikipedia-Eintrag, Presseecho und gepflegten Verzeichnissen gewinnen dagegen weniger, weil Systeme ohnehin genug Quellen finden.

Zwischen beiden Extremen liegt der häufigste Fall, ein mittelständisches Unternehmen mit einer Über-uns-Seite, die nie für Maschinen geschrieben wurde. Zur Wahl stehen dann eine eigene Faktenseite, der Umbau der bestehenden Über-uns-Seite oder vorerst gar nichts. Welcher Weg passt, hängt weniger vom Budget ab als von der Ausgangslage und davon, ob jemand die Seite später pflegt.

Situation	Empfehlung	Begründung
Marke jünger als zwei Jahre oder kürzlich umbenannt	Eigene Grounding Page	Kaum externe Quellen, Systeme greifen auf die einzige Referenz zu
Name mit anderen Unternehmen, Personen oder Produkten verwechselbar	Eigene Grounding Page	Abgrenzung braucht Platz und eigene Struktur
Mehrere Marken, Standorte, Produkte oder Schlüsselpersonen	Eigene Grounding Pages mit Hub	Beziehungen müssen explizit stehen, eine Über-uns-Seite reicht dafür nicht
Sichtbarkeit außerhalb des deutschsprachigen Raums	Eigene Grounding Page mit englischer Fassung	Englische Über-uns-Seiten existieren selten in sachlicher Form
KI-Systeme liefern bereits falsche oder veraltete Angaben	Eigene Grounding Page, sofort	Konkreter Schaden, der eine stabile Referenz braucht
Über-uns-Seite bereits sachlich, stabil, in dritter Person	Über-uns-Seite ergänzen	Kerndaten, Prüfdatum und JSON-LD nachrüsten genügt
Kleine Website, eindeutige Marke, keine Kapazität für Reviews	Vorerst nichts	Ungepflegte Faktenseiten schaden mehr als keine

Über-uns-Seite zur Faktenquelle umbauen

Über-uns-Seiten, die uns in einem GEO Audit begegnen, lassen als Faktenquelle größtenteils Potenzial liegen, selten wegen fehlender Informationen, meist wegen der Form. Dieselben Blöcke wie bei einer eigenen Seite kommen zum Einsatz, nur innerhalb des bestehenden Dokuments. Zuerst wandert die Wir-Form in die dritte Person, „wir sind seit 2011 für Sie da” wird zu „die Muster GmbH wurde 2011 in Frankfurt gegründet”. Dann rücken Kerndaten in eine Definitionsliste direkt unter den ersten Absatz, ergänzt um ein Prüfdatum und eine kurze Abgrenzung von ähnlichen Namen.

Werte, Geschichte und Team bleiben erhalten, sie rücken auf der Über-uns-Seite nach unten und verlieren ihre Superlative. Zum Schluss spiegelt ein Organization-Markup die Kerndaten, und der Footer-Link „Über uns” bleibt, wie er ist. Beim SEO Texte schreiben gelten für diesen Umbau dieselben Regeln wie sonst, kurze Sätze, klare Zwischenüberschriften, ein Gedanke pro Absatz, nur mit Fakten statt Argumenten. Kippt der Kompromiss, weil das Marketing die Superlative zurückfordert oder die Definition wieder auf Absatz drei rutscht, ist die eigene Grounding Page der ehrlichere Weg.

Umbau der Über-uns-Seite in vier Schritten mit Beispielsatz

Woran sich der Aufwand bemisst

Drei Größen bestimmen den Aufwand, die Zahl der Entitäten, die Verfügbarkeit belegter Fakten und die Frage, wer die Seite künftig prüft. Bei einer einzelnen Organisation mit vorhandenem Handelsregisterauszug und klarer Zuständigkeit liegt die Arbeit vor allem im Sammeln und Freigeben der Fakten, die Technik selbst bleibt überschaubar. Mehrmarkenunternehmen mit zehn Entitäten brauchen dagegen ein Redaktionskonzept. Jede Seite braucht einen festen Prüftermin, und die Beziehungen zwischen den Seiten sollen konsistent bleiben.

Freigabeprozesse zwischen Marketing, Recht und Geschäftsführung kosten in der Praxis mehr Zeit als das Schreiben selbst. Übernimmt intern niemand diese Rolle, ist eine SEO Beratung vor dem Bau sinnvoller als die Seite selbst. Geklärt wird dort zuerst, ob das Format überhaupt zum Problem passt. Eingebettet gehört die Grounding Page in eine SEO Strategie, die klassische Sichtbarkeit und Retrieval zusammen denkt, als Baustein unter mehreren statt als Einzelprojekt.

Wie messen Sie, ob KI-Systeme die Faktenseite nutzen?

Mit dem Bericht „AI Performance“ in den Bing Webmaster Tools und mit AI-Visibility-Tools prüfen Sie, ob KI-Antworten Ihre Faktenseite zitieren. Inzwischen gibt es dafür Werkzeuge, wenn auch keine einheitliche Kennzahl über alle Systeme hinweg. Laut einer Pew-Auswertung, über die SISTRIX im Juli 2025 berichtet hat, klicken Nutzer nur in etwa einem Prozent der Fälle auf Links innerhalb von AI Overviews. Rankings und Klicks, die eine SEO Analyse üblicherweise liefert, greifen dafür zu kurz, weil eine Zitation ohne Klick bereits Wirkung zeigt. Vor der Veröffentlichung lohnt deshalb eine Nullmessung, also die Frage an ChatGPT, Gemini und Perplexity, was sie heute über das Unternehmen sagen. Erst der Vergleich mit derselben Frage einige Wochen später zeigt, ob die Seite etwas verändert hat.

Bing Webmaster Tools und Grounding Queries

Microsoft zeigt in den Bing Webmaster Tools unter „AI Performance“, welche URLs einer Domain für welche Suchphrasen als Quelle in KI-Antworten zitiert wurden, inklusive Häufigkeit. Solche auslösenden Phrasen heißen Grounding Queries, weil sie die Antwort in Quellen verankern, und sie unterscheiden sich oft von den Suchbegriffen, für die eine Seite klassisch rankt. Damit lässt sich erstmals auf Seitenebene nachvollziehen, ob eine Faktenseite in der Praxis abgerufen wird oder nur im Index liegt. Über Bing hinaus zählt das, weil Microsoft Copilot und die Websuche in Windows denselben Index nutzen. Taucht die Faktenseite dort nach einigen Wochen nicht auf, liegt das Problem meist bei Indexierung oder Verlinkung und selten beim Inhalt.

AI-Visibility-Tools und die drei Kennzahlen

Spezialisierte Tracking-Werkzeuge stellen definierten Prompt-Sets regelmäßig dieselben Fragen und werten aus, welche Marken und Quellen in den Antworten erscheinen. Durchgesetzt haben sich dabei drei Kennzahlen, AI Visibility misst den Anteil der Antworten, in denen eine Marke vorkommt, Sentiment die Tonlage dieser Nennungen. Citations zählen die Fälle, in denen die eigene Domain als Beleg verlinkt wird. Zusammen bilden sie den Kern dessen, was GEO Tools heute leisten, und ergänzen das klassische SEO Monitoring um die Ebene der Antwortsysteme. Zusätzlich bietet das Grounding Page Project kostenlos einen Grounding Check für die schnelle Diagnose einer einzelnen Seite. Dessen Entity Decoder analysiert eine Seite in mehreren Durchläufen aus Sicht der Entität. KI Sichtbarkeit lässt sich damit vor und nach dem Bau einer Faktenseite vergleichen, ohne dass ein Team selbst hunderte Prompts absetzen muss. Brauchbar als SEO KPIs sind diese Werte allerdings nur bei stabilem Prompt-Set, denn Antworten schwanken von Lauf zu Lauf stark.

Klicks sind der falsche Maßstab

Beobachtungen aus der Branche beziffern die Klickrate aus Quellenangaben in Chatbots und AI Overviews auf etwa ein Prozent. Selbst eine häufig zitierte Faktenseite bringt also kaum Besucher, und wer sie an Sitzungen misst, wird sie für gescheitert halten. Ihr Wert liegt woanders, in der korrekten Darstellung des Unternehmens an dem Ort, an dem Menschen heute Antworten bekommen, bevor sie eine Website öffnen. Damit wirkt Generative Engine Optimization weniger als Performance-Kanal denn als Werkzeug der Markenführung, das falsche Angaben verhindert und Nennungen stabilisiert. Sinnvoll gemessen wird deshalb an Zitationen, Korrektheit der Aussagen und Präsenz in den Antworten, während organischer Traffic auf der Faktenseite selbst kaum etwas aussagt.

Häufige Fragen zu Grounding Pages

Muss der Begriff „Grounding Page" auf der Seite stehen?

Nein. Seit Version 1.6 empfiehlt der Standard ausdrücklich, weder im Titel noch im Text auf den technischen Zweck hinzuweisen. Passende Titel sind der Entitätsname oder „Fakten zur Muster GmbH”, ein dezenter Verweis auf den Standard gehört in den Footer oder den Quellcode.

Darf eine Grounding Page auf noindex stehen?

Nein. Retrieval-Systeme greifen über Suchindizes auf Seiten zu, eine nicht indexierte Faktenseite bleibt für sie unsichtbar. Zusätzlich sollte sie siteweit verlinkt sein, damit Crawler sie bei jedem Durchlauf finden.

Ersetzt eine Grounding Page die Über-uns-Seite?

Nein. Beide Seiten erfüllen unterschiedliche Aufgaben, die Über-uns-Seite baut Vertrauen bei Menschen auf, die Faktenseite liefert Maschinen und Lesern eine neutrale Referenz. Ist die Über-uns-Seite bereits sachlich und stabil geschrieben, lässt sie sich um Kerndaten, Prüfdatum und Markup ergänzen, statt eine zweite Seite zu bauen.

Braucht eine deutsche Grounding Page eine englische Version?

Sinnvoll ist sie, sobald Sichtbarkeit außerhalb des deutschsprachigen Raums zählt oder das Unternehmen mit englischsprachigen Wettbewerbern konkurriert. Mit einer englischen Fassung unter eigener URL und hreflang steigt dann die Chance auf korrekte Zitierung, weil die Entität im englisch geprägten Retrieval der Modelle sichtbar wird.

Wie viele Grounding Pages braucht ein Unternehmen?

So viele, wie es eigenständige Entitäten mit Bedeutung für die öffentliche Wahrnehmung gibt. Ohne eigenständige Marken ist das für ein einzelnes Unternehmen meist eine einzige Seite, bei mehreren Marken, Produkten oder Schlüsselpersonen entsprechend mehr. Wichtiger als die Zahl ist, dass jede Seite eine Zuständigkeit für die Pflege hat.