The Open Knowledge Format (OKF) is an open specification from Google Cloud for packaging knowledge as a folder of Markdown files with YAML frontmatter, so AI agents and people can read and maintain it. It was built for organizational knowledge, such as data tables, metrics and runbooks, rather than for search engines.
This guide explains the format from the specification itself, separates it from the AEO and GEO claims attached to it, and covers when publishing a bundle makes sense. All details were checked against the spec in Google's repository in October 2026.
What OKF Is
The Open Knowledge Format is a way to package knowledge as a folder of Markdown files. Each file describes one concept, starts with a short YAML block of metadata and links to related files with ordinary Markdown links. The links turn the folder into a graph that a person or an AI agent can browse one file at a time.
It came from Google Cloud's data analytics and BigQuery engineers, not from Google Search. Google Cloud's announcement, published June 12, 2026, describes the problem it targets: the knowledge agents need inside a company, such as what a table contains, what a metric means or how to handle an incident, is scattered across catalogs, wikis, drives and people's heads. The post presents OKF as a format rather than a service: no new runtime and no required SDK.
The repository is licensed under Apache 2.0. Alongside the spec, it holds a proof-of-concept agent that writes OKF documents from BigQuery metadata and documentation pages, a viewer that renders a bundle as an interactive graph in a single HTML file, and sample bundles for the public GA4 e-commerce, Stack Overflow and Bitcoin datasets.
What an OKF Bundle Looks Like
A collection of OKF files is called a knowledge bundle. You organize the folders however suits the subject. The spec reserves only two file names: index.md, which lists a folder's contents so an agent can see what's there before opening anything, and log.md, a dated change history. Every other .md file is a concept.
Here's a small bundle for a fictional software company's help content. It isn't a real product; it's sized so you can read the whole thing.
acme-help/
index.md # optional: lists what's in this folder
log.md # optional: dated history of changes
products/
index.md
starter-plan.md # one concept per file
pro-plan.md
policies/
index.md
refund-policy.md
guides/
index.md
connect-your-domain.mdEach concept file has frontmatter and a body. This one uses the optional v0.2 trust fields to record who wrote it, who confirmed it and when it should be checked again.
---
type: Policy
title: Refund policy
description: Who can get a refund, within how many days, and how to ask for one.
resource: https://acme.example/legal/refunds/
tags: [billing, refunds]
status: stable
generated: { by: human:jsmith, at: 2026-10-01T09:00:00Z }
verified: { by: human:finance-lead, at: 2026-10-02T15:30:00Z }
stale_after: 2027-04-01T00:00:00Z
---
# Summary
Monthly plans can be refunded within 14 days of the first payment.
Annual plans are refunded pro rata. Usage add-ons aren't refundable.
# How to request
Customers email billing@acme.example from the account owner's address.
Plan details live in [Starter plan](/products/starter-plan.md) and
[Pro plan](/products/pro-plan.md).The links in the body use paths that start with /, which the spec recommends because they're relative to the bundle root and survive moving files between folders. Broken links are allowed; the spec treats them as knowledge that hasn't been written yet.
| Field | Status | What it's for |
|---|---|---|
type | Required | The kind of concept, such as Metric, API Endpoint or Policy. There's no official list; you choose the values. |
title, description | Recommended | A display name and a one-sentence summary used in indexes and previews. |
resource | Recommended | A URI for the real thing the concept describes, such as a table, an API or a web page. |
tags | Recommended | Short labels for cross-cutting groups. |
sources | Optional (v0.2) | Where the content came from, with signals such as author and last change. |
generated, verified | Optional (v0.2) | Who or what wrote the concept and who confirmed it. A human: verifier makes it human-reviewed. |
status, stale_after | Optional (v0.2) | Draft, stable or deprecated, plus a date after which the content should be treated as stale. |
If you've read older coverage, note one change. Version 0.1 listed an optional timestamp field and a Citations section in the body. The OKF v0.2 specification replaces them with generated.at and the sources list. It also adds an Attested Computation concept type for data teams that need proof a number was calculated the approved way, which few website owners will need.
The index file at the bundle root is the only index allowed to carry frontmatter, and only to declare the version:
---
okf_version: "0.2"
---
# Products
* [Starter plan](products/starter-plan.md) - Single-site plan with email support.
* [Pro plan](products/pro-plan.md) - Multi-site plan with priority support.
# Policies
* [Refund policy](policies/refund-policy.md) - Who can get a refund and how to ask.
# Guides
* [Connect your domain](guides/connect-your-domain.md) - DNS records and how to check them.# Directory Update Log
## 2026-10-02
* **Update**: Refund window confirmed by finance in [Refund policy](/policies/refund-policy.md).
## 2026-10-01
* **Initialization**: Created products, policies and guides.What OKF Isn't
Several SEO blogs present OKF as a new answer engine optimization (AEO) or generative engine optimization (GEO) tactic. The primary sources don't support that, at least not yet.
What the sources support
- An open, vendor-neutral file format for AI agents and people
- Aimed mainly at organizational and data knowledge
- Readable with any text editor and storable in Git
- An early specification still at version 0.x
What they don't support
- A Google Search ranking factor
- A way to get into AI Overviews or AI Mode
- Proof that AI search engines fetch OKF bundles
- A replacement for schema.org structured data
Google Search's own position on AI features is direct. Google Search's AI features documentation says you don't need new machine-readable files, AI text files or markup to appear in AI Overviews or AI Mode. Pages need to be indexed and eligible for a snippet. That statement covers llms.txt-style files in general; it doesn't single out OKF, but nothing from Google suggests an exception.
I haven't found a primary source from OpenAI, Anthropic, Perplexity or Microsoft saying their search products read OKF bundles. If one appears, it changes the advice. Until then, treat claims that OKF will raise your AI visibility as speculation.
OKF vs llms.txt, Schema Markup and Markdown Pages
OKF lands in a crowded space of formats for machine readers. They're easy to mix up, but they answer different questions.
| Format | Built for | Where it lives | Read by Google Search? |
|---|---|---|---|
| Schema.org structured data | Search engines understanding page content and rich results. | Inside your HTML pages. | Yes, documented for rich results. |
| llms.txt | LLMs and agents reading a website at inference time. | /llms.txt at the site root. | Not required for AI features, per Google. |
| Markdown page versions | Agents that prefer clean text over HTML. | Next to each page, such as page.md. | No documented use. |
| OKF bundle | Agents and people sharing curated organizational knowledge. | A Git repo, archive or folder. | No documented use. |
Schema markup describes the content of a page to search engines and is the only one here with documented search features attached. Our schema markup guide covers it.
llms.txt is a proposal by Jeremy Howard, published at llmstxt.org in September 2024: a Markdown file at the site root that summarizes the site and links to its key pages. The same proposal suggests offering clean Markdown versions of pages at the same URL with .md added. This site ships an llms.txt and a longer llms-full.txt with the text of every guide, but not per-page Markdown files.
OKF overlaps most with llms.txt, since both are Markdown for agents. The difference is scope. llms.txt is a single entry point to a public website. OKF is a whole graph of small, typed documents with provenance and freshness built in, designed to be maintained over time by people and agents together, usually inside an organization.
Should You Publish an OKF Bundle?
For most websites, not yet. It depends on what you expect it to do.
Google says AI features need no special files. Pages must be indexed and eligible for a snippet. Start with technical SEO basics and search intent.
No AI search provider has documented reading OKF bundles. Crawlable HTML, clear answers and an allowed crawler in robots.txt matter more. An llms.txt file is cheap to add but optional.
If your docs already live as Markdown in Git, adding type frontmatter and index files costs little. Generate it from the same source as the site so the two can't drift apart.
This is what Google built it for: table meanings, metric definitions, runbooks. Start with a handful of concepts your team keeps explaining and record who verified each one.
The case is strongest where your content is already structured knowledge: developer documentation, API references, product specifications or data dictionaries, especially if they already live as Markdown files in Git. Adding frontmatter and index files there is a few hours of work, and an agent given the bundle gets well-scoped files instead of scraped HTML.
The case is weakest for a marketing site or a blog hoping for traffic. You'd be maintaining a second copy of your content for readers that, as far as anyone has documented, don't request it.
What to Do for AEO and GEO Instead
Answer engines and AI search features still mostly find content the way search engines do: by crawling public pages. The basics carry over.
- Make sure important pages are indexable. No accidental noindex, no blocked resources, correct canonicals. The noindex guide and page not indexed guide cover the common traps.
- Put the answer in the HTML. Content that appears only after JavaScript runs is harder for every crawler. See the JavaScript SEO guide.
- Write pages that answer one need clearly. Specific headings, direct answers near the top and real data are easier to quote. The search intent guide helps decide what a page should cover.
- Decide which AI crawlers you allow. The robots.txt guide explains the user agent tokens and the trade-offs.
- Add llms.txt if it's cheap for you. It's a small file that's easy to generate, but treat it as optional, not a ranking lever.
resource to the live URL of each page and use stale_after so stale concepts are flagged automatically.Keep an eye on the spec. It moved from 0.1 to 0.2 within months, with two breaking changes. Anything built on it today should be easy to regenerate when it changes again.
Frequently Asked Questions
Related Guides
- Add structured data search engines do use.
- Understand how Google finds and ranks pages.
- Control which AI crawlers can access your site.
- Keep content readable without JavaScript.
I'm a developer who moved into technical SEO. I trace search problems through crawling, rendering, indexing, templates, content and performance, then implement the fixes instead of handing over a generic export. Request a free website review and I'll review your site personally.