Will OKF Replace Your Wiki? What Google’s New Format Means for Content and Knowledge Teams

Last Thursday someone on our team dropped a link to Google’s Open Knowledge Format announcement into our chat with one line under it: “Should we move our wiki to this?” Our internal docs live in a normal team wiki, the kind everyone half-maintains and nobody fully trusts. So the question was fair. If Google just shipped a format for storing knowledge, does the wiki we have become the old way of doing things?

I spent an evening reading the spec and the early takes, and the short version is reassuring: no, OKF does not replace your wiki. It does something quieter and more interesting. Here is what it actually is, why a wiki and an OKF bundle are two different jobs, and what content and knowledge teams should do about it without falling for the hype.

First, what OKF actually is

Google Cloud announced the Open Knowledge Format (OKF) v0.1 on June 13, 2026. In Google’s own words it is “an open specification that formalizes the LLM-wiki pattern into a portable, interoperable format,” described as “a vendor-neutral, agent- and human-friendly standard for representing the metadata, context, and curated knowledge that modern AI systems need.”

Underneath the language it is simple. An OKF bundle is “a directory of markdown files with YAML frontmatter.” Each concept is one Markdown file, the files interlink like a wiki, and a small set of fields stay queryable: type, title, description, resource, tags, and timestamp. Only one field is actually required, the type field. No SDK, no runtime, no database. As Google puts it, it is “just markdown,” “just files,” and “just YAML frontmatter.” If you want the full plain-English version, we wrote a guide to Google’s Open Knowledge Format that breaks down every field.

One thing the announcement is careful about: OKF is built for AI systems and data teams, not for Google Search. The blog post never calls it a ranking signal, and you should not either. We dug into that distinction in our honest take on whether OKF matters for WordPress SEO.

What a wiki actually does

A wiki, whether it is Notion, Confluence, MediaWiki, or a pile of Google Docs, exists for people. Someone opens it, searches it, edits a page, leaves a comment, and links one note to another. It has permissions, version history, a search box, and a hundred small affordances that exist because humans are messy and need to find things fast. The wiki is a workspace.

An OKF bundle has none of that, on purpose. There is no edit button, no comment thread, no login. It is a frozen, structured snapshot of knowledge laid out so a machine can read the whole thing in one pass without guessing. The moment you understand that a wiki is a place people work and an OKF bundle is a thing a machine reads, the replacement question mostly answers itself.

So, will OKF replace your wiki? Short answer: no

OKF does not replace your wiki. It sits next to it as a second, machine-facing copy. Your team keeps writing and editing in the surface they already know, and the OKF bundle is generated from that source so an agent can consume it cleanly. Think of the wiki as the kitchen and the bundle as the plated dish you hand to a machine at the door.

The honest catch worth naming: a bundle is a second copy of knowledge you already maintain, so it only stays useful if it regenerates when the source changes. A stale bundle is worse than no bundle. And the payoff is not immediate. The technical SEO Suganthan, who has written some of the clearest material on OKF, puts the timing plainly: “A bundle will not move your rankings or your AI visibility this week.” His framing for why to bother anyway is the right one: “Schema took the best part of a decade to pay off, and I am still glad I shipped it early.” OKF is that same shape of bet, now with Google’s name on it.

Also Read: How to publish a Google OKF bundle on WordPress if you want the step-by-step on the actual /okf/ folder and frontmatter.

What this means for content and knowledge teams

If you run a content or knowledge team, here is the practical read. You do not migrate. You do not freeze your wiki and rebuild it as a folder of Markdown files by hand. You keep the wiki as the place people work, and you decide whether the knowledge inside it is worth exposing to AI agents in a clean, structured form.

For most teams the first candidates are the public-facing parts: your help docs, your product knowledge, the explainers that AI assistants already get asked about. That is the same thinking behind turning your site into an AI-readable knowledge base. OKF just gives the data-team version of that idea a shared shape. If your knowledge already lives as clean Markdown, you are most of the way there, which is why Markdown is quietly becoming the language of AI agents.

Internal-only knowledge, the HR policies and runbooks nobody outside should see, is a separate decision. OKF was designed inside Google partly for exactly that internal sharing between teams and agents, so the format fits, but exposing it on the open web is a choice you make deliberately, not a default.

Also Read: How to turn your WordPress content into an AI-readable knowledge base for the public-facing version of this same move.

The WordPress angle: one site can be both surfaces

Here is where WordPress quietly has an edge. A WordPress site can be the human knowledge base, pages and posts people read and search, and it can also serve the machine files at a path like /okf/. You own the server and the routing, so both surfaces live on one domain.

That is not true everywhere. As Suganthan notes, “on closed platforms like Wix or Squarespace you often cannot serve files at a custom path, which is the one real wall.” If your knowledge base sits on a closed builder, the OKF route is partly closed to you. On WordPress it is open. A clean block theme like Nexter Theme paired with Nexter Blocks keeps the human side fast and well-structured, and well-structured blocks export to clean Markdown far more cleanly than a pile of page-builder wrapper divs. OKF is one of four layers we cover in the 2026 AI-readiness stack for WordPress.

Where RankReady fits, and where it does not

Let me be precise about this so nobody buys the wrong thing. RankReady does not build your wiki, and it does not generate OKF bundles. There is no OKF button in it. What it does is the measurement layer that all of this is missing.

RankReady generates your llms.txt and llms-full.txt and keeps them current, adds a clean Markdown version to any post when you append .md to the URL, and outputs schema like Article, FAQPage, and HowTo. More to the point for this topic, it keeps a live AI crawler log of 31 named AI crawlers, with the timestamp and page for each fetch, plus a leaderboard of which of your own posts citation-style bots pulled in the last 30 days. So when you do expose knowledge to agents, you can see whether GPTBot, ClaudeBot, or PerplexityBot actually came and read it, instead of guessing. It is free on WordPress.org under GPL, and runs on WordPress 6.0+ with PHP 7.4+.

So, will OKF replace your wiki? No. Your wiki is for your people, and it is not going anywhere. OKF is a tidy way to hand a structured copy of that knowledge to machines, and it is a bet on a web that is increasingly read by agents before it is read by humans. Keep the wiki. If your public knowledge is worth being quoted by AI, make a machine-readable copy, and then watch the logs to see if it worked.

Suggested Reading

• What Is Google’s Open Knowledge Format (OKF)? A Plain-English Guide
• OKF vs llms.txt: Two Ways to Hand AI Your Site’s Knowledge
• How to Publish a Google OKF Bundle on WordPress
• Turn Your WordPress Content Into an AI-Readable Knowledge Base
• OKF Explained for SEOs and Marketers (Not Just Data Teams)