Yapılandırılmış veri: sayfanın anlamını doğru modelle

Yapılandırılmış veri, sayfadaki varlıkları ve ilişkileri makinenin okuyabileceği şekilde tarif eder. Bir ürünün adı, fiyatı ve stok durumu veya bir makalenin başlığı, yazarı ve tarihi açık alanlara dönüşür. İşaretleme eksik bir hizmeti var etmez, zayıf bir metni güvenilir yapmaz. Önce ziyaretçinin gördüğü bilgiyi düzenleyin, sonra bu bilgiyi uygun biçimde işaretleyin.

Google'ın genel kurallarına göre verinin sayfayı doğru temsil etmesi gerekir; yanıltıcı veya görünür içerikle çelişen bilgi uygun değildir. Geçerli işaretleme, zengin sonucun mutlaka gösterileceği anlamına gelmez. “Testten geçti” ile “aramada şu görünüm kesin çıkacak” farklı cümlelerdir. Raporlarınıza bu farkı baştan yerleştirin.

Eğitim senaryosu: Hayali “Pusula Atölye” sitesindeki “Ahşap masa bakımı” yazısında başlık ve yazar ziyaretçiye açıkça gösteriliyor. Aşağıdaki parça yalnız kavramı anlatan örnektir; canlı sayfanın bütün gereksinimlerini karşılayan hazır şablon değildir. Gerçek projede ilgili Google özellik rehberinden gerekli ve önerilen alanları kontrol edin.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Ahşap masa bakımı",
  "author": {
    "@type": "Organization",
    "name": "Pusula Atölye"
  }
}

Bu modelde olmayan tarih veya kişiyi sırf alan dolsun diye üretmeyin. Gerçek yazar kişi ise uygun kişi kaydıyla ve görünür biyografiyle ilişkilendirin. Örneği kendi eğitim dosyanıza kopyalayın, hayali adı değiştirin ve her alanın sayfada nereden geldiğini iki sütunlu tabloda gösterin. “Veri alanı → görünür karşılık” eşleştirmesi, sadece kod yazmaktan daha önemli bir denetim alışkanlığıdır.

Çok sayıda sayfada aynı şema üretilecekse içerik yönetimi alanlarını kaynak kabul edin. Elle kopyalanan fiyatlar veya tarihler kısa sürede tutarsızlaşabilir. Veri akışını tasarlarken bir ürünün fiyatı değiştiğinde hem ekranın hem işaretlemenin aynı kaynaktan güncellenmesini hedefleyin.

İlk katman sözdizimidir: JSON doğru mu, tırnaklar ve veri türleri uygun mu? İkinci katman anlamdır: isim, URL, teklif ve diğer alanlar gerçek sayfayla eşleşiyor mu? Üçüncü katman Google'ın ilgili arama özelliğidir: seçilen tür destekleniyor mu, özellik rehberindeki şartlar karşılanıyor mu? Yalnız ilk katmanı geçmek diğer ikisini doğrulamaz.

Rich Results Test ile Google'ın desteklediği uygun türleri inceleyin. Genel schema doğrulayıcıları daha geniş söz varlığını kontrol edebilir; bu nedenle iki aracın aynı sonucu göstermemesi her zaman çelişki değildir. Yayın sonrasında Search Console'daki ilgili geliştirme raporları varsa hataları sayfa örnekleri üzerinden değerlendirin.

Eğitim senaryosu: Hayali mağazada fiyat ekranda 1.250 TL, işaretlemede 950 TL kalmıştır. Kod teknik olarak geçerli olsa bile içerik yanlıştır. Hata önceliği “yeşil test” elde etmek değil, fiyat kaynağını birleştirmektir. Teslim kriteriniz hem kullanıcı ekranının hem verinin aynı fiyatı göstermesidir. İndirim başlangıcı ve bitişi gibi sınır durumlarını da deneyin; tek ürünle doğrulayıp tüm kataloğu güvenli saymayın.

Arama özellikleri zaman içinde değişir. Google'ın güncel değişiklik kaydına göre FAQ zengin sonuçları 7 Mayıs 2026 itibarıyla gösterilmiyor; ilgili dokümantasyon Haziran 2026'da kaldırıldı. Bu nedenle bir akademi veya ticari siteye FAQ işaretlemesi ekleyerek arama sonuçlarında geniş soru kutuları vaat etmek güncel bir yaklaşım değildir. Sorular ve yanıtlar okuyucuya faydalıysa içerikte bulunabilir; değeri yalnız arama görünümüne bağlanmamalıdır.

Benzer biçimde schema.org içinde bir türün bulunması, Google'ın o tür için özel bir sonuç göstereceğini kanıtlamaz. Bir eklentinin onlarca tür üretmesi kalite ölçüsü değildir. Gereksiz ve birbiriyle çelişen işaretlemeler denetim yükünü artırır. Önceliği gerçek sayfa türüne ve ziyaretçinin gördüğü anlamlı bilgiye verin.

Ödev: Eski bir SEO makalesindeki yapılandırılmış veri önerisini seçin. Resmi belgede bugün desteklenen davranışla karşılaştırın. Raporunuza kaynak adresi, kontrol tarihi ve değişen varsayımı yazın. Amacınız bir yazarı hatalı ilan etmek değil, tarihli teknik bilgiyi güncel karar sürecine çevirmektir.

Her şablonun sahibi, veri kaynağı ve kabul kriteri belli olsun. Ürün sayfasındaki stok değişimini ticaret ekibi, makale tarihini editör, çıktı doğruluğunu geliştirici birlikte takip edebilir. Birden fazla eklenti aynı varlığı farklı kimliklerle üretiyorsa önce çıktı envanteri çıkarın; rastgele birini silmek yerine hangi parçanın gerekli olduğunu belirleyin.

1. Temsilci sayfaların mevcut JSON-LD çıktısını kaydedin.
2. Görünür içerikle uyuşmayan alanları işaretleyin.
3. Desteklenen özellik rehberini ve kontrol tarihini ekleyin.
4. Düzeltmeyi test ortamında uygulayın.
5. Canlı URL üzerinde yeniden doğrulayın.
6. Fiyat, stok, yazar veya şablon değiştiğinde tekrar kontrol tetikleyin.

Sahte puanlar, uydurma yorum sayıları ve gerçekte verilmeyen hizmetler işaretlenmez. Gerçek müşteri yorumları da her tür işletme sayfasında istenen yıldız görünümünü sağlayacak diye düşünülmemelidir; ilgili özelliğin kendi kuralları incelenir. Başarılı çalışma, eklenen etiket sayısıyla değil doğru ve sürdürülebilir veriyle ölçülür.

Son tesliminiz bir örnek kod, alan eşleme tablosu, doğrulama çıktısı ve bakım sorumlusundan oluşsun. Böylece bir sonraki geliştirici yalnız kodu değil, kodun neden o şekilde kurulduğunu da anlayabilir.