Open Knowledge Format (OKF): The SEO & GEO Reality Check

Every time Google ships something new, a client lands in my inbox shortly after asking whether they need to change something fast. The Open Knowledge Format was no different. The name alone – “Open Knowledge”, from Google, for AI – is enough to make the SEO industry ask reflexively: is this the next thing I have to put on my domain to show up in AI answers?

Short answer: no. Slightly longer answer: it’s still worth understanding the format – just for different reasons than most people currently assume.

I went through the announcement, the specification on GitHub, and the first German analyses. In this post I separate what OKF technically is, what the hype wave gets wrong about it, and what you as an SEO or agency can actually do with it. No ranking promises, because there aren’t any.

The Open Knowledge Format was published on June 12, 2026 as version v0.1 – within the Google Cloud ecosystem, not as an official search or ranking standard. In the announcement, Google itself calls this version “a starting point, not a finished standard.” That matters for context: we’re talking about an early, experimental specification (as of June 2026).

Technically, OKF is surprisingly unspectacular – and that’s intentional. An OKF bundle is nothing more than a directory of Markdown files with YAML frontmatter. Each file describes a “concept”: a table, a dataset, a metric, a runbook, an API. The structured fields live in the YAML header, the human-readable description in the Markdown body. Google sums up the idea like this: “What’s missing is a format, not another service.”

The concept isn’t newly invented. It builds on Andrej Karpathy’s idea of an “LLM wiki” – a permanent, linked knowledge base a model uses instead of searching the same raw documents over and over on every query. That’s why some analysts interpret OKF as a counter-design to classic RAG, where fragments are pulled from a corpus per query. Importantly, that’s a third-party reading, not a product strategy from Google. Google itself frames it more cautiously, saying you give “agents a shared markdown library” “instead of using models to search the same documents for the same facts over and over.” The sharp RAG comparison comes from commentators, not from Google’s document – a subtle but important distinction.

What an OKF bundle looks like

To make it concrete: per the current v0.1 specification in the repository, OKF prescribes only a handful of reserved YAML fields, of which just type is mandatory. The rest is optional. This table shows the reserved fields and their purpose:

A concrete bundle is nothing mysterious – it’s a folder of files. Here’s what an OKF bundle for my own SEO knowledge could look like – processes and metrics my agents should use consistently:

seo-kreativ-knowledge/
├── index.md
├── processes/
│   ├── index.md
│   ├── content-audit.md
│   └── internal-linking.md
└── metrics/
    ├── index.md
    └── striking-distance.md

And a single concept file – here striking-distance.md – combines the structured YAML header with a human-readable Markdown body:

---
type: Metric
title: Striking Distance Keywords
description: Keywords ranking 8-20 with quick-win potential.
resource: https://search.google.com/search-console
tags: [gsc, content-audit, quick-wins]
timestamp: 2026-06-16
---
# Definition
Keywords with an average GSC position between 8 and 20.

# Thresholds
| Field       | Value      | Meaning                |
|-------------|------------|------------------------|
| position    | 8-20       | Striking-distance band |
| impressions | ≥ 10/mo | Minimum demand         |

# Usage
Feeds the editorial plan as a prioritized refresh candidate.

Illustrative example following the OKF v0.1 schema (simplified): type is required, all other fields optional. This is how a knowledge bundle for seo-kreativ.de could look.

The whole thing is published under the Apache 2.0 license in Google Cloud’s official GitHub repository. It shipped with two reference implementations – an “enrichment agent” that walks a BigQuery dataset and automatically drafts an OKF document for each table, plus a static HTML visualizer that turns a bundle into an interactive graph view without any backend – and three sample bundles (GA4 e-commerce, Stack Overflow and Bitcoin datasets). Anyone who has ever thought about structuring their knowledge as a knowledge graph will recognize the pattern immediately.

This is where the real misconception sits, the one I’m seeing everywhere right now. Because OKF is made of Markdown and is “for AI,” it ends up in the same mental folder as llms.txt. That’s wrong, and the difference isn’t academic – it decides whether you put work into the right direction or the wrong one.

The cleanest way to keep them apart is to ask: who is supposed to read this?

llms.txt is a proposal to place a file on your domain so AI systems can find and process your content more easily. It’s outward-facing. OKF does the opposite: it bundles your internal knowledge for your own agents – database schemas, metric definitions, runbooks. Nobody outside your organization is the audience.

And schema.org? That’s a web standard you use to mark up content in HTML for search engines – the basis for many rich results and a building block in how structured data feeds into AI Overviews. OKF is explicitly not such a web standard. It doesn’t replace schema.org and doesn’t compete with it.

Let’s answer the question everyone actually means: does OKF get you rankings, traffic, or citations in AI Overviews? Based on everything documented to date (as of June 2026), the answer is: no, not directly. OKF is not a factor Google’s ranking systems pull from your website. It lives internally, not in the open web.

From my analysis so far, I’m not aware of any solid cases where a page got cited regularly in AI Overviews without any organic ranking at all – and I check often enough in technical audits. The mechanics that make you visible in AI search still run on classic substance: relevant content that ranks, and the question of how you become the cited source in AI answers. An internal knowledge format changes none of that for now.

Still, I wouldn’t write OKF off. My take: the real value for us lies in the signal, not the mechanism. Google is showing here how it imagines prepared knowledge for agents – structured, curated, machine-readable, with clear types and links. That’s exactly the same thinking behind good GEO work. And it fits the line Google takes anyway: that GEO and AEO are at their core still SEO. Whoever builds content so a machine can cleanly grasp concepts, definitions, and relationships is working in the direction OKF demonstrates at the data level. That’s not a guarantee – but it tends to be the more robust path.

On top of that comes the context: this fits the broader development of Google expanding infrastructure for agent-based systems. The fact that a dedicated user agent for AI agents appeared in parallel, and now a format for agent knowledge, at least looks consistent with that direction.

Instead of asking “how do I rank with OKF?”, the more useful question is: “where am I working with AI agents myself – and how do I give them better knowledge?” That’s where the format gets interesting.

I’ve been feeding my own SEO dashboard with domain knowledge for months so the agents in it don’t start from scratch on every analysis – client context, definitions, recurring audit patterns. Until now that’s a homegrown mess of Markdown and notes. This exact problem – fragmented knowledge each agent has to reassemble – is what OKF addresses with a single format. For me, that’s the most honest use case.

For agencies, that translates well. Three starting points that are realistic today:

• Encapsulate internal domain knowledge: store SEO processes, briefings, recurring definitions and client specifics as an OKF bundle so your AI workflows access them consistently – instead of cramming context into prompts every time.
• Structure client data context: if you work with data (GSC exports, analytics, tables), OKF describes schemas and metrics so an agent knows what a column means – the enrichment agent in the repo demonstrates this for BigQuery.
• Watch the format, don’t over-invest: v0.1 is early. It’s worth running a sample bundle through the HTML visualizer once to get a feel for it – but don’t kick off a big migration while adoption outside Google is still unclear.

The reflex with new tools is almost always the same: first the hype, then eventually the question of what problem the thing actually solves. With OKF the problem is real – but it’s a knowledge management problem, not a ranking problem. Keep that distinction in mind and you can use the format soberly and usefully.

The Open Knowledge Format is a good example of how quickly “from Google, for AI” turns into a supposed ranking trick in the SEO industry. The sober view: OKF solves a real problem – fragmented knowledge that AI agents keep having to reassemble – but that problem is knowledge management, not search engine optimization.

For your day-to-day SEO work, nothing changes in the short term. In the medium term, the format is worth a look for two reasons: as a directional signal for how Google thinks about machine-readable knowledge, and as a practical tool if you work with AI workflows yourself. Both have value – just not the value the first reflex assumes.