JSON-LD'yi SEO "Çorbası" Olarak Görmeyi Nasıl Bıraktık ve LLM'ler İçin Makine Tarafından Okunabilir Bir Bilgi Katmanı İnşa Ettik

B2B donanım sektöründeki bir müşteri için kusursuz görünen bir Schema.org entegrasyonunu yeni yayına almıştık. Tüm doğrulama araçları yeşil tik veriyordu. Google Search Console sıfır hata gösteriyor ve tüm katalogda rich snippet kazandırıyordu.

Ardından ChatGPT-4o üzerinde bir test yaptım. Amiral gemisi endüstriyel pompalarının teknik özelliklerini rakipleriyle karşılaştırmasını istedim.

Tam bir fiyasko.

Teknik toleransların yarısını uydurdu (hallucination) ve şirketin yerine rakibin garanti koşullarını getirdi. LLM'lere geleneksel arama motoru muamelesi yapıyorduk ve bu durum elimizde patladı.

Tokenizasyon Karmaşık Formatları Neden Yok Eder?

İşin özeti şu:

LLM'ler web sayfalarını okumaz. Token'ları okur.

Bir yapay zeka botu sitenizi taradığında, DOM görselleştiricisi gibi iç içe geçmiş tertemiz bir JSON-LD betiği görmez. Yapısal zarafeti soyup atar, ham karakterleri alt kelime (subword) token'larına böler.

Yapay zekanın birbiriyle derinden ilişkili ürün entity'leri arasındaki hiyerarşiyi koruyacağını varsayarak standart Schema.org işaretlemelerini sayfaya yığmıştık.

Korumadı.

Aksine tokenizasyon, bu açık ilişkileri dümdüz etti. Model izole terimleri tanıdı ama düğümler (nodes) arasındaki temel mantıksal bağı kaybetti. Ortaya istatistiksel bir çorba çıktı.

Bu, birine alfabetik bir sözlük verip teknik kılavuzun konusunu anlamasını beklemeye benziyor.

Geleneksel SEO işaretlemesi artık yetersiz. Model, tokenizasyon sürecinde entity ilişkilerini koruyamıyorsa yapılandırılmış veriniz tamamen işlevsizdir.

Ekiplere sürekli "daha fazla şema ekleyin" diyen tavsiyelerden artık gerçekten gına geldi. Sıradan SEO eklentilerini üst üste yığmak, token işleme sırasındaki yapısal bozulmayı çözmez.

LLM bu entity ilişkilerini ham bayt akışından yeniden kuramıyorsa markanız üretken yanıtlarda (generative output) yok demektir.

Geleneksel Schema.org Generative Engine Optimization (GEO) Sürecinde Neden Başarısız Olur?

LLM'ler JSON-LD şemasını gerçekten kullanıyor mu?

Modern büyük dil modelleri, makine bağlamında halüsinasyon görmeden doğrudan entity ilişkilerini çıkarmak için akıl yürütme çerçeveleri ve bilgi grafikleriyle eşleştirildiğinde JSON-LD yapılandırılmış verilerine fazlasıyla güvenir.

Evet, yapay zeka modelleri yapılandırılmış veriyi işler. Ancak bunu ters dizin (inverted index) oluşturan geleneksel bir arama botu gibi yapmazlar.

Çoğu ekip Schema.org'a yüzeysel bir kontrol listesi gibi yaklaşıyor: Bir Article etiketi yapıştır, FAQ bloğu koy ve zengin sonuçlar için dua et. Bu yöntem 2020'de Google için işe yarıyordu. Bugün Generative Engine Optimization için tamamen kırılmış durumda.

Modeller sitenizi estetik işaretlemeler için gezmiyor. Açık düğüm bağlantılarını çıkarıyorlar.

Mühendislik ekipleri modellerin şemayı okuduğunu anlasa bile, şişirilmiş uygulamalarla kendi ayaklarına sıkıyorlar.

Eklenti Çatışması: Çoğaltma ve Aşırı Yük

Dün gece, Perplexity'nin temel ürün özelliklerini neden sürekli görmezden geldiğini anlayamayan 15.000'den fazla SKU'ya sahip kurumsal bir e-ticaret sitesini test etmek için saatler harcadım.

Ne mi buldum? Kaynak kodda tam bir kaos.

Aynı anda çalışan üç ayrı WordPress eklentileri vardı: biri site genelindeki meta veriler için, biri otomatik kullanıcı yorumları için ve eski bir e-ticaret eklentisi. Her biri kendi koordinesiz @context bloğunu enjekte ediyordu. Tek bir ürün sayfası, birbiriyle çelişen üç farklı @type: Organization tanımı ve çelişkili para birimi değerlerine sahip yinelenen ürün düğümleri sunuyordu.

İlişkili varyantlar arasındaki tekrarlayan şema döngüleri yüzünden ham JSON-LD yükü, tarayıcı asıl gövde içeriğine bile ulaşmadan 400 KB'ı aşıyordu.

Sorun tam olarak burada: Yapay zeka tarayıcıları, token sınırları ve istek zaman aşımları konusunda acımasızdır. Otonom bir ajan yarım megabaytlık gereksiz JSON metniyle karşılaştığında, veriyi kesip atar veya ayrıştırılmamış bir gürültüye dönüştürür.

Bu da bizi asıl büyük probleme götürüyor:

Çoğu yapay zeka tarayıcısı istemci tarafı JavaScript'i (client-side JS) çalıştırmaz.

Müşteri yorumlarını lazy-load ile yüklüyorsanız veya sayfanın altındaki güven sinyallerini dinamik script'lerle sayfalıyorsanız, yapay zeka tarayıcısı yalnızca boş bir kabuk görür. Google'ın geleneksel web tarayıcısı, ikincil bir kuyrukta istemci tarafı script'leri eninde sonunda render edebilir. Ancak gerçek zamanlı getirme yapan bir LLM botu asla beklemez.

Veri ilk bayttan itibaren statik, kesin HTML içine sabitlenmemişse makine için yok hükmündedir.

Paradigma Değişimi: Bilgi Katmanı Olarak Yapılandırılmış Veri

On yıl boyunca JSON-LD'ye görsel bir numara gözüyle baktık. Bir kod parçası ekler, parmaklarınızı çaprazlar ve Google'ın SERP sonucunuza yıldız puanı veya genişletilmiş bir SSS açılır menüsü vermesini umardınız. Bu sadece kozmetik bir yamaydı.

O dönem bitti.

Bugün yapılandırılmış veri, zengin bir sonuç üreticisi değildir. Büyük dil modelleri için temel bilgi katmanıdır (knowledge layer).

Bir yapay zeka motoru sitenizi değerlendirirken yüksek çözünürlüklü banner görselleri aramaz. Net gerçekler ister: doğrudan düğümler, doğrulanmış özellikler ve somut ilişkiler. Yalnızca doğal dil metnine güvenirseniz, modeli istatistiksel olasılıklar üzerinden tahmin yürütmeye zorlarsınız.

RAG (Retrieval-Augmented Generation) Ötesine Geçmek

Herkes ham RAG süreçlerinin her şeyi çözeceğini sanıyor. Yapılandırılmamış blog yazılarını bir vektör veri tabanına atın, kosinüs benzerliği çalıştırın, en iyi parçaları çekin ve gerisini LLM'e bırakın.

Bu yaklaşım sürekli çuvallıyor.

Bunu doğrudan test ettik: Özel bir B2B kataloğundaki karmaşık sorguları yanıtlayan standart vektör tabanlı bir RAG hattını, temiz ve entity modeli çıkarılmış bir JSON-LD bilgi grafiğiyle karşılaştırdık.

Vektör RAG kurulumu tam bir karmaşaydı. Parçalanmış kesitler getirdi, benzer model numaraları arasındaki fiyat kademelerini karıştırdı ve etrafındaki anlatım belirsiz olduğu için teknik özellikleri uydurdu.

Sonra modele temiz JSON-LD grafiğini verdik.

Sıfır halüsinasyon. Anında entity çözünürlüğü. Model gereksiz bağlam token'ları yakmadan kesin hiyerarşileri, iç içe geçmiş öznitelikleri ve ürün ilişkilerini kavradı.

Vektör benzerliği ilgili metni bulur, ancak yapılandırılmış veri makine tarafından okunabilir bağlamı sağlar. RAG bir LLM'e çiğ malzemeleri verir; düzgün bir JSON-LD yapısı ise bitmiş mimari planı sunar. Bir yapay zekanın entity'nizi mutlak hassasiyetle kaynak göstermesini istiyorsanız, onu şişirilmiş metin yığınlarıyla beslemeyi bırakın ve bilgi katmanınızı doğrudan işaretlemenizin içine inşa edin.

Yapay Zeka Görünürlüğü İçin Kullandığımız Net JSON-LD Çerçevesi

JSON Şemasının LLM'ler Tarafından Göründüğü Nasıl Kontrol Edilir?

JSON Şemanızın LLM'ler tarafından görünüp görünmediğini doğrulamak için yalnızca klasik aramayı izleyen Google Search Console'a güvenemezsiniz. Doğrudan sunucu log dosyalarınızı analiz etmeli, AI tarayıcılarıyla (GPTBot veya ClaudeBot gibi) ilişkili user-agent dizelerini tespit etmeli ve bunların gömülü JSON-LD yükünüzü içeren statik HTML dosyalarını başarıyla çekip çekmediğini teyit etmelisiniz.

Google Search Console, OpenAI veya Anthropic tarayıcılarının Organization şemanızı işleyip işlemediği konusunda size hiçbir şey söylemez. GSC yalnızca Googlebot'u ve klasik SERP özelliklerini takip eder.

GSC'yi tamamen devre dışı bırakıp GPTBot, ClaudeBot ve PerplexityBot isteklerini izole etmek için otomatik log filtreleri kurduk. İndeksleme durumunu değil, ham veri çekme (fetch) yüklerini izledik.

Bot ham HTML'i çektiğinde bu statik yanıt birleştirilmiş JSON-LD grafiğimizi içeriyorsa, veri başarıyla ayrıştırılmış demektir. JSON-LD hidrasyon sonrasında istemci tarafı JavaScript ile mi enjekte edildi? Bot 200 OK yanıtı kaydetti, boşluğu taradı ve sayfayı terk etti.

Yapay Zeka İçin Organization ve FAQPage Şemalarını Yapılandırma

Entity'nizin üretken motorlarda tutarlı şekilde öne çıkmasını sağlamak için deterministik bir yapıya ihtiyacınız var. Mevcut her Şema tipini tek bir sayfaya yığmak sadece gürültü yaratır.

Kullandığımız net yapısal şablon şudur:

Organization Şeması (Çapa): Alan adı genelinde global olarak enjekte edilir. Entity kimliğini kurar; sameAs üzerinden Wikidata kimliklerine ve harici otorite profillerine bağlanarak LLM'e tam olarak kimin konuştuğunu bildirir.
Article / TechArticle Şeması (Bağlam): Fazlalıklardan arındırılmıştır. author, datePublished ve sayfa konularını tanımlanmış entity düğümlerine bağlayan net about / mentions dizilerine öncelik veririz.
FAQPage Şeması (Doğrudan Besleme): LLM'ler deterministik Soru-Cevap formatlarını yüksek doğrulukla işler. Kritik teknik parametreleri ve spesifikasyonları doğrudan JSON-LD yükü içinde net Soru/Cevap çiftleri olarak eşleriz.

Mühendislik ekiplerinin en çok tökezlediği yer sunum aşamasıdır.

Yapay zeka botları için istemci tarafı render işlemlerine (CSR) güvenemezsiniz.

Bunu, FAQ şeması React üzerinden dinamik olarak bağlanan bir müşteride acı yoldan öğrendik. Yapay zeka tarayıcıları ilk sunucu yanıtını aldı ve istemci script'ini asla çalıştırmadı.

Kural çok basit: JSON-LD yükünüz ilk bayttan itibaren ilk HTML yanıtına statik olarak render edilmelidir. Gecikmeli hidrasyon yok, istemci tarafı enjeksiyonu yok.

Google İçin Optimize Etmeyi Bırakın, Entity'ler İçin Mühendislik Yapın

Geleneksel arama optimizasyonu sınırlarına ulaşıyor. Yalnızca mavi bağlantılara odaklanmak, bilgi getirmenin bugün gerçekte nasıl çalıştığını görmezden gelmektir. Operasyonel dönüşüm artık Makineler Arası (M2M) iletişimdir.

Gerçek şu: Bir yapay zeka ajanı yanıtı doğrudan sentezlediğinde, seçenekleri karşılaştırdığında ve niyeti arayüz içinde çözdüğünde alıcılar artık sitenize tıklamıyor. Bu ajan, özelliklerinizi ve ilişkilerinizi deterministik işaretlemelerle doğrulayamazsa markanız yanıttan tamamen çıkarılır.

M2M SEO'nun Geleceği

Şema sonradan akla gelen bir detay—şişirilmiş DOM ağaçlarının üzerine yapıştırılmış süs bir script—olarak görüldüğünde, bağlam pencerelerini hızla tüketir. Düzensiz token gürültüsünü ayrıştırmak gecikmeyi artırır ve modelleri kesin veriler yerine istatistiksel olasılıklara dayanmaya zorlar.

Bir yapay zeka botu entity ilişkilerinizi yapılandırılmamış metinden tahmin etmek zorunda kalırsa, sizin yerinize bir rakibi uyduracaktır.

AnswerShaper'da şemayı bir SEO eklentisi olarak değil, otonom modeller için açık bir API olarak ele alıyoruz. Yoğun, birbiriyle bağlantılı entity grafiklerini doğrudan statik koda eşleyerek ayrıştırma belirsizliğini ortadan kaldırır ve token maliyetinin çok küçük bir kısmıyla saf, doğrulanmış veri sunarsınız.

SEO stratejiniz M2M iletişimini hesaba katmıyorsa, hızla yok olan bir arama ekosistemi için kürek çekiyorsunuz demektir. Ya prompt'un içindesiniz ya da yoksunuz. Makine tarafından okunabilir bilgi katmanınızı şimdiden ana altyapınıza inşa edin ya da üretken web'de görünmez olmayı kabullenin. Entity mimarimizi nasıl kurguladığımızı görmek için Yapay Zeka İçin Token Harcamayı Bırakıp Knowledge Graph Optimizasyonunda Nasıl Uzmanlaştık rehberimizi inceleyin.