Schema.org yapısal veri nedir, JSON-LD graph neden önemli?

Schema.org yapısal veri nedir?

Schema.org

2011'de Google, Bing ve Yahoo'nun ortak kurduğu, daha sonra Yandex'in katıldığı açık sözlüktür. Kuruluş, hizmet, ürün, makale, soru-cevap gibi kavramları ve özelliklerini standart adlarla tanımlar.

JSON-LD

Schema.org sözlüğünün sayfaya eklenme biçimlerinden biridir. HTML içine bir script etiketiyle yerleştirilen JSON bloğudur; görünür içeriğe dokunmaz. Google'ın önerdiği biçimdir.

Bir insan sayfaya bakınca “bu bir klima servisi firması, şu şehirde, şu hizmetleri veriyor” sonucunu çıkarır. Makine için aynı sayfa, birbirinden bağımsız metin parçalarıdır. Yapısal veri, bu çıkarımı makineye hazır verir: şu metin bir kuruluş adı, şu metin bir hizmet, şu liste bir soru-cevap.

Yapısal veri, sayfanın görünür içeriğini makineler için tercüme eder; yeni bilgi eklemez, var olanı etiketler. Bu ilke aynı zamanda en önemli kuraldır: schema'da yazan her şey sayfada görünür olmalıdır. Görünmeyen içerik için yazılmış işaretleme, Google'ın yapısal veri kurallarına aykırıdır ve zengin sonuç hakkını kaybettirir.

@id ile graph kurmak neden önemli?

Çoğu site yapısal veriyi dağınık kurar: bir sayfada Organization, başka sayfada LocalBusiness, bir başkasında yalnızca FAQPage. Her blok kendi başına doğrudur ama birbirinden habersizdir. Makine, bu blokların aynı işletmeye ait olduğunu çıkarmak zorunda kalır.

@id, her düğüme kalıcı bir adres verir: örneğin https://site.com/#organization. Başka bir düğüm bu adresi referans gösterdiğinde iki düğüm bağlanır. WebSite düğümü publisher olarak Organization'a, WebPage düğümü isPartOf ile WebSite'a, Service düğümü provider ile Organization'a bağlanır. Sonuç, tek bir @graph içinde birbirine düğümlenmiş bir ağdır.

@id ile bağlı graph, işletmenin tüm sayfalarındaki işaretlemeyi tek bir kimlik etrafında toplar; makine tahmin etmez, okur. Dil modelleri için bu özellikle değerlidir: firma adı, adresi, hizmetleri ve sayfaları tek zincirde göründüğünde model işletmeyi başka bir firmayla karıştırmaz ve cevabına güvenle taşır. Bu zincirin yapay zekâ aramasındaki yerini Yapay Zekâ Aramasında Görünmek rehberinde anlatıyoruz.

Google zengin sonuçları ne kazandırır?

Google, bazı yapısal veri türlerini arama sonuçlarında görsel zenginleştirme için kullanır. BreadcrumbList, sonuç altındaki URL yerine okunabilir yol gösterir. Article, tarih ve görsel bilgisini taşır. Organization düğümündeki logo ve sameAs bağlantıları, marka panelini ve bilgi kartını besler.

Beklentiyi doğru kurmak gerekir. Google, Ağustos 2023'ten itibaren FAQ zengin sonucunu yalnızca tanınmış resmî kurum ve sağlık sitelerinde göstermeye başladı; HowTo zengin sonucunu ise kaldırdı. Sitelinks arama kutusu işaretlemesi de Kasım 2024'te kullanımdan çıkarıldı. Yani bir hizmet sitesinde FAQPage, arama sonucunda açılır soru kutuları üretmez.

FAQPage yine de değerlidir; sebebi artık Google zengin sonucu değil, sayfadaki soru-cevap yapısının makine tarafından net okunmasıdır. Dil modelleri ve cevap motorları bu yapıyı alıntılamak için kullanır. Bu konuyu AEO rehberinde ayrıntılı anlattık.

Yapısal veri graph'ı nasıl kurulur?

1. 1İşletmenin kimliğini tek düğümde sabitleyin: site genelinde aynı @id ile Organization (yerel işletmeyse LocalBusiness) yazın; ad, logo, adres, telefon ve sameAs (sosyal hesaplar, harita kaydı) ekleyin.
2. 2WebSite düğümünü kurun ve publisher olarak Organization'ı gösterin. Site adı ve URL burada tanımlanır.
3. 3Her sayfaya kendi WebPage düğümünü ekleyin: URL, başlık, açıklama, datePublished, dateModified; isPartOf ile WebSite'a bağlayın.
4. 4Hizmet sayfalarında Service düğümü, rehberlerde Article düğümü açın ve provider/author/publisher alanlarıyla Organization'a bağlayın.
5. 5Sayfada görünür soru-cevap varsa FAQPage, her sayfada BreadcrumbList ekleyin; içerik görünür metinle birebir aynı olsun.
6. 6Tüm düğümleri tek bir JSON-LD bloğunda @graph dizisi içinde yayımlayın; her düğüme tekrar edilebilir, kalıcı @id verin.
7. 7Google Rich Results Test ve Schema Markup Validator ile doğrulayın; hata ve uyarıları giderin, sonra Search Console'da zenginleştirme raporlarını izleyin.

Sık yapılan hatalar nelerdir?

• Görünür içerikle uyuşmayan schema: sayfada olmayan soru-cevap, sayfada yazmayan hizmet, farklı telefon. Bu, kural ihlalidir ve zengin sonuç hakkını kaybettirir.
• Her sayfada farklı @id ya da hiç @id kullanmamak: düğümler bağlanmaz, işletme kimliği parçalanır.
• Organization ile LocalBusiness'ı aynı işletme için ayrı ayrı, birbirinden habersiz tanımlamak: tek düğüm seçilmeli ve tutarlı kullanılmalıdır.
• Puan ve yorum (AggregateRating) işaretlemesini sayfada gerçek, görünür yorum olmadan eklemek: manuel ceza sebebidir.
• Tarihleri güncellemeden dateModified değerini ileri almak: metin değişmeden tarih değişirse sinyal güvenilirliğini yitirir.
• Yapısal veriyi JavaScript ile sonradan enjekte etmek: yapay zekâ botlarının çoğu bunu görmez; JSON-LD sunucudan gelen HTML'de olmalıdır.
• Şablon eklentisinin ürettiği veriyi hiç kontrol etmemek: eklentiler genellikle eksik ya da birbirini tekrar eden düğümler üretir.

Yapısal verinin yapay zekâ araçları için değerini gösteren en iyi test, modelin kendisine sormaktır: ChatGPT ya da Perplexity'ye “site.com kimin sitesi, hangi hizmetleri veriyor, nerede?” diye sorun. Graph doğru kurulmuşsa cevap, Organization ve Service düğümlerinde yazanla örtüşür. Firmanızın neden önerilmediğini düşünüyorsanız ChatGPT firmamı neden önermiyor rehberi tanı listesi sunar.

Graph kurulumu, SEO / GEO / AEO hizmetinin teknik katmanıdır; diğer katmanlar için rehber merkezine göz atabilirsiniz.