Ürün sayfasında Merchant listing şeması, Product içine Offer ve gerekli ticari alanları JSON-LD biçiminde ekleyerek kurulur. Ardından kod, görünür içerikle karşılaştırılır ve Google araçlarıyla doğrulanır.
Bu işaretleme fiyat, stok durumu, kargo maliyeti ve iade koşullarını açıklayabilir. Ancak geçerli şema, bu bilgilerin arama sonucunda kesin gösterileceği anlamına gelmez.
Merchant listing şeması nedir ve Product snippet'tan farkı nedir?
Merchant listing şeması, doğrudan satın alınabilen ürün sayfalarını Google'ın alışveriş odaklı arama özelliklerine uygun biçimde tanımlar. Temel yapı Product ve onun içindeki Offer nesnesinden oluşur.
Product snippet, ürün bilgilerini inceleme veya karşılaştırma bağlamında gösterebilir. Merchant listing ise aktif fiyat, para birimi, stok, kargo ve iade gibi işlem öncesi bilgilere odaklanır.
Bir sayfada “Sepete ekle” veya eşdeğer satın alma işlemi bulunuyorsa merchant listing kurulumu anlamlıdır. Yalnızca ürün tanıtan katalog sayfalarında Offer eklemek, sayfanın gerçek işlevini yanlış yansıtabilir.
| Ölçüt | Product snippet | Merchant listing |
|---|---|---|
| Temel amaç | Ürün bilgisini zenginleştirmek | Satın alınabilen teklifi açıklamak |
| Uygun sayfa | İnceleme veya ürün sayfası | Fiyatı bulunan satış sayfası |
| Kritik nesne | Product | Product içindeki Offer |
| Ticari alanlar | Puan, yorum ve ürün bilgisi | Fiyat, stok, kargo ve iade |
| Gösterim garantisi | Yok | Yok |
Aynı Product işaretlemesi iki deneyim için de değerlendirilebilir. Ayrımı çoğunlukla sayfanın niteliği, Offer verilerinin kapsamı ve Google'ın ilgili arama bağlamı belirler.
Ürün çevrim dışı satılıyor veya fiyat için teklif formu gerekiyorsa standart Offer yapısı uygun olmayabilir. İşaretleme, kullanıcıların sayfada gerçekten görebildiği ve kullanabildiği satın alma koşullarını temsil etmelidir.
Kurulumdan önce hangi ürün verileri hazırlanmalıdır?
Kurulumdan önce ürün adı, görseller, ürün kimliği, fiyat, para birimi, stok ve kanonik URL tek bir veri kaynağından alınmalıdır. Böylece sayfa ile şema arasındaki farklılık azalır.
JSON-LD koduna elle yazılan fiyatlar, kampanya veya kur değişiminden sonra eski kalabilir. En güvenli yöntem, işaretlemeyi ürün veritabanı ya da e-ticaret altyapısındaki güncel kayıttan üretmektir.
- Ürün adı, sayfadaki ana ürün adıyla aynı olmalıdır.
- Görsel URL'si taranabilir ve ürünü açıkça göstermelidir.
- SKU, GTIN veya MPN yalnız mevcutsa eklenmelidir.
- Fiyat, kullanıcıların ödeyebildiği güncel tutarı göstermelidir.
- Para birimi ISO 4217 koduyla belirtilmelidir.
- Stok durumu, sipariş verilebilirlikle aynı anda güncellenmelidir.
- Kargo ve iade koşulları hedef ülkeyle eşleşmelidir.
GTIN bulunmayan özel üretim bir ürüne rastgele barkod yazılmamalıdır. Gerçek GTIN yoksa SKU ve marka gibi mevcut tanımlayıcılar kullanılmalı, olmayan veri şemaya eklenmemelidir.
Sunucu tarafında gösterilen fiyat ile JavaScript sonrasında oluşan fiyat farklıysa Google iki ayrı değer görebilir. Üretilen HTML, yapılandırılmış veri ve ödeme akışı aynı fiyat kaynağına bağlanmalıdır.
Birden fazla ekip veri düzenliyorsa alan sahipliği belirlenmelidir. Örneğin fiyatı ERP, stoku depo sistemi, iadeyi hukuk ekibi yönetebilir. Şema üretimi bu kaynakların yayınlanan son değerlerini birleştirmelidir.
Product ve Offer JSON-LD kodu adım adım nasıl eklenir?
Product ve Offer JSON-LD kodu, ürünün temel bilgileri Product altında; satış koşulları ise iç içe Offer nesnesinde tanımlanarak eklenir. Her ürün URL'si kendi verisini üretmelidir.
- Sayfanın kanonik URL'sini belirleyin. Offer içindeki url alanında aynı satın alınabilir ürün adresini kullanın.
- Product içine name, image ve description alanlarını görünür ürün içeriğinden aktarın.
- Mevcutsa sku, brand, gtin veya mpn tanımlayıcılarını gerçek katalog kayıtlarından alın.
- Offers içine price, priceCurrency, availability, url ve itemCondition alanlarını yerleştirin.
- Kargo koşulları biliniyorsa shippingDetails, iade koşulları biliniyorsa hasMerchantReturnPolicy ekleyin.
- Şablonu tüm kataloğa açmadan önce farklı fiyat ve stok durumlarına sahip örnek URL'lerde test edin.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Örnek Ürün",
"image": ["https://www.example.com/urun.jpg"],
"description": "Sayfada görünen ürün açıklaması",
"sku": "SKU-123",
"brand": {
"@type": "Brand",
"name": "Örnek Marka"
},
"offers": {
"@type": "Offer",
"url": "https://www.example.com/ornek-urun",
"priceCurrency": "TRY",
"price": "1499.90",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
</script>Örnekteki alanlar doğrudan kopyalanmamalıdır. Alan değerleri ürün kaydından dinamik gelmeli; örnek marka, SKU, adres ve fiyat gerçek sayfa verileriyle değiştirilmelidir.
JSON-LD genellikle sayfanın head veya body bölümüne yerleştirilebilir. Kritik konu konum değil, kodun taranan sayfada bulunması ve işaretlenen ürünün kullanıcıya görünmesidir.
Aynı sayfada eklenti ve tema ayrı Product nesneleri üretiyorsa mükerrer veri oluşabilir. Tek ve tutarlı bir ana nesne kullanmak, çelişen fiyat veya stok değerlerini önler.
Fiyat ve stok alanları nasıl doğru işaretlenir?
Fiyat ve stok alanları, kullanıcının sayfayı açtığı anda satın alabileceği teklif ile eşleştirilmelidir. Liste fiyatı yerine ödeme sürecinde geçerli olan erişilebilir fiyat kullanılmalıdır.
price alanında yalnız sayısal değer bulunur; para birimi priceCurrency içinde TRY, EUR veya USD olarak belirtilir. Türkçe görüntülenen 1.499,90 TL tutarı JSON-LD içinde 1499.90 biçiminde yazılabilir.
- Stokta bulunan ürün: https://schema.org/InStock
- Stokta olmayan ürün: https://schema.org/OutOfStock
- Ön sipariş ürünü: https://schema.org/PreOrder
- Sınırlı stok: https://schema.org/LimitedAvailability
- Üretimi biten ürün: https://schema.org/Discontinued
Stok durumu yalnız depo adedine göre belirlenmemelidir. Depoda ürün bulunsa bile satış kanalı sipariş kabul etmiyorsa InStock değeri kullanıcı deneyimini yanlış tanımlar.
Yanlış: Yalnız üyelerin veya kupon sahiplerinin görebildiği indirimli fiyatı herkese açık Offer fiyatı olarak yazmak. Doğru: Koşulsuz satın alınabilen ve sayfada açıkça görünen fiyatı işaretlemek.
Kampanya başlangıç ve bitişleri otomatik yönetilmelidir. Kampanya sona erdiğinde sayfa fiyatı değişip JSON-LD sabit kalırsa Google, görünür içerik ile yapılandırılmış veri arasında uyumsuzluk belirleyebilir.
Tek ürün birden fazla satıcı tarafından sunuluyorsa AggregateOffer düşünülebilir. Ancak kullanıcı belirli satıcıdan doğrudan satın alıyorsa o satıcının gerçek Offer verisi, stok durumu ve URL'si daha açıklayıcıdır.
Kargo bilgileri shippingDetails ile nasıl tanımlanır?
Kargo bilgileri, Offer içindeki shippingDetails alanına OfferShippingDetails nesnesi eklenerek tanımlanır. Hedef ülke, ücret ve tahmini teslimat aralığı ayrı alanlarda gösterilir.
shippingDestination teslimat bölgesini, shippingRate kargo ücretini açıklar. deliveryTime altında sipariş hazırlama süresi handlingTime, taşıma süresi ise transitTime ile belirtilebilir.
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"addressCountry": "TR"
},
"shippingRate": {
"@type": "MonetaryAmount",
"value": "0",
"currency": "TRY"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 0,
"maxValue": 1,
"unitCode": "DAY"
},
"transitTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 3,
"unitCode": "DAY"
}
}
}Bu örnekteki ücretsiz kargo ve süre değerleri yalnız yapıyı gösterir. Gerçek sitede value, minValue ve maxValue alanları yayınlanan kargo tablosundan üretilmelidir.
Farklı ülkeler veya bölgeler için birden fazla shippingDetails nesnesi kullanılabilir. Her nesne yalnız kapsadığı bölgenin ücretini ve teslimat süresini açıklamalıdır.
Kargo ücreti sepet toplamına, üyeliğe veya posta koduna göre değişiyorsa tek sabit değer yanıltıcı olabilir. Desteklenen koşullar ayrı tanımlanmalı; temsil edilemeyen ayrıntılar görünür kargo sayfasında açıklanmalıdır.
Merchant Center ve sayfa şeması birlikte kullanılıyorsa ülke, ücret ve teslimat aralığı çelişmemelidir. Güncelleme sonrasında iki kaynağı aynı test siparişi üzerinden karşılaştırmak pratik bir kontrol yöntemidir.
İade politikası hasMerchantReturnPolicy ile nasıl eklenir?
İade politikası, Offer içindeki hasMerchantReturnPolicy alanına MerchantReturnPolicy nesnesi eklenerek tanımlanır. Ülke, iade penceresi, yöntem ve masraf koşulları gerçek politika metniyle eşleşmelidir.
Sınırlı süreli iadelerde MerchantReturnFiniteReturnWindow kategorisi ve merchantReturnDays alanı kullanılabilir. İade kabul edilmiyorsa MerchantReturnNotPermitted seçilmeli; gerçekte bulunmayan bir iade süresi yazılmamalıdır.
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "TR",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "https://schema.org/ReturnByMail",
"returnFees": "https://schema.org/FreeReturn"
}Örnekteki 30 günlük süre, ücretsiz iade ve posta yöntemi örnek veridir. Kod yayınlanmadan önce sözleşme, yardım merkezi ve ödeme sonrası iade süreciyle karşılaştırılmalıdır.
Ürünlerin çoğu aynı politikaya sahipse kuruluş düzeyinde ortak politika tanımlamak tekrarları azaltabilir. İstisna ürünlerde Offer düzeyindeki politika, ilgili ürüne özgü koşulları açıklamak için kullanılabilir.
Hijyen ürünü, kişiselleştirilmiş ürün veya bozulabilir ürün gibi istisnalar tek genel kuralla işaretlenmemelidir. Sayfa şablonu, kategori veya ürün kaydındaki iade uygunluğuna göre farklı veri üretmelidir.
Merchant Center hesabındaki politika değiştiriliyorsa veri kaynağı ve hesap yapısı ayrıca kontrol edilmelidir. Geçiş süreci için Merchant Center iade politikası nasıl taşınır? rehberindeki adımlar uygulanabilir.
Ürün varyantlarında Merchant listing şeması nasıl uygulanır?
Ürün varyantlarında her satın alınabilir seçenek kendi fiyatı, stoku, kimliği ve mümkünse seçili URL'siyle tanımlanmalıdır. Ana ürün ilişkisi ProductGroup yapısıyla açıklanabilir.
Renk veya beden seçildiğinde URL değişiyorsa her adres doğru varyantı önceden seçmelidir. O URL'deki JSON-LD yalnız seçili varyantın görünen fiyat ve stok durumunu yansıtmalıdır.
ProductGroup içinde productGroupID ortak aileyi tanımlar. variesBy alanı color, size veya material gibi değişkenleri belirtir. hasVariant ise gruba bağlı Product kayıtlarını gösterebilir.
Her varyanta aynı SKU veya GTIN yazmak doğru değildir. Üretici her varyant için ayrı GTIN tanımlamışsa işaretleme de bu ayrımı korumalıdır.
Örneğin siyah ayakkabının 42 numarası stokta, 43 numarası tükenmiş olabilir. Kullanıcı 43 numarayı seçtiğinde availability değeri OutOfStock olarak güncellenmeli veya o seçeneğin ayrı URL'sinde gösterilmelidir.
Varyant seçimi yalnız tarayıcı içindeki geçici JavaScript durumuna bağlıysa arama motoru her seçeneği ayrı değerlendiremeyebilir. Seçili durumu açabilen kalıcı URL'ler, tarama ve hata ayıklama sürecini kolaylaştırır.
Tek URL'de onlarca varyantı görünmeyen fiyatlarla listelemek işe yaramaz. İşaretlenen seçenekler sayfada erişilebilir olmalı; stokta olmayan veya satın alınamayan kombinasyonlar aktif Offer gibi sunulmamalıdır.
Varyant sayısı yüksek kataloglarda örneklem testi yapılmalıdır. En ucuz, en pahalı, stokta olmayan ve kampanyalı varyantlardan URL seçmek, şablon kaynaklı veri hatalarını daha hızlı ortaya çıkarır.
Merchant listing şeması nasıl test edilir ve hatalar nasıl izlenir?
Merchant listing şeması önce Rich Results Test ile, ardından URL Denetleme ve Search Console raporlarıyla izlenmelidir. Test yalnız kod sözdizimini değil, canlı veri eşleşmesini de kapsamalıdır.
İlk kontrolde Product ve Offer nesnelerinin algılanıp algılanmadığı incelenir. Zorunlu hata varsa yayın durdurulmalı; önerilen alan uyarıları ise mevcut ve doğrulanabilir veri bulunduğunda tamamlanmalıdır.
- Test edilen URL'nin kanonik adresini kontrol edin.
- Google tarafından oluşturulan HTML içindeki JSON-LD kodunu açın.
- Sayfadaki fiyatı Offer fiyatıyla karşılaştırın.
- Sepete ekleme sonucunu availability değeriyle doğrulayın.
- Kargo ücretini örnek teslimat adresiyle test edin.
- İade süresini yayınlanan politika metniyle karşılaştırın.
- Düzeltme sonrasında yeniden tarama talep edin.
Geçerli sonuç almak anında görünürlük sağlamaz. Google sayfayı yeniden taramalı, veriyi işlemeli ve ilgili arama deneyimi için uygunluk değerlendirmesi yapmalıdır. Görünüm türü sorguya göre de değişebilir.
Şema hatasız olduğu hâlde ürün görünmüyorsa Merchant Center teşhisleri, politika sorunları ve veri kaynağı ayrıca incelenmelidir. Google Merchant Center ürünü neden listelenmiyor? rehberi bu ayrımı açıklar.
Enerji sınıfı veya yaşa duyarlı ürün bilgileri, temel Product şemasından farklı hesap alanları gerektirebilir. Gerektiğinde enerji verimliliği alanı güncelleme ve hasAdultConsideration ekleme adımları ayrıca uygulanmalıdır.
Canlıya geçişten sonra fiyat ve stok değişen örnek URL'ler düzenli izlenmelidir. Kontrol sıklığı, kataloğun güncellenme hızına göre belirlenmeli; her dağıtımda otomatik şema testi çalıştırılmalıdır.
Merchant listing şablonunuzda fiyat, stok, kargo veya iade uyuşmazlığı bulunuyorsa Sen Medyografya'dan teknik SEO incelemesi ve uygulanabilir hata listesi talep edebilirsiniz.
İlgili Yazılar
Sık Sorulan Sorular
Merchant listing için yalnız Product şeması yeterli midir?
Satın alınabilir ürün sayfasında Product içine Offer eklenmelidir. Fiyat, para birimi, stok ve ürün URL'si Offer üzerinden tanımlanır.
Merchant listing şemasında fiyat nasıl yazılmalıdır?
price alanına sayısal tutar, priceCurrency alanına TRY gibi ISO 4217 kodu yazılmalıdır. Değer, sayfada koşulsuz satın alınabilen fiyatla eşleşmelidir.
Kargo bilgisi Product şemasında nereye eklenir?
Kargo bilgisi Offer içindeki shippingDetails alanına eklenir. Hedef ülke, ücret, hazırlama süresi ve taşıma süresi ayrı özelliklerle belirtilir.
İade politikası ürün bazında tanımlanabilir mi?
Evet. Ürüne özgü iade koşulları Offer içindeki hasMerchantReturnPolicy alanıyla tanımlanabilir. Ortak politika kuruluş düzeyinde yönetilebilir.
Geçerli Merchant listing şeması arama sonucunda gösterimi garanti eder mi?
Hayır. Geçerli işaretleme yalnız uygunluk sağlar. Google tarama, veri tutarlılığı, sayfa niteliği ve arama bağlamına göre gösterime karar verir.