Najważniejsze wnioski w pigułce
Czym jest OKF:
- Open Knowledge Format to specyfikacja opisująca strukturę folderów z plikami Markdown
- Każdy plik reprezentuje jedną „koncepcję" — tabelę, metrykę, proces czy dokument
- Format zaprojektowano z myślą o agentach AI w przedsiębiorstwach, nie o wyszukiwarkach
- Umożliwia przenoszenie wiedzy między narzędziami bez zamknięcia w ekosystemie dostawcy
Dlaczego to nie jest nowy standard SEO:
- Google Search nie wykorzystuje plików OKF do rankingu ani widoczności
- Specyfikacja została opublikowana przez Google Cloud, nie przez Search Central
- Dokumentacja Google jasno stwierdza, że wyszukiwarka nie używa takich formatów
- Docelowa grupa to inżynierowie danych i zespoły wewnętrzne, nie właściciele stron
Co to oznacza praktycznie:
- OKF standardizuje strukturę, ale nie semantykę — dwa zgodne bundle mogą używać zupełnie różnych nazw dla tych samych rzeczy
- Format rezygnuje z precyzji semantic web na rzecz prostoty implementacji
- Linki między koncepcjami nie mają typów — znaczenie relacji zawarte jest w otaczającym tekście
- Inne agenty AI (ChatGPT, Claude, Perplexity) mogą wykorzystać OKF, jeśli wystawisz taką strukturę
Strategiczne pytania:
- Czy twoja organizacja potrzebuje portable’owej struktury wiedzy dla wewnętrznych agentów?
- Czy twoi konkurenci są zamknięci w proprietary katalogach, które OKF mógłby otworzyć?
- Czy wartość leży w przygotowaniu się na świat, gdzie agenty będą konsumować twoją wiedzę?
Mniej więcej co osiemnaście miesięcy web urasta o kolejną warstwę czytelną maszynowo, a branża odgrywa ten sam rytuał. Ktoś publikuje specyfikację. Ktoś inny pisze „to wszystko zmienia". Trzecia osoba tworzy generator. W ciągu dwóch tygodni mamy wtyczkę, debatę na LinkedIn i konsultantów sprzedających pakiety implementacyjne standardu, którego w tym momencie nic na ziemi jeszcze nie czyta.
Przeszliśmy przez to z rel=author, z AMP, a najbardziej pouczająco — z llms.txt.
Gdy 12 czerwca 2026 roku Google Cloud opublikował Open Knowledge Format (OKF), odruch był przewidywalny. Nowa otwarta specyfikacja od Google, pojawiająca się w środku gorączki agentowej, opisana językiem zaprojektowanym tak, by uruchomić każdy nerw technicznego SEO: przenośny, interoperacyjny, niezależny od dostawcy, wiedza, graf.
To, co następuje, to próba zrobienia czegoś, w czym nasza branża jest chronicznieZŁA: przeczytanie źródła pierwotnego, zidentyfikowanie tego, co tak naprawdę mówi, zidentyfikowanie tego, czego celowo nie mówi, i zadanie pytania „dlaczego to istnieje?" zanim zapytamy „jak to optymalizować?".
Krótka wersja: OKF to rzeczywista i dobrze zaprojektowana rzecz, ale prawie na pewno nie jest tym, za co uznaje go większość branży SEO. A prawdziwie interesujące pytanie dotyczy czegoś, o co prawie nikt nie pyta.
Czym OKF naprawdę jest — ze specyfikacją otwartą przed nami
Specyfikacja OKF v0.1 znajduje się w repozytorium GoogleCloudPlatform/knowledge-catalog na licencji Apache 2.0. Ma około 450 linii i możesz przeczytać całość w piętnaście minut — co gorąco polecam każdemu, kto formułuje opinię na temat OKF, ponieważ większość krążących komentarzy to parafraza parafraz z drugiej ręki.
Knowledge bundle to drzewo katalogów z plikami Markdown. Jednostka dystrybucji, przesyłana jako repozytorium Git (zalecane), tarball, zip lub podkatalog większego repo.
Concept to jedna jednostka wiedzy, reprezentowana jako dokładnie jeden plik Markdown. Może opisywać coś namacalnego (tabela, endpoint API) lub abstrakcyjnego (metryka, proces, runbook). Jego ID to po prostu ścieżka pliku minus przyrostek .md: tables/orders.md to tables/orders. System plików jest schematem identyfikatorów. Żadnych IRI, żadnych mintowanych URI, żadnego rejestru.
Każdy plik zawiera nagłówek YAML (frontmatter) i ciało w Markdown. Dokładnie jedno pole jest wymagane: type — czyli string tekstowy taki jak BigQuery Table, Metric, Playbook. Wartości type nie są celowo rejestrowane centralnie, a konsumenci muszą gracefully tolerować nieznane typy. Pięć kolejnych jest zalecanych (title, description, resource, tags, timestamp). Producenci mogą dodawać dowolne klucze, a konsumenci nie mogą odrzucać dokumentów za posiadanie pól, których nie rozpoznają.
Dwie nazwy plików są zarezerwowane: index.md — katalog listingowy umożliwiający tzw. progressive disclosure, oraz log.md — chronologiczna historia zmian.
Koncepcje linkują do siebie zwykłymi linkami Markdown. Zalecana forma to absolutne linki relatywne do bundle’a, zaczynające się od /, bo przetrwają przeniesienie pliku.
A potem, w §5.3, następuje zdanie, na którym opiera się cała strategiczna ocena: link od koncepcji A do koncepcji B oznacza relację, ale rodzaj relacji jest przekazany przez otaczającą prozę, nie przez sam link.
Zatrzymaj się na tym. To cały argument.
Zgodność (§9) jest niemal agresywnie permisywna: bundle jest zgodny, jeśli każdy plik ma parsowalne frontmatter z niepustym type. Konsumenci nie mogą odrzucać bundle’a za brakujące opcjonalne pola, nieznane typy, nieznane klucze, złamane linki lub brak indexów.
Rodowód wyjaśnia design. W kwietniu 2026 roku Andrej Karpathy opublikował gist o nazwie LLM Wiki, argumentując, że zamiast używać RAG do re-derywacji wiedzy z surowych dokumentów przy każdym zapytaniu, powinieneś mieć agenta, który inkrementalnie buduje i utrzymuje trwałe, cross-linkowane wiki w Markdown.
Koncepcja podróżowała szybko, bo nazwała coś, co wielu już improwizowało: Obsidian vaults podłączone do coding agents, pliki CLAUDE.md i AGENTS.md, repozytoria „metadata as code". Wzorzec był wszędzie i nigdzie interoperacyjny. OKF to próba Google, by go określić — nie by zbudować na nim platformę.
To jest OKF. Folder z plikami Markdown z rulebook’iem na tyle cienkim, by zmieścił się w twojej głowie.
Czytaj kanał dystrybucji, nie press release
Dyscyplina warta przyjęcia przy każdym nowym standardzie: zobacz, gdzie został opublikowany, kto go opublikował i wraz z jakim produktem został wysłany.
Firmy mówią ci, dla kogo rzecz jest, wybierając miejsce, gdzie ją umieścić — długo zanim powiedzą ci to słowami.
OKF nie został opublikowany na Search Central. Nie na developers.google.com. Nie został współogłoszony z innymi wyszukiwarkami w stylu schema.org i nie został przepuszczony przez W3C. Został opublikowany na blogu Google Cloud, w sekcji Data Analytics, przez dwóch Tech Leadów z grupy Data Cloud, otagowany pod BigQuery i AI & ML, i równolegle z rebrandingiem Dataplex na Knowledge Catalog — produkt, który Google pozycjonuje jako zawsze-włączony silnik kontekstu do groundowania agentów enterprise, zaktualizowany o natywną ingestię bundle’y OKF.
Jeśli wiesz, jak czytać launch, to strategiczna historia w jednym akapicie.
Audytorium to inżynierowie danych, zespoły platformowe i ludzie budujący wewnętrznych agentów w przedsiębiorstwach.
Problem to coś, co każdy pracujący w dużej organizacji rozpozna natychmiast: wiedza, której potrzebuje agent, jest rozproszona pomiędzy katalog z proprietary API, wiki, którego nikt nie aktualizował od 2023 roku, komentarze w kodzie, wątek na Slacku i głowę seniora, który jest na urlopie.
Każdy nowy agent rozwiązuje ten sam problem assemblowania kontekstu od zera. Teza Google — dobra teza — brzmi, że rozwiązaniem nie jest kolejny knowledge service, z którym musisz się zintegrować, ale portable format, który każdy może wyprodukować bez SDK i skonsumować bez integracji.
Logika komercyjna też nie jest ukryta: wiedza enterprise jest uwięziona w katalogach konkurencji, a portable open format jest rozpuszczalnikiem tego lock-in, podczas gdy referencyjna ścieżka (Gemini piszący bundle, BigQuery jako źródło, Knowledge Catalog jako ingestion) utrzymuje grawitację wygodnie wewnątrz Google Cloud. To nie krytyka. To jest to, co launch mówi, czytany jako dokument strategiczny, nie techniczny.
Pytanie o Search — rozstrzygnięte przez jedyne źródło, które może je rozstrzygnąć
Teraz pytanie, które przywiodło tu większość naszej branży: czy publikacja bundle’a OKF na mojej stronie robi cokolwiek dla widoczności w Google?
Odpowiedź brzmi: nie. I niezwykle rzadko nie musimy tego wnioskować. Google umieścił to w dokumentacji.
15 maja 2026 roku Search Central opublikował „Optimizing your website for generative AI features on Google Search" — swoją pierwszą skonsolidowaną oficjalną instrukcję do AI Overviews i AI Mode, ogłoszoną na blogu Search Central. Wymienia, pojedynczo, taktyki, które właściciele stron mogą zignorować: llms.txt, chunking contentu, AI-specific rewriting i specjalne schema lub wersje Markdown stron. Nie potrzebujesz machine-readable files, AI text files, markup ani Markdown, by pojawiać się w Google Search, włącznie z jego generatywnymi funkcjami AI, ponieważ Google Search ich nie używa.
Miesiąc później Google wyjaśnił, że utrzymywanie llms.txt ani nie pomaga, ani nie szkodzi, bo Search to ignoruje.
Bundle OKF hostowany pod /okf/ to katalog plików Markdown. Wpada dokładnie w kategorię, o której Google właśnie nam powiedział, na piśmie, że Search jej nie używa.
Ale „nie jest sygnałem rankingowym" zostaje spłaszczone do „nieistotne", a to nie są te same stwierdzenia. To, co Google powiedział, jest precyzyjne i ograniczone: Google Search nie konsumuje tych plików. To stwierdzenie o jednym konsumencie, nie o Claude, ChatGPT, Perplexity, coding agents, browser agents czy wewnętrznym copilocie, którego zespół operacyjny twojego klienta cicho buduje — żaden z nich nie jest związany dokumentacją Search Central, i kilka z nich demonstracyjnie czyta kuratorowany Markdown, gdy się go przed nimi postawi.
Więc: OKF nie jest mechanizmem widoczności search, i nie ma dowodów, że którykolwiek answer engine szuka bundle’a hostowanego na stronie z własnej inicjatywy.
Współdzielony sposób przechowywania kontekstu to nie współdzielony sposób jego rozumienia
Wróć do §5.3. Linki są nie-typowane.
Link z tables/orders do tables/customers mówi konsumującemu agentowi, że dwie koncepcje są ze sobą powiązane. Nie mówi jak. Nie joins-with, nie depends-on, nie deprecated-by, nie is-a. Natura relacji żyje w prozie wokół linku, co oznacza, że agent musi ją przeczytać i wywnioskować, w języku naturalnym, za każdym razem, gdy przemierza tę krawędź.
To nie przeoczenie. To centralna zakładka designowa, a spec jest o tym szczery: konsumenci budujący widok grafowy powinni traktować każdy link jako skierowaną krawędź nie-typowanej relacji.
Postaw to obok tradycji, którą cicho przepisuje. Stos semantic web rozwiązał to dwie dekady temu z ogromnym rygorem i nigdy nie podbił enterprise — nie dlatego, że był zły, ale dlatego, że był kosztowny: ontologowie, triplestores i tolerancja dla formalizmu, której większość organizacji nie posiada.
Adopcja, nie design, była porażką. OKF stawia przeciwny zakład, celowo, wymieniając semantyczną precyzję na niemal zerową frikcję authoringu: jeśli potrafisz napisać Markdown, możesz go wyprodukować, a jeśli potrafisz zrobić cat pliku, możesz go skonsumować.
Ten zakład jest do obrony.
Ale powinniśmy być jasni co do tego, co dostajemy. Marc Bara sformułował to najostrzej: OKF dostarcza interoperacyjność strukturalną, nie semantyczną. Standardizuje kontener, nie znaczenie w środku.
Ustawione obok siebie, wymiana jest dokładna:
OKF vs RDF / Semantic Web Stack:
- Identyczność: ścieżka pliku (tables/orders) vs mintowane IRI
- Relacje: nie-typowane linki Markdown; znaczenie w prozie vs typowane predykaty; znaczenie w krawędzi
- Słownictwo: free-text type, brak rejestru centralnego vs współdzielone ontologie (RDFS, OWL)
- Walidacja: frontmatter parsuje się i type jest niepuste vs ograniczenia SHACL
- Query: przeczytaj dokumenty vs SPARQL, deterministycznie
- Koszt authoru: napisz plik Markdown vs zatrudnij ontologa
- Co dostajesz: interoperacyjność strukturalną vs interoperacyjność semantyczną
Co oznacza, że dwa perfekcyjnie zgodne bundle z dwóch organizacji mogą w ogóle nie dzielić słownictwa: ta sama rzeczywista koncepcja typowana Metric w jednej i KPI Definition w drugiej, powiązana z tabelą źródłową linkiem oznaczającym „derived from" tu i „documented in" tam, bez niczego, co powiedziałoby maszynie różnicę. Obydwa przechodzą conformance. Żadne nie może być automatycznie zrekoncyliowane z drugim.
Dla tych z nas, którzy pracują w entity SEO, to mapuje się na słownictwo, którego już używamy codziennie:
Ontologia — model domeny: jakie rodzaje rzeczy istnieją i jakie relacje mogą między nimi zachodzić. OKF jawnie odmawia jej zdefiniowania; „defining a fixed taxonomy of concept types" jest wymienione wśród stated non-goals.
Taksonomia — klasyfikacja: które rzeczy należą do których kategorii. Całkowicie pozostawiona producentowi.
Kontekst — proza, struktura, cytowania. To jedyna warstwa, której kształt OKF standaryzuje.
Innymi słowy, OKF daje agentowi pięknie zorganizowaną bibliotekę z niezawodnym systemem półek i bez katalogu kartkowego. Wszystko jest findable, jeśli już znasz budynek. Nic nie jest queryable między budynkami.
Społeczność semantic web zauważyła to natychmiast i zareagowała konstruktywnie, nie terytorialnie. Kurt Cagle, współautor specyfikacji W3C RDFa, zaproponował traktowanie jego specyfikacji DataBook jako formalnego profilu OKF: zachować human-authorable, git-hostable powierzchnię Markdown, którą specyfikuje OKF, i nałożyć na to typowane fenced blocks niosące payloady RDF, identyczność opartą na IRI, walidację SHACL i queryability.
Co to naprawdę znaczy dla twojej strategii
Jeśli jesteś agencją SEO lub content managerem, prawdopodobnie teraz czekasz na „więc co mam z tym zrobić?".
Odpowiedź strategiczna to nie „zaimplementuj OKF na stronie klienta", tylko „zrozum, dla kogo to zostało zbudowane, i zapytaj, czy twój przypadek use overlaps się z tym".
OKF został zbudowany dla:
- Zespołów data engineering dokumentujących setki tabel w BigQuery
- Platform teams zarządzających mikroserwisami i potrzebujących kontekstu dla dev agents
- Organizacji migrujących z proprietary catalog do interoperacyjnego stosu
Jeśli budujesz lub zarządzasz czymkolwiek z powyższych, OKF jest bardzo dobrze zaprojektowanym narzędziem do portable knowledge management.
Jeśli prowadzisz stronę content-driven i pytasz „czy to poprawi mój ranking?", odpowiedź pozostaje niezmieniona: nie, ale nie dlatego, że OKF jest zły, tylko dlatego, że został zaprojektowany dla innego problemu.
Pytanie, które warto zadać: czy którykolwiek z agentów, z którymi twoi użytkownicy faktycznie wchodzą w interakcje — coding assistants, research copilots, browser agents — skorzysta z curated, cross-linked knowledge bundle, jeśli go wystawisz?
Odpowiedź na to pytanie nie jest „tak" ani „nie". Jest „zależy od tego, kto konsumuje twoją treść i jak".
Google Search nie będzie. Ale świat się przesuwa.
Podsumowanie
Open Knowledge Format to dobrze zaprojektowana, otwarta specyfikacja do portable knowledge bundles, skierowana do przedsiębiorstw budujących agenty AI, nie do właścicieli stron próbujących poprawić ranking. Google jasno stwierdził, że Search go nie konsumuje. Format standardyzuje strukturę, nie semantykę, co czyni go prostym w adopcji, ale ograniczonym w interoperacyjności między organizacjami. Prawdziwe pytanie nie brzmi „czy to SEO?", ale „czy moja organizacja potrzebuje portable’owej warstwy kontekstu dla agentów?" — i dla wielu przypadków odpowiedź jest przecząca, a dla niektórych będzie twierdząca.
Źródło: Gianluca Fiorelli, „The Open Knowledge Format: what Google really shipped, and why the interesting question is not SEO", I Love SEO, 13 lipca 2026
