Yapılandırılmış Veriler için Schema.org ve JSON-LD Kılavuzu

Sayfada gerçekten açıklanan nesneyi seçin, özelliklerini doldurun ve HTML'ye eklemek için JSON-LD kodunu alın. Oluşturucu, sözdizimini oluşturmaya yardımcı olur, ancak yayınlamadan önce görünür içerikle uyumluluğu, seçilen veri tüketicisinin gereksinimlerini ve değerlerin güncelliğini kontrol etmek gerekir.

Schema.org, JSON-LD ve zengin sonuç farklı şeylerdir

Schema.org

Bu, ortak bir tür ve özellik sözlüğüdür: Article, Product, Organization, Event, name, image, offers ve diğerleri. Hangi varlıkların ve ilişkilerin yapılandırılmış biçimde temsil edilebileceğini açıklar.

JSON-LD

Bu, yapılandırılmış verileri yazmak için kullanılan biçimlerden biridir. Kod şunun içine yerleştirilir:

Google, uygulama için uygun olduğunda JSON-LD'yi önerir, ancak Schema.org ayrıca Microdata veya RDFa ile de yazılabilir.

Google zengin sonucu

Bu, arama sonuçlarında yalnızca sınırlı bir tür kümesini destekleyen ve Google'ın belirli kurallarına uyulmasını gerektiren özel bir gösterimdir. Geçerli bir Schema.org işaretlemesi, zengin bir sonucu, yüksek sıralamayı veya hatta gönderilen tüm özelliklerin kullanımını garanti etmez. Bu nedenle, işaretleme yalnızca "güzel bir snippet gösterir mi?" sorusuyla değerlendirilmemelidir. Öncelikle sayfanın gerçek varlığını doğru bir şekilde tanımlamalıdır.

İşaretleme türü nasıl seçilir

Türü, sayfanın ana nesnesine göre seçin, aramada istenen görünüme göre değil.

Bir sayfada birden fazla ilgili nesneye izin verilir. Örneğin, bir makalenin bir yazarı Person, bir yayıncısı Organization, ekmek kırıntıları BreadcrumbList ve gömülü bir videosu VideoObject olabilir. Bunları @id aracılığıyla bağlamak, birbiriyle çelişen kopyalar oluşturmaktan daha iyidir.

Google'ın önemli güncel kısıtlamaları

FAQPage

Google, SSS zengin sonuçlarının görüntülenmesini önemli ölçüde sınırladı: bunlar genellikle yalnızca bilinen yetkili devlet ve sağlık siteleri için kullanılabilir. Sıradan bir ticari veya bilgi sitesi için doğru bir FAQ işaretlemesi, arama sonuçlarında gözle görülür bir genişleme sağlamayabilir. Bu, FAQPage türünü Schema.org'da geçersiz kılmaz, ancak kullanıcıya "sorular Google'da görünecek" vaadi verilemez.

HowTo

Google, HowTo zengin sonuçlarını göstermeyi durdurdu. HowTo türü Schema.org sözlüğünde kalır ve diğer tüketiciler tarafından kullanılabilir, ancak yalnızca eski Google zengin sonucu için eklemenin artık bir anlamı yoktur.

Diğer türler

Organization, Person ve WebSite varlıkları tanımlamaya yardımcı olur, ancak her biri ayrı bir görsel zengin sonuç oluşturmaz. Arama özelliklerinin desteği ve görünümü değişir, bu nedenle uygulamadan önce mevcut Google Search Central galerisini kontrol edin.

Ana kural: işaretleme görünür içerikle eşleşmelidir

JSON-LD'ye sayfada bulunmayan veya onunla çelişen bilgiler eklemeyin. Bu özellikle şunlar için geçerlidir:

• ürün fiyatı ve stok durumu;
• puan ve yorum sayısı;
• sorular ve yanıtlar;
• etkinliğin tarihi ve yeri;
• materyalin yazarı;
• şirket adresi ve çalışma saatleri;
• iş ilanı koşulları;
• tarifin malzemeleri ve adımları.

İşaretleme, gizli reklam metni veya ek anahtar kelimeler için bir yer değildir. Kullanıcı ve arama motoru tutarlı bilgi almalıdır.

Zorunlu alanlar, işaretlemeyi kimin okuduğuna bağlıdır

Schema.org bir sözlük tanımlar, ancak tüm sistemler için evrensel bir "zorunlu alan" listesi değildir. Belirli bir tüketici, örneğin Google Search, belirli bir arama işlevi için kendi zorunlu ve önerilen özelliklerini belirler. Bu nedenle, üç farklı doğrulama sonucu mümkündür:

1. JSON sözdizimsel olarak doğrudur.
2. Türler ve özellikler Schema.org'da mevcuttur.
3. İşaretleme, belirli Google zengin sonucunun gereksinimlerini karşılar.

Birinci veya ikinci aşamayı geçmek üçüncüyü garanti etmez.

URL'ler, tarihler ve tanımlayıcılar nasıl doldurulur

Mutlak URL'ler kullanın

Tercihen:

Yerine:

Bağlantılar arama robotu tarafından erişilebilir olmalı, kimlik doğrulama gerektirmemeli ve sabit bir kaynağa yönlendirmelidir.

Tarihleri ISO 8601'de belirtin

Tarih:

Saat dilimli tarih ve saat:

Etkinlikler için saat dilimini kaybetmemek özellikle önemlidir. Aksi takdirde saat yanlış yorumlanabilir.

Sabit bir @id oluşturun

@id, varlığın tanımlayıcısıdır, genellikle parçalı URL biçiminde:

Farklı sayfalardaki aynı kuruluş, sabit bir tanımlayıcıya başvurmalı, birbirinden bağımsız birden fazla şirket gibi görünmemelidir.

Birden çok varlık @graph ile nasıl tanımlanır

İlgili nesneler için tek bir blok kullanmak uygundur:

Böylece nesneler açıkça bağlanır ve her makale içinde kuruluşla ilgili tüm bilgileri tekrarlamak gerekmez.

JSON-LD nereye eklenir

<script type="application/ld+json"> bloğu, HTML sayfasının <head> veya <body> bölümüne yerleştirilebilir. Şunlar daha önemlidir:

• kod, nihai HTML'de bulunmalı veya doğru işleme sonrasında erişilebilir olmalıdır;
• özellikle mevcut sayfayla ilgili olmalıdır;
• CMS, tırnak işaretlerine ve karakterlere zarar vermeden kaçış yapmalıdır;
• aynı şablon, farklı sayfalara aynı verileri eklememelidir;
• dinamik fiyat, stok durumu ve tarihler, görünür içerikle birlikte güncellenmelidir.

Uygulamadan sonra, yalnızca oluşturucudan alınan kodu değil, yayınlanan URL'yi de kontrol edin: şablon, eklenti veya JavaScript, nihai işaretlemeyi değiştirebilir.

İki farklı doğrulama seviyesi

Schema Markup Validator

Schema.org sözlüğünün sözdizimini ve kullanımını kontrol eder. Bulunan türleri, özellikleri ve işaretlemenin genel sorunlarını görmek için uygundur.

Google Rich Results Test

Google'ın sayfada desteklenen bir zengin sonuç türünü tanıyıp tanımadığını ve özel gereksinimlerinin karşılanıp karşılanmadığını gösterir. Araç, zenginleştirmenin aramada görüneceğini onaylamaz. Yayınlamadan sonra, Google'ın işlediği sürümü ve tespit edilen öğeleri görmek için URL'yi Google Search Console'daki URL İnceleme aracılığıyla kontrol etmek de faydalıdır.

Hata ve uyarı evrensel kategoriler değildir

Bir doğrulayıcı, bir özelliğin eksikliğini uyarı olarak değerlendirebilirken, belirli bir tüketici için zorunlu olabilir. Ve tam tersi, Schema.org, Google'ın istenen işlev için kullanmadığı bir özelliğe izin verir. Mesajı dört soruya göre değerlendirin:

1. JSON sözdizimi bozuk mu?
2. Tür ve özellik Schema.org'da mevcut mu?
3. Özellik doğru şekilde iç içe geçmiş mi ve geçerli bir değere sahip mi?
4. Seçilen arama işlevi veya başka bir entegrasyon tarafından gerekli mi?

Sık yapılan hatalar

• Uygun olmayan tür: Ürün kategorisi sayfası, tek bir Product olarak işaretlenmiştir, ancak sayfada tek bir ürün veya birleşik bir teklif yoktur. Veya sıradan bir makale, yalnızca altta küçük bir soru bloğu olduğu için FAQPage alır.
• İşaretleme sayfayla eşleşmiyor: Kodda eski fiyat, var olmayan puan, gizli sorular veya farklı bir yazar belirtilmiştir.
• Çelişen varlıklar: Birden fazla eklenti, farklı adlar, logolar ve URL'ler içeren farklı Organization blokları oluşturur. Nesneler ortak bir @id ile bağlanmaz.
• Yanlış iç içe yerleştirme: Örneğin, price doğrudan Product içine yazılır, oysa teklif genellikle offers özelliğindeki bir Offer nesnesi aracılığıyla tanımlanır.
• Yanlış değer türü: Tarih rastgele metin olarak yazılır, fiyat aynı dizede para birimini içerir, mantıksal değer bir ifade olarak iletilir ve URL bekleyen alan göreli bir yol içerir.
• Erişilemeyen resimler ve sayfalar: URL hata verir, kimlik doğrulama veya robots.txt tarafından engellenir, kararsız bir geçici bağlantıya veya arama motorunun alamadığı bir resme yönlendirir.
• Güncel olmayan dinamik veriler: Etkinlik sona ermiş, iş ilanı kapatılmış, ürün mevcut değil ancak işaretleme eski durumu iletmeye devam eder.
• JSON hataları: Tek veya tipografik tırnak işaretleri; son özellikten sonra fazladan virgül; kapatılmamış köşeli parantez; JSON içinde yorumlar; dize değeri içinde işlenmemiş satır sonu; aynı nesnede yinelenen anahtar.

Uygulama iş akışı

1. Ana nesneyi ve işaretleme amacını belirleyin.
2. Schema.org ve gerekli veri tüketicisinin güncel gereksinimlerini kontrol edin.
3. En doğru türü seçin.
4. Sayfada bulunan yalnızca güvenilir özellikleri doldurun.
5. JSON-LD'yi oluşturun.
6. Kodu Schema Markup Validator'da doğrulayın.
7. Desteklenen bir Google zengin sonucu gerekiyorsa, Rich Results Test ile kontrol edin.
8. Kodu sayfanın test sürümüne ekleyin.
9. Yalnızca izole edilmiş parçayı değil, yayınlanan URL'yi yeniden kontrol edin.
10. Dinamik değerlerin güncellenmesini ve şablon değişikliklerinden sonra yeniden kontrolleri yapılandırın.

Yayınlamadan önce kısa kontrol listesi

• sayfanın gerçek nesne türü seçildi;
• veriler görünür içerikle eşleşiyor;
• uydurma puan, yorum veya özellik yok;
• URL'ler mutlak, erişilebilir ve kurallı olarak tutarlı;
• tarihler açık biçimde ve gerektiğinde saat dilimiyle belirtilmiş;
• fiyat ve para birimi ayrı alanlarda;
• aynı varlıklar sabit bir @id ile bağlanmış;
• başka bir modülden çelişen işaretleme yok;
• kod uygun doğrulamalardan geçti;
• yayınlanan URL aynı doğru JSON-LD'yi içeriyor;
• dinamik veriler güncellenecek.

Sık sorulan sorular

Schema.org zengin bir snippet garantiler mi?

Hayır. Doğru bir işaretleme sayfayı işlenebilir hale getirir, ancak arama motoru bunu kullanıp kullanmayacağına ve sonucu nasıl göstereceğine bağımsız olarak karar verir.

Her sayfaya Schema.org eklemek gerekli mi?

Yalnızca bir varlığın ve onu tanımlamak için yararlı, güvenilir özelliklerin olduğu yerlerde. Aynı bloğun içerikle bağlantısı olmadan toplu olarak eklenmesi hatalara ve çelişkilere yol açar.

Kullanıcının görmediği özellikler bırakılabilir mi?

Teknik ilişkiler ve tanımlayıcılar ayrı bir metin olarak görünmeyebilir, ancak ürün, puan, sorular, etkinlik ve diğer nesneler hakkındaki fiili bilgiler, kullanıcının erişebileceği içeriğe ve tüketicinin kurallarına uygun olmalıdır.

Kod nereye yerleştirilmeli – head mi yoksa body mi?

JSON-LD her iki yerde de bulunabilir. Önemli olan doğru nihai HTML, işaretlemenin işlemci tarafından erişilebilirliği ve mevcut sayfayla tutarlılığıdır.

Schema Markup Validator hata göstermezken Google neden gösteriyor?

İlk araç Schema.org sözlüğünü ve işaretleme yapısını kontrol ederken, Google ayrıca belirli arama işlevinin gereksinimlerini uygular.

Şu anda FAQPage işaretlemek mantıklı mı?

Sayfa gerçekten bir SSS olduğunda ve tür diğer veri tüketicileri için yararlı olduğunda yapılabilir. Ancak çoğu site için Google'ın SSS zengin sonucuna güvenilmemelidir.

Google için HowTo gerekli mi?

Google artık HowTo zengin sonuçları göstermiyor. Tür, diğer sistemler için anlamsal bir açıklama olarak yararlı olmaya devam edebilir, ancak Google'ın önceki arama etkisi beklenmemelidir.

İlgili araçlar

Diffchecker; Metin İşleyici; Base64.

Resmi materyaller

• Schema.org sözlüğü
• Google Search Central — Yapılandırılmış verilere giriş
• Google — Genel yapılandırılmış veri yönergeleri
• Google — Yapılandırılmış veri özellikleri galerisi
• Schema Markup Validator
• Google Rich Results Test

Bölüm için genel editöryel öneriler

1. Her yararlı metnin içinde aynı ticari bloğu kopyalamayın

"Tam SEO denetimi, yapay zekada görünürlük büyümesi için araçlar ve otomasyon" hakkındaki mevcut blok, ana materyalden sonra ayrı bir görsel CTA olarak bırakılabilir. Yararlı bölümler arasındaki makale yapısına gömülmemelidir: bu, okuma akışını keser ve dokuz sayfada da aynı görünür. Bunun yerine, araca uygun kısa ve bağlamsal bir bağlantı kullanmak daha iyidir. Örneğin:

• UTM oluşturucudan sonra — kanallara ve dönüşümlere göre raporlara;
• birleştiriciden sonra — sıklık kontrolü, kümeleme ve sorguların sayfalara atanmasına;
• Schema'dan sonra — yapılandırılmış veri denetimine;
• Diffchecker'dan sonra — sayfa değişikliklerinin izlenmesine;
• yinelenenleri kaldırdıktan sonra — projeye anlambilim veya URL içe aktarmaya.

2. Şablon gereği "Avantajlar" ve "Kimler için uygun" gibi özdeş bölümler yapmayın

İçerikleri neredeyse her zaman tekrarlara dönüşür: "hızlı", "kullanışlı", "ücretsiz", "pazarlamacılar ve uzmanlar için". Belirli senaryoları, sınırlamaları, örnekleri ve SSS'leri bırakmak daha faydalıdır. "Ücretsiz", "tarayıcıda", "kayıt olmadan" gibi kısa özellikler zaten aracın yanında gösterilmektedir.

3. Vaadleri gerçek uygulamayla uyumlu hale getirin

Yayınlamadan önce geliştiricilerin şunları onaylaması gerekir:

• işleme tamamen tarayıcıda mı yapılıyor yoksa veriler sunucuya mı gönderiliyor;
• metin hacmi ve satır sayısı açısından hangi sınırlar mevcut;
• orijinal veriler veya sonuçlar saklanıyor mu;
• dil tespiti için hangi algoritma ve kütüphane kullanılıyor;
• Diffchecker kelimeleri ve satırları tam olarak nasıl karşılaştırıyor;
• yinelenen kaldırma büyük/küçük harf ve boşluklara duyarlı mı ve eylemler hangi sırada uygulanıyor;
• şifre oluşturucu, kriptografik olarak güvenli bir rastgelelik kaynağı kullanıyor mu;
• Base64 dönüştürücü hangi kodlamayı kullanıyor;
• Base64url'ü destekliyor mu yoksa yalnızca standart Base64 mi.

Onaylandıktan sonra, bu ayrıntılar her sayfada kısa bir "İşleme ve gizlilik" bloğuna eklenebilir. Araç görsel olarak tarayıcıda çalıştığı için yerel işleme ve depolama olmadığı vaat edilemez.

4. Sınırlamaları işlevin yanında gösterin, en alta saklamayın

Özellikle önemli uyarılar:

• UTM parametreleri dahili bağlantılara yerleştirilmez;
• Diffchecker anlamı ve fiili doğruluğu kontrol etmez;
• birleştirici talebi onaylamaz ve otomatik olarak site yapısı oluşturmaz;
• Base64 verileri şifrelemez;
• tüm URL kontrol edilmeden küçük harfe dönüştürülmemelidir;
• bir şifre, oluşturucu kontrol edilmeden kriptografik olarak güvenli kabul edilemez;
• geçerli bir Schema.org zengin sonucu garanti etmez.

5. Kullanıcının bir sonraki eylemine göre dahili bağlantılar ekleyin

Sayfanın sonundaki tüm araçların genel listesi yerine, gerçekten ilgili iki veya üç bağlantı yerleştirin. Bağlantı adı, senaryonun devamını açıklamalıdır: "Elde edilen listeyi temizle", "İki sürümü karşılaştır", "Yinelenen kombinasyonları kaldır", "Metnin dilini kontrol et".

6. SSS'leri yalnızca zengin snippet vaadi için işaretlemeyin

Bu metinlerdeki SSS, kullanıcı için yararlıdır ve sayfada kalabilir. Ancak FAQPage ekleme kararı, Schema.org kuralları ve arama motorlarının mevcut kısıtlamaları dikkate alınarak ayrıca verilmelidir. Sıradan siteler için Google şu anda genellikle SSS zengin sonuçları göstermez.

7. Önerilen uygulama sırası

1. Diffchecker, dil tespiti ve UTM — şu anda en az yararlı materyale sahipler.
2. Yinelenenleri kaldırma — tüm URL'leri küçük harfe dönüştürme tavsiyesini acilen düzeltin.
3. Base64 — "şifresini çözmek" ifadesini "kodunu çözmek" ile değiştirin ve Base64url ekleyin.
4. Şifre oluşturucu — uzunluk önerilerini güncelleyin ve rastgele oluşturma uygulamasını kontrol edin.
5. Schema.org — mevcut aşırı uzun ve tekrarlayan metni daha kompakt ancak teknik olarak hassas bir kılavuzla değiştirin.
6. Birleştirici ve metin işleyici — güçlü kısımları koruyun, sınırlamalar ve pratik bir eylem sırası ekleyin.