Schema Markup ve JSON-LD Yapılandırılmış Veri Rehberi

Schema.org ve JSON-LD nedir?

Schema.org, arama motorlarının ortaklaşa tanımladığı bir sözlüktür; Organization, Person, Article gibi tipleri ve bu tiplerin özelliklerini tanımlar. JSON-LD ise bu sözlüğü sayfaya ekleme biçimidir: HTML içine yerleştirilen bir script bloğunda JSON verisi olarak yazılır. Google, JSON-LD'yi önerilen biçim olarak belirtiyor; Microdata ve RDFa da desteklenir.

Yapılandırılmış veri bir sıralama garantisi değildir. Google'a göre bazı şema tipleri belirli zengin sonuçlar için uygunluk sağlar; bazıları ise yalnızca sayfayı anlamaya yardımcı olur. Zengin sonuç desteği zamanla değişir; nitekim FAQ zengin sonucu 2026'da kaldırıldı. Bu nedenle güncel uygunluk için Search Central belgelerine bakın.

Hangi şema tipleri ne için kullanılır?

Bir kişisel marka veya küçük işletme sitesinde birkaç tip çoğu ihtiyacı karşılar. Her tipi yalnızca sayfada gerçekten karşılığı olan içerik için kullanın.

• Organization: kurumsal sitelerde ana sayfa için; ad, logo, resmi site adresi, sosyal profiller (sameAs).
• Person: kişisel markalarda; ad, meslek, bağlı olduğu kurum, sosyal profiller ve uzmanlık alanı.
• LocalBusiness (veya alt tipleri): fiziksel adresi ve çalışma saati olan yerel işletmeler için; adres, telefon, bölge.
• Article / BlogPosting: blog yazıları için; başlık, yazar, yayın ve güncelleme tarihi, görsel.
• BreadcrumbList: sayfanın site hiyerarşisindeki yolunu bildirir.
• FAQPage: görünür SSS içeriğini işaretler; Google'da zengin sonuç sağlamaz, ayrıntı için AEO yazısına bakın.

Örnek JSON-LD yapısı nasıl görünür?

Bir Person şeması, @context ve @type ile başlar, ardından name, jobTitle, url ve sameAs gibi alanları içerir. sameAs alanına yalnızca gerçekten size ait ve doğru profil adreslerini koyun; üçüncü kişilere ait veya ölü bağlantılar güveni zedeler. Bir blog yazısı için BlogPosting; headline, datePublished, dateModified, author ve mainEntityOfPage alanlarını içerir.

Birden çok tipi ayrı script bloklarında ya da tek bir @graph içinde birleştirebilirsiniz. @graph kullanıyorsanız, varlıkları @id ile birbirine bağlayın; örneğin makalenin author alanı, aynı sayfadaki Person varlığının @id'sine işaret etsin. Bu, aynı varlığı iki kez tanımlama karmaşasını önler.

Görünür içerikle uyum kuralı

Google'ın yapılandırılmış veri yönergelerine göre işaretlediğiniz bilgi, kullanıcının sayfada görebildiği içerikle uyumlu olmalı. Sayfada olmayan bir yorum puanı, fiyat veya SSS işaretlemek yönerge ihlalidir ve manuel işlem riski taşır.

Pratikte kural basit: şemada yazan her bilgiyi sayfada da gösterin. Yazar adı şemada varsa, sayfada da yazar adı olsun; güncelleme tarihi varsa sayfada görünsün. Şema yazarken ‘bunu kullanıcı sayfada görebiliyor mu?’ sorusunu sorun.

• Sahte veya kullanıcıya gösterilmeyen yorum ve puanlar eklemeyin.
• Fiyat, stok ve tarih bilgileri sayfayla aynı olsun.
• Başka bir siteye ait içerik veya bilgiyi kendi şemanızda sunmayın.

Doğrulama araçları

İki ana araç var: Schema Markup Validator (validator.schema.org), schema.org sözlüğüne göre genel sözdizimi ve tür kontrolü yapar. Google'ın Rich Results Test aracı ise yalnızca Google'ın zengin sonuç için desteklediği tipleri değerlendirir; FAQ gibi kaldırılan tipler için desteğin sonlandırıldığı Google tarafından duyurulmuştu.

Kontrol akışı: önce Schema Markup Validator ile geçerliliği doğrulayın, sonra Rich Results Test ile Google uygunluğunu denetleyin, canlıya aldıktan sonra Search Console'daki ilgili iyileştirme raporlarını izleyin. Araçlarda uyarı görünmesi her zaman hata değildir; zorunlu ve önerilen alanları ayırt edin.

Tek sayfalı uygulamalarda (SPA) dikkat edilecekler

React gibi istemci taraflı çalışan sitelerde JSON-LD'nin tarayıcıda oluşturulması durumunda Google'ın bunu işleyebildiği belirtiliyor, ama bu işleme ek bir adımdır ve gecikebilir. Mümkünse yapılandırılmış veriyi sunucu tarafında ya da build aşamasında HTML'e dahil edin.

Her rota için ayrı ve doğru şema üretilmelidir. Tüm sayfalarda aynı ana sayfa Organization şemasını bırakmak ya da yönlendirmeler sonrasında eski sayfanın şemasının kalması sık görülen bir sorundur. Rota değişiminde script bloğunun güncellendiğini gerçek tarayıcıda ve Rich Results Test'te kontrol edin.

Yaygın hatalar

En sık hata, şemayı bir sihirli değnek sanıp içeriğin zayıflığını örtmeye çalışmak. Şema, içeriğin yerini tutmaz; sayfadaki bilgiyi netleştirir. İkinci hata, şablondan gelen hazır kodu kontrol etmeden kullanmak: yanlış telefon, eski adres veya başka bir markanın adı sitede kalabiliyor.

Üçüncü hata, JSON sözdizimi: kapanmamış virgül, tırnak hataları veya tekrar eden @id değerleri bloğun tamamını geçersiz kılabilir. Her değişiklikten sonra doğrulayıcıdan geçirin.

• Görünür içerikle çelişen alanlar.
• Eski veya yanlış iletişim bilgisi.
• Gereksiz veya sayfa ile ilgisiz tip kullanımı.
• Doğrulama yapmadan canlıya alma.
• Silinen zengin sonuç tipleri için hâlâ hata beklemek veya beklentiyle işaretleme eklemek.

Hızlı kurulum kontrol listesi

Yeni bir site için önerdiğim sıra şöyle: ana sayfaya Organization veya Person, tüm blog yazılarına BlogPosting, iç sayfalara BreadcrumbList, yerel işletme ise LocalBusiness ekleyin. Sonra her şablonu doğrulayıp birkaç örnek sayfayı Search Console'da inceleyin.

Yapılandırılmış veri bir kez yazılıp unutulacak bir iş değil. Adres, telefon, hizmet kapsamı veya yazar bilgisi değiştiğinde şemayı da güncelleyin ve üç ayda bir toplu doğrulama yapın.

Örnek kalıp: Person ve BlogPosting nasıl bağlanır?

Kod bloğu yerine alan alan tarif ediyorum; bunu kendi JSON-LD'nize çevirebilirsiniz. Ana sayfada bir @graph içinde Person varlığı tanımlayın: @type Person, name, jobTitle, url, sameAs (gerçek profil adresleri) ve @id olarak sayfa adresinin sonuna #kisi eklenmiş bir kimlik.

Blog yazısı sayfasında @type BlogPosting varlığı tanımlayın: headline (görünür başlıkla aynı), datePublished, dateModified, image, mainEntityOfPage ve author alanı. author içinde yeniden tüm kişi bilgilerini yazmak yerine, ana sayfadaki Person varlığının @id değerine işaret edin. Böylece makale ile yazar aynı varlığa bağlanır ve bilgi tekrarı ya da çelişkisi oluşmaz.

• Person: name, jobTitle, url, sameAs, @id.
• BlogPosting: headline, datePublished, dateModified, image, mainEntityOfPage, author (@id ile bağlı).
• BreadcrumbList: itemListElement içinde sıra numarası (position), ad (name) ve adres (item) üçlüsü; son öğe geçerli sayfa.
• Tüm tarihler ISO 8601 biçiminde olsun, örneğin 2026-09-30.

Hangi sayfaya hangi şema?

Her sayfaya mümkün olan tüm şemayı eklemek yerine, sayfanın rolüne uygun olanı seçin. Aşağıdaki eşleştirme, küçük bir hizmet veya kişisel marka sitesi için bir başlangıç noktasıdır; sektörünüze göre uyarlayın.

Şüphe duyduğunuzda şu soruyu sorun: bu bilgi sayfada görünür mü ve gerçekten bu sayfa mı bunu anlatıyor? İkisine de evet diyemiyorsanız ilgili şemayı eklemeyin.

• Ana sayfa: Organization veya Person (ve varsa WebSite).
• Hakkımda / iletişim sayfası: Person veya Organization, LocalBusiness için adres ve telefon bilgileriyle.
• Blog yazısı: BlogPosting (veya Article), BreadcrumbList.
• Hizmet sayfası: Service veya ProfessionalService türleri; yalnızca gerçekten sunulan hizmetler için.
• İlçe / il yerel sayfası: LocalBusiness alt türü, hizmet bölgesi ve BreadcrumbList.

Hata ayıklama ve bakım takvimi

Doğrulayıcıda hata görüyorsanız önce JSON sözdizimini düzeltin: eksik virgül, kapanmayan parantez ve çift tırnak yerine tipografik tırnak kullanımı sık görülen sebeplerdir. Ardından zorunlu alanların eksikliğine bakın; son olarak varlıkların @id ile doğru bağlandığını kontrol edin.

Bakım için takvim koyun: aylık olarak Search Console iyileştirme raporlarına bakın, her yeni şablon yayınında örnek bir sayfayı doğrulayın, her üç ayda bir iletişim ve sosyal profil bilgilerini şemadakilerle karşılaştırın. Büyük tasarım veya altyapı değişikliklerinde şema bloklarının kaybolup kaybolmadığını mutlaka kontrol edin.

• Ay 1: tüm şablonlar için şema envanteri çıkarın.
• Her yayın: örnek sayfayı Rich Results Test ve Schema Markup Validator'dan geçirin.
• Her 3 ay: iletişim bilgisi, sameAs ve tarih alanlarının güncelliğini kontrol edin.
• Her büyük değişiklik: şema bloklarının hâlâ HTML çıktısında olduğunu doğrulayın.

Şema ve yapay zekâ: ne biliyoruz?

Yapılandırılmış verinin yapay zekâ yanıtlarında alıntılanmayı artırdığına dair genel kabul görmüş bağımsız bir kanıt bugün yok. Arama motorları şemayı sayfayı anlamak için kullanabiliyor; yapay zekâ ürünlerinin bunu ne ölçüde kullandığı çoğunlukla açıklanmıyor. Bu yüzden şemayı ‘GEO hilesi’ olarak değil, sayfanızı doğru ve tutarlı anlatmanın bir parçası olarak ele alın.

Pratik sonuç: şema yazmak için harcanacak zamanı, içeriğin kendisini güçlendirmeye harcanacak zamanla dengeleyin. Doğru, güncel ve görünür içerikle uyumlu şema düşük maliyetli bir iyileştirmedir; ama içerik zayıfsa tek başına bir fark yaratmaz.