Merchant Center politikaları birleşince ne değişecek?

Merchant Center politikaları Eylül 2026’da nasıl birleşecek?

Merchant Center politikaları Eylül 2026’da birleşince, Alışveriş reklamları ve ücretsiz listelemeler aynı politika kümesi içinde değerlendirilecek.

Bugün mağazalar, reklam gösterimi ile ücretsiz ürün görünürlüğünü ayrı politika başlıkları üzerinden takip edebiliyor. Birleşmeyle birlikte ürün, mağaza ve teklif kontrolleri daha ortak bir çerçevede okunacak.

Bu değişiklik, her ürünün yeniden otomatik olarak reddedileceği anlamına gelmez. Asıl değişiklik, aynı ürün bilgisinin iki farklı yayınlama alanında farklı yorumlanması ihtimalinin azalmasıdır.

Örneğin bir ürün reklam kampanyasında uygun görünürken ücretsiz listelemelerde farklı bir uyarı alıyorsa, politika kümesi sonrasında kontrol mantığı daha yakın çalışabilir. Ancak Google’ın uygulama ekranında göstereceği hata türleri belirleyici olacaktır.

Mağaza sahibi açısından ilk sonuç, politika takibinin tek raporlama mantığına yaklaşmasıdır. Ürün durumu, mağaza bilgileri, ödeme koşulları, gönderim ve iade açıklamaları birlikte kontrol edilmelidir.

Değişiklik yalnızca reklam hesabını yöneten kişileri ilgilendirmez. Ürün feed’ini hazırlayan ekip, e-ticaret platformunu yöneten kişi ve müşteri hizmetleri sorumlusu da aynı verileri kullanır.

Bu nedenle Eylül 2026’ya kadar yapılacak iş, yalnızca reklam kampanyalarını incelemek değildir. Mağazanın web sitesindeki bilgilerle Merchant Center’daki ürün ve işletme verileri karşılaştırılmalıdır.

Politika birleşmesinin teknik etkisi, mevcut hesapta hangi kaynakların ürün uygunluğunu belirlediğini anlamayı gerektirir. Feed, web sitesi, ödeme sayfası ve işletme bilgileri birlikte değerlendirilmelidir.

Mevcut ürün onayları Eylül 2026’da otomatik olarak iptal edilir mi?

Mevcut ürün onayları, politika kümelerinin birleşmesi nedeniyle kendiliğinden iptal edilmiş sayılmaz; yine de ürünlerin güncel kurallara göre yeniden değerlendirilebilmesi mümkündür.

Buradaki ayrım önemlidir. Politika yapısının değişmesi başka, ürün verisinin politika ihlali oluşturması başkadır. Bir ürünün daha önce onaylanmış olması, sonraki kontrollerde aynı sonucu alacağını garanti etmez.

Örneğin ürün sayfasında teslimat süresi değiştiyse, Merchant Center’daki gönderim ayarı eski kalabilir. Ürün daha önce onaylanmış olsa bile bu uyumsuzluk yeni kontrol sırasında görünür hale gelebilir.

Onay durumunu değerlendirirken tarih yerine mevcut duruma bakın. Ürün teşhis ekranındaki etkin, beklemede, reddedildi veya sınırlı görünürlük gibi durumları ürün gruplarına göre dışa aktarın.

Özellikle çok sayıda ürünü olan mağazalar, tek tek kontrol yerine hata türlerini sınıflandırmalıdır. Marka, kategori, ülke, feed kaynağı ve hata nedeni ayrı sütunlarda tutulabilir.

Yanlış: “Ürün geçen yıl onaylandı, artık kontrol etmeye gerek yok.” Doğru: “Ürünün güncel verisini, web sitesiyle ve politika bildirimleriyle düzenli olarak karşılaştırıyorum.”

Mevcut onayları korumanın en güvenilir yöntemi, ürün sayfası ile feed arasındaki tutarlılığı ölçmektir. Ürün adı, fiyat, stok, görsel, varyant, gönderim ve iade bilgileri aynı olmalıdır.

Değişiklik sonrasında bir ürün reddedilirse, önce politika başlığını ve örneklenen URL’yi kaydedin. Sonra sorunun feed’de mi, web sitesinde mi, hesap ayarında mı olduğunu ayırın.

Bu süreçte Merchant Center politikaları Eylül 2026’da değişiyor mu? sayfasındaki genel değişiklik çerçevesi de karşılaştırma için kullanılabilir.

Reklamlar ve ücretsiz listelemeler için hangi bilgiler birlikte kontrol edilecek?

Birleşme sonrasında ürün verisi, mağaza güven sinyalleri ve ticari koşullar birlikte kontrol edilecek; bu nedenle yalnızca ürün başlığına odaklanmak yeterli olmayacak.

Ürün düzeyinde başlık, açıklama, fiyat, stok durumu, marka, GTIN, görsel ve bağlantı incelenmelidir. Bu alanlardan biri web sitesindeki gerçek bilgiyle çelişirse, görünürlük etkilenebilir.

Teknik bağlantılar da önemlidir. Ürün URL’si çalışmıyorsa, yönlendirme yanlışsa veya sayfadaki varyant seçimi feed’deki ürünle eşleşmiyorsa sorun yalnızca reklam tarafında oluşmaz.

Mağaza düzeyinde işletme adı, iletişim bilgileri, ödeme yöntemi, gönderim seçenekleri ve iade koşulları gözden geçirilmelidir. Bu bilgilerin sitede kolay bulunması, yalnızca tasarım tercihi değildir.

Teklif düzeyinde ise fiyatın hangi para biriminde gösterildiği, indirim bilgisinin nasıl sunulduğu ve stok durumunun ne sıklıkta güncellendiği kontrol edilmelidir.

Örneğin feed’de 899 TL görünen ürün, ürün sayfasında 999 TL ise iki yayın alanının birlikte değerlendirilmesi sorun yaratabilir. Bu fark kampanya parametresinden değil, temel veri uyumsuzluğundan kaynaklanabilir.

Ücretsiz listelemeler için veri doğruluğu önemsiz değildir. Reklam bütçesi kullanılmaması, politika ve ürün bilgisi kontrollerinin devre dışı kaldığı anlamına gelmez.

Aynı şekilde reklamların onaylanması da web sitesindeki tüm mağaza süreçlerinin uygun olduğu anlamına gelmez. Sipariş, ödeme ve teslimat deneyimi ayrıca incelenmelidir.

Örneğin e-ticarette teslimat süresinin nasıl yazılacağı belirsiz bırakılırsa, feed’deki gönderim ayarı doğru olsa bile müşteri beklentisiyle sayfa bilgisi çelişebilir.

Mağaza sahipleri Eylül 2026’dan önce hangi kontrol listesini uygulamalı?

Mağaza sahipleri Eylül 2026’dan önce ürün verisini, site bilgilerini ve Merchant Center ayarlarını aynı ürün örnekleri üzerinden karşılaştırmalıdır.

Kontrolü yalnızca en çok satan ürünlerle sınırlamayın. En azından farklı kategorilerden, farklı markalardan, varyantlı ürünlerden ve indirimli ürünlerden örnek seçin.

Her ürün için Merchant Center’daki durum, son güncelleme zamanı ve hata metnini kaydedin. Ardından aynı ürünün sayfasındaki fiyat, stok ve teslimat bilgilerini kontrol edin.

• Ürün başlığı ve açıklaması, ürün sayfasındaki bilgilerle aynı mı?
• Feed’deki fiyat ve para birimi, ödeme adımında değişiyor mu?
• Stok durumu, ürün sayfası ve feed arasında eşleşiyor mu?
• Ürün görseli çalışıyor ve ana ürünü doğru gösteriyor mu?
• Varyant seçimi, URL ve stok bilgisi birbiriyle uyumlu mu?
• Gönderim ücreti ve teslimat süresi sitede açıkça yazıyor mu?
• İade koşulları, iletişim bilgileri ve işletme verileri erişilebilir mi?
• Feed güncellemesi beklenenden uzun süre eski veri taşımıyor mu?

Bu listenin amacı yalnızca hata bulmak değildir. Hangi bilginin hangi sistemden geldiğini anlamaktır. Böylece aynı sorun tekrarlandığında sorumluluğu doğru kaynağa yönlendirebilirsiniz.

Kontrol sırasında bir ürünün yalnızca reklamda veya yalnızca ücretsiz listelemede görünmesine dikkat edin. Bu ayrım, politika birleşmesi sonrasında hangi alanların yeniden incelenmesi gerektiğini gösterir.

Listeyi elektronik tabloda tarih, ürün kimliği, kontrol edilen alan, sonuç ve düzeltme tarihi sütunlarıyla tutabilirsiniz. Böylece değişiklik sonrası karşılaştırma yapacak bir başlangıç kaydı oluşur.

Çok küçük kataloglarda manuel kontrol yeterli olabilir. Büyük kataloglarda ise feed dışa aktarımı, URL taraması ve fiyat-stok karşılaştırması gibi yöntemler kullanılmalıdır.

Merchant Center ürün reddi sonrası hangi sırayla hareket edilmeli?

Ürün reddi sonrasında önce hata türünü doğrulayın, sonra hatanın kaynağını düzeltin ve en son yeniden inceleme veya güncelleme talebi oluşturun.

İlk adımda reddedilen ürün kimliğini, politika başlığını, örnek URL’yi ve bildirimin tarihini kaydedin. Aynı hata birden fazla üründe varsa ortak alanları arayın.

1. Merchant Center teşhis ekranında hata mesajını ve etkilenen ürünleri listeleyin.
2. Ürün URL’sini açıp fiyat, stok, varyant, teslimat ve iade bilgilerini kontrol edin.
3. Feed kaynağında aynı ürün kimliğine ait alanları web sitesiyle karşılaştırın.
4. Sorunun kaynak sistemini düzeltin ve feed güncellemesini bekleyin.
5. Ürün durumunun değiştiğini kontrol edin; gerekiyorsa yeniden inceleme seçeneğini kullanın.

Bu sıra, yanlış kaynağı düzeltme riskini azaltır. Örneğin web sitesindeki fiyat hatasını yalnızca feed’de değiştirmek, sonraki güncellemede sorunu yeniden oluşturabilir.

Hata bir feed alanından kaynaklanıyorsa ürün yönetim sistemi veya e-ticaret platformundaki ana veriyi düzeltin. Feed’i elle değiştirmek, kalıcı çözüm olmayabilir.

Birden fazla üründe “yanlış beyan” veya benzeri güven sorunları görülüyorsa tek ürün düzeltmesi yeterli olmayabilir. Mağaza bilgileri, ödeme akışı ve işletme açıklamaları birlikte incelenmelidir.

Merchant Center’da yanlış beyan reddinin nasıl çözüleceği konusunda izlenecek temel yaklaşım, hata kaynağını hesap ve site düzeyinde ayırmaktır.

Yeniden inceleme talebi, düzeltilmemiş bir problemi çözmez. Önce değişikliğin gerçekten yayınlandığını ve taranan sayfada göründüğünü doğrulayın.

Feed ve web sitesi uyumsuzlukları politika birleşmesinden nasıl etkilenir?

Feed ve web sitesi uyumsuzlukları, birleşik politika yapısında daha görünür hale gelebilir; çünkü aynı ürün bilgisi farklı yayınlama alanlarında birlikte değerlendirilecektir.

En sık karşılaşılan uyumsuzluklar fiyat, stok ve varyant bilgilerindedir. Feed gün içinde yenilenirken web sitesi anlık stok değiştiriyorsa, iki sistem arasında kısa süreli fark oluşabilir.

Bu farkın etkisi, ürün sayısı ve güncelleme sıklığına göre değişir. Az ürünlü bir mağaza manuel kontrol yapabilir; büyük kataloglarda otomatik karşılaştırma gerekir.

URL yapısı da ayrıca incelenmelidir. Ürün bağlantısı mobilde açılmıyor, bölgesel yönlendirme yapıyor veya seçilen varyantı göstermiyorsa, feed’deki doğru veri sayfada doğrulanamayabilir.

Görseller için dosya bağlantılarının çalışması, ürünün doğru açıdan gösterilmesi ve görselin ilgili ürüne ait olması gerekir. 500x500 uyarısı gibi bildirimlerde yalnızca ölçüyü değil, görsel kullanımını da kontrol edin.

Bu tür uyarılar için 500x500 Merchant Center uyarısının çözüm adımları, görsel alanlarının teknik olarak incelenmesine yardımcı olur.

Video alanı kullanılan ürünlerde, bağlantının doğru biçimde gönderilmesi gerekir. Feed’de video bağlantısı bulunması, bağlantının erişilebilir ve ürünle ilişkili olduğu anlamına gelmez.

Bu nedenle Merchant Center video_link hatasının nasıl düzeltileceği incelenirken alan biçimi, bağlantı erişimi ve ürün eşleşmesi birlikte kontrol edilmelidir.

Uyumsuzlukları izlemek için haftalık veya ürün güncelleme sıklığına uygun bir kontrol periyodu belirleyin. Sabit bir sayı vermek yerine, stok değişim hızınıza göre süreyi kısaltın.

Gönderim, iade ve minimum sipariş bilgileri neden önem kazanıyor?

Gönderim, iade ve minimum sipariş bilgileri önem kazanıyor; çünkü ürünün satın alınabilirliği yalnızca fiyat ve stokla açıklanmıyor.

Bir ürünün sayfasında “3-5 iş günü” yazarken Merchant Center gönderim ayarında farklı bir süre bulunuyorsa müşteri, satın alma kararında çelişkili bilgi görür.

Gönderim ücretinin sepette sonradan ortaya çıkması da benzer bir sorundur. Ücretsiz kargo eşiği, bölgesel ücret veya teslimat kısıtı varsa bunlar anlaşılır biçimde belirtilmelidir.

İade koşullarında süre, ürünün iade edilebilirliği, kargo sorumluluğu ve istisnalar açıkça yazılmalıdır. Genel bir “şartlar geçerlidir” ifadesi, gerekli ayrıntıların yerine geçmez.

Minimum sipariş değeri uygulayan mağazalar, bu koşulu ürün ve ödeme akışıyla tutarlı göstermelidir. Merchant Center’da minimum sipariş değerinin nasıl ekleneceğini ilgili uygulama rehberinde bulabilirsiniz.

Örneğin 250 TL altındaki siparişlerde ödeme alınmıyorsa, ürün sayfası ve sepet bu koşulu açıkça göstermelidir. Aksi durumda ürün tek başına satın alınabilir izlenimi yaratır.

Bu bilgiler her mağazada aynı ağırlıkta görünmeyebilir. Dijital ürün, fiziksel ürün, kişiye özel ürün ve bölgesel gönderim yapan mağazaların kontrol alanları farklılaşır.

Gönderim süresi belirsizse yalnızca metni değiştirmek yeterli değildir. Depo hazırlık süresi, taşıyıcı süresi ve hafta sonu hesaplaması işletme süreciyle de uyumlu olmalıdır.

Birleşik politika yapısı, bu bilgilerin reklam dışı listelemelerde de göz ardı edileceği varsayımını geçersiz kılar. Ücretsiz trafik alan ürünler de ticari koşulları açıkça taşımalıdır.

E-ticaret platformu değişikliği Merchant Center uyumunu etkiler mi?

E-ticaret platformu değişikliği Merchant Center uyumunu etkileyebilir; çünkü feed alanları, URL yapısı, varyant mantığı ve güncelleme sıklığı platforma göre değişebilir.

İkas, T-Soft veya başka bir platforma geçişte ürün kimliklerinin korunup korunmadığını kontrol edin. Kimlikler değişirse geçmiş ürün performansı ve teşhis kayıtlarının takibi zorlaşabilir.

Platform değişiminden önce mevcut feed’i dışa aktarın. Ürün kimliği, başlık, fiyat, stok, marka, GTIN, görsel bağlantısı, ürün URL’si ve gönderim alanlarını saklayın.

Yeni feed’i doğrudan tüm katalogla yayına almak yerine, temsilî bir ürün grubuyla test etmek daha kontrollüdür. Farklı kategori ve varyantlardan örnek seçin.

İkas kullanan mağazalar için İkas’ta Google Merchant Center feed’inin nasıl açılacağı incelenirken, yalnızca bağlantı kurulumuna değil, alan eşleşmelerine de bakılmalıdır.

Platform karşılaştırması yaparken sadece aylık ücret veya tasarım özelliklerini dikkate almayın. Merchant Center feed’inin güncelleme mantığı, varyant desteği ve hata takibi de ölçülmelidir.

Bu nedenle İkas mı T-Soft mu karşılaştırmasında ürün aktarımı ve katalog yönetimi gibi operasyonel başlıklar ayrıca değerlendirilmelidir.

Yeni platformda URL’ler değişiyorsa, eski ürün bağlantılarının yönlendirmelerini test edin. Çalışmayan veya yanlış ürüne yönlenen bağlantılar, veri doğru olsa bile ürün sayfası kontrolünü bozabilir.

Geçiş tamamlandıktan sonra ilk kontrol, tüm ürünleri tekrar onaya göndermek değil, hata oranını karşılaştırmaktır. Eski ve yeni feed’de reddedilen ürün sayısı ile hata türlerini yan yana koyun.

Mağazalar birleşmeden sonra hangi ölçümleri takip etmeli?

Mağazalar birleşmeden sonra ürün onay oranını, aktif ürün sayısını, hata türlerini ve veri güncelleme gecikmelerini birlikte takip etmelidir.

Tek başına onay oranı yeterli değildir. Örneğin toplam ürünlerin çoğu onaylı görünürken, en yüksek ciroyu getiren kategori aynı politika hatası nedeniyle sınırlanmış olabilir.

Ürünleri en az dört gruba ayırın: aktif, beklemede, reddedilmiş ve sınırlı görünürlükte olanlar. Her grubun ürün sayısını ve toplam satış içindeki payını ayrı değerlendirin.

Hata türlerini de sınıflandırın. Fiyat-stok uyuşmazlığı, eksik gönderim bilgisi, görsel sorunu, URL erişim problemi ve mağaza politikası eksikliği aynı çözüm yöntemiyle giderilmez.

Güncelleme gecikmesi için feed’in gönderildiği zaman ile Merchant Center’da işlendiği zamanı karşılaştırın. Düzenli gecikme varsa veri kaynağı, zamanlama veya platform entegrasyonu incelenmelidir.

Değişiklik sonrası etkileri ölçerken aynı dönemi karşılaştırmaya çalışın. Sezon, kampanya bütçesi, stok seviyesi ve ürün fiyatı değiştiyse yalnızca politika birleşmesine sonuç atfetmeyin.

Bir ürünün görünürlüğü düşerse önce teknik ve politika durumunu kontrol edin. Ardından gösterim, tıklama, sepete ekleme ve satış verilerini aynı ürün grubu için inceleyin.

Örneğin reklam gösterimi sürerken ücretsiz listeleme trafiği düşmüş olabilir. Bu durum, tüm hesabın reddedildiğini değil, yayınlama alanlarından birinde farklı bir kısıt bulunduğunu gösterebilir.

Raporları haftalık, aylık veya katalog güncelleme hızınıza göre oluşturun. Önemli olan sabit bir sıklık değil, değişiklikleri karşılaştırabilecek düzenli kayıt tutmaktır.

Sonuç olarak Eylül 2026 hazırlığı, tek seferlik bir temizlik değil, ürün verisi ile mağaza koşullarını birlikte izleyen bir kontrol düzenidir.