
Bir sayfada başlık, yazar adı ve yayın tarihi görmek insan için kolaydır. Yazılımın bu bilgilerin görevini ayırt etmesi ise açık işaretlemeyle desteklenebilir. Yapılandırılmış veri bu amaçla kullanılır. Görünmeyen başarı vaatleri eklemek için değil, sayfada gerçekten bulunan bilgileri tutarlı biçimde anlatmak için hazırlanmalıdır.
Önce sayfanın ne olduğunu belirleyin
Bir haber yazısı, ürün sayfası ve tarif aynı veri modelini gerektirmez. Sitenizdeki bütün URL'lere aynı geniş kod bloğunu eklemek doğru başlangıç değildir. Sayfanın ana amacını ve desteklemek istediğiniz arama görünümüne ilişkin resmî gereklilikleri inceleyin.
Örneğin sıradan bir blog makalesinde ürün fiyatı veya değerlendirme puanı yoksa bu alanları sırf dikkat çekici sonuç elde etmek için üretmeyin. Sayfada yazar adı varsa gerçek yazarı gösterin; kurumun veya editörün rolünü karıştırmayın. İşaretlemenin kapsamı içeriğin önüne geçmemelidir.
Görünür metinle aynı bilgiyi kullanın
Tarihlerin, başlığın ve görsel adresinin sayfada görünen sürümle uyumlu olması gerekir. İçerik yönetim sisteminde başlık değişip veri bloğu eski kalıyorsa iki ayrı gerçeklik oluşur. Bilgiyi mümkün olduğunca aynı kayıt alanlarından üretmek bu riski azaltır.
Yayın sürecinde şu karşılaştırmayı yapın:
- Görünür başlık ile veri alanındaki başlık aynı yazıyı anlatıyor mu?
- Yazar bilgisi gerçek kişi veya kurumla tutarlı mı?
- Yayın ve güncelleme tarihleri doğru anlamı taşıyor mu?
- Görsel adresi erişilebilir ve ilgili mi?
- Eklenen bilgi okur tarafından da bulunabiliyor mu?
Bu liste sözdizimi kadar editoryal doğruluğu da kapsar.
Şablona uygun, sürdürülebilir üretim seçin
JSON-LD, yapılandırılmış veriyi sayfaya eklemek için yaygın bir yöntemdir. Ancak veri biçiminin geçerli olması, içerik modelinin doğru seçildiğini tek başına kanıtlamaz. Üretim kodunu tema içinde rastgele çoğaltmak yerine ortak bir bileşenden yönetmek bakım işini kolaylaştırabilir.
Birden fazla eklenti aynı makale için farklı veri blokları üretiyorsa bunları birlikte inceleyin. Sorun yalnızca kod miktarı değildir; çelişkili tarihler veya farklı yazarlar kafa karıştırabilir. Yeni işaretleme eklemeden önce mevcut sayfa kaynağında neler bulunduğunu araştırın.
Doğrulama aracını doğru yorumlayın
Zengin Sonuçlar Testi gibi araçlar belirli desteklenen türlerde teknik sorunları belirlemeye yardımcı olur. Hata ile uyarı aynı anlama gelmeyebilir. Eksik bir önerilen alanı değerlendirirken ilgili özellik belgesine bakın; olmayan veriyi doldurmak için tahmin yürütmeyin.
Testte uygun görünmek, arama sonucunda zengin görünümün kesin olarak sunulacağı anlamına gelmez. Google işaretlemeyi, sayfayı ve kalite koşullarını birlikte değerlendirir. Bu yüzden “kod eklendi, yıldızlar garanti” gibi vaatler gerçekçi değildir.
İçerik değiştiğinde veriyi de gözden geçirin
Bir yazı birleştirildiğinde, adresi taşındığında veya kapak görseli değiştiğinde işaretleme de etkilenebilir. Yayın kontrolünüzde sayfa kaynağını ve test sonucunu kısa biçimde doğrulayın. Özellikle ortak şablon düzenlemelerinde farklı sayfa türlerinden örnekler seçin.
İyi uygulama, editörün her makalede uzun bir kod bloğuyla uğraşmasını gerektirmez. Doğru veri alanları ve uygun şablonlar günlük üretimi basitleştirir. Yapılandırılmış verinin değeri, arama motoruna gerçek içerik hakkında daha net bilgi sunmasındadır; içeriğin kendisindeki eksikleri telafi etmesinde değildir.
Bir makale şablonunu güncellediğinizde üç kayıtla deneyebilirsiniz: bütün alanları dolu yazı, yazarı kurum olan yazı ve kapak görseli bulunmayan yazı. Eksik alanın nasıl ele alındığını görün. Boş görsel adresi üretmek veya olmayan kişiyi yazar gibi göstermek yerine uygun alanı kurala göre yönetmek gerekir. İçerik panelindeki alan etiketlerini de editörün anlayacağı biçimde yazın. “Yayın tarihi” ile “gerçek son güncelleme” aynı işlevi taşımamalıdır. Teknik üretim tutarlı olduğunda editörün manuel veri bloğu kopyalaması azalır ve yeni içeriklerde eski yazıdan kalan bilgilerin taşınma riski düşer.