Yapılandırılmış Veri Testi

Yapılandırılmış veri, bir sayfadaki bilgiyi (bir ürünün adını ve fiyatını, bir yazının yazarını, bir işletmenin adresini) makinelerin kolay okuyabileceği standart bir sözlükle işaretleme yöntemidir. En yaygın sözlük schema.org’dur; sayfanın görünen içeriğine ek olarak, aynı bilgiyi düzenli bir biçimde arama motorlarına ve diğer yazılımlara sunar.

Doğru kurulmuş yapılandırılmış veri, arama motorunun sayfayı daha doğru anlamasına yardımcı olabilir ve bazı türlerde arama sonucunda zengin görünüm için bir koşul olabilir. Ancak bir arama motorunun zengin sonucu gösterip göstermeyeceği ayrıca onun kendi ölçütlerine bağlıdır; şema eklemek bunu garanti etmez.

Yapılandırılmış veri ürün sayfalarında fiyat ve stok bilgisini, blog yazılarında yazar ve yayın tarihini, işletme sayfalarında adres ve telefonu, soru-yanıt içeriklerinde soruları ve yanıtları tanımlamak için sık kullanılır. Sayfadaki görünen bilgiyle işaretlemenin uyumlu olması beklenir; sayfada olmayan bir bilgiyi şemada vermek hem yanıltıcıdır hem de arama motorlarının yönergelerine aykırı olabilir.

JSON-LD, yapılandırılmış veriyi sayfanın görünen HTML’inden ayrı, bir script bloğu içinde JSON olarak taşıyan biçimdir. Blok type="application/ld+json" özniteliğiyle işaretlenir. Veri, sayfanın görünen işaretlemesinin arasına karışmadığı için eklemesi, güncellemesi ve incelemesi diğer biçimlere göre kolaydır; bu yüzden birçok sitede tercih edilir.

Bir JSON-LD bloğu genellikle @context (sözlüğün adresi), @type (nesnenin türü) ve türe ait alanlardan oluşur. Birden çok nesne @graph dizisi içinde tek blokta verilebilir, ya da her biri ayrı bir blok olarak yazılabilir.

Aracın üstündeki alana sayfanın adresini yazıp “Test Et” düğmesine basın. Araç sayfanın HTML’ini okur, içindeki bütün JSON-LD bloklarını bulur ve tek tek ayrıştırır. Sonuçta kaç blok bulunduğunu, kaçının geçerli olduğunu ve hangi türlerin tanımlandığını görürsünüz.

Henüz yayında olmayan bir sayfayı test etmek için sayfanın kaynağını ya da yalnızca JSON-LD script bloklarını yapıştırabilirsiniz. Yapıştırma yolunda da aynı çözümleme çalışır; yalnızca sayfanın adresi, durum kodu ve yanıt başlıkları gibi bilgiler bulunmaz. Betikler çalıştırılmadığı için bir betikle sayfa yüklendikten sonra eklenen JSON-LD blokları görünmez; yalnızca sunucunun gönderdiği HTML’deki bloklar bulunur.

Raporda önce üstteki özeti, sonra “Ayrıştırma hataları” bölümünü okuyun: geçersiz bir blok hiçbir arama motoru tarafından kullanılamaz, bu yüzden en önce düzeltilmesi gereken budur. Hatalar giderildikten sonra her varlığın kartındaki eksik alan listesine ve yinelenen @id bölümüne geçin.

Test beş başlıkta rapor üretir:

• Ayrıştırma: her blok geçerli JSON mu; değilse hata iletisi ve konum (satır ve sütun).
• Türler: @graph içindekiler ve iç içe nesneler dahil, bulunan bütün @type değerleri ve kaç kez geçtikleri.
• Alanlar: her varlığın taşıdığı alanlar ve kısa değer önizlemeleri.
• Yaygın alanlar: Organization ve LocalBusiness, Product, Article ve BlogPosting, FAQPage, BreadcrumbList ve WebSite türlerinde yaygın kullanılan alanlardan bulunmayanlar.
• Tutarlılık: birden çok kez tanımlanan @id değerleri, schema.org @context eksikliği ve sayfada microdata ya da RDFa bulunup bulunmadığı.

Bu beş başlık, raporun hem özet panelinde hem de ayrıntı bölümünde yer alır. Özet panel yalnızca sayıları ve eylemleri taşır; her bloğun, varlığın ve hatanın ayrıntısı sayfanın altındaki raporda listelenir. Raporu kopyala düğmesi aynı bilgiyi düz metin olarak verir; geliştiriciye iletmek ya da bir görev kaydına eklemek için uygundur.

JSON’un yazım kuralları katıdır ve tek bir yanlış karakter bütün bloğun okunamamasına yol açar. En sık görülen nedenler şunlardır:

• Son alandan sonra fazladan virgül bırakmak.
• Anahtar ya da metinlerde çift tırnak yerine tek tırnak kullanmak.
• Blok içine // ya da /* */ türünden yorum yazmak; JSON yorum desteklemez.
• Metin içindeki tırnak ve ters eğik çizgi gibi karakterleri kaçırmamak.
• Bir şablon ya da eklentinin boş bir değişkeni değer yerine bırakması, örneğin "price": ,.

Araç hata iletisini tarayıcının JSON ayrıştırıcısından alır ve mümkün olduğunda blok içindeki ve belgedeki satır ile sütunu gösterir. Bazı tarayıcılar iletiyle konum vermez; bu durumda “konum belirlenemedi” yazılır ve yalnızca iletiyi görürsünüz.

Örnek olarak, Product türündeki bir varlığın içinde fiyat bilgisi bir Offer nesnesinde tutulur. Araç, fiyat ya da para biriminin bu Offer içinde bulunup bulunmadığına bakar ve eksikse Product kartında “offers.price” ya da “offers.priceCurrency” olarak bildirir. AggregateOffer kullanıyorsanız lowPrice alanı fiyat yerine kabul edilir.

@graph, aynı blokta birden çok bağımsız nesneyi (örneğin bir WebSite, bir Organization ve bir BlogPosting) bir dizi içinde tanımlamanızı sağlar. Araç @graph içindeki her öğeyi ayrı bir varlık olarak listeler ve konumunu “Blok 2 > @graph[1]” biçiminde yazar.

Bir nesnenin alanı da başka bir türde nesne olabilir: bir Product içindeki offers bir Offer, bir BlogPosting içindeki author bir Person olabilir. Araç bu iç içe nesneleri de ayrı varlık olarak çıkarır ve “İç içe tür” etiketiyle gösterir; böylece hangi türün hangi nesnenin içinde olduğunu konum satırından izlersiniz. Bulunan türler listesindeki sayılar iç içe olanları da kapsar.

FAQPage için her sorunun bir adı ve bir yanıt metni olması beklenir; araç bu çiftlerden eksik olanları “mainEntity[2].acceptedAnswer.text” gibi dizin numarasıyla gösterir, böylece hangi sorunun sorunlu olduğunu hemen bulursunuz. BreadcrumbList için her öğenin sırası (position), adı ve adresi aynı biçimde denetlenir.

Araç her tür için, o türün örneklerinde sık kullanılan birkaç alanı kontrol listesi olarak taşır. Örneğin Organization ve LocalBusiness için ad, web adresi, logo, adres ve telefon; Product için ad, görsel, fiyat ve para birimi; BlogPosting için başlık, yayın tarihi, yazar ve görsel kontrol edilir.

Bu listeler bir arama motorunun şart koştuğu alan listeleri değildir. Bir alanın bulunmaması bir hata anlamına gelmez; bazı alanlar sayfanıza uymayabilir ya da bilginiz olmayabilir. Liste, “şemam sık görülen alanların hangilerini içermiyor?” sorusunu hızla yanıtlamak için vardır. Hangi alanların arama sonucunda zengin görünüm için gerekli ya da önerilen olduğunu, ilgili arama motorunun güncel belgelerinden doğrulayın.

BreadcrumbList için son öğenin adresi eksik sayılmaz, çünkü son öğe çoğunlukla bulunulan sayfanın kendisidir. Bu türler dışındaki türler için alanlar yalnızca listelenir.

@id, bir varlığı benzersiz biçimde tanımlayan adrestir. Aynı @id ile iki ayrı yerde farklı alanlar tanımlandığında, okuyan yazılım bu iki tanımı aynı varlığın parçası olarak birleştirmeye ya da birini yok saymaya çalışabilir; sonuç, öngörülemez ya da çelişkili olabilir.

Aynı varlığa başka bir yerden başvurmak sorun değildir; bu durumda yalnızca {"@id": "…"} yazılır, başka alan eklenmez. Araç, @id’nin yanında başka alan da taşıyan nesneleri “tanım”, yalnızca @id taşıyanları “başvuru” sayar ve yalnızca birden çok tanımı olan @id değerlerini yinelenen olarak bildirir. Çok eklentili sitelerde aynı Organization’ın hem tema hem SEO eklentisi tarafından yazılması bu uyarının sık nedenidir.

Çözüm çoğunlukla sade: kaynağı belirleyin (tema mı, eklenti mi, elle eklenen kod mu), aynı nesneyi yalnızca birinin üretmesini sağlayın ve diğer yerlerde @id ile başvuru yapın. Raporda her yinelenen @id için tanımın bulunduğu blok ve konum yazılır; bu, hangi iki kaynağın çakıştığını bulmanızı kolaylaştırır.

Microdata ve RDFa, aynı schema.org bilgisini JSON-LD’den farklı olarak sayfanın görünen HTML öğelerinin özniteliklerine yazar. Teknik olarak bir sayfada bu biçimler birlikte bulunabilir; ancak aynı bilgiyi iki biçimde ve farklı değerlerle vermek çelişki riski doğurur ve bakımı zorlaştırır.

Araç sayfada microdata (itemscope) ve RDFa (typeof, vocab) bulunup bulunmadığını, bulunduğunda kaç öğe ve hangi türlerde olduğunu bildirir. Bu biçimlerin içeriğini JSON-LD kadar ayrıntılı çözümlemez; amaç yalnızca sayfada birden çok biçimin bulunduğunu fark etmenizi sağlamaktır.

Bu araç bir arama motorunun doğrulayıcısı değildir ve şunları söylemez:

• Şemanızın arama sonucunda zengin görünüm sağlayıp sağlamayacağını.
• Bir arama motorunun belgelerindeki zorunlu ya da önerilen alan listelerine uygunluğu.
• Şemadaki bilgilerin sayfanın görünen içeriğiyle uyumlu olup olmadığını; örneğin fiyatın sayfadaki fiyatla aynı olduğunu.
• Değerlerin doğruluğunu: URL, tarih ve para birimi gibi alanlar biçimsel olarak denetlenmez.
• Betikle sonradan eklenen blokları: yalnızca sunucudan gelen HTML okunur.

Bu nedenle sonucu bir ön kontrol olarak kullanın. Yayına almadan önce, arama motorunun kendi araçlarında ve Search Console raporlarında da şemayı doğrulamak iyi bir alışkanlıktır.

Kısacası bu araç, şemanızın biçimsel olarak okunabilir ve tutarlı olup olmadığını görmeniz için hızlı bir ön kontroldür. Sonuçlar sayfanın o an sunucudan gelen HTML’ine aittir; sayfayı güncellediğinizde testi yeniden çalıştırın. Şablon ya da eklenti değişikliklerinden sonra yeniden test etmek özellikle önemlidir, çünkü bu tür değişiklikler şema çıktısını sessizce bozabilir.