Diller

JSON-LD: Yapılandırılmış Veri Biçimi

Google’ın önerdiği, script tabanlı yapılandırılmış veri biçimi JSON-LD — uygulanması en kolay seçenektir, görünür HTML’ye dokunmaz ve SEO için genellikle schema.org ile eşleştirilir.

İlk yayın tarihi: 26 Haz 2026 · Son güncelleme: 8 Ağu 2026 · Advanced
Diller
AIYazanAI v2
Bu sayfada 1 kanıt sinyali

JSON-LD, sayfa içeriğini açıklamak için <script type="application/ld+json"> etiketi içinde yaşayan bir yapılandırılmış veri biçimidir; SEO tarafında genellikle schema.org sözlüğüyle eşleştirilir ancak JSON-LD başka sözlükleri de taşıyabilir. 2014 tarihli bir W3C standardıdır ve Google, Microdata ve RDFa yerine tek bir nedenle bunu önerir: kendi bloğunda durduğu ve görünür HTML’ye hiç dokunmadığı için geniş ölçekte uygulanması ve bakımı en kolay biçimdir. Doğru uygulandığında üç biçimin tümü eşit derecede çalışır. Söz diziminin omurgası @context (çoğu SEO işaretlemesi için sözlük — schema.org, ancak tek geçerli değer değil), @type (varlık) ve @id’dir (varlıkları bağlamak için kullanışlı ama isteğe bağlı kararlı URI — @graph kalıbının temeli; kendisi de zorunlu olmayan geçerli bir düzenleme yoludur). Googlebot JavaScript’i oluşturduğu için dinamik eklenen JSON-LD Google’da çalışır; ancak test edildiği üzere GPTBot ve ClaudeBot dahil bazı AI tarayıcıları JavaScript çalıştırmaz. Bu sağlayıcıya ve tarihe özgüdür, evrensel kural değildir; belirli bir tarayıcı önemliyse doğrudan doğrulayın ve doğrulayamadığınız işaretlemeyi sunucu tarafında oluşturun. Yapılandırılmış veri sıralama sinyali değildir; zengin sonuç uygunluğunu ve varlık anlaşılmasını yönetir ve sayfada gerçekten görünür olan içeriği açıklamalıdır.

TL;DR — JSON-LD (JavaScript Object Notation for Linked Data), 2014 tarihli bir W3C Önerisidir — JSON üzerine kuruludur ancak onu yalnızca JSON değil bağlantılı veri yapan @context’tir. Google, geniş ölçekte uygulanması ve bakımı en kolay olduğu için bunu önerir ve görünür HTML’ye hiç dokunmaz; doğru kullanıldığında Microdata ve RDFa da eşit derecede geçerlidir. Söz diziminin omurgası @context (çoğu SEO işaretlemesi için sözlük — schema.org, ancak spesifikasyon başka bağlamlara da izin verir), @type (varlık) ve @id’dir (varlıkları birbirine referanslamak için kullanışlı ama isteğe bağlı kararlı URI — @graph’ın temeli; kendisi de tek geçerli kalıp değildir). <head> veya <body> içine yerleştirebilirsiniz — Google ikisini de kabul eder. Googlebot JS’yi oluşturduğu için dinamik eklenmiş JSON-LD Google’da çalışır; test edildiği üzere GPTBot ve ClaudeBot dahil bazı AI tarayıcıları JS çalıştırmaz, ancak bu sağlayıcıya ve tarihe özgüdür — her AI tarayıcısı için varsaymak yerine doğrudan doğrulayın ve doğrulayamadığınızı sunucu tarafında oluşturun. Yapılandırılmış veri sıralama sinyali değildir — zengin sonuç uygunluğunu ve varlık anlaşılmasını sağlar ve sayfada görünür içeriği açıklamalıdır.

JSON-LD bir sözlük değil, biçimdir

Önce karışıklığın çoğunu gideren bir ayrım: JSON-LD biçimdir; schema.org ise sözlüktür. JSON-LD, işaretlemeyi nasıl yazdığınızdır; schema.org’un Article, Product ve Organization türleri ise ne söylediğinizdir. Zengin sonuçlar her ikisinin üzerine kurulan özellik katmanıdır. Bu sayfa biçim hakkındadır. (Yapay zekâ için sözlük konusu AI için Schema Markup sayfasındadır.)

JSON-LD bir W3C Önerisidir; ilk kez 2014’te yayımlanmıştır — SEO tarafından benimsenmesinden önce gelir ve özellikle arama için değil, web genelinde bağlantılı veri birlikte çalışabilirliği için tasarlanmıştır. @id gibi bir özelliğin var olmasının nedeni budur ve çoğu SEO rehberinin atladığı spesifikasyon düzeyi nokta şudur: JSON-LD yalnızca JSON değildir. JSON söz dizimi üzerine kuruludur ancak veriyi bağlantılı — web genelinde tanımlanabilir ve bağlanabilir — yapan @context bildirimidir. @context’i çıkarırsanız ayrıştırıcının yorumlayamayacağı veriye sahip olursunuz.

JSON-LD’nin schema.org’a bağlı olması da gerekmez. Spesifikasyon, @context’in yayımlanmış herhangi bir sözlüğe referans vermesine izin verir — kendi örnekleri schema.org dışı bağlamlara bağlanır. Bu nedenle JSON-LD “hangi biçim” sorusunun doğru yanıtıdır; schema.org ise “hangi sözlük” sorusunun, arama ve AI arama işaretlemesi için yaygın olan, yanıtlarından biridir. Bir sayfa JSON-LD’yi başka bir sözlükle geçerli biçimde kullanabilir; yalnızca artık schema.org işaretlemesi olmaz.

JSON-LD ve Microdata ve RDFa

Yapılandırılmış veriyi ifade etmenin üç yolu vardır ve Google üçünü de destekler:

JSON-LDMicrodataRDFa
Nerede durur?Ayrı bir <script> bloğundaHTML’nizde satır içi itemprop özellikleriHTML’nizde satır içi property özellikleri
Görünür HTML’ye dokunur mu?HayırEvetEvet
JS / etiket yöneticisiyle enjekte edilebilir mi?Evet (temiz biçimde)ZahmetliZahmetli
Google’ın yaklaşımıÖnerilenDesteklenirDesteklenir
Hataya açıklıkEn düşükDaha yüksek (işaretlemeyle iç içe)Daha yüksek (işaretlemeyle iç içe)

Google’ın önerisi açıktır ancak kapsamı dardır: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).”

Rakiplerin genellikle atladığı ve saklamaya değer nüans aynı Google sayfasından gelir: “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” Yani öneri uygulama kolaylığı ve hata oranı hakkındadır; ayrıştırma hızı veya sıralama avantajı hakkında değil. Microdata kullanmak ceza değildir. JSON-LD pratikte yalnızca kazanır, çünkü yapılandırılmış veriyi tasarımcının yarın düzenleyebileceği işaretlemeyle iç içe sokmaz.

Söz dizimi: @context, @type, @id, özellikler, iç içelik

Açıklamalı bir Article bloğu:

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>
  • @context — anlamsal çerçeveyi (sözlüğü) kurar. schema.org SEO işaretlemesi için genellikle "https://schema.org" kullanılır; ancak bu bir kural değil, uzlaşıdır: @context terimleri tanımlayıcılara eşler ve spesifikasyon başka sözlüklere işaret etmesine izin verir. Ardından gelen her özellik adının nasıl yorumlanacağını ayrıştırıcıya söyler. Veriyi bağlantılı yapan parça budur.
  • @type — varlığı bildirir: Article, Product, Organization, BreadcrumbList vb. Bir schema.org türüne eşlenir. Uygulanabilir en spesifik türü kullanın — uyuyorsa NewsArticle yerine Article.
  • @id — kaynağı tanımlayan benzersiz URI’dir. Bir varlığa diğerinden referans vermenizi sağlayan mekanizmadır (aşağıdaki @graph’a bakın) ve çapraz referans vereceğiniz her şeye eklemeye değerdir; ancak her yerde zorunlu değildir. JSON-LD spesifikasyonu tanımlanmamış boş düğümlere izin verir; bu nedenle başka yerde referans vermeniz gerekmeyen varlıklarda @id bulunmayan geçerli JSON-LD olabilir.
  • Özellikler — @context’teki sözlük terimlerini kullanan sıradan JSON anahtar/değer çiftleri.
  • İç içelik — alt varlıklar, iç içe JSON nesneleri (yukarıdaki author nesnesi) veya nesne dizileri olarak ifade edilir.

@graph kalıbı (ölçeklenebilir yaklaşım)

Çoğu sayfanın birden fazla varlığa ihtiyacı vardır: bir Organization, bir WebSite, bir BreadcrumbList ve makalenin ya da WebPage’in kendisi. Saf yaklaşım, verileri tekrarlayan dört ayrı <script> bloğudur. Ölçeklenebilir alternatif, @id ile birbirine referans veren varlıklar dizisi olan @graph içeren tek bir bloktur. Ne JSON-LD spesifikasyonu ne de Google @graph’ı tek kalıp olarak zorunlu kılar — grafik ifade etmenin söz dizimidir ve başka geçerli düzenler de vardır (ayrı tür blokları, üst düzey @graph olmayan iç içe nesneler, hiç @id içermeyen boş düğümler) — ancak birden çok çapraz referanslı varlığın bulunduğu sitede her sayfada aynı Organization veya WebSite verisini tekrarlamaktan kaçınan kalıptır:

Declare each entity once and connect the graph with stable `@id` references instead of repeating full objects. Kaynak: Nested Schema

One Organization is referenced as publisher by the WebSite and Article. The WebPage belongs to the WebSite and is connected to the Article. Each entity is declared once, and the same stable ID string is reused for every reference.

© Patrick Stox LLC · CC BY 4.0 · 

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Organization’ı bir kez tanımlayın; adı, logosu ve URL’sini tekrarlamak yerine başka her yerde { "@id": "...#org" } ile ona işaret edin. Büyük CMS şema eklentileri çıktılarını böyle oluşturur ve @id’nin var olmasının nedeni budur. Bing de JSON-LD’nin iç içeliği için aynı noktayı belirtir: “makes defining links and relationships between data and entities… easy because it supports nested data.”

Nereye yerleştirilir: <head> veya <body>

Google ikisinin de çalıştığını doğrular — “You can put the JSON-LD data in the <head> or the <body> of the page.” <head> gelenekseldir ancak birçok CMS eklentisi onu <body>’nin sonuna enjekte eder ve bu da uygundur. Bing de sayfanın “header, body or foot” bölümünde durabileceğini kabul eder. Geçerli bir bloğu body’den head’e taşımakla zaman harcamayın; hiçbir şeyi değiştirmez. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: Google: Structured data introduction

JSON-LD’yi dinamik oluşturmak — ve AI tarayıcısı açığı

JSON-LD’yi JavaScript ile anında oluşturabilirsiniz; Google bunu yapmanın iki yolunu belgeliyor:

Evidence for this claim Dynamically generated structured data is acceptable to Google when it is rendered and complies with content and quality guidelines. Scope: Google Search JavaScript and structured-data guidance; crawlability and rendering remain prerequisites. Confidence: high · Verified: Google: Generate structured data with JavaScript
  1. Google Tag Manager — JSON-LD içeren ve değerleri GTM değişkenlerinden alan Özel HTML etiketi. (Sayfa ile etiket arasındaki veriyi iki kez üretmekten kaçının.)
  2. Özel JavaScript — script öğesini programlı olarak oluşturun:

Bu, Googlebot için çalışır, çünkü Google sayfayı oluşturur: “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” Şimdiye kadar her şey yolunda.

Çoğu rehberin dikkatinden kaçan noktayı dikkatli biçimde ifade edelim. GPTBot ve ClaudeBot dahil, yaygın olarak test edildiği üzere, bazı AI tarayıcıları JavaScript çalıştırmamıştır. JSON-LD’niz yalnızca istemci tarafı script çalıştıktan sonra varsa JS atlamalı bir tarayıcı onu göremez — Googlebot işaretlemeyi düzgün okusa bile o bot için görünmez; çünkü Google yapılandırılmış veriyi aramadan önce DOM’u oluşturduğunu belgeliyor.

Bu AI tarayıcısı davranışı hakkında iki dürüst uyarı var: Googlebot tarafını Google’ın kendi belgeleri kurar; AI tarayıcısı tarafı, herhangi birinin yayımladığı bir spesifikasyondan değil, tek tek sağlayıcılar hakkındaki test ve raporlardan gelir. Bu nedenle sağlayıcıya ve tarihe özgüdür — tarayıcının JavaScript desteği değişebilir ve ben her sağlayıcıyı doğrudan doğrulamadım. “AI tarayıcıları JS’yi atlar” ifadesini üzerine inşa edilecek evrensel bir kural olarak ele almayın; önem verdiğiniz tarayıcıyı kontrol etmek (veya kontrol edemiyorsanız varsayılan olarak sunucu tarafı oluşturma kullanmak) için bir neden olarak ele alın. Sunucu tarafından oluşturulmuş HTML’de yoksa ve tarayıcının JS çalıştırdığını doğrulamadıysanız göremediğini varsayın. AI arama görünürlüğü için, aksi doğrulanmadıkça JSON-LD’yi statik HTML’ye sunucu tarafında oluşturun. (Bu, yapılandırılmış veri açısından JavaScript oluşturma sorunudur — JavaScript SEO sayfasına bakın.)

E-ticaret için ikinci bir uyarı var: Google, dinamik oluşturulan Product işaretlemesinin “can make Shopping crawls less frequent and less reliable,” olabileceği konusunda uyarır; hızla değişen fiyat ve bulunabilirlik için bu gerçek bir sorundur. Ürünlerde, AI ne olursa olsun sunucu tarafı oluşturmayı tercih edin.

Politikalar (artık bunların yaptırımı var)

Google’ın yapılandırılmış veri yönergeleri kısa ve kritik öneme sahiptir:

  • “Don’t mark up content that is not visible to readers of the page.”
  • “Don’t mark up irrelevant or misleading content, such as fake reviews.”
  • “Put the structured data on the page that it describes.”
  • “Use the most specific applicable type and property names defined by schema.org.”
  • Yapılandırılmış veri sayfalarınızı robots.txt veya noindex ile Googlebot’a engellemeyin.

Görünür içerik kuralı içselleştirmeniz gereken kuraldır. Sayfada gösterilmeyen içeriği açıklayan şema her zaman ihlaldi; “görünmez” şemaya yönelik uygulama sıkılaştı. Bing uyarıyı açıkça ifade eder: “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.”

Yaygın JSON-LD hataları

  • Görünür sayfayla eşleşmeyen işaretleme — politika açısından 1 numaralı sorun (ziyaretçinin görmediği bir puanın JSON-LD’de bulunması).
  • Bozuk JSON — sondaki virgül, kaçışlanmamış tırnak veya tüm bloğu sessizce bozan Word akıllı tırnakları (" yerine "). JSON-LD katıdır.
  • Yanlış özellik adları — schema.org’da bulunmayan özellikler uydurmak veya gerçek olanları yanlış yazmak; ayrıştırıcı bunları yok sayar.
  • Spesifik tür varken genel tür kullanmak — Thing veya Article gerektiğinde Recipe ya da NewsArticle kullanmak.
  • Çelişen ad/logo içeren sayfalar arasında yinelenen ve tutarsız Organization blokları.
  • Hedeflediğiniz zengin sonuç için zorunlu özelliklerin eksik olması (her özellik kendi zorunlu alanlarını listeler).
  • Her tarayıcının gördüğünü varsayarak JS-enjekte işaretleme — Google bunu oluşturur ama bazı AI tarayıcıları oluşturmamıştır; yukarıdaki açığı tarayıcı başına doğrulamak gerekir.

JSON-LD’yi doğrulamak

“JSON-LD’m geçerli mi?” başlığı altında dört farklı soru sorulur ve bunlar aynı şey değildir — birini geçmek diğerlerini geçirmez:

TestKanıtladığı şeyKanıtlamadığı şey
JSON ayrıştırılır (herhangi bir JSON lint aracı veya Rich Results Test’in ayrıştırma adımı)Söz dizimi yasal JSON’dır — sondaki virgül, kaçışlanmamış tırnak veya akıllı tırnak bozulması yokturHer özellik adının gerçek schema.org sözlüğü olduğunu veya Google’ın bir şey göstereceğini
Schema.org ValidatorÖzellikler ve türler schema.org sözlüğünde vardırGoogle’ın bu türü zengin sonuç olarak desteklediğini veya belirli bir özellik için zorunlu alanların bulunduğunu
Rich Results Testİşaretleme, test ettiğiniz oluşturulmuş sayfada belirli bir desteklenen zengin sonuç türünün Google gereksinimlerini karşılarGoogle’ın zengin sonucu gerçekten göstereceğini — uygunluk garanti değildir — veya diğer arama/AI sistemlerinin bunu aynı şekilde ayrıştırdığını
Google Search Console — Enhancements / zengin sonuç raporlarıGoogle’ın canlı, taranmış sayfalarda gerçek hatalarla gerçekte ayrıştırdığı şeyGerçek zamanlı durumu — raporlar yeniden taramanın gerisinden gelir
  • JavaScript ile oluşturulan sayfalarda yapıştırılmış kod yerine URL ile test edin. Rich Results Test’in kod girişi modu script’lerinizi çalıştırmaz veya canlı URL testinin yaptığı gibi göreli referansları çözmez — istemci tarafında enjekte edilen bir bloğun oluşturma sonrasında nasıl göründüğünü söyleyemez.
  • Bing Webmaster Tools — Markup Validator — Bing, Ağustos 2018’den beri JSON-LD’yi doğrular.
  • Bu testlerin hiçbiri JavaScript oluşturmayan tarayıcılar adına konuşmaz (yukarıdaki AI tarayıcısı uyarısı) — oluşturulmuş URL’yi test etmek Google’ın gördüğünü doğrular, JS atlamalı bir botun aldığını değil.

JSON-LD SEO’ya yardım eder mi?

Beklentileri dürüstçe belirleyin:

  • Sıralama sinyali değildir. John Mueller yapılandırılmış verinin bir sitenin daha iyi sıralanmasını sağlamayacağını söyledi. Nokta.
  • Zengin sonuç uygunluğu. Geliştirilmiş SERP özellikleri (yıldızlar, fiyatlar, SSS, ekmek kırıntıları) için sizi uygun kılan şeydir — uygunluktur, garanti değil.
  • Dolaylı olarak CTR. Daha zengin görünen sonuçlar daha fazla tıklama kazanabilir; çoğu site için gerçek getiri budur.
  • Varlık anlaşılması. Motorların sayfanızı bilinen varlıklara ve Bilgi Grafiği’ne bağlamasına yardım eder.
  • AI araması. Fabrice Canel (Bing), 2025’te şema işaretlemesinin Microsoft’un LLM’lerinin içeriği anlamasına yardım ettiğini doğruladı — ancak AI için Schema Markup sayfasındaki kontrollü çalışma uyarısını unutmayın: bu, doğrudan alıntı kaldıracı değil, anlam ayrımı için altyapıdır.

Yani JSON-LD’yi zengin sonuç uygunluğu, varlık netliği ve AI/LLM anlayışı için uygulayın — sıralama hilesi olarak değil.

Bu makale structured data merkezinin parçasıdır. schema.org sözlüğünün yapay zekâya özgü yorumu için Schema Markup for AI sayfasına; dinamik enjeksiyonun arkasındaki oluşturma mekanikleri için JavaScript SEO sayfasına bakın.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.