Rakip Ürün Sayfası Yapılandırılmış Veri Analizi

Rakip bir ürün sayfasının yapılandırılmış verisini okumak için sayfanın JSON-LD bloğunu görüntüler, alanları Google'ın Product ve Offer belgelerindeki zorunlu ve önerilen listelerle satır satır eşleştirir, sonucu "var, yok, fazla, şüpheli" diye işaretlersiniz. Elde ettiğiniz tablo rakibi kopyalamanız için değil, kendi ürün şablonunuzda hangi alanın eksik olduğunu görmeniz için kullanılır. Pazaryeri ilan sayfası, mağaza ürün sayfası veya marka sitesi yöneten e-ticaret SEO ekipleri bu karşılaştırmayı şablon değişikliklerinden önce yapabilir.

Akışta örnek olarak bir spor ayakkabı ürün sayfası kullanılır. Alan adları ve kurallar Google Search Central belgelerinden alınır, sayfa ve alan değerleri ise kurgusaldır.

Rakip işaretlemesi neden karşılaştırma verisidir

Bir rakibin sayfasındaki işaretleme, o ekibin şablonunda hangi alanların üretildiğini gösteren herkese açık bir kayıttır. Fiyat, stok durumu, kargo ve iade bilgisi, marka, ürün kodları ve görsel listesi gibi alanların hangisinin doldurulduğunu tek bakışta görürsünüz. Bu kayıt sıralama sonucunu açıklamaz. Bir alanın bulunması, rakibin o alandan kazanç sağladığını da göstermez.

Google, ürün işaretlemesini iki sınıfa ayırır. Birincisi "product snippets": ürünün doğrudan satın alınamadığı sayfalar için. İkincisi "merchant listings": müşterilerin ürünü sizden satın alabildiği sayfalar için. Belgeye göre ikisi arasında örtüşme vardır ve merchant listings için gerekli ürün bilgisi alanlarını eklemek, sayfanızı product snippets için de uygun hale getirebilir. Rakip sayfayı okumadan önce hangi sınıfın hedeflendiğini belirlemek gerekir, çünkü zorunlu alan listesi buna göre değişir.

Karşılaştırmayla cevaplanabilen sorular

• Rakip sayfa satın alınabilir bir ürün sayfası mı, yoksa inceleme ya da yönlendirme sayfası mı?
• Zorunlu alanların hepsi bulunuyor mu, yoksa sayfa eksik alan nedeniyle uygunluk dışında mı kalıyor?
• Önerilen alanlardan hangileri dolu: marka, renk, beden, ürün kodu, durum, kargo, iade?
• Fiyat ve stok bilgisi sayfadaki görünür metinle aynı mı?

Cevaplanamayan sorular

Rakibin zengin sonuç alıp almadığı, hangi sorgularda göründüğü veya işaretlemenin trafiğe etkisi sayfa kaynağından okunamaz. Bunlar için kendi Search Console verinizdeki ilgili raporlara bakarsınız, ancak bu raporlar yalnızca sizin sitenizi kapsar. Rakip hakkında bu konuda belgelerde ifade yok.

Sayfadaki JSON-LD'yi görüntülemek

Google üç biçimi destekler: JSON-LD, Microdata ve RDFa. JSON-LD önerilen biçimdir. Rakip sayfada işaretleme bu üç biçimden biriyle bulunabilir, bu yüzden önce hangisinin kullanıldığını bulmanız gerekir.

Tarayıcı yöntemi

Herkese açık ürün sayfasını normal bir ziyaretçi gibi açın. Sayfa kaynağını görüntüleyin ve script etiketlerinde tür değeri application/ld+json olan blokları arayın. Her blok bir veya birden çok öğe içerebilir. Blokları bir metin dosyasına kopyalayıp biçimlendirirseniz iç içe Offer ve Brand nesnelerini okumak kolaylaşır. Sayfayı elle ve tek tek açmak yeterlidir. Toplu tarama, giriş gerektiren sayfalara erişme veya hizmet şartlarını ihlal eden otomasyon bu çalışmanın parçası değildir.

Sayfa kaynağı ile işlenmiş sayfa arasındaki fark

Bazı sayfalarda işaretleme ilk HTML'de bulunmaz, tarayıcıda çalışan betiklerle eklenir. Sayfa kaynağını görüntülediğinizde blok görünmüyorsa geliştirici araçlarının öğeler sekmesinde işlenmiş HTML'e de bakın. Bu fark kendi başına bir bulgudur. Google, Product işaretlemesinin ilk HTML'de bulunmasını önerir. Ayrıntısı JavaScript bölümünde yer alır.

Doğrulama aracı kararı

Google'ın merchant listing belgesi (yeni sekmede açılır), kodu "Rich Results Test" ile doğrulamayı önerir. Araç, belgede kendi kodunuzu sınamak için anılır. Rakip sayfayı bu araca vermek teknik olarak mümkün olabilir, ancak belgelerde rakip sayfa için kullanımı hakkında ifade yok. Uygulama önerisi: rakip incelemesinde tarayıcı yöntemini ana yol yapın, araç adını yalnızca kendi şablonunuzun çıktısını sınarken kullanın. Böylece rakip analizi herkese açık HTML okumasıyla sınırlı kalır ve aracın sonucu ile rakibin gerçek durumu birbirine karışmaz.

Zorunlu ve önerilen alanlara göre tablo çıkarmak

Merchant listings belgesindeki liste karşılaştırma tablosunun omurgasıdır. Product türünde zorunlu alanlar name, image ve offers'tır. offers alanı iç içe bir Offer olmalıdır. Offer içinde price (veya priceSpecification.price) ve priceCurrency (veya priceSpecification.priceCurrency) zorunludur. Diğer alanlar önerilen alanlardır.

Tabloyu her rakip sayfa için ayrı bir sütun olarak çoğaltabilirsiniz. Hücreleri dört değerden biriyle doldurun: var, yok, fazla, şüpheli. "Fazla" sayfada görünmeyen alan, "şüpheli" ise değeri sayfa metniyle çelişen alan demektir.

Offer tarafında okunacak ayrıntılar

Fiyat satırı kolay yanlış okunan kısımdır. Belgeye göre merchant listing deneyimleri sıfırdan büyük bir fiyat ister. Product snippets için bu koşul aranmaz. Etkin fiyat Offer düzeyinde price olarak verilebildiği gibi priceSpecification içinde de verilebilir. İkisi birlikte kullanılırsa Google offers.price değerini kullanır ve priceSpecification'ı yok sayar. Rakip kaynakta ikisini birden gördüğünüzde bunu bir tutarsızlık notu olarak yazın.

availability alanı için belgede on değer sayılır, örneğin InStock, OutOfStock, PreOrder, SoldOut. Birden fazla değer verilmemelidir. itemCondition için üç değer vardır: NewCondition, RefurbishedCondition, UsedCondition. Bu alanda da yalnızca biri verilmelidir. priceValidUntil için belge, geçmiş bir tarih verilirse listenin gösterilmeyebileceğini söyler. Rakip sayfada geçmiş tarihli bir priceValidUntil görürseniz bunu not edin, ancak sonucunu tahmin etmeyin.

Para birimi ve URL ilişkisi

Belge, ürünün birden çok para biriminde satıldığı durumlarda para birimi başına ayrı bir URL kullanılmasını ister. Rakip aynı adreste hem TL hem euro fiyat işaretliyorsa tablonuza "para birimi başına URL: yok" yazın. Bu, rakibin kusuru olarak değil, sizin şablonunuzda kontrol edeceğiniz bir madde olarak kayda geçer.

Görsel ve kimlik alanları

image alanı için belge, ürünü açıkça gösteren fotoğrafları tercih ettiğini söyler. En iyi sonuç için birden çok yüksek çözünürlüklü görsel önerilir: genişlik ile yüksekliğin çarpımı en az 50 bin piksel ve 16x9, 4x3, 1x1 oranlarında. Görsel adresleri taranabilir ve dizine eklenebilir olmalı, görsel işaretlenen içeriği temsil etmelidir. Rakip işaretlemesinde tek bir küçük görsel adresi görürseniz bunu "yalnızca bir oran" diye not edin.

Kimlik alanlarında belgenin kuralları nettir. sku için en fazla bir değer verilir ve değer boşluk karakteri içermemelidir, ASCII karakterler önerilir. gtin için sayısal biçim kullanılır, URL biçimi desteklenmez. brand.name için en fazla bir marka adı yazılır. Rakip sayfada sku alanında boşluklu bir değer veya birden çok marka adı varsa bu belgeye uymayan bir örnektir ve şablonunuza taşınmamalıdır.

Örnek senaryo: iki spor ayakkabı sayfası

Örnek senaryo: Koşu ayakkabısı satan A mağazasının ürün sayfasını ve B mağazasının ürün sayfasını karşılaştırıyorsunuz. Değerler kurgusaldır. Karşılaştırma tablosu okuma sonucunu gösterir.

Tablodan çıkan işler şöyledir. availability alanı sizde var, B mağazasında yok: bu bir fark olarak not edilir. gtin ve size alanları sizde yok: önerilen alan olduğu için ürün verinizde bu bilgiler varsa eklemeyi değerlendirirsiniz. B'nin iki marka adı, belgenin "en fazla bir marka adı" kuralına uymaz, bu yüzden taklit edilmez. shippingDetails alanı A'da var, sizde yok: kargo bilgisi sayfada görünüyorsa işaretlemeye eklemek mantıklıdır. Görsel oranlarında B'nin üç oranlı listesi belgedeki öneriyle örtüşür.

Fazla veya görünmeyen alan riski

Google'ın genel yapılandırılmış veri yönergeleri (yeni sekmede açılır), sayfada okuyucuya görünmeyen içeriğin işaretlenmemesini ister. Örnek olarak, JSON-LD bir sanatçıyı anlatıyorsa HTML gövdesi de aynı sanatçıyı anlatmalıdır. Sahte yorum gibi ilgisiz veya yanıltıcı içeriğin işaretlenmesi de yönergelere aykırıdır. Kalite yönergelerinin ihlali, sözdizimi doğru olsa bile zengin sonucun gösterilmesini engelleyebilir; manuel işlem de sayfanın zengin sonuçlar için uygunluğunu kaybetmesine yol açabilir.

Rakip sayfada şu işaretlerden birini görürseniz o alanı "şüpheli" yazın ve şablonunuza almayın:

• İşaretlemedeki fiyat, sayfada görünen fiyattan farklı.
• aggregateRating değeri var, ancak sayfada kullanıcı değerlendirmesi yok.
• Ürün adı ile sayfa başlığı farklı ürünleri anlatıyor.
• Görsel adresi ürünle ilgisiz bir görsele gidiyor.

Bir alanın fazla olup olmadığına karar vermek için belge listesine bakmak yetmez. Belgede yer almayan bir alan da geçerli bir schema.org özelliği olabilir. Yönergeler mümkün olan en belirgin schema.org türünün ve özelliğinin kullanılmasını söyler. Bu nedenle "fazla" etiketini, alan sayfada görünmüyorsa veya sayfa içeriğiyle çelişiyorsa verin.

Sayfa türü uyumu, varyantlar ve JavaScript

Merchant listings belgesi, yalnızca müşterinin ürünü satın alabildiği sayfaların uygun olduğunu söyler. Ürünü satan başka sitelere bağlantı veren sayfalar kapsam dışıdır. Ürün zengin sonuçları tek bir ürüne (veya aynı ürünün varyantlarına) odaklanan sayfaları destekler. Belgedeki örnek, "mağazamızdaki ayakkabılar" gibi bir sayfanın belirli bir ürün olmadığıdır. Her varyantın ayrı bir URL'si varsa varyantlar da kapsam içindedir. Belge, işaretlemeyi kategori ya da liste sayfaları yerine ürün sayfalarına eklemenizi önerir.

Rakip bir kategori sayfasında Product işaretlemesi görürseniz tabloya "sayfa türü uyumsuz" yazın. Aynı kural sizin için de geçerlidir: kategori sayfanıza ürün işaretlemesi koymak yerine ürün sayfalarınızı doğru işaretleyin.

JavaScript ile üretilen işaretleme

Belgeye göre tüm alışveriş sonuç türleri için en iyi sonucu almak isteyen bir satıcı Product yapılandırılmış verisini ilk HTML'e koymalıdır. JavaScript ile oluşturulan işaretleme alışveriş taramalarını daha seyrek ve daha az güvenilir hale getirebilir. Bu, fiyat ve stok gibi hızlı değişen içerik için sorun olabilir. JavaScript kullanıyorsanız sunucunuzun Google'dan gelecek artan trafiği karşılayacak kaynağa sahip olması gerekir. Rakibin işaretlemesi yalnızca işlenmiş HTML'de görünüyorsa bunu tabloya bir satır olarak ekleyin, ancak sonuçlarını varsaymayın.

Merchant Center verisiyle birlikte okumak

Google'ın Product belgesi (yeni sekmede açılır), ürün verisini iki yoldan alabildiğini söyler: web sayfasındaki Product yapılandırılmış verisi ve Merchant Center'a yüklenen beslemeler. İkisini birlikte sağlamak uygunluğu artırır ve Google'ın veriyi doğru anlamasına ve doğrulamasına yardımcı olur. Bazı deneyimler iki kaynaktaki veriyi birleştirir. Örneğin product snippets, sayfadaki işaretlemede fiyat yoksa Merchant Center beslemesindeki fiyat verisini kullanabilir.

Bu yüzden rakip sayfada bir alanın olmaması, rakibin o bilgiyi hiç sağlamadığı anlamına gelmez. Bilgi beslemeden gelebilir ve sizin göremediğiniz bir kaynakta bulunabilir. Tablonuza bu belirsizliği "yok (beslemede olabilir)" notu olarak ekleyin. Kendi beslemenizdeki hatalar için Merchant Center ürün verisi hataları yazısına bakabilirsiniz.

Karar kuralı: bir alan şablonunuza girsin mi

Karşılaştırma bir alan listesi üretir. Her alan için sırayla şu soruları sorun:

1. Alan, hedeflediğiniz deneyim için belgede zorunlu mu? Evetse ve eksikse ekleyin.
2. Önerilen bir alansa, ürün verinizde bu bilgi gerçekten var mı ve sayfada görünüyor mu? İkisi de evetse ekleyin.
3. Bilgi ürün verinizde yok ya da sayfada görünmüyorsa alanı eklemeyin. Alan eklemek için bilgi uydurmayın.
4. Rakipte olup belgede bulunmayan bir alan mı? Schema.org tanımına bakın, sayfada görünür bilgiyi temsil ediyorsa değerlendirin, aksi halde atlayın.

Bu sıralamada rakibin yaptığı bir adım tek başına gerekçe sayılmaz. Gerekçe belge, sayfadaki görünür bilgi ve ürün verinizdir.

Bulguları kendi şablonunuza çevirmek

Tabloyu bir ürün şablonu iş listesine dönüştürmek için şu sırayı izleyin:

1. Önce zorunlu alanları kapatın: name, image, Offer, price, priceCurrency.
2. Sonra Offer içindeki availability ve itemCondition değerlerini tek değere indirin.
3. Marka, sku ve gtin gibi kimlik alanlarını ürün verisinden otomatik üretin, elle yazmayın.
4. Kargo ve iade bilgisini tek bir kaynaktan, örneğin kurumsal işaretlemeden veya Merchant Center ayarlarından yönetin. Belge, genel iade politikanızı Organization işaretlemesi altında vermenizi önerir.
5. Görselleri üç orana göre hazırlayın ve görsel adreslerinin taranabilir olduğunu kontrol edin.
6. Değişikliği yayınlamadan önce Rich Results Test ile kendi sayfanızın kodunu sınayın ve kritik hataları giderin.
7. Yayından sonra Search Console'daki ilgili raporu izleyin.

Fiyat düşüşü gibi bazı geliştirmelerin Google tarafından hesaplandığı ve gösterilmesinin garanti olmadığı belgede yazar. Sonuç tahminini ekip raporuna "uygun hale getirdik" diye yazın, "çıkacak" diye değil. Google belgelerindeki alan listeleri değişebilir. Uygulamadan önce güncel sayfaya bakın.

Kategori, değerlendirme ve varyant alanlarını okumak

Önerilen alanlar arasında rakip şablonları en çok ayıran üç grup vardır: kategori bilgisi, değerlendirmeler ve varyantlar. Üçünün de belgede kendi kuralları bulunur.

category alanı

Belgeye göre category alanı ürünün kategorilerini belirtir ve metin ile CategoryCode nesnelerinin karışık bir dizisini kabul eder. Düz metin değerleri kendi özel ürün türünüzü temsil eder ve belge bu değerlerin 750 karakter sınırının altında tutulmasını önerir. Google ürün kategorisi vermek istiyorsanız CategoryCode türünü, inCodeSet alanında Google Product Taxonomy adresini ve codeValue alanında kategori kimliğini veya tam kategori yolunu kullanırsınız. Yol biçiminde seviyeler arasında büyüktür işareti kullanılır ve her bölümde en az bir harf bulunmalıdır. Rakip sayfada category alanını görürseniz hangi biçimin kullanıldığını yazın: düz metin mi, CategoryCode mu, ikisi birden mi. Spor ayakkabı örneğinde düz metin değeri "Koşu ayakkabısı" olabilir, bu bir özel ürün türüdür.

aggregateRating ve review alanları

Bu iki alan önerilen alanlar arasındadır ve değerlendirme yönergelerine bağlıdır. Belge, bir değerlendirme ekliyorsanız değerlendiren kişinin adının geçerli bir kişi veya ekip adı olması gerektiğini söyler. "Kara Cuma'da yüzde elli indirim" gibi bir metin yazarlık adı olarak önerilmez, "James Smith" ya da "CNET Reviewers" gibi bir ad önerilir. Genel yönergeler ise sahte değerlendirmeleri açıkça yönergelere aykırı sayar. Rakip sayfada aggregateRating varsa, aynı sayfada kullanıcı değerlendirmelerinin görünüp görünmediğine bakın. Görünmüyorsa tabloya "şüpheli" yazın.

Varyant URL'leri ve renk ya da beden alanları

Belge, Google'ın hangi ürünlerin aynı ana ürünün varyantı olduğunu anlamasına yardım eden ayrı bir varyant yapılandırılmış verisi sunar ve hem product snippets hem merchant listings varyantları destekler. Her varyantın ayrı bir URL'si olması da merchant listings kapsamında anılır. Rakip, ayakkabının her rengi için ayrı URL kullanıyorsa ve her sayfada o rengin color değeri varsa bunu tabloya "varyant başına URL, varyanta özgü color" diye yazın. Tüm renkler tek sayfada ve tek color alanında virgüllerle sıralanmışsa farklı bir yapı vardır. Kendi şablonunuzda hangi modeli seçtiğinizi bilinçli yapmanız gerekir.

Rakip seçimi ve örneklem

Tablodaki sütunların sayısı kadar önemli olan, hangi rakiplerin seçildiğidir. Arama sonuçlarında aynı sorguyla yan yana görünen satıcılar, aynı ürünü farklı şablonla sunan pazaryerleri ve doğrudan marka siteleri farklı yapıda olabilir. Ürün işaretlemesi karşılaştırmasında üç grup ayırmak işe yarar:

• Aynı ürünü satan doğrudan rakipler: aynı model için Offer yapısını karşılaştırırsınız.
• Aynı kategoride farklı model satan mağazalar: şablon genel yapısını, kimlik alanlarını ve görsel kurallarını karşılaştırırsınız.
• Pazaryeri ilan sayfaları: satıcı bilgisi ve fiyat yapısını karşılaştırırsınız.

Uygulama önerisi: her gruptan birer rakip alın ve her rakipte farklı kategorilerden iki ürün sayfası okuyun. Her sayfa için URL, okuma tarihi, işaretleme biçimi ve sayfa türünü tabloya ekleyin. Tarih kaydı önemlidir, çünkü rakip sayfalar değişir ve iki ay sonra tabloya baktığınızda hangi sürümü okuduğunuzu bilmeniz gerekir.

Örneklem notu

Tek bir ürün sayfası şablonun tamamını temsil etmeyebilir. İndirimli, stokta olmayan ve çok renkli ürün sayfaları farklı alanlar üretebilir. Örnek senaryo: Bir marka sitesinde stokta olmayan bir ayakkabı sayfasında availability alanında OutOfStock değerini görürsünüz. Aynı rakibin stokta olan sayfasında InStock görürsünüz. İki sayfa aynı şablonun iki durumunu gösterir. Siz de kendi şablonunuzu bu iki durumda sınamalısınız.

Okuma kaydında tutulacak alanlar

Her okuma için ortak bir kayıt biçimi kullanmak, aylar sonra tabloyu karşılaştırılabilir kılar. Kayıt satırında şu bilgiler bulunabilir:

• Sayfa adresi ve okuma tarihi.
• Sayfa türü: satın alınabilir ürün, inceleme, kategori veya liste.
• İşaretleme biçimi ve işaretlemenin ilk HTML'de mi, işlenmiş HTML'de mi görüldüğü.
• Zorunlu alanların durumu ve Offer içindeki değerler.
• Sayfadaki görünür fiyat, stok ve görsel ile işaretleme arasındaki uyum notu.
• Şüpheli bulunan alanlar ve gerekçesi.

Bu kayıt, kendi ekibinizin içinde paylaşılan bir çalışma belgesidir. Rakip sayfanın metnini veya görsellerini kopyalayıp saklamaya gerek yoktur. Yalnızca alan adlarını ve durum bilgisini tutmak, hem kopyalama riskini ortadan kaldırır hem de tabloyu kısa tutar.

Tablodan iş listesine: bulguları sıralamak

Karşılaştırma bittiğinde elinizde onlarca satır olabilir. Hepsini aynı anda yapmak gerekmez. Belgedeki zorunlu ve önerilen ayrımı sıralama için ilk ölçüttür. Tablo, bir öncelik çerçevesi önerir.

Bu çerçeve Google'dan gelen bir sıralama değil, uygulama önerisidir. Önemli olan, her satırın bir belge dayanağı ve bir sahibi olmasıdır. Zorunlu alan eksikleri şablon geliştiricisine, ürün verisi eksikleri katalog ekibine, görsel oranları görsel hazırlık ekibine verilebilir.

Örnek senaryo: spor ayakkabı şablonu için iş listesi

Örnek senaryo: Karşılaştırma tablosunda sizin şablonunuzda gtin, size ve shippingDetails alanlarının eksik olduğunu gördünüz. Katalog ekibi ayakkabıların barkod numaralarını ürün veritabanında tutuyor, beden bilgisi her varyantın ayrı kaydında duruyor. Kargo bilgisi sitenin kargo sayfasında yazılı ve ürün sayfasında kısa bir not olarak görünüyor.

Tablodaki son satır, karar kuralının üçüncü adımını gösterir. Rakiplerden birinde aggregateRating bulunması sizin için gerekçe değildir, çünkü sayfanızda eşleşen görünür değerlendirme yok. Bilgi olmadan alan eklemek hem yönergelere aykırıdır hem de ürün verinizi yanlış anlatır.

Bu işleri sırayla yapmak, her değişiklikten sonra kendi sayfanızı Rich Results Test ile sınamayı ve ardından Search Console raporlarında uyarı çıkıp çıkmadığına bakmayı mümkün kılar. Hepsini tek yayında birleştirirseniz bir hata çıktığında kaynağını bulmak zorlaşır.

Sahiplik ve yeniden kontrol

Her iş kalemine bir sahip ve bir yeniden kontrol tarihi yazın. Yeniden kontrol, kendi sayfanızın işaretlemesini Rich Results Test ile sınamak ve Search Console raporlarını izlemek demektir. Rakip tablosunu ise şablon değiştirdikten sonra yeniden okumanız gerekmez, ancak rakip büyük bir tasarım değişikliği yaptığında yeni bir okuma yapılabilir.

Okuma öncesi ve sonrası kontrol listesi

• Rakip sayfa herkese açık ve giriş gerektirmeyen bir sayfa.
• İşaretleme biçimi belirlendi: JSON-LD, Microdata veya RDFa.
• Sayfa kaynağı ile işlenmiş HTML karşılaştırıldı.
• Zorunlu alanlar tabloya işlendi.
• Offer içindeki price, priceCurrency, availability ve itemCondition okundu.
• Marka, sku, gtin ve görsel kuralları belgeyle karşılaştırıldı.
• Görünür metinle çelişen alanlar "şüpheli" olarak işaretlendi.
• Sayfa türü ve varyant URL'leri not edildi.
• Karar kuralı her alan için uygulandı.
• Tablonun tarihi kaydedildi, çünkü rakip sayfa değişebilir.

Dikkat edilecek hatalar

Rakibin değerlerini kopyalamak

Rakibin işaretlemesini olduğu gibi kendi şablonunuza yapıştırmak, ürününüzü yanlış anlatabilir ve yönergelere aykırı içerik üretir. Tablonuz bir alan listesi çıkarır, değer listesi değil.

Eksik alanı rakibin avantajı saymak

Alanın bulunmaması bir avantaj ya da dezavantaj kanıtı değildir. Rakip alanı besleme yoluyla sağlıyor olabilir.

Tek örnekle sonuç çıkarmak

Bir rakibin tek bir ürün sayfası şablonun tamamını temsil etmeyebilir. Aynı rakipten farklı kategorilerde en az iki ürün sayfası okuyun.

Sayfa türünü karıştırmak

Satın alma imkânı olmayan bir inceleme sayfasıyla satış sayfasını aynı tabloda değerlendirmek, zorunlu alanları yanlış okumanıza yol açar. Önce iki sınıfı ayırın.

Hizmet şartlarını gözden kaçırmak

Sayfayı elle ve tek tek açmak herkese açık bir okumadır. Otomatik toplu çekim, rakip sitenin kullanım şartlarına aykırı olabilir. Bu nedenle çalışmayı elle yürütün.

Karar kuralı: Bir alan farkı yalnızca kendi ürün verinizde gerçekten bulunan bilgiyi gösteriyorsa işe dönüşür. Elinizde olmayan bilgiyi işaretlemeye eklemek, sayfadaki içerikle uyuşmayan bir şema üretir.

Sık Sorulan Sorular

Rakibin ürün işaretlemesini nasıl görüntülerim?

Herkese açık ürün sayfasının kaynağını açıp application/ld+json türündeki script bloklarını arayabilirsiniz. İşaretleme sayfa yüklendikten sonra betikle ekleniyorsa geliştirici araçlarında işlenmiş HTML'e bakmanız gerekir.

Merchant listings için hangi alanlar zorunludur?

Google'ın merchant listing belgesine göre Product için name, image ve offers zorunludur. offers alanı iç içe bir Offer olmalı, Offer içinde de price ile priceCurrency verilmelidir.

Rakipte olmayan bir alanı ben de eklemeyebilir miyim?

Zorunlu alanlar hariç, önerilen alanı eklemek ürün verinize ve sayfadaki görünür bilgiye bağlıdır. Rakipte alanın olmaması onun avantajı ya da dezavantajı olduğunu göstermez.

Rakip kategori sayfasında Product işaretlemesi görürsem ne yapmalıyım?

Google belgesi ürün zengin sonuçlarının tek ürüne odaklanan sayfaları desteklediğini ve işaretlemenin kategori sayfaları yerine ürün sayfalarına eklenmesini önerdiğini söyler. Tabloya sayfa türü uyumsuzluğu olarak yazın.

Rich Results Test'i rakip sayfada kullanmalı mıyım?

Belge aracı kendi kodunuzu doğrulamak için anar. Rakip incelemesini tarayıcı yöntemiyle yapıp aracı kendi şablonunuz için kullanabilirsiniz.

İşaretleme eklersem zengin sonuç garanti mi?

Hayır. Google, yapılandırılmış veriye bağlı özelliklerin sonuçlarda görüneceğini garanti etmez. Fiyat düşüşü gibi bazı geliştirmeler Google tarafından hesaplanır ve gösterimi garanti edilmez.

Sonuç

Rakip ürün sayfasının yapılandırılmış verisini okumak dört adımlık bir iştir: işaretlemeyi herkese açık sayfadan görüntüleyin, alanları belgedeki zorunlu ve önerilen listelerle eşleştirin, görünür metinle çelişen veya belgeye uymayan alanları işaretleyin, bulguları karar kuralıyla kendi şablonunuza çevirin. Rakibin alanları örnek değil, karşılaştırma ölçüsüdür. Karar belgede ve sayfanızda görünen bilgidedir.

Ürün sayfalarınızı hazırladıktan sonra sayfalarınızın bağlantı profilini de güçlendirebilirsiniz. Seçenekleri görmek için backlink paketlerini inceleyin. Kendi Product şemanızı kurmak için ürün schema işaretlemesi rehberine bakın.