OKF Nedir? SEO ve Yapay Zeka Görünürlüğü İçin Önemi

OKF (Open Knowledge Format), Google’ın Haziran 2026’da duyurduğu, yapay zeka ajanlarının bilgiye standart bir dizin üzerinden erişmesini sağlayan açık bir spesifikasyondur; markdown ve YAML frontmatter’dan oluşan basit “bundle” yapısıyla çalışır, HTML’in web için yaptığını ajan çağı için yapmayı hedefler. SEO açısından klasik “arama motoruna görünme” hedefinden AEO ve GEO ile “ajanlara iş yapabilecekleri bilgi tabanı sunma” katmanına geçişin altyapısıdır; schema markup’ın yerini almaz, onu tamamlar. Bloglar, e-ticaret, SaaS, ajanslar, yayıncılar ve kurumsal ekipler için farklı bundle yapıları öneriyor; Türkiye pazarında henüz uygulayan yok, bu yüzden bugünden kendi bilgi tabanınızı OKF formatına dökmek ciddi bir first mover avantajı yaratıyor.

OKF Nedir?

OKF, Open Knowledge Format kelimelerinin kısaltmasıdır. Türkçe karşılığıyla Açık Bilgi Formatı, Google Cloud’un Haziran 2026’da yayımladığı, yapay zeka ajanlarının bilgiye standart bir dizin yapısı üzerinden erişebilmesini sağlayan açık bir spesifikasyondur.

Spec çok basit; birkaç kural üzerine kurulu:

• OKF, markdown dosyalarından oluşan bir dizindir.
• Her dosya bir “concept” yani tekil bir bilgi birimini temsil eder.
• Dosyaların başında YAML frontmatter bulunur; bu blok, ajanın dosyanın ne hakkında olduğunu içeriğin tamamını okumadan anlamasını sağlar.
• Dosyalar birbirine markdown linkleriyle bağlanır; sonuçta bir bilgi grafiği ortaya çıkar.

Google, bu formatı yeni bir platform, yeni bir SDK veya yeni bir servis olarak duyurmadı. Sadece bir “format” olarak duyurdu. Bu detay çok önemli, ilerleyen bölümlerde bu prensibin neden bu kadar kritik olduğunu detaylı anlatacağım.

Google Cloud’un OKF duyurusu şu adreste yer alıyor: How the Open Knowledge Format can improve data sharing.

OKF Neden Ortaya Çıktı?

Bugün her şirket, her ekip ve her ajans kendi bilgi mimarisini farklı yerlerde tutuyor. Verinin bir kısmı wiki’de, bir kısmı metadata catalog’da, bir kısmı Notion’da, bir kısmı da senelerdir dokunulmamış Google Drive klasörlerinde. AI ajanları bu dağınık kaynakları taradığında, aynı bilgi için farklı sürümlerle karşılaşıyor ve doğru cevabı üretmekte zorlanıyor.

Google’ın OKF blog yazısında da vurgulanan sorun bu: her ajan geliştiricisi context assembly problemini sıfırdan çözmeye çalışıyor. Her satıcı kendi katalog SDK’sını üretiyor, her şirket kendi meta veri şemasını icat ediyor. Sonuç, tekrar eden emek ve taşınamayan bilgi.

OKF, “bunu yeni bir servis ile çözmeyelim, format ile çözelim” diyor. Nasıl HTML web sayfaları için bir standart oluşturduysa, OKF de ajanlar için bir standart oluşturmayı hedefliyor. Standardı benimseyen herkes ortak bir dilde konuşuyor.

OKF Bundle Yapısı Nasıl Çalışır?

OKF’in en temel birimi “bundle” adı verilen dizindir. Bundle, tekil concept dosyalarını, indeks dosyalarını ve log dosyalarını barındıran bir markdown klasörüdür.

Google’ın sample örneğinden esinlenerek bir e-ticaret bundle örneği verelim:

satis/
├── index.md
├── veri-setleri/
│   ├── index.md
│   └── siparişler_db.md
├── tablolar/
│   ├── index.md
│   ├── siparişler.md
│   └── müşteriler.md
└── metrikler/
    ├── index.md
    └── haftalık_aktif_kullanıcı.md

Bu yapı size tanıdık geliyorsa yalnız değilsiniz. Obsidian vault kullananlar, Hugo ile statik site oluşturanlar veya CLAUDE.md dosyalarıyla çalışanlar bu mantığı biliyor. OKF, uzun süredir farklı isimler altında kullanılan bu deseni tek bir standart altında topluyor.

 YAML Frontmatter Alanları

Her concept dosyasının başında YAML frontmatter bloğu yer alır. OKF v0.1 spesifikasyonu şu alanları öneriyor:

Bunlardan yalnızca type alanı zorunludur. Geri kalanlar öneri niteliğindedir. Bu esneklik, OKF’i farklı sektörlere uyarlanabilir kılıyor.

Örnek Bir Concept Dosyası

Aşağıdaki örnek, tipik bir OKF concept dosyasının nasıl göründüğünü gösteriyor:

---
type: BigQuery Table
title: Siparişler
description: Tamamlanmış her sipariş için bir satır.
resource: https://console.cloud.google.com/bigquery?p=marka&d=satis&t=siparisler
tags: [satış, ciro, e-ticaret]
timestamp: 2026-05-28T14:30:00Z
---

# Şema

| Kolon | Tip | Açıklama |
|---|---|---|
| siparis_id | STRING | Global olarak benzersiz sipariş kimliği. |
| musteri_id | STRING | Müşteriler tablosuna FK. |
| toplam_tutar | NUMERIC | KDV dahil sipariş tutarı. |

# Birleştirmeler

Müşteriler tablosuyla `musteri_id` üzerinden join yapılır.

Bu dosyayı bir ajana verdiğinizde, ajanın öncelikle YAML bloğunu okuduğunu ve dosyanın türünü anladığını görüyorum. Body kısmına ise ancak gerektiğinde geçiyor. Bu yaklaşım, klasik RAG çözümlerinden çok daha verimli çünkü ajan tüm dosyayı okumak zorunda kalmıyor.

index.md ve log.md Dosyaları

OKF, iki opsiyonel dosya türü öneriyor:

• index.md: Progressive disclosure için kullanılır. Bir ajan bundle’a girdiğinde önce index.md’ye bakar; bu dosya ajana hangi klasörlerin ne içerdiğini kısaca anlatır. Bu sayede ajan tüm bundle’ı taramadan doğrudan ilgili bölüme gidebilir.
• log.md: Kronolojik değişiklik geçmişini tutar. Yeni concept eklendiğinde, mevcut bir concept güncellendiğinde veya eski bir concept çıkarıldığında log.md’ye kayıt düşürülür.

Bu iki dosya, bundle’ı yaşayan bir bilgi tabanına dönüştürüyor. Ben kendi bundle’ımda log.md’yi her hafta güncelliyorum; hangi konseptin ne zaman revize edildiğini takip etmek büyük bir konfor sağlıyor.

OKF v0.1’in Üç Temel Prensibi

Google, OKF v0.1’i tasarlarken üç temel prensibe bağlı kalmış. Bu prensipler yalnızca teknik bir tercih değil; formatın uzun vadede benimsenmesini garanti altına almak için stratejik seçimler.

Minimally Opinionated (Minimum Kural, Maksimum Esneklik)

OKF, bir concept dosyasından yalnızca type alanını zorunlu tutar. Body içeriği ne olursa olsun; markdown’un standart araçlarını kullandığınız sürece geçerli sayılırsınız. Hangi tipleri kullanacağınıza, hangi ek alanları ekleyeceğinize siz karar verirsiniz.

Bu tercih çok bilinçli. Google, format tanımlanırken aşırı kural koyulursa hiç kimsenin benimsemeyeceğini görüyor. Bu yüzden minimum kural, maksimum genişletilebilirlik felsefesini benimsemişler.

Producer/Consumer Independence (Üretici ve Tüketici Bağımsızlığı)

Bir OKF bundle’ını elle yazan bir insan üretebilir; ama aynı bundle’ı bir AI ajanı okuyup üzerinde çalışabilir. Bir metadata pipeline’ın ürettiği bundle’ı bir görselleyici görselleştirebilir. Bir LLM’in sentezlediği bundle’ı başka bir LLM sorgulayabilir.

Format, “kim ürettiğini” değil, “ne olduğunu” tanımlar. Bu ayrım, ekosistemin çeşitlenmesini kolaylaştırıyor. Ben Notion’da concept’lerimi yazıyorum, sonra bir script ile OKF formatına export ediyorum. Ajanlar bu OKF’i tüketiyor. Zincir tam olarak böyle çalışıyor.

Format, Not Platform (Platform Değil, Format)

Bu, benim en çok sevdiğim prensip. Google, OKF’i kendi cloud servisine bağlı bir standart olarak duyurmadı. Herhangi bir Google Cloud hesabı, herhangi bir SDK veya API’ye ihtiyaç yok. Bundle’ı bir git repo’da tutabilir, bir tar.gz olarak taşıyabilir, herhangi bir editörde açabilirsiniz.

Neden bu kadar önemli? Çünkü HTML’in başarısının nedeni de aynıydı. Kimse HTML kullanmak için Microsoft veya Netscape hesabı açmak zorunda kalmadı. Format, mülkiyetsizdi. OKF de aynı yolda ilerliyor.

OKF’in Kökeni: Karpathy’nin LLM-Wiki Pattern’i

OKF, sıfırdan doğmadı. Andrej Karpathy’nin 2025 sonunda yayımladığı LLM-Wiki gist fikri temel aldı. Karpathy, LLM’lerin bir bilgi tabanı üzerinde nasıl kalıcı hafıza oluşturabileceğini şöyle özetledi:

“LLM’ler sıkılmaz, çapraz referansları güncellemeyi unutmaz ve tek seferde 15 dosyaya dokunabilir.”

Yani insanların kişisel wiki’leri terk etmesine yol açan bakım yükünü, LLM’ler minimum efor ile üstlenebilir. Sizler yeni bilgi eklersiniz, ajan bu bilgiyi ilgili dosyalara serpiştirir, çapraz referansları günceller, çelişkileri işaretler.

Bu desen zaten yaygın olarak kullanılıyordu:

• Obsidian vault’lar coding ajanlarıyla bağlanıyordu.
• AGENTS.md ve CLAUDE.md gibi convention dosyaları öne çıkıyordu.
• Şirket içi wiki’ler LLM’e yem olacak şekilde yeniden düzenleniyordu.

Google, tüm bu deseni tek bir standart altında toplayıp OKF adını verdi. Bu, biraz da RFC benzeri bir hareket; herkesin farklı isimlerle uyguladığı şeyi tek bir konsensus etiketi altında birleştirmek.

OKF ile SEO Arasındaki İlişki

Şimdi konunun SEO’ya dokunan tarafına geliyoruz. OKF, SEO çalışanları için pasif okumaya değil, aktif harekete geçmeye çağıran bir gelişme.

SEO’dan Agentic Accessibility’ye Geçiş

Marie Haynes, OKF hakkındaki analizinde çok isabetli bir noktaya değinmiş: “Belki bu iş artık SEO, GEO veya AEO değil; başka bir isme geçiyoruz.” Ben de bu görüşü destekliyorum. Klasik SEO’nun temel varsayımı, “arama motoruna görünmek” idi. AEO ve GEO ile birlikte yavaş yavaş “yapay zekaya cevap kaynağı olmak” hedefine kaydık.

OKF ise bir sonraki adımı temsil ediyor: “ajanların iş yapabileceği bir bilgi tabanı sunmak”. Ajan sadece bilgiye erişmiyor; bilgiyi kullanarak işlem yapıyor. Rapor üretiyor, teklif hazırlıyor, veri analizi yapıyor.

Bu geçiş için detaylı bir çerçeve için Yapay zeka SEO yazımı da inceleyebilirsiniz. AI çağında SEO’nun evrimini oradan başlamak faydalı.

OKF ve İçerik Formatı

OKF’in içerik cephesinde başrol oyuncusu markdown ve YAML. Yani halihazırda AI için içerik formatları yazımda değindiğim yapılandırılmış markdown yaklaşımı, OKF için birebir geçerli. Web sitenizde blog yazılarınızı temiz markdown ile ürettiyseniz, OKF bundle’a taşımanız çok kolay olacak.

Şirket dokümantasyonunuzu, ürün açıklamalarınızı, iç süreç kılavuzlarınızı OKF formatında tutmak, gelecek dönemin altyapısını hazırlamaktır. Ajan bunları tarayabilir, cevap üretirken kaynak olarak kullanabilir, hatta müşteri hizmetinde otomatik cevaplar üretebilir.

AEO ve GEO Bağlamında OKF’in Rolü

OKF’i AEO (Answer Engine Optimization) ve GEO (Generative Engine Optimization) perspektifinden değerlendirmek gerekiyor. Ben Ahrefs’te yaptığım anahtar kelime araştırmasında “generative engine optimization” için 27.000 global aylık hacim, “geo seo” için 15.000 hacim gördüm. Bu hacimler artmaya devam ediyor ve OKF, bu ekosistemin bir sonraki katmanı olacak.

ChatGPT, Perplexity ve Google AI Mode’da OKF

AEO araştırmalarımdan bildiğim kadarıyla:

• ChatGPT, ret-rr-skysight-v3 retrieval modeli üzerinden çalışıyor ve içeriğin RRF skorunun 0.020 eşiğini geçmesini bekliyor. Yapısal ve semantik olarak tutarlı OKF bundle’lar bu eşiği aşmayı kolaylaştıracak.
• Perplexity, L3 XGBoost reranker’da 0.70 eşiği ile filtreleme yapıyor ve içerik tazeliğini, kaynak otoritesini, tıklanma oranını çok önemsiyor. OKF’in timestamp alanı Perplexity için doğrudan bir tazelik sinyali.
• Google AI Mode, Query Fan-Out yaklaşımıyla bir soruyu 8-10 alt soruya bölüyor. OKF bundle’ınız her alt soruyu kapsayan concept dosyalarına sahipse cevap kapsamınız yüksek olur.

Query Fan-Out nedir yazımı okumadıysanız oradan başlamanızı öneririm. Query Fan-Out olmadan AI Mode optimizasyonunu tam kavramak güç.

RAG’ın Yeniden Tanımı

Klasik RAG (Retrieval-Augmented Generation) yaklaşımında ajan, bir soru geldiğinde büyük bir vektör veritabanını tarar, ilgili chunk’ları bulur ve bunları context’e ekler. Bu yaklaşımın iki sorunu var:

1. Chunk boyutu ve seçimi ajan kalitesini doğrudan etkiliyor.
2. Bilgi grafiği ilişkileri kayboluyor; ajan yalnızca izole parçalar görüyor.

OKF ile birlikte bu tablo değişiyor. Ajan artık büyük bir vektör havuzunu taramak yerine, hedeflenmiş bir bundle’a bakıyor. index.md üzerinden hangi bölüme gitmesi gerektiğini anlıyor. Concept’ler arasındaki markdown link’leri sayesinde ilişkileri de görüyor.

Bu, retrieval maliyetlerini düşürüyor, cevap kalitesini artırıyor ve halüsinasyon oranını azaltıyor. AEO ve GEO kariyerine hazırlananlar için OKF, sadece bir moda değil; gelecek 3-5 yılın altyapısı.

OKF ile Schema Markup Arasındaki Fark

Sıklıkla karşılaştığım bir soru: “OKF, schema markup’ın yerini alacak mı?” Kısa cevap: hayır, ikisi farklı problemler için var.

Aşağıdaki tablo iki standardın nasıl birbirini tamamladığını özetliyor:

Schema markup, “bu sayfa bir ürün sayfası, fiyatı şu, stok durumu bu” der. OKF, “işletmemin tüm bilgi tabanı budur, ajan istediğin gibi kullan” der. İkisi birbirini tamamlar.

Schema markup AI Overview etkisi yazımda AI Overview’lar için schema kullanımını detaylıca anlattım. OKF, o katmana ek olarak çalışacak yeni bir ajan katmanı olarak konumlanıyor.

Kendi OKF Beyninizi Adım Adım Nasıl Oluşturursunuz?

Şimdi işin pratik tarafına geçelim. Ben kendi OKF beynimi son 3 haftadır kuruyorum ve süreçte öğrendiklerimi 10 adımda paylaşıyorum.

Adım 1: Bundle Konusunu Belirleyin

OKF beynini kurmadan önce hangi konuda uzmanlığınızı belgeleyeceğinize karar verin. Ben SEO ve dijital pazarlama üzerine kurdum; siz muhasebe, hukuk, e-ticaret operasyonları, ürün yönetimi gibi başka alanları seçebilirsiniz.

Adım 2: Concept Hiyerarşisi Tasarlayın

Her bundle mantıksal bir dizin hiyerarşisine ihtiyaç duyar. Örneğin benim bundle’ımda şu klasörler var: araştırma/, playbook/, referans/, entity/, sistem/. Bu klasörlerin isimleri sizin domain’inize göre değişebilir.

Adım 3: type Alanlarını Standardize Edin

YAML frontmatter’daki type alanı için tutarlı bir liste oluşturun. Ben şu tipleri kullanıyorum: Konsept, Playbook, Rakip Analizi, Referans, Denklem, Vaka İncelemesi. Bu listeyi bir README’ye ekleyip bundle’ınızın giriş noktası yapın.

Adım 4: İlk 10 Concept’i Yazın

Perfeksiyonist davranmayın, sadece başlayın. İlk 10 concept dosyasını yazmadan bundle’ın nasıl çalıştığını gerçek anlamda öğrenemezsiniz. Her dosya için 200-500 kelime yeterli.

Adım 5: index.md Dosyasını Oluşturun

Kök dizine bir index.md yerleştirin. Bu dosya bundle’ın “kapak sayfası” işlevi görecek. Ajanın hangi klasörde ne bulacağını buradan öğrenmesini sağlayın. Örnek:

---
type: Index
title: Ana İndeks
description: SEO ve dijital pazarlama bilgi tabanımın kök indeksidir.
timestamp: 2026-07-14T09:00:00Z
---

# Bölümler

- [araştırma/](arastirma/index.md) - Güncel SEO araştırmaları
- [playbook/](playbook/index.md) - Adım adım uygulanabilir stratejiler
- [referans/](referans/index.md) - Google dokümanları ve karşı referanslar

Adım 6: Cross-Link Ağı Kurun

Concept dosyalarınızı birbirine bağlayın. Bir Playbook, ilgili Konsept dosyalarına referans vermelidir. Bu ilişkiler bilgi grafiğinin kalbini oluşturur. Ajan bu grafiği takip ederek daha iyi cevaplar üretir.

Adım 7: log.md ile Değişiklik Kaydı Tutun

Her yeni concept eklediğinizde log.md’ye tarih ve kısa açıklama yazın. Örnek:

- 2026-07-14: query-fan-out.md eklendi
- 2026-07-12: perplexity-l3-reranker.md güncellendi
- 2026-07-10: rank-tracker.md ilk versiyon

Adım 8: Ajanınıza Yükleyin

Ben bundle’ı Antigravity ajanına yüklüyorum, ama siz Claude, ChatGPT Projects, Gemini veya kendi yerel LLM’inizle çalışabilirsiniz. Ajan bundle’ı okuyabildiği andan itibaren size kendi bilgi tabanınızdan cevap üretmeye başlar.

Adım 9: Playbook’lar ile Otomasyon Kurun

Bundle’ın en güçlü yönü playbook’lar. Her tekrarlayan görevi bir playbook.md olarak yazın. Örnek: “Teknik SEO Audit Playbook’u”, “Backlink Fırsat Analizi Playbook’u”, “İçerik Refresh Playbook’u”. Ajanınız bu playbook’ları takip ederek işlemleri otomatik yürütür.

Adım 10: Sürekli Güncelleme Sistemi Kurun

Google güncellemeleri, algoritma değişiklikleri, yeni araç çıkışları OKF beyninize düzenli beslenmelidir. Ben haftalık ritüel olarak yeni haberleri okuyup ilgili concept’leri güncelliyorum. Zaten OKF beynin gücü, bakımının kolay olmasında.

10. OKF Bundle Örneği: Gerçek Bir Playbook

Aşağıda kendi bundle’ımdan bir playbook örneği veriyorum. Bu, “Google Core Update Sonrası Etki Analizi” için kullandığım playbook’un basitleştirilmiş versiyonu:

---
type: Playbook
title: Core Update Sonrası Etki Analizi
description: Google core update sonrası trafik kayıplarını analiz etme rehberi.
resource: https://www.batuhandurmaz.com/seo-danismanligi/
tags: [seo, core-update, gsc, ahrefs]
timestamp: 2026-07-10T11:00:00Z
---

# Amaç

Bir Google core update sonrası trafik kayıplarının nedenlerini belirleyip
aksiyon listesi çıkarmak.

# Adımlar

1. Google Search Console'da 30 günlük ile önceki 30 günlük karşılaştırmayı al
2. En çok değer kaybeden 20 URL'yi listele
3. Her URL için E-E-A-T kriterlerini kontrol et
4. İçerik tazeliği ve derinliği açısından değerlendir
5. Rakip SERP analizi yap (Ahrefs)
6. Kullanıcı arama niyeti uyumluluk kontrol et
7. Aksiyon listesi oluştur ve önceliklendir

# İlişkili Konseptler

- entity-seo.md
- topical-otorite.md
- query-fan-out.md

Bu playbook’u ajana verdiğimde, ajan hangi adımı ne zaman uygulayacağını biliyor. Ben sadece “core update analizi başlat” diyorum, sonrasını ajan yürütüyor. Eskiden iki gün süren çalışma artık iki saatte tamamlanıyor.

11. Sektörel OKF Uygulamaları

OKF’i sektörünüze göre nasıl konumlandıracağınız, projeye alacağınız değerin en büyük belirleyicisi. Ben aşağıda farklı sektörler için gerçek dünyada işleyen OKF yapı önerilerini paylaşıyorum. Kendi sektörünüz aşağıdaki başlıklardan hangisine yakınsa oradaki yapıyı temel alarak başlayabilirsiniz.

11.1 Bloglar ve Kişisel Web Siteleri İçin OKF

Blog ve kişisel marka siteleri, OKF’e geçiş için en uygun yapıya sahip site tipidir. Zaten yazılarınız markdown veya WordPress editöründe üretiliyor; kavramsal olarak concept’lere ayrılabilir yapıdalar.

Blog sahipleri için önerdiğim bundle yapısı şu şekilde:

blog/
├── index.md
├── yazılar/
│   ├── seo-nasıl-yapılır.md
│   ├── ai-overview-nedir.md
│   └── query-fan-out-nedir.md
├── konseptler/
│   ├── e-e-a-t.md
│   ├── entity-seo.md
│   └── topical-otorite.md
├── yazar-profili/
│   └── yazar.md
└── log.md

Blog için OKF avantajları:

• Ajanlar yazılarınıza doğrudan referans verebilir; ChatGPT ve Perplexity gibi platformlarda görünürlüğünüz artar.
• Yazar profiliniz yazar.md içinde tek noktadan tanımlıdır; E-E-A-T sinyalini güçlendirir.
• Konsept dosyaları, yazılarınız arasındaki bağlantıyı yapay zeka için de görünür kılar.
• Yeni yazı eklediğinizde log.md otomatik güncellenirse, tazelik sinyali sürekli akar.

Blog için pratik ipucu: her yazınızın markdown versiyonunu ayrı bir concept dosyası olarak tutun. Yazının orijinal URL’sini resource alanına ekleyin. Bu, ajanın hem markdown’ı okuyup hem de canlı sayfaya link vermesini sağlar.

11.2 E-Ticaret Siteleri İçin OKF

E-ticaret siteleri, OKF’in belki de en yüksek ROI göstereceği alan. Ürün kataloğunuz zaten yapılandırılmış veri; onu OKF formatına dönüştürmek çok pratik.

E-ticaret siteleri için önerdiğim bundle yapısı:

magaza/
├── index.md
├── kategoriler/
│   ├── elektronik.md
│   ├── giyim.md
│   └── ev-yasam.md
├── urunler/
│   ├── iphone-15-pro.md
│   ├── samsung-tv-55.md
│   └── kahve-makinesi.md
├── politikalar/
│   ├── kargo-politikası.md
│   ├── iade-politikası.md
│   └── garanti-kosulları.md
├── sss/
│   ├── kargo-sss.md
│   ├── odeme-sss.md
│   └── iade-sss.md
├── musteri-hizmetleri/
│   └── canlı-destek-akisi.md
└── log.md

E-ticaret için OKF’in getirileri şunlar:

• Alışveriş ajanları ürün karşılaştırması yapmak için OKF bundle’ınıza doğrudan başvurabilir.
• Müşteri hizmetleri ajanı, iade veya kargo sorularına politikalar klasöründen anında cevap verir.
• Kategori sayfalarınızın semantik alanı ajanlara net şekilde geçer; SEO ve AEO’da paralel kazanım yaratır.
• Ürün açıklamalarınızın YAML frontmatter’ı SKU, fiyat, stok durumu gibi alanları taşıyabilir.

Örnek bir ürün concept dosyası:

---
type: Ürün
title: iPhone 15 Pro 256 GB
description: Apple'ın 2023 sonbahar akıllı telefon modeli.
resource: https://magazam.com/urun/iphone-15-pro-256gb
sku: APPLE-IP15P-256
fiyat: 79999 TL
stok: mevcut
tags: [apple, iphone, akıllı-telefon, premium]
timestamp: 2026-07-01T12:00:00Z
---

# Öne Çıkan Özellikler

- A17 Pro işlemci
- 6.1 inç Super Retina XDR ekran
- Titanyum gövde
- USB-C bağlantı noktası

# İlgili Ürünler

- iPhone 15 Pro Max
- iPhone 14 Pro
- MagSafe Kılıf

# İade Politikası

Politikalar klasöründeki iade-politikası.md dosyasına başvurun.

E-ticaret için önerim: önce en çok satan 50 ürününüzü OKF concept dosyasına dönüştürün. Sonra kargo, iade, garanti politikalarınızı ekleyin. Bu iki adım, ajan destekli müşteri deneyiminin %80’ini karşılar.

11.3 SaaS ve Yazılım Ürünleri İçin OKF

SaaS şirketleri için OKF, hem müşteri desteği hem ürün dokümantasyonu hem de satış öncesi bilgi paylaşımını dönüştüren bir standart.

SaaS için önerdiğim bundle yapısı:

saas-ürünü/
├── index.md
├── özellikler/
│   ├── analitik-panel.md
│   ├── api-erişimi.md
│   └── ekip-yönetimi.md
├── dokümantasyon/
│   ├── kurulum.md
│   ├── ilk-adım-rehberi.md
│   └── entegrasyonlar.md
├── fiyatlandırma/
│   ├── başlangıç-plan.md
│   ├── profesyonel-plan.md
│   └── kurumsal-plan.md
├── kullanım-senaryoları/
│   ├── b2b-satış-ekipleri.md
│   ├── pazarlama-ajansları.md
│   └── e-ticaret-siteleri.md
├── entegrasyonlar/
│   ├── zapier-entegrasyonu.md
│   ├── slack-entegrasyonu.md
│   └── google-sheets-entegrasyonu.md
├── sss/
│   └── genel-sss.md
└── log.md

SaaS için OKF avantajları:

• Ürününüzü değerlendiren müşteriler, ChatGPT veya Gemini üzerinden “X SaaS ürünü Y iş için uygun mu?” diye sorabiliyor. OKF bundle’ınız varsa cevap doğru ve marka lehine olur.
• Onboarding sürecini ajan destekli hale getirebilirsiniz; kullanıcı sorularına dokümantasyon üzerinden cevap üretilir.
• Satış ekibiniz teklif hazırlarken bundle’ı referans alır; fiyatlandırma ve kapasite bilgileri her zaman güncel kalır.
• Rakip karşılaştırmalarında OKF bundle’ınız, kaynağı belli ve doğrulanabilir bilgi sunar.

SaaS için önerim: fiyatlandırma sayfanızın markdown versiyonunu OKF bundle içinde fiyatlandırma/ klasörüne yerleştirin. Fiyatları YAML frontmatter’da tutun. Fiyat değişikliği olduğunda hem web sayfası hem bundle tek noktadan güncellenir.

11.4 Dijital Pazarlama Ajansları İçin OKF

Ajanslar için OKF, hem iç bilgi yönetimi hem de müşteri raporlaması açısından devrim niteliğinde. Ajans çalışanları farklı müşterilerle çalışırken tekrar eden bilgileri tek merkezden yönetebilir.

Ajanslar için önerdiğim bundle yapısı:

ajans/
├── index.md
├── müşteriler/
│   ├── müşteri-a/
│   │   ├── proje-özeti.md
│   │   ├── hedefler.md
│   │   └── raporlar/
│   └── müşteri-b/
├── playbook/
│   ├── seo-audit.md
│   ├── içerik-brief.md
│   └── backlink-analizi.md
├── metodolojiler/
│   ├── teknik-seo.md
│   ├── içerik-üretimi.md
│   └── link-building.md
├── araçlar/
│   ├── ahrefs.md
│   ├── screaming-frog.md
│   └── search-console.md
├── raporlama/
│   ├── aylık-rapor-şablonu.md
│   └── çeyreklik-özet-şablonu.md
└── log.md

Ajanslar için OKF ile gelen kazanımlar:

• Bir yeni ekip üyesi işe başladığında OKF bundle üzerinden 1 hafta içinde metodolojinizi öğrenebilir.
• Aylık müşteri raporları, ajanın raporlama klasöründeki şablonu takip etmesiyle otomatik üretilir.
• Metodolojileriniz standart ve tekrar edilebilir hale gelir; ekip değişiklikleri hizmet kalitesini etkilemez.
• Müşteri-spesifik konseptler ilgili klasörde tutulur; başka müşterilerle karışmaz.

Ajans için önerim: en çok tekrar eden 5 işi (audit, brief, backlink analizi, aylık rapor, keyword araştırması) playbook olarak yazın. Her müşteri için hedefler.md dosyası ekleyin. Bu iki dosya, ajan destekli iş akışının belkemiğidir.

11.5 Yayıncılık ve Medya Siteleri İçin OKF

Haber siteleri, dergi platformları ve yayınevleri için OKF, arşiv değerini ajan çağında da korumanın en verimli yolu.

Yayıncılar için önerdiğim bundle yapısı:

yayın/
├── index.md
├── kategoriler/
│   ├── ekonomi.md
│   ├── teknoloji.md
│   └── kültür.md
├── makaleler/
│   ├── 2026-07/
│   │   ├── makale-slug-1.md
│   │   └── makale-slug-2.md
│   └── 2026-06/
├── yazarlar/
│   ├── yazar-1.md
│   └── yazar-2.md
├── entity/
│   ├── şirketler/
│   ├── kişiler/
│   └── konseptler/
├── yayın-politikaları/
│   ├── editöryal-standartlar.md
│   └── düzeltme-politikası.md
└── log.md

Yayıncılık için OKF’in katkıları:

• Makaleleriniz ajanlar tarafından atıf verilebilir formda; AI Overview’lerde ve LLM cevaplarında kaynak olarak çıkma şansınız artar.
• Yazar profilleriniz E-E-A-T sinyali güçlendirir; deneyim ve uzmanlık ajanlara net şekilde iletilir.
• Entity klasörünüz, haberlerdeki kişi, şirket, kurum, konsept ilişkilerini merkezileştirir; ajanlar bu grafiği tarayarak bağlam üretir.
• Editöryal politikalarınız şeffaf ve doğrulanabilir hale gelir; ajanlar güvenilirlik değerlendirmesinde bu bilgiyi kullanır.

Yayıncılık için önerim: son 12 aylık makaleleri OKF bundle’a dönüştürmekle başlayın. Her makale için yazar, kategori ve entity referanslarını mutlaka ekleyin. Arşiv değeriniz ajan çağında ancak bu şekilde monetize olur.

11.6 Kurumsal İç Bilgi Yönetimi İçin OKF

Şirket içi ekipler, IT desteği, İK süreçleri ve iç iletişim için OKF muhteşem bir çözüm. Confluence veya Notion’da dağınık duran bilgiyi tek bir standart altında toplayabilirsiniz.

Kurumsal iç kullanım için önerdiğim bundle yapısı:

şirket-içi/
├── index.md
├── ik/
│   ├── izin-politikaları.md
│   ├── işe-alım-süreci.md
│   └── performans-değerlendirme.md
├── it/
│   ├── vpn-kurulum.md
│   ├── laptop-talep-süreci.md
│   └── şifre-yönetimi.md
├── satış/
│   ├── müşteri-onboarding.md
│   └── fiyat-teklifi-şablonu.md
├── pazarlama/
│   ├── marka-kimliği.md
│   └── içerik-onay-akışı.md
├── departmanlar/
│   ├── mühendislik.md
│   └── operasyon.md
└── log.md

Kurumsal OKF getirileri:

• Yeni çalışanlar OKF bundle üzerinden onboarding süreçlerini haftada tamamlayabilir.
• IT ve İK gibi sık sorulan konularda ajan destekli self-service çözüm üretilir.
• Süreç dokümantasyonu tek noktadan güncellenir; departmanlar arası tutarlılık artar.
• Şirket bilgisi çalışan ayrılınca kaybolmaz; kurumsal hafıza dijital ve taşınabilir olur.

Kurumsal için önerim: en çok tekrar eden İK ve IT sorularınızı 10-15 concept dosyası olarak yazın. Slack veya Teams entegrasyonu ile ajan bu bundle üzerinden anında cevap üretir. Bu, help desk yükünüzü %50’ye kadar düşürebilir.

12. OKF’in SEO Uzmanları İçin Yaratacağı Yeni Fırsatlar

OKF’in yerleşmesi, SEO uzmanlarının rolünü kökten değiştirecek. Şu fırsatları görüyorum:

12.1 Bilgi Grafiği Danışmanlığı

Şirketlerin dağınık bilgisini OKF bundle’a dönüştüren danışmanlık, klasik SEO danışmanlığının bir üst katmanına yerleşecek. Ben halihazırda iki müşterimle bu tarz proje görüşüyorum ve ilk kontratlar Eylül 2026 civarında başlayacak.

12.2 Uzman Bilgisinin Monetizasyonu

Marie Haynes’in vurguladığı bir başka nokta da bu: OKF bundle’lar satılabilir. Bir hukukçu, kendi süreçlerini kapsayan bir bundle üretip başka hukukçulara satabilir. Bir muhasebeci vergi mevzuatı bundle’ı hazırlayıp firmalara pazarlayabilir. Bu, SaaS ekonomisinin bilgi ekonomisine dönüşen versiyonu.

12.3 İç Bilgi Otomasyonu

Şirket içi kullanım için hazırlanan OKF bundle’lar müşteri hizmetlerini, satış süreçlerini ve içerik üretim akışlarını otomatikleştirecek. Ajanlar bu bundle’lar üzerinden çalışıp saniyeler içinde nitelikli cevap üretebilir.

12.4 Yeni Meslek: OKF Küratörü

Bundle’ları güncel, tutarlı ve doğru tutmak başlı başına bir uzmanlık gerektiriyor. Bunu düzenli yapan, çelişkileri tespit eden, log.md ile geçmişi kaydeden bir “OKF küratörü” pozisyonu doğacak. Şu an bu isimle bir pozisyon yok, ama 2027 sonuna kadar iş ilanlarında bu ismi göreceğiz.

13. Türkiye Pazarında OKF’e Nasıl Hazırlanmalıyız?

Türkiye pazarı OKF konusunda henüz uyanmadı. Bu, hem risk hem fırsat. Fırsat çünkü ilk uygulayan olma avantajı çok değerli. Risk çünkü ekosistem yavaş yavaş oluşacak ve ilk uygulayanlar denemelerinde bazı yanlış yönler alabilecek.

Benim önerilerim:

• Kişisel bilgi tabanınızla başlayın. Bir çalışan olarak yıllardır edindiğiniz bilgiyi OKF bundle’a dönüştürün. Bu, hem kariyer aracı hem de portfolyo olacak.
• Blog içeriklerinizi OKF formatına dönüştürün. Yazılarınızı markdown formatında tutmuyorsanız hemen başlayın. Yoast SEO veya Rank Math ile üretilen HTML çıktılarınızın yanı sıra markdown versiyonlarını da arşivleyin.
• Sitenizde llms.txt kullanın. OKF henüz kanonik bir web erişim mekanizmasına sahip değil, ama llms.txt zaten AI botlarına içerik yönlendirmek için standart bir dosya. Robots.txt ve llms.txt dosyalarını beraber kullanmak, sitenizin ajan çağına uyumunu artırır.
• Google’ın spec.md dosyasını takip edin. OKF v0.1 başlangıç noktası; v0.2 muhtemelen 2026 sonunda gelecek ve yeni özellikler eklenecek. GitHub’daki resmi repo’yu takip edin: GoogleCloudPlatform/knowledge-catalog.
• Test bundle’lar üretin. İlk bundle’ınız kusursuz olmayacak, dert etmeyin. Amaç, formatı pratik olarak öğrenmek ve iş akışlarınıza entegre etmek.

Türkiye’deki e-ticaret siteleri özellikle avantajlı konumda. Ürün açıklamalarınızı, kategori sayfalarınızı, iade politikalarınızı OKF formatına dönüştürmek görece kolay. Bu yapı, ajanların e-ticaret sitenizde daha iyi cevap üretmesini sağlayacak.

14. OKF ve Diğer AI Standartları

OKF, tek başına yaşamıyor. Onunla birlikte konuşan başka standartlar da mevcut:

OKF, bu ekosistemde “ajanın işlem yapacağı yapıyı” tanımlıyor. Diğer standartlar ise “içeriğin nasıl bulunacağı ve etiketleneceği” ile ilgileniyor. Ben, önümüzdeki 2 yıl içinde bu standartların birbirine referans veren bir üst ekosistem oluşturacağını düşünüyorum.

15. OKF’in Sınırları ve Eksileri

Her yeni teknoloji gibi OKF’in de eksikleri var. Bunları göz ardı etmek, sizi hayal kırıklığına uğratır:

• Standart henüz genç. v0.1 aktif geliştirmede; ilerleyen sürümlerde geriye dönük uyumsuzluklar çıkabilir.
• Görselleyici ekosistemi zayıf. Google’ın örnek statik HTML görselleyicisi dışında olgun araç sayısı çok az.
• Yazma yükü var. Kaliteli bir OKF bundle üretmek, en az bir teknik dokümantasyon projesi kadar iş gücü ister.
• Ajan uyumu değişken. Her ajan OKF bundle’ı aynı verimlilikle işlemez; test etmeden karar vermeyin.
• Güvenlik ve gizlilik ayarları eksik. OKF şu an public bundle’lara odaklanıyor; şirket içi hassas bundle’lar için ek katmanlar gerekiyor.

Bu eksiklikler, önümüzdeki 12 ay içinde çözülecek. Ancak bugünden başlayanların bilinçli beklentiye sahip olması gerekiyor.

Benim kendi sitemde kullandığım OKF yapısı; https://batuhandurmaz.com/okf-bundle/

okf-bundle/
├── index.md
├── README.md
├── log.md
├── yazar/
│   ├── index.md
│   └── batuhan-durmaz.md
├── markalar/
│   ├── index.md
│   ├── batuhandurmaz-com.md
│   └── marketingfocus.md
├── egitimler/
│   ├── index.md
│   ├── seo-egitimi.md
│   ├── google-analytics-egitimi.md
│   ├── google-tag-manager-egitimi.md
│   ├── google-search-console-egitimi.md
│   ├── google-data-studio-egitimi.md
│   ├── zapier-egitimi.md
│   ├── shopify-egitimi.md
│   ├── ai-otomasyon-egitimi.md
│   └── screaming-frog-egitimi.md
├── hizmetler/
│   ├── index.md
│   └── seo-danismanligi.md
├── araclar/
│   ├── index.md
│   ├── gpt-bot-simulator.md
│   ├── query-fan-out.md
│   ├── llm-txt-olusturucu.md
│   ├── seo-gap-analyzer.md
│   ├── http-status-checker.md
│   ├── anahtar-kelime-gruplandirma.md
│   ├── title-meta-kaziyici.md
│   ├── vector-analiz.md
│   └── ic-link-kesif.md
├── konseptler/
│   ├── index.md
│   ├── seo.md
│   ├── teknik-seo.md
│   ├── aeo.md
│   ├── geo.md
│   ├── ai-overview.md
│   ├── query-fan-out.md
│   ├── okf.md
│   ├── entity-seo.md
│   ├── topical-otorite.md
│   ├── e-e-a-t.md
│   ├── schema-markup.md
│   ├── llm-optimizasyonu.md
│   └── e-ticaret-seo.md
├── playbooklar/
│   ├── index.md
│   ├── teknik-seo-audit.md
│   ├── core-update-analizi.md
│   ├── blog-yazi-uretimi.md
│   ├── rakip-analizi.md
│   ├── ic-link-optimizasyonu.md
│   └── aeo-optimizasyon.md
└── iletisim/
    └── iletisim.md