Open Knowledge Format (OKF): Google's New Markdown Format for AI Agents

A few weeks ago I published a long post on making a website agent-ready. It runs through robots rules, llms.txt, schema, markdown negotiation, MCP cards and more, and almost none of it is officially acknowledged by anyone yet. It is a stack of educated bets. Last month Google turned one of those bets into a published standard, the Open Knowledge Format, and unlike most things Google ships you can write one in a text editor.

It arrived quietly, bolted to a rebrand. Google spent years selling Dataplex as enterprise data plumbing nobody outside a data team ever thought about. It is now Knowledge Catalog, described as an “always-on context engine” for AI agents. The product barely moved. The positioning moved completely, which I wrote about when it shipped. OKF is the portable, open piece of that launch, and it is the piece worth your time.

What OKF actually is

Underneath, OKF is plain. A bundle is a directory of markdown files. Every file carries a short block of YAML up top, the type of thing it is, a title, a description, and it links to its neighbours like any markdown document would. An agent reads it as is, with no scraping and no API in the way.

Here is what a single file looks like, since a whole bundle is just a folder of these.

---
type: Article
title: How to Connect the Ahrefs MCP Server to Manus
description: The official MCP servers, why they did not connect, and the fix.
resource: https://yoursite.com/blog/ahrefs-mcp-manus/
tags: [mcp, ahrefs]
---

# How to Connect the Ahrefs MCP Server to Manus

The body of the post, as clean markdown.

Add an index.md that lists the files so an agent can see what is there before opening everything, and that is the format. There is no registry to join and nothing to install. Google’s spec is still short enough to read in one sitting.

Where OKF fits

The web is quietly growing a second layer, one written for machines instead of browsers, and OKF is its newest floor. Sitemap.xml tells a crawler which URLs exist. llms.txt points an agent at the handful of pages you most want read. EntityMap, a separate spec I shipped here last month, declares which entities you own, you, your company, the topics you want your name stuck to, and how they relate. OKF goes one floor higher again and hands over the content itself, every page as a clean markdown concept, cross-linked into a graph an agent can walk.

They stack rather than compete. llms.txt is a signpost, EntityMap is a who’s who, and OKF is the library itself.

What changed in v0.2

Google shipped v0.2 on 25 July 2026, six weeks after the first version. If v0.1 asked what your content is, v0.2 asks whether anyone stands behind it.

The reasoning is worth reading even if you never write a bundle. When a person writes a document, accountability is implicit, because somebody put their name on it. When an agent generates ten thousand concepts overnight that guarantee is gone, so whatever reads them next has to judge each one on signals it can actually see. v0.2 adds four families of optional field to carry those signals.

Family	Fields	What it answers
Provenance	sources	What was this built from, and how credible is that?
Trust	generated, verified	Who made it, and who confirmed it?
Lifecycle	status, stale_after	Is this current, and when does it expire?
Attestation	Attested Computation	Was this number produced the way we said it must be?

Attestation is BigQuery machinery for finance teams who need proof an agent ran the sanctioned query instead of improvising its own. Ignore it. The rest matters to anyone who publishes.

verified is the one to watch. It’s a list of confirmations, each naming an actor, and an actor prefixed human: reads differently to a machine one. That gives you three tiers, unverified, machine-confirmed and human-reviewed, arriving at the exact moment the web fills up with generated text nobody has read. Google is careful to say a consumer must never reject a concept for missing any of this, while noting that its absence now carries meaning.

stale_after is the other one I’d use. It’s an absolute date rather than a countdown, so staleness is a fact instead of a calculation. It’s the first time I’ve been able to write my own re-check policy into the page itself rather than keep it in a document nobody else can read.

Two renames come with it, both backward compatible. timestamp becomes generated.at, and the old # Citations list in the body becomes the sources array.

What I put in my own bundle

I rebuilt my bundle on v0.2, and the honest version is less flattering than the marketing one would be. Here’s a real concept out of it, the same file an agent would fetch.

---
type: "Article"
title: "How ChatGPT Actually Picks Sources"
resource: "https://suganthan.com/blog/how-chatgpt-picks-sources/"
tags: ["geo", "ai-seo", "chatgpt"]
generated: { by: "human:suganthan", at: "2026-06-24T00:00:00.000Z" }
verified:
  - { by: "human:suganthan", at: "2026-06-27T00:00:00.000Z" }
status: stable
stale_after: 2027-06-27
---

All 61 concepts carry generated: { by: human:suganthan }, which is true, and which I suspect is about to become unusual.

Only 18 carry a verified entry. I write and edit everything here myself, so I could have stamped all 61 as human-reviewed and nobody could have checked me. But a confirmation is supposed to be separate from the writing, so the only defensible mapping is a post I went back to, re-checked and updated, and that’s 18 of them. The other 43 make no claim at all.

Eight are already past their stale_after date, the oldest expiring in 2020, all of them SEO posts I haven’t touched in years. The format turned my own bundle into a refresh worklist, which I didn’t ask for and probably needed.

The free tool got the same treatment pointed the other way. It crawls sites it has no relationship with, so it writes generated and a sources entry for the page it read, and it never writes verified. Reading a page isn’t confirming it. A tool that stamped every site it crawled as human-reviewed would make the field worthless inside a week, and that field is the most useful thing in v0.2.

Why it carries Google’s weight

EntityMap is a sharp spec from people I rate, Dixon Jones among them, but it is a community effort. OKF was introduced on the Google Cloud blog and ships inside Knowledge Catalog, a live Google product. Google describes it as formalising the “LLM-wiki” pattern, the markdown-and-frontmatter idea that has been surfacing as Obsidian vaults, AGENTS.md files and llms.txt for the past year. When Google standardises a pattern you’ve already bet on, that’s worth noticing. It has since shipped a second version inside six weeks, which is more attention than most draft specs ever get.

The GitHub repo says it is “not an official Google product”, which looks like a contradiction next to a Google Cloud blog launch. It is not. Google puts that same disclaimer on most of its open-source repos, its main AI samples repo included. It only means the code is unsupported, not that the format is unofficial. Google wrote the spec and announced it. The boilerplate is just doing its usual lawyerly job.

What it does for AI search

A bundle will not move your rankings or your AI visibility this week. Nothing crawls the web for these bundles yet, the spec is two versions into its first summer, and Google built it for data teams sharing tables and metrics, not for blogs. Pointing it at a website is a repurposing. A good one, but a repurposing.

What it does do is make your content effortless to read the day an agent comes looking. The body is clean markdown with the navigation and ads stripped out, every page is tagged with what it is, and the internal links survive as a graph, so an agent sees not just your pages but how they connect. That relationship layer is what a flat scrape throws away. You are not buying a ranking. The win is a site the systems sitting between your writing and your reader can actually understand.

How to make your own bundle

There are 3 ways to turn a site into an OKF bundle.

The first is by hand. Fine for a few pages, miserable for a whole site, since every post becomes a file you format and cross-link yourself.

Exporting from a data catalogue is the second, which is the enterprise route and assumes your content already lives in one. Yours almost certainly does not.

The third is the free tool I built. Paste your URL or your sitemap and it crawls up to 100 pages, converts each one to a clean OKF concept, links them into a graph, and gives you the bundle as a download, without writing code or signing up.

It also draws your site the way an agent sees it, every page a dot and every internal link a line, so the islands with nothing pointing in or out are obvious at a glance. That alone is a free structural audit.

You can find the tool at /free-seo-tools/okf-generator/. I built it the same time I turned my own site into a bundle, so it is the exact engine running here, just pointed at your pages instead of mine. It emits v0.2 bundles.

If you run WordPress

All three methods above work on any site. WordPress runs a big slice of the web, though, and on it you can skip the manual steps entirely. I built a free plugin called BotsBrief that does the whole job. It turns your published posts and pages into a bundle, serves it at /okf/, and rebuilds it every time you publish or edit, so it never falls out of date. It is the same engine as the web tool, wired straight into WordPress, with a live graph of how your content links together.

Installing it takes a minute:

1. Download the plugin from the link above.
2. In your dashboard, open Plugins, then Add New, then Upload Plugin. Choose the zip and click Install, then Activate.
3. Open the new OKF menu to see your bundle and the graph. It is already serving at yoursite.com/okf/.

You can change the settings to include/exclude posts/pages.

It needs WordPress 6.0 or newer and PHP 7.4 or newer, which covers almost every live site. For the tidy /okf/ address you want pretty permalinks turned on under Settings, then Permalinks. Without them the bundle still serves at yoursite.com/?okf=index.md.

It’s in review for the WordPress plugin directory and isn’t listed there yet, so the download above is the way to get it for now.

One note, since it is your site. The plugin is free and open source under the GPL and comes with no warranty. It only reads your published content to build the bundle. It never edits, deletes, or changes your posts, pages, or settings, and removing it leaves everything exactly as it was. As with any plugin, if your site is business critical, try it on a staging copy first.

Hosting it on your site

A bundle only helps if an agent can find it, so serve the files at yoursite.com/okf/, starting with /okf/index.md. On a static host or Cloudflare that is a drag and drop. On WordPress, the plugin above does the serving for you. Without it, it is a manual file upload, a little more fiddly. On closed platforms like Wix or Squarespace you often cannot serve files at a custom path, which is the one real wall. Add a line to your llms.txt pointing at the bundle and you are done.

Whether it is worth your time

So is it a must? No. Skip it and nothing breaks today, and anyone calling a 0.2 draft mandatory is selling you something. It is a nice-to-have. What tips it past the bar is the asymmetry. The cost is a free tool and a drag and drop, and the structural map you get back is a real audit on its own, even if no agent ever opens the bundle.

I have made this bet before, with EntityMap. Protocol-layer work is registration, not advertising. You put it down early, let it compound, and forget it is there. Schema took the best part of a decade to pay off, and I am still glad I shipped it early. This is the same shape of bet, now with Google’s name on it.