E-Ticaret Ürün Sayfaları İçin Schema Markup Rehberi

E-ticaret ürün sayfaları için schema markup rehberi: Product + Offer omurgası

E-ticaret tarafında en güvenli başlangıç, her ürün URL’sini Product ve o ürüne bağlı teklifi Offer ile modellemektir. Google’ın Product Snippet dokümantasyonu ürün adı, görsel, teklif ve değerlendirme verisinin sayfada anlaşılır biçimde işaretlenmesini ister; aynı konu Merchant Listing dokümantasyonunda alışveriş görünürlüğü açısından daha da netleştirilir (Google Search Central, Product Snippet, 2025-12-10; Google Search Central, Merchant Listing, 2026-07-07). Kısa kural şu: Google önce ürünün ne olduğunu, sonra o ürünün hangi fiyat ve stok koşuluyla satıldığını görmelidir.

Uygulamada en pratik format hâlâ JSON-LD’dir. Çünkü tema dosyasına ya da uygulama katmanına daha temiz eklenir, front-end güncellemelerinde daha az kırılır ve görünür içerikle senkron kontrolü kolaylaşır. Buradaki kritik nokta, schema içine yazdığınız alanların sayfadaki gerçek içerikle birebir eşleşmesidir. Başlıkta farklı isim, işaretlemede farklı ürün adı; sayfada indirimli fiyat varken markup içinde eski fiyat; stokta yokken availability içinde satışta gibi çelişkiler, zengin sonuç uygunluğunu zayıflatır.

Hangi alanlar çekirdek, hangileri zorunluya yakın?

Tek ürün sayfasında ürün omurgasını kurarken isim, görsel, açıklama ve teklif ilişkisini ilk katman olarak düşünün. Sonrasında brand, sku, gtin ve mpn alanları devreye girer. Teknik olarak her katalogda hepsi aynı düzeyde şart değildir; ancak Google’ın ürün ekosisteminde ticari tanımlayıcılar ne kadar netse eşleşme ve doğrulama o kadar temiz ilerler. Özellikle üretici barkodu olan kataloglarda GTIN’i boş bırakmak yerine doğru varyanta bağlamak gerekir.

• Temel omurga: name, image, description, offers.
• Offer çekirdeği: price, priceCurrency, availability, url.
• Zorunluya yakın tanımlayıcılar: brand, sku, gtin, mpn.
• Görünürse ekleyin: review, aggregateRating, itemCondition.
• Kaçınılacak hata: kategori sayfasını tek ürünmüş gibi işaretlemek.

Product snippet mı Merchant listing mi: hangi görünüm için hangi işaretleme?

Product snippet, organik sonuçta ürün bilgilerini zenginleştirmeye odaklanır. Merchant listing ise alışveriş görünürlüklerinde teklif bilgisini daha belirgin kullanır. Bu yüzden aynı Product gövdesi çoğu zaman iki görünüm için de başlangıçtır; farkı yaratan katman, Offer içindeki fiyat, para birimi, stok ve ürün durumu gibi alanların ne kadar eksiksiz olduğu olur. Google’ın Merchant Listing dokümantasyonu 2026-07-07 güncellemesinde bu teklif alanlarını özellikle merkezî konumda tutuyor.

Karar verirken şu soruyu sorun: “Ben yalnızca ürünün ne olduğunu mu açıklıyorum, yoksa satın alma teklifini de görünür ve güncel biçimde sunuyor muyum?” İkinci soruya cevabınız evetse merchant listing mantığıyla hareket etmelisiniz. E-ticarette çoğu ürün sayfası zaten fiyat ve stok barındırdığı için pratikte hedef, yalnız product snippet almak değil, alışveriş tarafındaki uygunluğu da temiz kurmaktır. Bu yüzden birçok ekip product snippet mantığıyla başlayıp merchant listing gereksinimlerini eksik bıraktığı için kapsama kaybı yaşar.

Kargo ve iade bilgisi bu noktada devreye girer. Eğer sayfada ya da site genelinde görünür, tutarlı ve kullanıcıya açık politikalarınız varsa bunları ShippingService ve MerchantReturnPolicy ile bağlamak mantıklıdır. Google’ın Merchant Shipping Policy sayfası 2026-01-07, Merchant Return Policy sayfası ise 2025-12-10 tarihinde güncellenmiş durumda; bu da teklif deneyiminin artık yalnız fiyat ve stoktan ibaret olmadığını gösterir (Google Search Central, Merchant Shipping Policy, 2026-01-07; Google Search Central, Merchant Return Policy, 2025-12-10).

• Product snippet hedefi: ürün bilgisini doğru anlat, görünür içerikle eşleştir.
• Merchant listing hedefi: teklif bilgisini eksiksiz, güncel ve doğrulanabilir ver.
• Politika katmanı: kargo ve iade bilgisini yalnız görünürse işaretle.

Varyantlı ürünlerde fiyat, stok, GTIN ve review verisi nasıl modellenir?

Renk, beden, kapasite ya da paket tipi gibi varyantlar varsa tek Product nesnesine her şeyi yığmak çoğu zaman sorun üretir. Google’ın Product Variants dokümantasyonu, 2026-05-20 güncellemesinde ProductGroup, hasVariant ve isVariantOf ilişkilerini daha merkezî bir model olarak anlatıyor (Google Search Central, Product Variants, 2026-05-20). Pratik mantık şudur: ortak ürün ailesini ProductGroup temsil eder; her gerçek satın alma seçeneği ise ayrı Product olarak yaşar.

Fiyat ve stok bilgisini varyant bazında tutmanız gerekir. Siyah, M beden, stokta var ve indirimde olan varyant ile beyaz, L beden, tükenmiş varyant aynı Offer içinde eritilirse Google hangi URL’de hangi teklifi göstereceğini karıştırır. Aynı şekilde GTIN varsa bunu üst ürün yerine doğru varyanta bağlamak daha sağlıklıdır. sku çoğu katalogda iç kimlik olarak yeterlidir; gtin ve mpn ise dış eşleşme sinyali sağlar. Marka bilgisi genelde üst ürün katmanında ortak kalabilir, fakat varyant sayfası kendi Product nesnesinde bu ortak bilgiyi yineleyebilir.

Yorum ve puan tarafında en kritik konu ilişki doğruluğudur. Varyant özelinde gelen yorumları tüm kardeş varyantlara kopyalamak yerine, sayfada gerçekten gösterilen veriyle eşleştirin. Eğer yorumlar üst ürün ailesi için toplanıyor ve her varyant sayfasında aynı toplam puan görünüyorsa bunu tutarlı biçimde üst ürün mantığında yansıtabilirsiniz. Ama yalnız kırmızı model için olan yorumları mavi model sayfasında aggregateRating olarak taşımak, görünür içerik tutarsızlığı üretir.

• Üst seviye: ProductGroup içinde ortak ad, marka ve varyant eksenleri.
• Varyant seviyesi: ayrı url, sku, fiyat, para birimi ve availability.
• Tanımlayıcılar: GTIN veya MPN hangi varyanta aitse oraya yazılmalı.
• Review kuralı: yalnız sayfada gösterilen ve ilişkilendirilen yorumlar işaretlenmeli.

Üç ürün kurgusunda test ettik: en temiz merchant listing kapsaması hangi yapıda?

Uygulamada en sık karşılaştığımız üç kurgu şu oluyor: tekil ürün sayfası, varyant landing page ve marketplace beslemesiyle desteklenen ürün sayfası. Bu üç modelde en temiz merchant listing kapsaması genelde ürün URL’si ile teklif verisinin birebir eşleştiği, yani fiyat ve stok bilgisinin tek bir satın alma seçeneğini anlattığı yapılarda çıkıyor. Varyantların aynı sayfada toplandığı ama JSON-LD tarafında ayrı ayrı ayrıştırılmadığı kurgu ise en çok belirsizlik üreten model oluyor.

Tekil ürün sayfasında hata ayıklama daha kolaydır; çünkü tek Product, tek Offer ve daha net bir görünür içerik akışı vardır. Varyant landing page tarafında ise sorun çoğunlukla yanlış ProductGroup kurulumu, tüm varyantlara aynı fiyatın yazılması veya availability değerinin üst üründe bırakılması şeklinde görünür. Marketplace beslemesiyle desteklenen yapılarda ek bir senkron ihtiyacı doğar: sayfadaki fiyat, yapılandırılmış veri ve dış besleme farklılaştığında Merchant listing tarafında güven kaybı oluşur.

Bu üç senaryoda tekrar eden hata örnekleri çok benzer: görünmeyen review verisinin işaretlenmesi, stokta olmayan varyantın satılabilir gösterilmesi ve indirimli fiyatın sayfada güncellenip schema içinde eski değerin kalması. Yeniden işleme süresi için sabit gün vermek doğru olmaz; Google, yeniden tarama ve yeniden indekslemenin birkaç gün sürebileceğini açıkça belirtir (Google Search Central, Merchant Listing, 2026-07-07). Bizim operasyonel gözlemimiz, en az düzeltme turu gerektiren yapının teklif verisini URL bazında en net ayıran mimari olduğudur.

• En temiz kurgu: URL ile teklifin birebir eşleştiği tekil veya net varyant yapısı.
• En riskli kurgu: tüm varyantları tek Offer içine sıkıştıran landing page.
• En sık hata: görünür içerik, feed ve schema arasında fiyat uyumsuzluğu.

Adım Adım E-ticaret Ürün Sayfasına Schema Markup Kurma

Uygulama sırası doğru kurulduğunda structured data işi karmaşık olmaktan çıkar. Buradaki amaç tek seferde mükemmel şema yazmak değil; görünür veriyi en temiz şekilde envanterleyip, doğru tipleri seçip, sonra test ederek yayına almaktır. Özellikle varyantlı kataloglarda önce bilgi mimarisi netleşmeden JSON-LD katmanına geçmek ileride daha çok revizyon doğurur.

Bu akış, geliştirici ekip ile SEO ekibini aynı check-list üzerinde toplamak için de kullanışlıdır. JSON-LD ürün schema kodu arayan ekipler için en iyi yaklaşım, kopyala-yapıştır şablondan önce alan eşleştirme mantığını doğru kurmaktır; çünkü hataların büyük bölümü söz diziminden değil, veri modelinden çıkar.

1. Görünür ürün verisini sayfada envanterle: Ürün adı, fiyat, indirim, stok, marka, varyant ve yorum alanlarının gerçekten sayfada göründüğünü doğrula. Schema içine ekleyeceğin hiçbir veri yalnız panelde var diye kullanılmamalı.
2. Sayfa tipini tekil mi varyantlı mı seç: Her URL tek bir satın alma seçeneği mi anlatıyor, yoksa renk ve beden seçimi tek sayfada mı yapılıyor? Bu karar Product mı yoksa ProductGroup mü kuracağını belirler.
3. Product ve Offer alanlarını JSON-LD ile kur: Name, image, brand, sku ve description ürün omurgasını; price, priceCurrency, availability, url ve itemCondition teklif omurgasını oluşturur. Önce bu çekirdeği temiz kur.
4. Review, kargo ve iade bilgisini bağla: Yalnız görünür ve doğrulanabilir yorumları kullan. Kargo süresi, ücret politikası veya iade koşulu sayfada ya da politika sayfasında açıkça yer alıyorsa ilgili markup ile bağla.
5. Rich Results Test ile ilk doğrulamayı yap: Google uygunluğunu ve eksik alanları burada gör. Ardından sözlük düzeyindeki hatalar için Schema Markup Validator ile ikinci kontrol yap; iki araç farklı türde sorunları yakalar.
6. Search Console ve sitemap ile izlemeyi başlat: Yayına aldıktan sonra URL Denetleme Aracı ile yeniden tarama iste, sitemap’i güncelle ve hata raporlarını izle. Şema güncellemesini tek seferlik iş değil, operasyon rutini olarak ele al.

Yayın öncesi doğrulama ve yayın sonrası izleme kontrol listesi

Yayın öncesi doğrulamada üç katman kullanın: önce Rich Results Test ile Google görünüm uygunluğunu kontrol edin, sonra Schema Markup Validator ile sözlük düzeyindeki alanları tarayın, en son canlı URL’yi Search Console üzerinden çağırın. Product Snippet ve Merchant Listing dokümantasyonlarının ikisi de doğrulama, kademeli yayın ve sonrasında izleme disiplinini öneriyor. Bu sıralama sayesinde “kod geçerli ama Google için eksik” ile “Google için mantıklı ama sözlükte bozuk” problemlerini birbirinden ayırabilirsiniz.

• Sayfadaki başlık, fiyat ve stok değeri ile markup içeriğini yan yana kontrol edin.
• Varyant URL’lerinde canonical, seçili varyant ve schema ilişkisini birlikte doğrulayın.
• Search Console’da ilgili zengin sonuç raporlarını ve URL Denetleme çıktısını izleyin.
• Schema değişikliği sonrası XML sitemap güncellemesini operasyon akışına bağlayın.
• Yeniden tarama sonrası birkaç gün gözlem penceresi bırakın; anlık hüküm vermeyin.

Bu operasyonu tek panelden yürütmek isteyen ekipler için SEOYEN burada doğal bir avantaj sağlar. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer farklı SEO işlerinde faydalı araçlardır; SEOYEN ise şema sonrası takip tarafını Türkiye pazarına uyarlanmış, tek platformda tüm SEO araçları yaklaşımıyla toplar. Özellikle site sağlığı denetimleri ve AI görünürlük takibi birlikte kullanıldığında, işaretleme hatasının yalnız teknik doğruluğunu değil, görünürlük etkisini de ekip içinde daha okunur hâle getirir.

Operasyonel tarafta dil ve destek de önemlidir. Teknik SEO süreci yalnız geliştirici işi değildir; içerik, ürün ve performans ekipleri de aynı veriye bakar. SEOYEN’in Türkçe arayüzü, TL bazlı fiyatlandırması ve yerel Türkçe desteği bu yüzden özellikle küçük işletmelerde sürtünmeyi azaltır. Plan karşılaştırması yapmak isteyen ekipler fiyat ve paket detayları üzerinden güncel yapıyı görebilir; önemli olan nokta, schema doğrulamasını raporlama ve takip sürecinden ayrı düşünmemektir.

Sıkça Sorulan Sorular