Örneklerle Schema Markup Rehberi: Yapılandırılmış Veriyi Doğru Kurmak

SEO denetimlerinde yapılandırılmış veri tarafında genellikle iki farklı durumla karşılaşılır. Schema markup ya hiç kullanılmıyordur ya da yıllar önce bir eklenti tarafından oluşturulmuş, sonrasında kontrol edilmediği için eksik veya hatalı hale gelmiş bir yapı vardır.

Her iki senaryoda da arama motorunun sayfanın ne anlattığını kendi başına çözmesi beklenir ve gereğinden fazla yorum alanı bırakılır.

Schema markup temelde oldukça basit bir görevi yerine getirir. Sayfada kullanıcıya sunulan bilgileri, arama motorlarının anlayabileceği standart bir formatta yeniden tanımlar. Örneğin bir ürün sayfasındaki ürün adı, fiyat, stok durumu, marka veya kullanıcı puanı gibi bilgiler yapılandırılmış veri üzerinden açık biçimde belirtilebilir.

Arama sonuçlarında bunun karşılığı fiyat, stok bilgisi, yıldızlar, breadcrumb yapısı veya farklı zengin sonuç formatları olabilir. Doğru bir kurulum, aynı sıralama pozisyonunda sonucun daha fazla bilgiyle gösterilmesine ve tıklama oranının desteklenmesine yardımcı olabilir.

Önce en temel sorudan başlayalım.

Google Neden JSON-LD Kullanılmasını Öneriyor?

Google, yapılandırılmış veri tarafında Microdata, RDFa ve JSON-LD formatlarını destekliyor. Ancak kendi dokümantasyonunda JSON-LD kullanımını öneriyor.

Bunun en önemli nedeni uygulama ve bakım sürecinin daha kolay olmasıdır.

Microdata ve RDFa kullanıldığında yapılandırılmış veri doğrudan HTML elemanlarının içine dağıtılır. Ürün adı bir <div> içerisinde, fiyat farklı bir <span> içerisinde, puan bilgisi ise sayfanın başka bir bölümünde tanımlanabilir.

Bu yapı nedeniyle tema üzerinde yapılan küçük bir değişiklik, eklenen yeni bir HTML kapsayıcısı veya A/B testi sırasında değiştirilen DOM yapısı markup’ın fark edilmeden bozulmasına yol açabilir.

JSON-LD’de ise verinin tamamı görünür HTML’den bağımsız bir <script type=”application/ld+json”> bloğunda tutulur. Tasarım katmanında yapılan değişikliklerin yapılandırılmış veriyi etkileme ihtimali böylece azalır.

JSON-LD’nin bir başka avantajı, @id kullanarak farklı varlıkları birbirine bağlayabilmesidir. Bir makalenin yazarı, yayımlayan kuruluş ve web sitesi ayrı kayıtlar şeklinde tanımlanabilir ve aynı veri grafiği içerisinde ilişkilendirilebilir.

Bu yapı büyük sitelerde veri ilişkilerinin daha düzenli biçimde yönetilmesini de kolaylaştırır.

Yeni bir yapılandırılmış veri kurulumu yapılacaksa JSON-LD, hem bakım süreci hem de varlıklar arasındaki ilişkilerin yönetimi açısından güçlü bir başlangıç noktasıdır.

Yapılandırılmış Veri Gerçekte Ne İşe Yarar?

Schema markup’ın kullandığı sözlük Schema.org tarafından tanımlanır. Schema.org ürün, makale, etkinlik, kişi ve kuruluş dahil çok sayıda varlık türü için ortak bir sözlük sunar.

Sayfadaki bilgiler bu sözlüğe uygun olarak tanımlandığında arama motoru, sayfanın ne anlattığını sadece metinsel ipuçlarından çıkarmak zorunda kalmaz. İlgili bilgileri yapılandırılmış veri üzerinden doğrudan okuyabilir.

Burada iki farklı işlevi ayırmak önemli.

İlki anlamlandırmadır. Yapılandırılmış veri, sayfanın hangi varlıktan bahsettiğini ve bu varlığın diğer varlıklarla nasıl ilişkili olduğunu daha açık biçimde gösterir.

İkincisi zengin sonuç uygunluğudur. Ürün fiyatı, stok durumu, etkinlik tarihi veya video bilgisi gibi alanlar, Google’ın desteklediği durumlarda arama sonucunun daha fazla bilgi içermesine imkan verebilir.

Buradaki önemli nokta uygunluk kavramıdır.

Schema markup eklemek, ilgili zengin sonucun mutlaka gösterileceği anlamına gelmez. Google yapılandırılmış veriyi teknik olarak doğru bulsa bile sorguya, site kalitesine ve arama deneyimine göre zengin sonucu göstermeyebilir.

Yapılandırılmış verinin doğrudan bir sıralama faktörü olmadığını da unutmamak gerekir.

Bir sayfaya schema eklemek, sayfanın otomatik olarak birkaç sıra yükselmesini sağlamaz. Asıl katkı, arama sonucunda daha fazla bilgi gösterilebilmesi ve sayfadaki varlıkların makine tarafından daha açık biçimde anlaşılmasıdır.

Bu yüzden yapılandırılmış veriyi bir sıralama hilesi gibi görmek yerine, arama motoruna daha temiz veri sunan teknik SEO katmanı olarak ele almak daha doğru olur.

Schema Markup Formatları: Microdata, RDFa ve JSON-LD

Farkı daha net görmek için aynı ürünün Microdata ile işaretlendiği basit bir örneğe bakalım:

<div itemscope itemtype=”https://schema.org/Product”>

  <h1 itemprop=”name”>Pamuklu Oversize Tişört</h1>

  <div itemprop=”offers” itemscope itemtype=”https://schema.org/Offer”>

    <span itemprop=”price” content=”449.90″>449,90</span>

    <meta itemprop=”priceCurrency” content=”TRY”>

  </div>

</div>

Burada yapılandırılmış veri doğrudan sayfanın tasarım kodunun içine yerleştirilmiştir.

Şablona daha sonra müdahale eden bir geliştirici, kod içerisinde markup bulunduğunu bilmiyorsa bu yapıyı fark etmeden bozabilir.

RDFa da benzer şekilde HTML elemanları üzerinden çalışır ve günümüzde yeni kurulumlarda daha az tercih edilir.

JSON-LD ise aynı veriyi HTML yapısından ayırır:

{

  “@context”: “https://schema.org”,

  “@type”: “Product”,

  “name”: “Pamuklu Oversize Tişört”,

  “offers”: {

    “@type”: “Offer”,

    “price”: 449.90,

    “priceCurrency”: “TRY”

  }

}

Yeni bir projede seçim çoğu zaman nettir: JSON-LD.

Ancak düzgün çalışan mevcut bir Microdata kurulumu varsa sadece formatı değiştirmek için bu yapıyı aceleyle kaldırmak gerekmez. Geçiş, tema veya altyapı yenilemesi gibi teknik çalışmalarla birlikte planlanabilir.

Aynı bilgiyi iki farklı format üzerinden iki kez tanımlamak da doğru değildir. Zaman içinde değerler birbirinden ayrışabilir ve örneğin aynı sayfada iki farklı fiyat veya stok bilgisi oluşabilir.

Çelişkili yapılandırılmış veri, bazı durumlarda hiç yapılandırılmış veri bulunmamasından daha ciddi sorun yaratabilir.

Yapılandırılmış Veri Kur ve Unut Alanı Değildir

Schema standartları ve Google’ın desteklediği zengin sonuç türleri zaman içerisinde değişebiliyor.

Bunun en bilinen örneklerinden biri data-vocabulary.org desteğinin kaldırılmasıdır. Google eski sözlüğe dayanan yapılandırılmış veri desteğini sonlandırdıktan sonra bu sistemi kullanan sitelerde breadcrumb ve benzeri işaretlemeler geçerliliğini kaybetti.

Eski Structured Data Testing Tool da benzer şekilde kullanımdan kaldırıldı. Bugün Google’ın zengin sonuç uygunluğunu test etmek ve Schema.org sözlüğüne göre doğrulama yapmak için farklı araçlar kullanılıyor.

Dolayısıyla schema markup, bir kez kurulup yıllarca kontrol edilmeden bırakılabilecek bir teknik alan değildir.

Tema değişiklikleri, eklenti güncellemeleri, altyapı geçişleri ve Google dokümantasyonundaki önemli değişikliklerin ardından yapılandırılmış verinin yeniden kontrol edilmesi gerekir.

Başlamadan Önce Beş Temel Kural

1. Markup Görünür İçerikle Eşleşmeli

Sayfada kullanıcıya gösterilmeyen bir bilgiyi yapılandırılmış veriye eklemek doğru değildir.

Ürün sayfasında yorum bulunmadığı halde aggregateRating eklemek, kullanıcıya indirimli fiyat gösterilmediği halde markup içerisinde indirimli fiyat tanımlamak veya stokta olmayan bir ürünü InStock olarak işaretlemek yanlış veri üretir.

Yapılandırılmış veri, sayfada kullanıcıya gösterilen bilginin makine tarafından okunabilir karşılığı olmalıdır.

2. Sayfanın Ana Varlığını İşaretleyin

Her sayfaya mümkün olan bütün schema türlerini eklemek daha güçlü bir SEO sinyali yaratmaz.

Bir ürün detay sayfasının ana varlığı Product, blog yazısının Article veya BlogPosting, fiziksel mağaza sayfasının ise uygun bir LocalBusiness alt tipi olabilir.

Buradaki amaç schema sayısını artırmak değil, sayfanın ne olduğunu doğru biçimde tanımlamaktır.

3. Schema.org ile Google Şartlarını Karıştırmayın

Bir yapılandırılmış verinin Schema.org açısından geçerli olması, Google’da zengin sonuç oluşturması için tek başına yeterli değildir.

Schema.org oldukça geniş bir sözlüktür. Google ise arama deneyiminde bu sözlüğün belirli bölümlerini kullanır ve her zengin sonuç türü için kendi ek şartlarını belirleyebilir.

Bu yüzden iki kontrol ayrı ayrı yapılmalıdır:

• Schema.org sözlük doğruluğu
• Google zengin sonuç uygunluğu

4. Yayına Almadan Önce Test Edin

JSON sözdizimi hatalara karşı toleranslı değildir.

Eksik bir tırnak, fazladan bırakılan bir virgül veya kapanmamış bir parantez tüm JSON-LD bloğunu geçersiz hale getirebilir.

Özellikle manuel hazırlanan schema kodlarının yayına alınmadan önce test edilmesi gerekir.

5. Kayıtları @id ile Birbirine Bağlayın

Kuruluş, web sitesi, sayfa ve yazar birbirinden tamamen bağımsız kayıtlar olarak düşünülmemelidir.

Daha sağlıklı bir yapı, bu varlıkların birbirine referans verdiği bir veri grafiği oluşturmaktır.

Burada @graph ve @id kullanımı devreye girer.

Omurga Kurulumu: @graph ve @id

İyi yapılandırılmış bir sitede schema verisinin her sayfada birbirinden kopuk JSON blokları halinde tekrar edilmesi gerekmez.

Kuruluş, site ve sayfa gibi temel varlıkları aynı veri grafiği içerisinde tanımlamak daha düzenli bir model kurulmasını sağlar.

Örneğin:

<script type=”application/ld+json”>

{

  “@context”: “https://schema.org”,

  “@graph”: [

    {

      “@type”: “Organization”,

      “@id”: “https://www.orneksite.com/#kurulus”,

      “name”: “Örnek Marka”,

      “url”: “https://www.orneksite.com/”,

      “logo”: “https://www.orneksite.com/logo.png”,

      “sameAs”: [

        “https://www.linkedin.com/company/ornekmarka”

      ]

    },

    {

      “@type”: “WebSite”,

      “@id”: “https://www.orneksite.com/#site”,

      “url”: “https://www.orneksite.com/”,

      “name”: “Örnek Marka”,

      “publisher”: {

        “@id”: “https://www.orneksite.com/#kurulus”

      },

      “inLanguage”: “tr”

    },

    {

      “@type”: “WebPage”,

      “@id”: “https://www.orneksite.com/schema-markup-rehberi/#sayfa”,

      “url”: “https://www.orneksite.com/schema-markup-rehberi/”,

      “isPartOf”: {

        “@id”: “https://www.orneksite.com/#site”

      },

      “inLanguage”: “tr”

    }

  ]

}

</script>

Buradaki #kurulus, #site ve #sayfa değerlerinin ayrı ayrı ziyaret edilebilir gerçek sayfalar olması gerekmez. Bu değerler ilgili varlıklara kalıcı bir kimlik kazandırır.

Örneğin bir Article kaydı, publisher alanından #kurulus kimliğine bağlanabilir. WebPage kaydı ise #site kimliğini referans gösterebilir.

Bu yöntem, aynı kuruluş bilgisini her sayfada yeniden ve zaman zaman farklı değerlerle tanımlamaktan daha temiz bir yapı oluşturur.

SearchAction Artık Neden Kullanılmıyor?

WebSite schema örneklerinde uzun yıllar potentialAction ve SearchAction kullanımını görmek mümkündü.

Bu yapı, Google arama sonuçlarında kullanılan sitelinks search box özelliğiyle ilişkiliydi. Google bu özelliği Kasım 2024 itibarıyla kaldırdı.

Bu yüzden güncel schema kurulumlarında sadece eski örneklerde yer aldığı için SearchAction eklemenin artık anlamlı bir karşılığı yoktur.

Bu değişiklik, yapılandırılmış veri dokümantasyonunun belirli aralıklarla neden yeniden kontrol edilmesi gerektiğini de iyi gösteriyor.

En Çok Kullanılan Schema Türleri ve Örnekleri

Aşağıdaki örneklerde <script type=”application/ld+json”> etiketi her bölümde tekrar edilmemiştir. JSON örneklerinin bu etiket içerisine yerleştirilmesi gerekir.

1. Organization Schema: Kurumsal Kimlik

Organization schema, markanın veya kuruluşun temel kimlik bilgilerini tanımlamak için kullanılır.

{

  “@context”: “https://schema.org”,

  “@type”: “Organization”,

  “@id”: “https://www.orneksite.com/#kurulus”,

  “name”: “Örnek Marka”,

  “url”: “https://www.orneksite.com/”,

  “logo”: “https://www.orneksite.com/logo.png”,

  “sameAs”: [

    “https://www.instagram.com/ornekmarka”,

    “https://www.linkedin.com/company/ornekmarka”

  ],

  “contactPoint”: {

    “@type”: “ContactPoint”,

    “telephone”: “+90-212-000-00-00”,

    “contactType”: “customer service”,

    “availableLanguage”: “Turkish”

  }

}

sameAs alanı burada önemli bir işleve sahiptir. Markanın resmi sosyal medya profillerinin aynı varlığa ait olduğunu açık biçimde tanımlamaya yardımcı olur.

Organization schema’nın temel amacı arama sonucunda doğrudan yıldız göstermek değildir.

Kuruluşun kendi sitesinde topladığı değerlendirmeleri Organization veya LocalBusiness içerisinde aggregateRating olarak tanımlayıp yıldız sonucu beklemek de doğru bir uygulama değildir. Google, işletmenin kendisi hakkındaki ve kendi kontrolündeki değerlendirmeleri zengin sonuç amacıyla kullanmasını uzun süredir sınırlandırıyor.

Ürün değerlendirmeleri ise Product schema kapsamında ayrı bir şekilde ele alınır.

2. Person Schema: Yazar ve Uzman Kimliği

Yazar, danışman veya uzman profillerinde Person schema kullanılabilir.

{

  “@context”: “https://schema.org”,

  “@type”: “Person”,

  “@id”: “https://www.orneksite.com/yazarlar/elif-yildiz/#yazar”,

  “name”: “Elif Yıldız”,

  “jobTitle”: “SEO Uzmanı”,

  “url”: “https://www.orneksite.com/yazarlar/elif-yildiz/”,

  “knowsAbout”: [

    “Teknik SEO”,

    “İçerik Stratejisi”

  ],

  “sameAs”: [

    “https://www.linkedin.com/in/elifyildiz”

  ]

}

Person schema’nın doğrudan bir zengin sonuç görünümü bulunmaz. Buna rağmen yazar veya uzman kimliğinin makine tarafından okunabilir şekilde tanımlanmasını sağlar.

Asıl katkı, Article veya BlogPosting kayıtlarının author alanından aynı Person kimliğine bağlanmasıyla ortaya çıkar.

Böylece aynı yazarın bilgileri her içerikte baştan tanımlanmak yerine tek bir varlık üzerinden referanslanabilir.

3. Article ve BlogPosting Schema

Blog yazıları ve editöryel içeriklerde Article veya daha spesifik olarak BlogPosting kullanılabilir.

{

  “@context”: “https://schema.org”,

  “@type”: “BlogPosting”,

  “headline”: “Örneklerle Schema Markup Rehberi”,

  “image”: “https://www.orneksite.com/gorseller/schema-rehberi.jpg”,

  “datePublished”: “2026-08-12T09:00:00+03:00”,

  “dateModified”: “2026-08-12T09:00:00+03:00”,

  “author”: {

    “@id”: “https://www.orneksite.com/yazarlar/elif-yildiz/#yazar”

  },

  “publisher”: {

    “@id”: “https://www.orneksite.com/#kurulus”

  },

  “mainEntityOfPage”: {

    “@id”: “https://www.orneksite.com/schema-markup-rehberi/#sayfa”

  }

}

Tarih alanları ISO 8601 formatında verilmelidir.

Örneğin:

2026-08-12T09:00:00+03:00

dateModified değeri, içerikte gerçekten anlamlı bir güncelleme yapıldığında değiştirilmelidir.

Bazı altyapılar bu alanı her deploy işleminde veya küçük bir teknik güncellemede otomatik olarak güncel tarihe çekebilir. Böyle bir kullanım, içeriğin gerçek güncellenme tarihini yansıtmadığı için doğru değildir.

Görseller tarafında da mümkün olduğunca farklı en-boy oranlarına uygun ve yüksek kaliteli seçenekler kullanmak faydalıdır. Bu, Google’ın içeriği farklı arama ve keşif yüzeylerinde kullanabilmesi açısından daha sağlıklı bir yapı oluşturur.

4. Product Schema: E-Ticaret Sitelerinin En Kritik Markup’ı

E-ticaret projelerinde en önemli yapılandırılmış veri türlerinden biri Product schemadır.

{

  “@context”: “https://schema.org”,

  “@type”: “Product”,

  “name”: “Pamuklu Oversize Tişört – Beyaz”,

  “image”: “https://www.orneksite.com/urun/tisort-beyaz.jpg”,

  “description”: “Yüzde yüz pamuk, önden baskılı oversize kesim tişört.”,

  “sku”: “TSRT-001-BYZ”,

  “gtin13”: “8680000000000”,

  “brand”: {

    “@type”: “Brand”,

    “name”: “Örnek Marka”

  },

  “offers”: {

    “@type”: “Offer”,

    “url”: “https://www.orneksite.com/pamuklu-oversize-tisort-beyaz”,

    “price”: 449.90,

    “priceCurrency”: “TRY”,

    “availability”: “https://schema.org/InStock”,

    “itemCondition”: “https://schema.org/NewCondition”

  },

  “aggregateRating”: {

    “@type”: “AggregateRating”,

    “ratingValue”: 4.6,

    “reviewCount”: 128

  }

}

Buradaki bazı alanların doğru formatta kullanılması özellikle önemlidir.

price alanına “449,90 TL” gibi biçimlendirilmiş bir metin yazmak yerine sayısal değer girilmelidir.

availability alanında da serbest metin kullanılmaz. Schema.org tarafından tanımlanan değerlerden uygun olanı seçilir:

https://schema.org/InStock

https://schema.org/OutOfStock

https://schema.org/PreOrder

GTIN gibi küresel ürün tanımlayıcıları, aynı ürünün farklı satıcılardaki kayıtlarının eşleştirilmesine yardımcı olur.

E-ticaret sitelerinde yapılandırılmış veri ile Merchant Center feed’i arasındaki tutarlılık da ayrıca kontrol edilmelidir.

Örneğin ürün sayfasında fiyat 449,90 TL görünürken Product schema içerisinde 399,90 TL, Merchant Center feed’inde ise 429,90 TL bulunuyorsa Google aynı ürün için üç farklı kaynaktan üç farklı fiyat bilgisi alır.

Bu yüzden fiyat ve stok bilgilerinin mümkün olduğunca aynı ürün veri kaynağından dinamik şekilde üretilmesi daha sağlıklıdır.

Aynı yaklaşım yorum bilgileri için de geçerlidir.

Sayfada gerçekten kullanıcı değerlendirmesi yoksa sadece arama sonucunda yıldız gösterebilmek amacıyla aggregateRating eklenmemelidir.

Ürün Varyantlarında ProductGroup Kullanımı

Beden, renk veya benzeri seçeneklere sahip ürünlarda her varyantı tamamen bağımsız bir ürün olarak işaretlemek her zaman en doğru model değildir.

Google, ürün varyantlarının ProductGroup ve hasVariant kullanılarak birbiriyle ilişkilendirilmesini destekler.

Örneğin aynı tişörtün beyaz, siyah ve lacivert renkleri tek bir ürün grubu altında tanımlanabilir.

Bu yapı, özellikle geniş ürün kataloğuna sahip e-ticaret sitelerinde varyantlar arasındaki ilişkinin daha açık biçimde aktarılmasına yardımcı olur.

5. BreadcrumbList Schema

BreadcrumbList, bir sayfanın site hiyerarşisi içerisindeki konumunu tanımlar.

{

  “@context”: “https://schema.org”,

  “@type”: “BreadcrumbList”,

  “itemListElement”: [

    {

      “@type”: “ListItem”,

      “position”: 1,

      “name”: “Ana Sayfa”,

      “item”: “https://www.orneksite.com/”

    },

    {

      “@type”: “ListItem”,

      “position”: 2,

      “name”: “Giyim”,

      “item”: “https://www.orneksite.com/giyim”

    },

    {

      “@type”: “ListItem”,

      “position”: 3,

      “name”: “Tişört”

    }

  ]

}

position alanı breadcrumb sıralamasını belirtir.

Son öğede item alanının bulunması her durumda zorunlu değildir.

Breadcrumb markup, özellikle uzun, parametreli veya kullanıcı açısından okunması zor URL yapılarına sahip sitelerde arama sonucunda sayfa yolunun daha anlaşılır biçimde gösterilmesine yardımcı olabilir.

Aynı zamanda sayfanın site içerisindeki konumunu arama motoruna daha açık şekilde aktarır.

6. FAQPage Schema: Beklentiyi Güncel Tutun

FAQPage schema için kullanılan temel yapı şöyledir:

{

  “@context”: “https://schema.org”,

  “@type”: “FAQPage”,

  “mainEntity”: [

    {

      “@type”: “Question”,

      “name”: “Kargoya ne zaman verilir?”,

      “acceptedAnswer”: {

        “@type”: “Answer”,

        “text”: “Saat 15:00’e kadar verilen siparişler aynı gün kargoya teslim edilir.”

      }

    },

    {

      “@type”: “Question”,

      “name”: “İade süresi kaç gündür?”,

      “acceptedAnswer”: {

        “@type”: “Answer”,

        “text”: “Teslimattan itibaren 14 gün içinde iade talebi oluşturabilirsiniz.”

      }

    }

  ]

}

FAQ schema geçmişte çok daha geniş bir site grubunda arama sonuçlarında görünür soru-cevap alanları oluşturabiliyordu.

Google, Ağustos 2023’te bu görünürlüğü büyük ölçüde sınırlandırdı. Bugün standart bir blog veya e-ticaret sitesinin FAQ schema ekleyerek eskisi gibi düzenli biçimde açılır soru-cevap alanı elde etmesini beklemek doğru değil.

Benzer dönemde HowTo zengin sonuç görünümü de kaldırıldı.

Bu yüzden FAQPage kullanırken beklentiyi güncel şartlara göre belirlemek gerekiyor.

FAQ schema’nın arama sonucundaki görsel katkısı geçmişe göre oldukça sınırlı. Buna rağmen sayfada bulunan soru-cevap ilişkisini yapılandırılmış veri üzerinden tanımlamak için kullanılabilir.

Ancak yalnızca SERP’te birkaç ek satır kazanmak amacıyla sitenin büyük bölümünü FAQPage markup ile doldurmak artık anlamlı bir SEO yatırımı değildir.

7. LocalBusiness Schema

Fiziksel konuma sahip işletmeler için LocalBusiness veya işletmeye uygun daha spesifik alt türler kullanılabilir.

Örneğin bir çiçekçi için:

{

  “@context”: “https://schema.org”,

  “@type”: “FlowerShop”,

  “name”: “Örnek Çiçekçilik”,

  “image”: “https://www.ornekcicek.com/magaza.jpg”,

  “url”: “https://www.ornekcicek.com/”,

  “telephone”: “+90-216-000-00-00”,

  “address”: {

    “@type”: “PostalAddress”,

    “streetAddress”: “Örnek Cad. No: 12”,

    “addressLocality”: “Kadıköy”,

    “addressRegion”: “İstanbul”,

    “postalCode”: “34710”,

    “addressCountry”: “TR”

  },

  “geo”: {

    “@type”: “GeoCoordinates”,

    “latitude”: 40.9903,

    “longitude”: 29.0290

  },

  “openingHoursSpecification”: [

    {

      “@type”: “OpeningHoursSpecification”,

      “dayOfWeek”: [

        “Monday”,

        “Tuesday”,

        “Wednesday”,

        “Thursday”,

        “Friday”,

        “Saturday”

      ],

      “opens”: “09:00”,

      “closes”: “20:00”

    }

  ]

}

Mümkün olduğu durumlarda genel LocalBusiness yerine işletmenin faaliyet alanını daha doğru ifade eden alt tip tercih edilmelidir.

Örneğin:

• Çiçekçi için FlowerShop
• Restoran için Restaurant
• Diş hekimi için Dentist

İsim, adres, telefon ve çalışma saatleri gibi temel işletme bilgilerinin Google İşletme Profili ile web sitesinde gösterilen bilgilerle tutarlı olması da önemlidir.

Buradaki amaç, farklı kaynaklarda aynı işletmenin aynı temel bilgilerle tanımlanmasıdır.

8. Event Schema

Etkinlik sayfalarında Event schema kullanılabilir.

{

  “@context”: “https://schema.org”,

  “@type”: “Event”,

  “name”: “Uygulamalı SEO Atölyesi”,

  “startDate”: “2026-09-19T14:00:00+03:00”,

  “endDate”: “2026-09-19T17:00:00+03:00”,

  “eventAttendanceMode”: “https://schema.org/OfflineEventAttendanceMode”,

  “eventStatus”: “https://schema.org/EventScheduled”,

  “location”: {

    “@type”: “Place”,

    “name”: “Örnek Etkinlik Merkezi”,

    “address”: {

      “@type”: “PostalAddress”,

      “streetAddress”: “Merkez Mah. No: 5”,

      “addressLocality”: “İstanbul”,

      “addressCountry”: “TR”

    }

  },

  “offers”: {

    “@type”: “Offer”,

    “price”: 0,

    “priceCurrency”: “TRY”,

    “availability”: “https://schema.org/InStock”,

    “url”: “https://www.orneksite.com/seo-atolyesi-kayit”

  },

  “organizer”: {

    “@id”: “https://www.orneksite.com/#kurulus”

  }

}

Çevrim içi etkinliklerde OnlineEventAttendanceMode ve VirtualLocation kullanılabilir.

Bir etkinlik iptal edildiğinde sayfayı doğrudan kaldırmak yerine eventStatus değerini güncellemek çoğu durumda daha sağlıklı olur.

Örneğin:

https://schema.org/EventCancelled

Bu sayede hem kullanıcılar hem de arama motorları etkinliğin güncel durumunu görebilir.

9. VideoObject Schema

Video bulunan sayfalarda VideoObject schema kullanılabilir.

{

  “@context”: “https://schema.org”,

  “@type”: “VideoObject”,

  “name”: “5 Dakikada Teknik SEO Kontrolü”,

  “description”: “Bir sitede ilk beş dakikada bakılması gereken teknik SEO noktaları.”,

  “thumbnailUrl”: “https://www.orneksite.com/video/kapak.jpg”,

  “uploadDate”: “2026-08-01T10:00:00+03:00”,

  “duration”: “PT5M30S”,

  “contentUrl”: “https://www.orneksite.com/video/teknik-seo.mp4”

}

duration alanında ISO 8601 süre formatı kullanılır.

Örneğin:

PT5M30S

Bu değer 5 dakika 30 saniyelik bir videoyu ifade eder.

Uzun videolarda önemli bölümler Clip ve hasPart kullanılarak ayrıca tanımlanabilir.

Video schema kurulurken yalnızca sayfada gömülü bir videonun bulunmasına bakılmamalıdır. Google’ın video sayfaları için belirlediği görünürlük ve indekslenebilirlik şartları da kontrol edilmelidir.

Schema Markup Sayfaya Nasıl Eklenir?

Yapılandırılmış veriyi siteye eklemek için farklı yöntemler kullanılabilir.

1. Şablon veya Sunucu Tarafından Oluşturmak

En sağlam yöntemlerden biri, markup’ın sayfa verilerinden dinamik olarak üretilmesi ve ilk HTML içerisinde sunulmasıdır.

Özellikle e-ticaret sitelerinde fiyat, stok, SKU ve ürün adı gibi bilgilerin doğrudan ürün veri kaynağından alınması gerekir.

Böylece kullanıcıya gösterilen bilgiler ile schema içerisindeki verilerin birbirinden farklı hale gelme ihtimali azalır.

Türkiye’de kullanılan birçok hazır e-ticaret altyapısı Product ve Breadcrumb markup’ını otomatik olarak oluşturur.

Ancak “altyapı zaten schema basıyor” demek kontrol sürecinin tamamlandığı anlamına gelmez.

Denetim sırasında şu noktaların mutlaka incelenmesi gerekir:

• Aynı sayfada birden fazla Product kaydı var mı?
• Fiyat güncel mi?
• Stok durumu doğru mu?
• Varyantlar doğru modellenmiş mi?
• Breadcrumb sırası görünür yapıyla eşleşiyor mu?

2. CMS Eklentisi Kullanmak

WordPress tarafında Yoast SEO ve Rank Math gibi eklentiler, site genelindeki Organization, Person, Article ve Breadcrumb kayıtlarının önemli bir bölümünü otomatik olarak oluşturabilir.

Birçok içerik sitesi için bu yapı yeterli olabilir.

Buradaki temel risk, eklentinin oluşturduğu markup’ın tema veya özel kod aracılığıyla ikinci kez eklenmesidir.

Örneğin eklenti zaten bir BlogPosting oluşturuyorsa geliştiricinin aynı sayfaya ayrıca ikinci bir Article kaydı eklemesi gereksiz tekrar oluşturabilir.

Bu nedenle manuel schema eklemeden önce kullanılan eklentinin hangi schema türlerini otomatik oluşturduğu bilinmelidir.

3. HTML Blok Üzerinden Body Alanına Eklemek

CMS panelinde doğrudan schema eklemek için bir alan bulunmuyorsa ve tema dosyalarına erişim de mümkün değilse, JSON-LD kodu bir HTML blok üzerinden sayfanın <body> bölümüne eklenebilir.

Buradaki önemli nokta, schema kodunun mutlaka <head> içerisinde bulunmak zorunda olmamasıdır. JSON-LD, geçerli bir <script type=”application/ld+json”> bloğu halinde sayfanın <body> bölümünde de kullanılabilir.

Örneğin CMS içerisinde özel HTML, HTML içerik bloğu veya özel kod alanı bulunuyorsa şu yapı eklenebilir:

<script type=”application/ld+json”>

{

  “@context”: “https://schema.org”,

  “@type”: “WebPage”,

  “name”: “Örnek Sayfa”,

  “url”: “https://www.orneksite.com/ornek-sayfa/”

}

</script>

Bu yöntem, özel geliştirme imkanının sınırlı olduğu hazır CMS ve e-ticaret altyapılarında pratik bir çözüm olabilir. Sayfaya özgü Article, FAQPage, LocalBusiness veya benzeri schema kayıtları bu şekilde eklenebilir.

Ancak HTML blok kullanımında bazı teknik kontroller gerekir. Öncelikle blok, kodu metin olarak kullanıcıya göstermemeli ve <script> etiketini temizlememelidir. Bazı CMS editörleri güvenlik gerekçesiyle script etiketlerini kaldırabilir veya değiştirebilir. Yayından sonra hem sayfa kaynağının hem de render edilmiş HTML’in kontrol edilmesi bu nedenle önemlidir.

İkinci konu veri güncelliğidir. Statik HTML bloklar, fiyat, stok, yorum sayısı veya etkinlik tarihi gibi sık değişen alanlar için ideal değildir. Örneğin Product schema içerisindeki fiyat manuel olarak girilmişse ürün fiyatı değiştiğinde schema içerisindeki değerin de ayrıca güncellenmesi gerekir. Dinamik veriye bağlı schema türlerinde şablon veya veri kaynağından otomatik üretim, HTML blok kullanımına göre daha sağlıklı bir yöntemdir.

Sabit veya nadiren değişen sayfalarda ise HTML blok oldukça kullanışlı olabilir. Kurumsal sayfa, hizmet sayfası, belirli bir içerik veya lokasyon sayfasında CMS başka bir yöntem sunmuyorsa body içerisindeki JSON-LD bloğu, GTM üzerinden JavaScript ile sonradan ekleme yapmaktan daha sade bir çözüm sunar.

Öncelik sırası bu açıdan şablon veya sunucu tarafı üretim, ardından CMS’nin kendi schema alanı veya HTML blok, son seçenek olarak da GTM üzerinden enjeksiyon şeklinde düşünülebilir. Kullanılan yöntem ne olursa olsun, yayın sonrasında Google Rich Results Test ve sayfa kaynağı üzerinden kodun gerçekten çıktığı kontrol edilmelidir.

4. Google Tag Manager Üzerinden JSON-LD Eklemek

JSON-LD teknik olarak JavaScript aracılığıyla sonradan sayfaya eklenebilir ve Google bunu render aşamasında görebilir.

Bu nedenle Google Tag Manager üzerinden schema oluşturmak mümkündür.

Ancak alternatif yöntemler kullanılabiliyorsa ilk tercih olarak GTM’ye yönelmek doğru değildir.

GTM kullanıldığında yapılandırılmış veri:

• tetikleyici kurallarına,
• container sürümüne,
• JavaScript çalışmasına,
• yayınlama sürecine

bağımlı hale gelir.

Bir trigger değiştirildiğinde veya etiket yanlışlıkla durdurulduğunda markup kaynak kodda görünmediği için problem uzun süre fark edilmeyebilir.

Sunucu veya şablon seviyesinde çözüm üretilemiyorsa GTM kullanılabilir. Ancak Product, Event gibi kritik veya dinamik schema türlerinde doğrudan veri kaynağıyla çalışan bir entegrasyon daha güvenilir olur.

Schema Markup Nasıl Test Edilir?

Schema kurulumu kodun sayfaya eklenmesiyle tamamlanmış sayılmaz.

Üç farklı kontrol katmanının birlikte kullanılması gerekir.

Google Rich Results Test

Google’ın Zengin Sonuç Testi, sayfanın Google tarafından desteklenen zengin sonuç türleri açısından uygunluğunu kontrol eder.

Bu araç üzerinden şu soruların yanıtı alınabilir:

• Google hangi yapılandırılmış veri türlerini tespit ediyor?
• Zorunlu alan hatası var mı?
• Önerilen alanlar eksik mi?
• Render sonrasında JSON-LD DOM’a geliyor mu?

URL üzerinden test yapıldığında JavaScript aracılığıyla sonradan oluşturulan markup da görülebilir.

Özellikle GTM kullanılan projelerde render edilmiş HTML açılarak JSON-LD bloğunun gerçekten sayfaya geldiği ayrıca kontrol edilmelidir.

Schema Markup Validator

Schema Markup Validator, yapılandırılmış verinin Schema.org sözlüğüne uygun olup olmadığını kontrol etmek için kullanılır.

Google’ın doğrudan bir zengin sonuç desteği sunmadığı Person veya bazı WebSite tanımları gibi kayıtların doğrulanmasında özellikle faydalıdır.

Schema Markup Validator ile Google Rich Results Test aynı kontrolü yapmaz.

Biri Schema.org sözlüğündeki yapısal doğruluğa, diğeri Google’ın desteklediği arama özelliklerine odaklanır.

Google Search Console

Yapılandırılmış veri yayına alındıktan sonraki temel takip alanı Google Search Console’dur.

Google yeterli sayıda ilgili markup tespit ettiğinde ürünler, breadcrumb veya video gibi türler için geliştirme raporları gösterebilir.

Ayrıştırılamayan yapılandırılmış veri raporu da ayrıca takip edilmelidir.

Bu rapor, JSON sözdizimi hatası nedeniyle Google’ın schema türünü dahi belirleyemediği blokların bulunmasına yardımcı olur.

Kurulum sonrasında yalnızca “testten geçti” sonucuna bakmak yeterli değildir. Geçerli ve hatalı öğelerin sayısı zaman içerisinde takip edilmelidir.

Schema Doğru Ama Zengin Sonuç Neden Görünmüyor?

Yapılandırılmış veri tarafında en sık karşılaşılan yanlış beklentilerden biri budur.

Test aracı markup’ın doğru olduğunu gösterebilir ancak Google arama sonucunda beklenen yıldız, fiyat veya başka bir zengin sonuç görünmeyebilir.

Böyle bir durumda üç aşamalı kontrol yapılabilir.

1. Sayfa Yeniden Tarandı mı?

Schema üzerinde yapılan değişikliğin arama sonucuna yansıyabilmesi için Google’ın sayfayı yeniden taraması ve işlemesi gerekir.

Yeni eklenen markup’ın ertesi gün mutlaka SERP’e yansımasını beklemek doğru değildir.

Özellikle büyük sitelerde veya düşük tarama sıklığına sahip sayfalarda bu süreç daha uzun sürebilir.

2. Google’ın Zengin Sonuç Şartları Karşılanıyor mu?

Validator’ın “geçerli” sonucu vermesi ile Google’ın ilgili zengin sonuç türü için belirlediği şartları karşılamak aynı şey değildir.

Örneğin Schema.org sözlüğü açısından geçerli bir Product nesnesinde, Merchant Listing için gerekli olan bazı alanlar eksik olabilir.

Bu yüzden Google Rich Results Test ile ilgili Google dokümantasyonu birlikte kontrol edilmelidir.

3. Google Sonucu Göstermeyi Tercih Ediyor mu?

Teknik açıdan doğru bir markup, zengin sonucun mutlaka gösterileceği anlamına gelmez.

Google sorguya, kullanıcı bağlamına, siteye ve arama sonuçlarının tasarımına göre ilgili görünümü göstermemeyi tercih edebilir.

Teknik kontroller tamamlandıktan sonra bu nokta artık yalnızca schema üzerinde değişiklik yapılarak çözülebilecek bir konu değildir.

Schema Markup İçin Sağlam Bir Başlangıç Planı

Schema markup’ın temel mantığı oldukça açıktır: sayfanın kullanıcıya anlattığı bilgileri arama motoruna da standart ve makine tarafından okunabilir bir formatta iletmek.

Yeni bir kurulum yapılırken şu sıra izlenebilir:

1. Mevcut schema kayıtlarını tespit edin.
2. Çift veya çelişkili kayıtları temizleyin.
3. JSON-LD formatını temel alın.
4. Organization, WebSite ve gerekli sayfalarda Person gibi merkezî varlıkları tanımlayın.
5. Varlıkları @id üzerinden birbirine bağlayın.
6. Sayfa tipine göre Product, Article, BreadcrumbList, Event veya diğer gerekli schema türlerini ekleyin.
7. Görünür içerikle markup arasındaki veri tutarlılığını kontrol edin.
8. Google Rich Results Test ve Schema Markup Validator ile doğrulayın.
9. Yayın sonrasında Google Search Console üzerinden hataları takip edin.

Başlangıç için yapılabilecek en kolay kontrollerden biri ise sadece birkaç dakika sürer.

Sitenizde önemli gördüğünüz herhangi bir sayfayı açın ve kaynak kod içerisinde şu ifadeyi arayın:

application/ld+json

Ardından karşınıza çıkan blokları tek tek kontrol edin.

Hiçbir sonuç bulamıyorsanız hangi schema türleriyle başlamanız gerektiğini belirleyebilirsiniz. Çok sayıda kayıt görüyorsanız bu kez asıl soru değişir: Bu kayıtlar doğru mu, güncel mi ve birbirleriyle tutarlı mı?

Çoğu sitede ilk schema çalışması yeni kod eklemekten önce mevcut yapının bu sorular üzerinden kontrol edilmesiyle başlamalıdır.

SIKÇA SORULAN SORULAR

Schema Markup sıralamayı doğrudan yükseltir mi?

Hayır. Schema markup doğrudan sıralama artışı sağlayan bir SEO faktörü değildir. Yapılandırılmış veri, sayfanın içeriğinin ve sayfadaki varlıkların arama motorları tarafından daha açık biçimde anlaşılmasını sağlar. Uygun durumlarda zengin sonuç görünümüne de katkıda bulunabilir. Bu durum aynı sıralama pozisyonundaki sonucun daha fazla bilgi içermesine ve tıklama oranının desteklenmesine yardımcı olabilir. Schema’nın değerini yalnızca “sıralama arttı mı?” sorusuyla ölçmek bu yüzden doğru bir yaklaşım değildir.

Her sayfaya schema eklemek gerekir mi?

Her sayfaya mümkün olan bütün schema türlerini eklemek gerekmez. Öncelikler sayfanın türüne ve içeriğine göre belirlenmelidir.

E-ticaret sitelerinde genellikle:

• Product
• BreadcrumbList
• Organization
• WebSite

önceliklidir.

İçerik sitelerinde:

• Article veya BlogPosting
• Person
• Organization
• BreadcrumbList

daha kritik hale gelir.

Yerel işletmelerde ise işletmeyi doğru tanımlayan LocalBusiness alt tipi önemlidir.

Schema seçiminde kayıt sayısından çok doğruluk ve sayfanın içeriğiyle uyum önem taşır.

Çalışan Microdata kurulumunu JSON-LD'ye taşımak gerekir mi?

Çalışan ve hatasız bir Microdata kurulumu sadece eski bir format olduğu için acil şekilde kaldırılmak zorunda değildir. Ancak şablon yenilemesi veya teknik yeniden yapılandırma sırasında JSON-LD’ye geçiş planlanabilir. Geçiş sürecinde eski ve yeni yapıların aynı bilgiyi farklı veya çelişkili değerlerle üretmemesine dikkat edilmelidir. Yeni JSON-LD yapısı doğrulandıktan sonra eski Microdata alanları temizlenebilir.

Yapay zekâ aramaları için schema önemli mi?

Yapay zeka destekli arama ve cevap sistemlerinde içeriklerin varlıklar, ilişkiler ve açık veri noktaları üzerinden anlaşılması giderek daha fazla önem kazanıyor.

Schema markup bir sitenin:

• hangi kuruluşa ait olduğunu,
• içeriği kimin yazdığını,
• hangi ürünü sattığını,
• hangi sosyal profillerin aynı markaya ait olduğunu

makine tarafından okunabilir biçimde tanımlamasına yardımcı olur.

 

Refik Aslandoğdu

SEO alanında 3 yıllık deneyimiyle çalışmalar yürütmektedir. Teknik analizler ve içerik optimizasyonu ile markalarına destek olmaktadır. Yenilikçi ve stratejik bir bakış açısıyla sürdürülebilir bir başarıya odaklanmaktadır.