Open Knowledge Format (OKF): Der SEO- und GEO-Reality-Check

Jedes Mal wenn Google etwas Neues raushaut, sitzt kurz darauf ein Kunde bei mir und will wissen, ob er jetzt schnell etwas umstellen muss. Beim Open Knowledge Format war es nicht anders. Der Name allein – „Open Knowledge“, von Google, für KI – reicht, damit die SEO-Branche reflexartig fragt: Ist das das nächste Ding, das ich auf meine Domain packen muss, um in den KI-Antworten aufzutauchen?

Kurze Antwort: Nein. Etwas längere Antwort: Es lohnt sich trotzdem, das Format zu verstehen – nur aus anderen Gründen, als die meisten gerade annehmen.

Ich habe mir die Ankündigung, die Spezifikation auf GitHub und die ersten deutschen Analysen angeschaut. In diesem Beitrag trenne ich, was OKF technisch ist, was die Hype-Welle daraus falsch macht, und was du als SEO oder Agentur damit konkret anfangen kannst. Ohne Ranking-Versprechen, weil es keine gibt.

Veröffentlicht wurde das Open Knowledge Format am 12. Juni 2026 in Version v0.1 – im Google-Cloud-Umfeld, nicht als offizieller Such- oder Ranking-Standard. Google selbst nennt diese Version im Ankündigungs-Blog „a starting point, not a finished standard“ – also ausdrücklich einen Anfang, kein fertiges Regelwerk. Das ist wichtig für die Einordnung: Wir reden über eine frühe, experimentelle Spezifikation (Stand: Juni 2026).

Technisch ist OKF erstaunlich unspektakulär – und das ist Absicht. Ein OKF-Bundle ist nichts weiter als ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter. Jede Datei beschreibt ein „Konzept“: eine Tabelle, ein Dataset, eine Metrik, ein Runbook, eine API. Im YAML-Kopf stehen die strukturierten Felder, im Markdown-Body die menschenlesbare Beschreibung. Google fasst die Idee so zusammen: „What’s missing is a format, not another service.“ Übersetzt: Es fehlt kein weiterer Wissens-Dienst, sondern ein gemeinsames Format.

Das Konzept ist nicht neu erfunden. Es greift Andrej Karpathys Idee einer „LLM-Wiki“ auf – einer dauerhaften, verlinkten Wissensbasis, die ein Modell nutzt, statt bei jeder Anfrage dieselben Rohdokumente neu zu durchsuchen. Genau deshalb wird OKF von einigen Analysten als Gegenentwurf zu klassischem RAG interpretiert, bei dem pro Anfrage Fragmente aus einem Korpus geholt werden. Wichtig: Das ist eine Einordnung Dritter, keine Produktstrategie von Google. Google selbst spricht zurückhaltender davon, dass man „agents a shared markdown library“ gibt, „instead of using models to search the same documents for the same facts over and over“. Die scharfe RAG-Gegenüberstellung kommt von Kommentatoren, nicht aus dem Google-Dokument – das ist ein feiner, aber wichtiger Unterschied.

So sieht ein OKF-Bundle aus

Damit das greifbar wird: Laut aktueller v0.1-Spezifikation im Repository schreibt OKF nur eine Handvoll reservierter YAML-Felder vor, von denen lediglich type verpflichtend ist. Der Rest ist optional. Diese Tabelle zeigt die reservierten Felder und ihren Zweck:

Ein konkretes Bundle ist nichts Geheimnisvolles – es ist ein Ordner mit Dateien. So könnte ein OKF-Bundle für mein eigenes SEO-Wissen aussehen – Prozesse und Metriken, die meine Agenten konsistent nutzen sollen:

seo-kreativ-wissen/
├── index.md
├── prozesse/
│   ├── index.md
│   ├── content-audit.md
│   └── interne-verlinkung.md
└── metriken/
    ├── index.md
    └── striking-distance.md

Eine einzelne Konzeptdatei – hier striking-distance.md – kombiniert den strukturierten YAML-Kopf mit einem menschenlesbaren Markdown-Body:

---
type: Metric
title: Striking Distance Keywords
description: Keywords auf Position 8-20 mit Quick-Win-Potenzial.
resource: https://search.google.com/search-console
tags: [gsc, content-audit, quick-wins]
timestamp: 2026-06-16
---
# Definition
Keywords mit durchschnittlicher GSC-Position zwischen 8 und 20.

# Schwellenwerte
| Feld        | Wert       | Bedeutung                 |
|-------------|------------|---------------------------|
| position    | 8-20       | Striking-Distance-Fenster |
| impressions | ≥ 10/Mo | Mindest-Nachfrage         |

# Verwendung
Fließt als priorisierter Refresh-Kandidat in den Redaktionsplan.

Illustratives Beispiel nach dem OKF-v0.1-Schema (vereinfacht): type ist Pflicht, alle anderen Felder sind optional. So könnte ein Wissens-Bundle für seo-kreativ.de aussehen.

Veröffentlicht ist das Ganze unter der Apache-2.0-Lizenz im offiziellen GitHub-Repository von Google Cloud. Mitgeliefert wurden zwei Referenz-Implementierungen – ein „Enrichment Agent“, der ein BigQuery-Dataset durchläuft und für jede Tabelle automatisch ein OKF-Dokument entwirft, sowie ein statischer HTML-Visualizer, der ein Bundle ohne Backend in eine interaktive Graph-Ansicht verwandelt – plus drei Beispiel-Bundles (GA4-E-Commerce, Stack Overflow und Bitcoin-Datensätze). Wer schon mal die Idee hatte, sein Wissen als Knowledge Graph zu strukturieren, erkennt das Muster sofort.

Hier liegt der eigentliche Denkfehler, den ich gerade überall sehe. Weil OKF aus Markdown besteht und „für KI“ ist, landet es im selben mentalen Ordner wie llms.txt. Das ist falsch, und der Unterschied ist nicht akademisch – er entscheidet, ob du Arbeit in die richtige oder die falsche Richtung steckst.

Der sauberste Weg, das auseinanderzuhalten, ist die Frage: Wer soll das lesen?

llms.txt ist ein Vorschlag, eine Datei auf deiner Domain abzulegen, damit KI-Systeme deine Inhalte leichter finden und verarbeiten. Es ist nach außen gerichtet. OKF macht das Gegenteil: Es bündelt dein internes Wissen für deine eigenen Agenten – Datenbank-Schemas, Metrik-Definitionen, Runbooks. Niemand außerhalb deiner Organisation ist die Zielgruppe.

Und schema.org? Das ist ein Web-Standard, mit dem du Inhalte im HTML für Suchmaschinen auszeichnest – die Grundlage für viele Rich Results und ein Baustein, wie strukturierte Daten in AI Overviews hineinspielen. OKF ist ausdrücklich kein solcher Web-Standard. Es ersetzt schema.org nicht und konkurriert nicht damit.

Lass uns die Frage, die alle eigentlich meinen, direkt beantworten: Bringt OKF dir Rankings, Traffic oder Citations in AI Overviews? Nach allem, was bis heute (Stand: Juni 2026) dokumentiert ist, lautet die Antwort: nein, nicht direkt. OKF ist kein Faktor, den Googles Ranking-Systeme von deiner Website abgreifen. Es lebt intern, nicht im offenen Web.

Mir sind aus meiner bisherigen Analyse keine belastbaren Fälle bekannt, in denen eine Seite ganz ohne organisches Ranking regelmäßig in AI Overviews zitiert wurde – und ich schaue in technischen Audits oft genug nach. Die Mechanik, über die du in der KI-Suche sichtbar wirst, läuft weiterhin über klassische Substanz: relevante Inhalte, die ranken, und die Frage, wie du zur zitierten Quelle in KI-Antworten wirst. Daran ändert ein internes Wissensformat erstmal nichts.

Trotzdem würde ich OKF nicht abhaken. Meine Einschätzung: Der eigentliche Wert für uns liegt im Signal, nicht im Mechanismus. Google legt hier offen, wie es sich aufbereitetes Wissen für Agenten vorstellt – strukturiert, kuratiert, maschinenlesbar, mit klaren Typen und Verlinkungen. Das ist exakt dieselbe Denkweise, die hinter guter GEO-Arbeit steckt. Und es passt zu der Linie, die Google ohnehin fährt: dass GEO und AEO im Kern noch SEO sind. Wer Inhalte so baut, dass eine Maschine Konzepte, Definitionen und Zusammenhänge sauber greifen kann, arbeitet in die Richtung, die OKF auf der Datenebene vormacht. Ein Garantie­versprechen ist das nicht – aber tendenziell der robustere Weg.

Dazu kommt der Kontext: Das passt in die Entwicklung, dass Google Infrastruktur für agentenbasierte Systeme ausbaut. Dass parallel ein eigener User Agent für KI-Agenten auftaucht und nun ein Format für Agenten-Wissen, wirkt zumindest konsistent mit dieser Entwicklung.

Statt zu fragen „Wie ranke ich mit OKF?“ ist die nützlichere Frage: „Wo arbeite ich selbst mit KI-Agenten – und wie gebe ich ihnen besseres Wissen?“ Genau da wird das Format interessant.

Mein eigenes SEO-Dashboard füttere ich seit Monaten mit Domänenwissen, damit die Agenten darin nicht bei jeder Auswertung wieder bei null anfangen – Kundenkontext, Definitionen, wiederkehrende Audit-Muster. Bisher ist das ein selbstgebautes Durcheinander aus Markdown und Notizen. Genau dieses Problem – fragmentiertes Wissen, das jeder Agent neu zusammensuchen muss – adressiert OKF mit einem einheitlichen Format. Das ist für mich der ehrlichste Anwendungsfall.

Für Agenturen lässt sich das übersetzen. Drei Ansatzpunkte, die heute schon realistisch sind:

• Internes Domänenwissen kapseln: SEO-Prozesse, Briefings, wiederkehrende Definitionen und Kunden-Eigenheiten als OKF-Bundle ablegen, damit deine KI-Workflows konsistent darauf zugreifen – statt jedes Mal Prompts mit Kontext vollzustopfen.
• Kundendaten-Kontext strukturieren: Wenn du mit Daten arbeitest (GSC-Exporte, Analytics, Tabellen), beschreibt OKF Schemas und Metriken so, dass ein Agent weiß, was eine Spalte bedeutet – der Enrichment Agent aus dem Repo zeigt das für BigQuery vor.
• Das Format beobachten, nicht überinvestieren: v0.1 ist früh. Es lohnt, einmal ein Beispiel-Bundle durch den HTML-Visualizer zu schicken und ein Gefühl zu bekommen – aber keine große Migration starten, solange die Adoption außerhalb von Google noch unklar ist.

Der Reflex ist bei neuen Tools fast immer gleich: erst der Hype, dann irgendwann die Frage, welches Problem das Ding eigentlich löst. Bei OKF ist das Problem real – aber es ist ein Wissensmanagement-Problem, kein Ranking-Problem. Wenn du diese Trennung im Kopf behältst, kannst du das Format nüchtern und nützlich einsetzen.

Das Open Knowledge Format ist ein gutes Beispiel dafür, wie schnell aus „von Google, für KI“ in der SEO-Branche ein vermeintlicher Ranking-Trick wird. Der nüchterne Blick: OKF löst ein echtes Problem – fragmentiertes Wissen, das KI-Agenten immer wieder neu zusammensuchen müssen – aber dieses Problem ist Wissensmanagement, nicht Suchmaschinenoptimierung.

Für deine tägliche SEO-Arbeit ändert sich kurzfristig nichts. Mittelfristig lohnt der Blick auf das Format aus zwei Gründen: als Richtungssignal, wie Google maschinenlesbares Wissen denkt, und als praktisches Werkzeug, wenn du selbst mit KI-Workflows arbeitest. Beides hat Wert – nur eben nicht den, den der erste Reflex vermutet.