JSON-LD temelleri.
JSON-LD, bir sayfanın anlamını makinelerin okuyabileceği biçimde bildiren ve sayfanın hiçbir pikselini değiştirmeyen yapılandırılmış veri biçimidir.
Bir sayfayı okuyan insan, başlıklardan ve metinden neyin ne olduğunu çıkarır: bu bir hizmet açıklaması, şu bir fiyat, bu bir yazar adı. Makine için aynı çıkarım tahmine dayalıdır ve hataya açıktır. Yapılandırılmış veri bu tahmini ortadan kaldırır: sayfanın içine gömülen bir blok, «bu bir kuruluş, adı şu, kurucusu şu, verdiği hizmet bu» der. Blok ekranda görünmez ama makinelerin en dikkatle okuduğu katmandır.
Üç ayrı biçim vardır ama pratikte tercih edilen tektir. Diğer iki biçim işaretlemeyi HTML'in içine serpiştirir; bu yaklaşım hem bakımı zordur hem de düzen değiştiğinde kolayca kırılır. JSON-LD ise ayrı bir blok olarak durur, HTML'den bağımsızdır ve bir sayfanın görsel yapısı tamamen değişse bile aynı kalır. Google'ın da açıkça önerdiği biçim budur.
Temel yapı
Bir JSON-LD bloğu, bağlamı bildiren bir alanla başlar ve ardından düğümler gelir. Her düğümün bir tipi vardır — kuruluş, kişi, makale, hizmet gibi — ve o tipin schema.org'da tanımlı alanları doldurulur. Tek bir sayfada birden fazla düğüm olabilir ve olması da beklenir; asıl değer, düğümlerin birbirine bağlanmasındadır.
Bağlama işi kimliklerle yapılır. Her düğüme sabit bir kimlik verilir ve başka düğümler o kimliğe atıf yapar. Böylece kuruluş bir kez tanımlanır, kişi bir kez tanımlanır, ve sayfa düğümü her ikisine de işaret eder. Bu kalıp olmadan grafik dağınık bir yığın olur: on ayrı kuruluş bildirimi mi, aynı kuruluşun on tekrarı mı belli olmaz.
- Tek blok, çok düğüm — sayfadaki tüm düğümler tek bir grafik içinde toplanır.
- Sabit kimlikler — kuruluş, kişi ve site bir kez tanımlanır, her yerden atıf alır.
- Sayfanın kendi düğümü — her sayfa kendi kimliğini taşır ve siteye bağlanır.
- Kırıntı yolu — sayfanın hiyerarşideki yeri, arama sonucunda da görünür.
- İçerik düğümü — sayfanın türüne göre makale, hizmet, ürün ya da tanım.
En sık yapılan hata
Yapılandırılmış verinin en tehlikeli kullanım biçimi, ekranda olmayan bir şeyi bildirmektir. Sayfada görünmeyen bir puan, listelenmemiş bir soru-cevap, ya da yazılmamış bir fiyat şemaya konduğunda iki sorun birden doğar: arama motoru kurallarının açık ihlalidir ve yaptırımı olabilir, ve sayfa kendisiyle çelişir hâle gelir. Model, şemanın söylediğini metinde bulamadığında güveni artmaz — azalır.
Doğru kalıp basittir: şema, ekranda zaten duran bilgiyi makine diline çevirir. Yeni bilgi eklemez, var olanı yapılandırır. Bu sitede kural kodla korunuyor — hizmet sayfalarındaki sık sorulan sorular hem şemada hem ekranda duruyor, ve doğrulama süiti ikisinin eşleştiğini her koşumda ölçüyor.
Şema yeni bilgi eklemez; var olan bilgiyi makine diline çevirir.
Nereden başlanır
Sıfırdan bir grafik kurmak gözü korkutabilir ama sıra bellidir ve her adım bir öncekine yaslanır. Önce kimlik: kuruluş ya da kişi düğümü, sabit bir kimlikle. Sonra site düğümü ve her sayfanın kendi düğümü. Sonra kırıntı yolu — hem gezinme yapısını hem arama sonucundaki görünümü besler. En sonda sayfa türüne özgü düğümler: makale, hizmet, tanım, soru-cevap.
Bu sıra atlanabilir ama atlandığında üst katmanlar boşa çalışır. Kimlik düğümü olmayan bir makale düğümü, yazarını gösteremez; site düğümü olmayan bir sayfa düğümü, hangi siteye ait olduğunu söyleyemez. Grafiğin değeri bağlarındadır ve bağlar merkezden dışa doğru kurulur.
Bakım tarafı da unutulmamalı: elle yazılan şemalar birkaç ay içinde gerçeğinden ayrışır. Sayfa değişir, şema kalır. Bu yüzden şemanın üretici tarafından, sayfanın kendi verisinden çıkarılması tercih edilmelidir — böylece ayrışma yapısal olarak imkânsız olur.
Doğrulama ve yaygın kırılmalar
Yazılan bir şemanın gerçekten okunabildiğini varsaymak yerine doğrulamak gerekir ve bunun iki katmanı var. Birincisi sözdizimi: blok geçerli bir veri yapısı mı, ayrıştırılabiliyor mu? Tek bir eksik virgül tüm bloğu geçersiz kılar ve o sayfadaki yapılandırılmış verinin tamamı yok sayılır. İkincisi anlam: çıkan düğüm listesi sitenin gerçekten ne olduğunu anlatıyor mu? Hatasız ama anlamsız bir grafik teknik olarak geçerlidir ve hiçbir işe yaramaz.
En sık kırılma noktaları bellidir. Tarih alanlarının biçimsiz yazılması — makine-okunur bir tarih standart bir biçim ister, serbest metin kabul edilmez. Kimliğe yapılan atıfların boşlukta kalması — bir düğüm var olmayan bir kimliğe işaret ederse bağ kurulmaz. Ve zorunlu alanların eksik bırakılması — bazı tipler belirli alanlar olmadan zengin sonuç üretmez.
Bu kontrollerin elle yapılması bir kereye mahsus işe yarar; kalıcı çözüm otomatikleştirmektir. Her dağıtımda tüm sayfaların şema bloklarını ayrıştıran ve düğüm tiplerini raporlayan kısa bir kontrol, kırılmayı anında görünür kılar. Bu sitede o kontrol doğrulama süitinin içinde yaşıyor ve her rotada şema grafiğinin beklenen düğümleri taşıdığını ölçüyor.
Son olarak, şema ile içeriğin birlikte yaşlanması meselesi var. Bir sayfanın metni güncellendiğinde şemadaki tarih alanı da güncellenmelidir; aksi hâlde makine-okunur katman ile görünen katman ayrışır ve tazelik sinyali yanlış olur. Bu sitede tarih alanları bir deftere bağlı ve defter yalnız sayfanın ÇIKTISI değiştiğinde ilerliyor — her build'de bugüne sıfırlanan bir tarih, bir süre sonra hiç dikkate alınmayan bir sinyale dönüşürdü. Doğru tazelik bildirimi, gerçekten değişen sayfayı işaret edendir.
Hangi tipler gerçekten işe yarıyor
Schema.org yüzlerce tip tanımlar ve hepsini kullanmaya çalışmak bir hatadır; çoğu tip hiçbir arama motoru ya da yanıt motoru tarafından özel olarak işlenmez. Pratikte fark yaratan tipler azdır ve bir sitenin türüne göre değişir. Bir danışmanlık sitesi için kuruluş, kişi, hizmet, makale ve soru-cevap tipleri neredeyse tüm faydayı sağlar; geri kalanı gürültüdür.
Seçim kriteri şu olmalıdır: bu tip, sayfada gerçekten var olan bir şeyi mi anlatıyor? Ürün tipi kullanmak için gerçek bir ürün, ürün şeması için gerçek bir fiyat gerekir. Olmayan bir şeyi bildirmek için tip seçmek, en baştan yanlış yola girmektir. Bu sitede fiyat bildirilmiyor çünkü site fiyat yayımlamıyor — ve doğrulama süiti uydurma bir fiyat alanının eklenmediğini denetliyor.
Bir de kapsam meselesi var: her sayfaya her tipi koymak yerine, sayfanın türüne uygun tek bir ana düğüm ve onu çevreleyen kimlik düğümleri yeterlidir. Bir yazı sayfasında makale düğümü, bir hizmet sayfasında hizmet düğümü ana düğümdür; ikisini aynı sayfaya koymak yapıyı bulanıklaştırır.