Open Knowledge Format (OKF): Google's Markdown Standard for AI Agents, Explained
Google shipped OKF, a plain-markdown format for handing your content to AI agents. What it is, how it sits next to llms.txt and schema, and whether it's worth your time.
A Library for the Bots
There is a quiet version of the web being built right now, and almost none of us asked for it. It is the layer machines read. Not the pages with the fonts and the hero images and the cookie banner that won’t go away. The other one.
The sitemap that tells a crawler which URLs exist. The robots file that tells it where not to go. The llms.txt that points an agent at the handful of pages you actually want read. Most people who make websites have never looked at any of it, and that is fine, because until recently it didn’t do much.
Last month Google added a new floor to that layer. It is called the Open Knowledge Format, OKF for short, and the surprising thing about it is that you can write one in a text editor. No SDK. No account. No build step. If you have ever written a markdown file with a bit of YAML at the top, you already know ninety percent of the spec.
I work on this stuff for a living, so I read the announcement the way you read a letter addressed to you by mistake. It was clearly written for data teams. But it lands squarely on a problem the rest of us have been poking at for a year. So here is what it actually is, where it fits, and whether you should bother.
What OKF Actually Is
Strip away the framing and OKF is almost boring, in the good way. A bundle is a folder of markdown files. Each file is one concept. A concept can be anything you want to capture: a blog post, a product, a dataset, a metric, a runbook. Every file opens with a short block of YAML that says what it is, and the body underneath is just markdown. Files link to each other with ordinary markdown links. That is the whole thing.
Here is a single file, since a bundle is only ever a folder of these.
---
type: Article
title: How I Migrated From WordPress to Astro
description: The plugins, the cache, and why I stopped fighting the platform.
resource: https://adityarsingh.in/blog/the-quieter-web/
tags: [astro, wordpress, web]
timestamp: 2026-06-06T00:00:00Z
---
# How I Migrated From WordPress to Astro
The body of the post, as clean markdown. Internal links like
[NoLogs](/concepts/nologs.md) stay as links, so an agent can follow them.Drop an index.md at the top that lists what’s in the folder, so an agent can see the shape of things before it opens every file, and you have a conformant bundle. The full spec fits on one page.
The only field OKF truly demands of every concept is type. Everything else is left to you. That restraint is the point. OKF is not trying to be a database or a knowledge graph or a platform. It is trying to be a handshake. A format both sides agree on, so a wiki one person writes can be read by an agent someone else built, with no translation in between.
Where OKF Fits
You already met most of this layer in the intro. The sitemap, the robots file, the llms.txt. OKF is the new floor sitting on top of them, and the easiest way to hold the whole thing in your head is to give each piece one job.
The sitemap is the index: here are the URLs that exist. Schema, the JSON-LD buried in your head tag, is the labelling: this page is a product, here is its price, here is the author. llms.txt is the signpost: of everything I have, read these first.
Every one of those either points at your content or describes it from the outside. None of them hands the content over. That is the gap OKF fills. It gives an agent the actual body of every page, with the navigation and the ads and the markup stripped away, written as clean markdown it can read without scraping a thing.
They do not compete, they stack. The sitemap and llms.txt tell an agent where your content is. Schema tells it what your content is. OKF just gives it the content.
OKF or Schema?
This is the bit that tripped people up in the first week, so it is worth slowing down on, because the two look similar and do opposite jobs.
Schema, the JSON-LD you bury in your <head>, describes a page from the outside. It tells a search engine this thing is a recipe, here is the cook time, here is the rating. It is metadata about the page, living inside the page, written for the machines that index the open web. It is brilliant at what it does and you should keep doing it.
OKF goes the other way. It does not describe the page. It is the page, lifted out of the HTML and handed over as portable markdown, body and all, for an agent that wants to read and reason over your content rather than rank it.
Schema says “here is what this is.” OKF says “here is the whole thing, plus how it connects to my other things.”
The honest one-liner: schema is for the search engine that ranks you, OKF is for the agent that reads you. If you only ever cared about ranking, OKF changes nothing for you today. If you care about being legible to the systems sitting between your writing and your reader, it is a different and newer bet.
What It Does for AI Search
If you take one thing from OKF, take this. When a model scrapes your site the normal way, it gets a flat pile of text. The relationships are gone. It cannot tell that your pillar post links to four supporting posts, or that this glossary term feeds that product page. A flat scrape throws the structure away and keeps the words.
OKF keeps the structure. The internal links survive as links, so the bundle is not a list of files, it is a graph. An agent sees not just your pages but how they hang together. For anyone who thinks about internal linking and topical clusters for a living, that is the interesting part. You are handing over the map, not just the territory.
And there is a free side effect. The moment you render a bundle as a graph, the orphan pages light up. The posts with nothing pointing in or out, the dead-end tags, the clusters that don’t connect to anything. That picture alone is a structural audit you didn’t have to pay for.
Why It Carries Google’s Weight
There are smarter, sharper specs in this space already, built by people I respect. What they don’t have is a live product behind them. OKF shipped inside Knowledge Catalog, a real Google Cloud product, announced on the Google Cloud blog. Google describes it as formalising the “LLM-wiki” pattern, the markdown-and-frontmatter idea that has been quietly reappearing for a year as Obsidian vaults wired to coding agents, as AGENTS.md and CLAUDE.md files, as repos full of index.md that agents read before doing real work.
None of those instances were designed to cooperate. OKF is the version with a standards body and a backwards-compatibility promise attached.
You will see the GitHub repo carry a “not an official Google product” line, which looks like a contradiction. It isn’t. Google stamps that on most of its open-source repos. It means the code is unsupported, not that the format is unofficial. Google wrote the spec and put its name on the announcement. The disclaimer is lawyers, not doubt.
When a company that size standardises a pattern you have already been betting on, that is worth a few minutes of your attention, even at version 0.1.
What It Won’t Do Yet
Here is the catch, and I would rather you hear it from me than learn it after a weekend of work. Nothing crawls the web for OKF bundles yet. The spec is weeks old. No agent is out there discovering your /okf/ folder and getting smarter about you because of it. And it was built for data teams sharing tables and metrics inside an organisation, not for blogs and marketing sites. Pointing it at a public website is a repurposing. A reasonable one, but a repurposing, and anyone selling it to you as urgent is selling you something.
So a bundle will not move your rankings this week, or your AI visibility, or anything you can put on a dashboard. What it does is make your content trivial to read the day an agent does come looking, and give you that structural map in the meantime. That is the entire pitch. No more, no less.
Whether It’s Worth Your Time
It depends on how you think about protocol-layer work. If you want results you can measure this quarter, skip it. Nothing breaks. Come back when something actually reads these.
But if you have ever shipped schema and waited years for it to matter, you know the shape of this bet. The cost is tiny: a folder of markdown and a drag-and-drop onto your host. The downside is basically zero. And the structural audit you get back has value even if no agent ever opens the bundle.
That asymmetry, near-zero cost against a small chance of an early-mover payoff, is the only reason I would touch a 0.1 draft at all. It is the same reason I shipped schema early and llms.txt early. You put it down, you forget it is there, and you let it compound.
I am putting one on my own site for exactly that reason. Not because it works yet. Because the day it does, I would rather already be on the shelf.
Building Your Own
You do not have to hand-write a bundle. The format is simple enough that a tool can crawl a site, convert each page to a clean OKF concept, link them into a graph, and hand you the folder. A few of these already exist. I am building my own, because it fits what I am already working on and because the format is small enough to be a fun weekend project rather than a quarter-long one.
The shape is roughly: a function that reads your sitemap, fetches each page, pulls out the main content, converts the HTML to markdown, writes the YAML front matter, and zips the lot. The hard parts are not the format, they are the boring web problems: messy HTML, pages that only render in JavaScript, and being polite about how fast you crawl.
If you want, I will write that up properly as its own post once mine is live.
OKF is not a revolution. It is a floorboard. But the web has been laying these quietly for a while now, and the people who put them down early tend to be glad they did. This one has Google’s weight on it, costs almost nothing, and hands the bots a clean copy of your work instead of making them guess. That is enough for me to ship it and move on.