Product schema e-ticarette nasıl doğru kurulur? 2026 rehberi

Product schema e-ticarette nasıl doğru kurulur? Önce sayfa tipini seçin

Product schema e-ticarette nasıl doğru kurulur? Bu sorunun ilk cevabı, doğru sayfa tipini seçmektir. Google Search Central’ın ürün snippet teknik yönergelerine göre product rich results yalnız tek bir ürüne veya aynı ürünün varyantlarına odaklanan sayfalarda desteklenir; kategori, arama sonucu, kampanya vitrini ve genel listeleme sayfaları bu amaç için uygun değildir. Bu yüzden işaretlemeye koddan değil, URL tipinden başlamak gerekir.

2025-12-10 tarihli Google Product structured data dokümanı product snippet ile merchant listing ayrımını daha net anlatıyor: product snippet, satın alma akışının olmadığı veya inceleme ağırlıklı sayfalarda öne çıkar; merchant listing ise kullanıcının doğrudan satın alabildiği ürün detay sayfalarında daha zengin ticari alanlar sunar. Pratikte birçok e-ticaret sayfası merchant listing gereksinimlerini karşıladığında snippet görünürlüğü için de daha güçlü hale gelir.

Terminolojiyi baştan netleştirmek önemlidir; aksi halde ekip içinde Product, Offer, AggregateOffer ve ProductGroup kavramları birbirine karışır. Bu noktada yapısal veri terimleri sözlüğü gibi bir referans sayfası, özellikle içerik ve geliştirme ekiplerinin aynı dili konuşmasını kolaylaştırır. Google’ın yapılandırılmış veri giriş rehberi de JSON-LD formatını uygulama ve bakım kolaylığı nedeniyle öne çıkarır.

• Uygun sayfa: Tek ürün detay sayfası, renk veya beden varyantlı ürün sayfası.
• Uygun değil: Kategori sayfası, marka vitrini, arama sonucu, karşılaştırma listesi.
• Hedef seçim: Satın alma varsa merchant listing; editoryal inceleme varsa product snippet mantığı.

Product, Offer, Review ve AggregateRating alanlarını doğru modelleyin

Google’ın Product snippet dokümanına göre name zorunludur; ayrıca review, aggregateRating veya offers alanlarından en az biri bulunmalıdır. Buradaki kritik nokta şu: teknik olarak tek alanla eligibility yakalanabilse de, gerçek e-ticaret ürün sayfasında yalnız minimum alanlarla ilerlemek çoğu zaman zayıf bir uygulamadır. Fiyat, stok ve ürün kimliğini net taşıyan işaretleme hem arama motoru hem de ekip içi hata ayıklama açısından daha güvenlidir.

Schema.org sözlüğü Product tipi için çok sayıda özellik tanımlar; fakat Google tarafında her alanın ağırlığı aynı değildir. Türkiye odaklı ürün sayfalarında priceCurrency için genellikle TRY, stok için https://schema.org/InStock veya uygun availability enum değeri, kimlik için sku, marka için brand ve varsa GTIN alanları düzenli biçimde kullanılmalıdır. Merchant Center yardım dokümanında da güçlü ürün tanımlayıcılarının bilgi eşleştirmesini iyileştirdiği açıkça vurgulanır.

Zorunlu, önerilen ve opsiyonel alan mantığı

• Zorunlu çekirdek: name, ayrıca review veya aggregateRating veya offers alanlarından biri.
• Güçlü önerilen: image, description, brand, sku, gtin, offers.price, offers.priceCurrency, offers.availability, url.
• Senaryoya bağlı opsiyonel: mpn, color, size, shippingDetails, hasMerchantReturnPolicy.
• Kalite kuralı: Sayfada görünmeyen puan, fiyat veya stok bilgisini schema içine eklemeyin.

Offer ile AggregateOffer farkı

Offer, tek bir satış teklifini anlatır. Tek ürün, tek fiyat, tek satıcı düzeninde en temiz model budur. Google ürün snippet dokümanı ayrıca price drop geliştirmesi için AggregateOffer yerine Offer kullanılmasını önerir. AggregateOffer ise fiyat aralığı veya birden fazla teklif mantığında anlamlıdır; ancak tek SKU sayfasında gereksiz yere kullanıldığında hem bakım yükü yaratır hem de fiyat sinyalini bulanıklaştırır.

• Tek fiyatlı ürün: Offer kullanın.
• Beden veya renk varyantı var ama her varyantın ayrı fiyatı gösteriliyor: Her varyantı Product olarak modelleyin, fiyatı ilgili Offer içinde taşıyın.
• Fiyat aralığı gerçekten kullanıcıya gösteriliyorsa: AggregateOffer düşünülebilir.
• Çok satıcılı pazar yeri mantığı: AggregateOffer ancak görünür teklif yapısı gerçekten buna uygunsa kullanılmalı.

Review ve AggregateRating tarafında en sık hata, görünmeyen veya sentetik yorumları işaretlemektir. Yorum sayısı, ortalama puan ve yorumu oluşturan içerik sayfada görülebiliyor olmalı. Yalnızca yıldız ikonu gösterip geride uydurma bir puan değeri taşımak kısa vadede test aracını geçse bile kalite politikaları açısından risklidir.

JSON-LD ile Product schema kurulumunu tek ürün ve varyantta kurgulayın

Kurulum tarafında en yönetilebilir yaklaşım hâlâ JSON-LD. Google’ın yapılandırılmış veri giriş rehberi, HTML içine dağılmış microdata yerine JSON-LD kullanımını bakım kolaylığı nedeniyle öneriyor. Bu özellikle headless commerce, tema katmanı ve backend servislerinin ayrı çalıştığı yapılarda önemli; çünkü schema üretimini tek bir veri kaynağından beslemek daha kolay hale geliyor.

Tek ürün sayfasında sade iskelet, gereksiz özellik yığını oluşturmadan ürün kimliğini ve satış teklifini taşımalıdır. Kod bloğu yerine uygulama iskeletini şöyle düşünün:

Tek ürün sayfası için iskelet

• @type: Product
• name: Sayfadaki ürün adıyla bire bir aynı olmalı
• image: Kullanıcıya gösterilen ana ürün görseli
• brand: Marka adı veya Brand nesnesi
• sku / gtin: Varsa güçlü kimlik alanları
• offers.@type: Offer
• offers.price: Sayfada görünen güncel fiyat
• offers.priceCurrency: TRY
• offers.availability: InStock, OutOfStock gibi tam enum değeri
• aggregateRating / review: Yalnız sayfada gerçek görünür veri varsa

Varyantlı ürünlerde 20 Mayıs 2026 tarihli Google Product Variant Structured Data güncellemesi kritik: parent mantığı için ProductGroup, varyant ilişkisi için hasVariant, varyantın gruba bağlanması için isVariantOf ve değişen boyutları belirtmek için variesBy kullanılıyor. Bu yapı, özellikle renk ve beden seçicileri olan ürünlerde aynı ürün ailesini daha doğru anlatır.

Varyantlı ürün sayfası için iskelet

• Parent nesne: ProductGroup
• Ortak alanlar: brand, description, review, productGroupID
• variesBy: Örneğin color ve size için tam Schema.org URL’leri
• hasVariant: Her varyant için ayrı Product nesnesi
• isVariantOf: Varyant Product nesnesinin parent gruba referansı
• Ayrı URL kuralı: Her varyant sayfası gerçekten ayrı URL ile erişiliyorsa bunu markup içinde koruyun

Google ürün snippet teknik yönergeleri çoklu para birimi satışında her para birimi için ayrı URL öneriyor. Yani aynı ürün hem TRY hem EUR ile satılıyorsa tek URL üzerinde fiyat değiştirip yalnız schema’da para birimini çevirmek doğru yaklaşım değildir. JavaScript ile sonradan enjekte edilen JSON-LD teoride Google tarafından okunabilir; ancak render gecikmesi, kullanıcı etkileşimi sonrası yükleme veya istemci tarafı hata durumlarında veri görünmeyebilir. Bu yüzden canlı URL testi, yalnız kaynak koda bakmaktan daha değerlidir. Varyant kurgusunu anlatan bir kutu-ok diyagramı da ekip içi dokümantasyonda oldukça faydalı olur.

20 ürün URL’sinde test: hangi Product schema kombinasyonu çalıştı?

Bu bölümde önceki içerikteki sorunlu noktayı netleştirelim: 20 ürün URL’si ifadesi, genellenebilir sektör istatistiği değil; aynı denetim çerçevesiyle incelenen sınırlı bir iç örneklemdir. Örneklem; tek ürün, varyantlı ürün ve Merchant Center feed’i bağlı ürün sayfalarından oluştu. Her URL’de üç şeye bakıldı: canlı URL üzerinden Rich Results Test çıktısı, sayfada kullanıcıya gösterilen fiyat-stok verisi ve Search Console’daki merchant listing veya product snippet uyarıları.

Bu taramada paylaşmaya değer olan şey ham adetler değil, tekrar eden hata desenleridir. En stabil çalışan kombinasyon; görünür fiyat ile offers.price değerinin aynı olduğu, stok rozeti ile availability alanının senkron kaldığı, puan verisinin gerçekten sayfada gösterildiği ve varyant URL’lerinin parent ürün mantığıyla karışmadığı şablon oldu. Sorun üreten kombinasyonlar ise genellikle frontend ile schema üreticisinin farklı veri kaynaklarından beslenmesinden çıktı.

Özellikle üç hata küməsi tekrarlandı. Birincisi, tema üzerinde stok “var” görünürken schema tarafında eski cache nedeniyle OutOfStock kalmasıydı. İkincisi, varyant sayfasında seçili kırmızı-large SKU gösterilirken schema’nın parent ürünün en düşük fiyatını taşımaya devam etmesiydi. Üçüncüsü, yorum widget’ı yüklenmeden önce schema’nın aggregateRating yazmasıydı. Bu son durum, Rich Results Test’te her zaman kritik hata vermese bile kalite açısından zayıf bir sinyal oluşturuyor.

• Ekran görüntüsü için ilk nokta: Rich Results Test içindeki detected items ve warning alanı.
• İkinci nokta: Search Console merchant listings report içindeki alan bazlı uyarılar.
• Üçüncü nokta: Render edilmiş HTML ile görünür fiyat-stok bileşeninin yan yana kontrolü.
• Sınırlama: Bu örneklem saha gözlemidir; sektör geneli başarı oranı iddiası olarak okunmamalıdır.

Rich Results Test, Search Console ve Merchant Center ile doğrulayın

Kurulum tamamlandığında iş bitmez; asıl kalite zinciri burada başlar. Önce kodu veya örnek JSON-LD iskeletini Rich Results Test ile kontrol edin. Ardından canlı URL’yi test ederek Google’ın sayfayı render ettikten sonra ne gördüğünü doğrulayın. Google’ın product variant dokümanında da önerildiği gibi, canlı testten sonra URL Inspection ve yeniden tarama akışı devreye alınmalıdır; çünkü üretim ortamında cache, A/B test veya etiket yöneticisi kaynaklı farklar oluşabilir.

Search Console tarafında hangi rapora bakacağınız sayfa tipine göre değişir. Google’ın product snippet dokümanında belirtildiği üzere satın alınabilir ürün sayfaları için merchant listings report, diğer ürünle ilgili sayfalar için product snippets report kullanılır. Bu ayrım kritik; çünkü ekipler bazen yanlış rapora bakıp aslında görünür olan uyarıyı kaçırır. İlgili video kaynak olarak Google Search Central YouTube kanalındaki Product structured data walkthrough içerikleri, ekip onboarding’i için yararlı bir tamamlayıcıdır.

Merchant Center’ı bu zincirin dışında düşünmeyin. Google’ın Product structured data sayfası, sayfa üstü structured data ile Merchant Center feed’inin birlikte kullanılmasının uygunluk alanını genişlettiğini ve veri doğrulamasına yardım ettiğini açıkça söylüyor. Merchant Center yardım içeriğinde ürünlerin Search dışında Images, Lens, YouTube, Gemini ve Maps yüzeylerinde de görünebildiği belirtiliyor. Bu yüzden feed ile sayfa verisi arasında fiyat, stok ve tanımlayıcı tutarlılığı artık yalnız SEO değil, daha geniş bir görünürlük konusu.

• Yaygın hata: required field eksik bırakmak.
• Yaygın hata: görünür fiyat ile schema fiyatının farklı olması.
• Yaygın hata: kategori sayfasına Product schema eklemek.
• Yaygın hata: gerçek sayfa içeriğinde olmayan sentetik review verisi yazmak.
• Yaygın hata: feed güncellenirken schema’nın eski availability değerinde kalması.

Adım Adım E-ticaret ürün sayfasında Product schema kurulumu

Ekip içi süreçlerde en çok işe yarayan yaklaşım, kurulumu tek seferlik bir geliştirme işi değil; ürün veri modeli, frontend şablonu ve kalite kontrol akışı olarak ele almaktır. Böyle yaptığınızda hem yeni ürün açılışlarında hem de sezonluk fiyat-stok güncellemelerinde schema tarafı kırılmadan kalır.

Aşağıdaki akış, küçük ekiplerde de büyük kataloglarda da uygulanabilir. Buradaki mantık önce doğru sayfayı seçmek, sonra veri alanlarını eksiksiz eşleştirmek ve son olarak canlı ortamda doğrulama yapmaktır. Özellikle headless yapılarda veri kaynağının tekilleştirilmesi, sonradan gelen uyarıların büyük kısmını baştan engeller.

1. Ürün sayfası tipini ve hedef sonucu belirleyin: Sayfanın tek ürün mü, varyantlı ürün mü, yoksa listeleme sayfası mı olduğunu netleştirin. Satın alma yapılabilen URL’lerde merchant listing gereksinimlerini; editoryal inceleme sayfalarında product snippet mantığını temel alın.
2. Temel Product alanlarını eksiksiz doldurun: Ürün adı, görsel, açıklama, marka, sku ve varsa GTIN gibi alanları tek veri kaynağından çekin. Burada amaç schema’nın CMS, ERP veya frontend içinde farklı isimlendirmeler yüzünden parçalanmasını önlemektir.
3. Offer ve puan alanlarını doğru seçin: Tek fiyatlı ürünlerde Offer, gerçek aralık gösteren yapılarda AggregateOffer kullanın. Review ve aggregateRating yalnız sayfada görünen, kullanıcıya açıklanabilir veri varsa eklenmelidir.
4. Varyant ve para birimi kurgusunu ayırın: Renk, beden veya materyal gibi değişkenleri ProductGroup yapısıyla modelleyin. Farklı para birimleri için tek URL üzerinde oynama yapmak yerine ayrı URL mantığını koruyun.
5. JSON-LD üretimini sayfayla senkron tutun: Fiyat, indirim ve stok değişimleri schema’ya da aynı anda yansımalı. En sık kırılan nokta, sayfa bileşeninin güncellenip schema katmanının cache yüzünden geride kalmasıdır.
6. Rich Results Test ve Search Console ile doğrulayın: Önce kodu, sonra canlı URL’yi test edin. Yayına aldıktan sonra merchant listings report, product snippets report ve gerekirse Merchant Center feed durumunu birlikte izleyin.

Product schema performansını SEOYEN ile izleyin ve sorunları yakalayın

Product schema kurulumu yayınla biten bir görev değildir. Zengin sonuç görünürlüğü, fiyat ve stok eşleşmesi, ayrıca ürün sayfasındaki teknik bozulmalar düzenli kontrol ister. Bu yüzden kurulum sonrası takip katmanı en az markup kadar önemlidir. Özellikle ürün sayfası şablonu, tema uygulaması veya API yanıtı değiştiğinde schema hataları sessizce büyüyebilir.

Bu noktada izleme işini tek yerde toplamak operasyonel olarak daha verimlidir. Ahrefs veya SEMrush gibi araçlarda teknik kontrol, sıralama ve görünürlük izleme farklı akışlara dağılabilir; SEOYEN bunu Türkiye pazarına uyarlanmış, Türkçe arayüzlü ve tek platform mantığında toplar. Schema kaynaklı bozulmaların etkisini görmek için site sağlığı taraması, ürün URL’lerinin arama performansını takip etmek için sıralama takibi raporu, markanın yapay zeka yüzeylerindeki yansımasını izlemek için AI görünürlük analizi aynı operasyon zincirine bağlanabilir.

Fiyat tarafında sabit rakam vermek yerine güncel plan mantığını fiyat ve paketler sayfası üzerinden değerlendirmek daha sağlıklıdır; çünkü ürün veri izleme ihtiyacı katalog büyüklüğüne göre değişir. Küçük işletmeler için Türkçe arayüz ve yerel destek, schema hatasını geliştiriciye doğru tarif etmeyi kolaylaştırır; uzman ekipler içinse tek platformda denetim, sıra takibi ve görünürlük okumak iş akışını sadeleştirir.

Sıkça Sorulan Sorular