Schema Markup Nedir? Yapılandırılmış Veri ve Zengin Sonuç Rehberi

Schema markup, bir sayfadaki içeriğin ne anlama geldiğini arama motorlarına ve dil modellerine makine diliyle söyleyen etiket setidir. HTML bir tarayıcıya "bu bir başlık, bu bir paragraf" der; schema ise "bu bir ürün adı, bu onun fiyatı, bu para birimi, bu satıcı" der. Etiketlerin sözlüğü schema.org üzerinde tanımlıdır ve Google, Bing ile büyük dil modelleri aynı sözlüğü okur.

Neden önemli olduğunu iki cümleyle söyleyelim ve abartmayalım. Birincisi, schema bazı zengin sonuç biçimlerine uygunluk kazandırır: kırıntı yolu, tarih, fiyat, stok durumu ya da genişletilebilir soru-cevap alanı ancak işaretleme varsa gösterilebilir. İkincisi ve daha kalıcı olanı, schema markanızı bir varlık(entity) olarak çözümlenebilir hale getirir — "Obelisx" kelimesinin bir ajansa mı yoksa başka bir şeye mi karşılık geldiği, sayfadaki metinden tahmin edilmek yerine veriden okunur.

Buna karşılık dürüst olalım: schema doğrudan bir sıralama sinyali değildir. İşaretleme eklemek bir sayfayı yukarı taşımaz. Etkisi dolaylıdır ve iki kanaldan gelir — sonuç sayfasındaki görünümün zenginleşmesi (dolayısıyla tıklanma davranışı) ve içeriğin makine tarafından doğru anlaşılması. Sıralama garantisi vaat eden hiçbir işaretleme yoktur; bunu SEO ve teknik optimizasyon hizmetimizde de aynı şekilde söylüyoruz.

Üç format da geçerlidir, ancak JSON-LD tercih edilen formattırve Google da bunu önerir. Sebebi teknik bir zarafet meselesi değil, bakım maliyetidir: JSON-LD işaretlemeyi HTML'den tamamen ayırır. Tek bir <script type="application/ld+json"> bloğu sayfanın içine konur ve görünür işaretlemeye hiç dokunulmaz.

Mikrodata ve RDFa ise etiketleri doğrudan HTML özniteliklerine gömer. Bu, iki pratik sorun üretir. Birincisi, tasarımı değiştiren her düzenleme işaretlemeyi de bozma riski taşır — bir div taşındığında ürün fiyatı ürün nesnesinin dışında kalabilir. İkincisi, veri sayfaya dağıldığı için tek bir yerden üretilemez; her şablonda ayrı ayrı bakım gerektirir.

JSON-LD'nin asıl avantajı budur: işaretleme tek bir modülden üretilebilir. Bu sitede tüm düğümler src/lib/schema.ts içindeki fonksiyonlardan çıkar; adres, telefon ya da kuruluş adı değiştiğinde tek bir dosya güncellenir ve site genelindeki her sayfa otomatik olarak doğru veriyi yayınlar. Aynı bilgiyi otuz şablona kopyalayan bir kurulumda bu değişiklik günler sürer ve mutlaka bir yerde eski kalır.

Tek uyarı şudur: JSON-LD'yi tarayıcıda JavaScript ile sonradan enjekte etmeyin. Sunucu tarafında render edilmeyen işaretleme, JavaScript çalıştırmayan tarayıcılar için hiç var olmamış demektir — bu özellikle AI tarayıcıları için belirleyicidir.

Schema.org sözlüğü yüzlerce tip içerir; gerçekte işe yarayanlar bir avuçtur. Aşağıdaki tablo, kurumsal bir sitede yatırımın karşılığını veren tipleri ve her birinin ne açtığını gösterir. "Uygunluk" kelimesi bilinçli seçilmiştir: işaretleme gösterimi hak eder, garanti etmez — hangi zengin sonucun hangi sorguda çıkacağına arama motoru karar verir.

Bir e-ticaret sitesinde ağırlık Product + Offer tarafındadır ve doğru kurulumu doğrudan gelire dokunur; kurulum kapsamını e-ticaret sitesi kurulumu sayfasında görebilirsiniz. Hizmet veren bir kurumsal sitede ise sıralama şudur: Organization, WebSite ve BreadcrumbList her sayfada; FAQPage ve Service ticari sayfalarda; Article yalnızca blog altında.

@id, bir düğüme verilen kalıcı kimliktir; bir düğümü tekrar tanımlamak yerine ona referans vermenizi sağlar. Çoğu rehberin atladığı nokta tam burasıdır. Yaygın kurulumda her sayfa kendi başına bir Organization bloğu yayınlar, kendi başına bir WebSite bloğu yayınlar ve bunların hiçbiri birbirine bağlı değildir. Sonuç, aynı markayı anlatan ama birbirinden habersiz onlarca adacıktır; her biri ayrı bir varlıkmış gibi okunabilir ve hiçbiri diğerinin otoritesini biriktirmez.

Doğru yaklaşım, site genelinde tek bir kuruluş düğümü ve tek bir site düğümü tanımlamak, geri kalan her düğümü bunlara {"@id": "..."} referansıyla bağlamaktır. Bu sitenin yaptığı da budur: kuruluş her zaman https://www.obelisx.com/#organization, site her zaman https://www.obelisx.com/#website kimliğini taşır. Sayfa düğümleri url#webpage, kırıntı yolu url#breadcrumb, makale url#article, hizmet url#service, S/C bloğu url#faq kimliğini alır ve hepsi aynı iki çapaya işaret eder.

İkinci kural: tüm bu düğümler tek bir @graph dizisinin içinde, tek bir script etiketiyle yayınlanır. Sayfaya beş ayrı JSON-LD bloğu koymak teknik olarak geçersiz değildir, ama düğümler arası ilişkiyi kurmayı zorlaştırır ve aynı verinin birden çok kez tekrarlanmasına yol açar. Aşağıda bu sitenin bir blog yazısı için ürettiği grafiğin sadeleştirilmiş hali var:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": ["Organization", "ProfessionalService"],
      "@id": "https://www.obelisx.com/#organization",
      "name": "Obelisx",
      "url": "https://www.obelisx.com",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://www.obelisx.com/#logo",
        "url": "https://www.obelisx.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://www.obelisx.com/#website",
      "url": "https://www.obelisx.com",
      "name": "Obelisx",
      "publisher": { "@id": "https://www.obelisx.com/#organization" },
      "inLanguage": "tr-TR"
    },
    {
      "@type": "WebPage",
      "@id": "https://www.obelisx.com/blog/schema-markup-nedir#webpage",
      "url": "https://www.obelisx.com/blog/schema-markup-nedir",
      "name": "Schema Markup Nedir?",
      "isPartOf": { "@id": "https://www.obelisx.com/#website" },
      "about": { "@id": "https://www.obelisx.com/#organization" },
      "breadcrumb": {
        "@id": "https://www.obelisx.com/blog/schema-markup-nedir#breadcrumb"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://www.obelisx.com/blog/schema-markup-nedir#article",
      "headline": "Schema Markup Nedir?",
      "mainEntityOfPage": {
        "@id": "https://www.obelisx.com/blog/schema-markup-nedir#webpage"
      },
      "author": { "@id": "https://www.obelisx.com/#organization" },
      "publisher": { "@id": "https://www.obelisx.com/#organization" },
      "datePublished": "2026-08-14",
      "dateModified": "2026-08-14"
    }
  ]
}
</script>

Dikkat edin: kuruluşun adı, adresi ve logosu grafikte bir kez geçiyor. Makale düğümü yazarını ve yayıncısını tekrar tarif etmiyor, kimliğe işaret ediyor. Sayfa düğümü sitenin parçası olduğunu bir referansla söylüyor. Aynı yapı hizmet sayfalarında #service, S/C bloklarında #faq düğümüyle genişliyor — ama çapa hep aynı iki kimlik.

Pratik sonuç şudur: markanız site genelinde tek bir varlık olarak okunur. Alan adı, logo, adres ve iletişim bilgileri her sayfada birbirini doğrular. Bu, bir marka adının arama motorunda ve dil modelinde tutarlı biçimde çözümlenmesi için elinizdeki en güçlü teknik sinyaldir.

Schema markup, dil modelleri için "çıkarım yemi" işlevi görür: modelin metne bakarak tahmin etmek zorunda kalacağı ilişkileri hazır veri olarak önüne koyar. Dil modelleri sayfayı okuduğunda ilişkileri metinden çıkarmak zorundadır: bu fiyat hangi ürüne ait, bu telefon numarası kimin, bu tarih yayın tarihi mi güncelleme tarihi mi. Schema markup bu çıkarım işini ortadan kaldırır — ilişkiyi tahmin edilecek bir şey olmaktan çıkarıp okunacak bir veri haline getirir. Model, kendi başına belirsizlikle üreteceği bilgiyi hazır ve tartışmasız biçimde almış olur.

Bunun cevap motorlarındaki karşılığı doğrudandır. Bir sayfayı alıntılamaya karar veren sistem, alıntıladığı bilgiyi bir kaynağa ve bir varlığa bağlamak zorundadır. Kuruluş düğümü tanımlı, tarih düğümü gerçek ve S/C bloğu sayfada görünür olan bir içerik, bu bağı kurmayı kolaylaştırır. Tersi de doğrudur: hiçbir işaretlemesi olmayan, yazarı belirsiz, güncelleme tarihi olmayan bir sayfa için model çok daha fazla varsayımda bulunmak zorundadır.

Yine de abartmayalım: hiçbir cevap motoru "schema varsa alıntılarım" demez. İşaretleme alıntılanma garantisi değildir; belirsizliği azaltan bir yardımcıdır. Asıl belirleyici olan içeriğin kendisi ve sunucu tarafında render edilmiş olmasıdır — AI tarayıcıları JavaScript çalıştırmaz. Bu konunun tamamını AI aramalarında görünürlük (GEO) rehberinde ele aldık.

İki farklı araç, iki farklı soruyu cevaplar ve ikisi de gereklidir. Yalnızca birine bakmak, en sık yapılan doğrulama hatasıdır.

• Rich Results Test (Google).Sorduğu soru: "Google bu işaretlemeyle hangi zengin sonuca uygunluk görüyor?" Yalnızca Google'ın desteklediği tipleri bilir; desteklenmeyen ama tamamen geçerli bir tipi görmezden gelir. Canlı URL ile çalıştırın — kodu yapıştırarak test etmek, işaretlemenin gerçekte sayfaya inip inmediğini göstermez.
• Schema Markup Validator (validator.schema.org).Sorduğu soru: "Bu işaretleme schema.org sözlüğüne göre geçerli mi?" Söz dizimi hatalarını, tanımsız özellikleri ve yanlış tipleri yakalar; zengin sonuç uygunluğu hakkında bir şey söylemez. Google'ın desteklemediği tipleri de doğrular.
• Search Console — gelişmiş sonuç raporları.Tek bir URL'i değil, gerçekten taranmış tüm sayfaları gösterir. Bir şablon hatasının kaç sayfayı etkilediği ancak burada görünür. İlk iki araç temiz olduğu halde burada hata çıkıyorsa, sorun çoğunlukla belirli bir sayfa tipindedir.
• Sayfa kaynağını gözle kontrol edin.Tarayıcıda "kaynağı görüntüle" dediğinizde JSON-LD bloğu görünüyorsa sunucudan geliyordur. Yalnızca geliştirici araçlarının inceleme sekmesinde görünüyorsa JavaScript ile enjekte ediliyordur — ve bu, işaretlemenin bir bölümünün hiç okunmaması demektir.
• @id referanslarının çözümlendiğini doğrulayın. Bir düğüm #organization kimliğine referans veriyorsa, o kimliğin aynı grafikte gerçekten tanımlı olduğundan emin olun. Boşa düşen bir referans hata vermez, sessizce işe yaramaz — bu yüzden en zor fark edilen hata sınıfıdır.

İki hata diğerlerinden ayrılır, çünkü bunlar "eksik uygulama" değil, politika ihlalidir ve manuel işlem riski taşır. Kaybettiğiniz şey bir zengin sonuç değil, arama görünürlüğünüzün tamamı olabilir.

• Sayfada görünmeyen içeriği işaretlemek. Ziyaretçinin ekranında olmayan bir soru-cevabı FAQPage olarak işaretlemek, olmayan bir fiyatı Offer olarak yazmak ya da sayfada bulunmayan bir hizmeti Service olarak eklemek doğrudan yapılandırılmış veri politikası ihlalidir. Kural basittir: işaretlediğiniz her şey, işaretlenen sayfada kullanıcı tarafından görülebilir olmalıdır.
• Kendi topladığınız yorumlarla AggregateRating işaretlemek.Kendi kuruluşunuz hakkında kendi sitenizde topladığınız puanları yıldız olarak işaretlemek "kendi kendini yücelten inceleme işaretlemesi" sayılır ve politikaya aykırıdır. Bu site bu yüzden AggregateRating hiç yayınlamaz: müşteri yorumlarımız referanslar sayfasında görünür metin olarak durur, işaretleme olarak değil. Görünür kalır, doğrulanabilir kalır, riskli olmaz.
• Her sayfada bağımsız Organization adacıkları. Yukarıda anlattığımız hata. Kuruluş bilgisi sayfadan sayfaya farklılaştığında (bir yerde eski telefon, bir yerde yeni adres) işaretleme markayı netleştirmek yerine bulanıklaştırır.
• Gerçek olmayan tarihler. Sayfaya dokunulmadığı halde her gün güncellenen bir dateModified, tazeliği sinyal etmez; işaretlemenin güvenilirliğini düşürür. Tarih alanı gerçek bir düzenlemeyi göstermelidir.
• Şablondan kopyalanmış, düzeltilmemiş işaretleme. Başka bir siteden alınmış JSON-LD içinde kalan yabancı alan adları, örnek telefon numaraları ve yanlış görsel adresleri şaşırtıcı derecede yaygındır. Google, erişilemeyen bir görsele işaret eden makale işaretlemesinde zengin sonucu tamamen düşürür.
• Doğrulanmış ama uygulanmamış işaretleme. Aracın yeşil vermesi, o sayfanın taranıp indekslendiği anlamına gelmez. İşaretlemenin karşılığını görmek için sayfanın erişilebilir, indekslenebilir ve makul hızda olması gerekir; teknik altyapı tarafını Core Web Vitals rehberinde ele aldık.

Kurulumu sıfırdan yapıyorsanız sıra şudur: önce Organization ve WebSite düğümlerini tek bir modülde tanımlayın, sonra her sayfa tipine WebPage ve BreadcrumbList ekleyin, en son sayfaya özel tipleri (Article, Service, Product, FAQPage) bağlayın. Bu sırayı bozup ürün işaretlemesiyle başlamak, bağlanacak bir çapa olmadığı için işin yarısını sonradan yeniden yaptırır. Mevcut bir sitede işaretlemenin durumunu görmek isterseniz iletişim sayfasından adresi iletmeniz yeterli.

• Schema markup, sayfa içeriğinin ne anlama geldiğini makine diliyle söyleyen etiket setidir. Doğrudan sıralama sinyali değildir; zengin sonuç uygunluğu ve varlık çözümlemesi üzerinden dolaylı etki eder.
• JSON-LD tercih edilen formattır: işaretlemeyi HTML'den ayırır, tek bir modülden üretilebilir ve tasarım değişiklikleri onu bozmaz. Ancak sunucu tarafında render edilmelidir.
• En çok işe yarayan tipler: Organization ve WebSite (varlık çapası), BreadcrumbList (kırıntı yolu), FAQPage (S/C alanı), Article (tarih ve yazar), Service, Product + Offer (fiyat ve stok), LocalBusiness (yerel sinyal).
• @id, düğümlere kalıcı kimlik verir. Site genelinde tek bir #organization ve tek bir #website düğümü tanımlayıp diğer her şeyi bunlara referansla bağlamak, her sayfada bağımsız adacıklar yayınlamaktan çok daha güçlüdür.
• Tüm düğümler tek bir @graph içinde, tek bir script etiketiyle yayınlanmalıdır — birden çok kopuk blok yerine.
• Doğrulama iki araç ister: Rich Results Test zengin sonuç uygunluğunu, Schema Markup Validator sözlük geçerliliğini kontrol eder. Search Console ise şablon düzeyindeki hataları gösterir.
• İki hata politika ihlalidir: sayfada görünmeyen içeriği işaretlemek ve kendi kuruluşunuz için kendi topladığınız yorumlarla AggregateRating yayınlamak. İkisi de manuel işlem riski taşır.

Tüm yazılar blog dizininde. Hizmet karşılıkları için hizmetler, paket bedelleri için fiyatlandırma sayfalarına bakabilirsiniz.