Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri

Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri, yalnızca bir JSON-LD kodunu doğrulama aracına yapıştırıp yeşil sonuç almak anlamına gelmez. Gerçek bir teknik SEO sürecinde kodun sözdizimi, Schema.org kuralları, Google desteği, sayfadaki görünür içerikle uyumu, render sonucu ve üretim ortamındaki indekslenebilirlik birlikte değerlendirilir. On yıllık proje deneyimimde en sık karşılaştığım sorunlardan biri, geliştiricinin “schema geçerli” demesiyle SEO ekibinin “o halde Google bunu gösterecek” sonucuna ulaşmasıdır. Oysa geçerlilik ile arama sonucunda görünme arasında birkaç ayrı kontrol katmanı bulunur. Bu rehberde rich snippets için yapılandırılmış veri testi nasıl yapılır, schema markup hataları nasıl tespit edilir ve düzeltilir, Google Rich Results Test ile yapılandırılmış veri doğrulama nasıl uygulanır ve JSON-LD schema markup ile zengin sonuç görünürlüğü nasıl artırılır gibi soruları teknik açıdan adım adım ele alacağız.

Yapılandırılmış Veri (Structured Data) Nedir?

Yapılandırılmış veri, bir web sayfasındaki bilgilerin anlamını makinelerin daha kolay yorumlayabileceği belirli bir sözlük ve biçim üzerinden açıklama yöntemidir. Bir ürün sayfasında görünen fiyatın fiyat, stok bilgisinin stok durumu ve marka adının marka olduğunu arama motoruna açık biçimde anlatabilirsiniz. Bu veri normal ziyaretçinin gördüğü içeriğin yerine geçmez, onu anlamsal olarak destekler. En yaygın kullanım alanları ürünler, makaleler, etkinlikler, içerik kırıntıları ve kurumsal varlıklardır. Sağlıklı bir uygulamada yapılandırılmış veri, sayfadaki gerçek bilgilerin teknik bir temsili olarak çalışır.

Schema Markup Nedir?

Schema markup, bir sayfadaki varlıkları ve bu varlıkların özelliklerini standart biçimde tanımlamak için kullanılan işaretlemedir. Örneğin bir ürün için ad, marka, SKU, fiyat ve stok durumu gibi bilgiler belirli property alanlarıyla ifade edilir. Buradaki amaç arama motoruna yeni bilgi uydurmak değil, ziyaretçinin sayfada zaten görebildiği bilgiyi daha açık biçimde sunmaktır. İyi hazırlanmış bir schema yapısı geliştirme, içerik ve SEO ekipleri arasında ortak bir veri sözleşmesi gibi çalışabilir. Bu nedenle schema markup, yalnızca SEO eklentisinin oluşturduğu görünmez birkaç satır kod olarak düşünülmemelidir.

Schema.org Nedir?

Schema.org, web üzerindeki varlıkları ve özellikleri tanımlamak için kullanılan geniş kapsamlı bir vocabulary sunar. Product, Article, Organization, Event ve BreadcrumbList gibi type tanımları bu sözlük içinde yer alır. Her type belirli property alanlarıyla ilişkilidir ve bazı property değerlerinin beklenen veri türleri vardır. Ancak Schema.org içinde bir type bulunması, Google Search'ün o type için özel bir zengin sonuç göstereceği anlamına gelmez. Bu ayrım, yapılandırılmış veri testlerinde en önemli teknik kontrol noktalarından biridir.

JSON-LD Nedir?

JSON-LD, yapılandırılmış veriyi JSON söz dizimi üzerinden ifade eden ve web projelerinde yaygın biçimde kullanılan bir formattır. Genellikle sayfaya application/ld+json türündeki bir script etiketi içinde eklenir. HTML elementlerinin içine tek tek property yerleştirmek gerekmediği için bakım süreci çoğu projede daha rahattır. Veri modeli backend, CMS veya API üzerinden oluşturuluyorsa JSON-LD üretimini uygulamanın veri akışıyla birleştirmek de kolaylaşır. Benim tercih ettiğim yaklaşım, JSON-LD'yi elle yazılmış sabit kod olmaktan çıkarıp gerçek veri kaynağından üretilen test edilebilir bir çıktı haline getirmektir.

Rich Result Nedir?

Rich result, Google Search sonuçlarında standart başlık, URL ve açıklama gösteriminin ötesinde ek görsel veya bilgisel öğeler içerebilen arama sonucu deneyimlerini ifade eder. Ürün fiyatı, stok bilgisi, puanlama, etkinlik bilgileri veya farklı desteklenen özellikler bu deneyimin bir parçası olabilir. Yapılandırılmış veri, Google'ın bu bilgileri anlamasına yardımcı olan kaynaklardan biridir. Bununla birlikte uygun işaretlemenin bulunması, belirli bir sorguda zengin görünümün kesin olarak sunulacağı anlamına gelmez. Google, gösterim kararını kendi arama sistemleri ve geçerli özellik kuralları doğrultusunda verir.

Rich Snippet ile Rich Result Arasındaki Fark

Rich snippet ifadesi uzun süredir SEO sektöründe kullanılan popüler bir terimdir ve çoğu zaman zenginleştirilmiş organik sonuçları anlatır. Rich result ise Google'ın dokümantasyonunda daha geniş kapsamda kullanılan güncel kavramdır. Pratik konuşmalarda iki ifade birbirinin yerine kullanılabilir, fakat teknik dokümantasyon incelenirken Google'ın kullandığı terminolojiye dikkat etmek yararlıdır. Bir projenin test planını oluştururken ekip üyelerinin aynı kavramları aynı anlamda kullanması yanlış beklentileri azaltır. Özellikle destekten kaldırılan özellikleri takip ederken “schema mevcut” ile “Google Search feature aktif” ifadelerini birbirinden ayırmak gerekir.

Yapılandırılmış Veri Neden Test Edilmelidir?

Yapılandırılmış veri küçük bir kod parçası gibi görünse de fiyat, tarih, URL, stok ve entity ilişkileri gibi birçok değişken içerir. API değişikliği, tema güncellemesi, CMS alanının boş kalması veya frontend refactor işlemi daha önce çalışan schema çıktısını bozabilir. Üstelik JSON sözdizimi geçerli olsa bile kullanılan property yanlış type altında bulunabilir veya Google'ın gerekli gördüğü bir alan eksik olabilir. Bu nedenle test süreci yalnızca ilk uygulama sırasında yapılmamalıdır. Schema sağlığı, release öncesinde ve production sonrasında düzenli olarak izlenmelidir.

Yapılandırılmış Veri Testinde Dört Farklı Doğruluk Seviyesi

Yapılandırılmış veri doğrulamasını dört katmanda düşünmek uygulamada ciddi kolaylık sağlar. Birinci katman JSON'un teknik olarak parse edilip edilmediğini, ikinci katman kullanılan type ve property yapısının Schema.org açısından anlamlı olup olmadığını inceler. Üçüncü katman Google'ın belirli bir Search feature için istediği kuralları karşılayıp karşılamadığınızı değerlendirir. Dördüncü katman ise sayfanın gerçekten Google Search'te ilgili zengin görünümle gösterilip gösterilmediğidir. Bu seviyeleri ayrı ölçmek, “test geçti ama sonuç görünmüyor” tartışmalarını daha sağlıklı çözmenizi sağlar.

Seviye 1 — JSON Syntax Valid

İlk seviyede amaç JSON-LD verisinin geçerli JSON olarak parse edilebilmesidir. Eksik virgül, yanlış tırnak, kapatılmamış süslü parantez veya hatalı escape karakteri bu seviyede sorun çıkarır. Bu kontrol, arama motoruna özel değildir ve standart bir JSON parser ile otomatik hale getirilebilir. CI ortamında saniyeler içinde çalıştırılabildiği için en erken kalite kapılarından biri olmalıdır. JSON parse edilemiyorsa daha ileri schema kontrollerine geçmenin pratik bir anlamı yoktur.

Seviye 2 — Schema.org Valid

İkinci seviyede JSON teknik olarak geçerli olsa bile anlamsal model kontrol edilir. Kullanılan @type değerinin varlığı, property'nin ilgili type ile ilişkisi ve beklenen value type burada önem kazanır. Örneğin bir property metin beklerken yanlış nesne yapısı göndermek sözdizimi açısından sorun yaratmayabilir, fakat vocabulary açısından problem oluşturabilir. Schema Markup Validator gibi araçlar bu seviyede oldukça değerlidir. Böylece Google Search desteğinden bağımsız olarak genel Schema.org uyumluluğunu görebilirsiniz.

Seviye 3 — Google Rich Result Eligible

Üçüncü seviye, Google'ın desteklediği belirli bir zengin sonuç özelliği için gerekli şartların karşılanıp karşılanmadığını inceler. Burada required ve recommended property ayrımı devreye girer. Schema.org açısından geçerli bir yapı, Google'ın özel kullanım kurallarında eksik kabul edilebilir. Google Rich Results Test özellikle bu sorunun yanıtını bulmak için kullanılır. Bu aşama başarılı olduğunda sayfa zengin sonuç için uygun olabilir, fakat gerçek gösterim yine garanti edilmiş olmaz.

Seviye 4 — Google Search'te Gerçekten Gösteriliyor

Dördüncü seviye production gerçekliğidir ve önceki üç testten farklı bir anlam taşır. Sayfa teknik olarak kusursuz ve ilgili özellik için uygun olsa bile Google belirli bir sorguda zengin görünümü göstermeyebilir. İndeksleme durumu, sorgu bağlamı, cihaz, arama deneyimi, kalite değerlendirmeleri ve Google'ın ilgili özelliği nasıl sunduğu sonucu etkileyebilir. Bu nedenle Search Console performans verileri ve gerçek arama görünümü ayrıca izlenmelidir. Teknik ekibin başarısını yalnızca SERP ekran görüntüsüne bağlamak da sağlıklı değildir, çünkü gösterim kararı tamamen sitenin kontrolünde değildir.

Bu Dört Seviye Neden Birbirine Karıştırılmamalıdır?

Bu seviyeler birbirine karıştırıldığında ekipler yanlış sorunu çözmeye çalışmaya başlar. Parse hatası yaşayan bir JSON için Search Console gösterimlerini incelemek erken bir adımdır, aynı şekilde tüm validator testlerinden geçen bir sayfada yalnızca kodu yeniden yazmak da gereksiz olabilir. Ben projelerde hata kaydına hangi doğruluk seviyesinde sorun bulunduğunu eklemeyi yararlı buluyorum. Böylece geliştirici, QA ve SEO ekipleri sorunun nerede başladığını hızlıca görür. Bu yaklaşım özellikle yüz binlerce URL barındıran platformlarda hata yönetimini daha düzenli hale getirir.

Geçerli Schema Zengin Sonuç Garantisi Verir mi?

Hayır, geçerli schema zengin sonuç garantisi vermez. Teknik validation yalnızca işaretlemenin belirli bir kontrol setine uyduğunu gösterir. Google tarafından desteklenen bir özellik için eligibility elde etmek de nihai görünümün zorunlu olduğu anlamına gelmez. Arama motoru sorguya, cihaza, sayfanın genel durumuna ve kendi ürün kararlarına göre farklı sunumlar tercih edebilir. Bu nedenle Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri yapılırken başarı kriteri yalnızca “validator yeşil” şeklinde tanımlanmamalıdır.

Validation ile Eligibility Arasındaki Fark

Validation, verinin belirli teknik ve anlamsal kurallara uygunluğunu ölçer. Eligibility ise Google'ın belirli bir Search feature için tanımladığı uygunluk koşullarına odaklanır. Schema.org üzerinde doğru kabul edilen her property Google'ın kullandığı zengin sonuç formatına dahil edilmez. Aynı şekilde Google bir özellik için Schema.org sözlüğündeki alanların yalnızca belirli bölümünü zorunlu veya önerilen olarak belirleyebilir. İki kontrolü ayrı raporlamak teknik kararların daha doğru verilmesini sağlar.

Eligibility ile Actual Appearance Arasındaki Fark

Eligibility elde etmek, Google'a ilgili zengin sonuç biçimi için değerlendirilebilecek bir sayfa sunduğunuzu gösterir. Actual appearance ise bu zengin görünümün gerçekten arama sonucunda gösterilmesidir. İkinci karar Google tarafından sorgu bazında ve arama deneyiminin genel bağlamı içinde verilir. Bu yüzden ekiplerin “uygunluk oranı” ile “rich result impression” gibi performans metriklerini ayrı izlemesi gerekir. Böyle bir ayrım yapıldığında teknik hata ile Google'ın ürün kararını birbirine karıştırmazsınız.

Google'ın Nihai Gösterim Kararı

Google, yapılandırılmış veriyi zengin sonuç oluştururken kullanabilir, ancak gösterim üzerinde tek belirleyici markup değildir. Arama sorgusunun niteliği, kullanıcının cihazı ve Google Search arayüzündeki güncel özellikler sonucu etkileyebilir. Belirli bir schema türü destekleniyor olsa bile her sorguda aynı sunumun görülmesi beklenmemelidir. Bu nedenle test raporlarında “eligible” ve “displayed” durumlarını farklı sütunlarda tutmak daha doğru olur. Böylece teknik ekip kontrol edebildiği alanlardan sorumlu tutulur.

Sorgu ve Cihaz Bağlamı

Aynı URL farklı sorgularda aynı zengin görünümü almak zorunda değildir. Mobil arama sonuçlarında kullanılan alan ile masaüstünde kullanılan alan ve arayüz tercihleri farklılaşabilir. Bu nedenle gerçek SERP kontrolleri yapılırken tek bir anahtar kelimeye veya tek bir cihaza bağımlı kalmamak gerekir. Googlebot Smartphone üzerinden render testinin önemi de buradan gelir. Mobil deneyim artık structured data test planında ayrı bir kontrol maddesi olarak ele alınmelidir.

Kalite ve Politika Gereksinimleri

Teknik olarak geçerli bir schema, kalite ve spam politikalarına aykırı bilgi içeriyorsa güvenli bir uygulama değildir. Sayfada bulunmayan değerlendirmeleri eklemek, gerçek olmayan puan üretmek veya görünmeyen bilgileri markup içine yerleştirmek bunun bilinen örnekleridir. Yapılandırılmış veri ziyaretçiye sunulan gerçek içeriği doğru biçimde temsil etmelidir. Teknik validation araçları her bağlamsal veya kalite sorununu tek başına yakalayamaz. İnsan incelemesi ve content parity testleri bu nedenle süreçte yer almalıdır.

Yapılandırılmış Veri İçin Desteklenen Formatlar

Google structured data uygulamalarında JSON-LD, Microdata ve RDFa gibi formatlarla karşılaşabilirsiniz. Üç format da doğru uygulandığında yapılandırılmış veri taşıyabilir. Seçim yapılırken yalnızca SEO açısından değil, geliştirme mimarisi, bakım maliyeti ve veri kaynağı yönetimi açısından da düşünmek gerekir. Modern uygulamalarda JSON-LD çoğu ekip için daha rahat bir geliştirme deneyimi sağlar. Bununla birlikte çalışan bir Microdata yapısını yalnızca moda olduğu için yeniden yazmak her zaman gerekli değildir.

JSON-LD

JSON-LD HTML elementlerinden bağımsız biçimde tanımlanabildiği için geliştiricilere esnek bir uygulama modeli sunar. Backend veya frontend tarafındaki gerçek veri modelinden üretilebilir ve unit test kapsamına alınabilir. Entity ilişkileri @id ve @graph gibi mekanizmalarla daha düzenli ifade edilebilir. Büyük projelerde ortak schema generator geliştirmek de bu formatla daha kolay hale gelir. Bu nedenle yeni projelerde benim ilk değerlendirdiğim seçenek genellikle JSON-LD olur.

Microdata

Microdata, structured data bilgisini doğrudan HTML elementleri üzerinde tanımlayan bir yaklaşımdır. İçeriğe yakın olması bazı projelerde avantaj sağlarken, yoğun şablonlarda bakım yükünü artırabilir. Bir HTML bileşeninin yeniden düzenlenmesi markup ilişkisinin fark edilmeden bozulmasına yol açabilir. Buna rağmen mevcut sistem doğru çalışıyor ve testlerle korunuyorsa yalnızca format değişikliği için migration yapmak zorunlu değildir. Karar teknik borç, ekip bilgisi ve bakım maliyeti birlikte değerlendirilerek verilmelidir.

RDFa

RDFa da HTML üzerinde anlamsal ilişkileri tanımlamak için kullanılabilen bir formattır. Bazı mevcut sistemlerde veya daha geniş semantic web ihtiyaçlarında karşınıza çıkabilir. Structured data test sürecinde formatın farklı olması temel doğruluk yaklaşımını değiştirmez. Type, property, value type ve içerik uyumu yine kontrol edilmelidir. Bir projede RDFa kullanılıyorsa test otomasyonu ve ekip hakimiyeti migration kararından daha önemli olabilir.

Neden Çoğu Projede JSON-LD Tercih Edilir?

JSON-LD'nin güçlü yanı, markup katmanını HTML sunumundan büyük ölçüde ayırabilmesidir. Bu yapı component refactor işlemlerinde structured data'nın yanlışlıkla silinmesi riskini azaltabilir. Ayrıca TypeScript modelinden veya backend DTO yapısından otomatik JSON-LD üretmek kolaydır. Snapshot, unit ve contract testleri de daha okunabilir hale gelir. Yine de doğru format seçiminin ötesinde, gerçek veriyi kullanan ve düzenli test edilen bir mimari oluşturmak daha değerlidir.

Mevcut Microdata Projesi JSON-LD'ye Taşınmalı mı?

Çalışan Microdata sistemini JSON-LD'ye taşımadan önce gerçek bir problem tanımlamak gerekir. Bakım maliyeti yükselmişse, şablon değişiklikleri sık sık markup bozuyorsa veya veri kaynağını merkezileştirmek istiyorsanız migration anlamlı olabilir. Buna karşılık mevcut işaretleme stabil, doğrulanmış ve otomatik testlerle korunuyorsa dönüşümün faydası sınırlı kalabilir. Migration sırasında bir süre iki formatın aynı entity'yi çelişkili verilerle üretmesi de ayrıca risk oluşturur. Bu nedenle geçiş planı duplicate schema testi içermelidir.

JSON-LD'nin Temel Yapısı

JSON-LD'yi güvenilir biçimde test edebilmek için temel yapı taşlarını anlamak gerekir. @context kullanılan vocabulary bağlamını, @type ise temsil edilen varlık türünü belirler. Property ve value alanları varlıkla ilgili özellikleri taşırken nested object ve array yapıları daha detaylı ilişkileri ifade eder. @id aynı entity'nin farklı yerlerde tutarlı biçimde referanslanmasını sağlayabilir. @graph ise tek sayfada birden fazla bağlantılı varlığı daha düzenli yönetmek için sık kullanılan bir yapıdır.

@context

@context, JSON-LD içinde kullanılan terimlerin hangi bağlamda yorumlanacağını belirtir. Schema.org tabanlı uygulamalarda çoğunlukla https://schema.org kullanılır. Bu değer, property adlarının ve type tanımlarının hangi vocabulary ile ilişkili olduğunu netleştirir. Otomasyon testlerinde @context değerini beklenen sabitlerden biri olarak kontrol etmek faydalıdır. Özellikle farklı generator sürümlerinin aynı projede kullanıldığı ortamlarda bu basit kontrol beklenmedik değişiklikleri yakalayabilir.

@type

@type, temsil edilen entity'nin Product, Article, Event veya başka bir Schema.org türü olduğunu belirtir. Yanlış type seçimi, property'ler teknik olarak okunabilse bile yanlış anlam kurulmasına yol açabilir. Google Search özelliği hedefleniyorsa seçilen type'ın güncel Google dokümantasyonunda desteklenip desteklenmediği ayrıca kontrol edilmelidir. Bir template için beklenen @type değerini automated test ile doğrulamak oldukça kolaydır. Böylece örneğin ürün sayfasında yanlışlıkla genel WebPage çıktısının tek başına kalması erken yakalanabilir.

Property

Property, entity hakkında belirli bir özelliği tanımlar. Product için name, image, offers ve benzeri alanlar bu yapının örnekleridir. Her property her type üzerinde aynı anlamı veya geçerliliği taşımaz. Schema generator geliştirirken izin verilen property setlerini type bazında modellemek hata oranını düşürür. Validator kontrolü de property kullanımındaki uyumsuzlukları görmek için sürecin parçası olmalıdır.

Value

Value, bir property'nin taşıdığı gerçek değerdir ve metin, sayı, URL, tarih veya başka bir nesne olabilir. Burada en sık görülen sorunlardan biri değerin doğru görünmesine rağmen yanlış veri tipinde gönderilmesidir. Özellikle fiyat, puanlama ve tarih alanlarında biçim kontrolü önemlidir. Uygulama katmanında type-safe modeller kullanmak bu riskin önemli bölümünü azaltır. Testlerde yalnızca property'nin varlığı değil, value'nun beklenen formatı da doğrulanmalıdır.

Nested Object

Nested object, bir property'nin başka bir yapılandırılmış entity içermesine imkan tanır. Örneğin Product içindeki offers alanı bir Offer nesnesi olarak modellenebilir. Bu yöntem gerçek dünya ilişkilerini daha anlamlı ifade etmeyi sağlar. Ancak nested yapı arttıkça eksik required property veya yanlış type kullanımı ihtimali de yükselir. Testlerin yalnızca üst seviyedeki Product nesnesini değil, iç içe geçmiş Offer ve benzeri nesneleri de kapsaması gerekir.

Array

Array, aynı property altında birden fazla değer veya nesne taşımak için kullanılabilir. Bir ürünün birden fazla görseli veya belirli modellerde birden fazla ilişkili öğesi bulunabilir. Array elemanlarının her birinin beklenen veri türünde olması gerekir. Otomatik testte yalnızca dizinin varlığını kontrol etmek yeterli değildir, boş dizi veya bozuk elemanlar da değerlendirilmelidir. Özellikle API dönüşleri değiştiğinde array tabanlı alanlarda regression görmek oldukça yaygındır.

@id

@id, bir entity'ye sayfa veya site kapsamında kararlı bir kimlik vermek için kullanılabilir. Bu kimlik sayesinde farklı JSON-LD düğümleri aynı Organization, Product veya başka bir entity'ye referans verebilir. Tutarlı @id kullanımı duplicate entity üretimini azaltmaya yardımcı olur. Buna karşılık yanlış veya değişken kimlikler ilişki grafiğini bozabilir. Testlerde beklenen referansların gerçekten mevcut node'lara bağlandığını kontrol etmek yararlıdır.

@graph

@graph, aynı sayfadaki birden fazla bağlantılı entity'yi tek JSON-LD yapısı içinde düzenlemek için kullanılabilir. Örneğin WebPage, Article, Organization ve BreadcrumbList düğümleri aynı graph içinde bulunabilir. Bu yaklaşım entity ilişkilerini daha açık hale getirebilir. Ancak her node'un doğru @type, benzersiz kimlik ve tutarlı referanslara sahip olması gerekir. Graph testlerinin duplicate node ve broken reference kontrollerini kapsaması bu yüzden önemlidir.

Schema.org ile Google Rich Results Aynı Şey Değildir

Structured data çalışmalarındaki temel kavramsal ayrımlardan biri Schema.org vocabulary ile Google Search feature desteğinin aynı sistem olmadığını bilmektir. Schema.org web üzerindeki varlıkları ifade etmek için çok geniş bir sözlük sunar. Google ise bu sözlüğün belirli bölümlerini kendi Search özellikleri için kullanır ve kendi teknik gereksinimlerini yayınlar. Dolayısıyla vocabulary içinde type bulunması, Rich Results Test'te desteklenen özel bir zengin sonuç oluşacağı anlamına gelmez. Bu ayrımı proje dokümantasyonuna açık biçimde yazmak, yanlış uygulama kararlarını ciddi ölçüde azaltır.

Schema.org Vocabulary

Schema.org vocabulary yalnızca Google Search için tasarlanmış dar bir rich result listesi değildir. Çok sayıda entity, property ve ilişkiyi kapsayan daha geniş bir anlamsal model sunar. Bir type Google tarafından zengin sonuç üretmek için kullanılmasa bile başka tüketiciler açısından anlamsal değer taşıyabilir. Bu yüzden “Google göstermiyor, o halde schema geçersiz” sonucu teknik olarak doğru değildir. Önce vocabulary geçerliliği, ardından hedeflenen tüketicinin desteği değerlendirilmelidir.

Google Search Feature

Google Search feature, Google'ın belirli structured data türlerini kullanarak sunduğu arama deneyimini ifade eder. Her özellik için gerekli alanlar, önerilen alanlar ve ek kurallar bulunabilir. Bu kurallar zaman içinde değişebilir veya özellik tamamen kaldırılabilir. Bu nedenle eski bir blog yazısına güvenmek yerine güncel Search Central dokümantasyonunu kontrol etmek gerekir. Support registry yaklaşımı bu değişiklikleri ekip içinde görünür hale getirir.

Schema.org'da Bulunan Her Type Google'da Rich Result Üretir mi?

Hayır, Schema.org içinde bulunan her type Google Search'te rich result üretmez. Bu yanlış varsayım özellikle eski teknik SEO rehberleri kopyalandığında sık görülür. Bir type'ın vocabulary içinde bulunması onun semantik olarak tanımlandığını gösterir, Google'ın özel arama görünümü sunduğunu değil. Rich result hedefleniyorsa Google'ın güncel destek dokümanları ayrıca kontrol edilmelidir. Uygulama başlamadan önce yapılacak bu küçük kontrol gereksiz geliştirme maliyetini önleyebilir.

Google Search Gallery Neden Ayrıca Kontrol Edilmelidir?

Google'ın desteklediği structured data özelliklerini takip etmek için güncel Search dokümantasyonu temel referanslardan biri olmalıdır. Burada hangi arama özelliklerinin desteklendiğini ve özellik bazında hangi teknik beklentilerin bulunduğunu görebilirsiniz. Schema.org Validator yalnızca bu Google özel ürün durumunu size tek başına anlatmaz. Proje başında ve önemli release'lerden önce destek listesi yeniden kontrol edilmelidir. Özellikle uzun süredir bakım görmeyen sitelerde bu kontrol eski markup yatırımlarını ortaya çıkarabilir.

Desteklenen Schema Türlerinin Zamanla Değişmesi

Google'ın desteklediği Search feature listesi sabit değildir. Bazı özellikler genişletilebilir, bazıları sınırlanabilir ve bazıları tamamen kaldırılabilir. Bu nedenle yıllar önce hazırlanmış bir schema spesifikasyonunu hiç değiştirmeden sürdürmek güvenilir bir yaklaşım değildir. Feature lifecycle takibi teknik SEO bakımının normal parçası olmalıdır. Registry kaydında son kontrol tarihi bulunması bu nedenle oldukça pratiktir.

2026'da Google Rich Result Desteğini Kontrol Etmek Neden Kritik?

2026 yılı, eski structured data rehberlerinin körü körüne uygulanmasının neden riskli olduğunu gösteren açık örnekler içeriyor. Google, yıllar içinde HowTo dahil çeşitli Search feature'ları kaldırdı ve 7 Mayıs 2026 itibarıyla FAQ rich result gösterimini de sona erdirdi. Bu durumda internette hâlâ dolaşan “FAQ schema ekleyin, arama sonucunda soru cevap alanı kazanın” türündeki eski öneriler güncel hedef olarak kabul edilmemelidir. Schema markup farklı anlamsal amaçlarla kullanılabilir, fakat Google Search zengin görünüm beklentisi güncel destek durumuna göre belirlenmelidir. Bu nedenle rich snippets ve schema markup teknik SEO optimizasyon hizmeti yürütürken feature yaşam döngüsünü izlemek zorunlu hale gelir.

FAQ Rich Result'ın Kaldırılması

FAQ structured data uzun süre SEO projelerinde yaygın olarak uygulandı. Önce görünürlüğü yalnızca belirli otoriter sağlık ve devlet siteleriyle sınırlandırılmıştı, ardından Google 2026 yılında özelliğin Search'te gösterimini sona erdirdi. Bu nedenle FAQPage type bulunması ile aktif FAQ rich result desteği aynı şey değildir. Mevcut projelerde FAQ markup kullanılıyorsa neden kullanıldığı yeniden değerlendirilmelidir. Yeni geliştirmelerde ise eski rich result vaadini hedef olarak yazmak doğru olmaz.

HowTo Rich Result'ın Kaldırılması

HowTo rich result desteği FAQ değişikliğinden daha önce Google Search sonuçlarından kaldırılmıştı. Buna rağmen eski eğitim içerikleri ve SEO kontrol listelerinde HowTo markup hâlâ zengin sonuç kazanma yöntemi olarak anlatılabiliyor. Bu durum, dokümantasyon güncelliğinin neden teknik test kadar önemli olduğunu gösterir. HowTo type semantik model açısından ayrı değerlendirilebilir, ancak Google Search feature beklentisi güncel destek durumuna göre kurulmalıdır. Ekipler yalnızca kodu değil, kodun hedeflediği özelliği de sürüm yaşam döngüsü içinde izlemelidir.

Eski Schema Rehberlerinin Yarattığı Risk

Eski bir rehber teknik olarak doğru JSON-LD örneği sunabilir fakat artık geçerli olmayan bir Google Search hedefini anlatıyor olabilir. Böyle bir örneği kopyalamak geliştirici açısından başarılı görünür, çünkü JSON parse edilir ve Schema.org vocabulary içinde type bulunabilir. SEO tarafında ise beklenen görünüm gerçekleşmediği için gereksiz hata araştırmaları başlar. Bu sorunun kök nedeni kod değil, güncelliğini kaybetmiş feature varsayımıdır. Her schema projesinde yayın tarihi ve güncel Google dokümanı birlikte kontrol edilmelidir.

Deprecated Search Feature Takibi

Deprecated veya kaldırılmış Search feature'ların takibi bir kişinin hafızasına bırakılmamalıdır. Basit bir registry içinde type, Google feature adı, durum, son doğrulama tarihi ve sorumlu ekip kaydedilebilir. Google dokümantasyon güncellemeleri belirli aralıklarla kontrol edilerek registry yenilenebilir. Böylece kaldırılan bir özelliğin aylarca yeni sayfalara eklenmesi engellenir. Büyük sitelerde bu takip deployment kalitesi kadar değerli bir teknik SEO kontrolüdür.

Schema.org Type ile Google Search Feature'ı Ayrı Takip Etmek

Bir registry satırında Schema.org type ile Google Search feature bilgisini ayrı sütunlarda tutmak çok kullanışlıdır. Örneğin type vocabulary içinde mevcut kalırken Google tarafından sunulan belirli arama deneyimi kaldırılmış olabilir. İki durumu tek “aktif veya pasif” alanında birleştirmek bu ayrımı görünmez hale getirir. Ayrıca farklı arama motorları veya veri tüketicileri için aynı markup başka amaçlarla kullanılabilir. Bu nedenle teknik model ile ürün desteğinin ayrı yaşam döngüleri olduğu kabul edilmelidir.

Structured Data Support Registry Nasıl Oluşturulur?

Structured Data Support Registry, sitenizde kullanılan schema type'larını ve bunların Google Search durumunu tek yerde takip eden basit fakat değerli bir yönetim tablosudur. Registry içinde type adı, Google desteği, durum, required property'ler, recommended property'ler, son kontrol tarihi ve owner bilgisi tutulabilir. Büyük ekiplerde bu kayıt, “bu markup neden var?” sorusunun cevabını aylar sonra bile bulmayı kolaylaştırır. Ayrıca deprecation değişiklikleri gerçekleştiğinde etkilenen template ve URL gruplarını daha hızlı belirleyebilirsiniz. Ben bu yaklaşımı schema governance kurmak isteyen ekipler için en düşük maliyetli başlangıç adımlarından biri olarak görüyorum.

Schema Type

Schema Type alanı Product, Article, Event veya kullanılan başka bir entity türünü açıkça kaydetmelidir. Projede aynı type birden fazla template üzerinde kullanılıyorsa template bilgisi de ilişkilendirilebilir. Böylece bir değişiklik geldiğinde hangi sayfa gruplarının inceleneceği hızlıca anlaşılır. Type adlarını serbest metin yerine kontrollü değerler olarak tutmak raporlama kalitesini artırır. Registry zamanla sitenin structured data envanterine dönüşür.

Google Search Desteği

Bu alan, type'ın veya ilgili işaretlemenin Google Search üzerinde hedeflenen özel bir feature desteği olup olmadığını belirtir. “Schema.org'da var” bilgisi buraya yazılmamalıdır, çünkü farklı bir kontrolü temsil eder. Destek varsa ilgili resmi doküman düzenli aralıklarla yeniden gözden geçirilmelidir. Destek yoksa ekibin markup kullanma amacı ayrıca açıklanabilir. Böylece rich result beklentisi yanlışlıkla oluşturulmaz.

Status

Status alanı feature yaşam döngüsünü ekip için anlaşılır hale getirir. Basit bir Active, Limited, Deprecated ve Removed modeli çoğu proje için yeterli olabilir. Bu alanın tanımları dokümante edilirse farklı ekipler aynı kavramları tutarlı kullanır. Durum değiştiğinde etkilenen release planı veya migration kaydı bağlanabilir. Böyle bir sistem yıllar içinde biriken eski markup sorunlarını azaltır.

Active

Active, hedeflenen Google Search feature'ın güncel olarak desteklendiğini belirtmek için kullanılabilir. Ancak active durumu tek başına her URL'nin eligible olduğu anlamına gelmez. Required property, kalite ve sayfa kuralları ayrıca yerine getirilmelidir. Registry yalnızca feature seviyesindeki desteği takip eder. URL seviyesindeki sağlık başka test ve dashboard metrikleriyle ölçülmelidir.

Limited

Limited durumu, feature'ın belirli ülke, site türü, sorgu veya başka koşullarda sınırlı kullanılabildiği durumları ifade etmek için yararlı olabilir. Ekip bu etiketi kullanıyorsa sınırlamanın ne olduğu not alanında açıkça belirtilmelidir. Aksi halde “limited” birkaç ay sonra anlamını kaybeder. Bölgesel sitelerde bu detay özellikle önemlidir. Feature'ın aktif olmasıyla her pazarda aynı erişime sahip olması aynı şey değildir.

Deprecated

Deprecated, özelliğin kaldırılma sürecinde olduğunu veya artık yeni yatırım yapılmaması gereken bir durumda bulunduğunu göstermek için kullanılabilir. Bu durum tespit edildiğinde yeni implementation talepleri durdurulabilir. Mevcut markup için migration veya kaldırma gerekip gerekmediği ayrıca değerlendirilmelidir. Search Console raporlarında yapılacak değişiklikler de planın parçası olabilir. Deprecated kaydına değişiklik tarihi eklemek sonraki incelemeleri kolaylaştırır.

Removed

Removed, hedeflenen Google Search feature'ın artık kullanılmadığını ifade eder. Bu durum schema type'ın Schema.org vocabulary içinden silindiği anlamına gelmek zorunda değildir. Ekip öncelikle markup'ın başka bir iş amacı olup olmadığını değerlendirmelidir. Yalnızca kaldırılmış rich result beklentisi için tutuluyorsa teknik borç olarak işaretlenebilir. Yeni geliştirmelerde aynı eski hedefin tekrar eklenmesi registry üzerinden engellenebilir.

Required Properties

Required Properties alanında Google'ın ilgili aktif feature için zorunlu tuttuğu property'ler sürüm mantığıyla takip edilmelidir. Bu listeyi kod içine sabit yazıp yıllarca unutmamak gerekir. Dokümantasyon değiştiğinde test rule set'i de güncellenmelidir. Required bir alanın eksikliği CI/CD aşamasında hard fail olarak değerlendirilebilir. Böylece production'a eligibility sorunu taşıma ihtimali azalır.

Recommended Properties

Recommended Properties, her zaman eligibility için zorunlu olmayan fakat sonuç kalitesini veya Google'ın içeriği anlamasını destekleyebilen alanlardır. Bu alanların eksikliğini required property ile aynı şiddette ele almak geliştirme akışını gereksiz yere durdurabilir. Bunun yerine warning veya kalite puanı şeklinde takip edilebilir. İş değeri yüksek alanlar ayrıca önceliklendirilebilir. Böylece teknik ekip tüm uyarıları aynı kategoride görmez.

Son Kontrol Tarihi

Son kontrol tarihi registry kaydının ne kadar güncel olduğunu anlamanın en basit yoludur. Structured data özellikleri değişebildiği için yıllar önce doğrulanmış kayıt güvenilir kabul edilmemelidir. Kritik schema türleri için periyodik review aralığı belirlenebilir. Google dokümantasyon güncellemesi geldiğinde tarih yeniden işlenebilir. Bu alan özellikle deprecation yönetiminde büyük kolaylık sağlar.

Owner

Owner alanı schema kararının kim tarafından takip edildiğini açık hale getirir. Bu kişi veya ekip SEO, development veya ortak bir teknik SEO sorumluluğu olabilir. Önemli olan sorun çıktığında kimsenin “bunu kim yönetiyor?” diye günlerce aramamasıdır. Owner, dokümantasyon değişikliklerini ve test kuralı güncellemelerini koordine eder. Büyük organizasyonlarda ortak ownership modeli de tanımlanabilir.

Google Rich Results Test Nedir?

Google Rich Results Test, bir URL veya kod parçasının Google'ın desteklediği zengin sonuç türleri açısından değerlendirilmesini sağlayan test aracıdır. Araç özellikle Google Rich Result eligibility kontrolünde önemlidir. Ancak Schema.org vocabulary içindeki tüm olası type'ları değerlendirmek amacıyla tasarlanmış genel bir validator değildir. Bu yüzden Google Rich Results Test ile yapılandırılmış veri doğrulama yapılırken aracın kapsamı doğru anlaşılmalıdır. En güvenli süreç, bu testi Schema.org doğrulaması ve production kontrolleriyle birlikte kullanmaktır.

URL Testi

URL testi gerçek bir sayfanın Google tarafından işlenebilen çıktısı üzerinde değerlendirme yapmanıza yardımcı olur. Bu yöntem özellikle production veya erişilebilir staging sayfalarında yararlıdır. Sayfanın yalnızca kaynak koduna bakmak yerine işlenmiş yapı içindeki structured data'nın algılanıp algılanmadığını görebilirsiniz. Dinamik oluşturulan markup için URL testi ayrıca önem kazanır. Ancak sonuç yine Search'te kesin gösterim garantisi olarak yorumlanmamalıdır.

Kod Testi

Kod testi henüz yayınlanmamış veya izole şekilde kontrol etmek istediğiniz structured data parçaları için kullanışlıdır. Geliştirme aşamasında JSON-LD örneğini hızlıca test edebilirsiniz. Bu yöntem URL erişimi veya indexability sorunlarından bağımsız biçimde markup kalitesine odaklanır. Yine de kod testinin staging render ve production sonucu yerine geçmediğini unutmamak gerekir. Kod doğru olsa bile template entegrasyonu sırasında veri kaybolabilir.

Googlebot Smartphone

Mobil tarama ve render perspektifi structured data testlerinde önemlidir. Sayfanın mobil sürümünde ana içerik veya JSON-LD farklı üretiliyorsa parity sorunu ortaya çıkabilir. Responsive tasarımın kendisi genellikle problem değildir, fakat cihaz bazlı template veya sunucu davranışı dikkat gerektirir. Test çıktısında Googlebot Smartphone perspektifini değerlendirmek bu yüzden yararlıdır. Mobilde kaybolan structured data üretim öncesi testlerle yakalanmalıdır.

Googlebot Desktop

Masaüstü görünümü de karşılaştırma ve parity kontrolleri açısından değer taşır. Özellikle legacy sitelerde desktop ve mobile için farklı HTML çıktıları üretiliyorsa iki tarafın schema yapısı ayrışabilir. Ana entity bilgileri cihaz değiştiğinde çelişmemelidir. Fiyat, stok, headline veya tarih gibi temel alanların aynı veri kaynağından üretilmesi tercih edilir. Mobile ve desktop diff testleri bu farkları otomatik biçimde görünür hale getirebilir.

Algılanan Structured Data Türleri

Test sonucunda algılanan structured data türlerine bakmak ilk teşhis adımlarından biridir. Beklediğiniz Product veya Article görünmüyorsa sorun syntax, render veya template koşullarından kaynaklanabilir. Beklenmedik ek türler görünüyorsa tema, eklenti veya üçüncü taraf script duplicate schema üretiyor olabilir. Type listesi bu nedenle yalnızca başarı göstergesi değildir. Aynı zamanda sistemin gerçekte hangi markup'ı yayınladığını gösteren bir envanter sinyalidir.

Rich Result Önizlemesi

Önizleme özelliği desteklenen bazı sonuç türlerinde verinin potansiyel sunumunu anlamaya yardımcı olabilir. Bu görünüm tasarım garantisi veya gerçek SERP kopyası olarak değerlendirilmemelidir. Google arama arayüzünü ve sunum biçimlerini zaman içinde değiştirebilir. Önizleme daha çok verinin doğru alanlara bağlanıp bağlanmadığını anlamak için kullanılmalıdır. Son karar gerçek production izleme ve Search Console performans verileriyle desteklenmelidir.

Rich Results Test Nasıl Kullanılır?

Rich Results Test kullanırken rastgele tek bir URL seçmek yerine template bazlı bir kontrol yaklaşımı benimsemek daha sağlıklıdır. Önce test edilecek sayfanın hangi schema türünü taşıması gerektiğini ve hangi alanların required olduğunu belirleyin. Testi çalıştırdıktan sonra algılanan type'ları, critical error'ları, uyarıları ve mümkünse önizlemeyi inceleyin. Sorun varsa önce veri kaynağını veya generator mantığını düzeltin, ardından yeniden test edin. Bu döngü schema markup hataları nasıl tespit edilir ve düzeltilir sorusuna pratikte en güvenilir cevaplardan biridir.

Test Edilecek URL'yi Seçmek

Test URL'si seçerken yalnızca en sorunsuz örneği kullanmak gerçek kaliteyi göstermez. Ürün projelerinde normal ürün, indirimli ürün, stoksuz ürün ve varyant gibi farklı veri durumları örneklenmelidir. Makale sitelerinde yazar, güncelleme tarihi ve görsel varyasyonları dikkate alınabilir. Risk bazlı örnekleme edge case sorunlarını erken yakalar. Büyük sitelerde her template için minimum fixture seti oluşturmak bu süreci standart hale getirir.

Testi Çalıştırmak

Testi çalıştırdıktan sonra yalnızca yeşil genel sonuca bakıp sekmeyi kapatmayın. Algılanan entity sayısı, type'lar ve ilgili uyarılar tek tek gözden geçirilmelidir. Beklenmeyen ikinci Product node'u gibi sorunlar genel sonuç olumlu görünse bile veri çelişkisi yaratabilir. Test çıktısı release kaydına veya QA notuna eklenebilir. Böylece aynı template sonraki sürümlerde karşılaştırılabilir.

Algılanan Type'ları İncelemek

Beklenen type ile gerçekten algılanan type'ın eşleşmesi temel kontroldür. Ürün template'inde Product yerine yalnızca Organization görülüyorsa schema generator koşulu çalışmamış olabilir. Birden fazla Product görülmesi ise duplicate kaynağa işaret edebilir. Bu kaynak tema, uygulama, eklenti veya üçüncü taraf script olabilir. Type incelemesi bu nedenle hata ayıklama sürecini önemli ölçüde hızlandırır.

Critical Errors Kontrolü

Critical error veya zorunlu alan problemi eligibility açısından yüksek öncelikli kabul edilmelidir. Bu sorun production'a taşınmadan önce kök neden seviyesinde düzeltilmelidir. Eksik alanı sahte veya sabit veriyle doldurmak çözüm değildir. Doğru yaklaşım gerçek veri kaynağını bulmak ve generator ile güvenli biçimde bağlamaktır. Aynı kontrol CI/CD testine eklenerek tekrar oluşması engellenebilir.

Non-Critical Warnings Kontrolü

Warning'ler her zaman release'i bloklamak zorunda değildir. Bununla birlikte sürekli görmezden gelinen uyarılar zaman içinde veri kalitesini düşürebilir. Hangi recommended alanların iş değeri taşıdığı SEO ve product ekipleriyle birlikte belirlenmelidir. Kritik olmayan sorunlar backlog içinde önceliklendirilebilir. Böylece geliştirme akışı gereksiz şekilde durdurulmadan schema kalitesi iyileştirilir.

Preview Kontrolü

Preview mevcutsa temel değerlerin beklendiği gibi taşındığını gözle kontrol etmek yararlıdır. Özellikle isim, fiyat veya başka kullanıcıya dönük bilgilerin yanlış kaynaktan gelmesi burada fark edilebilir. Ancak preview bir acceptance test'in tek kanıtı olmamalıdır. Aynı bilgi DOM ve JSON-LD arasında otomatik olarak karşılaştırılabilir. Bu yaklaşım görsel kontrole bağımlılığı azaltır.

Düzeltip Yeniden Test Etmek

Schema hatasını düzelttikten sonra yalnızca ilgili kod satırını kontrol etmek yeterli değildir. Değişiklik başka entity veya template'leri etkileyebilir. Aynı fixture setini yeniden çalıştırmak regression riskini azaltır. Staging ve production çıktıları da ayrı doğrulanmalıdır. İyi bir schema geliştirme döngüsü test, düzeltme, yeniden test ve izleme adımlarını birlikte içerir.

Rich Results Test Sonuçları Nasıl Okunur?

Rich Results Test sonuçlarını okurken etiketin arkasındaki teknik anlamı bilmek gerekir. Valid sonucu markup'ın ilgili kontrol için uygun olduğunu gösterirken warning bulunması her zaman eligibility kaybı anlamına gelmez. Invalid sonuç required property veya başka kritik bir problem içerebilir. Desteklenmeyen structured data ise Schema.org açısından geçersiz olmak zorunda değildir. Test sonucunu production Search görünümüyle aynı şey saymamak en önemli yorumlama kuralıdır.

Valid

Valid sonucu test edilen structured data'nın ilgili Google rich result kurallarında kritik hata taşımadığını gösterebilir. Bu olumlu bir teknik sinyaldir. Ancak URL'nin indeksleneceği veya rich result olarak gösterileceği sonucu buradan çıkarılmamalıdır. Indexability ve production durumları ayrıca kontrol edilmelidir. Valid, sürecin önemli fakat tek başına yeterli olmayan bir aşamasıdır.

Valid With Warnings

Valid with warnings benzeri durumlar, zorunlu gereksinimler karşılanırken bazı önerilen alanların eksik veya geliştirilebilir olduğunu gösterebilir. Warning listesinin iş değerine göre incelenmesi gerekir. Tüm warning'leri release blocker yapmak ekiplerin gereksiz iş yükü yaşamasına neden olabilir. Buna karşılık yıllarca biriken uyarıları tamamen görmezden gelmek de doğru değildir. Dashboard üzerinde warning trendi izlemek dengeli bir çözümdür.

Invalid

Invalid sonucu kritik structured data probleminin bulunduğuna işaret eder. Eksik required property, beklenmeyen veri türü veya başka uygunluk sorunları bunun nedeni olabilir. Hata yalnızca örnek URL üzerinde düzeltilmemeli, sorunun template veya veri modelinden kaynaklanıp kaynaklanmadığı araştırılmalıdır. Bir template hatası binlerce URL'yi etkileyebilir. Bu nedenle etkilenen URL sayısını incident kaydına eklemek yararlıdır.

Not Eligible for Rich Results

Bir yapı Schema.org açısından anlamlı olsa bile Google'ın ilgili zengin sonuç özelliği için uygun olmayabilir. Bunun nedeni kullanılan type'ın desteklenmemesi veya Google'ın feature kurallarının karşılanmaması olabilir. İlk adım güncel Google destek dokümanını kontrol etmektir. Ardından required property ve içerik gereksinimleri incelenmelidir. Kodun parse edilmesi eligibility sorununu otomatik olarak çözmez.

Unsupported Structured Data

Unsupported ifadesi gördüğünüzde “bu schema kesinlikle yanlıştır” sonucuna hızlıca ulaşmamak gerekir. Google Rich Results Test'in odağı Google'ın desteklediği rich result türleridir. Schema.org vocabulary ise bundan daha geniştir. Bu nedenle genel semantic validation ayrıca Schema Markup Validator üzerinden yapılabilir. Aracın kapsamını bilmek yanlış hata raporlarını önler.

Test Sonucunu Production Gerçekliğiyle Karıştırmamak

Bir test aracı belirli anda belirli kurallara göre değerlendirme yapar. Production ortamında ise crawl, render, canonical, noindex, HTTP durum kodu ve gerçek veri akışı gibi ek değişkenler bulunur. Deployment sırasında schema script'i kaybolabilir veya CDN eski HTML sunabilir. Bu nedenle post-deploy smoke test yapılmalıdır. Rich Results Test başarılı olsa bile Search Console monitoring süreci devam etmelidir.

Error ile Warning Arasındaki Fark

Error ve warning ayrımı structured data release politikasının temelini oluşturur. Kritik error genellikle uygunluğu doğrudan etkileyen bir sorun olduğu için hızlı çözüm ister. Warning ise çoğu senaryoda önerilen fakat zorunlu olmayan bir alanla ilişkilidir. Her iki durumu aynı şekilde ele almak ekiplerin önceliklendirme yeteneğini zayıflatır. En iyi yaklaşım, blocker kurallarını dokümante edip CI/CD davranışını buna göre ayarlamaktır.

Critical Error

Critical error, markup'ın hedeflenen rich result için geçerliliğini ciddi biçimde etkileyen problemdir. Bu tür sorunlar release öncesinde çözülmelidir. Hata doğrudan schema generator kodundan, eksik API alanından veya yanlış template koşulundan kaynaklanabilir. Root cause bulunmadan yalnızca çıktıyı yamamak tekrar eden hatalara yol açar. Kalıcı çözüm test kuralıyla birlikte uygulanmalıdır.

Missing Required Property

Missing required property, ilgili Google feature için zorunlu kabul edilen bir alanın bulunmadığını gösterir. Bu durumda önce property'nin hangi veri kaynağından gelmesi gerektiği belirlenmelidir. Eksik gerçek veriyi uydurmak structured data kalitesini daha da kötüleştirir. Veri yoksa business rule gözden geçirilmelidir. Required alan testi fixture ve unit test seviyesinde otomatikleştirilebilir.

Invalid Property Type

Property var olsa bile yanlış veri türü gönderildiğinde validation sorunu oluşabilir. Tarih yerine serbest metin, URL yerine uygunsuz değer veya nested object yerine yanlış primitive göndermek buna örnek olabilir. Type-safe model kullanmak bu tür hataları erken yakalamaya yardımcı olur. Runtime validation da API sınırlarında ek güvence sağlar. Test yalnızca property'nin mevcut olup olmadığını kontrol etmemelidir.

Warning

Warning, çoğu zaman markup'ın tamamen geçersiz olduğu anlamına gelmez. Önerilen bir property eksik olabilir veya kalite açısından iyileştirme fırsatı bulunabilir. Warning'in etkisi ilgili feature dokümanına göre değerlendirilmelidir. Ekip kendi business value puanını da ekleyebilir. Böylece önemli uyarılar öncelik alırken düşük etkili olanlar planlı şekilde yönetilir.

Missing Recommended Property

Recommended property eksikliği, gerekli alan eksikliğinden farklı şekilde ele alınmalıdır. Google belirli alanları sonuç kalitesini artırmak amacıyla önerebilir. Gerçek veri mevcutsa bu alanların eklenmesi çoğu zaman iyi bir yatırımdır. Veri yoksa yalnızca warning'i kaldırmak için sahte bilgi üretilmemelidir. Kalite ile doğruluk arasında her zaman doğruluk öncelikli olmalıdır.

Release'i Bloklayan ve Bloklamayan Sorunları Ayırmak

CI/CD pipeline içinde schema testlerinin gerçekten faydalı olması için hangi hataların merge veya deployment işlemini durduracağı açıkça tanımlanmalıdır. JSON parse problemi ve required property kaybı genellikle güçlü blocker adaylarıdır. Recommended alan uyarıları ise çoğu projede warning olarak raporlanabilir. Bu politika template riskine göre farklılaştırılabilir. Önemli olan kararın otomatik, görünür ve ekipçe anlaşılır olmasıdır.

Required Property Nedir?

Required property, Google'ın belirli bir structured data özelliği için zorunlu gördüğü alandır. Bu alanın eksikliği rich result eligibility üzerinde doğrudan etki yaratabilir. Required listesi Schema.org'un tüm genel olanaklarıyla karıştırılmamalıdır, çünkü Google kendi Search feature gereksinimlerini tanımlar. Ayrıca bu gereksinimler zaman içinde değişebileceği için güncel dokümantasyon düzenli kontrol edilmelidir. Kritik template'lerde required property coverage oranını yüzde yüz hedeflemek güçlü bir kalite standardıdır.

Rich Result Eligibility İçin Zorunlu Alan

Bir property required olarak belirtilmişse schema generator bu alanı güvenilir veri kaynağından üretmelidir. Alanın bazen boş gelmesi mümkünse business rule baştan düşünülmelidir. Test fixture'larında null, empty string ve eksik property senaryoları bulunmalıdır. Böylece gerçek kullanıcı verisiyle karşılaşıldığında beklenmedik production hataları azalır. Required alanlar yalnızca manuel validator kontrolüne bırakılmamalıdır.

Type'a Göre Required Property

Required property listesi schema type ve hedeflenen Google feature'a göre değişir. Product için önemli olan alanlar Article ile aynı değildir. Bu nedenle tek bir global “schema required fields” listesi kullanmak hatalı bir tasarımdır. Rule engine type bazında çalışmalıdır. Registry ve otomatik testler bu ayrımı aynı kaynaktan kullanırsa bakım kolaylaşır.

Missing Required Property

Eksik required property tespit edildiğinde etkilenen URL'nin tekil mi yoksa template seviyesinde mi olduğu araştırılmalıdır. Tek bir ürün veri kaynağında eksik alan bulunabilir. Diğer durumda generator değişikliği tüm ürün sayfalarını etkilemiş olabilir. URL sampling ve template aggregation bu ayrımı ortaya çıkarır. Sorunun kapsamı bilindiğinde release veya rollback kararı daha sağlıklı verilir.

CI/CD'de Hard Fail Olarak Kullanmak

Required property testlerinin CI/CD içinde hard fail olması kritik regresyonların production'a çıkmasını önleyebilir. Pull request sırasında örnek fixture'lar üzerinden generator çalıştırılır ve gerekli alanlar kontrol edilir. Bir alan kaybolursa test başarısız olur. Böylece sorun Search Console raporunda günler sonra fark edilmez. Bu yaklaşım structured data'yı gerçek yazılım kalitesi sürecinin parçası haline getirir.

Recommended Property Nedir?

Recommended property, Google'ın belirli bir yapılandırılmış veri özelliğinde kullanılmasını önerdiği fakat her durumda zorunlu tutmadığı alandır. Bu alanlar daha zengin veya daha doğru bilgi sağlamaya yardımcı olabilir. Bir warning gördüğünüzde önce hangi recommended property'nin eksik olduğunu ve gerçek verinin sistemde bulunup bulunmadığını inceleyin. Veri varsa generator'a eklemek mantıklı olabilir. Veri yoksa yalnızca test ekranını temizlemek için bilgi uydurulmamalıdır.

Rich Result Kalitesini Artıran Alan

Recommended property'ler çoğu zaman entity hakkında ek bağlam sağlar. Ürün, makale veya etkinlik verisinin daha eksiksiz ifade edilmesine yardımcı olabilir. Bununla birlikte her recommended alan aynı iş değerine sahip değildir. E-ticaret projesinde kullanıcı kararını etkileyen alanlar daha yüksek öncelik alabilir. SEO ve product ekipleri bu önceliği birlikte belirlemelidir.

Eligibility İçin Her Zaman Zorunlu Olmaması

Recommended property eksikliğinin her zaman eligibility kaybına yol açmadığını bilmek önemlidir. Bu nedenle warning ile error kavramlarını aynı kategoride yönetmek doğru olmaz. Ekibin release politikasında bu ayrım açıkça belirtilmelidir. Aksi halde küçük uyarılar nedeniyle gereksiz deployment gecikmeleri yaşanabilir. Öncelik her zaman gerçek ve doğru veri sunmak olmalıdır.

Warning Olarak Yönetmek

Recommended alan sorunları dashboard üzerinde warning kategorisinde izlenebilir. Warning oranı zaman içinde yükseliyorsa schema veri kalitesinde sistematik bir bozulma olabilir. Bu trend doğrudan release'i durdurmasa bile bakım sprintine girdi sağlayabilir. Böylece ekip uyarıları tamamen görmezden gelmez. Aynı zamanda kritik hatalarla aynı operasyonel seviyeye taşımaz.

Business Value'ya Göre Önceliklendirmek

Her recommended property için geliştirme maliyeti ve sağlayacağı değer farklı olabilir. Gerçek ürün verisi zaten API'de mevcutsa ekleme maliyeti oldukça düşük olabilir. Başka bir alan yeni veri toplama süreci gerektiriyorsa öncelik farklı değerlendirilir. Bu nedenle schema backlog'u yalnızca validator listesinden üretilmemelidir. İş değeri, teknik maliyet ve arama görünürlüğü birlikte düşünülmelidir.

Schema Markup Validator Nedir?

Schema Markup Validator, structured data'nın Schema.org vocabulary açısından incelenmesinde kullanılan önemli bir doğrulama aracıdır. Google Rich Results Test'ten farklı olarak odağı Google'ın belirli rich result listesiyle sınırlı değildir. JSON-LD, Microdata ve RDFa gibi farklı biçimlerdeki işaretlemeleri incelemek için kullanılabilir. Type, property ve value type ilişkilerini kontrol etmek genel semantic kalite açısından değerlidir. Bu yüzden kapsamlı bir test sürecinde iki aracın birbirinin alternatifi değil tamamlayıcısı olduğunu düşünmek gerekir.

Schema.org Vocabulary Doğrulaması

Vocabulary doğrulaması kullanılan type ve property ilişkilerinin Schema.org tanımlarına uygunluğunu anlamaya yardımcı olur. Burada Google'ın özel Search feature kararlarından bağımsız bir katman incelenir. Bir markup Google tarafından rich result üretmese bile semantic olarak anlamlı olabilir. Bu ayrım özellikle custom veya geniş entity modellerinde önemlidir. Test raporunda “Schema.org valid” ve “Google eligible” ayrı sonuçlar olarak tutulmalıdır.

JSON-LD

JSON-LD çıktısı validator üzerinden incelenerek type ve property yapısı kontrol edilebilir. Syntax problemi varsa parser seviyesi hata ayrıca görülmelidir. Ancak syntax validation ile vocabulary validation aynı kontrol değildir. Bir JSON dosyası parse edilebilirken semantic model hatalı olabilir. Bu nedenle test pipeline iki kontrolü ayrı aşamalar halinde çalıştırmalıdır.

Microdata

Microdata HTML içindeki attribute ilişkilerine bağlı olduğu için DOM değişikliklerinden etkilenebilir. Validator kontrolü markup'ın gerçek template çıktısı üzerinde yapılmalıdır. Yalnızca kod parçası değil, mümkünse render edilen sayfa değerlendirilmelidir. Refactor sonrasında attribute kaybı regression test ile yakalanabilir. Çalışan Microdata sistemlerinde bu kontrol özellikle değerlidir.

RDFa

RDFa için de type ve property ilişkileri genel vocabulary doğrulamasının parçasıdır. Formatın farklı olması test hedeflerini değiştirmez. Parser, semantic model ve gerçek içerik uyumu yine ayrı kontrollerdir. Legacy sistemlerde RDFa bulunması doğrudan migration zorunluluğu yaratmaz. Önce mevcut sağlık ve bakım maliyeti ölçülmelidir.

Property Kontrolü

Property kontrolünde alanın gerçekten ilgili type için anlamlı olup olmadığı değerlendirilir. Yanlış entity altında doğru isimli property kullanmak beklenmedik sonuçlar doğurabilir. Bu tür hatalar özellikle copy-paste JSON-LD uygulamalarında görülür. Type-safe generator ve validator kombinasyonu riski azaltır. Property listesi zaman içinde schema modelinin doğal bir test sözleşmesine dönüşebilir.

Type Kontrolü

Type kontrolü sayfanın temsil ettiği gerçek entity ile kullanılan @type değerinin uyuşmasını gerektirir. Her sayfaya aynı generic schema'yı eklemek bu açıdan zayıf bir yaklaşımdır. Product sayfası, Article sayfası ve Event sayfası farklı veri sözleşmelerine sahip olmalıdır. Route bazlı schema üretimi bu nedenle önemlidir. Test fixture'ları her route ailesini ayrı doğrulamalıdır.

Value Type Kontrolü

Property doğru olsa bile value type yanlışsa semantic hata oluşabilir. Tarih, sayı, URL ve nested object alanlarında bu sorun sık görülür. API'nin veri formatı değiştiğinde schema generator fark edilmeden yanlış değer üretebilir. Runtime validation ve unit test bu değişiklikleri erkenden yakalar. Structured data testi bu nedenle sadece SEO aracında yapılan manuel işlem olmamalıdır.

Rich Results Test ile Schema Markup Validator Arasındaki Fark

İki araç aynı soruya cevap vermez. Rich Results Test, Google'ın desteklediği zengin sonuç özelliklerine uygunluk açısından önemlidir. Schema Markup Validator ise daha geniş Schema.org vocabulary uyumluluğuna bakmanıza yardımcı olur. Yalnızca birini kullanmak test kapsamınızda boşluk bırakabilir. En iyi yaklaşım önce genel semantic doğruluğu, ardından Google'a özel eligibility şartlarını doğrulamaktır.

Google Rich Result Eligibility

Google Rich Result eligibility kontrolü belirli Search feature'ın şartlarını hedefler. Required property listesi ve Google'a özel kullanım kuralları burada önem kazanır. Bu nedenle Rich Results Test bir Google Search feature kontrolü olarak düşünülmelidir. Genel Schema.org doğrulamasının yerine geçmez. Pipeline raporunda bu aşama ayrı bir test sonucu üretmelidir.

Genel Schema.org Uyumluluğu

Genel Schema.org uyumluluğu entity modelinin vocabulary açısından doğru olup olmadığını değerlendirir. Google'ın desteklemediği bir type burada yine geçerli olabilir. Bu durum iki aracın neden farklı sonuçlar verebildiğini açıklar. Bir araçta desteklenmeyen yapı diğerinde semantic olarak doğru görünebilir. Sonucu yorumlarken aracın amacını bilmek gerekir.

Google'a Özel Kurallar

Google belirli Search feature'lar için Schema.org vocabulary üzerinde kendi uygulama kurallarını tanımlayabilir. Required ve recommended property ayrımı bu bağlamda değerlendirilir. Ayrıca sayfa içeriği ve kalite politikaları gibi teknik kodun dışına taşan şartlar bulunabilir. Bu kuralların kaynağı güncel Search Central dokümantasyonu olmalıdır. Eski üçüncü taraf rehberleri tek kaynak olarak kullanmak risklidir.

Daha Geniş Vocabulary Kontrolü

Schema Markup Validator daha geniş vocabulary kontrolünde yararlıdır. Bir sitede Google rich result hedeflemeyen Organization ilişkileri veya başka entity modelleri bulunabilir. Bu yapıların semantic doğruluğu yine önem taşır. Google'a özel araç bu kapsamı bütünüyle değerlendirmek için tasarlanmamıştır. Bu nedenle genel validator test zincirinde ayrı bir rol oynar.

Neden İki Araç Birlikte Kullanılmalı?

İki araç birlikte kullanıldığında validation ile eligibility ayrımı görünür hale gelir. Önce parse ve vocabulary hatalarını temizleyebilir, ardından Google Search feature kurallarına geçebilirsiniz. Bu sıra hata ayıklamayı kolaylaştırır. Bir sorun yalnızca Google'a özel gereksinimdeyse generator'ın temel semantic modelini gereksiz yere yeniden yazmazsınız. Sonuç olarak daha hızlı ve anlaşılır bir test süreci elde edilir.

URL Inspection Tool Yapılandırılmış Veri Testinde Nerede Kullanılır?

URL Inspection Tool, Rich Results Test'ten sonraki production doğrulamasında önemli rol oynar. Çünkü burada Google'ın URL'yi nasıl gördüğü, crawl ve indexability durumu gibi daha geniş teknik SEO sinyallerini değerlendirebilirsiniz. JavaScript sonrası rendered HTML üzerinde structured data'nın bulunup bulunmadığını kontrol etmek de kritik olabilir. Schema kodu kusursuz olsa bile sayfa noindex ise arama görünürlüğü hedefi gerçekleşmez. Bu nedenle yapılandırılmış veri ve teknik SEO danışmanlığı yakınımda gibi hizmet arayışlarında yalnızca schema kodu değil, crawl ve indeksleme katmanının da incelenmesi gerekir.

Google'ın Gördüğü Canlı Sayfa

Production testinde geliştiricinin tarayıcıda gördüğü HTML ile Google'ın eriştiği çıktı aynı varsayılmamalıdır. CDN, authentication, bot davranışı veya JavaScript sorunları farklı sonuç üretebilir. URL Inspection canlı sayfanın Google perspektifini anlamaya yardımcı olur. Schema bulunmuyorsa kaynak ile rendered output karşılaştırılmalıdır. Bu kontrol özellikle client-side injection kullanan projelerde değerlidir.

Crawl Durumu

Google sayfayı düzgün tarayamıyorsa structured data kalitesi tek başına hedeflenen sonucu sağlamaz. HTTP hataları, robots kısıtları veya geçici erişim problemleri markup'ın işlenmesini etkileyebilir. Crawl durumunu structured data testinden ayrı düşünmemek gerekir. Production smoke test içinde HTTP status ve erişilebilirlik kontrolü bulunmalıdır. Böylece schema sorunu gibi görünen altyapı problemleri daha hızlı ayrıştırılır.

Indexability

Indexability, sayfanın arama sonucunda yer alma potansiyeli açısından temel koşullardan biridir. noindex taşıyan bir URL'de kusursuz Product schema bulunması zengin sonuç hedefini gerçekleştirmez. Canonical tercihi de Google'ın hangi URL'yi esas alacağını etkileyebilir. Bu nedenle schema dashboard'una indexability sinyali eklemek yararlıdır. Teknik SEO kontrolleri birlikte düşünüldüğünde yanlış teşhis oranı azalır.

Rendered HTML

Rendered HTML, JavaScript çalıştıktan sonra sayfanın oluşan DOM durumunu anlamak için önemlidir. JSON-LD client-side olarak ekleniyorsa kaynak HTML'de bulunmayabilir. Ancak script hatası veya hydration problemi structured data'nın render aşamasında kaybolmasına neden olabilir. Staging testleri bu senaryoları yakalamalıdır. Production URL Inspection ise gerçek dağıtım sonrası ek doğrulama sağlar.

JavaScript Sonrası Structured Data

Google JavaScript ile oluşturulan structured data'yı işleyebilir, fakat uygulamanın güvenilir çalışması yine geliştiricinin sorumluluğundadır. Özellikle ürün markup'ında mümkün olduğunda ilk HTML içinde veri sunmak daha sağlam bir uygulama olabilir. Client-side API çağrısı gecikiyor veya hata veriyorsa schema hiç oluşmayabilir. Bu yüzden source ve rendered HTML karşılaştırılmalıdır. JavaScript tabanlı markup için hata senaryosu testleri mutlaka yazılmalıdır.

Rich Results Test'ten Sonraki Production Kontrolü

Rich Results Test başarılı olduktan sonra production deployment tamamlandığında yeniden kontrol yapılmalıdır. Build sırasında environment variable, cache veya template minification değişiklikleri çıktıyı etkileyebilir. URL Inspection ile erişilebilirlik, render ve indeksleme durumu birlikte değerlendirilir. Ardından Search Console üzerinden trend izleme başlar. Böylece test süreci tek bir validator ekranında sona ermez.

Yapılandırılmış Veri Testinin Doğru Sırası

Sağlam bir structured data test sırası sorunu mümkün olan en erken aşamada yakalamayı hedefler. Önce local JSON parser ile syntax kontrol edilir, ardından Schema.org validation yapılır. Daha sonra Google Rich Results Test üzerinden hedeflenen Search feature uygunluğu değerlendirilir. Staging render ve production deployment sonrasında URL Inspection devreye girer. Süreç Search Console monitoring ile devam ederek Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri yaklaşımını sürekli kalite modeline dönüştürür.

1 — Local JSON Test

Local JSON test en hızlı ve ucuz kontroldür. Generator çıktısı standart parser ile parse edilmeli ve syntax problemi varsa build erken aşamada durdurulmalıdır. Bu test için Google servisine erişmek gerekmez. Unit test içinde yüzlerce fixture saniyeler içinde çalıştırılabilir. Böylece basit virgül veya escape hataları development aşamasında yakalanır.

2 — Schema.org Validation

Syntax temizlendikten sonra vocabulary doğrulamasına geçilir. Type, property ve value ilişkileri burada değerlendirilir. Bu aşama Google Search hedefinden bağımsız semantic kalite sağlar. Validation sonucu mümkünse otomatik veya düzenli QA kontrolüne dönüştürülmelidir. Tek seferlik manuel işlem olarak bırakıldığında regression riski devam eder.

3 — Rich Results Test

Üçüncü aşamada Google'ın güncel feature desteği ve eligibility şartları kontrol edilir. Required property hataları burada yüksek önceliklidir. Unsupported type görülürse önce Google'ın ilgili feature'ı hâlâ destekleyip desteklemediği doğrulanmalıdır. Eski dokümanlara güvenmek yerine güncel Search Central kaynağı kullanılmalıdır. Bu test semantic validation'ın yerine değil üzerine eklenir.

4 — Staging Render Test

Staging render testi template'in gerçek uygulama ortamında beklenen JSON-LD'yi oluşturduğunu doğrular. Server ve client rendering farkları bu aşamada ortaya çıkabilir. Route bazlı fixture'lar kullanılarak farklı veri durumları denenmelidir. Mobil ve masaüstü parity kontrolü de burada yapılabilir. Staging yalnızca görsel QA için değil structured data QA için de kullanılmalıdır.

5 — Production Deploy

Production deploy, testlerin sona erdiği değil gerçek ortam kontrollerinin başladığı aşamadır. Cache, CDN, gerçek API verisi ve deployment konfigürasyonu staging'den farklı davranabilir. Bu yüzden kritik URL seti için otomatik smoke test çalıştırılmalıdır. Beklenen @type ve required alanlar yeniden kontrol edilir. Hata bulunursa hızlı rollback veya fix mekanizması bulunmalıdır.

6 — URL Inspection

URL Inspection ile Google'ın canlı sayfaya erişimi ve render durumu kontrol edilir. noindex, canonical veya crawl problemi varsa structured data başarısı tek başına yeterli olmaz. Kritik template değişikliklerinde birkaç temsilci URL üzerinde bu kontrol yapılmalıdır. JavaScript sonrası JSON-LD özellikle incelenmelidir. Böylece üretim gerçekliği test zincirine eklenir.

7 — Search Console Monitoring

Search Console monitoring uzun vadeli sağlık sinyallerini sağlar. Geçerli ve geçersiz öğelerdeki ani değişimler regression alarmı olarak değerlendirilebilir. Search appearance verileri de uygun olduğu durumlarda performans takibine yardımcı olur. Fix validation süreci production düzeltmelerinin ardından kullanılabilir. Structured data operasyonu bu aşamada sürekli gözleme dönüşür.

En Sık Görülen JSON-LD Syntax Hataları

JSON-LD sorunlarının önemli bölümü semantic kurallara geçmeden önce basit JSON syntax hatalarından kaynaklanır. Eksik veya fazla virgül, yanlış tırnak, kapanmamış parantez ve hatalı escape karakteri parser'ın tüm script'i okuyamamasına neden olabilir. Bu hataların manuel testte bulunmasını beklemek verimsizdir. Standart JSON parser testini build aşamasına eklemek daha güvenlidir. Özellikle CMS'den gelen serbest metin JSON içine doğrudan yerleştiriliyorsa escaping kuralları dikkatle yönetilmelidir.

Eksik Virgül

Eksik virgül iki property arasındaki JSON yapısını bozar. Hata küçük görünse de script'in tamamı parse edilemeyebilir. Elle oluşturulan JSON-LD bloklarında sık rastlanır. Programatik serialization kullanmak bu riski önemli ölçüde azaltır. JSON metnini string birleştirmeyle üretmek yerine güvenilir serializer tercih edilmelidir.

Fazla Virgül

Fazla virgül özellikle elle düzenlenen object ve array sonlarında görülebilir. Bazı JavaScript bağlamları bunu tolere etse bile standart JSON açısından sorun oluşabilir. Structured data çıktısı gerçek JSON kurallarına göre üretilmelidir. Parser testi bu hatayı hemen yakalar. Generator testinde gerçek serialize edilmiş çıktı kullanılmalıdır.

Eksik Süslü Parantez

Nested object sayısı arttıkça kapanış parantezlerini elle takip etmek zorlaşır. Eksik süslü parantez tüm JSON-LD yapısını bozabilir. IDE syntax highlighting yardımcı olsa da otomatik parser testinin yerini tutmaz. Nesneyi kod objesi olarak oluşturup serializer ile JSON'a çevirmek daha güvenlidir. Özellikle büyük @graph yapılarında bu yöntem tercih edilmelidir.

Yanlış Tırnak

JSON standart çift tırnak kullanımına dayanır. Akıllı tırnak karakterleri veya HTML editörünün dönüştürdüğü karakterler parser hatasına yol açabilir. CMS üzerinden kopyalanan metinlerde bu sorun görülebilir. Kullanıcı girdisini doğrudan JSON metnine eklemek yerine serializer kullanmak güvenli yaklaşımdır. Test fixture'larına özel karakterli içerik eklemek de faydalıdır.

Invalid Escape Sequence

Backslash içeren metinler yanlış escape edildiğinde JSON parse problemi oluşabilir. Özellikle kullanıcı tarafından girilen açıklamalar, Windows yol ifadeleri veya bazı özel karakter dizileri risk oluşturur. Serializer kullanıldığında escaping çoğunlukla güvenli biçimde yönetilir. Elle string oluşturmak bu nedenle kaçınılması gereken bir anti-pattern'dir. Parser testleri farklı karakter setlerini kapsamalıdır.

JSON İçinde Comment Kullanmak

Standart JSON comment sözdizimini desteklemez. Geliştirici JavaScript nesnesi yazıyormuş gibi // veya blok comment eklediğinde çıktı geçersiz hale gelebilir. Açıklama gerekiyorsa bunu kod tarafındaki generator mantığında tutmak daha doğrudur. Production JSON-LD yalnızca geçerli JSON içermelidir. Linter ve parser testleri bu hatayı release öncesinde yakalayabilir.

Duplicate Key

Duplicate key bazı parser'larda doğrudan hata vermese bile hangi değerin esas alınacağı konusunda belirsizlik yaratabilir. Özellikle nesne merge işlemlerinde aynı property iki kez üretilebilir. Generator kodunda object composition dikkatle yapılmalıdır. Testte aynı node içinde duplicate key kontrolü eklenebilir. Güvenilir structured data çıktısı deterministik olmalıdır.

Yanlış Veri Tipi

Yanlış veri tipi bazen JSON syntax açısından tamamen geçerlidir. Örneğin beklenen nesne yerine metin göndermek parser tarafından kabul edilebilir. Sorun semantic validation veya Google eligibility aşamasında ortaya çıkar. Bu nedenle syntax testinden sonra type validation mutlaka yapılmalıdır. TypeScript veya runtime schema modelleri bu noktada güçlü destek sağlar.

Unparsable Structured Data Nedir?

Unparsable structured data, arama motorunun veya test aracının işaretlemeyi geçerli veri yapısı olarak okuyamadığı durumları ifade eder. Bunun nedeni çoğu zaman eksik virgül, hatalı escape veya bozuk JSON yapısıdır. Böyle bir problemde entity'nin property kalitesini tartışmadan önce parser seviyesini düzeltmek gerekir. Search Console bu tür sorunları belirli raporlarda gösterebilir ve URL örnekleri sunabilir. Otomatik JSON parser testi aynı hatayı production'a çıkmadan çok daha erken yakalayabilir.

Parsing Error

Parsing error, structured data metninin kullanılan format kurallarına göre çözümlenemediğini gösterir. JSON-LD için bu genellikle geçersiz JSON anlamına gelir. Hatanın satır ve karakter konumu parser çıktısında bulunabiliyorsa debugging hızlanır. Fakat gerçek kalıcı çözüm generator'ın geçerli serialization üretmesini sağlamaktır. Elle JSON birleştiren kodlar mümkün olduğunca kaldırılmalıdır.

Missing Comma

Missing comma basit fakat etkili bir parser hatasıdır. Bir property'den diğerine geçişte ayırıcı eksik olduğunda object geçersiz olur. Code review sırasında fark edilebilir, fakat otomatik test daha güvenilir koruma sağlar. Generator çıktısının her build'de parse edilmesi bu hatayı tamamen sıradan bir unit test problemine dönüştürür. SEO ekibinin production'da bulmasını beklemek gereksizdir.

Invalid Escape

Invalid escape kullanıcı girdileriyle çalışan sistemlerde daha sık görülebilir. Metin içindeki backslash veya özel karakterler güvenli serialize edilmezse JSON bozulur. Bu nedenle raw string interpolation yerine object serialization tercih edilmelidir. Test fixture'larında tırnak, ters slash ve farklı Unicode karakterleri bulunmalıdır. Gerçek dünya verisini temsil etmeyen yalnızca basit fixture'lar yeterli koruma sağlamaz.

Incorrect Value Type

Incorrect value type parser hatasıyla aynı şey değildir, fakat bazı raporlarda structured data işleme problemlerinin parçası olarak karşınıza çıkabilir. Değer teknik olarak JSON olsa bile beklenen semantic type'a uymayabilir. Örneğin nested Offer beklenen yerde farklı yapı gönderilebilir. Bu durum type validation aşamasında yakalanmalıdır. Birden fazla doğruluk seviyesini ayırmanın önemi burada tekrar görülür.

Search Console'da Nasıl Görülür?

Search Console structured data sorunlarında hata grupları ve etkilenen URL örnekleri sağlayabilir. Buradaki örnekler sorunun kapsamını anlamak için başlangıç noktasıdır. Ancak yalnızca listelenen birkaç URL'yi düzeltmek yeterli olmayabilir. Sorunun template veya veri kaynağı düzeyinde olup olmadığı araştırılmalıdır. Düzeltmeden sonra validation süreci ve trend takibi devam etmelidir.

Otomatik JSON Parser Testi

Otomatik parser testi en kolay uygulanabilen structured data kalite kontrolüdür. Generator'ın ürettiği script içeriği alınır ve standart JSON parser ile parse edilir. Hata varsa test başarısız olur. Bu test pull request veya build aşamasında çalışabilir. Maliyeti düşük olduğu için structured data olgunluk modelinin ilk otomasyon adımlarından biri olmalıdır.

Syntax Doğru Olduğu Halde Schema Neden Hatalı Olabilir?

Geçerli JSON yalnızca verinin parse edilebilir olduğunu gösterir. Yanlış @type, type'a ait olmayan property, yanlış value type veya eksik required field gibi sorunlar syntax testinden geçebilir. Ayrıca Google'ın desteklemediği bir type kullanıldığında markup semantic olarak geçerli olsa bile rich result hedefi gerçekleşmeyebilir. Sayfa içeriğiyle markup'ın çelişmesi de tamamen ayrı bir kalite problemidir. Bu nedenle structured data doğrulaması çok katmanlı tasarlanmalıdır.

Yanlış @type

Yanlış @type sayfanın temel entity'sini hatalı tanımlayabilir. Bir template kopyalanırken eski type'ın kalması bu soruna yol açabilir. Route bazlı testler beklenen type'ı açık biçimde kontrol etmelidir. Ayrıca type seçimi gerçek sayfa amacına dayanmalıdır. Rich result hedefi varsa Google'ın güncel desteği de ayrıca doğrulanmalıdır.

Type'a Ait Olmayan Property

Property adı Schema.org içinde bulunabilir, fakat her type altında beklenen ilişkiye sahip olmayabilir. Copy-paste markup bu hatanın yaygın nedenidir. Validator genel vocabulary ilişkisini inceleyerek sorunu görünür hale getirebilir. Kod tarafında typed model kullanmak yanlış property eklenmesini daha erken engeller. Büyük projelerde schema generator bu nedenle serbest sözlük mantığıyla tasarlanmamalıdır.

Yanlış Value Type

Yanlış value type, property mevcut olduğu için ilk bakışta gözden kaçabilir. Örneğin tarih alanının standart format yerine doğal dil metni taşıması downstream yorumlamayı zorlaştırabilir. Value type testleri build aşamasına alınabilir. TypeScript model ve runtime validator birlikte güçlü bir koruma sağlar. Harici API verisi doğrudan markup'a aktarılmadan önce normalize edilmelidir.

Required Property Eksikliği

Required property eksikliği Google eligibility açısından kritik olabilir. Bu alanların listesi feature bazında takip edilmelidir. Generator'ın gerçek veri bulunmadığında nasıl davranacağı açık bir business rule'a sahip olmalıdır. Sessizce boş string üretmek çoğu zaman iyi çözüm değildir. Test fixture'ları eksik veri durumunu mutlaka kapsamalıdır.

Google'ın Desteklemediği Type

Schema.org'da geçerli olan bir type Google Search için özel rich result desteğine sahip olmayabilir. Bu durumda kodu sürekli değiştirerek zengin görünüm aramak yanlış problemi çözmeye çalışmaktır. Önce güncel feature support kontrol edilmelidir. Registry bu bilgiyi ekip içinde erişilebilir tutabilir. Böylece deprecated veya removed özellikler yanlışlıkla yeniden uygulanmaz.

Sayfa İçeriğiyle Uyuşmazlık

Structured data'nın sayfada görünen gerçek içeriği temsil etmesi gerekir. Fiyat HTML'de 799 TL iken JSON-LD içinde 999 TL bulunması veri kalitesi problemidir. Aynı durum stok, rating, tarih ve etkinlik bilgileri için de geçerlidir. Bu sorun validator tarafından her zaman yakalanamaz. Content-schema contract test bu nedenle çok değerlidir.

Content–Schema Parity Nedir?

Content-schema parity, yapılandırılmış veri içindeki bilgilerin kullanıcının sayfada gördüğü gerçek içerikle uyumlu olmasıdır. Bunu yalnızca SEO politikası olarak değil, yazılım veri bütünlüğü problemi olarak düşünmek daha verimli sonuç verir. HTML fiyatı ve JSON-LD fiyatı iki farklı kaynaktan geliyorsa zaman içinde ayrışmaları oldukça olasıdır. Ben projelerde fiyat, stok, puan, tarih ve yazar gibi kritik alanları aynı source of truth üzerinden üretmeyi tercih ediyorum. Bu yaklaşım hem arama motoruna hem kullanıcıya çelişkili veri sunma riskini azaltır.

Schema'daki Veri Sayfada Görünür Olmalı

Structured data kullanıcıdan saklanan ayrı bir bilgi deposu gibi kullanılmamalıdır. Schema içinde sunulan temel bilgi gerçek sayfa içeriğiyle desteklenmelidir. Aksi halde arama motoruna kullanıcının göremediği farklı bir gerçeklik anlatılmış olur. Test otomasyonu DOM içindeki görünür veriyi structured data ile karşılaştırabilir. İnsan QA kontrolü de özellikle karmaşık sayfalarda ek güvence sağlar.

Fiyat Eşleşmesi

Fiyat parity testi e-ticaret projelerinde en yüksek değerli kontrollerden biridir. Kampanya, kupon, üyelik veya para birimi kuralları nedeniyle fiyat birden fazla kaynaktan üretilebiliyorsa çelişki riski yükselir. Schema'daki offer price ile sayfadaki esas görünür fiyat iş kuralına göre karşılaştırılmalıdır. Personalized fiyatlar ayrıca ayrı tasarım gerektirir. En güvenli yöntem HTML ve JSON-LD'yi aynı fiyat servisinden beslemektir.

Stok Durumu Eşleşmesi

Ürün sayfası “stokta yok” derken JSON-LD içinde InStock sunmak ciddi veri tutarsızlığıdır. Bu sorun cache süresi veya farklı API uçları nedeniyle ortaya çıkabilir. Availability assertion production smoke test içine eklenebilir. Özellikle hızlı stok değişen ürünlerde cache politikası dikkatle tasarlanmalıdır. Kullanıcının gördüğü durum ile structured data aynı gerçek kaynağı temsil etmelidir.

Rating Eşleşmesi

AggregateRating değerleri gerçek review sisteminden üretilmelidir. Sayfada 4,2 görünen puanın schema içinde 4,8 olması kabul edilebilir bir fark değildir. Yuvarlama varsa aynı business rule her iki katmanda kullanılmalıdır. Test ratingValue ve sayfadaki görünür değeri normalize ederek karşılaştırabilir. Sabit rating yazmak kesinlikle iyi bir schema uygulaması değildir.

Review Count Eşleşmesi

Review count dinamik olarak değişebildiği için farklı cache katmanlarında kolayca ayrışabilir. JSON-LD bir saat eski, HTML anlık veri kullanıyorsa fark oluşabilir. Bu tolerans business rule ile açıkça belirlenmelidir. İdeal çözüm aynı veri snapshot'ını iki çıktıda da kullanmaktır. Büyük farklar monitoring tarafından alarm üretebilir.

Tarih Eşleşmesi

Article sayfalarında datePublished ve dateModified alanları görünür tarih bilgileriyle mantıksal olarak uyumlu olmalıdır. Her deploy işleminde dateModified değerini otomatik olarak “şimdi” yapmak yanlış bir içerik sinyali oluşturabilir. Gerçek içerik değişikliği olmadan tarih güncellenmemelidir. ISO 8601 ve timezone kuralları test edilmelidir. CMS alanı ile JSON-LD aynı tarih kaynağını kullanmalıdır.

Yazar Eşleşmesi

Author schema'da gösterilen kişi veya kuruluş sayfadaki gerçek yazar bilgisiyle eşleşmelidir. Generic veya varsayılan yazar kullanmak kullanıcıya sunulan atıfla çelişebilir. CMS author ID üzerinden hem görünür byline hem JSON-LD üretmek güvenilir bir yöntemdir. Yazar profil URL'leri varsa tutarlı kullanılmalıdır. İçerik üretim sisteminde author verisi zorunlu alan olarak modellenebilir.

Event Bilgisi Eşleşmesi

Etkinlik adı, tarih, saat, konum ve durum bilgisi markup ile görünür içerikte tutarlı olmalıdır. Etkinlik ertelendiğinde yalnızca metni güncelleyip schema'yı eski bırakmak yaygın bir regression örneğidir. Event status ve tarih alanları aynı event modelinden beslenmelidir. Production smoke test yaklaşan etkinlikleri örnekleyebilir. Özellikle iptal ve erteleme senaryoları fixture setinde ayrı bulunmalıdır.

Content–Schema Contract Test Nasıl Kurulur?

Content-schema contract test, sayfanın DOM içeriği ile JSON-LD çıktısını otomatik olarak karşılaştıran test yaklaşımıdır. Önce görünür içerikten normalize edilmiş veri alınır, ardından JSON-LD parse edilir ve karşılık gelen alanlar eşleştirilir. Ürün sayfasında fiyat ve stok, makalede tarih ve yazar, etkinlikte başlangıç zamanı gibi kritik alanlar assertion haline getirilebilir. Eşleşme bozulduğunda build veya release risk seviyesine göre durdurulur. Bu model, structured data'yı SEO kontrolünden çıkarıp gerçek veri sözleşmesine dönüştürür.

DOM'dan Görünür Veriyi Almak

DOM verisini almak için güvenilir selector veya semantic data attribute kullanılabilir. Selector yalnızca görsel CSS class'ına bağlıysa tasarım refactor işlemleri testi gereksiz yere bozabilir. Test amaçlı stabil attribute kullanmak daha güvenilir olabilir. Metin değerleri para birimi ve boşluk gibi formatlardan normalize edilmelidir. Amaç kullanıcıya gösterilen gerçek değeri makine tarafından karşılaştırılabilir hale getirmektir.

JSON-LD Verisini Parse Etmek

Sayfadaki application/ld+json script'leri bulunup standart parser ile parse edilmelidir. Birden fazla script varsa ilgili @type seçilmelidir. @graph kullanılan sayfalarda node çözümleme mantığı eklenebilir. Parse hatası varsa parity testine geçmeden test başarısız sayılmalıdır. Böylece error mesajı gerçek problem seviyesini gösterir.

İki Veri Setini Karşılaştırmak

DOM ve JSON-LD verileri doğrudan string eşitliğiyle karşılaştırılmadan önce normalize edilmelidir. Fiyat için para formatı, tarih için timezone ve URL için trailing slash gibi farklar hesaba katılabilir. İş kuralına göre hangi farkların kabul edilebilir olduğu açıkça tanımlanmalıdır. Tolerans kuralları gereğinden geniş tutulmamalıdır. Testin amacı gerçek semantic farkı yakalamaktır.

Price Assertion

Price assertion görünür ana fiyat ile schema Offer fiyatını karşılaştırır. Kampanya varsa hangi fiyatın structured data içinde temsil edileceği önceden belirlenmelidir. Para birimi ayrıca doğrulanmalıdır. Personalized fiyat varsa herkese açık temel fiyat ile kullanıcıya özel fiyat ayrımı dikkate alınmalıdır. Test yalnızca sayısal değer değil business rule doğruluğunu kontrol etmelidir.

Availability Assertion

Availability assertion ürünün görünür stok durumunu Schema.org availability değeriyle eşleştirir. “Stokta”, “tükendi” ve “ön sipariş” durumları normalize edilmiş enum değerlerine dönüştürülebilir. API ile frontend arasında farklı enum isimleri varsa mapping merkezi tutulmalıdır. Yeni stok durumu eklendiğinde test bilinmeyen değer nedeniyle fail olmalıdır. Bu davranış sessiz yanlış markup üretmekten daha güvenlidir.

Rating Assertion

Rating assertion sayfadaki kullanıcı puanı ile aggregateRating değerini karşılaştırır. Ondalık ayırıcı ve yuvarlama farkları normalize edilmelidir. Review count ayrıca bağımsız assertion olarak tutulabilir. Rating verisi bulunmayan üründe sahte varsayılan değer üretilmediği test edilmelidir. Fixture setinde review'suz ürün bulunmasının nedeni budur.

Date Assertion

Date assertion Article veya Event sayfalarında zaman bilgilerinin tutarlılığını kontrol eder. ISO 8601 string'i gerçek date nesnesine çevrilerek timezone farkları normalize edilebilir. Kullanıcıya gösterilen yerel saat ile schema'daki offset aynı anı temsil etmelidir. datePublished ve dateModified ayrı iş kurallarına sahiptir. Event startDate ve endDate için kronolojik sıralama da ayrıca test edilebilir.

Build'i Hata Durumunda Durdurmak

Her parity farkının build'i durdurması gerekmeyebilir, fakat kritik alanlarda bu güçlü bir kalite kapısıdır. Fiyat, stok ve required property gibi alanlar hard fail olarak değerlendirilebilir. Daha düşük öncelikli recommended farkları warning üretilebilir. Politika repo içinde test kodu ve dokümantasyonla görünür tutulmalıdır. Böylece ekip hangi hatanın neden release'i engellediğini anlayabilir.

Görünmeyen İçeriği Schema ile İşaretlemek Neden Risklidir?

Structured data'nın temel amacı sayfadaki gerçek içeriği daha anlaşılır hale getirmektir, kullanıcıya sunulmayan avantajlı veriler üretmek değildir. Görünmeyen review, gerçek olmayan FAQ, sayfada bulunmayan fiyat veya hiç gerçekleşmeyecek etkinlik bilgisini markup içinde sunmak yanıltıcı sonuçlara yol açabilir. Teknik validator bu tür bağlamsal yanlışları her zaman yakalayamaz. Bu nedenle kalite ve spam politikası kontrolleri test sürecine dahil edilmelidir. Gerçek içerik ile schema arasındaki güven ilişkisi bozulduğunda teknik olarak geçerli JSON'un değeri kalmaz.

Hidden Review

Sayfada gerçek kullanıcı değerlendirmeleri bulunmadığı halde schema içinde review veya rating üretmek riskli bir uygulamadır. Veri gerçek bir review sisteminden gelmeli ve kullanıcı tarafından erişilebilir olmalıdır. Marketing ekibinin manuel olarak verdiği sabit beş yıldız değeri aggregate rating değildir. Test fixture'larında reviewsuz ürünün rating üretmediği kontrol edilmelidir. Bu küçük test büyük politika problemlerini önleyebilir.

Hidden FAQ

FAQ içeriğini yalnızca schema içine ekleyip kullanıcıya sayfada göstermemek doğru yaklaşım değildir. Ayrıca 2026 itibarıyla Google Search'te FAQ rich result gösterimi sona erdiği için eski görünürlük hedefi artık geçerli değildir. FAQ içeriği kullanıcı için gerçekten faydalıysa sayfada normal içerik olarak sunulabilir. Schema kullanma kararı ayrı semantik ihtiyaçlara göre verilebilir. Eski rich result vaadi nedeniyle gizli soru cevap üretmekten kaçınılmalıdır.

Görünmeyen Fiyat

Schema içinde kullanıcının sayfada göremediği farklı bir fiyat sunmak güven sorununa yol açar. Özellikle eski kampanya fiyatlarının cache içinde kalması bu sorunu oluşturabilir. Fiyatın geçerlilik zamanı varsa backend modelinde yönetilmelidir. HTML ve JSON-LD aynı aktif fiyat kaynağını kullanmalıdır. Production parity testi bu sorunu otomatik yakalayabilir.

Olmayan Etkinlik

Gerçekte düzenlenmeyen veya süresi geçmiş bir etkinliği aktif Event schema ile tutmak doğru değildir. İptal ve erteleme durumları event modeline yansıtılmalıdır. Kullanıcıya gösterilen durum ile structured data aynı olmalıdır. Etkinlik sayfalarında cron tabanlı smoke test yaklaşan ve geçmiş event'leri örnekleyebilir. Böylece eski markup'ın aylarca aktif kalması engellenir.

Yanıltıcı Structured Data

Yanıltıcı structured data yalnızca teknik hata değildir, içerik güvenilirliği problemidir. Schema kullanıcıya sunulan sayfayı olduğundan farklı göstermeye çalışmamalıdır. Fake rating, yanlış fiyat veya alakasız type kullanımı bu kategoriye girebilir. İnsan review süreci özellikle yeni schema türlerinde yararlıdır. Otomasyon doğruluğu artırır, ancak iş bağlamını tamamen ikame etmez.

Manual Action Riski

Structured data kurallarının ihlali teknik validator hatasından farklı sonuçlar doğurabilir. Google Search Console içindeki manual action alanları bu nedenle structured data incident incelemesinin parçası olmalıdır. Teknik olarak valid markup politika açısından sorunlu olabilir. Incident playbook bu ayrımı açık şekilde ele almalıdır. Sorunu düzeltirken yalnızca syntax değil içerik ve kullanım amacı da değerlendirilmelidir.

Product Schema Testleri

Product schema e-ticaret sitelerinde en fazla dinamik veri taşıyan structured data türlerinden biridir. Ürün adı, görsel, marka, SKU, GTIN, fiyat, para birimi, stok, rating ve review gibi alanların bir bölümü farklı servislerden gelebilir. Bu nedenle yalnızca örnek bir ürün URL'sini manuel test etmek yeterli değildir. Normal, indirimli, stoksuz, varyantlı ve reviewsuz ürün fixture'ları oluşturmak gerekir. Ürün schema testlerini Core Web Vitals ve genel teknik site kalitesiyle birlikte ele almak isteyen ekipler https://www.diyarbakiryazilim.com.tr/posts/kurumsal-web-siteleri-icin-core-web-vitals-iyilestirme içeriğindeki performans yaklaşımını da inceleyebilir.

Product Name

Product name structured data içinde gerçek ürün adını temsil etmelidir. Sayfa başlığına SEO amacıyla eklenen gereksiz metin schema name alanına otomatik taşınmamalıdır. Ürün veri modelindeki canonical isim tercih edilmelidir. DOM başlığı ile JSON-LD adı arasındaki fark iş kuralına göre test edilebilir. Varyantlarda isim stratejisi ayrıca belirlenmelidir.

Image

Image alanında ürünle gerçekten ilişkili ve erişilebilir görsel URL'leri kullanılmalıdır. CDN dönüşümleri nedeniyle schema'daki URL'nin 404 vermediği smoke test ile kontrol edilebilir. Birden fazla görsel destekleniyorsa array yapısı doğrulanmalıdır. Placeholder görseller gerçek ürün görseli olarak sunulmamalıdır. Image URL kaynağı frontend galerisiyle aynı veri modeline dayanmalıdır.

Brand

Brand alanı ürünün gerçek marka bilgisinden üretilmelidir. Marketplace projelerinde satıcı ile marka birbirine karıştırılmamalıdır. Marka verisi eksik olduğunda generic site adı yazmak çoğu ürün için doğru olmayabilir. Veri modelinde brand ayrı entity olarak tutulabilir. Structured data generator bu alanı doğrudan ürün kaynağından almalıdır.

SKU

SKU dahili ürün veya varyant tanımlayıcısının tutarlı biçimde temsil edilmesine yardımcı olabilir. Parent product ve variant SKU değerleri karıştırılmamalıdır. URL değişse bile SKU business kimliği olarak kararlı kalabilir. Test fixture'larında duplicate SKU senaryoları değerlendirilebilir. Özellikle marketplace entegrasyonlarında mapping hataları burada görülebilir.

GTIN

GTIN yalnızca gerçek ve doğrulanabilir ürün tanımlayıcısı mevcut olduğunda kullanılmalıdır. Eksik GTIN'i rastgele sayı üreterek doldurmak doğru değildir. Farklı GTIN formatları ürün modelinde normalize edilebilir. Varyantların ayrı GTIN değerleri varsa doğru varyantla eşleştirilmelidir. Data quality testleri uzunluk ve format kontrolü yapabilir.

Offers

Offers alanı fiyat, para birimi, availability ve satın alma URL'si gibi ticari bilgileri taşır. E-ticarette en hızlı değişen verilerden biri olduğu için regression riski yüksektir. Offer nesnesi gerçek fiyat servisiyle senkron olmalıdır. Cache politikası HTML ve JSON-LD arasında fark üretmemelidir. Kampanya testleri bu alan için özellikle önemlidir.

Price

Price değeri aktif ürün fiyatını doğru biçimde temsil etmelidir. String veya numeric kullanımının hedef dokümana uygunluğu kontrol edilmelidir. Binlik ayırıcı ve para sembolü gibi sunum karakterleri ham structured data değerine yanlış taşınmamalıdır. Kampanya başlangıç ve bitiş zamanları business logic içinde yönetilmelidir. DOM-schema parity testi bu alanı release blocker yapabilir.

PriceCurrency

PriceCurrency fiyatın hangi para biriminde olduğunu açıklar. Türkiye merkezli projelerde çoğu örnekte TRY kullanılsa da uluslararası mağazalarda URL, locale veya pazar bazlı değer değişebilir. Fiyat ile para biriminin aynı bağlamdan gelmesi gerekir. Cache'in yalnızca fiyatı güncelleyip currency bilgisini eski bırakması önlenmelidir. Test fixture'ları çoklu para birimini kapsamalıdır.

Availability

Availability ürünün satın alınabilirlik durumunu yansıtır. InStock, OutOfStock ve PreOrder gibi durumlar gerçek stok servisindeki enum değerleriyle güvenli biçimde eşlenmelidir. Bilinmeyen yeni stok durumu geldiğinde sessizce InStock varsaymak risklidir. Mapping testi bilinmeyen değerde fail vermelidir. Böylece business rule değişiklikleri structured data'ya kontrolsüz taşınmaz.

URL

Offer veya ürün URL'si kullanıcıyı gerçek satın alma sayfasına yönlendirmelidir. Canonical ve varyant URL stratejisiyle uyum kontrol edilmelidir. Tracking parametreleri gereksiz yere schema URL alanına taşınmamalıdır. Ortam bazlı host değişikliği staging URL'sinin production markup'a sızmasına neden olabilir. Automated test production hostname doğrulaması yapabilir.

AggregateRating

AggregateRating gerçek kullanıcı değerlendirme verisinin özetini temsil etmelidir. Sabit puan veya pazarlama ekibinin verdiği manuel skor kullanılmamalıdır. Rating value ile review count aynı veri snapshot'ından gelmelidir. Review bulunmayan ürünün sahte aggregateRating üretmediği test edilmelidir. Self-serving review politikaları da hedef entity türüne göre ayrıca dikkate alınmalıdır.

Review

Review nesneleri gerçek değerlendirmeleri ve uygun olduğu ölçüde yazar, puan ve içerik bilgilerini temsil etmelidir. Kullanıcıya gösterilmeyen review'ları yalnızca schema içine eklemek doğru değildir. Moderasyon nedeniyle kaldırılan review structured data'dan da çıkmalıdır. PII veya özel veri yanlışlıkla markup içine taşınmamalıdır. Review generator gerçek yayın durumuna bağlı çalışmalıdır.

E-Ticarette Product Schema İçin Test Senaryoları

E-ticarette tek bir “örnek ürün” üzerinden test yapmak gerçek veri çeşitliliğini temsil etmez. Normal ürün, indirimli ürün, stokta olmayan ürün, ön sipariş, reviewsuz ürün, varyant, çoklu teklif ve marketplace senaryolarının her biri farklı kod yollarını çalıştırabilir. Bu yüzden fixture yaklaşımı structured data kalitesinde büyük fark yaratır. Her fixture gerçek business kurallarını temsil etmeli ve beklenen JSON-LD snapshot'ı bulunmalıdır. Release sırasında bu set otomatik çalıştırıldığında ürün schema regression'ları Search Console'a ulaşmadan yakalanabilir.

Normal Ürün

Normal ürün fixture'ı temel Product sözleşmesinin referans örneğidir. Ad, görsel, marka, kimlik, fiyat, para birimi ve stok gibi standart alanlar bulunur. Bu fixture mümkün olduğunca sıradan gerçek bir ürün durumunu temsil etmelidir. Diğer edge case testleri bunun üzerine eklenir. Temel fixture başarısızsa release'in durdurulması genellikle doğru karardır.

İndirimli Ürün

İndirimli ürün senaryosunda hangi fiyatın aktif olduğu açık iş kurallarıyla belirlenmelidir. Eski fiyat, kampanya fiyatı ve üyelik fiyatı birbirine karıştırılmamalıdır. Görünür HTML ile schema aynı aktif fiyat mantığını kullanmalıdır. Kampanya bitişi simüle edilerek otomatik geçiş test edilmelidir. Tarih sınırlarında oluşan bug'lar özellikle gece yarısı ve timezone nedeniyle görülebilir.

Stokta Olmayan Ürün

Stokta olmayan ürünün schema availability değeri gerçek sayfa durumuyla eşleşmelidir. Satın alma butonu kapalıyken JSON-LD InStock kalmamalıdır. Cache invalidation bu senaryoda sık problem yaratır. Fixture stok servisinden sıfır miktar döndüğünde beklenen markup'ı doğrulamalıdır. Production monitoring yüksek trafik alan stoksuz ürünleri örnekleyebilir.

Ön Sipariş

Ön sipariş normal InStock veya OutOfStock durumundan farklı iş kuralına sahip olabilir. Kullanıcıya ön sipariş olduğu açıkça gösterilmelidir. Structured data uygun availability durumunu temsil etmelidir. Tahmini çıkış tarihi ayrı içerik alanında bulunuyorsa tutarlılık test edilebilir. Yeni ürün lansmanlarında bu fixture özellikle önemlidir.

Review Olmayan Ürün

Reviewsuz ürün fixture'ı sahte rating üretimini önlemek için değerlidir. Generator review count sıfırken aggregateRating eklememelidir veya ilgili feature kurallarına göre güvenli davranmalıdır. Varsayılan “5 yıldız” değeri kesinlikle kullanılmamalıdır. Kullanıcı arayüzü de reviewsuz durumu doğru göstermelidir. Bu basit test politika açısından önemli bir güvence sağlar.

Variant Ürün

Variant ürünlerde parent ile child kimlikleri, SKU, GTIN, renk, beden ve URL ilişkileri test edilmelidir. Kullanıcı varyant değiştirdiğinde görünür fiyat değişiyorsa structured data stratejisi buna uygun olmalıdır. Her varyantın ayrı URL'si varsa canonical ve entity ilişkileri önem kazanır. isVariantOf gibi ilişkiler tutarlı kullanılmalıdır. Fixture en az iki farklı varyant içermelidir.

Birden Fazla Teklif

Bir ürün için birden fazla teklif bulunuyorsa offers modelinin gerçek satış yapısını doğru temsil etmesi gerekir. Farklı satıcı, fiyat veya stok seçenekleri varsa entity ilişkileri karıştırılmamalıdır. Kullanıcıya görünmeyen teklifleri markup'a eklemekten kaçınılmalıdır. Array yapısı ve nested Offer doğrulaması yapılmalıdır. Lowest price gibi türetilmiş bilgiler gerçek business rule'a dayanmalıdır.

Marketplace Ürünü

Marketplace ürününde marka, satıcı, offer ve ürün entity'leri birbirinden ayrılmalıdır. Satıcı adı yanlışlıkla Brand olarak kullanılmamalıdır. Aynı ürünün farklı satıcı teklifleri varsa veri modelinin bunu nasıl temsil ettiği açık olmalıdır. Marketplace API değişiklikleri schema generator üzerinde yüksek etki yaratabilir. Contract test yaklaşımı bu yüzden özellikle değerlidir.

Product Variant Structured Data Testleri

Product variant desteği renk, beden, kapasite veya başka özelliklerle ayrılan ürünlerin daha doğru modellenmesini sağlar. Testlerde parent product ile varyant entity'lerinin ilişkisi, isVariantOf bağlantısı ve her varyanta ait SKU ile GTIN değerleri incelenmelidir. Varyant URL'leri farklıysa canonical ve fiyat bilgilerinin seçilen varyantla uyumlu olması gerekir. Kullanıcı arayüzünde mavi beden M seçiliyken schema'nın başka varyantı temsil etmesi parity problemidir. Bu alan özellikle moda ve elektronik mağazalarında ayrı test sözleşmesi gerektirir.

Parent Product

Parent product varyant grubunun ortak ürün kimliğini temsil eder. Ortak marka, temel ad veya grup bilgisi burada modellenebilir. Parent ile satılabilir varyant birbirine karıştırılmamalıdır. Hangi entity'nin fiyat taşıdığı iş modeline göre net olmalıdır. Testler parent ID ve child referanslarının kararlı olduğunu doğrulamalıdır.

Variant

Variant gerçek satın alınabilir ürün seçeneğini temsil edebilir. Renk, beden, SKU ve GTIN gibi alanlar varyanta özgü olabilir. Kullanıcı seçimi değiştiğinde görünen verinin hangi URL veya schema çıktısıyla eşleşeceği önceden tanımlanmalıdır. Client-side seçim kullanılan sitelerde render davranışı ayrıca test edilmelidir. Yanlış varyant fiyatı ciddi parity sorunu oluşturur.

isVariantOf

isVariantOf varyant ile parent ürün arasındaki ilişkiyi ifade etmek için kullanılabilir. Referans verilen parent entity'nin gerçekten tanımlandığı kontrol edilmelidir. Broken @id reference graph kalitesini bozar. Testte tüm varyantların doğru parent'a bağlandığı doğrulanabilir. Aynı parent ID'nin site genelinde kararlı kullanılması faydalıdır.

Renk

Renk değeri kullanıcıya gösterilen gerçek varyant rengiyle eşleşmelidir. Pazarlama adı ile sistem enum'u farklıysa schema için hangi değerin kullanılacağı belirlenmelidir. “BLK01” gibi dahili kod yerine kullanıcıya anlamlı değer tercih edilebilir. DOM seçimi ile JSON-LD renk değeri karşılaştırılabilir. Locale bazlı adlandırma varsa test buna göre normalize edilmelidir.

Beden

Beden moda ürünlerinde varyant kimliğinin önemli parçasıdır. S, M, L veya bölgesel ölçü sistemleri doğru varyantla eşleşmelidir. Kullanıcı başka beden seçtiğinde URL değişmiyorsa structured data güncelleme stratejisi dikkatle düşünülmelidir. Server-rendered canonical varyant bilgisi çoğu durumda daha öngörülebilir olur. Fixture setinde farklı bedenler yer almalıdır.

SKU

Varyant SKU değeri parent SKU ile aynı varsayılmamalıdır. Her satılabilir varyantın kendi kimliği varsa markup bunu doğru yansıtmalıdır. API mapping hatası aynı SKU'nun bütün varyantlara kopyalanmasına yol açabilir. Duplicate detection bu sorunu yakalayabilir. SKU üretim kaynağı product data modelinde tek olmalıdır.

GTIN

GTIN varyant bazında değişebiliyorsa her child entity doğru kodu taşımalıdır. Parent'taki tek GTIN'in tüm varyantlara kopyalanması veri kalitesi problemi olabilir. Fixture iki farklı GTIN içeren varyant setiyle bunu test edebilir. Format doğrulaması ayrıca uygulanmalıdır. Gerçek veri yoksa yapay GTIN üretilmemelidir.

Variant URL'leri Arasında Tutarlılık

Her varyantın ayrı URL'si varsa URL, canonical, selected option ve structured data aynı varyantı temsil etmelidir. Bir URL kırmızı ürünü açarken JSON-LD mavi varyantı göstermemelidir. Crawl tabanlı test varyant URL setini karşılaştırabilir. Duplicate canonical stratejisi SEO ekibiyle birlikte belirlenmelidir. Product model ile routing tasarımı burada doğrudan birbirine bağlanır.

Fiyat Verisi Neden En Sık Bozulan Schema Alanlarından Biridir?

Fiyat verisi kampanya, cache, para birimi, API, kullanıcı segmenti ve stok gibi birçok sistemden etkilenebilir. HTML bir servisten, JSON-LD başka servisten beslendiğinde kısa sürede tutarsızlık oluşması şaşırtıcı değildir. Özellikle kampanya başlangıç ve bitiş anlarında stale cache problemi çok görülür. Bu nedenle fiyat için single source of truth yaklaşımı structured data mimarisinde en güçlü iyileştirmelerden biridir. Fiyat hatası yalnızca schema problemi değil, kullanıcı güveni ve ticari veri bütünlüğü problemidir.

Campaign Price

Campaign price belirli başlangıç ve bitiş koşullarına bağlıdır. Schema generator kampanya durumunu frontend ile aynı business service üzerinden öğrenmelidir. Farklı timezone veya cron zamanlaması fiyatların ayrışmasına neden olabilir. Sınır zaman testleri özellikle önemlidir. Kampanya sona erdiğinde eski fiyatın structured data cache'inde kalmadığı doğrulanmalıdır.

Cached Price

Cached price performans için yararlı olsa da veri güncelliği problemi oluşturabilir. HTML ve JSON-LD farklı cache katmanlarından geliyorsa TTL farkları parity sorununa neden olur. Cache invalidation event'i iki çıktıyı da güncellemelidir. Production smoke test kampanya değişikliklerinden sonra kritik ürünleri kontrol edebilir. Stale fiyat oranı dashboard metriği haline getirilebilir.

API Price

API fiyat verisinin kaynağıysa contract değişiklikleri schema generator'ı etkileyebilir. Alan adı veya veri tipi değiştiğinde frontend fallback yaparken JSON-LD boş kalabilir. API contract testleri bu farkı önceden yakalar. Currency ve tax dahil fiyatın anlamı da dokümante edilmelidir. Schema generator ham veriyi anlamını bilmeden doğrudan yayınlamamalıdır.

Currency

Currency fiyatla birlikte ele alınması gereken temel bağlamdır. Çok ülkeli projelerde domain, locale veya kullanıcı seçimi para birimini değiştirebilir. Structured data bu seçimin hangi public URL bağlamında geçerli olduğunu doğru yansıtmalıdır. Personalized currency kullanımı ekstra dikkat ister. Test URL ve currency mapping'ini birlikte kontrol edebilir.

Personalized Price

Kullanıcıya özel fiyatlandırma structured data açısından daha dikkatli tasarım gerektirir. Her kullanıcıya farklı fiyat gösteriliyorsa arama motoruna hangi genel fiyatın sunulacağı ürün ve merchant kurallarıyla birlikte değerlendirilmelidir. Bot için yapay düşük fiyat üretmek doğru değildir. Public sayfada erişilebilen temel teklif mantığı kullanılmalıdır. SEO, product ve legal ekipleri gerektiğinde bu tasarımı birlikte incelemelidir.

HTML ve JSON-LD'nin Farklı Veri Kaynaklarından Beslenmesi

HTML ve JSON-LD farklı veri kaynaklarından besleniyorsa parity bozulması yalnızca zaman meselesi olabilir. Bir servis güncellenirken diğeri eski kalabilir. En etkili çözüm iki çıktıyı aynı domain modelinden üretmektir. Bu mümkün değilse contract ve integration testleri aradaki eşitliği korumalıdır. Mimari karar test yükünü doğrudan etkiler.

Single Source of Truth

Single source of truth, fiyat gibi kritik verinin birincil kaynağını netleştirir. Frontend görünümü ve JSON-LD aynı normalize edilmiş fiyat nesnesini kullanırsa tutarsızlık ihtimali azalır. Aynı yaklaşım stok, rating ve tarih için de uygulanabilir. Schema generator'ın kendi business logic kopyasını oluşturması önlenmelidir. Bu tasarım uzun vadede bakım maliyetini ciddi biçimde düşürür.

Article ve BlogPosting Schema Testleri

Article ve BlogPosting schema testlerinde headline, author, yayın tarihi, güncelleme tarihi, image, publisher ve mainEntityOfPage gibi alanlar öne çıkar. İçerik sitelerinde en sık gördüğüm sorunlardan biri her deploy sırasında dateModified değerinin otomatik değişmesidir. Bu durum gerçek içerik güncellemesiyle teknik deployment arasındaki farkı ortadan kaldırır. Yazar ve tarih verileri doğrudan CMS içerik modelinden üretilirse hata ihtimali azalır. İçerik ve teknik projelerin nasıl ele alındığını görmek için https://www.diyarbakiryazilim.com.tr/projects sayfasındaki çalışmalar incelenebilir.

Headline

Headline makalenin gerçek başlığını doğru biçimde temsil etmelidir. SEO title ile görünür H1 birbirinden farklıysa schema için hangi değerin kullanılacağı içerik modeli içinde açık olmalıdır. Genellikle makalenin gerçek headline alanı tercih edilir. CMS başlık alanından doğrudan üretim tutarlılığı artırır. Snapshot test gereksiz prefix veya site adının eklenmesini yakalayabilir.

Author

Author bilgisi gerçek içerik yazarıyla eşleşmelidir. Generic site adı veya yanlış kullanıcı hesabı kullanılmamalıdır. CMS author entity'si hem görünür byline hem schema için ortak kaynak olabilir. Person ve Organization ayrımı gerçek yayın modeline göre yapılmalıdır. Yazar profili değiştiğinde structured data otomatik güncellenmelidir.

DatePublished

DatePublished içeriğin ilk yayın tarihini temsil etmelidir. Teknik migration veya yeniden deployment bu değeri değiştirmemelidir. ISO 8601 formatı ve timezone açık biçimde yönetilmelidir. CMS veri modelinde immutable veya kontrollü bir publishedAt alanı bulunması yararlıdır. Parity testi görünür yayın tarihiyle karşılaştırma yapabilir.

DateModified

DateModified gerçek anlamlı içerik güncellemesini temsil etmelidir. Her build veya deploy sırasında otomatik olarak güncel zamana çekmek yanıltıcı olabilir. İçerik editörünün yaptığı anlamlı değişiklikle teknik sistem değişikliği ayrılmalıdır. CMS'de contentModifiedAt benzeri ayrı alan tasarlanabilir. Testler published ve modified zamanlarının mantıksal sırasını da kontrol etmelidir.

Image

Article image alanı içerikle ilişkili gerçek görseli temsil etmelidir. Varsayılan placeholder yalnızca zorunluluk gidermek için kullanılmamalıdır. CDN URL'sinin erişilebilir olduğu kontrol edilebilir. Responsive image sisteminde canonical görsel kaynağı netleştirilmelidir. CMS asset ID üzerinden güvenilir URL üretmek tercih edilir.

Publisher

Publisher yayınlayan gerçek kuruluşu temsil eder. Organization entity'si site genelinde tutarlı @id ile referanslanabilir. Her makalede farklı veya duplicate Organization üretmek graph kalitesini zayıflatır. Logo ve URL bilgileri merkezi kurumsal kaynaktan gelmelidir. Global schema generator bu entity'yi yönetebilir.

mainEntityOfPage

mainEntityOfPage, makalenin hangi web sayfasının ana entity'si olduğunu ifade etmeye yardımcı olabilir. Canonical URL stratejisiyle tutarlı olması önemlidir. Preview veya staging domain'inin production markup'a sızmaması gerekir. Ortam bazlı host testi bu riski azaltır. URL normalization merkezi yardımcı fonksiyonla yapılmalıdır.

Article Tarih Alanları Nasıl Test Edilir?

Article tarih testleri yalnızca string'in varlığını kontrol etmekle sınırlı kalmamalıdır. ISO 8601 biçimi, timezone, yayın ve güncelleme ilişkisi, görünür tarihle eşleşme ve yanlış otomatik güncelleme senaryoları birlikte ele alınmalıdır. Content platformlarında deployment timestamp'ini dateModified olarak kullanmak sık rastlanan anti-pattern'lerden biridir. Gerçek içerik değişmediyse structured data tarihi de değişmemelidir. Böylece kullanıcıya ve arama sistemine daha tutarlı yayın bilgisi sunulur.

ISO 8601

Tarih değerlerini standart ISO 8601 biçiminde üretmek sistemler arası yorum farkını azaltır. Tarih string'i unit test ile parse edilebilir. Eksik timezone veya geçersiz ay değeri gibi hatalar otomatik yakalanabilir. CMS'den gelen tarih değerini doğrudan string concat ile üretmek yerine date library kullanılabilir. Standartlaştırılmış format debugging sürecini de kolaylaştırır.

Timezone

Timezone özellikle etkinlik ve yayın tarihlerinde gün değişimine neden olabilecek önemli ayrıntıdır. UTC veri saklama ile yerel saat gösterimi arasında doğru dönüşüm yapılmalıdır. Türkiye için sabit yerel varsayımlar başka pazarlarda hata oluşturabilir. Schema değeri hangi zaman dilimini temsil ettiğini açık şekilde ifade etmelidir. Test fixture'larında gece yarısına yakın zamanlar kullanılabilir.

Published vs Modified

dateModified normal koşullarda datePublished değerinden önce olmamalıdır. Migration verilerinde bu sıra bozuksa veri temizliği gerekebilir. İlk yayın anında iki değer aynı olabilir. Sonraki anlamlı editlerde modified güncellenir. Assertion bu basit kronolojik kuralı otomatik olarak kontrol edebilir.

Sayfada Görünür Tarihle Eşleşme

Kullanıcıya görünen yayın veya güncelleme tarihi schema ile aynı gerçek olayı temsil etmelidir. Görsel format “26 Ağustos 2026” olabilirken JSON-LD ISO formatında olabilir. Test iki değeri date nesnesine dönüştürerek karşılaştırabilir. Locale farkları normalize edilmelidir. Böylece format farklılığı yanlış alarm üretmez.

Yanlış Otomatik Güncelleme Tarihlerini Önlemek

Build zamanı veya dosya modified timestamp'i içerik güncelleme tarihi olarak kullanılmamalıdır. Bu anti-pattern her deployment sonrasında tüm makaleleri “güncellenmiş” gibi gösterebilir. Gerçek edit olayı CMS seviyesinde izlenmelidir. Schema generator yalnızca bu içerik alanını kullanmalıdır. Regression test deploy sırasında dateModified değişmediğini doğrulayabilir.

BreadcrumbList Testleri

BreadcrumbList, sayfanın site hiyerarşisi içindeki konumunu yapılandırılmış biçimde ifade eder. Testlerde ListItem yapısı, position sırası, name ve item URL'leri birlikte kontrol edilmelidir. Breadcrumb schema gerçek navigasyon veya bilgi mimarisiyle çelişmemelidir. Canonical URL stratejisi özellikle kategori ve filtre sayfalarında önem kazanır. Aynı breadcrumb generator tüm site template'lerinde kullanılıyorsa küçük bir hata çok sayıda URL'yi etkileyebilir.

ListItem

BreadcrumbList içindeki her adım ListItem olarak modellenir. Eksik veya yanlış type kullanımı zinciri bozabilir. Generator route segmentlerinden otomatik üretim yapıyorsa özel sayfalar için mapping gerekebilir. Test item sayısını görünür breadcrumb ile karşılaştırabilir. Böylece navigasyon ve schema birlikte değişir.

Position

Position değerleri breadcrumb sırasını ifade eder ve mantıksal olarak artmalıdır. Duplicate veya atlanan değerler generator hatasına işaret edebilir. Basit array index yaklaşımı çoğu projede güvenli üretim sağlar. Test tüm item'ların sıralı olduğunu doğrulayabilir. Manuel position yazımı gereksiz risk yaratır.

Name

Name kullanıcıya gösterilen breadcrumb etiketiyle anlamlı biçimde eşleşmelidir. Dahili route kodları kullanıcı dostu ad yerine geçmemelidir. CMS kategori adı veya navigasyon modeli ortak kaynak olarak kullanılabilir. Locale sitelerinde dil doğru bağlama göre seçilmelidir. Parity testi görünür label ile schema name'i karşılaştırabilir.

Item

Item URL ilgili breadcrumb adımının gerçek hedefini göstermelidir. 404 URL veya staging host üretimi kontrol edilmelidir. URL normalize edilerek canonical stratejiyle uyum sağlanabilir. Tracking parametresi eklenmemesi tercih edilir. Crawl testi breadcrumb URL'lerinin HTTP durumunu kontrol edebilir.

Hiyerarşi

Breadcrumb hiyerarşisi site bilgi mimarisini tutarlı temsil etmelidir. Ürün URL'sinin kategorisi görünür navigasyondan farklıysa kullanıcı ve arama sistemi farklı yapı görür. Çoklu kategori ürünlerde hangi canonical breadcrumb'ın kullanılacağı önceden belirlenmelidir. Business rule merkezi olmalıdır. Rastgele referrer veya kullanıcı gezinme geçmişine göre markup değiştirmekten kaçınılmalıdır.

Gerçek Site Navigasyonuyla Uyum

Schema breadcrumb yalnızca SEO için üretilmiş yapay bir hiyerarşi olmamalıdır. Kullanıcının sayfada gördüğü breadcrumb veya gerçek bilgi mimarisiyle desteklenmelidir. DOM-schema parity burada da uygulanabilir. Menü yapısı ile breadcrumb birebir aynı olmak zorunda değildir, fakat anlamsal çelişki olmamalıdır. SEO ve UX ekipleri hiyerarşi kararını birlikte vermelidir.

Canonical URL ile Uyum

Breadcrumb item URL'leri canonical URL stratejisiyle gereksiz çelişki yaratmamalıdır. Özellikle filtre ve parametreli kategori sayfalarında canonical hedef başka URL olabilir. Structured data generator SEO routing kurallarını bilmelidir. Aynı helper fonksiyonun canonical ve breadcrumb URL üretiminde kullanılması tutarlılığı artırır. Test environment host sızıntısını da kontrol etmelidir.

Review ve AggregateRating Testleri

Review ve AggregateRating alanları kullanıcı güvenini doğrudan etkileyen veriler olduğu için yalnızca syntax düzeyinde test edilmemelidir. Rating value, rating count, review count, best rating ve worst rating gerçek değerlendirme sistemiyle uyumlu olmalıdır. Sahte veya görünmeyen puan üretmek teknik olarak kolay olsa da doğru bir uygulama değildir. Ayrıca self-serving review politikaları hedef entity türüne göre dikkate alınmalıdır. Rating verisinin tek kaynaktan üretilmesi ve reviewsuz senaryonun ayrı fixture olarak test edilmesi en güvenli yaklaşımdır.

Gerçek Review Verisi

Review structured data gerçek kullanıcı değerlendirmelerine dayanmalıdır. Moderasyondan geçmemiş veya yayınlanmamış içerik schema içine taşınmamalıdır. Review silindiğinde markup da güncellenmelidir. Backend query yalnızca public review setini kullanmalıdır. Böylece DOM ve schema aynı veri koleksiyonunu temsil eder.

Rating Value

Rating value gerçek ortalama puanı göstermelidir. Yuvarlama kuralı UI ve schema arasında aynı olmalıdır. Beş üzerinden 4,24 değeri ekranda 4,2 gösteriliyorsa schema stratejisi dokümante edilmelidir. Sabit 5 değeri kullanmak kabul edilebilir bir fallback değildir. Test gerçek hesaplama fonksiyonunu doğrulamalıdır.

Rating Count

Rating count puanlama sayısını ifade eder ve review count ile aynı olmak zorunda olmayabilir. Sistem kullanıcıların yalnızca puan vermesine izin veriyorsa iki değer doğal olarak farklılaşabilir. Bu ayrım veri modelinde net olmalıdır. UI hangi değeri gösteriyorsa schema doğru property'yi kullanmalıdır. Test farklı senaryolar için beklenen sayıları doğrulayabilir.

Review Count

Review count gerçek yazılı değerlendirme sayısını temsil etmelidir. Moderasyon veya silme işlemleri sayıyı değiştirebilir. Cache süreleri nedeniyle eski değer kalmamalıdır. Aggregate query ile sayfadaki liste aynı filtre koşullarını kullanmalıdır. Büyük farklar content parity alarmı üretebilir.

Best Rating

Best rating kullanılan puanlama ölçeğinin üst sınırını açıklar. Sistem beş yıldızlıysa bu değer business modelle tutarlı olmalıdır. Farklı kategorilerde farklı ölçekler kullanılıyorsa generator bunu varsaymamalıdır. Rating value bu sınırı aşmamalıdır. Unit test basit range assertion ile problemi yakalayabilir.

Worst Rating

Worst rating ölçeğin alt sınırını ifade eder. Sıfır veya bir gibi değerler kullanılan gerçek review sistemine göre belirlenmelidir. Rating value bu değerin altında olmamalıdır. Best ve worst ilişkisi de mantıksal olarak test edilmelidir. Sabit değerler yalnızca sistem ölçeği gerçekten sabitse kullanılmalıdır.

Self-Serving Review Politikası

Review markup uygulanırken Google'ın ilgili entity ve review politikaları güncel dokümantasyondan kontrol edilmelidir. Kuruluşun kendisi hakkında kendi sitesinde oluşturduğu değerlendirme gösterim beklentileri farklı olabilir. Teknik olarak AggregateRating üretilebilmesi Google Search'te aynı biçimde kullanılacağı anlamına gelmez. Bu nedenle implementation öncesi feature policy kontrolü gereklidir. SEO spesifikasyonu bu politikayı geliştiriciye açık biçimde iletmelidir.

Sahte Rating Üretmemek

Rating alanını doldurmak için gerçek olmayan veri üretmekten kesinlikle kaçınılmalıdır. Reviewsuz ürüne beş yıldız eklemek kısa vadeli görünürlük denemesi gibi görülse de veri güvenilirliğini bozar. Generator yalnızca doğrulanmış review servisinden veri almalıdır. Veri yoksa ilgili rating alanı business rule'a göre hiç üretilmeyebilir. Testin amacı warning'i gizlemek değil doğru bilgiyi korumaktır.

Event Schema Testleri

Event schema zaman, konum ve durum değişikliklerine duyarlı olduğu için düzenli test gerektirir. Name, startDate, endDate, timezone, location, eventStatus ve offers alanlarının gerçek etkinlik bilgileriyle eşleşmesi gerekir. İptal veya erteleme sonrası yalnızca görünür sayfayı güncellemek yeterli değildir. Structured data aynı event modelinden otomatik güncellenmelidir. Özellikle yaklaşan etkinlikler için production smoke test kullanmak eski tarih veya yanlış durum problemlerini azaltır.

Name

Event name gerçek etkinlik adını temsil etmelidir. SEO amaçlı gereksiz şehir veya anahtar kelime tekrarları schema adını bozmamalıdır. CMS event title ortak kaynak olarak kullanılabilir. Görünür H1 ile anlamlı biçimde uyum beklenir. Snapshot test istenmeyen prefix ve suffix eklenmesini yakalayabilir.

StartDate

StartDate etkinliğin gerçek başlangıç anını doğru timezone ile ifade etmelidir. Yerel saat ile UTC dönüşümü dikkatle yapılmalıdır. Etkinlik ertelendiğinde tarih aynı kaynaktan güncellenmelidir. Geçmiş tarih yanlışlıkla aktif event olarak kalmamalıdır. Test current time ile mantıksal kontroller yapabilir.

EndDate

EndDate varsa startDate değerinden önce olmamalıdır. Çok günlük etkinliklerde timezone dönüşümü özellikle önemlidir. Etkinlik uzatılırsa HTML ve schema aynı güncellemeyi almalıdır. Null endDate senaryosu ilgili feature kurallarına göre ele alınmalıdır. Unit test kronolojik sıralamayı doğrulayabilir.

Timezone

Timezone hatası etkinliği saatlerce kaydırabilir ve kullanıcıya yanlış bilgi sunabilir. CMS yerel saat saklıyor, backend UTC varsayıyorsa ciddi fark oluşabilir. Veri modeli saat dilimini açıkça taşımalıdır. ISO datetime offset kullanımı belirsizliği azaltır. Farklı ülkelerdeki etkinlik fixture'ları test kapsamına alınmalıdır.

Location

Location etkinliğin gerçek fiziksel konumunu doğru biçimde temsil etmelidir. Adres, venue adı ve şehir bilgileri event sayfasıyla uyumlu olmalıdır. Online-only etkinliklerin güncel Google feature kuralları ayrıca kontrol edilmelidir. Google'ın 2025 dokümantasyon güncellemesinde event deneyimi için fiziksel konum ve genel rezervasyon erişimi konusunda ek açıklamalar yapıldı. Bu nedenle eski örnekleri aynen kopyalamak yerine güncel dokümantasyon kullanılmalıdır.

EventStatus

EventStatus iptal, erteleme veya yeniden planlama gibi değişiklikleri temsil etmek için önemlidir. Event lifecycle backend modelinde açık enum olarak tutulmalıdır. Kullanıcıya iptal mesajı gösterilirken schema aktif görünmemelidir. Status transition testleri fixture olarak yazılabilir. Operasyon ekibinin etkinlik güncellemesi schema'yı otomatik tetiklemelidir.

Offers

Event offers bilet veya katılım bilgilerini temsil edebilir. Fiyat, para birimi, URL ve availability gerçek satış sistemiyle uyumlu olmalıdır. Ücretsiz etkinlik business rule'u ayrı test edilmelidir. Bilet satışı kapandığında eski availability değeri kalmamalıdır. Ticketing entegrasyonu contract test kapsamına alınabilir.

İptal veya Erteleme Durumları

İptal ve erteleme event schema için en önemli edge case'ler arasındadır. Tarih, eventStatus ve görünür kullanıcı mesajı birlikte güncellenmelidir. Sadece CMS metnini değiştirmek yeterli değildir. Eski schema cache'i temizlenmelidir. Production monitoring yaklaşan etkinliklerde status-parity kontrolü yapabilir.

Organization ve LocalBusiness Testleri

Organization ve LocalBusiness markup, kurumun adı, URL'si, logosu, adresi, telefonu, çalışma saatleri ve ilişkili profilleri gibi bilgileri temsil edebilir. Bu alanlarda en sık karşılaşılan sorun, yıllar önce eklenmiş sabit verinin site güncellendiğinde unutulmasıdır. Kurumsal bilgi tek bir merkezi konfigürasyondan üretilirse farklı sayfalarda çelişki azalır. LocalBusiness kullanımı gerçek işletme modeline dayanmalı ve fiziksel bilgiler doğru olmalıdır. Diyarbakır Yazılım Topluluğu hakkında güncel kurumsal bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Name

Organization name gerçek kurumsal adı göstermelidir. Sayfa title şablonundaki slogan veya SEO uzantısı otomatik olarak name alanına eklenmemelidir. Merkezi site konfigürasyonu bu değer için uygun kaynaktır. Rebranding durumunda tüm schema node'ları tek yerden güncellenmelidir. Duplicate Organization entity'lerinde farklı isim kullanımı engellenmelidir.

URL

Organization URL kurumun canonical ana web adresini göstermelidir. Staging veya lokal domain production çıktısına sızmamalıdır. Protocol ve host normalization merkezi yardımcı fonksiyonla yapılabilir. Çoklu domain yapısında ana entity stratejisi dokümante edilmelidir. Automated smoke test hostname kontrolü yapabilir.

Logo

Logo gerçek ve erişilebilir kurumsal görsel URL'sine işaret etmelidir. Asset taşındığında schema URL'sinin 404 olmaması önemlidir. CDN dönüşümü stabil URL üretiyorsa tercih edilebilir. Boyut ve format gereksinimleri hedef feature dokümanına göre kontrol edilmelidir. Logo bilgisi merkezi Organization modelinden gelmelidir.

Address

Address gerçek işletme veya kuruluş adresini doğru biçimde temsil etmelidir. LocalBusiness için fiziksel konum bilgisi özellikle önemlidir. Taşınma sonrası eski adresin schema'da kalması sık rastlanan bakım problemidir. Kurumsal iletişim sayfasıyla parity kontrolü yapılabilir. Adres değişikliği tek konfigürasyon üzerinden bütün siteye yansıtılmalıdır.

Telephone

Telefon numarası gerçek ve güncel iletişim bilgisinden üretilmelidir. Format normalize edilerek ülke kodu stratejisi belirlenebilir. Kullanıcıya gösterilen numara ile schema farklı olmamalıdır. Eski departman telefonu hard-code edilmemelidir. Merkezi contact model uzun vadeli bakım sağlar.

Opening Hours

Opening hours gerçek çalışma saatlerini yansıtmalıdır. Resmi tatil veya dönemsel değişiklikler varsa veri modelinin bunu nasıl yöneteceği düşünülmelidir. Sabit schema ile dinamik site bilgisi arasında fark oluşmamalıdır. LocalBusiness projelerinde parity testi bu alana uygulanabilir. Güncel olmayan saat kullanıcı güvenini doğrudan etkiler.

sameAs

sameAs kurumun gerçek ve resmi dış profil ilişkilerini göstermek için kullanılabilir. Alakasız veya sahip olunmayan profiller eklenmemelidir. URL listesi merkezi ayarlardan yönetilebilir. Kapanan sosyal profil kaldırılmalıdır. Link health kontrolü periyodik olarak uygulanabilir.

Gerçek Kurumsal Bilgilerle Uyum

Organization markup'ın temel amacı kurum hakkında gerçek bilgi sunmaktır. Schema içinde başka, iletişim sayfasında başka telefon veya adres bulunması veri kalitesi problemidir. Kurumsal bilgiler tek bir kaynak üzerinden üretildiğinde bu risk büyük ölçüde azalır. Periodic audit özellikle eski sitelerde değerlidir. Structured data bakımını genel kurumsal içerik yönetiminden ayırmamak gerekir.

Aynı Sayfada Birden Fazla Schema Kullanılabilir mi?

Evet, aynı sayfada birden fazla schema entity'si bulunabilir ve bu çoğu zaman gerçek sayfa yapısını daha doğru ifade eder. Product sayfasında BreadcrumbList, Article sayfasında Organization veya WebPage gibi ilişkili entity'ler bulunabilir. Önemli olan aynı gerçek entity'yi çelişkili verilerle tekrar tekrar üretmemektir. @graph ve @id ilişkileri bu yapıyı daha düzenli modellemenize yardımcı olabilir. Testler type sayısının yanında entity kimliklerini ve referans bütünlüğünü de kontrol etmelidir.

Product + Breadcrumb

Product ve BreadcrumbList aynı ürün sayfasında doğal biçimde birlikte bulunabilir. Product satılan varlığı, breadcrumb ise sayfanın bilgi mimarisindeki konumunu ifade eder. İki yapı farklı sorulara cevap verir. URL alanları canonical stratejiyle uyumlu olmalıdır. Test beklenen iki type'ın da render edildiğini doğrulayabilir.

Article + Breadcrumb

Article ve BreadcrumbList içerik sitelerinde sık kullanılan kombinasyondur. Article yayınlanan içeriği, breadcrumb kategori yolunu temsil eder. Başlık ve kategori değişiklikleri farklı veri kaynaklarından yönetilebilir. Ancak canonical URL ilişkileri tutarlı kalmalıdır. Template snapshot test iki node'un beklenen yapısını korur.

Recipe + Video

Bir tarif sayfasında gerçek video içeriği bulunuyorsa farklı entity'ler arasında ilişkiler kurulabilir. Her entity sayfada gerçekten bulunan içeriği temsil etmelidir. Video markup eklemek için sayfada video olmayan durumlarda yapay entity üretilmemelidir. Google'ın ilgili feature desteği güncel dokümantasyondan ayrıca doğrulanmalıdır. Test content availability koşulunu kontrol edebilir.

Organization + WebPage

Organization site sahibini, WebPage ise belirli URL'yi temsil eder. Aynı Organization her sayfada yeni ve çelişkili node olarak üretilmek yerine kararlı @id ile referanslanabilir. Logo, URL ve isim merkezi kaynaktan gelmelidir. WebPage ana entity ilişkisini ilgili içerikle bağlayabilir. Graph test bu referansların kırılmadığını kontrol eder.

@graph

@graph birden fazla entity'yi tek JSON-LD blok içinde düzenlemek için kullanışlıdır. Bu yapı duplicate script sayısını azaltabilir ve ilişkileri daha görünür hale getirebilir. Bununla birlikte graph içindeki her node bağımsız olarak doğru olmalıdır. Bir node'daki hata diğerlerinin de debugging sürecini zorlaştırabilir. Automated graph validator bu yüzden değerlidir.

@id ile Entity Bağlama

@id aynı entity'nin farklı node'larda tutarlı biçimde referanslanmasını sağlar. Organization için site çapında kararlı bir kimlik kullanmak duplicate üretimini azaltabilir. URL formatının deployment ortamına göre yanlış değişmediği test edilmelidir. Referans verilen ID graph içinde tanımlı olmalıdır. Broken reference tespit etmek oldukça kolay bir otomasyon kuralıdır.

Aynı Entity'yi Duplicate Etmemek

Aynı Product veya Organization entity'sini iki farklı plugin veya script farklı değerlerle üretirse arama motoruna çelişkili bilgi sunulabilir. Duplicate detection type ve canonical entity kimliği üzerinden yapılabilir. Tema, SEO eklentisi ve custom code birlikte schema üretiyorsa risk artar. Önce ownership belirlenmeli ve tek generator tercih edilmelidir. Migration sırasında geçici duplicate oluşumu ayrıca test edilmelidir.

@graph Yapısı Nasıl Test Edilir?

@graph testinde yalnızca JSON'un parse edilmesi yeterli değildir. Her node'un type değeri, benzersiz @id kullanımı, entity referansları ve main entity ilişkileri incelenmelidir. Duplicate Organization veya broken reference gibi problemler semantic graph kalitesini bozar. Basit bir script graph içindeki tüm ID'leri toplayıp referans edilen ID'lerin varlığını doğrulayabilir. Böylece karmaşık JSON-LD yapıları da klasik yazılım testleriyle güvence altına alınabilir.

Her Node'un @type'ı

Graph içindeki her node beklenen entity rolünü açıkça ifade etmelidir. Type eksikliği veya yanlış type generator bug'ına işaret edebilir. Template contract hangi node'ların zorunlu olduğunu belirleyebilir. Product sayfasında beklenen Product node'u yoksa test fail olmalıdır. Generic graph snapshot tek başına yeterli değildir.

Benzersiz @id

Aynı graph içinde farklı entity'lerin yanlışlıkla aynı @id değerini kullanması ciddi ilişki problemi yaratır. ID generator merkezi ve deterministik olmalıdır. Test duplicate ID listesini kolayca çıkarabilir. Aynı gerçek entity'nin aynı ID ile referanslanması ise beklenen davranıştır. Test duplicate node ile shared reference arasındaki farkı bilmelidir.

Entity Referansları

Entity referansı bir node'un başka entity'ye bağlanmasını sağlar. Örneğin Article publisher üzerinden Organization'a bağlanabilir. Referans edilen ID'nin gerçekten tanımlı olduğu kontrol edilmelidir. Ortam değişiklikleri host içeren ID'leri bozabilir. Production ve staging ID stratejisi açıkça belirlenmelidir.

Broken @id Reference

Broken reference, bir node'un graph içinde bulunmayan veya yanlış oluşturulmuş kimliğe işaret etmesidir. Bu hata syntax açısından tamamen geçerli olabilir. Bu yüzden semantic graph testi gereklidir. Basit set membership assertion ile otomatik yakalanabilir. Büyük graph yapılarında çok değerli bir kontroldür.

Duplicate Organization

Birçok CMS ve SEO eklentisi Organization markup üretmeye çalışabilir. Custom kod da ayrı Organization eklediğinde aynı kurum iki veya üç kez tanımlanabilir. Değerler farklıysa problem daha belirgin hale gelir. Duplicate detector name, URL ve @id ilişkilerini inceleyebilir. En güvenli çözüm tek ownership modelidir.

Main Entity İlişkisi

Sayfanın ana entity'si ile WebPage ilişkisi doğru kurulmalıdır. Product sayfasında ana varlık ürün, Article sayfasında içerik olabilir. Yanlış template inheritance nedeniyle eski main entity referansı kalabilir. Route contract test bu ilişkiyi doğrulayabilir. Böylece schema graph sayfanın gerçek anlamını daha doğru yansıtır.

Duplicate Schema Sorunu

Duplicate schema, aynı sayfada aynı entity'nin birden fazla kaynaktan tekrar ve bazen çelişkili biçimde üretilmesidir. WordPress eklentileri, tema, CMS, GTM ve custom code aynı anda markup eklediğinde bu sorun sık görülür. İki Product node'undan biri 799 TL, diğeri 999 TL gösteriyorsa hangi bilginin gerçek olduğu belirsizleşir. Duplicate detector bu nedenle structured data audit'in temel parçalarından biri olmalıdır. Sorun genellikle schema'yı tek bir owner ve generator altında toplamakla daha kalıcı biçimde çözülür.

SEO Plugin + Tema

SEO plugin ve tema aynı entity için markup üretebilir. Güncelleme sonrası tema yeni schema özelliği eklediğinde daha önce olmayan duplicate aniden ortaya çıkabilir. Release regression testi algılanan type ve entity sayısını kontrol etmelidir. Plugin ayarları ile tema özellikleri belgelenmelidir. Hangisinin source of truth olduğu açık biçimde seçilmelidir.

CMS + Custom Code

CMS platformu varsayılan structured data eklerken geliştirme ekibi custom JSON-LD generator yazmış olabilir. İki yapı aynı Product veya Article'ı farklı değerlerle temsil edebilir. Önce mevcut markup envanteri çıkarılmalıdır. Custom implementation başlamadan önce platform davranışı test edilmelidir. Gereksiz ikinci generator yerine mevcut sistem genişletilebilir.

GTM + Server-Side JSON-LD

GTM üzerinden eklenen JSON-LD ile server-rendered schema aynı anda çalışabilir. Tag configuration unutulduğunda eski markup yeni server uygulamasından sonra da devam eder. Source ve rendered HTML incelemesi bunu ortaya çıkarır. GTM container structured data ownership listesine dahil edilmelidir. Migration checklist eski tag'in kaldırılmasını içermelidir.

Aynı Product'ın İki Kez İşaretlenmesi

Aynı Product'ın iki kez işaretlenmesi özellikle e-ticaret projelerinde veri çelişkisi riski taşır. İki node aynı SKU veya URL'yi farklı fiyatlarla sunabilir. Duplicate detector kimlik alanlarını kullanarak bunu işaretleyebilir. Birden fazla gerçek ürün bulunan liste sayfalarıyla duplicate problemi birbirine karıştırılmamalıdır. Sayfanın business yapısı teste bağlam sağlar.

Birbirini Çürüten Offer Verileri

İki Offer nesnesi gerçekten farklı teklifler olabilir, ancak aynı satıcı ve aynı ürün için çelişkili fiyat sunuyorsa sorun oluşur. Test offer identity modelini anlamalıdır. Sadece “iki Offer var” diyerek hata üretmek yeterli değildir. Fiyat, seller, URL ve availability birlikte değerlendirilmelidir. Marketplace senaryoları özel kurallar gerektirir.

Duplicate Detector

Duplicate detector sayfadaki JSON-LD script'lerini parse edip type, @id, URL, SKU veya başka kimlik alanlarına göre kümelendirebilir. Aynı entity için birden fazla farklı değer bulunduğunda warning veya error üretilebilir. Bu kontrol production crawl içinde çalıştırılabilir. Template bazlı trend raporu hangi plugin veya release'in problemi başlattığını bulmayı kolaylaştırır. Açık kaynak schema tester projesinde de değerli bir modül olabilir.

WordPress Schema Testleri

WordPress projelerinde schema çoğu zaman tema, SEO eklentisi, WooCommerce ve ek modüllerin birleşiminden oluşur. Bu nedenle sayfada hangi kodun hangi kaynaktan geldiğini belirlemek ilk adımdır. Eklenti ayar ekranında doğru görünen yapı production HTML'de duplicate veya eksik olabilir. Tema ve eklenti güncellemeleri structured data regression testi gerektirir. WordPress'te “plugin hallediyor” yaklaşımı yerine gerçek URL çıktısını düzenli doğrulamak daha güvenlidir.

Yoast

Yoast gibi SEO eklentileri belirli schema graph yapıları üretebilir. Custom geliştirme yapılmadan önce eklentinin hangi entity'leri oluşturduğu incelenmelidir. Aynı Organization veya Article yapısını tekrar üretmek gereksiz duplicate doğurabilir. Eklenti güncellemesinden sonra snapshot farkı kontrol edilmelidir. Custom hook kullanılıyorsa sürüm uyumluluğu ayrıca test edilmelidir.

Rank Math

Rank Math kullanılan projelerde de aktif schema modülleri ve template ayarları envantere dahil edilmelidir. Aynı içerik türü için hem eklenti hem tema markup üretmemelidir. Plugin konfigürasyonu repository dışında tutuluyorsa değişiklik takibi zorlaşabilir. Kritik ayarlar release dokümantasyonuna eklenebilir. Production crawl gerçek sonucu doğrulamalıdır.

Tema Tarafından Eklenen Schema

Bazı WordPress temaları fark edilmeden Organization, Article veya Breadcrumb markup ekleyebilir. Tema değiştirilirken yeni schema'nın mevcut eklentiyle çakışıp çakışmadığı test edilmelidir. Source HTML araması hızlı ilk kontrol sağlar. Ancak rendered DOM ve JSON-LD parse envanteri daha güvenilir sonuç verir. Tema güncellemesi regression suite'i tetiklemelidir.

WooCommerce

WooCommerce ürün verisi Product schema için güçlü bir kaynak olabilir, ancak eklenti ve tema davranışı birlikte incelenmelidir. Variant, stok, fiyat ve review alanları gerçek WooCommerce modelinden gelmelidir. Custom pricing plugin'leri schema fiyatını otomatik güncellemeyebilir. İndirim ve varyant fixture'ları bu nedenle önemlidir. Checkout fiyatıyla ürün sayfası markup'ı arasındaki business rule net olmalıdır.

Plugin Çakışmaları

İki SEO veya schema plugin'inin aynı anda aktif olması duplicate ihtimalini yükseltir. Her plugin farklı Organization, Breadcrumb veya Product node'u üretebilir. Plugin inventory structured data audit'in başlangıç adımı olmalıdır. Gereksiz modüller kapatılmalı ve tek ownership sağlanmalıdır. Güncelleme sonrası active plugin listesi ve schema snapshot karşılaştırılabilir.

Güncelleme Sonrası Regression

WordPress otomatik güncellemeleri template çıktısını değiştirebilir. Bu nedenle kritik schema type'ları için production smoke test yararlıdır. Update sonrasında Product veya Article sayfasında beklenen node kaybolursa alarm üretilebilir. Aynı şekilde duplicate sayısındaki artış da izlenebilir. Schema monitoring WordPress bakım planının normal parçası olmalıdır.

Shopify Schema Testleri

Shopify projelerinde theme JSON-LD, ürün varyant verisi ve uygulamalar tarafından eklenen ek schema kaynakları birlikte incelenmelidir. Tema güncellemesi veya app kurulumu duplicate Product markup oluşturabilir. Fiyat ve availability verileri seçilen varyanta bağlı olduğundan parity testi özellikle önemlidir. Client-side varyant değişimi ile server-rendered structured data arasındaki strateji açık olmalıdır. Her tema release'inde representative product fixture seti yeniden test edilmelidir.

Theme JSON-LD

Shopify temaları ürün ve site bilgileri için JSON-LD üretebilir. Custom snippet eklenmeden önce mevcut theme output analiz edilmelidir. Aynı Product'ı ikinci kez üretmek yerine mevcut yapıyı geliştirmek daha güvenli olabilir. Theme update sonrası snippet değişiklikleri snapshot ile karşılaştırılabilir. Git tabanlı theme geliştirmede bu kontrol otomatikleştirilebilir.

Product

Shopify Product schema ürün modelindeki gerçek isim, medya ve teklif bilgilerini yansıtmalıdır. Product ve selected variant ayrımı doğru kurulmalıdır. Storefront üzerindeki SEO title ile product title birbirine karıştırılmamalıdır. Test gerçek Liquid çıktısını parse etmelidir. Placeholder veya preview verisi production'a sızmamalıdır.

Variant

Variant seçimi fiyat, stok, SKU ve URL bilgilerini değiştirebilir. Schema'nın hangi varyantı temsil ettiği açık olmalıdır. Her varyantın ayrı URL parametresi veya canonical stratejisi varsa birlikte test edilmelidir. Client-side selection markup'ı değiştiriyorsa render testi gerekir. Yanlış varyant bilgisini Google'a sunmak parity sorunudur.

Price

Shopify'da fiyat kampanya ve compare-at price gibi farklı alanlardan gelebilir. Structured data'nın aktif satış fiyatını hangi kuralla seçtiği net olmalıdır. Liquid filter veya money format çıktısı raw numeric değerle karıştırılmamalıdır. Çoklu currency mağazalarında market bağlamı test edilmelidir. DOM ile JSON-LD fiyat assertion'ı yüksek değer taşır.

Availability

Availability ürünün veya seçili varyantın gerçek satın alınabilir durumunu göstermelidir. Inventory policy nedeniyle stok sıfırken satışa izin verilen senaryolar ayrı ele alınabilir. Basit quantity kontrolü her mağazada doğru business rule olmayabilir. Schema generator storefront'un gerçek purchasability mantığını kullanmalıdır. Fixture bu özel durumu temsil etmelidir.

App Tarafından Eklenen Duplicate Schema

SEO, review veya merchandising app'leri kendi JSON-LD bloklarını ekleyebilir. Yeni app kurulumu sonrası duplicate schema audit yapılmalıdır. App kaldırıldığında script'in gerçekten kaybolduğu doğrulanmalıdır. App kaynaklı markup bazen admin ekranında açıkça görünmeyebilir. Rendered HTML inventory bu nedenle önemlidir.

Tema Güncelleme Testleri

Tema güncellemesi schema snippet yapısını değiştirebilir veya custom değişiklikleri silebilir. Staging veya preview theme üzerinde regression testi çalıştırmak güvenli yaklaşımdır. Product, collection ve article template'leri örneklenebilir. Deployment sonrası production smoke test yapılmalıdır. Böylece sorun arama raporlarına yansımadan fark edilebilir.

Headless CMS ve Structured Data

Headless CMS mimarisinde structured data çoğu zaman CMS veri modeli, API, frontend template ve schema generator arasındaki zincirin sonucudur. Bu ayrık yapı güçlü esneklik sağlar, fakat contract bozulmalarına da açıktır. CMS alan adı değiştiğinde frontend içerik fallback ile çalışmaya devam ederken JSON-LD boş kalabilir. Bu nedenle API contract ve schema contract testleri birlikte kullanılmalıdır. Server render çıktısını production benzeri ortamda doğrulamak özellikle önemlidir.

CMS Veri Modeli

CMS veri modeli structured data için gerekli gerçek alanları açıkça taşımalıdır. SEO ekibinin ihtiyaç duyduğu veriyi frontend metninden tahmin etmek yerine model içinde saklamak daha güvenlidir. Author, date, product brand veya event location gibi alanlar typed olabilir. Validation CMS giriş seviyesinde başlayabilir. Böylece bozuk veri frontend'e ulaşmadan engellenir.

Frontend Template

Frontend template görünür içerik ile schema generator arasında koordinasyon noktasıdır. İki çıktı aynı domain object kullanırsa parity korunur. Ayrı query veya transform mantıkları duplication oluşturabilir. Template test aynı fixture üzerinden hem DOM hem JSON-LD render etmelidir. Contract assertion iki sonucu karşılaştırabilir.

API

API alan isimleri ve veri türleri schema generator için bağımlılıktır. Breaking change release edilmeden consumer contract test çalıştırılabilir. Optional alanlar için fallback kuralları açık olmalıdır. Null değeri sahte veriyle doldurmak yerine uygun schema davranışı seçilmelidir. API versioning structured data üzerindeki etkileri de kapsamalıdır.

Schema Generator

Schema generator görünür içerikten ayrı bir SEO script'i gibi değil domain modelinin serializer katmanı gibi tasarlanabilir. Type-safe fonksiyonlar belirli template için izin verilen entity'leri üretir. Required alan eksikse kontrollü hata verebilir. Unit test her generator için fixture setini doğrular. Böylece schema kodu sürdürülebilir yazılım bileşenine dönüşür.

Server Render

Server render structured data'nın ilk HTML içinde bulunmasını sağlayabilir. Bu özellikle kritik Product bilgileri için daha öngörülebilir bir yaklaşım sunar. Ancak server ile client data farklıysa hydration sonrası çelişki oluşabilir. Source ve rendered HTML karşılaştırılmalıdır. SSR testleri gerçek production data shape'iyle çalışmalıdır.

Veri Kaynakları Arasında Contract Test

CMS, commerce API ve frontend arasında ortak veri sözleşmesi tanımlamak schema regresyonlarını azaltır. Contract test alanın varlığını, veri tipini ve business anlamını kontrol eder. Örneğin price alanının vergi dahil mi hariç mi olduğu yalnızca sayı tipiyle anlaşılmaz. Bu semantic anlam dokümante edilmelidir. Schema generator bu contract'ın tüketicilerinden biri olarak ele alınmalıdır.

JavaScript ile Üretilen Structured Data Nasıl Test Edilir?

JavaScript ile üretilen structured data testinde source HTML ve rendered HTML arasındaki farkı görmek gerekir. Client-side injection doğru çalışıyorsa markup render sonrasında ortaya çıkabilir. Ancak API hatası, hydration problemi veya runtime exception structured data'nın tamamen kaybolmasına yol açabilir. Google Rich Results Test ve URL Inspection bu nedenle değerli ek kontrollerdir. Kritik e-ticaret markup'ında mümkün olduğunda başlangıç HTML'inde veri sunmak daha dayanıklı bir tasarım sağlayabilir.

Source HTML

Source HTML server'ın ilk gönderdiği içeriği gösterir. JSON-LD burada bulunuyorsa client JavaScript'e bağımlılık azalır. SSR veya SSG kullanan uygulamalarda beklenen schema çoğunlukla kaynakta test edilebilir. Automated crawler script tag varlığını kontrol edebilir. Ancak source doğruluğu rendered DOM testini tamamen gereksiz kılmaz.

Rendered HTML

Rendered HTML JavaScript çalıştıktan sonraki DOM durumunu gösterir. Client-side injected schema yalnızca burada ortaya çıkabilir. Headless browser ile script'ler parse edilip beklenen type kontrol edilebilir. Runtime console error'ları da test sonucuna eklenebilir. Böylece schema kaybının JavaScript hatasından kaynaklanıp kaynaklanmadığı anlaşılır.

Hydration

Hydration server ve client çıktılarının birleştiği hassas aşamadır. Server JSON-LD üretirken client farklı veriyle aynı script'i yeniden yazarsa çelişki oluşabilir. Hydration warning'leri yalnızca UI problemi olarak görülmemelidir. Structured data snapshot source ve post-hydration durumunda karşılaştırılabilir. Aynı entity'nin duplicate üretilmediği kontrol edilmelidir.

Client-Side Injection

Client-side injection bazı mimarilerde gerekli olabilir, fakat runtime bağımlılığı oluşturur. API isteği başarısızsa schema hiç eklenmeyebilir. Bot için özel veya farklı veri üretmekten kaçınılmalıdır. Injection fonksiyonu unit test ile doğrulanabilir. Production render smoke test gerçek davranışı kontrol etmelidir.

Rich Results Test Render

Rich Results Test rendered sayfada Google'ın algıladığı desteklenen structured data hakkında yararlı bilgi sağlayabilir. Client-side markup'ın gerçekten görüldüğünü doğrulamak için kullanılabilir. Ancak tek test URL'si tüm route çeşitliliğini temsil etmez. Template bazlı örnek seti kullanılmalıdır. Sonuç yine production Search gösterim garantisi değildir.

URL Inspection

URL Inspection production sayfasının Google tarafından nasıl erişilip işlendiğini anlamanıza yardımcı olur. Client-side schema testinde Rich Results Test'ten sonra değerli bir kontrol katmanıdır. Crawl ve indexability bilgisi de aynı incelemeye bağlanır. Render edilmiş HTML içinde JSON-LD'nin varlığı kontrol edilebilir. Kritik release'lerde birkaç temsilci URL üzerinde uygulanmalıdır.

JavaScript Hatası Durumunda Schema'nın Kaybolması

Schema yalnızca belirli client component mount olduğunda üretiliyorsa JavaScript hatası tüm markup'ı kaybettirebilir. Bu risk e-ticaret gibi kritik sayfalarda önemlidir. Error boundary UI'ı kurtarsa bile schema script'i oluşmayabilir. End-to-end test runtime exception senaryosunu kapsayabilir. Server-generated markup bu bağımlılığı azaltan seçeneklerden biridir.

React ve Next.js Projelerinde Schema Testleri

React ve Next.js projelerinde structured data üretimi SSR, SSG, CSR ve Server Components gibi farklı render modellerine göre değişebilir. En önemli hedef, route bazında beklenen JSON-LD'nin güvenilir şekilde üretilmesi ve gerçek sayfa verisiyle aynı kaynaktan beslenmesidir. Tekrar kullanılabilir JSON-LD component geliştirmek kod standardizasyonu sağlar. Ancak component'i her sayfaya aynı props ile eklemek doğru değildir. Snapshot, unit ve rendered DOM testleri birlikte kullanıldığında framework güncellemeleri sonrası regression riski azalır.

Server Components

Server Components structured data'yı server tarafındaki gerçek veriyle üretmek için uygun bir nokta olabilir. Client bundle'a gereksiz schema business logic taşımak gerekmez. Data fetching ile JSON-LD aynı component tree içinde koordine edilebilir. Output source HTML üzerinde test edilmelidir. Framework sürümü değiştiğinde render snapshot karşılaştırılabilir.

SSR

SSR her istekte server üzerinde HTML üretir. Structured data gerçek request ve locale bağlamına göre oluşturulabilir. Bununla birlikte personalized veri kullanımına dikkat edilmelidir. Cache katmanı JSON-LD'nin stale kalmasına neden olabilir. Integration test SSR çıktısını gerçek fixture ile doğrulamalıdır.

SSG

SSG build zamanında sayfaları ve structured data'yı üretir. Sık değişmeyen Article sayfaları için uygun olabilir. Fiyat ve stok gibi dinamik alanlarda revalidation stratejisi dikkat gerektirir. Eski static markup kullanıcıya yeni fiyat gösteren client component ile çelişebilir. Test freshness davranışını kapsamalıdır.

CSR

CSR structured data'yı tamamen client tarafında üretirse runtime bağımlılığı artar. JavaScript veya API problemi markup'ın kaybolmasına neden olabilir. Bu nedenle kritik schema için server rendering seçeneği değerlendirilmelidir. CSR kullanılıyorsa rendered DOM end-to-end testi zorunlu hale gelir. Source HTML'nin boş olması bilinen mimari karar olarak belgelenmelidir.

JSON-LD Component

Tekrar kullanılabilir JSON-LD component output escaping ve script üretimini standartlaştırır. Ancak component serbest any veri kabul ederse type güvenliği kaybolur. ProductJsonLd, ArticleJsonLd gibi typed wrapper'lar daha güvenli olabilir. Unit test component'in doğru serialize ettiğini doğrular. User input doğrudan script string içine eklenmemelidir.

Route Bazlı Schema

Her route ailesinin ana entity modeli farklı olabilir. Product route Product, blog route Article ve event route Event contract'ı taşıyabilir. Generic tek schema component içinde onlarca koşul zamanla hata riskini artırır. Route bazlı generator daha okunabilir olabilir. Test matrix route ve fixture kombinasyonlarını kapsamalıdır.

Test Snapshot

Snapshot test beklenen JSON-LD yapısındaki beklenmedik değişiklikleri görünür hale getirir. Yeni property eklenmesi veya eski alanın kaybolması code review sırasında fark edilir. Ancak snapshot'ı her hata çıktığında düşünmeden güncellemek testin değerini yok eder. Diff semantic olarak incelenmelidir. Required field assertion snapshot'tan ayrı tutulmalıdır.

Vue ve Nuxt Projelerinde Schema Testleri

Vue ve Nuxt uygulamalarında SSR, SSG ve head management mekanizmaları structured data üretiminin temel parçaları olabilir. Schema script'inin server ve client tarafında duplicate oluşmaması özellikle kontrol edilmelidir. Hydration sonrası JSON-LD'nin kaybolması veya iki kez eklenmesi regression testle yakalanabilir. Route ve content type bazında farklı schema generator kullanmak model netliği sağlar. Framework plugin'leri güncellendiğinde rendered head snapshot'ı karşılaştırmak yararlıdır.

SSR

Nuxt SSR çıktısında JSON-LD'nin ilk HTML içinde bulunması güvenilirlik açısından avantaj sağlayabilir. Server data fetch işlemi ile schema aynı veri nesnesini kullanmalıdır. Locale ve route parametreleri output'u değiştirebilir. Integration test farklı route fixture'larını render etmelidir. Source HTML parse edilerek script sayısı ve type kontrol edilebilir.

SSG

Static generation içerik sayfalarında hızlı ve stabil schema üretimi sağlar. Ancak dinamik ürün fiyatı gibi veriler build sonrasında eskiyebilir. Revalidation veya client update stratejisi varsa parity korunmalıdır. Static JSON-LD ile dinamik DOM farklı gerçeklik sunmamalıdır. Freshness testi deployment planına eklenmelidir.

Meta/Head Management

Head management kütüphanesi JSON-LD script eklemek için kullanılabilir. Duplicate key veya route geçişlerinde eski script'in kalması SPA davranışında sorun yaratabilir. Client navigation testi bu durumu kontrol etmelidir. Her route değişiminde beklenen structured data seti yeniden doğrulanabilir. Unique key stratejisi önemlidir.

JSON-LD Rendering

JSON-LD rendering güvenli serialization ile yapılmalıdır. Raw HTML injection kullanılıyorsa kullanıcı girdisinin script yapısını bozmadığı test edilmelidir. Framework'ün escaping davranışı sürüm değişikliklerinde incelenmelidir. Snapshot test gerçek final HTML'i kapsamalıdır. Sadece component props test etmek yeterli olmayabilir.

Client–Server Farklılıkları

Server ve client aynı entity için farklı değer üretiyorsa hydration sonrasında schema değişebilir. Fiyat, locale ve kullanıcı durumu bu farkın yaygın nedenleridir. Source ve rendered HTML diff testi problemi ortaya çıkarır. Structured data mümkün olduğunca public canonical sayfa gerçeğini temsil etmelidir. Personalized state'in schema'yı kontrolsüz değiştirmesi önlenmelidir.

Mobil ve Masaüstü Structured Data Parity

Mobil ve masaüstü sürümlerinde ana structured data entity'sinin tutarlı kalması gerekir. Ayrı template sistemleri kullanılıyorsa Product, Article ve diğer kritik bilgiler cihaz bazında kaybolabilir veya farklılaşabilir. Responsive tek HTML kullanan projelerde risk daha düşük olabilir, fakat device detection yapan sistemler ayrıca incelenmelidir. Googlebot Smartphone testleri bu yüzden structured data QA planına dahil edilmelidir. Otomatik mobile-desktop diff yaklaşımı kritik alanların cihazlar arasında eşleşmesini doğrulayabilir.

Aynı Ana Entity

Mobil ve masaüstü aynı canonical URL'yi temsil ediyorsa ana entity de tutarlı olmalıdır. Masaüstünde Product varken mobilde yalnızca WebPage kalması beklenmeyen durumdur. Device-specific rendering kodu bu farkı yaratabilir. Test iki user agent ile sayfayı render edip type setini karşılaştırabilir. Fark varsa intentional olup olmadığı belgelenmelidir.

Aynı Product Bilgileri

Product adı, fiyat, stok ve kimlik bilgilerinin cihazlar arasında çelişmemesi gerekir. Mobil API endpoint'i farklıysa fiyat güncelliği problemi çıkabilir. Aynı backend service kullanmak tutarlılığı artırır. Smoke test iki render çıktısından Product node'larını karşılaştırabilir. Özellikle mobile-first yaklaşım nedeniyle mobil veri kalitesi kritik önemdedir.

Aynı Article Bilgileri

Article headline, author ve tarih alanları mobilde de aynı içeriği temsil etmelidir. Mobil şablon sadeleştirme sırasında author alanı veya JSON-LD script'i kaldırılmamalıdır. Responsive UI ile structured data birbirinden bağımsız test edilmelidir. Source ve rendered output karşılaştırılabilir. Mobile template regression içerik görünürlüğünü de etkileyebilir.

Structured Data'nın Mobilde Kaybolmaması

Mobil optimizasyon sırasında head script'lerinin koşullu olarak çıkarılması structured data kaybına yol açabilir. Bu durum özellikle eski m-dot veya ayrı template mimarilerinde görülür. Device test suite script varlığını ve beklenen type'ı kontrol etmelidir. Production monitoring mobil user agent ile de çalıştırılabilir. Böylece yalnızca masaüstü testine güvenilmez.

Googlebot Smartphone Testi

Googlebot Smartphone perspektifinde sayfanın erişilebilir ve render edilebilir olması kontrol edilmelidir. Structured data'nın render sonucunda görüldüğü doğrulanabilir. robots veya user-agent bazlı davranış farkları varsa ayrıca incelenmelidir. Bot için ayrı içerik üretmekten kaçınılmalıdır. Test gerçek kullanıcı deneyimiyle tutarlı public sayfayı hedeflemelidir.

Mobile–Desktop Diff

Mobile-desktop diff otomasyonu type, property ve kritik value farklarını raporlayabilir. Her fark hata değildir, fakat ana entity farklılığı yüksek öncelikli olabilir. Diff çıktısı allowlist kurallarıyla yönetilebilir. UI'a özgü önemsiz farklar filtrelenebilir. Structured data parity metriği dashboard'a eklenebilir.

Robots ve Indexability Structured Data Testinin Parçası mıdır?

Evet, zengin sonuç hedefi açısından robots ve indexability kontrolleri structured data test sürecinin parçası olarak düşünülmelidir. JSON-LD kusursuz olsa bile Google URL'ye erişemiyor veya sayfa noindex ise arama görünürlüğü gerçekleşmez. HTTP status, canonical, authentication ve robots kuralları production kontrolünde birlikte incelenmelidir. Bu kontroller markup validation değildir, fakat Search eligibility zincirinin temel parçalarıdır. Teknik SEO'nun güçlü tarafı tam da bu katmanları tek süreç içinde değerlendirmesidir.

robots.txt

robots.txt crawl erişimini etkileyebilir. Structured data bulunan sayfanın gerekli kaynaklara ve URL'ye Googlebot erişiminin engellenmediği kontrol edilmelidir. Yanlış wildcard kuralı büyük URL gruplarını etkileyebilir. Staging robots ayarının production'a taşınması bilinen deployment riskidir. Smoke test kritik path'ler için robots politikasını kontrol edebilir.

noindex

noindex sayfanın indekslenmesini engellemek için kullanılan önemli kontroldür. Schema eklemek noindex kararını geçersiz kılmaz. Production deployment sırasında staging noindex etiketi kalırsa rich result hedefi doğal olarak gerçekleşmez. Automated HTML test robots meta içeriğini doğrulayabilir. Bu kontrol kritik landing page'lerde release blocker olabilir.

Authentication

Login arkasındaki sayfaya arama motoru normal kullanıcı gibi erişemeyebilir. Test ortamında authentication gerekli olması Rich Results Test ve crawler sonuçlarını etkileyebilir. Production public URL'lerin yanlışlıkla auth middleware arkasına geçmediği kontrol edilmelidir. HTTP 401 veya 403 structured data sorunundan önce çözülmesi gereken erişim problemidir. Monitoring status code değişikliklerine alarm vermelidir.

HTTP Status

Structured data taşıyan canonical sayfanın başarılı HTTP durumu sunması beklenir. 404, 500 veya redirect loop varsa markup kalitesi ikincil hale gelir. Production smoke test ilk olarak status code kontrol etmelidir. Redirect sonrası final URL'nin schema ve canonical durumu ayrıca incelenebilir. Böylece altyapı hatası schema hatası gibi yorumlanmaz.

Canonical

Canonical Google'a tercih edilen URL hakkında sinyal sağlar. Structured data non-canonical URL üzerinde farklı değer taşıyorsa site genelinde tutarsızlık oluşabilir. Product varyant ve filtre sayfalarında canonical stratejisi özellikle dikkat ister. Schema URL ve mainEntity ilişkileri canonical modelle uyumlu olmalıdır. Test bu değerleri aynı routing helper üzerinden doğrulayabilir.

Googlebot'un Sayfaya Erişebilmesi

Googlebot erişimi zengin sonuç değerlendirmesinin temel ön koşullarındandır. WAF, bot protection veya geo restriction yanlış yapılandırıldığında gerçek kullanıcı erişirken crawler engellenebilir. Log analizi ve URL Inspection bu durumu anlamaya yardımcı olur. Structured data incident araştırmasına crawl erişimi kontrolü eklenmelidir. Sadece markup kodunu değiştirmek böyle bir problemi çözmez.

Schema Doğru, Sayfa noindex İse Ne Olur?

Schema doğru olsa bile sayfa noindex ise structured data tek başına arama görünürlüğü sağlamaz. Bu durum validation ile Search eligibility arasındaki farkı açık biçimde gösterir. Önce sayfanın neden noindex olduğu ve bu kararın intentional olup olmadığı belirlenmelidir. Canonical, HTTP status ve crawl erişimi de aynı inceleme içinde ele alınmalıdır. Teknik SEO kontrollerini bir arada yapmak, “schema çalışmıyor” şeklindeki yanlış teşhisleri azaltır.

Structured Data Tek Başına Yeterli Değildir

Structured data arama motoruna ek anlam sağlar, fakat indeksleme mekanizmasının yerine geçmez. Sayfa erişilemiyorsa veya indekslenmeye uygun değilse markup'ın rich result üretmesini beklemek doğru değildir. Bu nedenle test planı HTML script kontrolüyle bitmemelidir. Crawl, render ve indexability birlikte değerlendirilmelidir. SEO başarısı birden fazla teknik katmanın ortak sonucudur.

Indexability

Indexability teknik SEO'nun temel kontrol alanıdır. noindex, canonical veya başka sinyaller URL'nin arama sonuçlarındaki durumunu etkileyebilir. Structured data dashboard'una indexability flag eklemek debugging süresini azaltır. Invalid schema ile non-indexable URL aynı kategoriye konulmamalıdır. Her problem farklı owner ve çözüm gerektirir.

Canonical

Canonical başka URL'yi işaret ediyorsa Google farklı sayfayı tercih edebilir. Bu durumda test edilen URL'nin schema'sı doğru olsa bile arama sonucu başka canonical üzerinden değerlendirilir. Duplicate product URL'lerinde bu durum yaygındır. URL Inspection canonical seçimini anlamaya yardımcı olur. Structured data analizinde canonical bilgisi bu yüzden mutlaka görülmelidir.

Search Eligibility

Search eligibility yalnızca structured data validation'dan oluşmaz. İndekslenebilirlik, içerik kalitesi ve feature desteği gibi farklı koşullar birlikte rol oynar. Bu nedenle “Rich Results Test geçti” ifadesi bütün Search eligibility sürecinin tamamlandığı anlamına gelmez. Production monitoring ek katmanları izler. KPI'lar da yalnızca validator başarı oranına bağlanmamalıdır.

Teknik SEO Kontrollerini Birleştirmek

En iyi debugging yaklaşımı schema, indexability, canonical, HTTP status ve render kontrollerini tek raporda birleştirmektir. Böylece mühendis sorunun hangi katmanda olduğunu hızlıca görür. Büyük sitelerde crawler çıktısı bu bilgileri URL bazında tabloya dönüştürebilir. Dashboard filtreleri template ve error type üzerinden çalışabilir. Teknik SEO operasyonu böylece daha ölçülebilir hale gelir.

Search Console ile Structured Data Monitoring

Search Console, production ortamındaki structured data durumunu uzun vadede izlemek için önemli sinyaller sunar. Geçerli ve geçersiz öğelerdeki trendler, URL örnekleri ve bazı Search appearance verileri regression tespitinde kullanılabilir. Ancak Search Console anlık CI testi değildir ve değişikliklerin raporlara yansıması zaman alabilir. Bu nedenle release öncesi testlerin yerine geçmez. En iyi model CI/CD kontrollerini Search Console production gözlemiyle birleştirmektir.

Geçerli Öğeler

Geçerli öğe sayısı zaman içindeki structured data kapsamını anlamaya yardımcı olabilir. Ani düşüş template regression veya feature reporting değişikliğine işaret edebilir. Tek başına sayı yeterli değildir. Site büyümesi ve URL sayısı bağlamında oran olarak da izlenmelidir. Template bazlı internal dashboard ek ayrıntı sağlar.

Geçersiz Öğeler

Geçersiz öğelerde artış release sonrası incident sinyali olabilir. URL örnekleri root cause araştırması için başlangıç noktasıdır. Hatanın tekil veri mi yoksa global template problemi mi olduğu ayrıştırılmalıdır. Etkilenen URL sayısı incident önceliğini belirlemeye yardımcı olur. Fix sonrası validation süreci izlenmelidir.

Warning Trendleri

Warning trendleri doğrudan kritik hata olmasa bile veri kalitesindeki bozulmayı gösterebilir. Recommended property kaybı yeni API sürümüyle başlamış olabilir. Trend release timeline ile karşılaştırılmalıdır. Warning oranı template bazında tutulduğunda sorun kaynağı daha hızlı bulunur. Her warning'in business value puanı farklı olabilir.

URL Örnekleri

Search Console tarafından sunulan URL örnekleri sorunu yeniden üretmek için değerlidir. Ancak yalnızca örnek URL'leri manuel düzeltmek yeterli değildir. Template veya veri modeli ortaksa tüm grup etkilenebilir. Örnek URL staging fixture'a dönüştürülebilir. Böylece aynı gerçek dünya hatası regression test setine eklenir.

Fix Validation

Production düzeltmesinden sonra validation süreci sorunun giderildiğini Google'a bildirmek ve yeniden değerlendirme akışını takip etmek için kullanılabilir. Önce düzeltme birkaç representative URL'de doğrulanmalıdır. Ardından deployment tamamlanır. Validation başlatıldıktan sonra yeniden tarama ve rapor değişimi izlenir. Tekrar eden hata varsa root cause analizine geri dönülmelidir.

Search Appearance Verileri

Uygun Search appearance verileri rich result performansını anlamada yardımcı olabilir. Impression, click ve CTR teknik sağlık metrikleriyle birlikte değerlendirilmelidir. Gösterim düşüşü her zaman schema hatası anlamına gelmez. Google feature değişikliği veya sorgu davranışı da etkili olabilir. Bu nedenle performans ve validation verileri aynı dashboard'da fakat ayrı metrik olarak tutulmalıdır.

Search Console'daki “Düzeltmeyi Doğrula” Süreci

“Düzeltmeyi doğrula” süreci bir hatayı gizlemek için değil, gerçek kök neden düzeltildikten sonra Google'ın yeniden değerlendirmesini takip etmek için kullanılmalıdır. Önce hata birkaç URL üzerinde yeniden üretilmeli ve template, API veya veri kaynağı seviyesinde düzeltilmelidir. Production deploy sonrasında temsilci sayfalar tekrar test edilir. Ardından validation başlatılır ve yeniden tarama süreci izlenir. Aynı problem geri dönüyorsa regression test eksikliği de postmortem konusu olmalıdır.

Hatanın Kök Nedenini Düzeltmek

Kök neden template kodu, API alanı, CMS verisi veya plugin çakışması olabilir. Sadece Search Console'da listelenen URL'nin HTML'ini elle değiştirmek ölçeklenebilir çözüm değildir. Sorunun ortak pattern'i belirlenmelidir. Fix ortak katmanda uygulanmalıdır. Regression testi aynı hatanın tekrarını engellemelidir.

Birkaç URL'de Test Etmek

Fix sonrasında farklı veri durumlarını temsil eden birkaç URL test edilmelidir. Normal örnek tek başına yeterli olmayabilir. Edge case ürün veya eski içerik ayrıca seçilebilir. Rich Results Test ve internal parity test birlikte çalıştırılabilir. Böylece production'a geçmeden kapsam hakkında güven artar.

Production Deploy

Production deploy sonrasında gerçek veri ve cache davranışı kontrol edilmelidir. Staging'de bulunmayan CDN veya environment farkları output'u etkileyebilir. Kritik URL smoke test otomatik çalışmalıdır. Build ID ile schema test sonucu ilişkilendirilebilir. Hata varsa rollback kararı hızlı verilebilir.

Validation Başlatmak

Validation, production fix gerçekten yayınlandıktan ve örnek URL'ler kontrol edildikten sonra başlatılmalıdır. Henüz deployment tamamlanmadan doğrulama başlatmak süreci gereksiz uzatabilir. Incident kaydına validation başlangıç tarihi eklenebilir. Search Console durumu düzenli takip edilir. Ekip sonucu manuel hatırlamaya bırakmamalıdır.

Google Yeniden Tarama Süreci

Google'ın URL'leri yeniden taraması anlık olmak zorunda değildir. Bu nedenle validation sonucunun hemen değişmemesi fix'in başarısız olduğu anlamına gelmez. Internal smoke test production doğruluğunu daha hızlı teyit eder. Search Console zaman içindeki Google gözlemini sağlar. İki zaman ölçeğini birbirinden ayırmak gerekir.

Tekrar Eden Hataları İzlemek

Aynı structured data hatası birkaç release sonra geri geliyorsa süreç problemi vardır. Incident yalnızca kapatılmamalı, test boşluğu da analiz edilmelidir. Fixture, contract veya snapshot testi eklenebilir. Regression sayısı KPI olarak izlenebilir. Sürekli tekrar eden hata teknik borç önceliğini yükseltmelidir.

Rich Result Kaybolduğunda Nasıl Debug Yapılır?

Rich result kaybolduğunda ilk refleks JSON-LD'yi baştan yazmak olmamalıdır. Önce schema'nın sayfada hâlâ bulunup bulunmadığı, Google'ın feature desteğinin devam edip etmediği ve required property kurallarının değişip değişmediği kontrol edilmelidir. Ardından content-schema parity, noindex, canonical ve manual action durumları incelenir. Tüm teknik kontroller doğru olsa bile Google belirli sorguda zengin görünümü göstermemeyi seçebilir. Sistematik checklist, rastgele kod değişikliklerinden daha hızlı sonuç verir.

Schema Hâlâ Sayfada mı?

İlk kontrol structured data'nın gerçekten production HTML'de bulunup bulunmadığıdır. Tema veya component güncellemesi script'i kaldırmış olabilir. Source ve rendered HTML birlikte incelenmelidir. Beklenen @type bulunmuyorsa release diff'e bakılır. Bu kontrol birkaç dakika içinde önemli bir problem sınıfını eler.

Google Desteği Devam Ediyor mu?

Feature lifecycle değişikliği zengin görünüm kaybının doğrudan nedeni olabilir. FAQ rich result'ın 2026'da kaldırılması bunun güncel bir örneğidir. Schema'yı değiştirerek kaldırılmış özelliği geri getirmeye çalışmak sonuç vermez. Güncel Search Central dokümantasyonu kontrol edilmelidir. Registry status alanı hızlı cevap sağlamalıdır.

Required Property Değişti mi?

Google dokümantasyonu zamanla property gereksinimlerini güncelleyebilir. Daha önce valid olan yapı yeni required veya farklı kullanım kuralıyla sorun yaşayabilir. Documentation update takibi bu yüzden önemlidir. Rule set sürümü güncellenmelidir. CI testleri yeni beklentiyi tüm fixture'larda doğrulamalıdır.

İçerik–Schema Uyumu Bozuldu mu?

Frontend redesign görünür fiyat veya tarih kaynağını değiştirmiş, JSON-LD eski kaynağı kullanmaya devam etmiş olabilir. Validator bunu her zaman fark etmeyebilir. Content parity testi devreye girer. Release timeline ile mismatch başlangıcı karşılaştırılır. Aynı source of truth'a dönüş kalıcı çözüm olabilir.

noindex veya Canonical Değişti mi?

SEO meta ayarındaki küçük değişiklik rich result görünümünden daha büyük indeksleme sorununa yol açabilir. noindex veya yanlış canonical deployment sonrası kontrol edilmelidir. CMS plugin güncellemesi bu alanları değiştirmiş olabilir. URL Inspection faydalı bilgi sağlar. Structured data debugging her zaman indexability kontrolünü içermelidir.

Manual Action Var mı?

Search Console Manual Actions alanı politika problemi ihtimalinde kontrol edilmelidir. Teknik validation başarısı manual action olmadığı anlamına gelmez. Fake review veya yanıltıcı structured data gibi kullanımlar farklı kalite boyutuna sahiptir. Sorun varsa politika kapsamında gerçek içerik ve markup düzeltilmelidir. Yalnızca property ekleyip çıkarmak yeterli olmayabilir.

Google Algoritmik Olarak Göstermiyor Olabilir mi?

Tüm teknik ve politika kontrolleri doğru olsa bile rich result her sorguda görünmeyebilir. Eligibility, actual appearance garantisi değildir. Google arama deneyimine göre farklı sunum tercih edebilir. Bu durumda gereksiz kod değişikliklerinden kaçınılmalıdır. Search Console impression trendleri ve gerçek sorgu örnekleri birlikte değerlendirilmelidir.

Google Search Feature Değişiklikleri Nasıl İzlenmeli?

Structured data desteği yaşayan bir sistemdir ve düzenli dokümantasyon takibi gerektirir. Search Documentation Updates, desteklenen structured data listesi, deprecation bildirimleri ve property değişiklikleri periyodik olarak incelenmelidir. Her ekipte bu işi yapan belirli bir schema governance owner bulunması sürecin unutulmasını engeller. Değişiklik bulunduğunda registry, test rule set'i ve release checklist birlikte güncellenmelidir. Böylece güncelliğini kaybetmiş SEO tavsiyeleri production kodunda yıllarca yaşamaz.

Search Documentation Updates

Google Search dokümantasyon güncelleme sayfası önemli değişiklikleri takip etmek için doğrudan kaynaklardan biridir. Structured data feature kaldırmaları veya yeni property desteği burada duyurulabilir. Takip manuel yapılabilir veya feed üzerinden otomatik bildirim oluşturulabilir. Önemli değişiklikler internal ticket'a dönüştürülmelidir. Sadece SEO ekibinin okuması yerine development owner da bilgilendirilmelidir.

Supported Structured Data Gallery

Desteklenen structured data listesi yeni bir schema projesine başlamadan önce kontrol edilmelidir. Buradaki bilgiler Google Search feature hedefi açısından Schema.org type listesinden daha anlamlıdır. Yeni bir type görür görmez implementation başlatmak yerine gerekli property ve politika kuralları okunmalıdır. Registry kayıtları bu listeyle periyodik karşılaştırılabilir. Kaldırılan feature'lar alarm üretebilir.

Deprecation

Deprecation bildirimi teknik borç planlaması için erken uyarıdır. Feature tamamen kaldırılmadan önce yeni yatırım durdurulabilir. Etkilenen URL ve template sayısı hesaplanabilir. Gerekirse schema kaldırma veya alternatif search feature migration planı hazırlanır. Search Console rapor değişiklikleri de aynı plan içinde değerlendirilmelidir.

New Required Fields

Yeni required field eklenmesi doğrudan eligibility etkisi yaratabilir. Registry rule set'i güncellenmeli ve tüm fixture'lar yeniden çalıştırılmalıdır. Gerçek veri modelinde alan yoksa product veya content ekibiyle çalışma gerekebilir. Sahte fallback üretmek yerine doğru veri kaynağı oluşturulmalıdır. Migration release planına bağlanmalıdır.

New Recommended Fields

Yeni recommended field değişikliği daha düşük aciliyetle ele alınabilir. Önce iş değeri ve veri kullanılabilirliği değerlendirilir. Veri kolay erişilebiliyorsa generator genişletilebilir. Yoksa backlog maddesi olarak izlenebilir. Warning politikasının amacı bu tür değişiklikleri yönetilebilir hale getirmektir.

Schema Governance Owner

Schema governance owner feature yaşam döngüsü, registry ve test rule set koordinasyonunu yürütür. Bu rol tek kişinin her kodu yazması anlamına gelmez. SEO, development ve QA arasında sorumluluk paylaşımını düzenler. Dokümantasyon değişikliklerinin unutulmamasını sağlar. Büyük ekiplerde rol bir çalışma grubu şeklinde de yürütülebilir.

Schema Deprecation Alarmı

Schema deprecation alarmı, Google Search feature değişikliklerinin production markup üzerindeki etkisini sistematik biçimde takip etmeyi amaçlar. Önce kullanılan type envanteri oluşturulur, ardından her type için Google feature status ve son değişiklik tarihi tutulur. Bir feature deprecated veya removed durumuna geçtiğinde etkilenen URL sayısı hesaplanır. Migration gereksinimi varsa owner'a görev atanır. Search Console rapor değişiklikleri de alarmın kapsamına dahil edilirse deprecation süreci daha kontrollü yönetilir.

Kullanılan Type'ların Envanteri

Envanter olmadan hangi feature değişikliğinin sizi etkilediğini bilmek zordur. Crawler site genelindeki JSON-LD type'larını çıkarabilir. Template bilgisiyle birleştirildiğinde kapsam netleşir. Kullanılmayan eski type'lar da bu süreçte görünür hale gelir. Envanter düzenli olarak yenilenmelidir.

Google Feature Status

Her type için Google feature status ayrı tutulmalıdır. Active, Limited, Deprecated veya Removed gibi değerler kullanılabilir. Type vocabulary içinde varlığını sürdürse bile Google feature removed olabilir. Bu ayrım raporda açıkça görünmelidir. Status değişikliği otomatik bildirim tetikleyebilir.

Değişiklik Tarihi

Feature değişiklik tarihi migration önceliğini ve geçmiş analizini kolaylaştırır. Trafik veya Search appearance düşüşü aynı zamanla karşılaştırılabilir. Dokümantasyon güncellemesinin tarihi internal kayıtla birlikte tutulabilir. Böylece aylar sonra neden karar alındığı anlaşılır. Teknik yönetişim için küçük ama değerli bir alandır.

Etkilenen URL Sayısı

Bir feature değişikliğinin etkisi tek URL veya milyonlarca URL olabilir. Crawl veya template inventory üzerinden etkilenen kapsam hesaplanmalıdır. URL sayısı business impact ile birlikte önceliklendirme sağlar. Büyük sayı otomatik olarak yüksek gelir etkisi anlamına gelmez. Template trafik verisiyle birlikte değerlendirmek daha doğrudur.

Migration Gereksinimi

Her removed feature markup'ın hemen tamamen silinmesini gerektirmeyebilir. Schema başka semantic tüketiciler için hâlâ değer taşıyabilir. Ancak yalnızca kaldırılmış Google görünümü için tutulan kod teknik borç haline gelebilir. Migration kararı amaç bazında verilmelidir. Test ve monitoring sistemi yeni duruma göre güncellenmelidir.

Search Console Rapor Değişiklikleri

Feature kaldırıldığında Search Console raporları veya Rich Results Test davranışı da değişebilir. Monitoring dashboard bu değişikliği gerçek incident sanmamalıdır. Feature lifecycle bilgisi alert sistemiyle ilişkilendirilebilir. Böylece beklenen rapor kaybı için gereksiz acil durum açılmaz. Governance ile observability burada doğrudan birleşir.

Schema Testleri CI/CD'ye Nasıl Eklenir?

Schema testlerini CI/CD'ye eklemek structured data'yı manuel SEO kontrolünden gerçek yazılım kalite sürecine taşır. Pull request sırasında JSON parse, type validation, required field, snapshot ve content contract testleri çalıştırılabilir. Staging ortamında rendered DOM ve route testleri yapılır. Production deployment sonrasında smoke test kritik URL'leri yeniden kontrol eder. Regression monitoring ise Search Console ve internal crawler verileriyle sürecin devamlılığını sağlar.

Pull Request

Pull request aşaması en ucuz hata yakalama noktalarından biridir. Generator unit testleri ve fixture kontrolleri burada çalıştırılmalıdır. Required property kaybı merge'i bloklayabilir. Snapshot diff reviewer tarafından incelenir. Böylece schema değişikliği kod review'da görünür hale gelir.

Build

Build aşamasında route veya static output üretilebiliyorsa final JSON-LD parse edilebilir. Environment değerlerinin yanlış host oluşturmadığı kontrol edilir. Build artifact içindeki script sayısı ve type seti doğrulanabilir. Büyük projelerde yalnızca representative template'ler yeterli olabilir. Kritik hata build'i başarısız kılmalıdır.

Test

Test aşaması unit, contract ve DOM kontrollerini bir araya getirebilir. Her test aynı problemi tekrar etmek zorunda değildir. Unit test generator logic, contract test veri ilişkisi ve end-to-end test gerçek render davranışını hedefler. Test pyramid structured data için de uygulanabilir. En yavaş testler kritik path'lere odaklanmalıdır.

Staging

Staging gerçek uygulama entegrasyonunu doğrular. CMS, API ve frontend birlikte çalışırken JSON-LD'nin doğru oluştuğu kontrol edilir. Mobile rendering ve error page senaryoları denenebilir. Authentication nedeniyle dış araç erişemiyorsa internal headless browser kullanılabilir. Staging verisinin production davranışını yeterince temsil etmesi önemlidir.

Production

Production kontrolü gerçek deployment artifact ve gerçek veri üzerinde yapılır. Kritik URL listesi 200 status, expected type, required property ve parity açısından test edilir. Hata release ile ilişkilendirilir. Gerekirse rollback mekanizması çalıştırılır. Bu kontrol Search Console'dan daha hızlı erken uyarı sağlar.

Post-Deploy Validation

Post-deploy validation birkaç dakika içinde schema regression tespit edebilir. Site geneline tam crawl yapmak şart değildir. Trafik ve risk bazlı temsilci URL seti yeterli başlangıç olabilir. Sonuç Slack, e-posta veya monitoring sistemine gönderilebilir. Kritik error production incident açabilir.

Regression Monitoring

Regression monitoring yalnızca deploy anını değil zaman içindeki bozulmaları da yakalar. CMS veri değişikliği veya üçüncü taraf app update'i release olmadan schema'yı etkileyebilir. Periyodik crawl bu nedenle değerlidir. Error ve warning trendleri dashboard'a aktarılabilir. Schema health score zaman içinde izlenebilir.

Pull Request Aşamasında Schema Testleri

Pull request seviyesinde schema testleri hızlı, deterministik ve geliştiriciye doğrudan geri bildirim veren kontroller olmalıdır. JSON parse, type validation, required field, snapshot ve content contract testleri burada yüksek değer sağlar. Test başarısız olduğunda hata mesajı yalnızca “schema invalid” demek yerine hangi fixture ve hangi property'nin bozulduğunu göstermelidir. Böylece geliştirici sorunu Search Console'a çıkmadan düzeltir. Merge blocker politikası yalnızca gerçekten kritik kurallar için uygulanmalıdır.

JSON Parse

Her fixture generator çıktısı standart JSON parser ile okunmalıdır. Parse edilemiyorsa test anında fail olur. Bu kontrol çok hızlı olduğu için bütün schema fixture'larında çalıştırılabilir. Error mesajı mümkünse bozuk output'un ilgili bölümünü göstermelidir. Serializer kullanımı parse hatalarının önemli bölümünü zaten önler.

Type Validation

Type validation route için beklenen @type değerinin bulunduğunu doğrular. Product fixture'da Product kaybolursa test hemen kırılır. Unexpected type sayısı ayrıca warning olabilir. Graph yapısında her node ayrı kontrol edilir. Typed model compile-time güvenlik sağlayarak testi destekler.

Required Field Test

Required field test feature rule set'ine göre gerekli property'leri kontrol eder. Rule set'in güncel Google dokümantasyonuyla senkron tutulması önemlidir. Missing field doğrudan anlaşılır hata üretmelidir. Null ve empty string de eksik kabul edilecekse kural açık olmalıdır. Test business fixture ile birlikte çalışmalıdır.

Snapshot Test

Snapshot beklenmeyen yapısal değişiklikleri ortaya çıkarır. Yeni property eklenmesi bazen istenen değişikliktir ve reviewer onayıyla snapshot güncellenir. Kaybolan alan veya duplicate node ise regression olabilir. Snapshot diff okunabilir formatta tutulmalıdır. Körü körüne kabul edilmemelidir.

Content Contract Test

Content contract test DOM veya view model ile JSON-LD arasındaki kritik değerleri karşılaştırır. Fiyat, stok, headline veya tarih gibi alanlar uygun adaylardır. Unit seviyesinde aynı domain object üzerinden assertion yapılabilir. End-to-end seviyede gerçek DOM parse edilebilir. Bu test semantic yanlışları syntax testinden önce yakalayabilir.

Test Başarısızsa Merge'i Bloklamak

Merge blocker kuralları ekip tarafından önceden bilinmelidir. Parse error, missing required field ve kritik content mismatch çoğu projede güçlü blocker adaylarıdır. Recommended warning ise yalnızca raporlanabilir. Böylece pipeline kullanılabilir kalır. Fazla agresif blocker sistemi zamanla geliştiricilerin testleri devre dışı bırakmasına neden olabilir.

Staging Ortamında Schema Testleri

Staging structured data testleri gerçek template render davranışını production öncesinde görme fırsatı verir. Rendered DOM, route, template, mobile, error page, canonical ve test data fixture kontrolleri bu aşamada yapılabilir. Internal CMS ve API entegrasyonları birlikte çalıştığı için unit testte görünmeyen problemler burada ortaya çıkar. Staging'in tamamen sahte ve tek tip veriyle dolu olması edge case hatalarını saklayabilir. Bu yüzden kontrollü test fixture kayıtları staging ortamında da bulunmalıdır.

Rendered DOM

Headless browser ile sayfa render edilip JSON-LD script'leri parse edilebilir. Client-side injection ve hydration sorunları böylece görünür olur. Console error'ları test raporuna eklenebilir. Source ile rendered type seti karşılaştırılabilir. Kritik farklar release'i durdurabilir.

Route Test

Her ana route ailesi en az bir örnek URL ile test edilmelidir. Product, article, category ve event gibi template'lerin beklenen schema contract'ı farklıdır. Route mapping yanlışsa generic schema tüm sayfalara uygulanabilir. Automated test route ile expected type eşleşmesini doğrular. Dynamic parameter edge case'leri ayrıca eklenebilir.

Template Test

Template test aynı sayfa türündeki farklı veri durumlarını kapsar. Product template için indirimli ve stoksuz fixture örnektir. Article için yazar değişimi veya eksik görsel senaryosu bulunabilir. Tek happy path test gerçek kapsama sahip değildir. Fixture seti production incident'lerinden öğrenilerek büyütülmelidir.

Mobile Test

Mobil viewport ve gerekiyorsa mobile user agent ile render yapılmalıdır. Structured data script'i cihaz bazında kaybolmamalıdır. Responsive DOM farklılıkları parity sorununa yol açmamalıdır. Mobile-first indexing bağlamı nedeniyle bu kontrol önemlidir. Desktop ile semantic diff raporlanabilir.

Error Pages

404 ve 500 sayfalarında yanlışlıkla Product veya Article schema kalmaması kontrol edilmelidir. Generic layout global entity'ler üretebilir, fakat ana content schema olmamalıdır. Error route yanlış status ile 200 dönüyorsa ayrı SEO problemi vardır. Test status code ve type setini birlikte doğrular. Soft 404 benzeri durumlar ayrıca incelenebilir.

Canonical

Staging canonical değerinin production domain'i hedefleyip hedeflememesi ortam stratejisine bağlıdır. Önemli olan production deploy sırasında staging hostname kalmamasıdır. Schema URL ve canonical değerleri birlikte test edilebilir. Varyant ve pagination senaryolarında özel kurallar uygulanır. Route helper'ların ortak kullanımı hata ihtimalini azaltır.

Test Data Fixtures

Staging fixture kayıtları gerçek edge case'leri sürekli yeniden üretmenizi sağlar. İndirimli ürün, reviewsuz ürün veya ertelenmiş event gibi kayıtlar değişmeden tutulabilir. QA ekibi aynı URL'leri her release'te kullanır. Otomasyon bu fixture ID'leriyle çalışır. Böylece random production verisine bağımlılık azalır.

Production Sonrası Otomatik Schema Smoke Test

Production smoke test, deployment tamamlandıktan hemen sonra kritik URL'lerin temel structured data sağlığını kontrol eder. Tüm siteyi taramak yerine yüksek trafik alan veya business açısından kritik template örnekleri seçilir. JSON-LD varlığı, beklenen @type, required property, HTTP status ve content parity temel kontrollerdir. Kritik hata varsa alert üretilir. Bu yaklaşım schema regression'ının Search Console'a yansımasını beklemeden müdahale etmenizi sağlar.

Kritik URL'leri Seçmek

URL seçimi trafik, gelir, template ve risk bilgisine göre yapılabilir. Ana ürün, kategori ve içerik template'lerinden temsilci sayfalar bulunmalıdır. Edge case fixture URL'leri de listeye eklenebilir. Set çok büyürse smoke test yavaşlar. Derin crawl ayrı periyodik job olarak çalıştırılabilir.

JSON-LD Var mı?

İlk kontrol sayfada beklenen JSON-LD script'inin bulunup bulunmadığıdır. Script tamamen kaybolduysa daha detaylı property testine gerek kalmadan kritik hata üretilebilir. Birden fazla script normal olabilir. Hedef type'ın bulunduğu node seçilmelidir. Duplicate script sayısı ayrıca takip edilebilir.

Beklenen @type Var mı?

Route için beklenen ana @type production'da doğrulanmalıdır. Product URL'sinde Product yoksa deployment problemi olabilir. Yanlış type görünüyorsa routing veya CMS template mapping incelenir. Test yalnızca script varlığını kontrol etmekten daha anlamlı hale gelir. Graph içindeki nested type'lar doğru şekilde ayrıştırılmalıdır.

Required Property'ler Var mı?

Production gerçek veri bazı required alanları boş bırakabilir. Fixture testleri bunu her zaman yakalayamaz. Bu nedenle smoke test canlı URL'deki required property'leri yeniden kontrol eder. Null, empty ve invalid type durumları değerlendirilir. Kritik eksiklik alert üretir.

Sayfa 200 Dönüyor mu?

HTTP status structured data testinin ön koşullarından biridir. Kritik ürün URL'si 500 dönüyorsa schema validation ikincil kalır. Smoke test final redirect zincirini de inceleyebilir. Beklenmeyen redirect varsa canonical ve schema URL davranışı kontrol edilir. Status check sistem sağlığına ek katkı sağlar.

Content Parity

Smoke testte DOM ve JSON-LD arasındaki birkaç kritik alan karşılaştırılabilir. Tüm property'leri kontrol etmek zorunlu değildir. Fiyat, stok veya headline gibi yüksek riskli alanlar yeterli başlangıçtır. Bu test production API ve cache farklarını yakalar. Mismatch oranı zaman içinde KPI olarak izlenebilir.

Alert

Alert yalnızca gerçekten aksiyon gerektiren durumlarda üretilmelidir. Her recommended warning için gece alarmı göndermek sistemi kullanılmaz hale getirir. Severity modeli critical, warning ve info gibi seviyelere ayrılabilir. Alert içinde URL, template, property ve son release bilgisi bulunmalıdır. Böylece incident sahibi hızlıca root cause araştırmasına başlayabilir.

Test Fixture Nedir?

Test fixture, belirli bir structured data senaryosunu sürekli ve tekrarlanabilir biçimde test etmek için kullanılan kontrollü örnek veridir. Gerçek production verisini rastgele seçmek yerine normal ürün, indirimli ürün, stoksuz ürün, reviewsuz ürün, event ve article gibi sabit örnekler oluşturulur. Her fixture'ın beklenen output'u veya contract kuralları bulunur. Yeni production incident yaşandığında ilgili edge case fixture setine eklenebilir. Böylece test kapsamı gerçek hatalardan öğrenerek zaman içinde güçlenir.

Örnek Ürün

Örnek ürün temel Product schema sözleşmesini temsil eder. Tüm standart alanları doğru ve eksiksiz içerir. Unit ve integration testlerinin başlangıç noktasıdır. Bu fixture değişken olmamalı ve test amacı dışında editlenmemelidir. Beklenen JSON-LD snapshot ile birlikte saklanabilir.

İndirimli Ürün

İndirimli ürün kampanya logic'ini test eder. Aktif ve eski fiyat ayrımı net biçimde modellenmelidir. Campaign expiry zamanı simüle edilebilir. DOM ve structured data fiyatı aynı business rule'u takip etmelidir. Boundary time testleri bu fixture üzerinden çalıştırılabilir.

Stokta Olmayan Ürün

Stoksuz fixture availability mapping'i doğrular. Satın alma butonu ve JSON-LD aynı durumu göstermelidir. Cache veya fallback kodu yanlışlıkla InStock üretmemelidir. Inventory policy özel durumları ayrıca eklenebilir. Production'a yakın gerçek veri şekli kullanılmalıdır.

Review'suz Ürün

Reviewsuz fixture rating ve review alanlarının yanlış varsayılan üretmediğini test eder. Zero count senaryosu açık biçimde modellenmelidir. AggregateRating gereksiz yere eklenmemelidir. UI'da review bölümü yoksa parity korunmalıdır. Fake rating önleme açısından değerli bir fixture'dır.

Event

Event fixture tarih, timezone, location ve status alanlarını test eder. Normal aktif etkinliğe ek olarak iptal veya erteleme fixture'ları bulunabilir. Start ve end tarih ilişkisi doğrulanır. Location verisi gerçek formatı temsil eder. Offers varsa ayrıca ticketing senaryosu test edilir.

Article

Article fixture headline, author, date ve publisher sözleşmesini doğrular. İlk yayın ve daha sonra güncellenmiş içerik için iki fixture oluşturulabilir. dateModified deploy zamanından bağımsız tutulur. Author entity ilişkisi kontrol edilir. Görsel eksikliği gibi edge case ayrıca eklenebilir.

Her Template İçin Minimum Örnek Seti

Her template için tek fixture yerine minimum temsilci set belirlemek daha güçlü kapsama sağlar. Happy path yanında en az birkaç yüksek riskli edge case seçilmelidir. Set sürekli büyümek zorunda değildir. En çok incident üreten durumlar önceliklendirilir. Böylece test süresi ile kapsama arasında dengeli model kurulur.

Schema Contract Test Yaklaşımı

Schema contract test, her template'in hangi entity ve property yapısını üretmesi gerektiğini kodlanabilir kurallara dönüştürür. Product template için Product ve Offer, Article için headline ve author, Event için tarih ve location gibi beklentiler açık şekilde tanımlanır. API veya CMS modeli değiştiğinde contract kırılırsa test hata verir. Bu yaklaşım schema output'unu rastgele JSON olarak değil public teknik sözleşme olarak ele alır. Büyük ekiplerde özellikle API değişikliğinin SEO katmanını fark edilmeden bozmasını önlemek için değerlidir.

Product Template Contract

Product contract beklenen Product type, temel kimlik alanları ve offer yapısını tanımlar. Variant senaryoları ayrı rule set taşıyabilir. Required property ve content parity kuralları aynı contract'a bağlanabilir. API price alanı değişirse test kırılır. Böylece e-ticaret regression'ları erken yakalanır.

Article Template Contract

Article contract headline, author, dates, publisher ve main entity ilişkilerini belirler. CMS migration bu alanlardan birini kaldırırsa test alarm verir. Visible byline ve schema author aynı ID üzerinden karşılaştırılabilir. Date rules semantic assertion olarak eklenebilir. Contract content platformunun kalite standardına dönüşür.

Event Template Contract

Event contract ad, başlangıç zamanı, location ve status gibi temel bilgileri kapsar. İptal ve erteleme için farklı state kuralları olabilir. Ticket offers yalnızca mevcut olduğunda üretilir. Past event davranışı ayrıca tanımlanabilir. Bu sayede event lifecycle schema ile birlikte yönetilir.

Breadcrumb Contract

Breadcrumb contract ListItem yapısını, sıralı position değerlerini ve URL formatını tanımlar. Route hiyerarşisi değiştiğinde test bilinçli update gerektirir. Canonical helper aynı contract içinde kullanılabilir. Broken breadcrumb URL'si crawl testte yakalanabilir. Global component regression site genelinde erken bulunur.

Organization Contract

Organization contract isim, URL, logo ve kimlik gibi merkezi değerleri korur. Site genelinde duplicate veya farklı Organization çıktıları tespit edilebilir. Rebranding sırasında contract bilinçli şekilde güncellenir. sameAs listesi ayrı kalite kontrolü alabilir. Global entity'lerin güvenilirliği böylece artar.

API Değişikliğinin Schema'yı Bozmasını Önlemek

API değişiklikleri structured data tüketicisini de etkileyen contract değişiklikleridir. Consumer-driven test yaklaşımı gereken alanların kaybolmasını release öncesinde gösterebilir. Nullable hale gelen property'ler ayrıca incelenir. Frontend fallback ile çalışıyor diye schema'nın da doğru kaldığı varsayılmamalıdır. API ve SEO ekipleri ortak contract sahipliği geliştirebilir.

Schema Snapshot Testleri

Schema snapshot testleri belirli fixture için beklenen JSON-LD yapısını kayıt altına alır ve sonraki çıktılarla karşılaştırır. Yeni property eklenmesi, mevcut alanın kaybolması veya duplicate node oluşması diff içinde görünür. Bu yaklaşım özellikle refactor işlemlerinde faydalıdır. Ancak snapshot değiştiğinde otomatik olarak kabul etmek testin anlamını ortadan kaldırır. Reviewer değişikliğin business ve SEO açısından gerçekten beklenen sonuç olup olmadığını incelemelidir.

Beklenen JSON-LD

Beklenen JSON-LD fixture'ın referans çıktısıdır. Deterministik olmayan timestamp veya random ID'ler snapshot dışında normalize edilmelidir. Böylece gereksiz diff azalır. Snapshot okunabilir biçimde formatlanmalıdır. Büyük graph yapılarında node sırası stabil tutulabilir.

Yeni Property

Yeni property diff içinde görünür hale gelir. Değişiklik intentional ise dokümantasyon ve test rule set'i güncellenebilir. Yanlışlıkla eklenen gereksiz alan ise review sırasında fark edilir. Schema output değişiklikleri böylece görünmez olmaz. Code review SEO etkisini de kapsar.

Kaybolan Property

Kaybolan property özellikle required alan ise kritik regression'dır. Snapshot diff bunu hemen gösterir. Ayrı required assertion daha anlaşılır hata mesajı verir. Recommended alan kaybı warning seviyesinde değerlendirilebilir. İki test türü birbirini tamamlar.

İstenmeyen Duplicate

Yeni plugin veya component aynı entity'yi ikinci kez eklediğinde snapshot büyüyebilir. Reviewer duplicate node'u kolayca fark eder. Programatik duplicate detector ayrıca güçlü koruma sağlar. Snapshot tek başına semantic duplicate'i her zaman anlamaz. Kimlik bazlı assertion daha güvenilirdir.

Review Gerektiren Değişiklik

Her snapshot değişikliği code review sırasında açıklanmalıdır. Otomatik update komutu kullanımını kolaylaştırır, fakat karar mekanizması değildir. PR açıklamasında neden değiştiği belirtilebilir. Kritik schema dosyalarına SEO reviewer atanabilir. Böylece teknik ve Search etkisi birlikte değerlendirilir.

Snapshot'ı Körü Körüne Güncellememek

Test kırıldığında ilk çözüm snapshot update komutunu çalıştırmak olmamalıdır. Diff önce incelenmelidir. Required property kaybı veya yanlış fiyat yeni snapshot haline getirilirse regression normalleştirilmiş olur. Snapshot testinin değeri tam da beklenmeyen değişikliği durdurmasından gelir. Review kültürü bu nedenle teknik araç kadar önemlidir.

JSON Schema ile Schema.org Aynı Şey midir?

Hayır, JSON Schema ile Schema.org aynı sistem değildir. JSON Schema uygulama içindeki JSON verisinin yapısını ve veri tiplerini doğrulamak için kullanılabilen teknik bir şema tanımlama yaklaşımıdır. Schema.org ise web üzerindeki entity ve property anlamlarını tanımlayan vocabulary sunar. Structured data projelerinde JSON Schema benzeri iç contract araçları generator güvenliğini artırabilir, fakat Schema.org semantic validation'ın yerine geçmez. İki katmanı birlikte kullanmak type-safe structured data generator geliştirmede oldukça güçlü sonuç verir.

JSON Schema'nın Test Amaçlı Kullanımı

JSON Schema ile internal output'un gerekli alanlara ve veri tiplerine sahip olduğu kontrol edilebilir. Product generator için price'ın string veya number formatı ve zorunlu nested object yapısı tanımlanabilir. Build sırasında hızlı validation yapılabilir. Ancak Google feature kuralları ayrıca güncel kaynaktan takip edilmelidir. Internal schema dosyası tek başına external Search gerçeğini temsil etmez.

Schema.org Vocabulary

Schema.org semantic anlamı tanımlar. Product ile Offer arasındaki ilişki veya Article property'leri bu vocabulary içinde ifade edilir. Internal JSON Schema ise sizin uygulama sözleşmenizdir. İki sistem farklı amaçlara hizmet eder. Generator tasarımında bu ayrım açık tutulmalıdır.

İç Contract ile Search Vocabulary'yi Ayırmak

İç contract veri kalitesi ve uygulama ihtiyaçlarını temsil eder. Search vocabulary ise dış semantic standardı ve Google özel feature kurallarını içerir. Internal model daha kısıtlayıcı olabilir. Örneğin uygulama SKU'yu zorunlu tutarken Schema.org aynı business zorunluluğunu taşımayabilir. Bu ayrım dokümante edildiğinde ekip hangi testin neden kırıldığını daha kolay anlar.

Type-Safe Structured Data Generator

Type-safe generator yalnızca izin verilen entity modellerini kabul eder. Yanlış property veya eksik zorunlu internal alan compile veya runtime aşamasında hata üretir. Output daha sonra Schema.org ve Google validation katmanlarından geçer. Bu zincir güçlü defense-in-depth sağlar. Type güvenliği manual validator kullanımını tamamen ortadan kaldırmaz.

TypeScript ile Yapılandırılmış Veri Test Otomasyonu

TypeScript, frontend veya Node.js tabanlı projelerde structured data generator ve test otomasyonu için doğal bir seçenektir. Typed model sayesinde Product, Article ve Event gibi entity'lerin gerekli alanlarını compile-time seviyesinde kontrol edebilirsiniz. Unit test, DOM test ve build-time validation aynı toolchain içinde çalışabilir. Özellikle React, Next.js, Vue ve Nuxt projelerinde uygulama koduyla test kodunun aynı veri modellerini kullanması bakım kolaylığı sağlar. Yine de dil seçiminin ötesinde iyi bir contract ve fixture tasarımı daha önemlidir.

Typed Models

Typed model yanlış property ve veri tipi kullanımını erken azaltır. Her schema entity için ayrı interface veya type tanımlanabilir. Generic Record<string, any> kullanmak bu avantajı büyük ölçüde yok eder. Domain model ile schema model arasında kontrollü mapper bulunabilir. Böylece external vocabulary değişiklikleri tek katmanda yönetilir.

Required Fields

Internal olarak kesin gerekli alanlar TypeScript type içinde required tanımlanabilir. Google feature required listesi de ayrı rule set ile doğrulanabilir. İki kavram birebir aynı olmayabilir. Optional data geldiğinde generator'ın davranışı açık olmalıdır. Compile-time ve runtime validation birlikte kullanılabilir.

Unit Test

Unit test generator fonksiyonunu fixture ile çağırır ve beklenen entity'yi doğrular. Parse, required field ve value mapping birkaç milisaniyede test edilebilir. Harici servise ihtiyaç yoktur. Her bug için regression fixture eklenebilir. Hızlı test suite developer feedback süresini kısaltır.

DOM Test

DOM test render edilen component içindeki görünür değerlerle JSON-LD output'u karşılaştırabilir. React Testing Library veya benzeri araçlarla component fixture üzerinden oluşturulur. Price ve headline assertion uygulanabilir. Gerçek browser gerekmeyen senaryolar hızlı çalışır. Hydration ve runtime durumları için end-to-end test ayrıca kullanılır.

Build-Time Validation

Build sırasında statik sayfa çıktıları parse edilebilir. Script type, JSON syntax ve environment URL kontrolleri yapılabilir. Build artifact'i production'a gitmeden temel kalite kapısından geçer. Çok büyük sitede tam tarama yerine template sample uygulanabilir. Derin crawl post-deploy aşamasına bırakılabilir.

Frontend Stack ile Entegrasyon

TypeScript'in en büyük avantajlarından biri mevcut frontend stack ile aynı araç zincirinde çalışabilmesidir. Jest, Vitest veya Playwright gibi test araçlarıyla schema kontrolleri aynı pipeline'a eklenebilir. Developer ayrı SEO script dili öğrenmek zorunda kalmaz. Shared package ile schema modelleri farklı uygulamalar arasında kullanılabilir. Monorepo projelerinde bu yaklaşım özellikle güçlüdür.

Python ile Yapılandırılmış Veri Test Otomasyonu

Python, büyük URL listelerini taramak, JSON-LD çıkarmak, audit tablosu hazırlamak ve toplu karşılaştırma yapmak için oldukça kullanışlıdır. SEO audit otomasyonunda requests, HTML parser ve veri analizi araçlarıyla hızlı prototip geliştirilebilir. URL crawl sonucunda type, error, duplicate ve content mismatch gibi alanlar tabloya aktarılabilir. CI script olarak da kullanılabilir. Frontend uygulaması TypeScript olsa bile site çapındaki bağımsız audit katmanı Python ile rahatça çalışabilir.

URL Crawl

Python script sitemap veya URL listesini okuyarak sayfaları tarayabilir. HTTP status, canonical ve JSON-LD script'leri birlikte toplanabilir. Crawl rate site kapasitesine uygun ayarlanmalıdır. Retry ve timeout politikası açık olmalıdır. Sonuç template veya path pattern'e göre gruplanabilir.

JSON-LD Parse

HTML içindeki JSON-LD script'leri çıkarılıp standart JSON parser ile okunabilir. Birden fazla script ve @graph desteği eklenmelidir. Parse hataları URL bazında raporlanır. Node'lar type üzerinden normalize edilebilir. Bu veri sonraki audit aşamalarının temelini oluşturur.

DataFrame / Audit

Audit sonuçları tablo yapısına dönüştürülerek filtrelenebilir. URL, template, type, valid, warning, error ve last tested gibi sütunlar bulunabilir. Aggregate rapor template bazında error oranını gösterir. CSV veya dashboard aktarımı kolaylaşır. Büyük sitelerde manuel incelemeye göre çok daha ölçeklenebilir bir modeldir.

Bulk Validation

Bulk validation tek URL'ye bağımlı kalmadan yüzlerce veya binlerce sayfayı kontrol eder. Her URL için external validator çağırmak ölçek açısından uygun olmayabilir. Local rule set ve parser kontrolleri toplu çalıştırılabilir. Representative sample Google araçlarıyla ayrıca doğrulanır. Bu hibrit yöntem hız ve doğruluk arasında iyi denge sağlar.

Content Comparison

Python HTML'den görünür fiyat, tarih veya başka alanları çıkarıp JSON-LD ile karşılaştırabilir. CSS selector mapping template bazında tutulabilir. Currency ve date normalization yardımcı fonksiyonları geliştirilir. Mismatch oranı rapora eklenir. Bu yaklaşım content-schema parity'yi site ölçeğinde ölçmenizi sağlar.

CI Script

Python audit'in küçük bir bölümü CI script olarak çalıştırılabilir. Fixture HTML veya staging URL'leri kontrol edilir. Critical error varsa process non-zero exit code ile kapanır. Warning sonuçları artifact olarak kaydedilebilir. Mevcut DevOps stack'e uygunluk dil seçiminden daha önemlidir.

Schema Testi İçin En İyi Programlama Dili Hangisidir?

Schema testi için herkese uygun tek bir en iyi programlama dili yoktur. Frontend ve Node.js ağırlıklı ekiplerde JavaScript veya TypeScript doğal seçim olabilir. Bağımsız SEO audit, crawler ve veri analizi süreçlerinde Python çoğu zaman hızlı geliştirme avantajı sağlar. Mevcut CI/CD stack'iniz hangi dilde güçlü ise yeni bir teknoloji eklemek yerine onu kullanmak daha mantıklı olabilir. Başarılı sonuç dil seçiminden çok test contract'ının, fixture'ların ve monitoring modelinin kalitesine bağlıdır.

Tek Bir En İyi Dil Neden Yok?

Her projenin mimarisi ve ekip yetkinliği farklıdır. TypeScript frontend codebase içinde güçlü entegrasyon sağlarken Python site dışı crawling için daha rahat olabilir. Java, PHP veya başka dillerle çalışan ekipler de aynı kontrolleri kendi stack'lerinde uygulayabilir. JSON parse ve HTTP request temel olarak her modern dilde mümkündür. Bu nedenle yeni dil öğrenmek testin ön koşulu değildir.

Frontend İçin JavaScript / TypeScript

Frontend structured data generator uygulama component'leriyle yakın çalışıyorsa TypeScript güçlü seçimdir. Shared domain model ve type sistemi duplicate mapping ihtiyacını azaltabilir. Unit ve DOM test aynı repo içinde çalışır. Framework tooling entegrasyonu kolaydır. Production smoke test için Playwright benzeri araçlar da kullanılabilir.

SEO Audit Otomasyonu İçin Python

Python URL crawling ve veri analizi işlerinde pratik bir ekosistem sunar. Sitemap'ten URL okuyup JSON-LD çıkarmak kısa script ile yapılabilir. Audit sonuçları tablo ve rapora dönüştürülebilir. SEO uzmanlarının prototip geliştirmesi de kolay olabilir. Ancak üretim pipeline'ında bakım ownership'i net olmalıdır.

Mevcut CI/CD Stack'ine Uyum

Bir organizasyonda tüm pipeline Node.js tabanlıysa yalnızca schema testi için ayrı Python runtime eklemek gereksiz olabilir. Tersi durumda mevcut Python QA araçları rahatça genişletilebilir. Dependency ve security bakım maliyeti de kararın parçasıdır. En az sürtünmeyle sürdürülebilen çözüm tercih edilmelidir. Test mantığı dil bağımsız dokümante edilmelidir.

Dilden Çok Test Contract'ının Önemli Olması

Kötü tanımlanmış test kurallarını en popüler dilde yazmak kaliteli sonuç üretmez. Önce hangi property'nin neden kritik olduğu belirlenmelidir. Fixture gerçek business edge case'lerini temsil etmelidir. Error severity ve release blocker politikası açık olmalıdır. Dil yalnızca bu kuralları çalıştıran araçtır.

Büyük Sitelerde Toplu Structured Data Testi

Büyük sitelerde tek URL test etmek template ve veri çeşitliliğini temsil etmez. Milyonlarca sayfayı her release öncesinde dış validator üzerinden geçirmek de pratik değildir. Bu nedenle URL sampling, template-based sampling ve risk-based sampling birlikte kullanılabilir. Periyodik crawl daha geniş kapsam sağlayarak error aggregation ve trend monitoring verisi üretir. Böylece günlük pipeline hızlı kalırken site genelindeki schema sağlığı da düzenli ölçülür.

Tek URL Testi Neden Yeterli Değildir?

Aynı template farklı veri durumlarında farklı code path çalıştırabilir. Normal ürün düzgünken stoksuz ürün required alan kaybedebilir. Eski makaleler yeni içeriklerden farklı CMS modeline sahip olabilir. Tek URL yalnızca kendi durumunu doğrular. Template riskini anlamak için örnekleme şarttır.

URL Sampling

URL sampling site genelinden belirli sayıda sayfa seçer. Random sample genel kalite hakkında fikir verebilir. Ancak nadir edge case'leri kaçırabilir. Bu nedenle template ve risk sample ile birlikte kullanılması daha güçlüdür. Sample seed kaydedilirse sonuçlar yeniden üretilebilir.

Template-Based Sampling

Template-based sampling her ana sayfa türünden belirli sayıda URL seçer. Product, Article, Event ve category ayrı gruplar olur. Böylece yüksek hacimli bir template diğerlerini gölgede bırakmaz. Her grup için error rate hesaplanabilir. Owner atanması da template bazında kolaylaşır.

Risk-Based Sampling

Risk-based sampling en çok değişen veya gelir açısından önemli sayfalara daha fazla ağırlık verir. Kampanyalı ürün, yeni varyant sistemi veya yeni CMS template buna örnektir. Son release'te değişen code path'ler ayrıca örneklenebilir. Bu yaklaşım test maliyetini gerçek riske yönlendirir. Random sampling ile birlikte daha dengeli sonuç sağlar.

Crawl

Periyodik crawl site genelindeki structured data sağlığını daha geniş ölçekte inceler. Crawl günlük, haftalık veya site büyüklüğüne göre farklı aralıkta çalışabilir. Rate limit ve kaynak kullanımı dikkate alınmalıdır. Sonuçlar önceki crawl ile karşılaştırılır. Yeni error pattern'leri alarm üretir.

Error Aggregation

Aynı hata binlerce URL'de tekrarlanıyorsa tek tek kayıt açmak yerine kök neden etrafında gruplanmalıdır. Template, error code ve property kombinasyonu iyi aggregation key olabilir. Etkilenen URL sayısı ayrıca gösterilir. Bu yaklaşım ekiplerin en yüksek etkili probleme odaklanmasını sağlar. Dashboard gürültüsü azalır.

Trend Monitoring

Bugünkü error sayısı tek başına bağlam vermez. Geçen haftaya göre değişim ve release zamanlarıyla ilişki daha değerlidir. Valid, warning, mismatch ve duplicate oranları zaman serisi olarak izlenebilir. Ani değişim alert tetikleyebilir. Böylece schema operasyonu reaktif kontrolden proaktif izlemeye geçer.

Schema Health Score Nasıl Oluşturulur?

Schema Health Score, yapılandırılmış veri sağlığını tek metrikte özetlemek için kullanılabilir, ancak alttaki bileşenler mutlaka görünür tutulmalıdır. Valid URL oranı, critical error oranı, warning oranı, content mismatch, duplicate schema, deprecated type ve render failure gibi metrikler ağırlıklandırılabilir. Kritik hata ve content mismatch daha yüksek negatif ağırlık alabilir. Skorun amacı karmaşık sistemi gizlemek değil trendi hızlı göstermek olmalıdır. Teknik ekip detay rapora her zaman erişebilmelidir.

Valid URL Oranı

Valid URL oranı test edilen URL'ler içinde kritik schema hatası taşımayanların yüzdesini gösterir. Template bazında hesaplanması genel site oranından daha açıklayıcı olabilir. Yeni release sonrası düşüş regression sinyali verir. Eligibility ve Schema.org validation farklı oranlar olarak da tutulabilir. Tek valid tanımı bütün katmanları karıştırmamalıdır.

Critical Error Oranı

Critical error rate toplam test edilen URL içindeki blocker hata oranını gösterir. Bu metrik SLO için güçlü adaydır. Kritik template'lerde hedef sıfıra yakın veya sıfır olabilir. Error definition açık dokümante edilmelidir. Recommended warning bu orana dahil edilmemelidir.

Warning Oranı

Warning rate recommended alan veya düşük öncelikli kalite sorunlarının yaygınlığını gösterir. Zaman içinde sürekli artıyorsa bakım ihtiyacı vardır. Tek başına release başarısızlığı anlamına gelmez. Business value ağırlığıyla daha gelişmiş skor oluşturulabilir. Dashboard template kırılımı sunmalıdır.

Content Mismatch Oranı

Content mismatch oranı DOM ile structured data arasındaki kritik değer farklarını ölçer. Fiyat ve stok gibi alanlarda bu metrik özellikle önemlidir. Küçük format farkları normalize edilmelidir. Gerçek semantic mismatch ayrı hata kodu almalıdır. Yüksek oran data architecture problemine işaret edebilir.

Duplicate Schema Oranı

Duplicate schema oranı aynı entity'nin beklenmeyen şekilde birden fazla üretildiği URL yüzdesini gösterir. Plugin veya tema güncellemesi sonrası ani artış olabilir. Gerçek çoklu entity sayfaları false positive olmamalıdır. Duplicate detector business identity kurallarını kullanmalıdır. Trend zaman içinde izlenebilir.

Deprecated Type Oranı

Deprecated type oranı eski Google Search feature hedeflerine bağlı markup kapsamını gösterir. Bu değer migration planının ilerlemesini ölçebilir. Type Schema.org açısından hâlâ geçerli olsa bile feature status ayrı değerlendirilir. Removed durum daha yüksek risk puanı alabilir. Registry bu metriğin kaynak verisini sağlar.

Render Failure Oranı

Render failure JavaScript veya template problemi nedeniyle beklenen structured data'nın ortaya çıkmadığı URL oranıdır. Source doğru olsa bile client runtime hatası olabilir. Headless crawl bu metriği üretir. Mobil ve desktop ayrı ölçülebilir. Yüksek oran frontend incident göstergesidir.

Structured Data KPI'ları

Structured data KPI'ları yalnızca kaç URL'nin valid olduğunu değil, eligibility, hata oranı, Search görünümü ve regression kalitesini birlikte izlemelidir. Eligible URL, invalid URL, critical error rate, warning rate, rich result impression, click, CTR ve regression sayısı iyi başlangıç setidir. Teknik ve performans metrikleri aynı şey olmadığı için ayrı yorumlanmalıdır. Impression düşüşü schema regression olmadan da gerçekleşebilir. KPI seti teknik ekip ile SEO ekibi arasındaki ortak dili güçlendirir.

Eligible URL Sayısı

Eligible URL sayısı hedeflenen Google feature koşullarını karşılayan test edilmiş URL kapsamını gösterir. Site URL toplamıyla birlikte oran olarak değerlendirilmelidir. Deprecated feature'lar bu metrikten çıkarılmalıdır. Template bazlı hedefler belirlenebilir. Search görünümü garantisi olarak yorumlanmamalıdır.

Invalid URL Sayısı

Invalid URL sayısı kritik structured data problemi taşıyan sayfaların kapsamını gösterir. Sayı tek başına site büyüklüğüne göre yanıltıcı olabilir. Oran ve trafik etkisiyle birlikte incelenmelidir. Yeni release sonrası ani artış incident tetikleyebilir. Root cause aggregation önceliklendirmeyi kolaylaştırır.

Critical Error Rate

Critical error rate release kalite göstergesi olarak kullanılabilir. Kritik template'lerde çok düşük hedef belirlenebilir. Hata tanımı değişirse trend kırılabilir, bu nedenle metric versioning faydalıdır. Deploy annotation dashboard üzerinde gösterilmelidir. Böylece artışın hangi release ile başladığı görülür.

Warning Rate

Warning rate recommended property eksikliklerini veya düşük öncelikli sorunları takip eder. Bu metrik tamamen sıfırlanmak zorunda değildir. Ancak hızlı yükseliş rule veya data regression göstergesi olabilir. Warning kategorileri ayrı gösterilirse aksiyon daha kolay belirlenir. İş değeri yüksek warning'ler ayrıca etiketlenebilir.

Rich Result Impression

Rich result impression uygun Search Console verisi mevcut olduğunda gerçek Search görünürlüğü hakkında performans sinyali sağlar. Eligibility metriğiyle birlikte karşılaştırmak önemlidir. Eligible URL artarken impression düşüyorsa sorgu veya Google feature davranışı incelenebilir. Teknik ekibe doğrudan hata yüklemek doğru olmaz. Trend ve sorgu bağlamı birlikte değerlendirilmelidir.

Rich Result Click

Click metriği rich result görünümünün kullanıcı etkileşimine katkısını anlamaya yardımcı olabilir. Ancak trafik değişimi sıralama ve talep gibi başka faktörlerden etkilenir. Bu nedenle click tek başına schema ROI ölçümü değildir. Impression ve position bağlamı eklenmelidir. A/B benzeri doğal karşılaştırmalarda dikkatli yorum yapılmalıdır.

CTR

CTR zengin sonuç görünürlüğünün tıklama davranışıyla ilişkisini izlemek için kullanılabilir. Sorgu mix değişimi CTR'yi etkileyebilir. Öncesi-sonrası analiz aynı sorgu veya segmentlerde yapılmalıdır. Schema değişikliği ile ranking değişikliği birbirinden ayrılmalıdır. KPI yorumunda nedensellik iddiası dikkatle kurulmalıdır.

Schema Regression Sayısı

Schema regression sayısı release veya zaman içinde tekrar ortaya çıkan teknik bozulmaları ölçer. Sık regression test kapsamının veya ownership modelinin yetersiz olduğunu gösterebilir. Incident başına root cause kategorisi tutulmalıdır. Aynı hata ikinci kez yaşanıyorsa yeni test eklenmesi beklenebilir. Bu metrik sürekli iyileştirme için oldukça değerlidir.

Schema Test Dashboard

Schema test dashboard, büyük sitelerde structured data sağlığını tek ekranda takip etmeyi kolaylaştırır. Template, type, valid, warning, error, deprecated, content mismatch, last tested ve owner gibi alanlar temel görünümü oluşturabilir. Kullanıcı önce genel trendi görür, ardından sorunlu URL örneklerine iner. Dashboard Search Console verisiyle internal crawl sonuçlarını ayrı kaynaklar olarak işaretlemelidir. Böylece farklı doğruluk seviyeleri tek “yeşil veya kırmızı” kutuya sıkıştırılmaz.

Template

Template alanı sorunları sayfa türüne göre gruplar. Product template yüksek error rate gösterirken Article sağlıklı olabilir. Bu ayrım owner ve öncelik belirlemeyi kolaylaştırır. Route pattern otomatik template sınıflandırmasında kullanılabilir. Unknown template ayrıca veri kalitesi sinyali olabilir.

Type

Type alanı hangi Schema.org entity'sinin test edildiğini gösterir. Bir URL'de birden fazla type varsa satır veya ilişki modeli buna göre tasarlanabilir. Expected type ve detected type ayrı tutulabilir. Farklar regression olarak işaretlenebilir. Deprecated status type kaydıyla ilişkilendirilebilir.

Valid

Valid alanının hangi validator katmanını temsil ettiği açık olmalıdır. JSON parse valid ile Google eligibility valid aynı şey değildir. İki veya daha fazla ayrı sütun kullanmak daha doğrudur. Genel health score bunları ağırlıklandırabilir. Kullanıcı detay seviyesine inebilmelidir.

Warning

Warning sayısı ve kategorisi düşük öncelikli kalite sorunlarını gösterir. Recommended property eksikleri gruplanabilir. Warning trendi release bazında izlenebilir. Business value etiketi eklenirse backlog önceliği kolaylaşır. Her warning otomatik incident açmamalıdır.

Error

Error alanı kritik ve actionable problemlere odaklanmalıdır. Missing required, parse error ve content mismatch farklı kodlarla gösterilebilir. URL sayısı ve trafik etkisi eklenebilir. Son release bilgisi root cause araştırmasını hızlandırır. Error sahibi owner alanından belirlenebilir.

Deprecated

Deprecated sütunu feature lifecycle riskini gösterir. Active olmayan Search feature'lar burada görünür hale gelir. Migration ticket bağlantısı eklenebilir. Removed type kullanan URL sayısı ayrı alarm seviyesi alabilir. Registry bu bilginin ana kaynağı olmalıdır.

Content Mismatch

Content mismatch DOM ve JSON-LD farklılığını ölçer. Fiyat, stok, rating veya tarih gibi alt kategoriler bulunabilir. Normalize edilmiş değerler raporda gösterilebilir. Böylece geliştirici farkı doğrudan görür. Yüksek mismatch oranı source-of-truth problemi düşündürür.

Last Tested

Last tested verinin güncelliğini gösterir. Haftalar önce test edilmiş kritik URL'ler stale olarak işaretlenebilir. SLA veya SLO belirlenirse test freshness ölçülebilir. Deployment sonrası ilgili URL'lerin tarihleri güncellenir. Böylece dashboard yalnızca eski snapshot sunmaz.

Owner

Owner sorun çıktığında hangi ekibin aksiyon alacağını gösterir. Template, data source veya feature bazında farklı owner olabilir. Ortak ownership durumunda primary ve secondary kişi tanımlanabilir. Alert doğrudan doğru ekibe yönlendirilebilir. Bu alan operasyonel tepki süresini kısaltır.

Structured Data İçin SLO Tanımlanabilir mi?

Evet, structured data için teknik kalite SLO'ları tanımlanabilir. Kritik template'lerde yüzde yüz required property coverage, sıfıra yakın critical error, belirli regression recovery süresi ve deprecated type kullanım süresi gibi hedefler ölçülebilir. SLO'nun amacı ekibi cezalandırmak değil kalite beklentisini görünür hale getirmektir. Release sonrası schema sağlığı da gözlem penceresi içinde değerlendirilmelidir. Gerçekçi hedefler template önemine göre farklı olabilir.

Kritik Template'lerde %100 Required Property Coverage

Kritik Product veya Article template'lerinde required property coverage için yüzde yüz hedef makul olabilir. Bu hedef gerçek veri bulunmayan business durumlarını ayrıca tanımlamalıdır. “Boş değer üretmek” coverage sayılmamalıdır. Automated test ölçümü kolaylaştırır. Coverage düşerse release veya incident politikası devreye girebilir.

Critical Error Sayısı

Critical error sayısı mümkün olduğunca sıfıra yakın tutulmalıdır. Büyük sitelerde absolute sayı yerine oran daha anlamlı olabilir. Yeni incident'ler zaman bazında ayrıca izlenir. Error severity standardize edilmelidir. Warning bu metriğe dahil edilmemelidir.

Regression Recovery Süresi

Regression recovery süresi problemin tespitinden production fix'e kadar geçen zamanı ölçebilir. High traffic template'lerde daha kısa hedef belirlenebilir. Otomatik alert tespit süresini azaltır. Rollback mekanizması çözüm süresini kısaltabilir. Postmortem sürekli iyileştirmeye veri sağlar.

Deprecated Type Kullanım Süresi

Deprecated feature tespitinden migration kararına kadar maksimum süre tanımlanabilir. Her deprecation hemen kod silme gerektirmez. Önce business etkisi ve alternatifler değerlendirilir. Bununla birlikte removed feature'ın yıllarca unutulmaması için süre hedefi yararlıdır. Registry status değişikliği timer başlatabilir.

Release Sonrası Schema Sağlığı

Release sonrası belirli süre içinde smoke test başarı oranı SLO olarak kullanılabilir. Kritik URL'lerin tamamının expected type ve required property testini geçmesi beklenebilir. Search Console daha geç sinyal verdiği için internal monitor daha hızlıdır. Gözlem penceresi sonunda release schema açısından healthy kabul edilir. Hata durumunda incident açılır.

Schema Regression Incident Playbook

Schema regression incident playbook, production'da yapılandırılmış veri bozulduğunda ekibin hangi sırayla hareket edeceğini belirler. Alert alındığında etkilenen template, URL sayısı ve son release kontrol edilir. Root cause belirlendikten sonra fix veya rollback kararı verilir. Production düzeltmesi sonrası Search Console validation ve monitoring süreci devam eder. Son aşamada postmortem ile test boşluğu kapatılır.

Alert

Alert açık ve actionable bilgi içermelidir. URL, template, error code ve first seen zamanı temel alanlardır. Gürültülü warning'ler ayrı kanalda tutulabilir. Critical schema kaybı hızlı notification gerektirebilir. Alert doğrudan doğru owner'a yönlenmelidir.

Etkilenen Template

Template bilgisi sorunun kapsamını hızlıca gösterir. Product template etkilenmişse gelir riski Article probleminden farklı olabilir. Aynı release hangi component'i değiştirdiğiyle karşılaştırılır. Template owner sürece dahil edilir. Unknown scope varsa hızlı crawl yapılabilir.

Etkilenen URL Sayısı

URL sayısı incident severity için önemli fakat tek kriter değildir. Beş yüksek trafik ürünü yüz bin düşük trafik sayfasından daha büyük business etki yaratabilir. Trafik ve revenue segmentleri eklenebilir. Sample üzerinden tahmini kapsam üretilebilir. Fix sonrası aynı sayı yeniden ölçülmelidir.

Son Release

Son release schema değişikliği içermese bile ortak component veya API davranışını değiştirmiş olabilir. Deployment diff ilk kontrol noktalarından biridir. Feature flag değişimleri de incelenmelidir. Release annotation dashboard üzerinde tutulursa korelasyon kolaylaşır. Gerekiyorsa rollback seçeneği değerlendirilir.

Root Cause

Root cause syntax, template, data, cache, plugin veya policy gibi kategorilere ayrılabilir. Yalnızca belirtileri düzeltmek tekrar riski taşır. Neden test tarafından yakalanmadığı ayrıca sorulmalıdır. Her incident test suite'e öğrenme katmalıdır. Böylece regression sayısı zamanla azalır.

Fix veya Rollback

Fix geliştirmek zaman alacaksa kritik business etkide rollback daha güvenli olabilir. Karar mevcut release riskine bağlıdır. Rollback sonrası schema smoke test yeniden çalıştırılmalıdır. Hotfix ise aynı PR testlerinden geçmelidir. Acil durumda bile validation tamamen atlanmamalıdır.

Search Console Validation

Production fix iç testlerle doğrulandıktan sonra Search Console süreci takip edilir. Google yeniden tarama yaptığı için sonuç anlık değişmeyebilir. Validation başlangıç ve bitiş durumu incident kaydında tutulabilir. Bu aşama internal fix doğrulamasının yerine geçmez. İki sistem farklı zaman ölçeğinde çalışır.

Postmortem

Postmortem suçlu bulmak için değil sistem öğrenmesi için yapılmalıdır. Hata neden oluştu, neden önceden yakalanmadı ve hangi test eklenecek soruları cevaplanır. Fixture veya contract güncellenebilir. Ownership boşluğu varsa düzeltilir. Aynı incident'in tekrar etmemesi başarı ölçütüdür.

Yapılandırılmış Veri Güvenlik ve Spam Politikaları

Structured data teknik olarak geçerli olsa bile yanıltıcı veya spam amaçlı kullanıldığında sorun yaratabilir. Fake reviews, olmayan ürün, gizli içerik, yanıltıcı event ve alakasız schema uygulamaları yalnızca validator ekranıyla değerlendirilemez. Gerçek sayfa içeriği ve business verisiyle doğruluk esastır. Manual action ile syntax error farklı problem sınıflarıdır. Bu nedenle test planı teknik validation yanında human review ve content parity kontrolü de içermelidir.

Fake Reviews

Sahte review veya rating üretmek structured data'nın güvenilirliğini bozar. Generator yalnızca gerçek, yayınlanmış review verisini kullanmalıdır. Marketing metni review olarak işaretlenmemelidir. Reviewsuz fixture sahte fallback'i engeller. Review pipeline veri kaynağı audit edilebilir olmalıdır.

Olmayan Ürünü İşaretlemek

Sayfada gerçek ürün sunulmadığı halde Product schema eklemek doğru değildir. Generic kategori veya içerik sayfasını ürün gibi işaretlemek entity anlamını bozar. Route contract bu hatayı engelleyebilir. Product markup gerçek ürün sayfasıyla sınırlanmalıdır. İstisnalar hedef dokümana göre değerlendirilmelidir.

Gizli İçeriği İşaretlemek

Kullanıcıya sunulmayan bilgiyi schema içinde avantaj sağlamak amacıyla eklemek risklidir. Hidden review ve eski fiyat örnekleri buna dahildir. Content parity testi otomatik güvence sağlar. CSS ile kasıtlı gizlenen content ayrıca insan review gerektirebilir. Schema gerçek public deneyimi temsil etmelidir.

Yanıltıcı Event

Olmayan, iptal edilmiş veya genel katılıma açık olmayan etkinliği yanlış biçimde işaretlemek kullanıcıyı yanıltabilir. Event status ve availability gerçek sistemden gelmelidir. Eski event sayfasında markup'ın aktif kalması önlenmelidir. Fixture lifecycle senaryolarını kapsamalıdır. Periyodik crawl geçmiş event'leri kontrol edebilir.

Irrelevant Schema

Her sayfaya rich result kazanma umuduyla ilgisiz schema eklemek doğru değildir. Type sayfanın gerçek ana entity'sine dayanmalıdır. Generic SEO template'i bütün sitelere aynı markup'ı basmamalıdır. Route contract expected type setini sınırlar. Daha az ama doğru structured data çoğu zaman daha sağlıklıdır.

Manual Action

Manual action teknik validation başarısızlığıyla aynı şey değildir. Search Console üzerinde politika ihlalleri ayrı şekilde ele alınabilir. Teknik olarak valid JSON bu riski ortadan kaldırmaz. Incident playbook manual action kontrolünü içermelidir. Düzeltme gerçek içerik ve kullanım amacını kapsamalıdır.

Manual Action ile Teknik Validation Hatası Aynı Şey midir?

Hayır, manual action ile teknik validation hatası farklı problem sınıflarıdır. Syntax error veya missing required property teknik uygunluk problemidir. Quality violation veya spam policy ihlali ise markup'ın nasıl ve ne amaçla kullanıldığıyla ilgilidir. Teknik olarak geçerli bir schema yanıltıcı içerik içeriyorsa politika açısından yine sorunlu olabilir. Bu ayrım debugging sürecinde doğru ekibi ve doğru çözümü seçmek için önemlidir.

Syntax Error

Syntax error parser seviyesinde objektif teknik hatadır. JSON parse edilmez ve structured data işlenemez. Otomatik testle kolayca yakalanabilir. Çözüm serializer veya generator kodunu düzeltmektir. Policy review gerektiren problemden farklıdır.

Quality Violation

Quality violation markup'ın kullanıcıya sunulan içerikle ve kullanım beklentileriyle ilişkisinden kaynaklanabilir. Fake rating buna örnek olabilir. JSON tamamen valid olsa bile sorun devam eder. Human review ve content parity önem kazanır. Çözüm yalnızca syntax değişikliği değildir.

Spam Policy

Spam policy Search deneyimini manipüle etmeye yönelik yanıltıcı uygulamaları kapsayabilir. Structured data da bu politikalardan bağımsız değildir. Güncel Google politikaları düzenli kontrol edilmelidir. Ekip kısa vadeli görünürlük uğruna yapay veri üretmemelidir. Governance süreci bu riskleri review eder.

Search Console Manual Actions

Search Console Manual Actions alanı siteye uygulanan belirli manuel işlemler hakkında bilgi sağlayabilir. Structured data incident araştırmasında gerektiğinde kontrol edilmelidir. Sorun varsa kapsam ve örnekler incelenir. Düzeltme sonrası ilgili değerlendirme süreci takip edilir. Internal monitoring bu bilginin yerine geçmez.

Teknik Olarak Valid Fakat Politika Açısından Geçersiz Schema

Bu durum structured data testinin neden yalnızca validator'dan ibaret olmadığını gösterir. Kod doğru type ve property kullanabilir. Fakat içerik gerçek değilse veya kullanıcıya görünmüyorsa kalite problemi vardır. Contract test yalnızca bazı mismatch'leri yakalar. Human review ve governance bu nedenle hâlâ önemlidir.

AI Tarafından Üretilen JSON-LD Nasıl Test Edilmeli?

Otomatik içerik veya kod üretim araçlarının verdiği JSON-LD çıktısı production'a doğrudan alınmamalıdır. Çıktı önce syntax validation, Schema.org validation, Google eligibility, content parity ve human review aşamalarından geçmelidir. Araç güncel olmayan feature önerebilir veya sayfada bulunmayan property değerlerini uydurabilir. Bu nedenle generated code normal pull request kodundan daha düşük test standardına sahip olmamalıdır. En güvenli model, üretim aracını öneri sağlayan kaynak olarak görüp doğrulamayı sizin sisteminizin yapmasıdır.

AI Çıktısını Doğrudan Production'a Almamak

Üretilen JSON-LD mantıklı göründüğü için doğru kabul edilmemelidir. Schema.org property adı uydurulabilir veya eski Google feature tavsiye edilebilir. Kod review ve test pipeline'dan geçmelidir. Gerçek veri kaynaklarıyla mapping ayrıca doğrulanmalıdır. Production sorumluluğu kullanılan araçta değil uygulama ekibindedir.

Syntax Validation

İlk aşama standart JSON parse testidir. Generated output geçersiz tırnak veya yorum gibi sorunlar içerebilir. Parser bu hataları hızlıca yakalar. Geçerli JSON elde edilmeden semantic kontrol yapılmamalıdır. Bu aşama tamamen otomatikleştirilebilir.

Schema.org Validation

Syntax sonrası type ve property ilişkileri doğrulanmalıdır. Uydurulmuş veya yanlış bağlamdaki property'ler burada fark edilebilir. General vocabulary ile Google feature kuralları ayrılmalıdır. Validator sonucu code review notuna eklenebilir. Generated örnek dokümantasyondaki gerçek vocabulary ile karşılaştırılmalıdır.

Google Eligibility

Google Rich Results Test hedeflenen feature için uygunluğu değerlendirmede kullanılmalıdır. Tool çıktısının “bu schema rich snippet kazandırır” iddiasına güvenilmemelidir. Feature desteği 2026 güncel dokümantasyonundan kontrol edilmelidir. FAQ ve HowTo gibi eski tavsiyeler özellikle filtrelenmelidir. Registry otomatik uyarı sağlayabilir.

Content Parity

Generated code sayfada bulunmayan rating, fiyat veya author bilgisi ekleyebilir. DOM-schema parity testi bu riski azaltır. Generator yalnızca explicit data object alacak şekilde tasarlanabilir. Serbest metinden değer tahmin edilmesi kritik alanlarda kullanılmamalıdır. Gerçek kaynak yoksa property üretilmemelidir.

Human Review

Human review business anlamını ve politika bağlamını değerlendirir. Teknik testlerin hepsi geçse bile entity seçimi yanlış olabilir. Reviewer sayfanın gerçek amacıyla markup'ın uyumuna bakar. Yeni schema type ilk kez uygulanırken bu kontrol özellikle değerlidir. Sonraki tekrarlar otomasyonla daha fazla kapsanabilir.

AI'ın En Sık Yapabileceği Schema Hataları

Generated schema örneklerinde en tehlikeli sorun syntax hatasından çok ikna edici görünen yanlış bilgidir. Olmayan property, kaldırılmış Search feature, fake rating, eksik required field, yanlış value type veya sayfada bulunmayan içerik üretilebilir. Bu hatalar kodun görsel olarak profesyonel görünmesi nedeniyle kolayca gözden kaçabilir. Güncel validator, registry ve content parity testleri koruma sağlar. Kodun kaynağı ne olursa olsun aynı release kalite kuralları uygulanmalıdır.

Olmayan Property Üretmek

Property adı mantıklı görünebilir fakat Schema.org vocabulary içinde bulunmayabilir. Typed models ve validator bunu yakalar. Generated code copy-paste edilmeden önce dokümantasyon kontrol edilmelidir. Custom property gerekiyorsa bunun ayrı teknik tasarımı yapılır. Yanlış alanı yalnızca validator warning vermedi diye kabul etmemek gerekir.

Deprecated Google Feature Önermek

Modelin eğitim verisinde eski SEO rehberleri bulunabileceği için kaldırılmış feature önerileri gelebilir. FAQ ve HowTo zengin sonuç tavsiyeleri bunun açık örnekleridir. 2026 güncel support registry kontrolü bu riski azaltır. Feature status release checklist'te yer almalıdır. Güncellik doğrulaması manuel bilgi hafızasına bırakılmamalıdır.

Fake Rating Eklemek

Generated örnekler açıklama amacıyla 4.8 gibi örnek rating yazabilir. Bu değer production'a aynen kopyalanırsa gerçek olmayan bilgiye dönüşür. Rating yalnızca gerçek review servisinden gelmelidir. Placeholder data ile production data ayrımı test edilmelidir. Demo değerlerinin deployment artifact'e sızması engellenmelidir.

Required Property Atlamak

Generated örnek minimal olabilir ve Google'ın hedef feature için gerekli alanlarından birini atlayabilir. Rich Results Test bu sorunu gösterebilir. Internal required rule set ayrıca CI'da kontrol edilmelidir. Example code production spesifikasyonu değildir. Gerçek feature dokümanı source of truth olmalıdır.

Yanlış Value Type

Property doğru görünse bile value type yanlış olabilir. Tarih natural language, URL nesne veya sayı beklenmeyen string formatında üretilebilir. Typed model ve runtime validation güçlü koruma sağlar. Parser testi tek başına yeterli değildir. Semantic validator ikinci aşamada çalışmalıdır.

Sayfada Olmayan İçeriği İşaretlemek

Generated schema sayfa metninden çıkarım yaparak görünmeyen özellik ekleyebilir. Structured data'nın gerçek ve görünür içerikle uyumlu olması gerekir. DOM-schema contract test kritik alanları karşılaştırmalıdır. Human review yeni implementation'da örnek URL'leri kontrol eder. Otomasyonun tahmini veri üretmesine izin verilmemelidir.

Open Source ve Yapılandırılmış Veri Testleri

Açık kaynak yaklaşımı structured data testlerinde ortak parser, rule set ve fixture geliştirmeyi kolaylaştırabilir. Schema.org ekosistemi zaten açık web standartları çevresinde şekillenir. Basit bir URL tester, JSON-LD extractor ve content parity aracı topluluk için yararlı bir eğitim projesine dönüşebilir. Farklı geliştiricilerin gerçek bug fixture'ları paylaşması test kapsamını güçlendirir. Böyle bir proje tek bir SEO aracını kopyalamak yerine otomasyon ve teknik SEO bilgisini bir araya getirmelidir.

Schema.org Ekosistemi

Schema.org geniş bir vocabulary ve topluluk temelli geliştirme modeli sunar. Open source tester bu vocabulary bilgilerini kontrollü şekilde kullanabilir. Ancak Google Search feature kuralları ayrıca ayrı modül olarak tutulmalıdır. Böylece general semantic validation ile Google eligibility birbirine karışmaz. Mimari tasarım eğitim açısından da değerli olur.

Açık Kaynak Validator Yaklaşımı

Açık kaynak validator kullanıcıya hangi kuralın neden hata verdiğini açıkça göstermelidir. Black-box skor yerine rule ID ve kaynak açıklaması daha öğreticidir. Community pull request ile yeni rule eklenebilir. Sürümleme feature değişikliklerini takip etmeyi kolaylaştırır. Test suite validator'ın kendi doğruluğunu güvence altına almalıdır.

JSON-LD Parser'ları

JSON-LD extraction ve parsing projenin temel modülüdür. Birden fazla script, array ve @graph desteği bulunmalıdır. Parser yalnızca valid JSON'u kabul etmeli ve hata konumunu raporlamalıdır. HTML parser ile script içerikleri güvenli alınmalıdır. Test fixture'ları bozuk JSON örneklerini içermelidir.

Ortak Test Rule Set'leri

Rule set Product, Article ve Event gibi type'lara göre ayrılabilir. Required field, duplicate entity ve content parity kuralları modüler tutulmalıdır. Google'a özel kurallar ayrı namespace altında bulunabilir. Böylece kullanıcı hangi standardın hata verdiğini bilir. Rule source ve son güncelleme tarihi metadata olarak eklenebilir.

Community Contribution

Topluluk katkısı gerçek dünya edge case'lerinin projeye eklenmesini sağlar. Contributor yeni bug için fixture ve test gönderebilir. Code review teknik doğruluğu korur. Dokümantasyon yeni başlayanların katkı yapmasını kolaylaştırmalıdır. Açık issue listesi öğrenme yol haritasına da dönüşebilir.

Test Fixture Paylaşımı

Fixture paylaşımı yalnızca kod değil problem örneklerini de toplulukla paylaşmak anlamına gelir. Kişisel veya ticari özel veri temizlenmelidir. Minimal reproducible example tercih edilmelidir. Her fixture beklenen result ve rule açıklaması içermelidir. Böylece eğitim ve regression testing aynı kaynak üzerinden ilerler.

Diyarbakır Yazılım Topluluğu İçin Örnek Open Source Schema Tester

Diyarbakır Yazılım Topluluğu içinde geliştirilebilecek örnek bir open source schema tester, URL girdisi alıp JSON-LD çıkaran ve type detection yapan basit bir araçla başlayabilir. İkinci aşamada required property rules, content parity ve deprecated feature warning eklenebilir. Sonuçlar HTML rapor olarak sunulabilir ve GitHub Actions entegrasyonuyla pull request kontrolüne dönüştürülebilir. Böyle bir proje frontend, backend, test otomasyonu ve teknik SEO becerilerini aynı çalışma içinde buluşturur. Topluluğun farklı projelerini incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

URL Girdisi

İlk sürüm kullanıcıdan tek URL alabilir. HTTP response, status code ve HTML güvenli şekilde indirilir. Timeout ve redirect limiti bulunmalıdır. Localhost veya private network erişimi server-side güvenlik açısından kontrollü yönetilmelidir. Sonraki sürüm toplu URL desteği ekleyebilir.

JSON-LD Extraction

HTML içindeki tüm application/ld+json script'leri çıkarılır. Her script ayrı parse sonucu alır. Parse hatası kullanıcıya anlaşılır mesajla gösterilir. Graph node'ları normalize edilir. Kaynak script index'i debugging için korunabilir.

Schema Type Detection

Parser sonrası bulunan @type değerleri listelenir. Beklenen veya desteklenen type bilgisi ayrı göstergede sunulabilir. Multiple types ve arrays doğru ele alınmalıdır. Unknown type doğrudan error kabul edilmeden önce vocabulary kontrol edilmelidir. Google support status ayrı modülden gelir.

Required Property Rules

Rule engine aktif Google feature'lar için required property setini tutabilir. Rule metadata son kontrol tarihi ve doküman referansı içerebilir. Eksik alan critical olarak raporlanır. Recommended alan warning seviyesine ayrılır. Community update süreçleri rule güncelliğini korur.

Content Parity Test

İlk parity modülü Product fiyatı gibi belirgin alanlardan başlayabilir. Kullanıcı DOM selector belirtir veya template adapter kullanılır. JSON-LD value normalize edilip görünür text ile karşılaştırılır. Mismatch raporu iki değeri yan yana gösterir. Sonraki sürümlerde availability ve date eklenebilir.

Deprecated Feature Warning

Tool Google Search feature lifecycle registry taşıyabilir. FAQ veya HowTo gibi kaldırılmış rich result hedefleri için bilgilendirici warning gösterilebilir. Schema.org type'ın semantic geçerliliğiyle Google support status ayrı yazılmalıdır. Böylece kullanıcı “schema geçersiz” yanlış sonucuna ulaşmaz. Registry periyodik olarak güncellenmelidir.

HTML Report

HTML rapor URL, detected types, critical errors, warnings ve parity sonuçlarını okunabilir biçimde sunabilir. Her kural açıklaması ve severity içermelidir. Rapor CI artifact olarak saklanabilir. Ekip üyesi JSON dosyası okumadan problemi görebilir. Accessibility ve responsive tasarım da proje kalitesinin parçası olmalıdır.

GitHub Actions Entegrasyonu

GitHub Actions entegrasyonu tester'ı gerçek development workflow'a taşır. Pull request sırasında fixture veya staging URL kontrolü çalıştırılabilir. Critical error varsa job fail olur. Report artifact olarak eklenebilir. Bu proje katılımcılara CI/CD ve SEO otomasyonunu birlikte öğretir.

Topluluk İçinde Structured Data Test Atölyesi

Structured data test atölyesi yalnızca hazır JSON-LD kopyalamak yerine hata ayıklama ve otomasyon pratiğine odaklanabilir. İlk bölümde JSON-LD temelleri, ardından Rich Results Test ve Schema.org Validator farkı gösterilir. Katılımcılar Product ve Article test case üzerinde çalışır, kasıtlı bozuk schema debug eder ve son aşamada CI/CD entegrasyonu yapar. Böyle bir akış hem yeni başlayanlar hem deneyimli geliştiriciler için somut çıktı üretir. Diyarbakır Yazılım Topluluğu hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi ziyaret edilebilir.

JSON-LD Temelleri

Atölye @context, @type, property ve nested object kavramlarıyla başlayabilir. Katılımcılar küçük bir Product örneği yazar. Ardından kasıtlı syntax hataları eklenir. Parser ile hatalar bulunur. Böylece validation seviyeleri uygulamalı olarak anlaşılır.

Rich Results Test

Katılımcılar aynı markup'ı Google Rich Results Test ile kontrol eder. Required ve recommended alan farkı örnek üzerinden gösterilir. Eligible olmanın actual appearance garantisi olmadığı vurgulanır. Desteklenmeyen type senaryosu ayrıca incelenir. Güncel feature dokümantasyonuna nasıl bakılacağı öğretilir.

Schema.org Validator

Aynı örnek Schema Markup Validator üzerinden test edilir. İki araç arasındaki kapsam farkı karşılaştırılır. Google'ın desteklemediği fakat Schema.org içinde bulunan type örneği incelenebilir. Katılımcılar validation ile eligibility kavramlarını ayırır. Bu fark atölyenin temel kazanımlarından biridir.

Product Test Case

Product case fiyat, stok ve review verilerini içerir. İndirimli ve stoksuz iki fixture üzerinden test yapılır. DOM fiyatı ile JSON-LD price karşılaştırılır. Duplicate Product problemi kasıtlı olarak oluşturulabilir. Katılımcılar root cause bulup düzeltir.

Article Test Case

Article case author, published ve modified tarihlerini içerir. Yanlış timezone veya her deploy'da değişen modified date senaryosu gösterilir. Visible byline ile schema author karşılaştırılır. Snapshot test yazılır. Böylece içerik sistemlerindeki tipik problemler somut hale gelir.

Broken Schema Debugging

Kasıtlı bozuk fixture seti debugging pratiği sağlar. Bazı örneklerde syntax, bazılarında semantic ve bazılarında content parity hatası bulunur. Katılımcı önce hatanın hangi doğruluk seviyesinde olduğunu belirler. Daha sonra uygun aracı seçer. Bu yöntem araç ezberlemekten daha kalıcı öğrenme sağlar.

CI/CD Entegrasyonu

Son bölümde test script GitHub Actions veya benzeri pipeline'a bağlanır. Required field kaybında build fail edilir. Warning sonuçları artifact olarak saklanır. Katılımcılar küçük pull request ile testi kırıp düzeltir. Böylece structured data gerçek development workflow içinde görülür.

Yazılımcı Olmak İsteyenler Structured Data Konusunda Ne Öğrenmeli?

Structured data öğrenmek isteyen bir geliştiricinin yalnızca Schema.org property isimlerini ezberlemesi gerekmez. HTML, JSON, HTTP, DOM, JavaScript, server-side rendering, test automation ve temel teknik SEO kavramları birlikte çok daha sağlam temel oluşturur. Bu bilgiler schema problemlerinin neden yalnızca SEO problemi olmadığını anlamayı sağlar. Bir JSON-LD bug'ı bazen API contract, bazen hydration, bazen canonical veya cache problemidir. Bu nedenle konu full-stack düşünme becerisi geliştirmek için iyi bir pratik alanıdır.

HTML

HTML sayfanın görünür içeriğini ve structured data script'inin yer aldığı temel dokümanı anlamanızı sağlar. DOM yapısını bilmeden content parity testi yazmak zordur. Head ve body farkları, script etiketleri ve semantic elementler öğrenilmelidir. Source HTML ile rendered HTML ayrımı da burada başlar. Güçlü HTML bilgisi debugging süresini kısaltır.

JSON

JSON-LD için geçerli JSON syntax bilgisi temel gereksinimdir. Object, array, string, number ve escaping kuralları öğrenilmelidir. JavaScript object literal ile JSON aynı şey değildir. Serializer kullanımının avantajı anlaşılmalıdır. Parser error mesajlarını okuyabilmek günlük işte çok yararlıdır.

HTTP

HTTP bilgisi status code, redirect ve erişilebilirlik problemlerini anlamanızı sağlar. 200, 301, 404 ve 500 davranışları structured data görünürlüğüyle ilişkilidir. Header ve caching bilgisi de fiyat stale problemlerinde önemlidir. Bot erişimi authentication ve WAF katmanından etkilenebilir. Schema debugging yalnızca frontend dosyasına bakmaktan çıkmış olur.

DOM

DOM rendered sayfanın programatik temsilidir. Görünür fiyat veya tarih değerini testte almak için DOM selector kullanılır. Client-side JavaScript DOM'u değiştirebilir. Source ve rendered farkı bu nedenle önemlidir. Headless browser testleri DOM bilgisini doğrudan kullanır.

JavaScript

JavaScript client-side schema injection ve modern frontend framework'lerini anlamada önemlidir. Runtime error structured data'nın kaybolmasına yol açabilir. JSON serialization ve object manipulation günlük kullanım alanlarıdır. Promise ve data fetching bilgisi render zamanlamasını anlamayı sağlar. Ancak mümkün olan her şeyi client-side yapmak zorunlu değildir.

Server-Side Rendering

SSR ilk HTML'in server tarafından üretilmesini sağlar. Structured data'nın kaynak HTML içinde bulunması bazı projelerde dayanıklılığı artırır. Cache ve personalization etkileri yine değerlendirilmelidir. Framework'lerin SSR davranışı öğrenilmelidir. Source-output testleri burada değer kazanır.

Test Automation

Test automation structured data bilgisini sürdürülebilir kaliteye dönüştürür. Unit, contract, snapshot ve end-to-end test türleri öğrenilmelidir. Hangi hatanın hangi test seviyesinde yakalanacağı anlaşılmalıdır. CI/CD entegrasyonu release öncesi koruma sağlar. Bu yetkinlik SEO dışındaki yazılım projelerinde de doğrudan değerlidir.

Teknik SEO

Teknik SEO crawl, indexability, canonical, robots ve Search feature mantığını bir araya getirir. Schema validation bu resmin yalnızca bir bölümüdür. Geliştirici temel Search kavramlarını bildiğinde SEO taleplerini daha doğru yorumlar. Aynı şekilde SEO uzmanı yazılım test mantığını öğrendiğinde daha uygulanabilir spesifikasyon yazar. İki disiplinin buluştuğu alan oldukça pratiktir.

Structured Data Yetkinliği Nasıl Ölçülür?

Structured data yetkinliği yalnızca ezberden JSON-LD yazabilmekle ölçülmemelidir. Doğru schema türünü seçmek, valid JSON-LD üretmek, Rich Results Test kullanmak, debugging yapmak, content parity kurmak, otomasyon geliştirmek ve Search Console monitoring yürütmek birlikte değerlendirilmelidir. İyi bir uzman “validator yeşil” sonucundan sonra hangi kontrollerin kaldığını bilir. Ayrıca kaldırılmış feature'ları güncel destekten ayırabilir. Yetkinlik teorik bilgi kadar production problem çözme becerisine dayanır.

Doğru Schema Türünü Seçme

Sayfanın ana entity'sini doğru anlamak ilk yetkinliktir. Her sayfaya Product veya FAQ eklemek doğru yaklaşım değildir. Schema.org vocabulary ve Google feature desteği ayrı kontrol edilmelidir. Business bağlamı okunmalıdır. Seçim gerekçesi teknik spesifikasyonda açıklanabilmelidir.

JSON-LD Yazma

Geçerli JSON-LD yazmak temel beceridir. Nested object, array, @id ve @graph kavramları anlaşılmalıdır. Gerçek veri kaynaklarından output üretmek elle statik kod yazmaktan daha değerlidir. Serializer ve typed model kullanılmalıdır. Güvenli escaping de dikkate alınmalıdır.

Rich Results Test Kullanma

Aracı açıp URL girmek tek başına yetkinlik değildir. Sonucun hangi Google feature kapsamını temsil ettiğini bilmek gerekir. Error ile warning ayrımı doğru yorumlanmalıdır. Eligibility ile actual appearance birbirine karıştırılmamalıdır. Unsupported sonucu Schema.org invalid diye etiketlenmemelidir.

Debugging

Debugging sorunu doğru katmana yerleştirme becerisidir. Syntax, semantic, Google eligibility, render veya indexability problemi birbirinden ayrılmalıdır. Sistematik checklist kullanılmalıdır. Release diff ve data source incelenmelidir. Rastgele property ekleyip çıkarma yaklaşımı yerine root cause bulunmalıdır.

Content Parity Testi

Content parity güçlü structured data mühendisliğinin ayırt edici özelliklerinden biridir. DOM ve JSON-LD aynı gerçek veriyi temsil etmelidir. Price, availability ve date assertion yazılabilir. Normalization kuralları anlaşılmalıdır. Bu test semantic kaliteyi otomasyona dönüştürür.

Automation

Automation tekrar eden manuel kontrolleri pipeline'a taşır. Parser, type, required field ve smoke test geliştirilebilir. Büyük sitelerde crawl ve dashboard kurulabilir. Severity ve alert tasarımı önemlidir. Amaç her şeyi otomatikleştirmek değil yüksek değerli hataları erken yakalamaktır.

Search Console Monitoring

Production sonrası monitoring uzun vadeli yetkinliğin parçasıdır. Error trendi, fix validation ve Search appearance verileri okunmalıdır. Search Console'un gecikmeli production sinyali olduğu bilinmelidir. Internal testlerle birlikte yorumlanmalıdır. Feature deprecation rapor değişikliklerinden ayrıştırılmalıdır.

“En İyi Yazılımcı” Structured Data Testinde Nasıl Fark Yaratır?

Structured data konusunda güçlü bir geliştirici yalnızca geçerli JSON üretmekle yetinmez. Sayfanın search intent'ini ve gerçek entity'sini anlamaya çalışır, güncel Google kurallarını kontrol eder ve schema'yı gerçek veri kaynağıyla eşleştirir. Regression test yazar, deployment sonrası production sonucunu ölçer ve hatayı yalnızca SEO ekibinin bulmasını beklemez. Böyle bir yaklaşım yazılım kalitesi ile teknik SEO'yu aynı engineering disiplini içinde ele alır. Fark yaratan nokta çok property bilmek değil güvenilir sistem kurmaktır.

Sadece Geçerli JSON Üretmez

Geçerli JSON ilk seviyedir. Güçlü geliştirici Schema.org semantic doğruluğunu ve Google eligibility şartlarını ayrıca inceler. Content parity ve indexability katmanlarını bilir. Test sonuçlarını doğru terminolojiyle raporlar. Böylece false confidence oluşmasını engeller.

Search Intent'i Anlar

Sayfanın kullanıcı açısından ne sunduğunu anlamak doğru entity seçimini kolaylaştırır. Ürün listeleme sayfası ile tek ürün sayfası aynı schema hedefini taşımayabilir. Search intent sadece anahtar kelime konusu değildir. Sayfa amacı, content modeli ve entity ilişkisi birlikte değerlendirilir. Teknik uygulama bu anlayışa dayanır.

Google Kurallarını Kontrol Eder

Eski blog yazısını kopyalamak yerine güncel Search Central dokümanına bakar. Feature'ın active, limited veya removed durumunu kontrol eder. Required property listesini güncel tutar. Değişiklikleri registry'ye işler. Böylece 2026'da kaldırılmış FAQ rich result hedefi için gereksiz geliştirme yapmaz.

Gerçek Veriyi Schema ile Eşleştirir

Fiyat, stok ve yazar gibi alanları gerçek domain modelinden alır. Hard-coded değer kullanmaz. DOM ve JSON-LD aynı source of truth üzerinden beslenir. Gerekirse parity assertion yazar. Bu yaklaşım hem SEO hem kullanıcı güvenini korur.

Regression Test Yazar

Bir bug düzeltildiğinde aynı hatanın tekrarını engelleyen test ekler. Fixture gerçek incident'i temsil eder. Required field veya duplicate detector rule set'e dahil edilir. CI/CD merge öncesi problemi yakalar. Böylece ekip her release'te aynı manuel kontrolü tekrar etmez.

Production Sonucunu Ölçer

Local test başarılı diye işi bitmiş saymaz. Production smoke test ve monitoring kurar. Search Console trendlerini release timeline ile karşılaştırır. Actual appearance ile eligibility farkını bilir. Engineering sonucu gerçek sistem davranışıyla doğrular.

SEO Ekibi ile Yazılım Ekibi Arasında Sorumluluk Dağılımı

Structured data projelerinde sorumluluğun tek ekibe bırakılması sık sık bakım problemi yaratır. SEO ekibi schema türü, Google Search feature ve güncel gereksinimleri tanımlayabilir. Product gerçek veri ve business rule'ları, development uygulamayı, QA test kapsamını, DevOps pipeline'ı ve data ekibi veri kalitesini sahiplenebilir. Ortak ownership modelinde karar noktaları açıkça belgelenir. Böylece “schema SEO'nun işi” veya “kod geliştiricinin işi” şeklindeki kopuk yaklaşım yerine ortak kalite modeli oluşur.

SEO — Schema Türü ve Search Feature

SEO ekibi sayfanın hangi Search feature hedefiyle ilişkilendirildiğini tanımlar. Güncel Google dokümantasyonunu ve deprecation durumunu takip eder. Required ve recommended alanları spesifikasyona işler. Teknik implementation detayını development ile birlikte değerlendirir. Search performance monitoring sonucunu paylaşır.

Product — Gerçek Veri ve İş Kuralı

Product ekibi fiyatın, stok durumunun veya event lifecycle'ın business anlamını bilir. Schema generator bu gerçekliği kendi başına yeniden icat etmemelidir. Hangi fiyatın public offer olduğu product rule ile belirlenir. Edge case fixture'ları product bilgisiyle oluşturulur. Böylece teknik doğru fakat business açısından yanlış markup önlenir.

Development — Uygulama

Development ekibi schema generator, render ve entegrasyon kodunu geliştirir. Type-safe model ve serializer kullanır. Unit ve contract testleri yazar. Performance ve security etkilerini de değerlendirir. Production bug root cause çözümünde ana teknik sorumluluk alır.

QA — Test

QA happy path ve edge case senaryolarını doğrular. Staging URL'lerinde expected type ve content parity kontrolleri yapabilir. Regression fixture setini yönetebilir. Manual tool sonuçlarını release kaydına ekler. Otomasyon kapsamındaki boşlukları development ekibine bildirir.

DevOps — Pipeline

DevOps CI/CD quality gate ve post-deploy smoke test altyapısını sağlar. Test artifact ve alert mekanizmasını yönetir. Environment farklılıklarının production output'a sızmamasını kontrol eder. Rollback sürecini hazır tutar. Monitoring job'larının güvenilir çalışmasını destekler.

Data — Veri Kalitesi

Data veya backend ekipleri structured data'ya kaynak olan ürün, review ve event verisinin doğruluğunu sağlar. Duplicate ID veya eksik brand gibi sorunlar frontend'de çözülemez. Data validation upstream seviyede yapılmalıdır. Schema audit sonuçları data quality backlog'una girdi olabilir. Ortak metric sistemi ekipleri aynı soruna bağlar.

Ortak Ownership

Structured data birçok katmana yayıldığı için ortak ownership en gerçekçi modeldir. Bununla birlikte her görev için primary owner bulunmalıdır. RACI matrisi bu ayrımı görünür hale getirir. Incident sırasında karar mekanizması hızlanır. Governance owner farklı ekiplerin koordinasyonunu sağlayabilir.

Structured Data RACI Matrisi

RACI matrisi structured data sürecinde kimin sorumlu, hesap veren, danışılan ve bilgilendirilen olduğunu açık hale getirir. Schema specification, implementation, testing, approval, release, monitoring, incident response ve deprecation migration ayrı satırlar olarak tanımlanabilir. Büyük ekiplerde bu basit tablo iletişim boşluklarını önemli ölçüde azaltır. Özellikle feature deprecation gibi nadir fakat etkili olaylarda kimin aksiyon alacağı önceden bellidir. RACI teknik kalitenin yanı sıra operasyonel süreklilik sağlar.

Schema Specification

Specification aşamasında SEO ve development birlikte çalışmalıdır. SEO Search feature gereksinimini, development uygulanabilir veri modelini değerlendirir. Product gerçek business verisini doğrular. Required ve recommended alanlar kayda alınır. Doküman versiyonlanır.

Implementation

Implementation development ekibinin ana sorumluluğundadır. Typed generator, integration ve render davranışı burada geliştirilir. SEO gerektiğinde property anlamı konusunda danışılır. Product data mapping'i doğrular. Code review testleri kontrol eder.

Testing

Testing QA ve development arasında paylaşılabilir. Unit test geliştirici, staging acceptance QA tarafından yürütülebilir. SEO Rich Results ve Search feature kontrolüne katkı sağlar. Otomasyon mümkün oldukça manuel yük azaltılır. Fixture set ortak artifact haline gelir.

Approval

Approval risk seviyesine göre farklı ekiplerden gelebilir. Basit refactor development review ile yeterli olabilir. Yeni Search feature uygulamasında SEO onayı gerekebilir. Fiyat veya review business rule değişiminde product da değerlendirme yapar. Gereksiz onay zinciri oluşturulmamalıdır.

Release

Release DevOps pipeline üzerinden standardize edilir. Schema testleri diğer kalite kontrolleriyle aynı süreçte çalışır. Critical fail deployment'ı durdurabilir. Release metadata monitoring dashboard'a aktarılır. Post-deploy validation otomatik tetiklenebilir.

Monitoring

Monitoring SEO ve engineering ortak sorumluluğudur. Internal health metrics engineering, Search Console performance SEO tarafından daha yoğun takip edilebilir. Alert owner template'e göre yönlenir. Trend toplantılarında önemli değişiklikler paylaşılır. Data source incident'leri ilgili ekibe aktarılır.

Incident Response

Incident response severity ve etkiye göre koordine edilir. Development root cause, SEO Search etkisi ve DevOps rollback sürecini yönetebilir. Product kritik ticari veri hatalarında dahil olur. Tek communication owner belirlemek yararlıdır. Postmortem ortak yapılmalıdır.

Deprecation Migration

Deprecation migration genellikle SEO tarafından başlatılan fakat development tarafından uygulanan süreçtir. Registry status değişikliği ticket tetikleyebilir. Etkilenen URL ve business değer değerlendirilir. Kod kaldırma veya alternatif feature kararı verilir. Monitoring yeni duruma uyarlanır.

Structured Data Definition of Done

Structured Data Definition of Done, bir schema geliştirmesinin gerçekten tamamlanmış sayılması için ortak kalite kriterleri belirler. Doğru @type, required property, recommended alan değerlendirmesi, Schema.org validation, Rich Results Test, content parity, mobile render, duplicate kontrolü ve production smoke test bu kriterler arasında yer alabilir. Böylece “kod yazıldı” ile “özellik production'da güvenilir çalışıyor” arasındaki fark görünür olur. Definition of Done proje riskine göre sadeleştirilebilir. Kritik nokta validation, regression ve production monitoring katmanlarının birlikte düşünülmesidir.

Doğru @type Kullanıldı

Sayfanın ana entity'siyle uyumlu type seçilmelidir. Route contract bunu otomatik doğrulayabilir. Google Search hedefi varsa feature desteği ayrıca kontrol edilir. Generic veya alakasız type kullanılmamalıdır. Review sırasında seçim gerekçesi açık olmalıdır.

Required Property'ler Var

Hedef feature için güncel required property listesi eksiksiz olmalıdır. Değerlerin yalnızca mevcut değil geçerli type ve gerçek veri taşıdığı kontrol edilmelidir. Null ve placeholder kabul edilmemelidir. Unit test bu kriteri korur. Coverage kritik template'lerde yüzde yüz hedeflenebilir.

Recommended Property'ler Değerlendirildi

Recommended alanların tamamını zorunlu olarak eklemek gerekmez. Ancak her biri iş değeri ve veri kullanılabilirliği açısından değerlendirilmelidir. Eklenmeyen önemli alan için gerekçe bulunabilir. Warning backlog'a alınabilir. Böylece validator uyarıları bilinçli yönetilir.

Schema.org Validation Geçti

General vocabulary doğrulaması semantic modelin temel kontrolüdür. Type, property ve value ilişkileri incelenir. Google'a özel eligibility ile aynı test değildir. Hata varsa generator düzeltilir. Sonuç release kaydına eklenebilir.

Rich Results Test Geçti

Google tarafından desteklenen feature hedefleniyorsa representative URL veya kod Rich Results Test ile doğrulanmalıdır. Critical error bulunmamalıdır. Warning'ler değerlendirilmelidir. Eligibility actual appearance garantisi olarak yazılmamalıdır. Feature support güncelliği ayrıca kontrol edilmelidir.

Content Parity Geçti

Schema kritik alanları görünür sayfa içeriğiyle eşleşmelidir. Product için price ve availability, Article için headline ve date örnek olabilir. Automated assertion tercih edilir. Manuel QA ek kontrol sağlayabilir. Mismatch kritikse release durdurulur.

Mobile Render Geçti

Mobil render içinde beklenen schema bulunmalıdır. Ana entity desktop ile çelişmemelidir. Client-side JavaScript hatası markup'ı kaybettirmemelidir. Googlebot Smartphone perspektifi representative URL'de kontrol edilebilir. Mobile diff raporu saklanabilir.

Duplicate Schema Yok

Aynı entity'nin çelişkili duplicate node'ları bulunmamalıdır. Tema, plugin, GTM ve custom code kaynakları incelenir. Duplicate detector otomatik çalışabilir. Gerçek çoklu entity sayfaları false positive olmamalıdır. Ownership net olmalıdır.

Production Smoke Test Geçti

Deployment sonrası kritik URL seti yeniden test edilmelidir. HTTP 200, expected type, required fields ve parity kontrol edilir. Hata varsa alert üretilir. Bu aşama staging ile production arasındaki farkı yakalar. Feature ancak bu kontrolden sonra tam tamamlanmış kabul edilebilir.

Structured Data Release Checklist

Release checklist, structured data değişikliğini production'a taşımadan önce güncellik ve kalite kontrollerini kısa bir listede toplar. Google'ın ilgili type'ı hâlâ destekleyip desteklemediği, required property'lerin güncel olup olmadığı, fixture'ların hazır bulunması, staging ve mobile testlerin tamamlanması, Search Console baseline ve monitoring hazırlığı değerlendirilir. Böyle bir checklist özellikle nadir schema release'lerinde unutulan adımları azaltır. Otomatik kontroller mümkün olduğunca pipeline'a taşınmalıdır. Manuel checklist yalnızca otomasyonun kapsamadığı karar noktalarına odaklanmalıdır.

Google Bu Type'ı Hâlâ Destekliyor mu?

Release öncesinde güncel Google Search feature desteği doğrulanmalıdır. Eski implementation aylarca feature branch'te kaldıysa status değişmiş olabilir. Registry son kontrol tarihi incelenir. Removed feature için yeni release yapılmaz. Semantic ihtiyaç varsa amaç ayrıca belgelenir.

Required Properties Güncel mi?

Required listesi güncel dokümantasyonla karşılaştırılmalıdır. Rule set eskiyse CI yanlış güven verebilir. Yeni alan gerekiyorsa fixture ve model güncellenir. Gerçek veri kaynağı doğrulanır. Placeholder ile requirement karşılanmış sayılmaz.

Test Fixture'lar Güncel mi?

Fixture'lar gerçek data modelinin güncel sürümünü temsil etmelidir. API migration sonrası eski fixture testleri anlamsız hale gelebilir. Edge case seti son incident'leri içermelidir. Snapshot bilinçli güncellenir. Test datası production PII içermemelidir.

Staging Test Edildi mi?

Staging render representative route'larda kontrol edilmelidir. External validator erişemiyorsa internal browser test çalıştırılır. Source ve rendered HTML gerektiğinde karşılaştırılır. CMS gerçek fixture verisiyle denenir. Critical sorun çözülmeden production'a geçilmez.

Mobile Test Edildi mi?

Mobil render ana entity ve kritik property açısından doğrulanmalıdır. Desktop'ta çalışan markup mobilde kaybolmamalıdır. Device-specific template varsa özel test gerekir. Mobile viewport tek başına user-agent farkını temsil etmeyebilir. Test yöntemi mimariye göre seçilir.

Search Console Baseline Alındı mı?

Büyük schema release'inden önce mevcut valid, invalid ve performance metrikleri kaydedilebilir. Release sonrası değişim bu baseline ile karşılaştırılır. Feature reporting değişikliği ayrıca not edilmelidir. Baseline nedensellik garantisi sağlamaz. Ancak debugging için değerli referans sunar.

Monitoring Hazır mı?

Release sonrası kimin hangi alert'i takip edeceği belli olmalıdır. Smoke test job aktif olmalıdır. Search Console ve internal dashboard owner'ı atanmalıdır. Critical error notification kanalı test edilebilir. Monitoring olmadan production release yarım kalmış süreçtir.

30 Günlük Yapılandırılmış Veri Test İyileştirme Planı

İlk 30 günün amacı mevcut durumu anlamak ve en kritik hataları temizlemektir. Önce schema envanteri çıkarılır, desteklenen ve deprecated type'lar ayrılır. Representative URL'ler Rich Results Test ve Schema.org Validator ile kontrol edilir. Critical error'lar ve duplicate schema problemleri önceliklendirilir. Bu aşamada ileri otomasyondan önce temel gerçekliği görünür hale getirmek daha doğrudur.

Schema Envanteri

Site crawl ile kullanılan type'lar listelenir. Template, URL sayısı ve source bilgisi eklenir. Tema, plugin ve custom code kaynakları ayrıştırılır. Duplicate üreticiler işaretlenir. Envanter sonraki governance çalışmalarının temelidir.

Supported / Deprecated Type Analizi

Her type Google Search feature status ile eşleştirilir. Active, limited, deprecated ve removed etiketleri atanır. FAQ ve HowTo gibi eski hedefler ayrıca incelenir. Son kontrol tarihi kaydedilir. Migration ihtiyacı belirlenir.

Rich Results Test

Her kritik template için representative URL test edilir. Required ve warning sonuçları kayda alınır. Unsupported durum güncel support listesiyle karşılaştırılır. Tek URL sonucu site geneline genellenmez. Edge case URL'ler ayrıca seçilir.

Schema.org Validation

General vocabulary doğrulaması Google testinden ayrı yürütülür. Invalid property ve type ilişkileri temizlenir. JSON syntax sorunları önceden parser ile çözülür. Sonuçlar template bazında gruplanır. Teknik borç listesi oluşturulur.

Critical Error Fix

En yüksek öncelik required property ve parse gibi critical sorunlardır. Root cause template veya data source seviyesinde düzeltilir. Regression test eklenir. Production deploy sonrası smoke test yapılır. Search Console validation gerektiğinde başlatılır.

Duplicate Schema Analizi

Aynı entity'yi üreten plugin, tema ve custom code kaynakları bulunur. Çelişkili node'lar önceliklendirilir. Tek owner seçilir. Gereksiz generator kapatılır. Migration sonrası duplicate detector yeniden çalıştırılır.

31–60 Günlük Plan

İkinci 30 günlük dönemde temel validation'ın üzerine semantic ve otomasyon katmanları eklenir. Content parity testleri oluşturulur, fixture setleri genişletilir ve mobile ile rendered HTML kontrolleri devreye alınır. Kritik generator'lar için CI unit testleri yazılır. Structured data dashboard ilk sürümü hazırlanır. Ownership modeli netleştirilerek sorunların kimin tarafından takip edileceği belirlenir.

Content Parity Testleri

İlk olarak fiyat, stok, headline ve tarih gibi kritik alanlar seçilir. DOM ve JSON-LD değerleri normalize edilerek karşılaştırılır. Mismatch severity belirlenir. Template bazlı selector adapter oluşturulur. Test sonuçları dashboard'a aktarılır.

Test Fixture'lar

Happy path dışında gerçek edge case'ler eklenir. İndirimli, stoksuz ve reviewsuz ürünler iyi başlangıçtır. Article ve Event için tarih varyasyonları bulunur. Her incident yeni fixture fırsatı olarak değerlendirilir. Fixture ownership QA ve development arasında paylaşılabilir.

Mobile / Render Kontrolleri

Headless browser mobile ve desktop render çalıştırır. Structured data type setleri karşılaştırılır. Client-side injection ve hydration problemleri raporlanır. Source-render diff kritik route'larda tutulur. JavaScript error'ları ayrıca kaydedilir.

CI Unit Testleri

JSON parse, required fields ve type assertions pull request aşamasına eklenir. Hızlı fixture testleri bütün PR'larda çalışır. Critical fail merge'i bloklar. Warning artifact olarak sunulur. Test süresi developer deneyimini bozmayacak düzeyde tutulur.

Structured Data Dashboard

İlk dashboard template, type, valid, warning, error ve last tested alanlarını gösterebilir. Crawl ve CI verileri ayrı kaynak etiketi alır. Trend grafikleri sonradan eklenebilir. Owner filtreleri operasyonu kolaylaştırır. Dashboard karar vermeyi destekleyecek kadar sade tutulmalıdır.

Ownership Modeli

SEO, development, QA, DevOps ve product rolleri belirlenir. Registry ve rule set için primary owner atanır. Incident escalation yolu tanımlanır. RACI matrisi oluşturulabilir. Ownership olmadan otomasyon alarmları kolayca sahipsiz kalır.

61–90 Günlük Plan

Üçüncü 30 günlük dönem structured data kalite sürecini sürekli yönetişim modeline taşır. CI/CD quality gate, production smoke test, automated crawl ve deprecation monitoring birlikte çalışmaya başlar. Search Console alerting ve internal dashboard trendleri ilişkilendirilir. Ekip belirli aralıklarla schema retrospective yapar. Böylece test sistemi yalnızca bir proje olarak kurulup unutulmaz, sürekli geliştirilen operasyonel bir yeteneğe dönüşür.

CI/CD Quality Gate

Critical rule set production release için gate haline getirilir. Parse, missing required ve kritik parity error deployment'ı durdurabilir. Warning'ler ayrı raporlanır. Gate policy version-controlled tutulur. False positive oranı düzenli gözden geçirilir.

Production Smoke Test

Her release sonrası kritik URL listesi otomatik kontrol edilir. Expected type, required fields, HTTP status ve parity ölçülür. Hata deployment ID ile ilişkilendirilir. Alert doğrudan owner'a gider. Gerekiyorsa rollback playbook devreye girer.

Automated Crawl

Periyodik crawl daha geniş URL kapsamını test eder. Template sampling ve risk sampling birlikte kullanılabilir. Error aggregation dashboard'a aktarılır. Site kapasitesine uygun crawl rate belirlenir. Yeni hata pattern'i incident açabilir.

Deprecation Monitoring

Google Search documentation update takip mekanizması kurulur. Registry status değişiklikleri owner'a bildirilir. Etkilenen URL sayısı otomatik hesaplanabilir. Migration ticket oluşturulur. Removed feature monitoring metric'leri güncellenir.

Search Console Alerting

Search Console verisindeki belirgin invalid artışı düzenli kontrol edilebilir. API veya export altyapısı uygunsa internal dashboard'a aktarılır. Gecikmeli veri olduğu unutulmamalıdır. Internal crawl erken uyarı sağlar. İki kaynak birlikte daha güçlü monitoring oluşturur.

Schema Retrospective

Belirli aralıklarla schema incident ve trendleri gözden geçirilir. En sık hata kategorileri çıkarılır. Test rule set ve fixture backlog'u güncellenir. Deprecated type borcu değerlendirilir. Bu toplantı yalnızca SEO değil ilgili engineering ekiplerini de içerebilir.

Yapılandırılmış Veri Test Olgunluk Modeli

Structured data test olgunluk modeli ekiplerin mevcut seviyesini ve sonraki gelişim adımını anlamasına yardımcı olur. Seviye 0'da test yoktur, Seviye 1'de manuel Rich Results Test başlar. Seviye 2 çift validator yaklaşımını, Seviye 3 content ve render testlerini, Seviye 4 CI/CD regression testing'i ve Seviye 5 sürekli governance modelini temsil eder. Her ekibin doğrudan en yüksek seviyeye çıkması gerekmez. Kritik olan bir sonraki en değerli kontrolü sistematik biçimde eklemektir.

Seviye 0 — Test Yok

Bu seviyede ekip plugin veya generator'ın doğru çalıştığını varsayar. Hatalar genellikle production'da Search Console üzerinden geç fark edilir. Structured data ownership belirsizdir. Regression kontrolü bulunmaz. İlk hedef basit manuel validation rutini kurmaktır.

Seviye 1 — Manuel Rich Results Test

Kritik URL'ler release öncesi manuel olarak test edilir. Bu adım hiç test olmamasına göre büyük ilerlemedir. Ancak tek araç ve tek URL sınırlı kapsama sahiptir. Checklist ile süreç standardize edilebilir. Sonraki adım Schema.org validation eklemektir.

Seviye 2 — Rich Results + Schema.org Validation

İki farklı doğruluk katmanı artık ayrı kontrol edilir. Required ve recommended alan farkı anlaşılır. Search Console monitoring temel seviyede yapılır. Yine de content parity ve render regression otomasyonu eksiktir. Sonraki yatırım semantic testlere yönelir.

Seviye 3 — Content ve Render Testleri

DOM ile JSON-LD karşılaştırılmaya başlanır. Mobile ve rendered HTML kontrolleri devreye girer. Duplicate detection ve template fixtures kullanılır. Structured data yalnızca validator kodu olmaktan çıkar. CI otomasyonu için güçlü temel oluşur.

Seviye 4 — CI/CD Regression Testing

Unit, contract, snapshot ve smoke test pipeline'a bağlanır. Critical fail merge veya deployment'ı durdurabilir. Production monitoring release metadata ile ilişkilendirilir. Regression sayısı azalır. Sonraki adım feature lifecycle governance'dır.

Seviye 5 — Continuous Structured Data Governance

En yüksek seviyede Search feature lifecycle, deprecation monitoring, health dashboard, SLO ve incident playbook birlikte çalışır. Structured data sürekli bakım gerektiren ürün yeteneği gibi yönetilir. Ownership nettir. Yeni Google değişiklikleri rule set'e düzenli yansır. Ekip validation, regression ve monitoring süreçlerini tek operasyon altında birleştirir.

Seviye 0 — Test Yok

Test yapılmayan modelde structured data çoğu zaman eklentiye veya yıllar önce yazılmış template koduna emanet edilir. Kodun gerçekten production'da ne ürettiği düzenli olarak bilinmez. Search Console hata raporu çıktığında reaktif çalışma başlar. Feature deprecation veya duplicate markup aylarca fark edilmeyebilir. En küçük iyileştirme, kritik birkaç URL için düzenli manuel kontrol başlatmaktır.

Plugin'e Güvenmek

Plugin kullanmak kötü değildir, ancak plugin output'unu hiç kontrol etmemek risktir. Tema veya başka eklenti duplicate schema üretebilir. Plugin güncellemesi davranışı değiştirebilir. Gerçek URL test edilmelidir. Ownership “plugin yapıyor” cümlesiyle bırakılmamalıdır.

Production'da Hataları Geç Fark Etmek

Search Console güçlü bir production sinyali olsa da anlık build testi değildir. Regression günler sonra fark edilebilir. Critical Product schema kaybında bu süre değerli olabilir. Basit smoke test detection süresini ciddi biçimde düşürür. Erken geri bildirim her yazılım sisteminde olduğu gibi burada da önemlidir.

Search Console'a Reaktif Bakmak

Yalnızca hata geldiğinde Search Console açmak proaktif monitoring değildir. Trendler periyodik izlenmelidir. Release annotation ile değişimler ilişkilendirilebilir. Internal crawler daha hızlı sinyal sağlayabilir. İki sistem birlikte daha güçlü operasyon oluşturur.

Seviye 1 — Manuel Validation

Manuel validation seviyesinde ekip kritik URL'leri Rich Results Test üzerinden düzenli olarak kontrol etmeye başlar. Release öncesi checklist bulunması sürecin kişiden bağımsız hale gelmesine yardımcı olur. Bu yöntem küçük sitelerde uzun süre faydalı olabilir. Ancak template sayısı ve release sıklığı arttıkça manuel kontrolün ölçek sınırı ortaya çıkar. Sonraki gelişim adımı ikinci validator ve otomatik temel testlerdir.

Kritik URL Testi

En yüksek trafik veya business değeri taşıyan birkaç URL seçilir. Her ana template temsil edilmelidir. Tek homepage testi structured data sağlığını göstermez. Edge case ürün veya içerik de eklenebilir. Test sonuçları release kaydında tutulmalıdır.

Rich Results Test

Manuel süreçte Rich Results Test Google eligibility açısından temel araçtır. Error ve warning ayrımı doğru yorumlanmalıdır. Unsupported type güncel Search feature desteğiyle karşılaştırılır. Valid sonucu gösterim garantisi sayılmaz. Bu bilgi checklist notuna eklenmelidir.

Release Öncesi Manuel Checklist

Checklist test URL'leri, expected type ve required property kontrolünü içerebilir. Mobile veya canonical kontrolü de kritik projelerde eklenir. Liste çok uzun tutulursa uygulanmaz hale gelir. Otomatikleştirilebilen adımlar zamanla CI'a taşınmalıdır. Checklist karar gerektiren kontrollerde kalmalıdır.

Seviye 2 — Çift Validator

Çift validator seviyesinde ekip Google Rich Results Test ile Schema.org Validator'ın farklı amaçlara hizmet ettiğini kabul eder. Genel semantic validation ve Google Search eligibility ayrı test edilir. Required ve recommended property ayrımı operasyonel hale gelir. Search Console monitoring düzenli rutine eklenir. Bu seviye yanlış “schema geçerli, o halde kesin görünür” varsayımını önemli ölçüde azaltır.

Rich Results Test

Google Search feature hedefi açısından representative URL'ler test edilir. Eligibility sonucu kaydedilir. Feature support güncelliği kontrol edilir. Error ve warning severity mapping yapılır. Sonuç Schema.org validation ile karıştırılmaz.

Schema.org Validator

General vocabulary uyumluluğu ayrıca incelenir. Google'ın desteklemediği entity türleri burada yine semantic olarak değerlendirilebilir. Type ve property hataları temizlenir. Farklı formatlar gerektiğinde kontrol edilir. İki test sonucunun neden farklı olabileceği ekipçe anlaşılır.

Required / Recommended Ayrımı

Required sorunlar yüksek öncelikli blocker olarak tanımlanır. Recommended eksikler warning olarak yönetilir. İş değeri yüksek warning'ler backlog'a alınır. Sahte veriyle warning kapatılmaz. Bu severity modeli sonraki CI otomasyonunun temelidir.

Search Console Monitoring

Geçerli ve geçersiz öğe trendleri periyodik izlenir. Fix validation süreci öğrenilir. Search appearance verileri uygun olduğunda performans analizine eklenir. Reporting değişiklikleri deprecation ile ilişkilendirilir. Monitoring artık reaktif olmaktan çıkar.

Seviye 3 — Semantic Testing

Semantic testing seviyesinde structured data artık yalnızca validator çıktısıyla değerlendirilmez. Content parity, rendered HTML, mobile parity, duplicate detection ve template fixture testleri devreye girer. Bu aşama gerçek sayfa ile schema arasındaki anlam bütünlüğünü ölçer. Fiyat ve stok gibi kritik business verileri otomatik karşılaştırılabilir. Ekip CI/CD otomasyonuna geçmek için güçlü test sözleşmeleri geliştirmiş olur.

Content Parity

DOM ve JSON-LD kritik değerleri karşılaştırılır. Fiyat, stok, rating, date ve author örnek alanlardır. Normalize kuralları dokümante edilir. Mismatch severity business etkisine göre belirlenir. Source of truth problemleri görünür hale gelir.

Rendered HTML

Headless browser client-side structured data'yı doğrular. Runtime error ve hydration sorunları test edilir. Source ve rendered output karşılaştırılabilir. JavaScript injection güvenilirliği ölçülür. Mobile render ayrıca çalıştırılabilir.

Mobile Parity

Mobil ve masaüstü ana entity'leri karşılaştırılır. Product veya Article bilgilerinin cihaz bazında kaybolmaması beklenir. User-agent farklılığı varsa ayrı test yapılır. Diff allowlist ile false positive azaltılır. Mobile-first bağlamı dikkate alınır.

Duplicate Detection

Aynı entity'nin birden fazla generator tarafından üretilmesi otomatik yakalanır. ID, URL, SKU ve type kombinasyonları kullanılabilir. Gerçek çoklu entity sayfaları hariç tutulur. Plugin update sonrası duplicate artışı alert üretebilir. Ownership tek kaynağa taşınır.

Template Fixtures

Her ana template için edge case fixture seti bulunur. Product indirim, stok ve review durumlarını kapsar. Article tarih ve author varyasyonlarını içerir. Event lifecycle ayrıca test edilir. Fixture seti production incident'leriyle sürekli geliştirilir.

Seviye 4 — Automated Regression

Automated Regression seviyesinde structured data testlerinin önemli bölümü CI/CD ve production monitoring içine taşınmıştır. Unit test generator mantığını, contract test veri ilişkisini, snapshot yapısal değişikliği ve smoke test gerçek deployment sonucunu kontrol eder. Critical kurallar quality gate olarak merge veya release'i engelleyebilir. Developer feedback hızlıdır. Search Console artık ilk hata tespit noktası değil production doğrulama katmanlarından biri olur.

Unit Test

Generator fonksiyonları hızlı fixture setiyle test edilir. Parse, type ve required field assertion bulunur. API mapping edge case'leri eklenir. Test her PR'da çalışır. Hata geliştiriciye saniyeler içinde geri döner.

Contract Test

Schema ile domain model arasındaki veri sözleşmesi doğrulanır. API change breaking davranış üretirse test fail olur. Content parity internal seviyede ölçülebilir. Business rule değişikliği bilinçli contract update gerektirir. Silent regression azalır.

Snapshot

JSON-LD yapısal diff code review'a taşınır. Yeni veya kaybolan property görünür olur. Duplicate node kolayca fark edilir. Reviewer bilinçli şekilde snapshot update eder. Critical assertion snapshot'tan bağımsız kalır.

CI/CD Gate

Parse error ve missing required field gibi sorunlar gate olarak tanımlanır. Warning merge'i durdurmaz. Policy repository içinde version-controlled tutulur. False positive oranı izlenir. Gate ekip tarafından güvenilir kabul edilmelidir.

Production Smoke Test

Deployment sonrası representative URL'ler gerçek ortamda doğrulanır. HTTP status, expected type, required fields ve parity test edilir. Alert release ID ile birlikte üretilir. Rollback gerekirse hızlı uygulanır. Production gerçekliği otomatik kalite zincirine bağlanır.

Seviye 5 — Continuous Governance

Continuous Governance seviyesinde structured data yalnızca kod değil sürekli yönetilen Search ve veri yeteneği olarak ele alınır. Search feature lifecycle, automated deprecation warning, health dashboard, SLO, incident playbook ve continuous improvement aynı model içinde çalışır. Google feature değişikliği geldiğinde registry ve test rule set güncellenir. Hatalar production incident süreçleriyle yönetilir. Bu seviye büyük ve sık değişen sitelerde en sürdürülebilir yaklaşımdır.

Search Feature Lifecycle

Her Google feature active durumdan deprecation veya removal aşamasına geçebilir. Registry yaşam döngüsünü takip eder. Son güncelleme tarihi ve doküman kaynağı bulunur. Migration ticket otomatik oluşturulabilir. Böylece eski Search hedefleri kodda unutulmaz.

Automated Deprecation Warning

Crawler detected type'ları registry ile karşılaştırır. Deprecated veya removed feature ilişkisi varsa warning üretir. Type'ın Schema.org açısından geçerliliği ayrı tutulur. Ekip migration gereksinimini değerlendirir. Warning rollout planına dönüşebilir.

Health Dashboard

Dashboard teknik ve lifecycle metriklerini birleştirir. Valid, error, mismatch ve deprecated oranları template bazında görülür. Release annotation trendle ilişkilendirilir. Owner ve last tested bilgisi operasyonu destekler. Tek skor yerine detay bileşenleri görünür tutulur.

SLO

SLO kritik template'lerde required coverage ve recovery time gibi hedefler belirler. Gerçekçi ve ölçülebilir olmalıdır. Warning ile critical error ayrılır. Hedef ihlali postmortem veya improvement action tetikleyebilir. SLO ekipler arası ortak beklenti oluşturur.

Incident Playbook

Alert geldiğinde izlenecek adımlar önceden bellidir. Scope, last release, root cause ve rollback kontrol edilir. Search Console validation daha sonra takip edilir. Postmortem test boşluğunu kapatır. Böylece schema incident kişisel deneyime bağlı kalmaz.

Continuous Improvement

Her incident ve Google feature değişikliği test sistemine yeni bilgi ekler. Fixture ve rule set güncellenir. False positive'ler azaltılır. Dashboard kullanılmayan metriklerden arındırılır. Governance statik doküman değil yaşayan süreç olur.

Yapılandırılmış Veri Testlerinde Sık Yapılan Hatalar

Structured data projelerinde en sık yapılan hataların önemli bölümü araç kullanımından değil yanlış varsayımlardan kaynaklanır. Sadece Rich Results Test kullanmak, valid sonucu gösterim garantisi sanmak veya Schema.org'daki her type'ın Google'da desteklendiğini düşünmek bunların başında gelir. Eski FAQ ve HowTo rehberlerini uygulamak 2026 itibarıyla ayrıca belirgin bir güncellik problemidir. Recommended warning'leri critical error sanmak veya sayfa içeriğiyle schema'yı hiç karşılaştırmamak da süreç kalitesini düşürür. Plugin'e güvenmek, tek URL test etmek ve release sonrası izleme yapmamak aynı risk zincirini tamamlar.

Sadece Rich Results Test Kullanmak

Rich Results Test Google eligibility için değerlidir, fakat genel Schema.org vocabulary kontrolünün tamamını temsil etmez. Parser, semantic validator ve content parity ayrıca gereklidir. Unsupported type otomatik olarak invalid schema demek değildir. Test zinciri birden fazla katmandan oluşmalıdır. Tek araç false confidence yaratabilir.

Hatasız Sonucu Gösterim Garantisi Sanmak

Valid veya eligible sonuç actual appearance garantisi değildir. Google sorgu ve arama deneyimine göre zengin görünümü göstermeyebilir. Teknik ekibin başarısı yalnızca SERP ekran görüntüsüne bağlanmamalıdır. Eligibility ve impression ayrı KPI olmalıdır. Bu ayrım stakeholder beklentisini düzeltir.

Schema.org'daki Her Type'ın Google'da Desteklendiğini Sanmak

Schema.org vocabulary Google Search feature listesinden daha geniştir. Type bulunması rich result desteği anlamına gelmez. Güncel Google support documentation kontrol edilmelidir. Registry bu bilgiyi kalıcı hale getirir. Implementation öncesi yapılacak bu kontrol gereksiz işten korur.

Eski FAQ / HowTo Rehberlerini Uygulamak

HowTo rich result daha önce kaldırıldı ve FAQ rich result 7 Mayıs 2026 itibarıyla Google Search'te gösterilmemeye başladı. Buna rağmen eski makaleler bu taktikleri hâlâ aktif fırsat gibi sunabilir. Feature lifecycle takibi bu nedenle zorunludur. Schema type semantik amaçla varlığını sürdürebilir, fakat Search feature hedefi ayrı değerlendirilmelidir. Yayın tarihi ve resmi doküman her uygulama öncesi kontrol edilmelidir.

Recommended Warning'leri Critical Error Sanmak

Her warning release blocker değildir. Recommended property eksikliği business value'ya göre değerlendirilmelidir. Tüm uyarıları hard fail yapmak pipeline'ı gereksiz sert hale getirir. Buna karşılık warning'leri sonsuza kadar görmezden gelmek de doğru değildir. Severity modeli dengeli çözüm sağlar.

Sayfa İçeriğiyle Schema'yı Karşılaştırmamak

Validator sayfadaki gerçek fiyatı her zaman structured data ile karşılaştırmaz. Bu nedenle technically valid fakat yanlış markup mümkün olabilir. Content parity assertion yüksek değer sağlar. Fiyat ve stok gibi alanlar otomatik karşılaştırılmalıdır. Tek source of truth mimari olarak daha güçlü çözümdür.

Plugin'in Ürettiği Schema'yı Test Etmemek

Plugin kullanmak kalite garantisi değildir. Tema veya başka plugin duplicate üretebilir. Güncelleme davranışı değiştirebilir. Gerçek production URL test edilmelidir. Plugin output da diğer kodlar gibi regression monitoring kapsamına alınmalıdır.

Sadece Tek URL Test Etmek

Tek URL yalnızca kendi veri durumunu temsil eder. Edge case ürün veya eski içerik farklı code path çalıştırabilir. Template-based sampling kullanılmalıdır. Fixture seti riskli durumları kapsamalıdır. Büyük sitelerde periyodik crawl ek güvence sağlar.

Release Sonrası İzleme Yapmamak

Staging başarısı production başarısını garanti etmez. Cache, environment ve gerçek API verisi fark yaratabilir. Smoke test deployment sonrası çalışmalıdır. Search Console trendleri uzun vadede izlenmelidir. Monitoring olmadan regression detection gecikir.

Structured Data Anti-Pattern'leri

Structured data anti-pattern'leri kısa vadede hızlı implementation gibi görünür, fakat bakım ve doğruluk problemlerine yol açar. Copy-paste JSON-LD, hard-coded price, hard-coded rating, görünmeyen review, duplicate Product ve her sayfaya aynı schema eklemek bu kategoridedir. Google desteği kaldırılmış bir type'ı hâlâ rich result hedefiyle kullanmak da güncellik anti-pattern'idir. JSON-LD'yi yalnızca SEO ekibinin manuel yönettiği ayrı kod parçası haline getirmek veri kaynaklarından kopmaya neden olabilir. En iyi yapı, gerçek domain verisinden otomatik üretilen ve test edilen schema'dır.

Copy-Paste JSON-LD

Başka bir sayfadan JSON-LD kopyalamak yanlış URL, fiyat veya entity bilgisinin kalmasına yol açabilir. Küçük site bile olsa gerçek veri binding kullanılmalıdır. Template generator tekrar eden yapıyı yönetir. Copy-paste örnek yalnızca öğrenme amacıyla kullanılabilir. Production kodu data-driven olmalıdır.

Hard-Coded Price

Hard-coded price kampanya veya fiyat güncellemesinde hızla eski hale gelir. HTML dinamik fiyat gösterirken schema sabit kalabilir. Bu doğrudan content mismatch oluşturur. Price service ortak kaynak olmalıdır. Test hard-coded literal'leri code review sırasında da yakalayabilir.

Hard-Coded Rating

Sabit rating gerçek kullanıcı değerlendirmesini temsil etmez. “Varsayılan 5 yıldız” schema kalitesini bozar. Review servisi yoksa rating üretilmemelidir. Fixture reviewsuz durumu test etmelidir. Marketing değeri structured data rating değildir.

Schema'da Olmayan Review

Sayfada veya gerçek sistemde bulunmayan review'ı schema içine eklemek yanıltıcıdır. Content visibility ve publication status kontrol edilmelidir. Review silinince markup'tan da çıkmalıdır. Public review query tek kaynak olmalıdır. Human audit ayrıca uygulanabilir.

Duplicate Product

Aynı ürün iki generator tarafından işaretlenebilir. Farklı fiyat veya stok bilgisi çelişki yaratır. Duplicate detector SKU, URL veya ID üzerinden kontrol yapabilir. Plugin ve custom code ownership netleştirilmelidir. Gerçek birden fazla ürün sayfası ayrı senaryodur.

Her Sayfaya Aynı Schema

Global template içine aynı JSON-LD eklemek kolay görünür fakat sayfa anlamını yanlış temsil edebilir. Product, Article ve Contact sayfası farklı entity modelleridir. Route bazlı generator tercih edilmelidir. Expected type contract bunu doğrular. Gereksiz schema eklemekten kaçınılmalıdır.

Google Desteği Kalkmış Type'ı Rich Result İçin Kullanmaya Devam Etmek

Feature removed durumuna geçtiğinde eski rich result beklentisi bırakılmalıdır. Schema type başka semantic amaçla tutulabilir. Ancak ROI hesabı kaldırılmış Search görünümüne dayanmamalıdır. Registry status ve deprecation alarmı bunu önler. 2026 FAQ değişikliği güncel örnektir.

JSON-LD'yi SEO Ekibinin Tek Başına Yönetmesi

SEO ekibi Search gereksinimini bilir, fakat fiyat veya stok business logic'inin sahibi olmayabilir. JSON-LD manuel snippet olarak yönetildiğinde gerçek veri akışından kopabilir. Development ve product ekipleri implementation sahipliğine dahil edilmelidir. SEO governance ve specification rolünü sürdürebilir. Ortak ownership daha güvenilir sonuç verir.

Structured Data Audit Kontrol Listesi

Structured data audit sırasında type seçimi, Google desteği, syntax, Schema.org validation, required ve recommended property'ler, içerik uyumu, mobil render, duplicate durum ve indexability birlikte kontrol edilmelidir. Bu liste tek seferlik teknik denetim için kullanılabileceği gibi periyodik health check'e de dönüştürülebilir. Her kontrolün sonucu pass, warning veya fail olarak kaydedilebilir. URL bazlı bulgular template seviyesinde gruplanmalıdır. Böylece audit yalnızca uzun hata listesi değil uygulanabilir iyileştirme planı üretir.

Type Doğru mu?

Sayfanın ana entity'si ile @type uyumlu olmalıdır. Generic veya alakasız type işaretlenmemelidir. Route amacı incelenmelidir. Multiple entity varsa ilişkiler doğrulanır. Type selection gerekçesi dokümante edilebilir.

Google Tarafından Destekleniyor mu?

Rich result hedefleniyorsa güncel Google Search feature desteği kontrol edilir. Schema.org varlığı tek başına yeterli değildir. Active veya removed status registry'den görülebilir. Documentation update tarihi incelenir. Eski rehberler doğrulanmadan uygulanmaz.

Syntax Doğru mu?

JSON-LD standart parser ile parse edilmelidir. Eksik virgül ve invalid escape gibi hatalar bulunmamalıdır. Serializer kullanımı önerilir. Multiple script ayrı test edilir. Parser failure critical kabul edilebilir.

Schema.org Valid mi?

Type ve property vocabulary açısından doğrulanmalıdır. Value type ilişkileri kontrol edilir. Google eligibility'den ayrı sonuç tutulur. Unsupported Google type semantic olarak yine valid olabilir. Audit raporu bu ayrımı açıklar.

Required Property'ler Tam mı?

Güncel feature required listesi kontrol edilir. Null veya placeholder gerçek coverage sayılmamalıdır. Missing alan root cause seviyesinde düzeltilmelidir. Critical template'de fail verilebilir. Rule set son kontrol tarihi kaydedilmelidir.

Recommended Property'ler Değerlendirildi mi?

Recommended alanların varlığı ve gerçek veri kaynağı incelenir. Eksik alanlar warning olarak raporlanabilir. İş değeri yüksek olanlar önceliklendirilir. Sahte veri eklenmez. Backlog maddesi owner ile ilişkilendirilir.

Sayfa İçeriğiyle Uyumlu mu?

Structured data kritik değerleri görünür içerikle eşleşmelidir. Fiyat, stok, rating ve tarih örnek kontrollerdir. Otomatik parity test kullanılabilir. Format farkları normalize edilir. Gerçek semantic mismatch fail olarak işaretlenir.

Mobilde Var mı?

Mobil render expected type açısından kontrol edilir. Desktop ile ana entity parity sağlanmalıdır. Device-specific template varsa özel risk bulunur. Googlebot Smartphone testi yardımcı olabilir. Mobilde kaybolan script regression olarak raporlanır.

Render Ediliyor mu?

Client-side schema kullanılıyorsa rendered HTML kontrol edilmelidir. JavaScript runtime error markup'ın oluşmasını engelleyebilir. Source ve rendered output karşılaştırılır. Headless browser test kullanılabilir. URL Inspection production doğrulamasına katkı sağlar.

Duplicate Var mı?

Aynı entity'nin birden fazla ve çelişkili node'u bulunup bulunmadığı kontrol edilir. Tema, plugin ve custom script kaynakları ayrıştırılır. Duplicate detector ID, URL ve SKU kullanabilir. Gerçek multi-entity durumları hariç tutulur. Tek ownership hedeflenir.

Indexable mı?

noindex, canonical, robots ve HTTP status kontrol edilmelidir. Structured data valid olsa bile non-indexable sayfa rich result hedefini gerçekleştirmez. URL Inspection yardımcı olabilir. Audit bu problemi schema error olarak etiketlememelidir. Teknik SEO kategori ayrımı korunmalıdır.

Product Schema Audit Checklist

Product schema audit ürünün kimliği, görselleri, ticari teklifleri ve kullanıcı değerlendirme verilerini birlikte kontrol etmelidir. name, image, SKU veya GTIN, offers, price, priceCurrency, availability ve rating alanları temel kontrol noktalarıdır. Visible-content parity ve variant consistency özellikle e-ticarette yüksek öncelik taşır. Audit normal ürün yanında indirimli, stoksuz ve varyantlı örnekleri kapsamalıdır. Tek ürün URL'sindeki başarı bütün katalog için yeterli kanıt değildir.

name

Ürün adı gerçek product modelinden gelmelidir. SEO title ile gereksiz biçimde karıştırılmamalıdır. DOM başlığıyla anlamlı parity bulunmalıdır. Varyant stratejisi belgelenmelidir. Hard-coded ürün adı kullanılmamalıdır.

image

Görsel URL'leri gerçek ürün medya varlıklarına işaret etmelidir. 404 ve placeholder kontrol edilir. CDN URL'si stabil olmalıdır. Multiple images array doğrulanabilir. Ürünle ilgisiz görsel kullanılmamalıdır.

sku / gtin

SKU ve GTIN gerçek kimlik verisinden üretilmelidir. Varyant değerleri parent ile karıştırılmamalıdır. Fake GTIN oluşturulmamalıdır. Duplicate kimlikler audit edilebilir. Data format ve source kaydedilmelidir.

offers

Offer yapısı gerçek satış teklifini temsil etmelidir. Fiyat, currency, stok ve URL birlikte kontrol edilir. Marketplace çoklu offer senaryosu ayrıca incelenir. Nested object type doğrulanır. Eski cache teklifleri bulunmamalıdır.

price

Price görünür aktif fiyatla eşleşmelidir. Kampanya ve üyelik fiyatı business rule'a göre ayrılmalıdır. Formatting normalize edilir. Stale cache kontrol edilir. Critical mismatch fail sayılabilir.

priceCurrency

Currency doğru pazar ve URL bağlamını temsil etmelidir. Price ile aynı source'tan gelmelidir. Çoklu currency fixture test edilir. Yanlış locale mapping raporlanır. ISO currency code kullanımı doğrulanmalıdır.

availability

Availability gerçek purchasability durumunu yansıtmalıdır. InStock ve OutOfStock mapping kontrol edilir. PreOrder ayrı senaryodur. UI ve schema parity test edilir. Bilinmeyen inventory enum sessiz fallback yapmamalıdır.

rating

Rating gerçek review verisine dayanmalıdır. Review count ve rating value birlikte kontrol edilir. Reviewsuz üründe sahte puan olmamalıdır. Visible rating ile parity aranır. Policy gereksinimleri ayrıca değerlendirilir.

visible-content parity

Ürün sayfasındaki temel ticari bilgiler schema ile aynı olmalıdır. Price ve availability en kritik alanlardır. DOM selector ve JSON-LD parser otomatik karşılaştırma yapabilir. Mismatch oranı dashboard metriği olabilir. Aynı source of truth tercih edilmelidir.

variant consistency

Seçilen varyantın renk, beden, SKU, GTIN ve fiyat bilgisi tutarlı olmalıdır. Varyant URL stratejisi canonical ile birlikte değerlendirilir. Parent-child ilişkisi doğrulanır. Yanlış varyant markup'ı yüksek risklidir. Multiple fixture ile test edilmelidir.

Article Schema Audit Checklist

Article schema audit headline, author, datePublished, dateModified, image, publisher, mainEntityOfPage ve visible-content parity alanlarını birlikte değerlendirmelidir. İçerik sistemlerinde tarih ve yazar verileri özellikle migration sonrasında bozulabilir. CMS modelinin gerçek değerleri structured data ile görünür sayfada aynı kaynaktan üretmesi tercih edilir. Eski içerik ve yeni içerik ayrı örneklenmelidir. Audit yalnızca son yayınlanan makaleyi kontrol etmekle sınırlı kalmamalıdır.

headline

Headline gerçek makale başlığını temsil etmelidir. Site adı veya SEO suffix gereksiz yere eklenmemelidir. H1 ile anlamlı uyum bulunmalıdır. CMS title alanı ortak kaynak olabilir. Çok uzun veya boş değer ayrıca raporlanabilir.

author

Author gerçek yazar entity'sine bağlanmalıdır. Generic fallback kullanımı incelenir. Byline ve schema parity kontrol edilir. Person veya Organization seçimi gerçek yayın modeline dayanmalıdır. Profil URL'si varsa doğrulanabilir.

datePublished

İlk yayın tarihi gerçek content lifecycle verisinden gelmelidir. Migration tarihiyle değişmemelidir. ISO 8601 formatı test edilir. Görünür tarih ile karşılaştırılır. Timezone açık olmalıdır.

dateModified

dateModified gerçek anlamlı içerik güncellemesini göstermelidir. Her deployment sırasında otomatik değişmemelidir. Published değerinden önce olmamalıdır. Visible modified date varsa parity kontrol edilir. CMS source alanı belgelenmelidir.

image

Article image içerikle ilişkili gerçek asset olmalıdır. Placeholder ve broken URL kontrol edilir. CDN davranışı incelenir. Multiple image kullanımı varsa type doğrulanır. CMS asset modeli ortak kaynak olabilir.

publisher

Publisher gerçek yayıncı Organization entity'sine bağlanmalıdır. Site genelinde kararlı @id kullanılabilir. Duplicate Organization kontrol edilir. Logo ve URL merkezi kaynaktan gelir. Rebranding sonrası tutarlılık incelenir.

mainEntityOfPage

mainEntityOfPage ilgili canonical makale URL'sini doğru temsil etmelidir. Staging host production'a sızmamalıdır. URL normalization uygulanır. Canonical ile çelişki araştırılır. Route helper ortak kullanılabilir.

visible-content parity

Headline, author ve tarihler görünür içerikle aynı gerçekliği temsil etmelidir. Format farklılıkları normalize edilmelidir. CMS ve schema iki ayrı kaynaktan beslenmemelidir. Mismatch automated testle yakalanabilir. Human audit özellikle eski içeriklerde ek güvence sağlar.

Sık Sorulan Sorular

Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri hakkında en sık sorulan sorular validation, Google eligibility, JSON-LD, error yönetimi ve production monitoring çevresinde toplanır. Aşağıdaki yanıtların ortak noktası, tek bir aracın bütün structured data doğruluğunu ölçmediğidir. Schema.org, Google Search feature desteği, görünür içerik ve indekslenebilirlik farklı katmanlardır. 2026 itibarıyla destekten kaldırılmış özelliklerin eski rehberlerden ayrılması da özellikle önemlidir. Uygulamada en güvenilir yaklaşım validation, regression testing ve production monitoring süreçlerini birlikte yürütmektir.

Yapılandırılmış veri nedir?

Yapılandırılmış veri, web sayfasındaki entity ve özelliklerin makinelerin yorumlayabileceği standart bir modelle açıklanmasıdır. Product, Article veya Event gibi type'lar kullanılabilir. Kullanıcının gördüğü gerçek içeriğin semantik temsilini oluşturur. Yeni veya gizli bilgi uydurmak için kullanılmamalıdır. Doğru implementation düzenli test gerektirir.

Rich snippet nedir?

Rich snippet SEO sektöründe standart arama sonucundan daha fazla bilgi gösteren sonuçları anlatmak için kullanılan yaygın terimdir. Google dokümantasyonunda rich result ifadesi daha geniş ve güncel şekilde kullanılır. Fiyat veya etkinlik gibi ek bilgi sunumları buna örnek olabilir. Structured data bu deneyim için gerekli sinyallerden biri olabilir. Gösterim yine Google'ın kararına bağlıdır.

Rich result ile rich snippet arasındaki fark nedir?

Günlük SEO dilinde iki terim sık sık birbirinin yerine kullanılır. Rich result Google'ın dokümantasyon terminolojisinde daha geniş kavramdır. Rich snippet ise sektör içinde tarihsel olarak yaygınlaşmış ifadedir. Teknik ekip güncel Google dokümanını takip ederken rich result kavramını kullanmalıdır. Terminoloji farkı feature desteğiyle karıştırılmamalıdır.

Rich Results Test nedir?

Google Rich Results Test bir URL veya kodun Google'ın desteklediği zengin sonuç türleri açısından uygunluğunu değerlendiren araçtır. Required ve warning bilgilerini görmenize yardımcı olabilir. Genel Schema.org vocabulary validator'ı değildir. Valid sonuç gerçek Search gösterimini garanti etmez. Production monitoring ayrıca gereklidir.

Schema Markup Validator nedir?

Schema Markup Validator structured data'nın Schema.org vocabulary açısından incelenmesine yardımcı olur. Type, property ve value ilişkileri burada önemlidir. Google'ın zengin sonuç ürün desteğiyle sınırlı değildir. Bu nedenle Rich Results Test ile farklı soruya cevap verir. İki araç birlikte daha geniş kontrol sağlar.

İki araç arasındaki fark nedir?

Rich Results Test Google Search eligibility'ye odaklanır. Schema Markup Validator genel Schema.org semantic uyumluluğunu değerlendirir. Bir markup validator açısından geçerli olup Google rich result desteğine sahip olmayabilir. Bu normal bir durumdur. Test raporunda iki sonuç ayrı tutulmalıdır.

JSON-LD nasıl test edilir?

Önce standart JSON parser ile syntax kontrol edilir. Ardından Schema.org validation yapılır. Google Search feature hedefleniyorsa Rich Results Test kullanılır. Staging ve production render ayrıca incelenir. Son aşamada Search Console monitoring yürütülür.

Schema hataları nasıl bulunur?

Schema markup hataları nasıl tespit edilir ve düzeltilir sorusunun ilk adımı hatayı doğru seviyeye ayırmaktır. Parse error, semantic error, Google eligibility ve content mismatch farklı sorunlardır. Uygun validator ve otomatik test seçilir. Root cause template veya veri kaynağında düzeltilir. Fix sonrası regression testi eklenir.

Required property ne demektir?

Required property hedeflenen feature için zorunlu alanı ifade eder. Eksikliği eligibility problemine yol açabilir. Liste type ve Google Search feature'a göre değişir. Güncel dokümantasyon kullanılmalıdır. CI/CD içinde hard fail kuralı olarak uygulanabilir.

Warning zengin sonucu engeller mi?

Her warning zengin sonuç uygunluğunu otomatik olarak engellemez. Recommended property eksikliği warning olarak görülebilir. Ancak uyarının gerçek anlamı ilgili feature dokümanından kontrol edilmelidir. Veri mevcutsa kaliteli biçimde eklenebilir. Sadece warning'i kaldırmak için sahte bilgi üretilmemelidir.

Rich Results Test'ten geçen schema kesin görünür mü?

Hayır, testten geçmek kesin görünüm garantisi değildir. Test eligibility hakkında teknik sinyal sağlar. Google sorgu, cihaz ve kendi Search deneyimine göre gösterim kararı verir. Indexability ve kalite koşulları da önemlidir. Eligible ve displayed metrikleri ayrı izlenmelidir.

Geçerli schema neden Google'da görünmüyor?

Feature destekten kaldırılmış olabilir veya sayfa target feature için eligible olmayabilir. Sayfa noindex, canonical başka URL veya crawl problemi taşıyor olabilir. Tüm teknik koşullar doğruysa Google yine rich görünüm göstermeyebilir. Search Console ve URL Inspection birlikte incelenmelidir. Rastgele markup değişikliği yapılmamalıdır.

FAQ schema hâlâ rich result üretir mi?

Google, FAQ rich result özelliğinin 7 Mayıs 2026 itibarıyla Search'te artık gösterilmeyeceğini duyurdu. Bu nedenle FAQPage markup'ı 2026'da eski “FAQ rich result kazanma” hedefiyle uygulanmamalıdır. Schema type'ın başka semantic kullanımları ayrı değerlendirilebilir. Güncel Google feature desteği esas alınmalıdır. Eski rehberler bu konuda güncelliğini kaybetmiş olabilir.

HowTo schema Google'da hâlâ destekleniyor mu?

Google HowTo rich result gösterimini 2023 yılında Search sonuçlarından kaldırdı. Dolayısıyla HowTo markup'ını günümüzde Google rich result elde etme taktiği olarak sunmak güncel değildir. Schema.org type ile Google Search feature aynı şey değildir. Semantic kullanım ayrı değerlendirilebilir. Rich result hedefi için güncel destek listesine bakılmalıdır.

Product schema nasıl test edilir?

Product schema önce syntax ve vocabulary açısından doğrulanmalıdır. Ardından Google'ın güncel Product gereksinimleri Rich Results Test ile kontrol edilir. Price, currency ve availability görünür sayfayla karşılaştırılır. Normal, indirimli, stoksuz ve varyant fixture'ları test edilir. Production smoke test ve Search Console monitoring süreci tamamlar.

Structured data sayfada görünür içerikle aynı olmak zorunda mı?

Structured data sayfanın gerçek ve kullanıcıya sunulan içeriğini doğru biçimde temsil etmelidir. Fiyat veya rating gibi kritik bilgilerin markup içinde farklı olması risklidir. Formatlar farklı olabilir, semantic değer aynı olmalıdır. Content parity test bu kontrolü otomatikleştirebilir. Aynı source of truth kullanmak en güçlü mimari çözümdür.

JavaScript ile eklenen JSON-LD Google tarafından okunur mu?

JavaScript ile oluşturulan structured data Google tarafından işlenebilir, ancak runtime ve render güvenilirliği önemlidir. JavaScript hatası markup'ın kaybolmasına yol açabilir. Source ve rendered HTML karşılaştırılmalıdır. Rich Results Test ve URL Inspection yardımcı kontrollerdir. Kritik Product markup'ında ilk HTML'de veri sunmak daha dayanıklı olabilir.

Search Console schema hataları nasıl izlenir?

Search Console ilgili structured data raporlarında geçerli ve geçersiz öğeler ile URL örnekleri sunabilir. Trendler release tarihleriyle karşılaştırılmalıdır. Fix sonrası validation süreci kullanılabilir. Search Console anlık CI testi değildir. Internal monitoring ile birlikte değerlendirilmelidir.

CI/CD içinde schema testi yapılabilir mi?

Evet, JSON parse, type validation, required field, snapshot ve content contract testleri CI/CD içinde çalıştırılabilir. Critical sorun merge veya deployment'ı bloklayabilir. Staging render ve production smoke test sonraki katmanlardır. Warning'ler ayrı severity ile raporlanabilir. Bu yaklaşım structured data regression'larını çok daha erken yakalar.

Schema testi için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. TypeScript frontend uygulamalarında doğal entegrasyon sunar. Python crawling ve audit otomasyonunda oldukça kullanışlıdır. PHP, Java veya başka mevcut stack'ler de aynı test mantığını uygulayabilir. Dilden çok contract, fixture ve monitoring tasarımı önemlidir.

Açık kaynak araçlarla structured data testi yapılabilir mi?

Evet, JSON parser, HTML parser ve headless browser kütüphaneleriyle açık kaynak test sistemi oluşturulabilir. General vocabulary ve Google feature kuralları ayrı modüllerde tutulmalıdır. URL crawl, duplicate detection ve content parity otomatikleştirilebilir. Community fixture paylaşımı kapsama katkı sağlar. External Google araçları representative kontroller için yine kullanılabilir.

Yazılımcı olmak için structured data bilmek gerekir mi?

Structured data her yazılımcı için zorunlu temel beceri değildir. Ancak web, e-ticaret, içerik platformları ve teknik SEO ile çalışan geliştiriciler için değerli uzmanlık alanıdır. JSON, HTTP, DOM ve test automation becerilerini gerçek projede birleştirir. Search sistemlerinin web içeriğini nasıl yorumladığını anlamaya yardımcı olur. Öğrenmek özellikle frontend ve full-stack geliştiricilere pratik avantaj sağlar.

Diyarbakır Yazılım Topluluğunda schema test projesi geliştirilebilir mi?

Evet, URL alan, JSON-LD çıkaran ve validation raporu üreten açık kaynak bir proje iyi bir topluluk çalışması olabilir. İlk sürüm parser ve type detection ile başlayabilir. Sonraki aşamada content parity, deprecated feature warning ve CI entegrasyonu eklenebilir. Böyle bir proje test automation ile teknik SEO bilgisini aynı çalışma içinde toplar. Katılım ve topluluk hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Zengin sonuçlar (Rich Snippets) için yapılandırılmış veri nasıl test edilir?

Önce JSON-LD'nin parse edilebilir olduğundan emin olun, ardından Schema.org vocabulary doğrulaması yapın. Google'ın hâlen desteklediği bir Search feature hedefleniyorsa Rich Results Test ile eligibility kontrolü gerçekleştirin. Sonraki aşamada görünür içerikle structured data'yı karşılaştırın ve staging render sonucunu inceleyin. Production deployment sonrasında URL Inspection ve smoke test uygulayın. Search Console monitoring ise hataların ve Search görünümünün uzun vadeli takibini sağlar.

Google Rich Results Test ile Schema.org Validator arasındaki fark nedir?

Google Rich Results Test, Google Search tarafından desteklenen zengin sonuç özelliklerine uygunluğu değerlendirmeye odaklanır. Schema.org Validator ise daha geniş Schema.org vocabulary'sindeki type ve property ilişkilerini kontrol eder. Bu nedenle Schema.org açısından geçerli bir type Rich Results Test tarafından özel Search feature olarak desteklenmeyebilir. İki araç birbirinin alternatifi değildir. Sağlıklı test sürecinde ikisi farklı doğruluk katmanlarında birlikte kullanılır.

Yapılandırılmış veri testlerinde çıkan hata ve uyarılar nasıl düzeltilir?

Önce problemin error mı warning mi olduğu belirlenmelidir. Missing required property, parsing error ve kritik content mismatch gibi sorunlar yüksek öncelikli ele alınır. Recommended property warning'leri ise gerçek veri ve iş değerine göre planlanabilir. Hata template veya veri kaynağında kök neden seviyesinde düzeltilmelidir. Ardından aynı hata için regression testi yazılarak tekrar oluşması önlenmelidir.

JSON-LD ve Schema Markup uygulamalarının Google zengin sonuçlarına uygunluğu nasıl kontrol edilir?

Önce kullanılan schema type'ın Google tarafından hâlen desteklenen bir Search feature ile ilişkili olup olmadığını güncel dokümantasyondan kontrol edin. JSON syntax ve Schema.org validation aşamalarını tamamladıktan sonra Google Rich Results Test çalıştırın. Required property ve policy gereksinimlerini inceleyin. Sayfa production'a çıktıktan sonra render, indexability ve Search Console verilerini ayrıca kontrol edin. JSON-LD schema markup ile zengin sonuç görünürlüğü nasıl artırılır sorusunun sağlıklı cevabı daha fazla markup eklemek değil, doğru ve güncel veriyi güvenilir biçimde sunmaktır.

Rich Snippets ve yapılandırılmış veri testleri konusunda yakınımda teknik SEO danışmanlığı nerede bulabilirim?

Rich snippets ve schema markup teknik SEO optimizasyon hizmeti ararken hizmet sağlayıcının yalnızca JSON-LD üretip üretmediğine değil, validation, content parity, render ve production monitoring süreçlerini birlikte ele alıp almadığına bakın. Yapılandırılmış veri ve teknik SEO danışmanlığı yakınımda şeklindeki aramalarda yerel iletişim kadar uygulanan test metodolojisi de önemlidir. Diyarbakır Yazılım Topluluğu'nun çalışmaları ve topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi edinebilirsiniz. Proje örnekleri için https://www.diyarbakiryazilim.com.tr/projects sayfası incelenebilir. Teknik SEO çalışmalarında hedef, yalnızca validator ekranında hata görmemek değil sürdürülebilir ölçüm ve geliştirme sistemi kurmaktır.

Sonuç — Yapılandırılmış Veri Testi Bir Validator'a Kod Yapıştırmaktan Daha Fazlasıdır

Zengin Sonuçlar (Rich Snippets) İçin Yapılandırılmış Veri Testleri, syntax kontrolünden production monitoring'e uzanan çok katmanlı bir mühendislik sürecidir. Schema.org doğruluğu, Google eligibility, görünür içerikle veri eşleşmesi, render sonucu ve indexability birbirinden farklı kontrollerdir. Özellikle 2026'da FAQ gibi Search feature'ların kaldırılması, feature lifecycle takibinin teknik validation kadar önemli olduğunu açıkça gösteriyor. Required property hatalarının release öncesinde yakalandığı, regression testlerinin CI/CD içinde çalıştığı ve production sağlığının düzenli izlendiği model uzun vadede daha güvenilirdir. Kendi projenizde bu yaklaşımı geliştirmek veya topluluk çalışmalarına katılmak için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects adreslerinden Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi edinebilirsiniz.

Önce Schema.org Doğruluğu Kontrol Edilmelidir

İlk semantic kontrol type, property ve value ilişkilerinin Schema.org açısından doğru olup olmadığını anlamaktır. Bundan önce JSON syntax zaten doğrulanmış olmalıdır. General vocabulary kontrolü Google Search feature desteğiyle karıştırılmamalıdır. Bu ayrım debugging süresini kısaltır. Sağlam temel olmadan sonraki eligibility testleri anlamını kaybeder.

Ardından Google Rich Result Uygunluğu Test Edilmelidir

Schema.org validation sonrasında hedeflenen Google feature için güncel destek kontrol edilmelidir. Rich Results Test required ve warning bilgilerini değerlendirmenize yardımcı olur. Removed feature için valid markup yazmak rich result oluşturmaz. 2026 feature status düzenli izlenmelidir. Eligibility yine actual appearance garantisi değildir.

Schema ile Görünür İçeriğin Aynı Veri Kaynağını Temsil Ettiği Doğrulanmalıdır

Content parity structured data güvenilirliğinin merkezindedir. Fiyat, stok, rating, tarih ve author gibi kritik değerler aynı gerçek kaynaktan gelmelidir. Farklı kaynak kullanılıyorsa contract test gereklidir. DOM ile JSON-LD otomatik karşılaştırılabilir. Kullanıcı ve arama motoruna farklı bilgi sunulmamalıdır.

Render ve Indexability Kontrol Edilmelidir

JavaScript sonrası schema gerçekten render ediliyor mu sorusu production'da doğrulanmalıdır. noindex, canonical, robots ve HTTP status ayrıca kontrol edilmelidir. Rich Results Test bu bütün teknik SEO zincirinin tek aracı değildir. URL Inspection production doğrulamasına yardımcı olur. Schema doğru olsa bile indekslenemeyen URL hedeflenen görünürlüğü elde edemez.

Required Property Hataları Release'i Bloklamalıdır

Kritik template'lerde missing required property güçlü quality gate adayıdır. Test pull request veya build aşamasında çalışmalıdır. Gerçek veri eksikse root cause çözülmelidir. Sahte fallback ile test geçmek doğru değildir. Böylece Search Console'a ulaşmadan regression durdurulur.

Schema Testleri CI/CD İçine Taşınmalıdır

Tekrarlanan manuel testler otomasyona dönüştürüldüğünde kalite daha sürdürülebilir hale gelir. JSON parse, type, required field, snapshot ve parity testleri pipeline'a eklenebilir. Staging render ve production smoke test sonraki katmanları oluşturur. Alert sistemi kritik sorunları owner'a yönlendirir. Structured data gerçek software quality practice haline gelir.

Google'ın Desteklediği Search Feature'lar Sürekli İzlenmelidir

Feature desteği yıllar boyunca aynı kalmaz. FAQ, HowTo ve başka kaldırılmış Search özellikleri bunun açık kanıtıdır. Documentation update ve support registry düzenli takip edilmelidir. Deprecated durum migration planı tetikleyebilir. Güncel olmayan SEO rehberlerinin production kararını belirlemesine izin verilmemelidir.

Başarılı Model Validation, Regression Testing ve Production Monitoring'i Tek Süreçte Birleştirir

En güçlü structured data modeli üç temel katmanı birleştirir. Validation kodun ve semantic yapının doğruluğunu ölçer, regression testing gelecek release'lerde aynı hatanın geri dönmesini önler, production monitoring ise gerçek sistem davranışını izler. Bu üçlü yaklaşım yalnızca rich result kazanma hedefinden daha geniş ve daha sürdürülebilir bir teknik SEO standardı oluşturur. Ekip Search feature değişikliklerine daha hızlı uyum sağlar. Sonuçta yapılandırılmış veri, bakım gerektiren fakat ölçülebilir bir ürün yeteneğine dönüşür.