Schema.org JSON-LD Oluşturucu
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article"
}
</script>Yapılandırılmış veri (structured data), düz mavi bir bağlantı ile yıldız puanı, fiyat, FAQ akordiyonu, yemek tarifi süresi veya site içi arama kutusu çeken zengin bir arama sonucu arasındaki farktır. Google, Bing, Yandex ve modern arama motorlarının çoğu, bir sayfanın üzerindeki kelimelerin ötesinde sayfanın ne hakkında olduğunu anlamak için Schema.org sözlüğüne dayanır; ve önerilen kodlama, zengin sonuç programı 2010'ların ortalarında gerçek bir sıralama ve TO sinyali haline geldiğinden beri JSON-LD olarak kalmıştır. Bu sinyalin önemine rağmen, gerçek yazma deneyimi hâlâ şaşırtıcı derecede sancılıdır: dokümantasyon schema.org ile Google search central arasında bölünmüştür, JSON-LD spesifikasyonunun daha önce yazmadıysanız öğrenme eğrisi diktir ve en yaygın yazım hataları — eski dateModified, mutlak olmayan görsel URL'leri, offers'sız Product — sürekli olarak sessizce doğrulamayı geçer ama CI'da yakalayabileceğiniz net bir hata üretmez.
Bu oluşturucu, 2026'da gerçekten zengin sonuçlar kazanan tipler için sürtünmeyi kaldırmak üzere tasarlandı: Article (ve onun NewsArticle / BlogPosting alt tipleri), Product, FAQPage, LocalBusiness ve BreadcrumbList. Bu beş tip, tipik bir içerik sitesinde, e-ticaret mağazasında veya yerel hizmet işletmesinde sayfaların büyük çoğunluğunu kapsar. Form size tam olarak Google'ın zengin sonuç dokümantasyonunda zorunlu veya güçlü tavsiye edilen olarak işaretlediği alanları sunar; en sık doğrulamayı bozan tuzaklar için satır içi ipuçları içerir. Yazdıkça, sağda canlı bir JSON-LD önizlemesi @context ve @type otomatik atanmış şekilde, doğru girintilenmiş olarak güncellenir. Memnun kaldığınızda Kopyala düğmesi ilgili sayfanın <head> bölümüne doğrudan yapıştırabileceğiniz <script type="application/ld+json"> etiketiyle sarılı temiz bir parçacık verir.
JSON-LD'nin neden kazandığını anlamak faydalıdır. Schema.org üç serileştirme tanımlar — Microdata, RDFa ve JSON-LD — ve projenin ilk birkaç yılında öneri Microdata idi; o yapı içinde yapılandırılmış veriyi doğrudan HTML işaretlemesinin içine gömer. Avantajı, yapılandırılmış verinin onu üreten içeriğin yanında yaşamasıydı; dezavantajı, şablonların itemprop, itemscope ve itemtype niteliklerle dolup geliştiriciler için okunamaz hale gelmesi ve istemci tarafında yeniden render eden dinamik sayfaların işaretlemeyi senkronize tutmak için ek özen göstermek zorunda olmasıydı. JSON-LD, yapılandırılmış veriyi render edilen HTML'den tamamen ayrılmış ayrı bir JSON bloğu olarak gönderir. Bu, sunucu katmanında veya statik bir varlık olarak üretmeyi son derece kolaylaştırır ve tek bir şablon değişikliği olmadan istemci tarafında yeniden render etmeyi atlatır. Google 2015'te birinci sınıf JSON-LD desteğini açıkladı ve 2018'de bu, çoğu zengin sonuç tipinde önerilen serileştirme oldu. Bugün hemen hemen her modern CMS ve SEO aracı varsayılan olarak JSON-LD üretir.
Article içerik sitelerinin ekmek-suyudur. Google headline (temiz SERP renderı için pratikte ≤110 karakter), image (bir veya daha fazla mutlak URL, ideal olarak büyük görsel kartlar için 1200px genişlikte yüksek çözünürlüklü), ISO 8601 formatında datePublished ve bir author ister. dateModified isteğe bağlıdır ama güçlü tavsiye edilir — Google önbelleğe alınmış parçacığı yenileyip yenilemeyeceğine karar vermek için bunu kullanır ve eksik veya eski dateModified, makalelerin Top Stories'te görünememesinin yaygın nedenidir. publisher alanı AMP için zorunludur ve diğer durumlarda önerilir; publisher logosu en az 60×600 piksel olmalı, hem image hem logo'da mutlak URL'ler kullanılmalıdır. Oluşturucu, datetime-local input aracılığıyla ISO tarih formatını dayatır; author ve publisher'ı düz bir nesne yerine doğru şekilde @type Person ve @type Organization altında iç içe sağlamanıza izin verir — yazarların Stack Overflow'dan düz bir nesne örneği kopyaladıkları en yaygın hata bu.
Product, e-ticaret için en yüksek kaldıraçlı tiptir ve ayrıca en zorudur, çünkü Google'ın politikaları 2022 ve 2023'te önemli ölçüde sıkılaştırıldı. Zorunlu alanlar name, image (mutlak URL) ve offers'tır — offers olmadan ürün, ürün zengin sonuçlarında hiç görünmez. price alanı offers.price içinde bir string olmalıdır (JSON sayıya izin vermesine rağmen sayı değil) ve currency, priceCurrency içinde üç harfli ISO 4217 kodu olmalıdır. availability alanı https://schema.org/InStock gibi Schema.org URL değerlerini kullanır — oluşturucu bunları doğru yazar, böylece ezberlemenize gerek kalmaz. AggregateRating eskiden yıldız puanlarını ortaya çıkarmanın yoluydu, ama Google artık puanların aynı ürün üzerindeki gerçek, doğrulanabilir kullanıcı incelemelerinden gelmesini istiyor; kendi atadığınız puanlar manuel işleme yol açabilir. Oluşturucu aggregateRating alanlarını içerir ama bunları yalnızca destekleyebildiğiniz durumda doldurun.
FAQPage ilginç bir yörünge izledi: 2019'dan 2023'e kadar zengin sonuç sevgilisiydi ve Google sonra Ağustos 2023'te FAQ zengin sonuçlarının devlet ve tanınmış otoritatif sağlık siteleriyle sınırlı olacağını duyurdu. Yapılandırılmış veri hâlâ değer taşır — bazı Google dışı yüzeylerde görünür, AI Overview alıntılarını tetikleyebilir ve Google hâlâ varlık çıkarımı için ayrıştırır — ama beklentilerinizi gerçekçi tutmalısınız. Oluşturucu her Q&A'nın hem soru hem yanıt içerdiğini doğrular (Google'ın ayrıştırıcısı eksik olanları düşürür) ve doğru Question / Answer iç içe geçirmesi olan bir mainEntity dizisi üretir. Yaygın bir hata, Q&A'ların tıklamaların arkasına gizlendiği bir sayfada FAQPage bulundurmaktır; Google'ın politikası tüm yanıt metninin kullanıcı etkileşimi olmadan görünür olmasını ister, dolayısıyla tıklama sırasında JavaScript'ten içerik yükleyen bir akordiyon cloaking olarak işaretlenebilir.
LocalBusiness, doğru çalışma saatleri, fotoğraflar ve yol tarifi kartı ile Google'ın yerel paketinde görünmek isteyen herhangi bir adres tabanlı işletme için işçi attır. Oluşturucu en kullanışlı alt tipleri (Restaurant, Store, MedicalClinic, vb.) sunar çünkü Google uyumlu en spesifik tipi güçlü şekilde tercih eder — LocalBusiness olarak tiplendirilmiş bir restoran çalışacaktır ama Restaurant olarak tiplendirilmiş bir restorandan daha az zengin özellik ortaya çıkaracaktır. address alanı standart alanları olan iç içe bir PostalAddress'tir; addressCountry alanı çevrimiçi birçok örnekte tam ülke adı kullanılsa bile iki harfli ISO 3166-1 kodu olmalıdır (US, GB, TR), tam adı değil. openingHours en çok yazarı şaşırtan alandır — Mo-Fr 09:00-18:00 veya Sa 10:00-16:00 gibi gün kodları ve 24 saat formatında zaman aralıkları olan yoğun bir format kullanır ve birden fazla aralık için birden fazla satır verebilirsiniz. Oluşturucu satır başına bir aralık kabul eder ve bunları Schema.org'un beklediği diziye birleştirir.
BreadcrumbList, içerik sitelerinde en ucuz zengin sonuç kazançıdır. Sitenin bilgi mimarisinde mevcut sayfanın hiyerarşisini Google'a sinyaller ve Google bunu mobil SERP'lerinde sayfa başlığının altında görünen breadcrumb izini oluşturmak için kullanır. Format, her biri position (1-tabanlı), name ve item (mutlak URL) olan ListItem girdilerinin bir itemListElement dizisidir. İki hata neredeyse tüm BreadcrumbList renderlama hatalarını oluşturur: item alanındaki göreli URL'ler ve dizi dinamik oluşturulduğunda position numaralandırmasında bir-değişimi. Oluşturucu 1-tabanlı pozisyonları dayatır ve mutlak URL'leri varsayar; bir girdi göreli yol gibi göründüğünde satır içi ipucu verir. BreadcrumbList'i aynı sayfada Article veya Product ile eşleştirmek en iyi uygulamadır — birbirlerini güçlendirirler ve Google'a sayfanın ne olduğuna dair daha tam bir resim verirler.
Doğrulama, herkesin atladığı ve sonra pişman olduğu adımdır. Google'ın Rich Results Test'i (search.google.com/test/rich-results) kanonik araçtır: URL'yi getirir veya yapıştırılan kodu kabul eder, Google'ın gerçek ayrıştırıcısı üzerinden geçirir ve hem doğrulama hatalarını hem de sayfanın hangi zengin sonuç kategorileri için uygun olduğunu raporlar. Schema.org doğrulayıcısı (validator.schema.org) daha hoşgörülüdür ve genel yapılandırılmış veri çalışmaları için kullanışlıdır ama Google'a özgü gereksinimleri kontrol etmez. Schema.org'un dokümantasyonu zaman zaman Google'ın gerçek render kurallarının gerisinde kalır, dolayısıyla iki kaynak çeliştiğinde SEO amaçları için Rich Results Test'e güvenin. Oluşturucu, mutlu yolda her iki doğrulayıcıyı geçen çıktı üretir; bir alan boşsa, ilgili anahtar boş bir string olarak verilmek yerine çıktıdan atlanır çünkü boş değerler genellikle doğrulama uyarılarını tetikler.
Uygulamada, önerilen yerleştirme sayfanın <head> bölümünün içidir, ama Google JSON-LD'yi <body> içinde de kabul eder — CMS'iniz size head düzeyinde kontrol vermediğinde kullanışlıdır. Birden fazla ayrı <script type="application/ld+json"> bloğu gönderebilir veya bunları tek bir @graph dizisi altında birleştirebilirsiniz, ki bu hem BreadcrumbList hem Article (veya Product, vb.) gerektiren sayfalar için daha temiz bir kalıptır. Oluşturucu, doğrudan kaynağı basit tutabilmeniz için tek seferde bir blok üretir; gönderdiğinizde manuel olarak @graph kalıbını kullanabilir veya kendiniz birleştirebilirsiniz. İkisi de Google için çalışır. Bir hatadan kaçının: tırnakları kaçıran bir Mustache veya Handlebars bloğu içine JSON-LD gömmeyin — kaçırılmış JSON ayrıştırıcıyı bozar. Her zaman ham olarak render edin.
Gizlilik ve güvenlik burada basittir çünkü her şey tarayıcınızda gerçekleşir. Form durumu React state'inde yaşar; JSON serileştirmesi bu state üzerinde saf bir fonksiyondur; hiçbir sunucuya hiçbir şey yüklenmez, hiçbir telemetri formunuzun içeriğini izlemez ve hiçbir şey sızdırmadan duyurulmamış ürünler veya yayımlanmamış blog yazıları için yapılandırılmış veri yazabilirsiniz. Sıkı dışa içerik politikaları olan kurumsal bir ortamda çalışıyorsanız bu önemlidir: tipik bir çevrimiçi şema oluşturucu, herhangi bir alanı her değiştirdiğinizde taslak alanlarınızı sunucusuna yükler ki bu her zaman izinli değildir. Bu oluşturucu yapmaz ve doğrulamak için tarayıcı ağ sekmesini açıp izleyebilirsiniz: düzenleme sırasında istek yoktur.
Vurgulanmaya değer birkaç pratik kalıp. İlk olarak, şemanızı bir kez yazın ve sayfa şablonunuzun bir parçası olarak ele alın — tek seferlik bir yapıştırma olarak değil. Article'lar başlık, görsel, tarihler ve yazar alarak JSON-LD üreten bir partial'dan yararlanır; Product, ürün detay sayfanızın render ettiği aynı veriyi alan bir partial'dan yararlanır. Bu şekilde yapılandırılmış veri ve görünür içerik senkronize kalır. İkinci olarak, dateModified'i dürüstçe kullanın — Google, makaleyi değiştirmeden günlük olarak dateModified'i artıran siteleri izler ve bu kalıp Top Stories'te öncelik kaybına yol açabilir. Üçüncü olarak, aynı sayfada breadcrumb, article ve product şemalarında yalnızca tek bir kanonik URL kullanın; kanonik host'ları (www ile apex, http ile https) karıştırmak indeksleyiciyi şaşırtır.
Bu araç, Omnvert'in geri kalan geliştirici yardımcı programlarıyla doğal olarak eşleşir. JSON-LD'yi ürettikten sonra çıktıyı ağaç yapısını görsel olarak doğrulamak için JSON Viewer'a yapıştırabilir veya büyük bir şemada bir token'ı toplu olarak değiştirmeniz gerekiyorsa Regex Tester'dan geçirebilirsiniz. Open Graph & Twitter Card Preview aracı, sosyal önizlemelerinizin doğru olduğundan emin olmanın ilgili ama farklı sorununu kapsar — JSON-LD arama motorlarını hedefler, OG ve twitter:card sosyal platformları hedefler. Çoğu üretim sayfası ikisine de ihtiyaç duyar. Hash Generator, doğal bir URL'si olmayan kaynaklar için sabit bir @id URI'sine ihtiyacınız olduğunda kullanışlıdır. Bunların hepsi tarayıcıda aynı gizlilik modeli ile çalışır, böylece bütün bir SEO yazma akışı tek bir sekmede üçüncü taraf bir hizmete tek bir istek olmadan gerçekleşebilir.
- Bir blog yazısına yazar, yayıncı, tarihler ve hero görsel ile Article yapılandırılmış verisi ekleyin.
- Fiyat, para birimi, stok durumu ve marka ile bir e-ticaret sayfası için Product şeması üretin.
- Bir Q&A listesinden FAQPage bloğu oluşturun ve CMS'inize yapıştırın.
- Adres, telefon, çalışma saatleri ve coğrafi koordinatlarla yerel bir işletmeyi işaretleyin.
- SERP breadcrumb izini kazanmak için kategori veya detay sayfasına BreadcrumbList ekleyin.
- Rich Results Test ile doğrulamadan önce taslak bir sayfa için yapılandırılmış veriyi hızlıca taslaklayın.
- Junior geliştiricilere şablonlar arasında geçiş yaparak tam bir şemanın nasıl göründüğünü öğretin.
- Tersine mühendislik alan değerlerini forma yapıştırarak mevcut sayfaları denetleyin.
- 1Bir şablon seçin: Article, Product, FAQ, LocalBusiness veya BreadcrumbList.
- 2Form alanlarını doldurun — yalnızca uygulanan alanları; boş alanlar çıktıdan çıkarılır.
- 3JSON-LD önizlemesinin yazdıkça canlı oluşturulmasını izleyin.
- 4HTML'e doğrudan yapıştırmak istiyorsanız <script> sarmalayıcısını açın veya ham JSON kopyalayın.
- 5Yeni sekmede Google'ın Rich Results Test'ini açmak için Doğrula'ya tıklayın.
- 6Parçacığı kopyalayın veya indirin ve sayfanızın <head> bölümüne yapıştırın.