Hızlı Cevap
Ürün sayfasında yapılandırılmış veriye başlarken önce Product.name, image ve offers alanlarını kurun. Sayfa satın alınabilir durumdaysa Offer içinde price, priceCurrency ve availability’i hemen ekleyin. Sonra brand, sku, gtin, review, shippingDetails ve hasMerchantReturnPolicy alanlarını yalnızca sayfada görünür ve operasyonel olarak sürdürülebilir olduklarında katmanlayın.
Önemli Noktalar
- Satın alınabilir sayfalarda çekirdek set Product.name, image ve offers’tır.
- Offer içinde price, priceCurrency ve availability ilk genişletilecek alanlardır.
- Görünür fiyat ve stok ile schema verisi birebir eşleşmelidir.
- SKU, GTIN ve varyant eşleştirmesi katalog doğruluğunu güçlendirir.
- Rich Results Test, Search Console ve Merchant Center birlikte okunmalıdır.
Ürün sayfalarında yapılandırılmış veri hangi alanlarla başlamalıdır?: minimum set
Kısa cevap şu: satın alınabilir bir ürün sayfasında ilk katman genelde Product.name, image ve offers olur. Google Search Central’ın 20 Mayıs 2026 tarihli merchant listing dokümanında ürün işaretlemesinin temelinde ürün bilgisi ve teklif bilgisinin birlikte ele alındığı açıkça görülür; Schema.org Product tanımı da ürün nesnesinin merkezde olduğunu doğrular. Uygulamada bu, ürün adını ve ana görseli Product altında açıp satış durumunu Offer ile bağlamak anlamına gelir.
Sayfa gerçekten satışa açıksa, ikinci cümlede beklemeden eklenmesi gereken alanlar price, priceCurrency ve availability olur. Buradaki kritik nokta teknik tamamlık değil, görünür veri uyumudur. Sayfada görünen ürün adı, fiyat, para birimi ve stok bilgisi schema’da farklıysa uygunluk sorunu yaşarsınız. Merchant Center yardım belgelerinde yapılandırılmış verinin kullanıcıya gösterilen değerlerle eşleşmesi gerektiği özellikle vurgulanır.
- Hemen başlayın: name, image, offers, price, priceCurrency, availability.
- İkinci katmana bırakın: brand, sku, gtin, mpn, itemCondition.
- Operasyon oturduğunda ekleyin: review, aggregateRating, shippingDetails, hasMerchantReturnPolicy.
Her ürün URL’si için aynı yoğunlukta işaretleme gerekmez. Yalnızca ürün tanıtımı yapan, sepete ekleme akışı olmayan sayfalarda Product çekirdeğiyle kalabilirsiniz; fakat fiyat ve stok gösteren ticari sayfalarda Offer tarafını eksik bırakmak doğru başlangıç olmaz. Başlangıç mantığı bu yüzden şöyledir: önce Google’ın ürünü ve teklifini net okumasını sağlayın, sonra güven sinyallerini katmanlayın.
Product snippet mi Merchant listing mi: hangi alan ne zaman eklenir?
10 Aralık 2025’te güncellenen Google ürün yapılandırılmış veri dokümanı iki görünümü net ayırır: Product snippet daha çok değerlendirme, fiyat ve uygunluk gibi zengin sonuçlara odaklanır; merchant listing ise satın alınabilir ürün sayfalarında teklif, kargo ve iade gibi daha ticari sinyalleri öne çıkarır. Aynı sayfa iki yapıyla da ilişki kurabilir; ancak başlangıç sorunuzun cevabı sayfanın satış niyetine göre değişir.
Karar mantığını sadeleştirirsek: ürün sayfasında yorumlar görünür durumdaysa review ve aggregateRating eklenebilir; ürün durumu önemliyse itemCondition mantıklıdır; kargo ücreti, teslimat mantığı ve iade politikası sayfada açıkça yer alıyorsa shippingDetails ile hasMerchantReturnPolicy güçlü ticari sinyal olur. Son dönemde Google belgelerinde shipping ve returns alanlarının daha görünür hale gelmesi, bu alanların başlangıç zorunluluğu değil ama ticari olgunluk göstergesi olduğunu anlatıyor.
- Snippet önceliği: review, aggregateRating, price, availability.
- Merchant listing önceliği: offers yapısı, itemCondition, shippingDetails, iade politikası.
- İkisi için ortak temel: doğru Product nesnesi ve görünür Offer bilgisi.
Terimlerin birbirine karıştığı ekiplerde küçük bir referans sayfası çok iş görüyor; bu yüzden teknik ve pazarlama tarafını hizalamak için schema terimleri sözlüğü tarzı bir iç kaynak bulundurmak pratik olur. Buradaki ana kural basit: sayfada görünmeyen bir alanı yalnızca schema’da eklemeyin; önce ürün sayfasının neyi gerçekten anlattığını belirleyin, sonra o görünümü destekleyen alanları ekleyin.
SKU, GTIN, MPN ve varyantlarda eşleştirme mantığı
Çekirdek kurulum geçtikten sonra en fazla değer üreten ikinci katman ürün tanımlayıcılarıdır. Merchant Center’ın desteklenen özellikler dokümanında SKU ve GTIN verilmesinin eşleştirme kalitesini güçlendirdiği açıkça belirtilir; aynı belgede bu tanımlayıcılar eksik olduğunda açılış sayfasındaki ürünlerin yapılandırılmış verilerle eşleştirilemeyebileceği söylenir. Bu yüzden pratik öncelik sırası çoğu projede brand, sonra sku, ardından mevcutsa gtin, yoksa mpn şeklindedir.
Tek URL ve çok varyant senaryosu
Tek URL üzerinde renk, beden veya hacim varyantı varsa iki hata sık görülür: tüm varyantlara tek fiyat yazmak ve tek SKU ile hepsini temsil etmeye çalışmak. Google ürün dokümanında varyant yapılandırılmış verisinin hem product snippets hem merchant listings tarafında desteklendiği özellikle belirtilir. Eğer kullanıcı seçimiyle değişen teklif varsa, seçilebilir varyantın URL, fiyat, stok ve tanımlayıcı bilgisini mantıklı şekilde eşleştirmek gerekir.
TRY odaklı teklif kurgusu
Türkiye odaklı sayfalarda en temel kural para birimini metin olarak değil, ISO 4217 kodu ile yazmaktır; yani priceCurrency alanında TRY kullanılır. Schema.org Product sayfasının 19 Mart 2026 tarihli V30.0 sürümü, Product, Offer ve MerchantReturnPolicy sözlüğünün hâlâ aktif biçimde geliştiğini gösteriyor; bu da sabit bir ezber yerine sözlük mantığını takip etmeniz gerektiği anlamına gelir. Özellikle çoklu teklif yapısında her Offer’ın doğru fiyat, stok ve tanımlayıcı bağını kurması, hem katalog tutarlılığı hem de raporlamada hata ayıklama için fark yaratır.
JSON-LD kurulumu ve doğrulama akışı: ilk HTML, test ve hata ayıklama
Kurulum biçimi tarafında başlangıç önerisi nettir: JSON-LD ile ilerleyin. Merchant Center yardım içeriği, JSON-LD’nin yönetiminin daha kolay olduğunu söyler; aynı içerikte yapılandırılmış verinin web sunucusundan dönen HTML içinde bulunması gerektiği ve sayfa yüklendikten sonra JavaScript ile oluşturulmaması gerektiği de açıkça yazılıdır. Bu nokta kritik çünkü fiyat ve stok gibi hızlı değişen alanlarda geç yüklenen işaretleme daha kırılgan olur.
Doğrulama akışını tek araçla sınırlamayın. İlk durak Rich Results Test ile söz dizimi ve uygunluk kontrolüdür. İkinci durak Search Console içinde Merchant Listings veya Product raporlarının izlenmesidir. Üçüncü durak ise Merchant Center tarafında sayfa verisi ile katalog beklentisinin örtüşüp örtüşmediğini okumaktır. Google Search Central, merchant listing dokümanında Rich Results Test ve URL Inspection ile yayın sonrası kontrolü açıkça önerir.
- Eksik priceCurrency: çoğu zaman teklif vardır ama para birimi unutulmuştur.
- Fiyat veya stok uyuşmazlığı: sayfadaki görünür veri ile schema aynı değildir.
- Varyant URL hatası: seçilen varyant yerine ana ürün URL’si işaretlenir.
- Kargo veya iade kopukluğu: görünür politika vardır ama schema bağlanmamıştır.
2026’da da temel gerçek değişmedi: doğru işaretleme zengin görünüm garantisi vermez, ama eksik veya çelişkili işaretleme uygunluk şansını düşürür. Bu yüzden hata ayıklamayı teknik doğrulama olarak değil, ticari sayfa tutarlılığı denetimi olarak ele almak daha doğru olur.
| Alan/Kriter | Minimum başlangıç seti | Merchant listing odaklı set | Gelişmiş güven sinyali seti |
|---|---|---|---|
| Product.name ve image | İlk kurulumda eklenir | İlk kurulumda eklenir | İlk kurulumda eklenir ve varyant mantığıyla bağlanır |
| offers, price ve priceCurrency | Satın alınabilir sayfada temel gereksinim | Ana odak noktası | İndirim veya çoklu teklif senaryosuyla genişletilir |
| availability ve itemCondition | Availability öncelikli, condition opsiyonel | İkisi de güçlü ticari sinyal | Varyanta göre ayrıştırılır |
| review ve aggregateRating | Gerekli değil | Görünür yorum varsa eklenir | Tutarlı inceleme akışı varsa güçlenir |
| brand, sku, gtin, mpn | İkinci katmanda eklenir | Eşleştirme kalitesi için önemli | Katalog doğruluğunun merkezinde yer alır |
| shippingDetails ve hasMerchantReturnPolicy | Başlangıçta şart değil | Kargo ve iade görünüyorsa eklenir | Operasyonel politika netse yüksek değer üretir |
| Varyant ve çoklu teklif yapısı | Basit ürünlerde ertelenebilir | Satış sayfalarında dikkat ister | Tek URL ve çoklu Offer senaryosunda kritik hale gelir |
Adım Adım Ürün sayfasında minimum Product schema kurulumu
İlk yayına alma için en pratik yaklaşım, tüm olası alanları aynı gün eklemek değil, çekirdeği doğru kurup kontrollü genişlemektir. Aşağıdaki akış hem geliştirici tarafını hem de e-ticaret ekibinin veri doğruluğunu aynı sıraya koyar.
- Görünür ürün verisini envanterleyin. Ürün adı, ana görsel, fiyat, para birimi, stok ve varyant bilgisi sayfada gerçekten görünüyor mu kontrol edin. Görünmeyen bir bilgiyi schema’da başlatmak, ileride uyumsuzluk üretir.
- Çekirdek Product alanlarını kurun. Product nesnesinde önce name ve image ile ürün kimliğini açın. Sayfa yalnızca ürün tanıtımıysa burada durabilir; satış akışı varsa Offer katmanına geçin.
- Offer alanlarını satış durumuna göre ekleyin. Satın alınabilir sayfalarda price, priceCurrency ve availability alanlarını birebir görünür veriyle bağlayın. TRY kullanan sayfalarda para birimini kod olarak tanımlayın.
- Tanımlayıcı ve ticari sinyalleri genişletin. brand, sku, gtin veya mpn alanlarını katalog mantığına göre ekleyin. Kargo ve iade bilgisi sayfada netse shippingDetails ve hasMerchantReturnPolicy ile ikinci katmanı açın.
- Üç kanalda doğrulayın. Önce Rich Results Test, sonra Search Console, ardından Merchant Center geri bildirimini okuyun. Hata ile uyarıyı ayırın; özellikle fiyat, stok ve varyant kopukluklarını önce düzeltin.
Bu sıralama küçük ekipler için de çalışır çünkü önce gerekli olanı, sonra değer katanı, en sonda da operasyonu zorlaştırabilecek alanları ele alır. Başlangıçta sade kalmak çoğu zaman eksik kalmaktan daha güvenlidir.
Üç canlı testten öğrendiğimiz farklar ve SEOYEN ile izleme
Aynı ürün URL’sinde üç katmanlı bir denetim akışı kullandığımızda tablo netleşiyor. İlk turda yalnızca name, image, offers, price, priceCurrency ve availability bıraktığımız sürüm Rich Results Test’te temel uygunluğu veriyor; ancak Search Console ve Merchant Center tarafında en sık açık kalan alanlar tanımlayıcı derinliği ve varyant eşleştirmesi oluyor. İkinci turda brand, sku ve mevcutsa gtin eklendiğinde özellikle tek URL ve çok seçenek kullanan sayfalarda hata ayıklama kolaylaşıyor, çünkü hangi teklifin hangi varyanta ait olduğu daha net okunuyor.
Üçüncü turda shippingDetails ve hasMerchantReturnPolicy eklediğimizde fayda hemen görünmüyor; asıl fark, sayfadaki kargo ve iade bilgisinin zaten düzenli yönetildiği mağazalarda ortaya çıkıyor. Eğer politika metni güncel değilse veya varyanta göre değişiyorsa bu alanlar yeni tutarsızlık üretmeye daha yatkın. Bu yüzden gelişmiş alanları erken eklemektense, görünür içerik ile operasyon aynı düzene girdikten sonra açmak daha güvenli oluyor.
Buradaki kritik ders, daha fazla alan eklemenin tek başına daha iyi olmadığıdır. Üç sürümlü test mantığında en iyi sonuç, görünür verisi sağlam ve sürdürülebilir olan sürümden gelir. Özellikle Search Console uyarıları ile Rich Results Test temiz görünümü arasında fark olduğunda, sorun çoğu zaman kodun varlığı değil veri tutarlılığıdır. Bu yüzden yayına aldıktan sonra teknik kontrol ile performans kontrolünü birlikte izlemek gerekir.
Bu izleme tarafında site sağlığı kontrolü, işaretlemenin sayfa bazında bozulup bozulmadığını yakalamak için; sıralama takibi paneli, ürün odaklı sorgularda görünürlük değişimini okumak için; AI görünürlük raporu ise ürün sayfalarının yeni arama yüzeylerinde ne kadar anıldığını izlemek için aynı iş akışına bağlanabilir. SEOYEN’in Türkçe arayüzü ve TL bazlı fiyatlandırması, bu kontrolleri yerel ekipler için daha erişilebilir hale getirir; güncel plan detayları için fiyat ve paket seçenekleri sayfasına bakılmalıdır.
Kaynaklar
Sıkça Sorulan Sorular
Başlangıçta en güvenli çekirdek set Product.name, image ve offers yapısıdır. Eğer sayfa doğrudan satışa açıksa Offer içinde price, priceCurrency ve availability alanlarını da ilk kurulumda eklemek gerekir. Teknik olarak daha çok alan eklenebilir. ancak başlangıç mantığı zorunlu ve görünür veriye bağlı alanları önce kurmaktır. Ürün açıklaması, marka, SKU veya GTIN gibi alanlar çok değerlidir ama ilk yayına alma için ikinci katmanda ele alınabilir. En kritik şart, schema içindeki değerlerin sayfada kullanıcıya gösterilen bilgilerle birebir aynı olmasıdır.
Product, ürünün kendisini tanımlar. yani ürün adı, görseli, marka bilgisi ve genel ürün kimliği burada yer alır. Offer ise aynı ürünün satış koşullarını taşır. fiyat, para birimi, stok durumu, ürün durumu ve gerekirse kargo ya da iade bilgisi bu katmandadır. Bu ayrım uygulamada önemlidir çünkü Google ürünün ne olduğunu Product üzerinden, kullanıcının hangi şartlarla satın alabileceğini ise Offer üzerinden okur. Tek ürün sayfasında bu iki katman birlikte çalışır ve çoğu ticari sayfada biri olmadan diğeri eksik kalır.
Ürün snippet'i daha çok arama sonuçlarında değerlendirme, fiyat ve uygunluk gibi zengin bilgi katmanlarını destekler. Satıcı ürün listeleme işaretlemesi ise satın alınabilir ürün sayfalarında teklif, kargo ve iade gibi daha ticari sinyalleri de kapsayan bir çerçeve sunar. İkisi arasında örtüşen alanlar vardır. hatta merchant listing için gerekli ürün bilgilerini eklemek çoğu durumda snippet uygunluğunu da destekler. Fark şu noktada ortaya çıkar: ürün yorumlarını göstermek ile bir ürünün gerçek satış teklifini, stok durumunu ve politika bilgilerini göstermek aynı şey değildir.
Satın alınabilir ürün sayfalarında evet, bunlar pratikte temel öncelik alanlarıdır. Çünkü Offer katmanında fiyatı para biriminden bağımsız vermek yeterli değildir. Google fiyatı anlamlandırmak için price ile birlikte priceCurrency bekler. Üstelik ürün sayfasında kullanıcı fiyat görüyorsa schema tarafında bu bilgiyi eksik bırakmak doğru bir başlangıç sayılmaz. Bilgilendirici, satış dışı ürün sayfalarında Offer hiç kullanılmayabilir. fakat sepete ekleme veya teklif mantığı olan bir URL'de price ve priceCurrency'i sonraya bırakmak yerine ilk kurulumda eklemek daha doğrudur.
Bu tanımlayıcılar çekirdek Product ve Offer kurulumu tamamlandıktan hemen sonra devreye alınmalıdır. Özellikle birden fazla ürünün aynı sayfada listelendiği, varyantların tek URL altında toplandığı veya Merchant Center ile eşleştirme kalitesinin kritik olduğu senaryolarda SKU ve GTIN büyük fark yaratır. GTIN yoksa MPN ve marka bilgisi devreye girer. Basit ürün sayfalarında bile brand ile sku eklemek, ileride yaşanacak eşleştirme ve hata ayıklama sorunlarını azaltır. Kısacası bunlar lüks değil, ikinci aşamanın en değerli alanlarıdır.
Her ürün sayfası için başlangıç zorunluluğu değildir. Ancak sayfada veya bağlı politika sayfalarında kargo ücreti, teslimat süresi ve iade koşulları açıkça sunuluyorsa shippingDetails ve hasMerchantReturnPolicy alanları güçlü ticari sinyal haline gelir. Buradaki püf nokta görünürlük ve sürdürülebilirliktir: operasyon sık değişiyorsa ve ekip bu verileri güncel tutamıyorsa erken aşamada eklemek yerine önce çekirdek işaretlemeyi sabitlemek daha güvenli olur. Operasyon oturduğunda bu alanlar merchant listing tarafında daha zengin ve güvenilir bir veri katmanı sağlar.
Varsayılan tercih evet, JSON-LD olmalıdır. Google ve Merchant Center dokümantasyonunda JSON-LD'nin yönetiminin daha kolay olduğu açıkça belirtilir. Bunun nedeni, HTML görünümünü bozmadan sayfaya ayrı bir veri katmanı ekleyebilmenizdir. Yine de önemli bir şart var: işaretleme sayfa yüklendikten sonra istemci tarafında rastgele üretilmemeli, sunucunun döndürdüğü HTML içinde yer almalıdır. Özellikle fiyat ve stok gibi sık değişen alanlarda geç yüklenen JavaScript işaretlemesi, güvenilirlik ve tarama sıklığı açısından sorun çıkarabilir.
İlk adım URL'yi Rich Results Test aracına vermek ve Product ya da Merchant Listings kapsamında hata ve uyarıları ayırmaktır. Hatalar yayın uygunluğunu doğrudan etkiler. uyarılar ise çoğu zaman eksik ama geliştirilebilir alanları gösterir. İkinci adım Search Console tarafında ilgili raporları izlemek, üçüncü adım ise Merchant Center eşleşme ve nitelik geri bildirimini okumaktır. En sık görülen sorunlar eksik priceCurrency, görünür fiyat ile schema fiyatının uyuşmaması, varyant URL'sinin yanlış bağlanması ve kargo ya da iade bilgisinin sayfada görünmesine rağmen işaretlenmemesidir.