Open Knowledge Format (OKF) for Websites: The Practical Playbook for AI-Readable Knowledge Graphs
Google’s Open Knowledge Format (OKF) hints at a more agent-friendly web: your site as a traversable graph of concepts, not a pile of pages. Here’s what changed, why it matters, what to build, what can break, and how SMEs can execute safely with an approval-first system.
AI didn’t “replace search.” It replaced the interface to search for a growing share of customers. People now ask questions in chat, in AI answer boxes, and in agent-like experiences that try to decide for them. That creates a brutal new requirement for every website: your business has to be understandable not only as a set of pages, but as a body of knowledge.
Google’s Open Knowledge Format (OKF) is a simple file-based way to represent knowledge as linked markdown documents with a thin metadata layer. It was designed for internal company knowledge—but it accidentally exposes something the public web has struggled with for years: machines can extract facts from pages, but they often miss how ideas relate to each other. Relationships are where meaning lives.
Based on reporting and experimentation covered by Search Engine Journal (Google’s Open Knowledge Format Could Work For Websites, Too), I want to go beyond the news and turn this into an operator-grade editorial: what changed, why it matters, what can go wrong, and what SMEs and agencies should do next—without pretending OKF is already a “standard” you must adopt.
Concise Summary
- OKF is a pattern: a folder of markdown files (one per concept) with YAML frontmatter plus links between concepts—forming a traversable graph.
- The big shift: AI systems don’t experience your site the way humans do. They often “see” a flat set of pages. A concept graph exposes meaning through relationships: what depends on what, what applies where, what’s primary vs. supporting.
- The opportunity: whether or not OKF becomes common for websites, the discipline of modeling your knowledge will make your site clearer, easier to maintain, and more resilient in AI-driven discovery.
- The danger: any parallel machine-readable layer creates a synchronization tax. If it drifts, you publish a polished, authoritative-looking version of wrong information.
- Where AYSA fits: this is fundamentally a Monitoring + execution problem. AYSA is built to monitor changes and drift, prepare improvements, ask for approval, and execute accepted changes—turning “AI readiness” from a deck into shipped work.
Key Takeaways (For Busy Business Owners)
- Stop thinking in “pages” only. Start thinking in concepts (products, services, policies, definitions, locations, eligibility rules) and the relationships between them.
- AI mistakes are rarely about one page. They’re usually about contradictions across the site or missing relationship clarity (what applies, to whom, where, and under what conditions).
- OKF is useful even if nobody reads it. It forces you to define your knowledge and relationships explicitly; that process alone surfaces gaps.
- Execution is the moat. The winners won’t be the teams with the prettiest schema. They’ll be the teams that keep “truth” updated across pages, Structured data, Internal linking, and citations.
Table Of Contents
- What Changed: From “Pages” To “Concepts” (And Why That’s A Big Deal)
- OKF In Plain English: “Just Markdown” With A Relationship Layer
- Why This Matters Now: AI Answers Need Relationships, Not Just Content
- The Hidden Problem: Your Website’s Meaning Collapses In Plain Text
- Knowledge Graph Thinking For SMEs (No PhD Required)
- OKF vs. Schema Markup: Complementary, Not Competing
- A Concrete SME Scenario: Multi-Location Service Business With “Wrong Answers” Everywhere
- A Second Scenario: Ecommerce Where Policies And Availability Drive Returns
- What Agencies Should Rethink: Deliverables That Ship, Not Audits That Die
- Implementation Blueprint: Inventory → Canonical Truth → Relationship Links → Governance
- A Practical Relationship Language You Can Use Today (Even Without OKF)
- Should You Publish An OKF Bundle Publicly? A Sane Decision Framework
- The Execution Problem: Parallel Truth Layers Rot Without Governance
- What SMEs Should Monitor Weekly (So AI Doesn’t Drift From Reality)
- The AYSA POV: Monitoring + Approved Execution Is The Only Scalable Path
- What To Do Next (Action List)
- Sources And Further Reading
What Changed: From “Pages” To “Concepts” (And Why That’s A Big Deal)
Traditional SEO trained the market to think: “If we publish the right page and optimize the right keywords, we win.” That’s still partially true. But AI-driven discovery changes how meaning is assembled.
When a customer asks an AI system a question like:
- “Is this clinic open on Saturdays?”
- “Does this brand offer returns on clearance items?”
- “What’s the difference between plan A and plan B?”
- “Which contractor can handle X in my zip code this week?”
…the system isn’t “reading your homepage.” It’s synthesizing an answer from fragments across sources and pages. And in many cases, the reason it gets it wrong is simple: your site doesn’t state relationships cleanly.
Humans infer relationships from design and context. Machines often don’t. Breadcrumbs, sidebars, navigation labels—these are weak signals for an agent that’s extracting text or consuming partial renders. As a result, your site’s knowledge becomes a pile of sentences, not a coherent model.
OKF (and the broader “machine-first” momentum around plain text formats) is a signal that the industry is searching for a missing layer: a cheap way to publish the structure of knowledge, not just the words.
OKF In Plain English: “Just Markdown” With A Relationship Layer
OKF—Open Knowledge Format—was introduced by Google’s data team as a format for representing a body of knowledge as a directory of markdown files, each with lightweight YAML frontmatter and links between documents. Search Engine Journal’s coverage explains the essential pieces and why it could matter for websites even though it was created for internal documentation (SEJ article).
Stripped down, OKF is:
- A folder (a bundle) of files
- One concept per markdown file
- YAML frontmatter at the top for queryable metadata (type/title/description/tags/timestamp/resource)
- Normal markdown content underneath
- Links between concepts using standard markdown links, creating a graph
The reason this matters is not because “YAML is magic.” It’s because OKF treats knowledge like a set of connected nodes instead of pages in a navigation tree. For machines, those are not the same thing.
There’s also a cultural detail hiding in plain sight: OKF is intentionally low ceremony. “Just files.” That’s the same reason markdown became the default language of documentation and developer communities. You don’t need a proprietary platform. You can version it, diff it, audit it, and deploy it like code.
Why This Matters Now: AI Answers Need Relationships, Not Just Content
AI Search experiences reward sites that are:
- Consistent (the same policy doesn’t change wording across ten pages)
- Unambiguous (eligibility rules are explicit and not hidden in marketing copy)
- Well-structured (definitions exist; canonical pages exist; key entities are clearly described)
- Relationship-rich (what depends on what; what applies where; what is included vs excluded)
Most SEO teams focus heavily on the first three. The fourth—relationships—is where many sites fail, especially SMEs with fast-changing operations.
Here’s a simple example: a hotel chain might have “Late checkout” mentioned on a dozen pages. But the real knowledge is relational:
- Late checkout is available at some properties
- Late checkout applies to certain room types
- Late checkout depends on availability
- Late checkout is included for members but paid for non-members
If the site doesn’t model those relationships, AI will improvise. And improvisation becomes “confidently wrong.”
OKF is a concrete reminder: the future of visibility is not only writing better pages—it’s publishing your business as a coherent knowledge system.
The Hidden Problem: Your Website’s Meaning Collapses In Plain Text
If you want a quick sanity check, do this: copy the text of your most important page into a plain-text editor. No styling. No layout. Links become just words. Navigation becomes noise. Now ask:
- Does the page still communicate what this concept is?
- Does it state what it depends on or what depends on it?
- Does it clearly link to the canonical definition or policy it references?
- Is it clear what applies universally vs. what applies only in certain cases?
For many sites, the answer is “no.” Not because the business is unclear—but because the web page is doing too many jobs at once: marketing persuasion, lead capture, navigation, SEO, and legal disclaimers. The underlying knowledge gets diluted.
This is why “markdown mirrors” and “machine-readable layers” keep coming up across the industry: not because everyone loves plain text, but because plain text makes structure and contradictions obvious.
Knowledge Graph Thinking For SMEs (No PhD Required)
The phrase “Knowledge graph” scares people because it sounds like enterprise data engineering. But for most SMEs, the goal isn’t to build a global ontology. The goal is to stop losing money because your business facts are inconsistent across the web.
Think of your website knowledge as a set of stable concepts that should not be reinvented in every new blog post or Landing page:
- Offerings: primary services, service packages, product categories
- Policies: shipping, returns, cancellation, warranties, refund rules
- Eligibility rules: who qualifies, requirements, limitations
- Locations: addresses, hours, service areas, appointment rules
- Definitions: your terminology, acronyms, branded names
- Proof: certifications, standards, processes, guarantees
A knowledge graph mindset is simply: each of these concepts should have a canonical home and be referenced consistently. Relationships should be explicit:
- “This warranty applies to these categories.”
- “This service is only available in these locations.”
- “This policy overrides that policy for clearance items.”
- “This plan includes these features; this other plan excludes them.”
OKF is one formal way to store that model. But the model itself is the real work.
OKF vs. Schema Markup: Complementary, Not Competing
Schema markup helps search engines interpret page elements using a shared vocabulary. It’s essential for many use cases. But schema is not designed to express the full logic of your business knowledge across pages.
In practice:
- Schema answers “what is this page about?” (Product, Organization, LocalBusiness, FAQ, etc.)
- A concept graph answers “how do these concepts relate?” (depends-on, applies-to, part-of, defined-by, overrides, etc.)
You can do schema perfectly and still have an AI assistant misunderstand you because the relationships are only implied in prose—or scattered across a dozen pages with slightly different wording.
My editorial stance: if you’re choosing between schema and knowledge modeling, you’re asking the wrong question. Do both, but start with the fundamentals:
- Canonical truth pages
- Clear definitions
- Explicit relationship linking
- Governance that keeps it updated
A Concrete SME Scenario: Multi-Location Service Business With “Wrong Answers” Everywhere
Let’s use a scenario I see constantly in the market: a multi-location service business—clinic, home services, fitness studios, or specialty retail.
They typically have:
- Multiple locations with different hours
- Different services offered per location
- Different pricing ranges or promotions
- Different eligibility rules (insurance accepted, age limits, service area radius)
Here’s what happens in the real world:
- A location changes hours. The GBP listing is updated, but the website location page is not.
- A promotion ends. The blog post remains indexed and still mentions it, with no clear end date.
- A new service launches, but only at two locations. The service page sounds universal.
Now an AI system tries to answer: “Does this business offer X near me?” It scrapes fragments and builds a response. If your site doesn’t explicitly model the relationships, the system will guess:
- It may treat a universal statement as universal even if it’s only true for one location.
- It may combine details from two locations into one incorrect “average” answer.
- It may cite an outdated promo as current because the relationship to time (valid-through) is unclear.
The fix is not “write more content.” The fix is to build canonical concept nodes:
- A concept page for each location (address, hours, service list, constraints)
- A concept page for each service (definition, prerequisites, where available)
- A concept page for each policy (cancellation, refunds, eligibility)
Then link them with intent: “Service X is offered at Locations A and B.” “Policy Y applies to Service X.” That’s graph thinking.
A Second Scenario: Ecommerce Where Policies And Availability Drive Returns
Ecommerce isn’t just product pages. The real margin killers are policies and exceptions: shipping thresholds, return windows, warranty terms, subscription rules, international restrictions.
AI-driven shopping experiences and assistants increasingly answer questions like:
- “Can I return this if I opened it?”
- “Does this ship to my country?”
- “Is this compatible with X?”
- “What’s the difference between these two models?”
These are not “keyword pages.” These are relationships between product, policy, and context.
Common failure modes on ecommerce sites:
- Return policy exists, but category exceptions are scattered in FAQs or product descriptions.
- Shipping policy exists, but hazardous items or oversized items have special rules not modeled consistently.
- Compatibility is described in blog posts and support docs, but not structured as a concept relationship.
OKF-style modeling would encourage you to create stable, linkable concepts:
- Return policy (canonical)
- Return exceptions (concepts by category)
- Shipping restrictions (concepts by item type)
- Compatibility definitions (concepts for device models or standards)
Even if you never publish an OKF bundle, building this model helps you fix the site’s internal linking, consolidate contradictory policy statements, and reduce the chance of AI answers “hallucinating” the wrong policy for the wrong product.
What Agencies Should Rethink: Deliverables That Ship, Not Audits That Die
Agencies are facing an uncomfortable truth: “SEO strategy” without execution is getting commoditized. In AI search, shipping matters more than slides because accuracy and consistency are operational, not theoretical.
If you’re an agency, OKF’s real lesson is not “sell OKF.” It’s “sell the work that makes machine understanding reliable.” That means shifting deliverables away from one-time audits and toward ongoing knowledge maintenance:
- Concept inventory & canonicalization plan (what concepts exist, where they live, what is duplicated)
- Relationship map (what depends on what; what applies where)
- Content governance (who can publish policy changes; how to deprecate old promos)
- Execution cadence (weekly fixes, monthly reviews, quarterly deep audits)
The agencies that win will look more like product teams: tight loops, fast shipping, measurable outcomes. The ones that lose will keep delivering “recommendations” that never get implemented.
Implementation Blueprint: Inventory → Canonical Truth → Relationship Links → Governance
If you want a practical plan that doesn’t require betting the farm on OKF, here’s the blueprint I’d recommend to most SMEs and agencies.
Step 1: Build a concept inventory (not a keyword list)
A keyword list describes how people search. A concept inventory describes what must be true for your business to be represented accurately.
Start with 25–50 concepts (most SMEs can do this in a week). Example buckets:
- Offerings: top services, top product categories, plans
- Policies: shipping, returns, cancellation, warranties, guarantees
- Constraints: service areas, eligibility, prerequisites
- Locations: each location as a concept with stable facts
- Definitions: terms customers misunderstand or that you use uniquely
Step 2: Choose canonical URLs for each concept
If the concept matters, it needs a canonical home. Many SMEs fail here because the same concept is expressed across:
- sales pages
- blog posts
- PDFs
- help center articles
Decide: where is the source of truth? Everything else should link to that canonical page, not re-interpret it.
Step 3: Add relationship clarity via internal linking and page structure
This is where most “AI content” programs fail. They add words, not relationships.
Add explicit relationship sections on key pages:
- “Applies to”: list which locations/services/products are covered
- “Depends on / Requirements”: prerequisites, eligibility
- “Exceptions”: the edge cases that cause AI confusion
- “Related definitions”: link to canonical definitions instead of repeating them
Write these sections for humans and machines. Simple language beats clever copy.
Step 4: Use structured data where it cleanly applies
Schema markup remains important, but keep it honest. Don’t add structured data that implies certainty you don’t have (for example, marking up “FAQ” with answers that change by location without reflecting that nuance on the page).
Step 5: (Optional) Model the same concepts as an internal OKF-style bundle
This is the best “low risk” way to use OKF thinking: treat it as an internal modeling tool first. A private repository of markdown concept files forces clarity and gives you:
- version control (what changed, when)
- auditable diffs
- a clean map of relationships
If you later publish it, you do so with discipline.
A Practical Relationship Language You Can Use Today (Even Without OKF)
You don’t need an ontology project. You need a small set of relationship types you use consistently across your site and content operations.
For SMEs, I recommend picking 5–7 relationship patterns and using them everywhere:
- Is-a: “X is a type of Y.” (Service tiers, product types)
- Part-of: “X is part of Y.” (Locations within a region, modules within a program)
- Applies-to: “This policy applies to these items/locations.”
- Depends-on: “This requires that.” (Eligibility, prerequisites)
- Defined-by: “This term is defined here.”
- Overrides: “This exception overrides the general policy.”
- Valid-through: “This is true until date X.” (Promos, seasonal availability)
In a website context, you express these relationships with:
- clear headings
- short declarative sentences
- consistent internal links to canonical concept pages
The goal is not to “sound smart.” The goal is to be un-misunderstandable.
Should You Publish An OKF Bundle Publicly? A Sane Decision Framework
The SEJ piece notes OKF was created for internal knowledge; public websites adopting it is effectively “off-label.” That matters. If nobody consumes it, publishing it won’t directly change visibility tomorrow.
So when should you publish an OKF-like bundle publicly?
You may consider publishing if:
- You have a large body of definitions/policies/technical docs that people (and machines) routinely misinterpret.
- You already have good governance and versioning discipline (or you’re willing to adopt it).
- You can commit to keeping it updated the moment the business changes.
- You treat it as a product surface, not an SEO hack.
You should not publish yet if:
- Your site already struggles with basic consistency (duplicate policy statements, outdated promos, conflicting location info).
- You don’t have an owner for “truth maintenance.”
- You can’t guarantee updates within days of operational changes.
My take: most SMEs should start with the model and the governance, not the public bundle. You can get 80% of the benefit by building canonical concept pages and relationship-rich internal links, then maintaining them aggressively.
The Execution Problem: Parallel Truth Layers Rot Without Governance
Any parallel representation of your site—OKF bundle, markdown mirror, even a simple “AI-friendly facts” file—creates a new problem: synchronization.
If your machine-readable layer says one thing and your human pages say another, which one should an AI believe?
And here’s the uncomfortable part: AI systems tend to treat structured, cleanly packaged information as more authoritative than messy marketing pages. If your structured layer is wrong, you’ve amplified the wrongness.
Minimum governance you need (non-negotiable)
- Ownership: one accountable owner (a person, not a committee)
- Update triggers: define what business changes require updates (hours, pricing ranges, eligibility, inventory constraints, promotions)
- Review cadence: weekly checks for high-risk concepts; monthly audits for the rest
- Approval workflow: changes proposed, reviewed, approved, published
- Deprecation policy: how you retire old promos and outdated pages so they stop being “true” by default
This is exactly why I keep hammering the same point in the AI era: the advantage will not come from “one more technical trick.” It will come from teams that can ship truth consistently.
What SMEs Should Monitor Weekly (So AI Doesn’t Drift From Reality)
You don’t need to monitor “everything AI says about you.” You need to monitor what costs you money when it’s wrong.
1) Business-critical facts
- hours, holiday closures
- address/phone changes
- service areas
- eligibility and prerequisites
- pricing language (“starting at” ranges, minimums)
- shipping timelines and return windows
2) Business meaning
- category/positioning: what you are and what you are not
- definitions of proprietary terms
- plan comparisons and what’s included/excluded
3) Visibility across AI-driven surfaces
Rankings still matter, but they don’t fully capture how you’re represented in AI answers. This is why we built AYSA around AI visibility and operational monitoring:
- AI search visibility (how you show up when answers are generated, not just when pages are listed)
- Monitoring (detect drift, inconsistencies, and high-risk changes)
- AI SEO tools (practical execution for AEO/GEO, not theory)
The operational mindset: treat wrong answers like bugs. If a wrong answer can cost you a call, a booking, or a return, it deserves a ticket and a fix.
The AYSA POV: Monitoring + Approved Execution Is The Only Scalable Path
From the AYSA.ai perspective, OKF is interesting—but it’s not the point. The point is the direction of travel: websites becoming machine-traversable knowledge systems, not just page collections.
That direction creates a new requirement: approved execution at scale. Because knowledge changes constantly:
- a policy changes
- a location’s hours change
- a service becomes unavailable in a region
- a product line is discontinued
If you can’t ship updates quickly and consistently, AI systems will continue to assemble answers from whatever fragments they find—including old ones.
AYSA’s model is intentionally pragmatic:
- Monitor your critical facts and surfaces (Monitoring).
- Prepare proposed improvements (content, internal links, structured data where appropriate) using practical workflows (AI SEO tools).
- Ask for approval before changes go live (because SMEs need control; mistakes are expensive).
- Execute accepted website changes so strategy turns into shipped reality—repeatedly, not once.
If you want to see how we think about this space, start with:
And here’s the blunt editorial point: the businesses that win in AI search will not be the ones that “add OKF.” They will be the ones that operationalize truth—through monitoring, governance, and execution.
What To Do Next (Action List)
- Create a concept inventory of the top 25–50 concepts customers must understand correctly (services/products/policies/locations/eligibility/definitions).
- Assign canonical URLs to those concepts (one source of truth each). Consolidate duplicates.
- Add relationship clarity to your pages using consistent sections: Applies to, Depends on, Exceptions, Defined by.
- Strengthen internal linking to reflect relationships (not “read more,” but “this applies to that,” “requires,” “defined here”).
- Clean up contradiction hotspots: promos, location hours, pricing language, returns/cancellation rules.
- Implement governance: owner, update triggers, review cadence, approval workflow, deprecation policy.
- Optionally prototype an OKF-style bundle internally to force clarity and make relationships auditable.
- Set up monitoring for your most expensive-to-be-wrong facts and surfaces (AYSA Monitoring), and adopt an approval-first execution loop for fixes.
Sources And Further Reading
- Search Engine Journal: Google’s Open Knowledge Format Could Work For Websites, Too
- Search Engine Journal
- AYSA: AI Search Visibility
- AYSA: AI SEO Tools
- AYSA: Monitoring
- AYSA: Pricing
- AYSA: Blog
Important sourcing note: The provided research context includes Search Engine Journal’s coverage and summary details about OKF’s structure and intent. It does not include the primary OKF specification link or other official documentation. For that reason, I’ve treated OKF here as a directional pattern and avoided claims that require verifying details beyond the SEJ reporting.
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
