Google araçları olmadan yapılandırılmış veriler nasıl doğrulanır

Yapılandırılmış veri doğrulaması, tuhaf biçimde Google’a yönelik araçlara bağımlı hâle geldi. Bu anlaşılır bir durum: birçok ekip JSON-LD ekliyor çünkü zengin sonuçlar istiyor ve Google’ın test araçları tanıdık geliyor. Ancak yapılandırılmış veri bir Google formatı değildir. Genellikle HTML içine yerleştirilmiş, Schema.org sözlüğünü kullanan JSON-LD’dir; birçok tüketici tarafından yorumlanır ve kendi yayınlama iş akışınız tarafından sürdürülür.

Yalnızca bir arama motoru merceğinden doğrulama yaparsanız temel sorunları kaçırabilirsiniz: geçersiz JSON, işleme sonrasında kaybolan veri, güncelliğini yitirmiş ürün fiyatları, çelişkili canonical URL’ler veya teknik olarak geçerli olsa da anlamsal açıdan mantıksız işaretleme.

Daha iyi bir iş akışı standartları öncelemektir. Veriyi önce veri olarak doğrulayın, ardından sözlüğü doğrulayın, sonra da sayfayı üretimde var olduğu hâliyle doğrulayın.

Aslında neyi doğruluyorsunuz?

“Yapılandırılmış veri” tek bir şey değildir. Çoğu web sitesinde dört katmanı vardır:

1. JSON söz dizimi — kod ayrıştırılabiliyor mu?
2. JSON-LD modeli — anlamlı bağlı veriye genişliyor mu?
3. Schema.org sözlüğü — türler ve özellikler makul mü?
4. Sayfa düzeyi gerçekliği — işaretleme, kullanıcıların ve tarayıcıların görebildiği şeyle eşleşiyor mu?

Google araçları çoğunlukla dördüncü katmana ve Google’a özgü zengin sonuç uygunluğuna odaklanır. Evet, faydalıdır. Ama eksiksiz değildir.

Örneğin, aşağıdaki geçerli JSON-LD olabilir ve yine de zayıf yapılandırılmış veri sayılabilir:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Burada bozuk bir şey yok. Ancak görünür sayfada farklı bir başlık, yazar atfı yoksa ve işaretlemeyle çelişen bir son değiştirilme tarihi varsa, söz dizimi probleminden çok bir kalite probleminiz vardır.

Adım 1: SEO’yu düşünmeden önce JSON’ı ayrıştırın

Sıkıcı kontrolden başlayın: JSON ayrıştırılabiliyor mu?

HTML içine yerleştirilmiş JSON-LD, çoğu zaman küçük şablon hataları nedeniyle bozulur:

• sonda kalan virgüller
• ürün adlarında kaçışlanmamış tırnak işaretleri
• dizelerin içinde geçersiz satır sonları
• koşullu alanlardan sonra eksik süslü parantezler
• layout mirasından gelen yinelenen script blokları
• kısmi nesneler çıktılayan CMS eklentileri

Yerel kontroller için bir SEO platformuna ihtiyacınız yoktur. Geliştirme yığınınızda zaten bulunan araçları kullanın.

JavaScript’te:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

CI içinde, işlenmiş HTML’den script içeriklerini çıkarın ve bunları JSON olarak ayrıştırın. Bu, birçok sorunu üretime ulaşmadan yakalar.

Önemli nokta şu: bunu herhangi bir Schema.org doğrulamasından önce yapın. Veri geçerli JSON değilse bir sözlük doğrulayıcısı yardımcı olamaz.

Adım 2: Yalnızca JSON söz dizimini değil, JSON-LD davranışını kontrol edin

Geçerli JSON otomatik olarak geçerli JSON-LD anlamına gelmez. JSON-LD @context, @type, @id ve graph ilişkileri gibi kavramları kullanır. Bunlar hatalı biçimlendirilirse ayrıştırıcılar verinizi amaçladığınızdan farklı yorumlayabilir.

En azından şunları doğrulayın:

• her blok uygun bir @context içeriyor
• birincil varlıkların net @type değerleri var
• tekrarlanan varlıklar, yararlı olduğu yerlerde kararlı @id değerleri kullanıyor
• iç içe varlıklar mantıksal olarak bağlı
• birden çok değerin mümkün olduğu yerlerde diziler kullanılıyor

Daha büyük siteler için kararlı tanımlayıcılar özellikle faydalıdır. Kuruluşunuz Article, Product, BreadcrumbList ve FAQPage verilerinde görünüyorsa, aynı @id değerini kullanmak tüketicilerin bunların aynı varlığa referans olduğunu anlamasına yardımcı olur; aynı ada sahip dört alakasız kuruluş olmadıklarını gösterir.

Tipik bir kalıp şöyle görünür:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Burada bir doğrulayıcıyı etkilemeye çalışmıyorsunuz. Verinizi daha az belirsiz hâle getiriyorsunuz.

Adım 3: Schema.org sözlüğüne göre doğrulayın

JSON ve JSON-LD yapısı sağlam olduğunda, sözlüğü kontrol edin.

Schema.org doğrulayıcısı faydalıdır çünkü bir arama motorunun zengin sonuç kuralları yerine Schema.org terimlerine göre test yapar. Özelliklerin tanınıp tanınmadığını, türlerin beklendiği gibi yorumlanıp yorumlanmadığını ve iç içe yapılarınızın anlamlı olup olmadığını gösterebilir.

Bu aşamada şu tür hataları yakalarsınız:

• datePublished yerine publishingDate
• image beklenen yerde imageUrl
• ürün olmayan bir kategori listelemesinde Product işaretlemesi
• anlamlı bir incelenen öğe olmadan AggregateRating
• bir marka hesabı için Person kullanılması

Uyarılara dikkatle yaklaşın. Schema.org bilinçli olarak esnektir. Bir doğrulayıcı, kullanım durumunuz için faydalı olmayan bir özelliğe izin verebilir veya isteğe bağlı bir konu hakkında uyarı verebilir. Doğrulamayı bir kanıt olarak görün, hüküm olarak değil.

Pratik bir kural: Bir özellik makinenin sayfayı daha doğru anlamasına yardımcı oluyorsa, onu tutun. Yalnızca biri onu bir snippet oluşturucudan kopyaladığı için varsa, sorgulayın.

Adım 4: İşaretlemeyi görünür içerikle karşılaştırın

Arama motorları ve diğer veri tüketicileri, sayfayla eşleşmeyen işaretlemeye güvenmemeye eğilimlidir. Daha önemlisi, kullanıcılar tutarlılığı hak eder.

Her yapılandırılmış veri türü için işaretlemeyi görünür sayfayla karşılaştırın:

Article ve BlogPosting

Başlığın, yazarın, yayın tarihinin, değiştirilme tarihinin, görselin ve yayıncının görünür veya makul biçimde çıkarılabilir olduğunu kontrol edin. Yapay zekâ destekli içerik yayımlıyorsanız, yapılandırılmış veriniz belirsiz yazarlığı aklamak için kullanılmamalıdır. Küçük bir web sitesinde dürüst yapay zekâ açıklamasının nasıl göründüğü hakkında ayrıca yazdık; aynı ilke burada da geçerlidir: meta veri açıklık getirmeli, gizlememelidir.

Product

Adı, fiyatı, stok durumunu, para birimini, varyantları, puanları ve yorum sayılarını kontrol edin. Ürün yapılandırılmış verisi özellikle hızlı bayatlar çünkü fiyatlar ve stok durumu CMS dışında değişir.

LocalBusiness

Adı, adresi, telefon numarasını, çalışma saatlerini ve hizmet bölgesini kontrol edin. Footer bir şey söylüyor, JSON-LD başka bir şey söylüyorsa, JSON-LD “daha iyi” değildir. Çelişkilidir.

BreadcrumbList

Breadcrumb konumlarının görünür breadcrumb yoluyla eşleştiğini ve URL’lerin canonical, taranabilir ve gereksiz yere yönlendirilmemiş olduğunu kontrol edin.

Bu gösterişli bir iş değildir. Aynı zamanda birçok yapılandırılmış veri sorununun bulunduğu yerdir.

Adım 5: Şablonunuzu değil, işlenmiş sayfayı doğrulayın

Birçok site JSON-LD’yi JavaScript, tag manager’lar, kişiselleştirme katmanları veya bileşen hidrasyonu üzerinden üretir. Bu, şablon dosyasının bir tarayıcının veya crawler’ın gerçekte gördüğünü temsil etmeyebileceği anlamına gelir.

İşlenmiş HTML’yi en az üç durumda doğrulayın:

• yerel geliştirme derlemesi
• staging veya önizleme URL’si
• üretim URL’si

Son DOM’u incelemek için browser DevTools kullanın. application/ld+json arayın ve işleme sonrasında var olan tam script içeriğini kopyalayın. Server-rendered işaretleme hydrated işaretlemeden farklıysa, tüketicilerin hangi sürümü okumasını beklediğinize karar verin.

Ayrıca yapılandırılmış verinin yinelenip yinelenmediğini kontrol edin. Bir CMS eklentisi ve özel bir bileşen aynı anda schema ürettiğinde yinelenen Article veya Product blokları yaygındır. Yinelenme her zaman ölümcül değildir, ancak çelişkili yinelenme bir problemdir: iki fiyat, iki yazar, iki yayın tarihi veya iki canonical URL.

Bu, performans ve tanılama raporlarını okumaya benzer: ilk görev paniğe kapılmak değil, sinyali gürültüden ayırmaktır. Aynı alışkanlık, paniğe kapılmadan bir Lighthouse raporu okurken de yardımcı olur — ancak yapılandırılmış verinin kendisi tek bir skora indirgenmemelidir.

Adım 6: Üretim aktarım ayrıntılarını kontrol edin

Yapılandırılmış veri kaynakta kusursuz olabilir ve yine de sayfa varsaydığınız şekilde erişilebilir olmadığı için üretimde başarısız olabilir.

Kontrol edin:

• nihai durum kodu soft 404 değil, 200
• canonical URL doğruladığınız sayfayla eşleşiyor
• yönlendirmeler kasıtlı ve kararlı
• indexing beklendiği yerde robots yönergeleri indexing’i engellemiyor
• HTML bazı user agent’lar için hata sayfasıyla değiştirilmiyor
• önbelleğe alınmış sayfalar bayat JSON-LD sunmuyor

HTTP incelemesinin önemli olduğu yer burasıdır. Bir ürün sayfası canonical hedefe ulaşmadan önce üç URL üzerinden yönleniyorsa, CMS’den kopyalanan ilk URL’yi değil, nihai sayfayı doğrulayın. Ham işleyiş için üretimde yönlendirmeleri ve HTTP header’larını debug etme rehberimiz yararlı bir eşlikçidir.

Yapılandırılmış veri boşlukta yaşamaz. Header’lar, yönlendirmeler, caching, canonical tag’ler ve robots yönergeleriyle birlikte hareket eder.

Adım 7: Yayın sürecinize yapılandırılmış veri testleri ekleyin

Manuel doğrulama tek bir sayfa için uygundur. Yüzlerce veya binlerce URL’ye ölçeklenmez.

Basit bir otomatik test paketi en pahalı hataları yakalayabilir:

• her şablon türünden temsili URL’leri getir
• tüm JSON-LD bloklarını çıkar
• bunları JSON.parse ile ayrıştır
• her sayfa türü için gerekli alanları doğrula
• tarihlerin geçerli ISO 8601 dizeleri olduğunu kontrol et
• URL’lerin mutlak ve canonical olduğunu kontrol et
• ürün sayfaları için fiyatların ve stok durumunun var olduğunu kontrol et
• yinelenen varlıkların çelişmediğini kontrol et

Bunu şablonlar için CI içinde, üretim URL’leri için de zamanlanmış olarak çalıştırabilirsiniz. Amaç her zengin sonuç özelliğinin görüneceğini kanıtlamak değildir. Arama motorunun dışındaki hiç kimse bunu vaat edemez. Amaç kendi verinizi doğru, ayrıştırılabilir ve tutarlı tutmaktır.

<!-- tool-cta:start -->

💡 Bunu deneyin: Şema mantığını doğrulamadan önce, aksi takdirde sonraki her kontrolü bozacak söz dizimi hatalarını yakalamak için JSON-LD’nizi JSON Formatter üzerinden geçirin.

<!-- tool-cta:end -->

Standartları önceleyen doğrulama kontrol listesi

Bir arama motorunun sayfayı beğenip beğenmediğini sormadan önce bu kısa kontrol listesini kullanın:

• Her JSON-LD bloğu geçerli JSON mı?
• Her blok doğru @context ve @type içeriyor mu?
• Schema.org özellikleri doğru yazılmış mı?
• İşaretleme görünür içerikle eşleşiyor mu?
• Tarihler, fiyatlar, puanlar ve stok durumu güncel mi?
• URL’ler mutlak, canonical ve erişilebilir mi?
• İşlenmiş üretim sayfası test ettiğiniz sayfayla aynı mı?
• Yinelenen varlıklar kasıtlı ve çelişkisiz mi?

Bu sorulara evet yanıtı verebiliyorsanız, yapılandırılmış veri çalışmasının kalıcı kısmını yapmışsınız demektir. Aramaya özgü testler daha sonra hâlâ faydalı olabilir, ancak doğrulama sürecinizin temeli değil, son uyumluluk kontrolü olmalıdır.