Şema ve yapılandırılmış veriyi öğrenmek

Google bu kodla ne yapar?

Google, web'de bulduğu yapılandırılmış veriyi sayfanın içeriğini anlamak için ve ayrıca web ile dünya hakkında bilgi toplamak için kullandığını yazıyor: kişiler, kitaplar, şirketler. Yani bu kod her şeyden önce bir SEO tekniği değil, ortak bir dildir.

Üç biçim destekleniyor: JSON-LD, Microdata ve RDFa. Google, işaretleme geçerli ve düzgün uygulandığı sürece üçünün de kendisi için eşit olduğunu yazıyor ve çoğu durumda JSON-LD'yi öneriyor; çünkü sayfa HTML'inin arasına serpilmek yerine kendi script bloğunda durur. Pratikte de insanların yazdığı bu.

Ve kısa kesilmesi gereken bir beklenti: bu kodu yazmak zengin sonuç almak demek değildir. Doğru işaretleme sayfayı zengin bir sunuma uygun hâle getirir; gösterme kararı Google'da kalır. Söyleyecek şeyi olmayan bir sayfanın, üzerine şema konunca da söyleyecek şeyi olmaz.

Bir adım ötesi: sunumların kendisi de geri çekiliyor. Google, belge güncellemelerinde SSS zengin sonucunun 7 Mayıs 2026'dan itibaren Arama'da görünmeyeceğini yazdı ve ardından o belgeyi tümüyle kaldırdı; aynısını daha önce "nasıl yapılır" zengin sonucu için de yapmıştı. Yani 2023'te yazmaya değer olan işaretleme bugün aynı kod ve aynı ölçüde geçerli, ama sonuçlarda hiçbir şey göstermiyor. Bu site de soru ve yanıt içeren sayfalarda FAQPage basıyor ve o tarihten beri ondan bir zengin sonuç çıkmıyor; yerinde kalması sorun değil, çünkü gerçekten görünen içeriği tanımlıyor, ama ondan bir şey beklemek sorun.

Hangi şema türü sizin sayfanıza aittir?

Yanıt kısa: sayfanın gerçekte olduğu tür. Bir hosting satış sayfası Product'tır. Bir blog yazısı Article'dır. Bir iletişim sayfası Organization ya da LocalBusiness'tır. Bir hizmet sayfası Service'tir. Türü, hangi zengin sonucun daha güzel göründüğüne bakarak seçmek, sonradan manuel işlemle biten hatadır.

Her türün zorunlu ve önerilen özellikleri vardır ve bunlar Google'ın o tür için hazırladığı belgede listelenir. Örneğin LocalBusiness türünün iki zorunlu özelliği var: adres ve ad. Google, bir nesnenin zengin sonuca uygun olması için bütün zorunlu özelliklerin bulunması gerektiğini yazıyor.

Tek bir sayfada birden çok tür bulunması normaldir: bir blog yazısı Article'dır, izi BreadcrumbList'tir, yayıncısı Organization'dır. Bunları temiz yazmanın yolu graf kullanmaktır: birkaç düğüm taşıyan ve düğümlerin birbirine tanımlayıcıyla atıf yaptığı tek bir JSON-LD bloğu. Böylece "kurum" bir kez tanımlanır ve diğer bütün düğümler ona işaret eder.

Üç fikri bir arada tutan küçük bir örnek: doğru tür, zorunlu bir özellik ve tanımlayıcıyla atıf.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "İşletmenin adı",
      "url": "https://example.com/"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "headline": "Sayfada basılı olan başlığın aynısı",
      "datePublished": "2026-09-05",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}

Bu birkaç satırda üç şey görünüyor. Birincisi, her düğümün bir tanımlayıcısı var ve o tanımlayıcı bir adres; dolayısıyla başka her şey ona işaret edebilir. İkincisi, makalenin yayıncısı yeniden tanımlanmamış, yalnızca kurumun tanımlayıcısına atıf yapılmış; aynı şeyin iki farklı tanımını engelleyen tek hamle budur. Üçüncüsü, makale başlığı optimize edilmiş bir varyantı değil, sayfada basılı olan başlığın kendisi; bu da doğrudan bir sonraki bölümün kuralına götürür.

Sayfada olmayanı neden işaretlememelisiniz?

Google bunu iki ayrı yerde yazmış ve ikisinde de açık sözlü. Genel yönergelerde: "Sayfanın okurlarına görünmeyen içeriği işaretlemeyin." Ve tanıtım sayfasında: yalnızca yapılandırılmış veri taşımak için boş sayfalar oluşturmayın ve kullanıcının göremediği bilgiler hakkında, o bilgi doğru olsa bile, işaretleme eklemeyin.

Tartışma o son sözcüklerde biter. En sık duyduğumuz gerekçe şudur: "ama sayı gerçekten doğru, sadece sayfaya yazmadık". Politika açısından bu hiçbir şeyi değiştirmez.

Sonucun bir adı var: "yapılandırılmış veri sorunu", Search Console'da bildirilen manuel işlemlerden biri. Etkisi, sayfanın zengin sonuçlara uygunluğunu yitirmesi. Fazla işaretlemenin kazandıracağı sanılan şey, tam olarak kaybettirdiği şeydir.

Doğru sıra basit ve her zaman tek yönlü: önce bilgiyi sayfaya koyun, sonra işaretleyin. Asla tersi değil.

Kendi topladığınız puan neden yıldız getirmez?

Küçük bir pazarda yanlış şemanın çoğu burada yazılır. Google'ın değerlendirme snippet'i belgesinde birebir okunması gereken bir madde var: değerlendirilen varlık kendisi hakkındaki değerlendirmeleri denetliyorsa, LocalBusiness ya da başka herhangi bir Organization türü yapılandırılmış veri kullanan sayfaları yıldızlı değerlendirme özelliğine uygun değildir.

Google'ın verdiği örnek tam da bizim yaygın durumumuz: A varlığı hakkındaki bir değerlendirmenin, doğrudan yapılandırılmış verisinde ya da gömülü bir üçüncü taraf widget'ı aracılığıyla, A varlığının kendi sitesinde bulunması. Yani değerlendirmeler gerçek olsa bile kendi değerlendirme kutunuz.

Kısıtlamanın bütün türlere değil iki türe bağlı olduğuna dikkat edin. Product ve Software App gibi türlerde puan gösterimi hâlâ destekleniyor; Google'ın kapattığı şey, işletme ve kurum türlerinde kendi topladığınız puandır. LocalBusiness için ayrıca, puan özelliğinin yalnızca başka işletmeler hakkında değerlendirme toplayan siteler için önerildiğini söylüyor.

Daha az dikkat çeken bir kural daha: işaretlediğiniz değerlendirme, ziyaretçiye aynı sayfadan ulaşılabilir olmalı ve sayfada değerlendirme içeriği bulunduğu hemen anlaşılmalıdır. İşaretlemeye toplu bir puan yazıyorsanız, aynı puanın sayfada da görünmesi gerekir.

Nasıl test edilir ve bir sayfa kaç blok taşır?

Google iki ayrı aşamayı adıyla anıyor ve bu ayrım önemli. Geliştirme sırasında Zengin Sonuç Testi; yayına aldıktan sonra Search Console'daki zengin sonuç durum raporları; çünkü işaretleme genellikle siz yazarken değil, sonradan şablon ve sunum sorunları yüzünden bozulur. URL Denetleme aracı ise Google'ın yapılandırılmış verinizi hiç bulup bulmadığını görmek içindir. Kodun kendisini, zengin sonuç uygunluğu sorusundan bağımsız denetlemek içinse schema.org'un kendi doğrulayıcısı var.

Şimdi araçların size göstermediği tuzak: bir sayfa birden çok JSON-LD bloğu taşıyabilir ve genelde taşır; çünkü tema bir tane, her eklenti bir tane basar. Kendi sayfalarımızdan birinde 5 Eylül 2026'da dört ayrı blok saydık: temadan gelen beş düğümlü bir graf ve eklentilerin bastığı üç bağımsız blok. Tek komutla sayın:

curl -s -A "Mozilla/5.0" "https://example.com/page/" \
| grep -c 'application/ld+json'

Neden önemli? Çünkü tek sayfada birkaç blok bulununca aynı şey iki kez ve iki farklı biçimde tanımlanabilir. Bizim o sayfamızda birbiriyle uyuşmayan iki breadcrumb düğümü var: biri iki basamaklı, biri üç. Bu denetim tam da bunu bulmak için vardır ve biz onu kendi sitemizde bulduk. Doğru kural, her varlık için tek bir doğruluk kaynağı tutmak ve geri kalan her şeyin ona atıf yapmasıdır. Birkaç eklentinin aynı anda şema bastığı bir sitede bu birleştirme, genellikle bir SEO projesinin yapması gereken ilk iştir.