Open Knowledge Format (OKF): How to Add It to WordPress, Shopify, Webflow, and Squarespace

Open Knowledge Format (OKF) is a vendor-neutral standard for publishing your content as plain markdown files with YAML frontmatter, organized so AI agents can read and cite it without scraping your HTML. Google’s Cloud Data Analytics team published it in 2026, building on Andrej Karpathy’s LLM-wiki pattern. The whole spec fits on a single page.

I run an OKF bundle on this site. It’s live at /okf/ and it’s generated automatically from my posts and pages. Below is what OKF actually is, why I bothered, and how to add it to WordPress, Shopify, Webflow, or Squarespace. If you only care about your own platform, skip ahead.

Skip to your platform: WordPress · Shopify · Webflow · Squarespace

What Open Knowledge Format actually is

OKF is a format, not a platform. A bundle is a directory of markdown files. Each file is one concept: a product, a dataset, an article, a metric. Each file opens with YAML frontmatter for the structured metadata and then uses normal markdown for the body. Files reference each other with ordinary markdown links, so the bundle is a graph, not just a folder tree. That makes it a close cousin of an entity map, which describes what your site knows rather than which pages exist. An index.md in each directory lists what is there.

Here is the shape of a single concept file, straight from Google’s spec:

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
status: stable
generated:
  by: "process:warehouse-sync"
  at: 2026-05-28T14:30:00Z
---
# Schema
| Column        | Type    | Description                       |
|---------------|---------|-----------------------------------|
| order_id      | STRING  | Globally unique order identifier. |
| customer_id   | STRING  | FK to [customers](/tables/customers.md). |

# Joins
Joined with [customers](/tables/customers.md) on customer_id.

The only required key is type. Everything else (title, description, resource, tags) is optional. The v0.1 field list also included timestamp; v0.2 deprecates it in favour of generated.at, which I cover below. Existing bundles still parse, and you can add your own keys without breaking anything that reads the bundle. A whole bundle is just nested folders of these files:

sales/
├─ index.md
├─ datasets/
│  └─ orders_db.md
├─ tables/
│  ├─ orders.md
│  └─ customers.md
└─ metrics/
   └─ weekly_active_users.md

What OKF v0.2 changed: trust signals

Google shipped v0.2 in July 2026, and it’s the first update that changes how you should think about the format rather than just what you’re allowed to put in it. v0.1 answered what is this thing. v0.2 answers should I believe it.

The reason is agents. When a person writes a wiki page you know who to ask when it’s wrong. When an agent generates ten thousand pages overnight, nobody is accountable for any of them, and the next agent reading those pages has no way to tell the difference. v0.2 adds five signals to the frontmatter so it can.

Signal	Field	What it records
Provenance	sources	What the concept was built from
Trust	generated, verified	What produced it, and who confirmed it
Freshness	stale_after	The date it needs re-checking
Lifecycle	status	draft, stable, or deprecated
Attestation	Attested Computation	A sanctioned calculation, plus a way to verify it ran correctly

Nothing breaks. Every new key is optional, a v0.1 bundle is still conformant, and consumers are told not to reject a file for missing fields. The timestamp field from v0.1 is deprecated rather than removed. generated.at supersedes it, and old bundles still parse.

That has a blunt consequence if you generate a bundle from a crawler, which is how most website bundles get made. A crawler read your pages. It didn’t review them. So every concept it writes is honestly unverified, and any tool that stamps them verified is lying on your behalf. The one field automation can’t fill in is the one that matters most, and only you can fill it:

verified:
  - by: "human:your-name"
    at: 2026-07-31T09:00:00Z
stale_after: 2027-07-31

Two lines, and the concept moves from unverified to human-reviewed, the top tier. I added them across my own bundle: all 54 concepts at /okf/ now carry a verified entry naming me, a generated block recording when the content last actually changed, and a stale_after date. That last one is the honest half of the deal. A review that never expires is just a claim, so the date is what stops it becoming one. Mine are 24 months for structural pages, 12 for posts, 6 for anything about AI search, because that’s the material that rots fastest.

The same fields now ride along on the markdown version of every page, so an agent asking for a URL as markdown and an agent reading the bundle get the same provenance rather than two different stories about the same content.

Attested Computation: a check you can actually run

The fifth signal is the strangest and, I think, the most interesting. An Attested Computation is a concept that carries a calculation: the code, a runtime, an executor that produces a receipt of what it returned, and an attester: separate, deterministic code whose only job is to re-run the thing and confirm the receipt is true.

Google’s example is SQL over a data warehouse: here is the sanctioned way to compute revenue, and here is how to prove the number you were handed came from it. For a website that sounds irrelevant, and mostly it is, until you point it at the bundle itself.

So that’s what I built. Bundles from my OKF Generator now ship a conformance.md concept with two small scripts beside it. The executor counts the bundle and prints a receipt:

$ node checks/conformance.mjs .
{
  "concepts": 36,
  "conformant": 36,
  "with_generated": 36,
  "with_sources": 35,
  "unverified": 36,
  "machine_confirmed": 0,
  "human_reviewed": 0
}

And the attester re-derives every field and exits non-zero if any of them is wrong:

$ node checks/attest.mjs . receipt.json
ATTESTED — receipt matches the bundle.

No network, no service, no model in the loop. That’s what separates an attester from a second opinion. The practical effect is that a bundle can now make a claim about itself that someone else can check. Hand it to a client, a compliance reviewer, or another agent, and they can confirm the trust numbers rather than take your word for them. Inflate human_reviewed in the receipt and the attester fails on exactly that field.

I know it works because it caught me. The first real bundle I generated failed its own attestation: the receipt claimed 35 concepts, the executor counted 36. conformance.md is itself a concept, so the check counted it and the receipt, written a step earlier, didn’t. A wrong number I’d never have found by reading the code, surfaced in about ten seconds by running it. That’s the whole argument for shipping the verifier rather than just asserting the result.

Why I bothered

Agents are starting to sit between your content and the person asking the question. When an agent reads a normal site, it scrapes HTML, strips the layout, and loses the structure: which page is canonical, how your pages relate, what each thing actually is. An OKF bundle hands the agent that structure directly. The frontmatter says what a thing is. The markdown links say how it connects to the rest of your knowledge. That’s the part scraping can’t reconstruct.

This is the same shift I write about in LLM SEO and AEO content strategy: the work moves from being found by a search engine to being usable by an agent. OKF is the file-level version of that idea, and it pairs naturally with the AI-citation work in my answer engine optimization program. It won’t show up in your analytics next month. It compounds, the way structured data did. The same bundle also feeds my AI information page, the plain-language identity doc agents read alongside it.

How to add OKF to your CMS

Because a bundle is just files, the job on every platform is the same in principle: produce the markdown files, then host them where an agent can fetch them.

Start in the same place whichever platform you’re on. Run your domain through my free OKF Generator and you get the bundle back as a ZIP: one concept file per page, an index.md, an llms.txt, and the conformance check described above. It takes a minute, costs nothing, and you’ll see exactly what an agent would get before you change anything on your site. After that the platforms differ in only two ways: where the files go, and whether anything keeps them current.

Platform	Native OKF support	How you ship it
WordPress	Yes (plugin)	Generator for a one-off bundle, or a plugin that rebuilds on every publish
Shopify	No	Generator, then upload the files to a subdomain you control
Webflow	No	Generator, or script the CMS API if you want automatic rebuilds
Squarespace	No	Generator, then host externally; Squarespace can’t serve the files itself

WordPress

WordPress is the one platform where you have a real choice, and it comes down to whether the bundle maintains itself. The generator gives you one in a minute, which is the fastest way to see what yours looks like, but it’s a snapshot: publish a post and it’s out of date until you run it again. A plugin rebuilds on every publish instead.

Install the OKF for WordPress plugin, point it at the post types you want included, and it generates a bundle from your published content and serves it at /okf/. That’s where I started; I’ve since replaced it with my own build so I could emit the v0.2 trust fields covered above, but for most sites the plugin is the shortest path to a bundle that stays current. Mine is live at toddmorourke.com/okf/, served as text/markdown, with every post and page turned into a concept file and an index listing them all. You maintain nothing by hand: publish a post, and it appears in the bundle.

• Run your domain through the OKF Generator first if you want to see the output before installing anything.
• Install and activate the OKF for WordPress plugin.
• Choose which post types and taxonomies to include.
• Load /okf/ and confirm it returns markdown with frontmatter.
• Add a line to your llms.txt pointing at the bundle so agents can find it.

Shopify

Shopify has no OKF plugin, and it won’t serve a directory of .md files from your theme. So you generate the bundle and host it. The generator handles the first half: point it at your storefront and it crawls your sitemap, converts every page, and hands back the files ready to upload. If you want richer product data than a page crawl can see, pull the catalog through the Admin API instead and write the files yourself. Either way your highest-value concepts are products and collections: one markdown file per product, with frontmatter describing it.

---
type: Product
title: Trail Runner GTX
description: Waterproof trail running shoe, Vibram outsole.
resource: https://store.com/products/trail-runner-gtx
tags: [footwear, trail]
status: stable
generated:
  by: "process:catalog-export"
  at: 2026-06-20T00:00:00Z
---
# Details
Drop: 8mm. Weight: 295g. Sizes 7 to 13.
Pairs with [merino socks](/products/merino-socks.md).

• Run your store domain through the OKF Generator for a complete bundle in one pass, or pull your catalog and blog through the Shopify Admin API if you want structured product fields.
• Write one OKF file per product, collection, and article, with cross-links between related items.
• Host the bundle on a subdomain you control (GitHub Pages, Netlify, or Cloudflare Pages all serve static files for free), for example okf.yourstore.com.
• Reference that subdomain from your llms.txt and footer. Regenerate on a schedule so it stays current.

Webflow

Same story as Shopify: no plugin, and Webflow won’t serve raw markdown trees. Run the site through the generator and you have a bundle immediately. The advantage Webflow has is that your content already lives in CMS Collections, which the Webflow API exposes cleanly, so if you want the bundle to rebuild itself the export is scriptable. Map each Collection to a type (an articles collection becomes type: Article, a products collection becomes type: Product) and write one file per item.

• Generate a bundle from the live site with the OKF Generator, or read your Collections through the Webflow CMS API if you want it automated.
• Convert each item to an OKF file, keeping the type aligned to its Collection and linking related items.
• Host the bundle on a subdomain and point your llms.txt at it.
• Trigger a rebuild from a Webflow publish webhook so the bundle tracks your site.

Squarespace

Squarespace is the most closed of the four. You can’t serve a file directory or custom file types from Squarespace itself, so the bundle has to live somewhere else. Generate it from your content with the OKF Generator, host it externally on a subdomain, and reference it. If you’re committed to Squarespace and serious about agent-readiness, this is the platform most likely to push you toward an external static host, which is fine: OKF was designed to be hosted anywhere.

• Run your domain through the OKF Generator, or export your pages, blog posts, and products by hand (the Squarespace API or a content export).
• Convert each to an OKF concept file with frontmatter and cross-links.
• Host the bundle on a subdomain and link it from llms.txt.

How I use OKF in my Claude Code brain

The bundle at /okf/ is the outward-facing half: my site, packaged for agents. The inward-facing half is how I run the actual consulting work. My workspace is a set of OKF bundles that my own agents read: one for brand and business context, one for SEO data like keyword research and audits, one for research notes pulled from newsletters and videos. The format is identical to what I publish, which is the point.

Every concept is one markdown file. Every file carries frontmatter, links to at least one related file, and gets a line in its directory’s index.md plus a dated entry in a log.md. A real one looks like this:

---
type: reference
title: URL Inventory and Internal Link Map
description: Every live URL grouped by theme, with each theme's internal-link target.
tags: [internal-links, site-structure]
status: stable
generated:
  by: "human:todd-orourke"
  at: 2026-06-20T00:00:00Z
verified:
  - by: "human:todd-orourke"
    at: 2026-06-20T00:00:00Z
---
# Targets
Link AEO posts to [AI Search](./services/ai-search.md).
Link technical posts to [Technical SEO](./services/technical.md).

The reason this works is the reason OKF works at all. Karpathy’s observation was that LLMs don’t get bored, don’t forget to update a cross-reference, and can touch fifteen files in one pass. The bookkeeping that makes humans abandon a personal wiki is exactly what an agent is good at. When I ask my brain a question, the agent walks the bundle and follows the links instead of re-reading raw documents every time. I wrote about the full setup in how I built an AI second brain.

Should you do this yet

Straight answer: it won’t change your traffic this quarter, and skipping it causes no immediate problem. The case for doing it now is that it’s cheap and the downside is capped. On WordPress it’s a plugin install. Everywhere else, it’s a generate-and-host job you automate once and forget. If you think agents will keep moving between your content and your buyers, an agent-readable copy of your knowledge is worth a little more every month. If you’re wrong, you lose an afternoon. I made the bet on my own site, and the bundle has been running quietly at /okf/ since.

FAQs

What changed in OKF v0.2?

v0.2 added five trust signals to the frontmatter: sources (provenance), generated and verified (what produced a concept and who confirmed it), stale_after (freshness), status (lifecycle), and a new Attested Computation concept type. Nothing breaks. Every field is optional and v0.1 bundles remain valid. The timestamp field is deprecated in favour of generated.at. The meaningful change is that the absence of a trust signal now carries information: a concept with no verified entry reads as unverified rather than neutral.

Do I need to add a verified field to my OKF bundle?

Only you can. Any tool that generates a bundle by crawling your site has read your pages, not reviewed them, so it can’t honestly emit verified, and one that does is making a claim on your behalf. Once you have actually checked a concept, add a verified entry naming yourself and a stale_after date, and it moves to the human-reviewed tier. It’s two lines, and it’s the only part of the bundle automation can’t write for you.

What is the Open Knowledge Format?

OKF is a vendor-neutral standard for representing knowledge as plain markdown files with YAML frontmatter, created by Google’s Cloud Data Analytics team. A bundle is a directory of these files, one per concept, cross-linked with markdown links. The only required frontmatter field is type.

Is OKF the same as llms.txt?

No. An llms.txt is a single file that points agents to your important URLs. OKF is a structured bundle of many markdown files, one per concept, linked into a graph. They’re complementary, and I run both: the llms.txt points at the OKF bundle.

Does OKF help SEO or rankings?

Not directly, and not today. OKF is a machine-readability layer for AI agents, not a Google ranking factor. The payoff is agent-driven discovery and citation, which is a slower, compounding return, similar to how schema markup paid off over years rather than weeks.

Do I still need schema markup if I publish OKF?

Yes. Schema markup describes entities inside your HTML for search engines. OKF publishes your knowledge as standalone files for agents. They cover different surfaces, and both are worth doing.

Who created OKF and when?

Google’s Cloud Data Analytics team, with tech leads Sam McVeety and Amir Hormati, published OKF v0.1 in 2026, and followed it with v0.2 in July. It formalizes the LLM-wiki pattern described by Andrej Karpathy into a portable, open specification.

Sources

• Google Cloud – OKF v0.2 adds trust signals
• GitHub – Open Knowledge Format specification (SPEC.md)
• Search Engine Journal – Google’s Open Knowledge Format Adds Five Trust Signals
• LangChain – OpenWiki 0.2 brings OKF to codebase documentation
• Google Cloud – How the Open Knowledge Format can improve data sharing
• Google Cloud – Introducing the Google Cloud Knowledge Catalog
• GitHub – Google Cloud Platform Knowledge Catalog (OKF)
• Suganthan Mohanadasan – Open Knowledge Format
• Marie Haynes – OKF