E-ticaret tarafında yılın en sessiz ama en maliyetli teknik kırılması yaşanıyor. Google, yıllardır Merchant Center ürün akışlarının omurgası olan Content API for Shopping'i 18 Ağustos 2026 itibarıyla resmen emekliye ayırdı. 1 Eylül'den itibaren eski entegrasyon üzerinden gönderilen istekler kademeli olarak HTTP 410 Gone yanıtı almaya başladı. Yani sorun "yakında olacak" değil, şu anda oluyor.
Bu geçişin sinsi tarafı, aniden kapanan bir musluk gibi davranmaması. Akış tamamen durmuyor; istekler önce ara ara hata veriyor, ürünlerin bir kısmı güncellenmiyor, stok ve fiyat bilgileri bayatlıyor. Reklam hesabındaki tablo ise bambaşka görünüyor: kampanya "aktif", bütçe harcanıyor, ama ürünlerin bir bölümü onaysız duruma düşüyor ve gösterim payı sessizce eriyor. Çoğu marka sorunu, aylık raporda dönüşüm düşüşünü gördüğünde fark ediyor.
Content API for Shopping neden kapatıldı?
Content API, on yılı aşkın süredir kullanılan, tek parça halinde tasarlanmış bir yapıydı. Hesap bilgisi, ürün verisi, kargo ayarları, vergi tanımları ve dönüşüm kaynakları aynı devasa kaynağın içinde duruyordu. Tek bir alanı güncellemek isteseniz bile, tüm nesneyi göndermek zorunda kalıyordunuz. Bu da hem gereksiz veri trafiği hem de birden fazla sistemin aynı anda yazdığı senaryolarda kontrolsüz üzerine yazma sorunları anlamına geliyordu.
Merchant API ise sıfırdan modüler kuruldu. Her alan kendi kaynağına ayrıldı: hesap bilgileri, işletme profili, veri kaynakları, ürün girdileri ve raporlama artık birbirinden bağımsız servisler. Bu ayrışma sadece geliştirici konforu değil; çok kanallı, çok pazarlı ve çok besleyicili yapılar kuran markalar için operasyonel bir kazanım. Bir pazaryeri akışını güncellerken kendi sitenizin akışını bozma riskiniz ortadan kalkıyor.
Google'ın zamanlaması da tesadüf değil. Ürün verisinin doğruluğu artık yalnızca Shopping reklamlarını değil, yapay zekâ destekli alışveriş deneyimlerini ve ücretsiz ürün listelemelerini de besliyor. Eksik ya da bayat veri, bu yüzeylerin hiçbirinde görünürlük kazanamıyor. Ürün verisini bir "reklam girdisi" değil, marka envanterinin tek doğruluk kaynağı olarak görmek gereken bir döneme girdik.
Merchant API'de değişen üç temel yapı
Geçişi doğru planlamak için önce neyin gerçekten değiştiğini anlamak gerekiyor. Üç başlık, migrasyonun neredeyse tamamını kapsıyor.
1. Ürün yönetimi ikiye ayrıldı
Merchant API, ürünü tek bir nesne olarak görmüyor. Artık iki ayrı kaynak var: ProductInput ve Product. ProductInput, sizin gönderdiğiniz ham veri. Product ise Google'ın kurallarınızı, ek besleme verilerinizi ve otomatik iyileştirmelerini uyguladıktan sonra ortaya çıkan, salt okunur nihai sonuç. Yani "ne gönderdim" ile "Google ne gördü" artık iki ayrı yerden okunuyor.
Bu ayrım, feed hata ayıklamasını köklü biçimde kolaylaştırıyor. Daha önce bir ürünün başlığının neden değiştiğini anlamak için tahmin yürütmek gerekiyordu; şimdi girdi ile çıktıyı yan yana koyup farkı görebiliyorsunuz. Ayrıca yeni productInputs.patch metodu sayesinde tek bir alanı, örneğin sadece fiyatı güncelleyebiliyorsunuz. Eski sistemde tüm ürünü yeniden göndermek zorunda kalmanın yol açtığı çakışmalar büyük ölçüde tarihe karışıyor.
2. Veri kaynakları artık açıkça tanımlanıyor
Eski API'de ilk ürününüzü gönderdiğiniz anda Google sizin için otomatik olarak bir "Content API" veri kaynağı yaratıyordu ve elinizde tek bir kaynak oluyordu. Merchant API'de bu sihir yok: veri kaynaklarını önceden ve açıkça siz oluşturuyorsunuz. Dahası, API tipinde birden fazla kaynak tanımlayabiliyorsunuz.
Her yazma işleminde artık dataSource parametresi zorunlu. İlk bakışta fazladan iş gibi görünse de, pratikte en değerli değişiklik bu. Ana katalog beslemesi, kampanya fiyatları, stok güncellemeleri ve yerel envanter artık ayrı kaynaklardan gelebiliyor. Hangi sistemin hangi alanı yazdığı net; bir hata olduğunda kaynağı bulmak dakikalar sürüyor. Karmaşık katalog yapıları için e-ticaret altyapı çözümleri tarafında bu ayrışmayı baştan doğru kurgulamak, ilerideki teknik borcu ciddi biçimde azaltıyor.
3. Hesap yönetimi modülerleşti
Content API'deki tek parça Account kaynağı, Merchant API'de küçük ve odaklı parçalara bölündü. İşletme adresinizi güncellemek için artık tüm hesap nesnesini göndermeniz gerekmiyor; BusinessInfo kaynağına küçük bir PATCH isteği yeterli. Kargo ayarları, kullanıcı yetkileri, program katılımları ve iş ortağı ilişkileri de benzer şekilde ayrıştı.
Çok mağazalı ya da çok ülkeli yapılarda bu fark çok belirgin. Onlarca alt hesabı yöneten ajanslar ve markalar için istek sayısı da, hata yüzeyi de küçülüyor.
Geçişi yapmadıysanız şu anda ne oluyor?
Burada en tehlikeli varsayım, "hata almıyorum, demek ki sorun yok" düşüncesi. Google kapanışı kademeli uyguluyor; onaylı uzatma başvurusu olmayan entegrasyonlar önce aralıklı 410 hataları görüyor. Sistem bazı istekleri kabul ediyor, bazılarını reddediyor. Sonuç, kısmen güncellenmiş bir katalog.
Pratikte şu tabloyla karşılaşıyorsunuz:
- Fiyat uyuşmazlığı reddi: Sitedeki indirimli fiyat akışa yansımıyor, ürün "fiyat eşleşmiyor" gerekçesiyle onaysız kalıyor.
- Stokta olmayan ürüne reklam: Tükenen ürün akışta hâlâ mevcut görünüyor; tıklama alıyor, dönüşüm getirmiyor.
- Gösterim payında sessiz erime: Kampanya aktif ama uygun ürün sayısı azaldığı için erişim düşüyor; panelde bariz bir alarm görünmüyor.
- Ücretsiz listelemelerin kaybı: Onaysız ürünler Shopping sekmesindeki organik görünürlüğü de kaybediyor.
Bu kayıpların çoğu Google Ads yönetimi panelinde "kampanya sorunu" gibi görünmüyor. Bütçe harcanmaya devam ettiği için bir süre fark edilmiyor. Geçiş için ek süreye ihtiyacınız varsa Google hâlâ uzatılmış erişim başvurusu kabul ediyor, ancak bu kalıcı bir çözüm değil; yalnızca nefes alma payı.
Raporlama tarafında ne değişiyor?
Migrasyonun çoğu zaman gözden kaçan ikinci yarısı raporlama. Merchant API, ürün performansını ve rekabet verilerini yeni bir raporlama servisi üzerinden sunuyor. Eski entegrasyonunuzda veri çeken BI panelleri, Looker Studio bağlantıları veya iç dashboard'larınız varsa, bunlar da geçişin kapsamında. Ürün gönderimini taşıyıp raporlamayı unutmak, iki hafta sonra boş grafiklerle uyanmak anlamına geliyor.
Yeni yapıda raporlar daha ayrıntılı sorgulanabiliyor: marka, kategori ve özel etiket kırılımında tıklama, gösterim ve rekabetçi görünürlük verisi çekilebiliyor. Bu, özellikle geniş kataloglarda "hangi ürün grubu bütçeyi yiyor, hangisi ciroyu taşıyor" sorusuna çok daha net cevap veriyor. Kampanya yapınızı ürün performansına göre yeniden kurgulamak istiyorsanız, geçiş bunun için doğal bir fırsat.
Dönüşüm kaynakları da ayrı bir kaynağa taşındı. Mağaza içi satış yüklemesi ya da üçüncü taraf dönüşüm entegrasyonu kullanan markaların bu tarafı ayrıca doğrulaması gerekiyor. Ölçümleme zincirinde kopan tek bir halka, otomatik teklif algoritmalarını haftalarca yanlış yönlendirebiliyor.
Uzatma başvurusu: kime, ne kadar süre?
Google, geçişi tamamlayamayan işletmeler için uzatılmış erişim başvurusu kabul ediyor. Başvurunuz onaylanırsa Content API istekleriniz belirli bir süre daha çalışmaya devam ediyor. Ancak burada iki kritik nokta var: onay otomatik değil ve süre kalıcı değil.
Uzatmayı bir çözüm değil, planlı geçiş için zaman kazanma aracı olarak görmek gerekiyor. Pratikte en sağlıklı yaklaşım, uzatma başvurusunu yaparken aynı anda geliştirme takvimini de netleştirmek. Yılın son çeyreğinde, yani kampanya yoğunluğunun zirve yaptığı dönemde teknik migrasyon yapmak istemeyeceğinizi şimdiden hesaba katın. Ekim ortasından sonra başlayan bir geçiş, Kasım kampanya trafiğiyle çakışma riski taşıyor.
Yedi adımda Merchant API geçiş planı
Migrasyonu tek seferlik bir kod değişikliği gibi değil, kontrollü bir devreye alma süreci gibi ele almak gerekiyor.
- 1. Envanter çıkarın. Merchant Center'a veri yazan tüm sistemleri listeleyin: ERP, PIM, stok servisi, fiyatlandırma motoru, özel scriptler. Genellikle unutulmuş bir cron işi mutlaka çıkar.
- 2. Hangi metotları kullandığınızı belirleyin. Products, datafeeds, accounts, inventory, conversion sources arasından hangilerine dokunduğunuzu netleştirin; her birinin Merchant API karşılığı farklı.
- 3. Veri kaynaklarını önceden oluşturun. Artık otomatik yaratılmıyorlar. Ana katalog, stok ve fiyat güncellemeleri için ayrı kaynaklar tanımlayın.
- 4. Yazma işlemlerini ProductInput'a taşıyın. Kısmi güncelleme yapacaksanız patch metodunu kullanın; her seferinde tam ürün göndermek eski alışkanlık.
- 5. Paralel çalıştırın. Mümkünse kısa bir süre eski ve yeni entegrasyonu birlikte izleyin, nihai Product çıktılarını karşılaştırın.
- 6. Hata izleme kurun. 410 ve 400 yanıtlarını loglayın, eşik aşıldığında uyarı gönderin. Sessiz başarısızlık en pahalı senaryo.
- 7. Onay oranını takip edin. Geçişten sonraki iki hafta boyunca onaylı ürün sayısını günlük izleyin; düşüş varsa kaynak bazında ayırt edin.
Shopify, WooCommerce ve diğer platform kullanıcıları
Shopify, WooCommerce, Magento veya BigCommerce üzerinde resmî ve güncel bir Google entegrasyonu kullanıyorsanız, geçişi büyük ihtimalle sağlayıcınız üstlenmiştir. Ancak bu varsayımı doğrulamadan geçmeyin. Uygulama sürümünüz eskiyse ya da yıllar önce kurulmuş özel bir bağlayıcı kullanıyorsanız, riski hâlâ siz taşıyorsunuz.
Kendi geliştirdiğiniz entegrasyonlar ise tamamen sizin sorumluluğunuzda. Özellikle B2B tarafında, ERP'den doğrudan Merchant Center'a yazan kurum içi çözümler sık görülüyor ve bunlar genellikle yıllardır kimsenin dokunmadığı kodlar. Bu tür yapılar için geçişi, mevcut akışı iyileştirme fırsatı olarak da değerlendirmekte fayda var: ürün başlıklarının kalitesi, özel etiket stratejisi ve envanter segmentasyonu aynı çalışma içinde elden geçirilebilir.
Akış sağlıklı hâle geldikten sonra asıl kazanç, bütçenin nereye gittiğini doğru okuyabilmekte. Ürün verisi temiz olduğunda kampanya yapısı da anlamlı hâle geliyor ve performans pazarlaması tarafında yapılan optimizasyonlar gerçek sinyallere dayanıyor. Kirli veriyle yapılan teklif optimizasyonu, yanlış haritayla hızlı araba kullanmaya benziyor.
Geçiş sonrası kontrol listesi
Migrasyonu tamamladıktan sonra şu dört göstergeyi iki hafta boyunca günlük takip edin: onaylı ürün sayısı, reddedilen ürün gerekçe dağılımı, API hata oranı ve Shopping gösterim payı. Bu dördü birlikte okunduğunda, geçişin gerçekten temiz olup olmadığı ilk 48 saatte anlaşılıyor.
Ayrıca akış frekansınızı yeniden gözden geçirin. Merchant API'nin kısmi güncelleme yeteneği, daha sık ve daha küçük güncellemeler yapmanıza imkân tanıyor. Stok ve fiyat gibi hızlı değişen alanları günde birkaç kez güncellemek, özellikle kampanya dönemlerinde reddedilme oranını belirgin şekilde düşürüyor.
Sonuç olarak bu geçiş, yüzeyde bir API sürüm yükseltmesi gibi görünüyor; pratikte ise ürün verisi mimarinizi yeniden kurma daveti. Kataloğunu tek beslemeli, tek parça bir yapıdan çıkarıp kaynak bazlı ve izlenebilir bir mimariye taşıyan markalar, sadece bugünkü hataları önlemiş olmuyor; ürün verisinin arama, reklam ve yapay zekâ destekli alışveriş yüzeylerini aynı anda beslediği bir döneme hazırlanmış oluyor. Erteleyenler içinse fatura, kesintisiz ama görünmez bir ciro sızıntısı olarak gelmeye devam edecek.
