Merchant Center politikaları Eylül 2026'da değişiyor mu? Evet, Google Alışveriş reklamları ve ücretsiz listeleme politikalarını tek bir politika kümesinde birleştireceğini açıkladı.
Bu değişiklik, satıcıların ürün reddi, hesap uygunluğu ve politika ihlali bildirimlerini değerlendirme biçimini etkileyebilir. Ancak her ürünün otomatik olarak reddedileceği anlamına gelmez.
Asıl değişiklik, iki ayrı politika çerçevesinin tek bir yapı altında toplanmasıdır. Satıcıların ürün verisini, web sitesini ve hesap ayarlarını birlikte kontrol etmesi gerekecektir.
Google Merchant Center politikaları Eylül 2026'da neden birleşiyor?
Google, Eylül 2026'da Alışveriş reklamları ile ücretsiz listeleme politikalarını tek politika kümesinde birleştirecek.
Bugüne kadar reklam gösterimi ve ücretsiz ürün listelemeleri için benzer konuları açıklayan, ancak ayrı bağlamlarda kullanılan politika metinleri bulunuyordu. Bu yapı, aynı ürünün farklı yüzeylerde farklı değerlendirilmesine yol açabiliyordu.
Birleşik politika yaklaşımı, ürünün Google'da nerede gösterildiğinden bağımsız ortak kurallar oluşturmayı amaçlıyor. Ürün reklamda, ücretsiz listede veya her iki kanalda görünse de temel uygunluk kriterleri aynı çerçevede değerlendirilecek.
Bu değişiklik yeni bir ürün kategorisinin otomatik olarak yasaklanması demek değildir. Değişikliğin merkezinde, politika metinlerinin ve uygulama mantığının sadeleştirilmesi bulunuyor.
Satıcı açısından önemli nokta, yalnızca Merchant Center arayüzündeki uyarıyı izlememektir. Ürün başlığı, açıklaması, görseli, fiyatı, stok bilgisi, ödeme adımı ve iade koşulları birlikte incelenmelidir.
Google'ın politika değişiklikleriyle ilgili ayrıntılı açıklamaları için Google Merchant Center politikaları Eylül 2026'da ne değiştiriyor? başlıklı içeriğe de bakabilirsiniz.
Birleşik politika seti hangi alanları kapsayacak?
Birleşik politika seti, ürün uygunluğu ile mağaza ve hesap uygunluğunu aynı değerlendirme çerçevesinde ele alacak.
Ürün uygunluğu; ürünün yasaklı veya kısıtlı bir kategoride olup olmadığını, ürün verisinin doğru aktarılıp aktarılmadığını ve kullanıcıya sunulan bilgilerin tutarlı olup olmadığını kapsar.
Mağaza uygunluğu ise web sitesindeki ödeme sürecini, iletişim bilgilerini, teslimat açıklamalarını, iade politikasını ve ürün sayfalarının erişilebilirliğini içerir.
Hesap uygunluğu daha geniş bir seviyededir. Tek bir ürün yerine, satıcının tekrarlanan ihlalleri, yanlış yönlendiren beyanları veya temel işletme bilgilerindeki tutarsızlıklar değerlendirmeye alınabilir.
| Değerlendirme alanı | Kontrol edilen unsur | Olası sonuç |
|---|---|---|
| Ürün verisi | Başlık, fiyat, stok, açıklama ve görsel | Ürün reddi veya görünürlüğün sınırlanması |
| Web sitesi | Ödeme, teslimat, iade ve iletişim bilgileri | Mağaza uygunluğu sorunu |
| Hesap davranışı | Tekrarlanan ihlaller ve yanlış beyanlar | Hesap incelemesi veya askıya alma |
| Ürün kategorisi | Yasaklı ya da kısıtlı ürün kuralları | Kanala özel veya genel kısıtlama |
Bu alanlar birbirinden bağımsız değildir. Örneğin fiyat feed'de doğru görünse bile ödeme sayfasında farklı bir fiyat çıkıyorsa sorun yalnızca ürün verisi olarak değerlendirilmeyebilir.
Bu nedenle Eylül 2026 hazırlığı, yalnızca yeni politika metnini okumaktan oluşmaz. Ürün kaynağı ile web sitesinin aynı bilgiyi sunduğunu kanıtlamak gerekir.
Ürün reddi Eylül 2026 değişikliğinden nasıl etkilenebilir?
Ürün reddi, birleşik politika yaklaşımında ürün verisi ile açılış sayfası arasındaki tutarsızlıklar nedeniyle daha görünür hale gelebilir.
Bir ürünün reddedilmesi için başlığında açıkça yasaklı bir ifade bulunması gerekmez. Yanlış fiyat, eksik stok bilgisi, erişilemeyen ürün sayfası veya belirsiz teslimat koşulu da inceleme nedeni olabilir.
Örneğin feed'de “stokta” görünen bir ürün, ürün sayfasında “tükendi” olarak görünüyorsa Google iki kaynak arasında çelişki tespit edebilir. Aynı durum indirimli fiyat, para birimi ve varyant bilgilerinde de yaşanabilir.
Yanlış: Ürün reddedildiyse yalnızca başlığı değiştirip yeniden göndermek.
Doğru: Reddin ürün verisinden mi, açılış sayfasından mı veya kategori politikasından kaynaklandığını ayırarak düzeltmek.
Reddin kaynağını belirlemek için önce Merchant Center'daki sorun açıklamasını kaydedin. Ardından ürün kimliğini, feed kaynağını, son tarama tarihini ve açılış sayfasındaki gerçek bilgileri karşılaştırın.
Başlık değişikliği, yalnızca başlıkta politika ihlali varsa işe yarar. Asıl sorun ödeme adımındaki fiyat farkıysa başlığı değiştirmek sonucu düzeltmez.
Benzer şekilde, görseli değiştirmek ürün kategorisinin yasaklı olması durumunda çözüm sağlamaz. Her düzeltme, Merchant Center'ın bildirdiği ihlal türüyle doğrudan ilişkili olmalıdır.
Geçmişteki reddedilen ürünleri incelemek için Merchant Center geçmiş raporu nasıl indirilir? rehberindeki dışa aktarma adımlarını kullanabilirsiniz.
Hesap uygunluğu ürün reddinden nasıl farklıdır?
Hesap uygunluğu, tek bir ürünün değil, satıcının Merchant Center hesabındaki genel güvenilirliğin değerlendirilmesidir.
Ürün reddi çoğunlukla belirli bir ürün kimliği ve belirli bir ihlal mesajıyla ilişkilidir. Hesap uygunluğu sorunu ise birden fazla ürünü, ürün kaynağını veya mağazanın tamamını etkileyebilir.
Örneğin beş üründe farklı fiyat hataları görülmesi, tek tek ürün sorunlarından daha geniş bir veri kalitesi problemine işaret edebilir. Ürünlerin tamamında aynı yanlış işletme bilgisi bulunması da benzer bir risk oluşturur.
Hesap uygunluğu kontrollerinde işletme adı, alan adı, iletişim bilgileri, ödeme yöntemi, gönderim süresi ve iade şartları gibi unsurlar önem taşır. Bu bilgilerin birbirini desteklemesi gerekir.
Web sitesinde şirket bilgileri bir yerde “A Ltd.”, başka bir yerde “A Ticaret” olarak geçiyorsa kullanıcı açısından belirsizlik oluşabilir. Aynı belirsizlik, Google'ın işletme bilgisi kontrollerinde de sorun yaratabilir.
Hesap uygunluğu problemi görüldüğünde yeni ürün yüklemek veya mevcut ürünleri yeniden göndermek genellikle ilk adım olmamalıdır. Önce hesabın tamamındaki ortak hata aranmalıdır.
Merchant Center raporlarında yapılan değişiklikleri anlamak için Merchant Center raporu neden değişti? içeriğindeki rapor türü ve kapsam ayrımlarından yararlanabilirsiniz.
Hesabın askıya alınması gibi ağır sonuçlarda itiraz göndermeden önce düzeltme kayıtlarını hazırlayın. Hangi sayfayı, hangi ürün kaynağını ve hangi ayarı değiştirdiğinizi tarih sırasıyla yazın.
Satıcılar Eylül 2026'dan önce hangi kontrolleri yapmalı?
Satıcılar, Eylül 2026'dan önce ürün verisi, web sitesi ve hesap ayarlarını birlikte denetlemelidir.
İlk kontrol, ürün feed'indeki fiyat ve stok bilgisinin web sitesindeki değerlerle eşleşmesidir. Bu karşılaştırmayı yalnızca birkaç popüler üründe değil, farklı kategorilerden seçilmiş örneklerde yapın.
İkinci kontrol, ürün sayfalarının mobil cihazlarda açılmasıdır. Sayfa açılmıyor, varyant seçilemiyor veya ödeme adımına geçilemiyorsa ürün verisi doğru olsa bile kullanıcı deneyimi sorunu oluşur.
Üçüncü kontrol, teslimat ve iade bilgilerinin açık biçimde yayınlanmasıdır. “Kısa sürede gönderilir” gibi belirsiz ifadeler yerine, mümkün olan yerlerde işleme ve teslimat sürelerini ayrı açıklayın.
- Ürün fiyatı, feed ve ödeme sayfasında aynı mı?
- Stok durumu ürün sayfasında ve feed'de eşleşiyor mu?
- Ürün varyantlarının renk, beden ve stok bilgileri doğru mu?
- İade koşulları, teslimat bilgileri ve iletişim sayfası erişilebilir mi?
- İşletme adı ve iletişim bilgileri sitede tutarlı mı?
- Yasaklı veya kısıtlı kategoriler için Google kuralları ayrıca incelendi mi?
Bu liste tek seferlik bir temizlik için kullanılabilir. Ancak stok ve fiyat değişen mağazalarda aynı kontrollerin planlı olarak tekrarlanması gerekir.
Kontrol sıklığını belirlerken sipariş hacmini, ürün sayısını ve veri güncelleme hızını dikkate alın. Günde sık fiyat değişen mağazanın aylık manuel kontrolle yetinmesi riskli olabilir.
T-Soft kullanan mağazalarda bağlantı ve veri aktarımı için T-Soft'ta Google Merchant Center nasıl bağlanır? rehberindeki temel kurulum adımlarını kontrol edebilirsiniz.
Ürün feed'i ve web sitesi arasındaki tutarlılık nasıl ölçülür?
Feed ve web sitesi tutarlılığı, aynı ürün kimliği üzerinden alan alan karşılaştırma yapılarak ölçülür.
Önce ürün kimliğini sabitleyin. Ardından başlık, marka, GTIN, fiyat, indirimli fiyat, stok, kargo ve açılış URL'si gibi alanları tabloya aktarın.
Her alan için feed değeri, web sitesi değeri ve kontrol tarihi ayrı sütunlarda yer almalıdır. Böylece sorun yalnızca fark edildiğinde değil, hangi kaynakta başladığında da görülebilir.
Örnek olarak 100 ürün seçtiğinizi düşünün. Bu örneklemde 7 ürünün fiyatı farklıysa tutarsızlık oranı yüzde 7'dir. Bu oran Google'ın resmi bir eşik değeri değildir; yalnızca işletme içi risk takibi için kullanılır.
Burada amaç Google'ın açıklamadığı bir sınırı tahmin etmek değildir. Amaç, değişikliklerden sonra veri kalitesinin iyileşip iyileşmediğini kendi kayıtlarınızla izlemektir.
- Merchant Center'dan ürün kimliklerini ve güncel sorunları dışa aktarın.
- Aynı ürünlerin web sitesi fiyat, stok ve varyant bilgilerini alın.
- Farklılıkları ürün kimliği bazında sınıflandırın.
- Feed kaynağı, önbellek, entegrasyon veya site veritabanı sorununu belirleyin.
- Düzeltmeden sonra yeniden tarama ve ürün durumunu kontrol edin.
Bu süreçte yalnızca reddedilen ürünleri incelemek eksik sonuç verir. Onaylı ürünlerden de örneklem seçmek, henüz uyarı üretmemiş veri hatalarını görmenizi sağlar.
Performans raporundaki değişimler için Merchant Center performans raporu neden değişti? açıklamasını da inceleyebilirsiniz. Trafik düşüşü her zaman politika ihlali anlamına gelmez.
Platform entegrasyonu Eylül 2026 değişikliğinde neden önem kazanıyor?
Platform entegrasyonu, ürün bilgilerinin Merchant Center'a hangi sıklıkta ve hangi alanlarla aktarıldığını belirlediği için önem kazanıyor.
Bir e-ticaret platformu fiyatı anlık güncellerken Merchant Center feed'i gecikmeli çalışıyorsa iki kaynak arasında geçici fark oluşabilir. Bu farkın süresi, ürün sayısı ve güncelleme düzenine göre değişir.
Entegrasyon kontrolünde bağlantının kurulmuş olması yeterli değildir. Feed'in son başarılı çalıştırma zamanı, hata kayıtları, gönderilen alanlar ve güncelleme sıklığı da incelenmelidir.
Özellikle varyantlı ürünlerde ana ürün ile alt ürünlerin eşleşmesi önemlidir. Beden veya renk seçimi sonrasında fiyat değişiyor, fakat feed yalnızca ana ürünü gönderiyorsa yanlış eşleşme oluşabilir.
Bu sorunlarda platformu değiştirmek her zaman gerekli değildir. Önce hangi alanın aktarılmadığını ve hatanın platformda mı, ürün veri kaynağında mı olduğunu ayırmak gerekir.
İkas ve T-Soft arasında seçim yapan mağazalar için İkas mı T-Soft mu? E-Ticaret Platform Karşılaştırması (2026) içeriğindeki entegrasyon, veri yönetimi ve işletme ihtiyaçları karşılaştırması yol gösterici olabilir.
Entegrasyon testinde üç ürün grubu seçin: basit ürünler, varyantlı ürünler ve indirimli ürünler. Her grupta feed ile site değerlerini aynı gün karşılaştırın.
Sonuçları kayıt altına almak, Eylül 2026 sonrasında görülen değişimin politika kaynaklı mı yoksa teknik kaynaklı mı olduğunu ayırmayı kolaylaştırır.
Eylül 2026 sonrasında politika sorunları nasıl izlenmeli?
Eylül 2026 sonrasında politika sorunları, ürün durumu, hesap bildirimleri ve veri değişiklikleri birlikte izlenerek yönetilmelidir.
Öncelikle değişiklikten önce bir referans kaydı oluşturun. Ürün sayısı, reddedilen ürün sayısı, en sık görülen hata türleri ve önemli ürün gruplarının görünürlüğü bu kayıtta yer alabilir.
Bu kayıt, Google'ın resmi bir performans garantisi veya politika eşiği değildir. Yalnızca mağazanızdaki değişimi karşılaştırmalı olarak görmenizi sağlayan bir başlangıç noktasıdır.
Değişiklik sonrasında ani düşüş gördüğünüzde önce tarihleri karşılaştırın. Aynı dönemde kampanya bütçesi, stok, fiyat, sezon talebi veya site erişiminde değişiklik olduysa yalnızca politika sonucuna odaklanmayın.
Ürün reddi sayısı artmışsa hata türlerini gruplayın. Fiyat tutarsızlığı, eksik kargo bilgisi ve kısıtlı ürün uyarısı farklı çözüm yolları gerektirir.
Hesap uygunluğu uyarısı varsa tek bir ürün üzerinde çalışmak yerine ortak işletme bilgilerini inceleyin. Alan adı, şirket adı, ödeme ve iade sayfaları ilk kontrol noktalarıdır.
Her düzeltme sonrası ekran görüntüsü, dışa aktarılan rapor ve değişiklik tarihini saklayın. İtiraz gerektiğinde yalnızca “sorunu düzelttik” demek yerine yapılan işlemi gösterebilirsiniz.
Rapor metrikleri değiştiğinde, eski ve yeni raporların aynı kapsamı ölçtüğünü doğrulayın. Rapor kapsamı farklıysa doğrudan yüzde değişimi yorumlamak yanıltıcı olabilir.
Merchant Center politika değişikliği için nasıl bir hazırlık planı yapılmalı?
Hazırlık planı, önce mevcut riskleri ölçüp sonra ürün, site ve hesap düzeltmelerini önceliklendirecek şekilde yapılmalıdır.
İlk hafta mevcut sorunları listeleyin. Son 30 günlük ürün reddi bildirimlerini, hesap uyarılarını ve feed hata kayıtlarını aynı tabloda toplayın.
İkinci aşamada sorunları etkisine göre sıralayın. Mağazanın tamamını etkileyebilecek işletme bilgisi ve ödeme sorunları, tek ürünle sınırlı başlık sorunlarından önce ele alınmalıdır.
Üçüncü aşamada örneklem denetimi yapın. En çok satan ürünleri, yeni eklenen ürünleri, indirimli ürünleri ve varyantlı ürünleri ayrı gruplar halinde kontrol edin.
Dördüncü aşamada entegrasyon kayıtlarını inceleyin. Feed'in son güncelleme zamanını, başarısız aktarımları ve ürün alanlarının eksik gönderilip gönderilmediğini kontrol edin.
Son aşamada değişiklik sonrası izleme sorumluluğunu belirleyin. Kim ürün reddini kontrol edecek, kim site bilgilerini güncelleyecek, kim itiraz dosyasını hazırlayacak soruları önceden yanıtlayın.
Bu planın işe yaramadığı durum, mağazanın tüm sorunlarını yalnızca politika metni değişikliğine bağlamasıdır. Stok tükenmesi, fiyat artışı veya sezon etkisi de görünürlüğü değiştirebilir.
Bu nedenle Eylül 2026 karşılaştırması, politika uyarılarıyla ticari ve teknik verileri birlikte değerlendirmelidir. Tek bir metrik, değişikliğin tamamını açıklamaz.
Satıcılar Eylül 2026 değişikliğini nasıl değerlendirmeli?
Satıcılar bu değişikliği, yeni bir panik nedeni olarak değil, ürün ve hesap uygunluğunu birlikte denetleme gereği olarak değerlendirmeli.
Google'ın açıkladığı temel konu, Alışveriş reklamları ve ücretsiz listeleme politikalarının tek politika kümesinde birleşmesidir. Bu açıklama, her satıcı için aynı ürün reddi sonucunun doğacağını göstermez.
En önemli hazırlık, feed ile web sitesindeki bilgileri eşleştirmektir. Fiyat, stok, varyant, teslimat, iade ve işletme bilgileri farklı kaynaklarda aynı görünmelidir.
İkinci öncelik, ürün reddi ile hesap uygunluğu sorununu ayırmaktır. Ürün bazlı uyarılar ürün verisiyle; hesap bazlı uyarılar ise mağazanın genel yapısıyla birlikte incelenmelidir.
Üçüncü öncelik, değişiklik öncesi ve sonrası kayıt tutmaktır. Ürün durumları, hata türleri ve feed güncellemeleri tarihleriyle kaydedilirse gerçek değişim daha doğru ölçülür.
Merchant Center'da yaşanan sorunları başka kanallardaki satış ve reklam verileriyle karşılaştırmak da gerekir. Örneğin kendi sitenizdeki dönüşüm değişimini analiz ederken Trendyol'da Satış mı, Kendi Siteniz mi? karşılaştırmasındaki birim ekonomi yaklaşımı kullanılabilir.
Sonuç olarak Eylül 2026 için yapılacak en somut iş, politika metnini beklemek değil, mevcut veri akışını ve mağaza bilgilerini bugünden denetlemektir.
Merchant Center politika değişikliğinin mağazanızdaki ürün reddi ve hesap uygunluğuna etkisini veriler üzerinden incelemek istiyorsanız Medyografya ekibiyle iletişime geçebilirsiniz.
İlgili Yazılar
Sık Sorulan Sorular
Merchant Center politikaları Eylül 2026'da değişiyor mu?
Evet. Google, Alışveriş reklamları ve ücretsiz listeleme politikalarını Eylül 2026'da tek politika kümesinde birleştireceğini açıkladı.
Birleşik politikalar tüm ürünlerin yeniden reddedileceği anlamına mı geliyor?
Hayır. Değişiklik, politika yapısının birleşmesi anlamına gelir. Ürün reddi; ürün verisi, web sitesi, kategori ve hesap uygunluğu kontrollerine bağlıdır.
Ürün reddi ile hesap uygunluğu arasındaki fark nedir?
Ürün reddi genellikle belirli bir ürün veya ürün verisiyle ilgilidir. Hesap uygunluğu ise tekrarlanan ihlaller, mağaza bilgileri ve genel işletme güvenilirliğiyle ilgilidir.
Satıcılar Eylül 2026'dan önce neyi kontrol etmeli?
Feed ve web sitesi fiyatlarını, stokları, varyantları, teslimat ve iade bilgilerini, iletişim sayfalarını ve işletme bilgilerinin tutarlılığını kontrol etmelidir.
Politika değişikliğinin etkisi nasıl ölçülür?
Değişiklik öncesi ürün reddi, hata türleri ve hesap bildirimleri kaydedilmeli; sonrasında aynı metrikler tarih ve kapsam karşılaştırmasıyla izlenmelidir.