murattunalı.

Yapılandırılmış veri hata ayıklama.

Yapılandırılmış veri hataları sayfada hiçbir belirti göstermez; yalnız bir doğrulama aracıyla ya da bir testle görünür hâle gelir.

Yapılandırılmış verinin en sinsi yanı sessiz kırılmasıdır. Bir şema bloğu bozulduğunda sayfa normal görünmeye devam eder, hiçbir hata mesajı çıkmaz, hiçbir görsel belirti olmaz. Yalnızca makineler o bloğu okuyamaz — ve bunu size kimse söylemez. Kusur aylarca yaşayabilir.

Bu yüzden şema, yazıldıktan sonra bir kez doğrulanıp bırakılamaz. Doğrulama, dağıtım sürecinin bir parçası olmalıdır; aksi hâlde bir sonraki içerik değişikliği sessizce bozar.

İki katman: sözdizimi ve anlam

Hata ayıklamanın iki ayrı katmanı var ve ikisi farklı şeyleri yakalıyor. Birincisi sözdizimidir: blok geçerli bir veri yapısı mı, ayrıştırılabiliyor mu? Tek bir eksik virgül ya da kaçırılmamış bir tırnak, o sayfadaki tüm yapılandırılmış veriyi geçersiz kılar — kısmi okuma diye bir şey yoktur.

İkincisi anlamdır: çıkan düğüm listesi sitenin gerçekten ne olduğunu anlatıyor mu? Sözdizimi kusursuz ama içeriği anlamsız bir grafik teknik olarak geçerlidir ve hiçbir işe yaramaz. Doğrulama araçları birinci katmanı otomatik yakalar; ikincisi insan yargısı gerektirir.

  1. Sözdizimi — blok ayrıştırılabiliyor mu? Otomatik araçlar yakalar.
  2. Zorunlu alanlar — tipin gerektirdiği alanlar dolu mu? Otomatik araçlar uyarır.
  3. Biçim — tarih, süre ve sayı alanları beklenen biçimde mi? Otomatik.
  4. Kimlik bağları — atıf yapılan kimlikler gerçekten tanımlı mı? Kısmen otomatik.
  5. Ekranla tutarlılık — şemada yazan ekranda da var mı? İNSAN yargısı.
  6. Anlam — grafik siteyi doğru anlatıyor mu? İNSAN yargısı.

Son iki satır en önemlileridir ve hiçbir araç tarafından kapsanmaz. Şemada olup ekranda olmayan bir bilgi, doğrulama aracında yeşil görünür — çünkü araç sayfayı okumaz, yalnız bloğu okur. O ihlali yalnız bir insan ya da özel yazılmış bir test yakalar.

Yaygın kırılma noktaları

Gerçek sitelerde tekrar eden hatalar bellidir ve çoğu içerik değişikliğinden doğar.

Kaçırılmamış özel karakterler. İçerikte geçen bir tırnak işareti ya da ters eğik çizgi, şema bloğuna doğrudan yazıldığında yapıyı bozar. Bu, elle yazılan şemalarda en sık kırılma sebebidir ve üreticiden çıkan şemalarda hiç görülmez — çünkü kaçırma otomatik yapılır.

Boş kalan alanlar. Bir içerik alanı silindiğinde şemada boş bir değer kalabilir. Boş bir alan, olmayan bir alandan kötüdür: tipi doldurmuş gibi görünür ama bilgi taşımaz.

Kopuk kimlik atıfları. Bir düğüm, artık üretilmeyen bir düğümün kimliğine işaret edebilir. Grafik teknik olarak geçerli kalır ama bağ boşluğa gider ve yapı çözülür.

Bayat tarihler. Sayfa güncellenir, şemadaki tarih kalır. Bu, tazelik sinyalini yanlış yapar ve zamanla motorun o sinyale güvenmeyi bırakmasına yol açar.

Kalıcı çözüm: teste bağlamak

Elle doğrulama bir kereye mahsus işe yarar. Kalıcı çözüm, şema kontrolünü dağıtım sürecine bağlamaktır: her sayfanın blokları ayrıştırılır, düğüm tipleri listelenir ve beklenen yapıyla karşılaştırılır.

Bu sitede o kontrol doğrulama süitinin içinde yaşıyor. Her rotada şema grafiğinin beklenen düğümleri taşıdığı, kimlik bağlarının kopuk olmadığı ve ekrandaki soru-cevap bloklarının şemayla eşleştiği her koşumda ölçülüyor. Bir içerik değişikliği şemayı bozarsa, kusur dağıtım anında görünür — bir sonraki denetimde değil.

Ve en değerli test türü, ters nöbetçidir: olmaması gereken bir şeyin eklenmediğini doğrulayan test. Uydurma bir profil bağı, ölçülmemiş bir sonuç rakamı ya da yayımlanmamış bir fiyat — üçü de iyi niyetle eklenebilir ve üçü de kural ihlalidir. Ters nöbetçi, gelecekteki iyi niyeti de denetler.

Doğrulama araçları ve sınırları

Elde birkaç araç var ve her biri farklı bir soruyu cevaplıyor. Schema.org'un kendi doğrulayıcısı sözdizimi ve tip geçerliliğine bakar — en geniş kapsamlı olanı budur. Arama motorlarının zengin sonuç test araçları ise dar bir soruyu sorar: bu blok, bizim zengin sonuç üretmemiz için yeterli mi? İkisi farklı şeylerdir ve biri geçip diğeri kalabilir.

Bu ayrım pratikte kafa karıştırıyor. Zengin sonuç aracında «uygun değil» uyarısı almak, şemanın bozuk olduğu anlamına gelmez — yalnız o motorun o görünüm için istediği alanların eksik olduğunu gösterir. Şema yine de geçerli olabilir ve yanıt motorları için işini yapabilir.

  1. Genel doğrulayıcı — sözdizimi ve tip geçerliliği. En geniş kapsam.
  2. Zengin sonuç testi — belirli bir görünüm için yeterlilik. Dar kapsam.
  3. Arama konsolu raporları — canlı sayfalarda tespit edilen hatalar. Gecikmeli ama gerçek.
  4. Kendi testin — projeye özgü kurallar. Araçların sormadığı soruları sorar.

Dördüncü satır en değerlisidir çünkü diğer üçünün kapsamadığı boşluğu doldurur: şemadaki bilginin ekranda da var olduğu, uydurma bir alanın eklenmediği ve tarihlerin gerçekten güncel olduğu — hiçbiri genel bir araç tarafından denetlenemez ve hepsi bir testle denetlenebilir.

Hata ayıklamanın sırası

Bir sayfada şema sorunu olduğundan şüphelenildiğinde, izlenecek sıra zamandan kazandırır. Önce blok gerçekten sayfada mı — kaynağa bakıp varlığını doğrulayın; şaşırtıcı sayıda vakada blok bir koşula takılmış ve hiç basılmamıştır. Sonra ayrıştırılabiliyor mu — bir doğrulayıcıya yapıştırın. Sonra tipler doğru mu, alanlar dolu mu. En son ekranla tutarlı mı.

Bu sıra atlandığında en çok yapılan hata, anlam katmanında saatler harcayıp sorunun aslında basit bir sözdizimi kırılması olduğunu geç fark etmektir. İlk iki adım bir dakika sürer ve vakaların büyük kısmını çözer.

Ve bir kez çözülen her hata bir teste dönüştürülmelidir. Şema kırılmalarının neredeyse tamamı tekrar eder — çünkü sebepleri yapısaldır, tesadüfi değil. Bir kaçırma hatası bir kez olduysa yine olacaktır; onu yakalayan bir test, aynı saatleri bir daha harcamamayı sağlar.

KAYNAKLAR