The Open Knowledge Format: what Google really shipped, and why the interesting question is not SEO

Every eighteen months or so, the web grows a new machine-readable layer, and the industry performs the same ritual. Someone publishes a specification. Someone else writes “this changes everything.” A third person builds a generator. Within a fortnight, there is a plugin, a LinkedIn debate, and consultants selling implementation packages for a standard that, at that moment, nothing on earth is reading. We have been through this with rel=author, with AMP, and most instructively with llms.txt.

So when Google Cloud published the Open Knowledge Format (OKF) on 12 June 2026, the reflex was predictable. A new open specification from Google, arriving in the middle of the agentic gold rush, described in language engineered to trigger every nerve ending in a technical SEO: portable, interoperable, vendor-neutral, knowledge, graph.

What follows is an attempt to do what our profession is chronically bad at doing with new standards: read the primary source, identify what it actually says, identify what it deliberately does not say, and ask why it exists before asking how to optimize for it.

The short version: OKF is a real and well-designed thing, but it is almost certainly not what most of the SEO industry thinks it is, and the genuinely interesting question about it is one that almost nobody is asking.

What OKF really is, with the specification open in front of us

The OKF v0.1 specification lives in the GoogleCloudPlatform/knowledge-catalog repository under an Apache 2.0 license. It is about 450 lines, and you can read the whole thing in fifteen minutes, which I would encourage anyone forming an opinion about OKF to do, because much of the commentary now circulating is second-hand paraphrase of second-hand paraphrase.

Here is what it defines:

1. A knowledge bundle is a directory tree of Markdown files; the unit of distribution, shipped as a Git repository (recommended), a tarball, a zip, or a subdirectory of a larger repo.
   
2. A concept is one unit of knowledge, represented as exactly one Markdown file. It may describe something tangible (a table, an API endpoint) or abstract (a metric, a process, a runbook). Its ID is simply the file path minus the .md suffix: tables/orders.md is tables/orders. The filesystem is the identifier scheme. No IRIs, no minted URIs, no registry.
3. Each file carries YAML frontmatter and a Markdown body. Exactly one field is required: type, aka a free-text string such as BigQuery Table, Metric, Playbook. Type values are explicitly not registered centrally, and consumers must tolerate unknown ones gracefully. Five more are recommended (title, description, resource, tags, timestamp); producers may add any keys they like, and consumers must not reject documents for carrying fields they do not recognize.
   
4. Two filenames are reserved: index.md, a directory listing enabling what the spec calls progressive disclosure, and log.md, a chronological change history.
   
5. Concepts link to each other using ordinary Markdown links. Absolute, bundle-relative links beginning with / are the recommended form, because they survive a file being moved.

And then, in §5.3, comes the sentence on which the entire strategic assessment turns: a link from concept A to concept B asserts a relationship, but the kind of relationship is conveyed by the surrounding prose, not by the link itself.

Hold on to that. It is the whole argument.

Conformance (§9) is almost aggressively permissive: a bundle conforms if every file has parseable frontmatter with a non-empty type. Consumers must not reject one for missing optional fields, unknown types, unknown keys, broken links, or absent indexes.

The lineage explains the design. In April 2026, Andrej Karpathy published a gist called LLM Wiki, arguing that instead of using RAG to re-derive knowledge from raw documents on every query, you should have an agent incrementally build and maintain a persistent, cross-linked Markdown wiki.

It travelled fast, because it named something many were already improvising: Obsidian vaults wired to coding agents, CLAUDE.md and AGENTS.md files, “metadata as code” repositories. The pattern was everywhere and interoperable nowhere. OKF is Google’s attempt to specify it, and not to build a platform on it.

That is OKF. A folder of Markdown files with a rulebook thin enough to fit in your head.

Read the distribution channel, not the press release

A discipline worth adopting for any new standard: look at where it was published, who published it, and what product it shipped alongside.

Companies tell you who a thing is for by choosing where to put it, long before they tell you in words.

OKF was not published on Search Central. Not on developers.google.com. Not co-announced with other search engines in the manner of schema.org and not routed through the W3C. It was published on the Google Cloud blog, in the Data Analytics section, by two Tech Leads from the Data Cloud group, tagged under BigQuery and AI & ML, and in lockstep with the rebranding of Dataplex into the Knowledge Catalog, a product Google positions as an always-on context engine for grounding enterprise agents, and which was updated to natively ingest OKF bundles and serve them.

If you know how to read a launch, that is the strategic story in one paragraph.

The audience is data engineers, platform teams, and the people building internal agents inside enterprises.

The problem is one anyone who has worked in a large organization recognizes instantly: the knowledge an agent needs is scattered across a catalogue with a proprietary API, a wiki nobody has updated since 2023, some code comments, a Slack thread, and the head of a senior engineer who is on holiday.

Every new agent solves the same context-assembly problem from scratch. Google’s thesis — a good one — is that the fix is not another knowledge service you must integrate with, but a portable format anyone can produce without an SDK and consume without an integration.

The commercial logic is not hidden either: enterprise knowledge is trapped inside competitors’ catalogues, and a portable open format is a solvent for that lock-in, while the reference path (Gemini writing the bundles, BigQuery as the source, Knowledge Catalog as ingestion) keeps the gravity comfortably inside Google Cloud. That is not a criticism. It is what the launch says, read as a strategic document rather than a technical one.

The Search question, settled by the only source that can settle it

Now the question that brought most of our profession here: does publishing an OKF bundle on my site do anything for visibility in Google?

The answer is no; and unusually, we need not infer it. Google put it in documentation.

On 15 May 2026, Search Central published Optimizing your website for generative AI features on Google Search, its first consolidated official guide to AI Overviews and AI Mode, announced on the Search Central blog. It names, individually, the tactics site owners can ignore: llms.txt, content chunking, AI-specific rewriting, and special schema or Markdown versions of pages. You do not need machine-readable files, AI text files, markup, or Markdown to appear in Google Search, including its generative AI features, because Google Search itself does not use them.

A month later, Google clarified that maintaining an llms.txt neither helps nor harms, because Search ignores it.

An OKF bundle hosted at /okf/ is a directory of Markdown files. It falls squarely inside the category Google has just told us, in writing, that Search does not use.

But “not a ranking signal” gets flattened into “irrelevant,” and those are not the same statement. What Google said is precise and limited: Google Search does not consume these files. That is a statement about one consumer, and not about Claude, ChatGPT, Perplexity, coding agents, browser agents, or the internal copilot your client’s operations team is quietly building, none of which are bound by Search Central’s documentation, and several of which demonstrably do read curated Markdown when it is put in front of them.

So: OKF is not a search-visibility mechanism, and there is no evidence that any answer engine goes looking for a website-hosted bundle on its own initiative.

A shared way to store context is not a shared way to understand it

Return to §5.3. The links are untyped.

A link from tables/orders to tables/customers tells a consuming agent the two concepts are related. It does not say how. Not joins-with, not depends-on, not deprecated-by, not is-a. The nature of the relationship lives in the prose around the link, which means an agent must read and infer it, in natural language, every time it traverses that edge.

This is not an oversight. It is the central design bet, and the spec is honest about it: consumers building a graph view are expected to treat every link as a directed edge of an untyped relationship.

Set that against the tradition it is quietly rewriting. The semantic web stack solved this two decades ago with enormous rigor and never conquered the enterprise; not because it was wrong, but because it was expensive: ontologists, triplestores, and a tolerance for formalism most organisations do not possess.

Adoption, not design, was the failure. OKF makes the opposite bet, deliberately, trading semantic precision for near-zero authoring friction: if you can write Markdown, you can produce it, and if you can cat a file, you can consume it.

That bet is defensible.

But we should be clear about what we are getting, and here Marc Bara’s framing is the sharpest distinction anyone has drawn: OKF delivers structural interoperability, not semantic interoperability. It standardizes the container, not the meaning inside it.

Laid side by side, the trade is exact:

Which means two perfectly conformant bundles from two organisations may share no vocabulary at all: the same real-world concept typed Metric in one and KPI Definition in the other, related to its source table by a link meaning “derived from” here and “documented in” there, with nothing to tell a machine the difference. Both pass conformance. Neither can be automatically reconciled with the other.

For those of us who work in entity SEO, this maps onto vocabulary we already use daily:

• Ontology — the model of the domain: what kinds of things exist and what relationships can hold between them. OKF explicitly declines to define one; “defining a fixed taxonomy of concept types” is listed among its stated non-goals.
• Taxonomy — the classification: which things belong in which categories. Left entirely to the producer.
• Context — the prose, the structure, the citations. This is the only layer whose shape OKF standardizes.

In other words, OKF gives an agent a beautifully organised library with a reliable shelving system and no card catalogue. Everything is findable if you already know the building. Nothing is queryable across buildings.

The semantic web community noticed immediately and responded constructively rather than territorially. Kurt Cagle, co-author of the W3C RDFa specification, has proposed treating his DataBook specification as a formal OKF profile: keep the human-authorable, git-hostable Markdown surface OKF specifies, and layer on typed fenced blocks carrying RDF payloads, IRI-based identity, SHACL validation and SPARQL ingest. A bundle conforming to such a profile would remain readable by any ordinary OKF consumer and deployable to any SPARQL-compatible triplestore.

This is the most important thing happening around OKF, and it is happening almost entirely outside the SEO conversation. The framing is elegant: OKF as the adoption vector the semantic web never had; RDF as the deployable back end it always was.

If that profile lands, the calculus changes materially. Until it does, we should be honest that what we have is a folder specification with excellent manners, and the critics on Hacker News made that point more bluntly; the most common objection in that thread being precisely that you cannot represent knowledge well without labelled relationships between entities.

The question I did not see many asking: who fetches the bundle?

The debate about OKF and the open web has been stuck on one fact: nothing goes looking for your bundle. You can publish a perfectly conformant directory at /okf/, and no crawler, no answer engine, no agent will spontaneously request it, because no convention tells them it is there. Everyone who has looked at this with intellectual honesty has reached that conclusion, and the practitioners implementing it were the first to say so publicly.

The conclusion is correct. But it is where the analysis stops, and the missing mechanism now exists. It came from Google.

On 17 June 2026, five days after OKF, Google announced the Agentic Resource Discovery specification (ARD), Apache 2.0, built on a data model developed in a Linux Foundation working group. The mechanics are almost embarrassingly familiar to anyone who has ever written a sitemap:

• A publisher hosts a machine-readable manifest at a well-known path on its own domain: /.well-known/ai-catalog.json.
• That manifest declares the agentic resources the domain offers — each entry a uniformly shaped envelope with an IANA media type, a URN identifier and a URL. MCP servers, A2A agents, OpenAPI tools, skills, nested catalogues.
  
• Registries crawl those catalogues, index them, and answer natural-language discovery queries from agents at runtime, returning matches with the metadata needed to verify the publisher before connecting.

ARD sits entirely before invocation. It does not replace MCP or A2A; it answers the question an agent must ask before using either: what capability exists for this task, and can I trust it? The specification and its ai-catalog data model are public, and the contributor list is not Google-only: Hugging Face shipped a reference implementation, Snowflake published its own position, and Microsoft is a named participant.

And here is the connection I have not seen drawn anywhere (this does not mean anybody has drawn it, simply that I did not see it): the resource types an ARD catalogue can advertise explicitly include Open Knowledge Format bundles.

The reason nothing fetches your OKF bundle is not that OKF is useless. It is that OKF is a payload without a discovery layer, and Google published the discovery layer five days later, in a different division, with a different set of partners, and our industry did not join the two.

A necessary tempering, because I have no interest in replacing one piece of over-excitement with another: ARD is a draft, and its adoption today is close to zero. A census of major sites in mid-June found none of them — including the working group’s own named members — serving a discoverable catalogue. This is a forecast, not a finding. But it is materially different from “nothing will ever read your bundle.”

The correct sentence is:

“Nothing reads a website-hosted OKF bundle today, and the mechanism by which something might eventually read it is now specified, backed by a Linux Foundation working group, and sitting at /.well-known/ai-catalog.json waiting for registries to exist.”

Which does not mean build one this afternoon. It means the thing to monitor is not OKF adoption. It is ARD registry adoption — because the payload is worthless until the discovery layer is populated, and interesting the moment it is.

Open license is not open governance

There is a second structural question, and history tells us it is the one that actually determines whether a standard survives.

OKF is genuinely open in the ways that matter to a developer: Apache 2.0, no SDK, no account, no proprietary runtime, plain Markdown and YAML that any model from any vendor can parse. A third-party ecosystem of generators, editors and validators appeared within weeks. All real.

But “open license” and “open governance” are different animals, and our industry conflates them constantly.

Set OKF against its own siblings:

The empty cell (“None”) is the finding. OKF has no standards-body home. Google wrote it, Google controls v0.1, and the roadmap is whatever Google decides. That is not sinister but the ordinary condition of a specification eight weeks old. But it means the phrase “open standard,” applied to OKF, is doing more work than it has earned.

My formulation, offered as a diagnostic rather than a verdict: open license, not yet open governance.

Nor is the spec itself entirely settled: it says one field is required, while Google’s own reference parser is stricter; forgivable in a draft, but a reminder not to treat conformance as a guarantee of anything yet.

Three different things are being called “OKF”

Much of the current confusion comes from collapsing three distinct objects into one word.

1. OKF the format. A specification for packaging knowledge as Markdown files, published by Google Cloud, whose intended home is inside an organization, feeding internal agents.
2. The /okf/ hosting convention. Publishing a bundle at a path on a public website. This is not in the specification: Google specified a distribution format — git repo, tarball, subdirectory — and said nothing about serving bundles from a web root. The convention emerged from practitioners, and it is a sensible one, but it should be labelled as what it is: a community proposal, not a Google directive.
3. The “second layer” narrative, or OKF as one storey in a new machine-readable stack alongside llms.txt, EntityMap, ARD, WebMCP and UCP. As a conceptual map this is useful. As a practical map it is dangerous, because it renders things at wildly different levels of maturity as equal rows in a table. The fix is not to abandon the table. It is to add the column everyone leaves out:

Two rows deserve a note rather than a cell. EntityMap, introduced on Search Engine Journal, is intellectually the most semantically ambitious item on the list, and it has exactly the typed predicates OKF conspicuously lacks.

And OKF, the row this whole article is about, is the only one being widely discussed as a publishing layer while its specification describes an internal one.

These are not eight storeys of one building. They are eight construction sites at eight different stages. When a client asks which to implement, the honest answer is that last column, not an architecture diagram.

What the people actually building things have found

The most useful information in this space is coming from implementation, not analysis, and the implementers have been notably honest about what they are seeing.

Suganthan Mohanadasan built an OKF Bundle Generator: paste a URL or sitemap, and it crawls the site, strips the navigational chrome, converts each page into a conformant concept file with frontmatter and cross-links, and hands you a zip with an index.md and a log.md. He also built a WordPress plugin that serves the bundle at /okf/ and rebuilds it on publish, while being explicit that no major model currently goes looking for these bundles.

One output of that generator is being undersold, and it has nothing to do with agents. It renders your site as a graph — pages as nodes, links as edges. Orphan pages jump out. Weak clusters jump out. Content islands you did not know you had jump out. That is a legitimate internal-linking and entity-architecture audit, valuable entirely independently of whether any machine ever reads the bundle. If you take one operational thing from this article, take that: run the export as a diagnostic, not as a deliverable.

Emina Demiri-Watson’s The Web Is Growing A Second Layer – Almost A Third Head is the clearest map of this terrain anyone has drawn so far, and it arrives at several of the same conclusions I did, from a different direction. Emina refuses both camps — markdown as the future, or ignore all of it — and instead does the harder thing: she separates the layers. Crawlable HTML, schema.org, llms.txt, MCP/WebMCP, OKF, ARD, product feeds. Six or seven distinct floors, each doing a distinct job, none of them a silver bullet.

Her verdict on OKF is precise and unsentimental: it is not a retrieval system, it does not replace crawling, it was built for data teams rather than marketing sites, and — citing Francois Vanderseypen — a directed graph of markdown files is a web of documents, not a knowledge graph. She reaches the same untyped-links problem I reach through §5.3 of the spec, and the same schema.org arc I describe: these formats are most valuable early, as explicit signals, and the platforms eventually fold the lesson into the algorithm.

Where our readings sit side by side rather than on top of each other is the relationship between OKF and ARD. Emina places them as parallel efforts at different layers — OKF packaging knowledge for consumption, ARD advertising capabilities for connection — and she is right that they are different beasts. My argument is that they are also stacked: an ARD catalogue can advertise an OKF bundle among its resource types, which means the payload and the discovery layer were shipped five days apart by two different Google divisions and nobody joined them. Tellingly, she is already circling the same seam from the other side, flagging the missing media type as the thing that stops a catalogue from recognising a bundle it can otherwise list, and asking, correctly, what happens when an autonomous agent ingests and acts on something whose type it had to infer. That is the same question I end on, arrived at independently. Read her piece alongside this one: she gives you the map of the building, and I am arguing about which two floors have a lift between them.

Marie Haynes has gone, then in the other direction the Suganthan, aka not publishing outward, but building inward. She has documented building an “OKF brain”: her consulting processes, training material, research and reference documents structured as a connected bundle, with an automated pipeline that monitors changes to Google’s documentation and updates the relevant concepts when they move, so the context does not decay. On top of that sit executable playbooks: her agent reads the playbook, reads her consulting context, and drafts proposals and analyses in her own working style.

This is exactly the use case OKF was designed for, and the strongest argument in the format’s favor I have seen anywhere. It is not a publishing tactic; it is a private, compounding knowledge asset that an agent grounds on: the Karpathy’s LLM wiki with a rulebook, applied to a professional practice. And it works not because Google rewards it, but because her own agents get better when the knowledge they read is curated, cross-linked, and current instead of re-derived from a pile of PDFs on every query.

Marie also raises a genuinely provocative possibility: a market in pre-compiled expert bundles, where a lawyer, an accountant, or a search consultant packages their proprietary processes and regulatory knowledge as a conformant bundle another organization can buy and drop straight into the filesystem its agent reads. It is speculation, and she frames it as such, but speculation with a real mechanism behind it. And it leads to the one thing about that future that has not been adequately addressed.

The uncomfortable question: a bundle is an instruction set

If OKF bundles become purchasable artefacts mounted straight into the filesystems that agents read, we should think carefully about what we have built.

An OKF bundle is not data.

It is prose that an agent reads and acts upon. The playbooks are instructions. The runbooks are instructions. The citation sections point at external URLs the agent may fetch. And the conformance model requires consumers to tolerate unknown types, unknown keys, and broken links, which is to say, it requires them to be maximally credulous about content they did not author. That is, structurally, an indirect prompt-injection surface. Not hypothetically. By construction.

WebMCP’s security guidance already grapples with the equivalent problem on the browser side, which is why it ships annotation hints and warns explicitly about indirect prompt injection.

OKF, at the format level, has no security machinery at all: no authentication, no authorization, no provenance signing, no trust semantics. Not an oversight either because the spec’s non-goals decline to prescribe storage or serving infrastructure, so security lands at the serving layer. Inside Google Cloud that means IAM and VPC Service Controls once a bundle is ingested. Outside it, whatever you build.

Telling, then, that ARD carries a trust manifest, binding resources to domain identity and compliance attestations, because its authors understood that a discovery layer without a verification layer is an attack surface with a search engine bolted on.

So if the bundle economy arrives, the question is not “can my agent read this file.” It is “who wrote it, how do I know, and what happens when an instruction inside it tells my agent to do something I did not sanction?” I do not have a good answer. I am fairly confident we will need one before we need another plugin.

What I would do, in order

If you run internal agents, copilots or RAG systems over your own knowledge — and they keep getting your metric definitions, data sources or processes subtly wrong — OKF is worth a pilot this quarter.

Not a migration. A pilot. Pick the five concepts your agents get wrong most often: your two most-argued-about metrics, your core dataset, your main API, your most-run playbook. Write one file each. Point an agent at the folder. Measure whether accuracy improves. A two-day experiment with a falsifiable outcome.

If you are an SEO or AI-search consultant, do not sell OKF as a visibility tactic. It is not one; Google has said so in documentation, and the correction will be expensive for your credibility. The higher-leverage work for being found, understood and cited by machines has not changed, and is frankly a little boring: crawlable, server-rendered, semantically structured HTML; genuine schema.org markup with coherent sameAs entity resolution; consistent entity signals across the open web; original, non-commodity content a model cannot generate from thin air; and, where relevant, a real API or MCP endpoint rather than a document to scrape.

And watch four things, in this order. Not “keep an eye on the space” — these are falsifiable, and each one, if it moves, changes the advice above:

None of the four has moved yet. That is the whole answer, and it is worth more than any implementation guide written this month.

Where this fits

We have spent twenty years watching the same story tell itself in different costumes.

• From strings to things: Google stops matching text and starts resolving entities, and schema.org gives publishers a vocabulary to declare what a page is about rather than what words it contains.
• From things to answers: the Knowledge Graph and then generative retrieval make the destination the answer rather than the click.
• And now, from answers to actions: agents that do not merely tell a user something but transact, book, and execute, which is why UCP exists, why WebMCP exists, and why the discovery problem ARD is trying to solve suddenly matters.

OKF belongs to that lineage, but it answers a quieter question, which is why it is being misread. The action protocols concern what an agent can do. OKF concerns what an agent knows… and an agent that does not know your business cannot act on its behalf, however many tools you expose.

Framed that way, the assessment is not complicated. OKF is a well-designed answer to a real problem most of the SEO industry does not have, arriving in a form most of the SEO industry has mistaken for something else.

It is not a ranking lever. It is not, today, a visibility mechanism. It is a portable memory for machines, and its natural home is inside the organization, not on its public façade.

Which means the correct posture is neither the breathless one nor the dismissive one, but the one our profession is worst at maintaining and most in need of: read the specification, understand what it is for, watch the four things that would change the answer, and build the boring fundamentals in the meantime.