Eğer Wildberries, Ozon veya Avito'da rakiplerin fiyatlarını IMPORTXML ile Google Sheets üzerinden izliyorsanız, er ya da geç tablo #N/A hataları vermeye başlar, veriler saatlerce güncellenmez ve bazen tamamen çekilmez hale gelir. Bu bir hata değil — bu, Google Sheets'in kendi limitlerine ve aynı IP adreslerinden gelen toplu isteklere karşı sitelerin koruma önlemlerine takılmaktır. Bu yazıda, tablonun kaynaklarının tükendiğini anlamanın belirtilerini ve kendi proxy'li parser'ınıza nasıl sorunsuz geçiş yapacağınızı inceleyeceğiz.
IMPORTXML nasıl çalışır ve neden kullanılır
IMPORTXML — Google Sheets'te yerleşik bir işlevdir, sayfadan XPath sorgusu ile veri alır ve bunları doğrudan hücreye yerleştirir. =IMPORTXML("URL"; "//span[@class='price']") şeklindeki bir formül, tek bir kod satırı yazmadan Wildberries veya Ozon'daki ürünün fiyatını çekmenizi ve her saat otomatik olarak güncellenmesini sağlar.
Satıcılar ve pazarlamacılar için bu, mükemmel bir çözüm gibi görünmektedir: geliştiriciye ihtiyaç yok, sunucuya ihtiyaç yok, her şey tanıdık tabloda çalışıyor. 20-30 üründen oluşan küçük bir mağaza gerçekten de yıllarca tek bir IMPORTXML ile sorun yaşamadan devam edebilir. Ancak izlenen SKU sayısı birkaç yüzü geçtiğinde ve güncellemelerin günde bir kez değil, saatte bir kez yapılması gerektiğinde — sistemsel hatalar başlar ve bu hataları işlevin ayarlarıyla çözmek artık mümkün olmaz.
Sorun, tüm IMPORTXML isteklerinin Google sunucularından geldiğidir, sizin bilgisayarınızdan değil. Google'ın bu tür istekler için sınırlı bir IP adresi havuzu vardır ve pazar yerleri bu aralıkları çok iyi bilmektedir. İstek sayısı arttığında, sitenin koruma önlemleri devreye girer — ve hücrede fiyat yerine hata veya boş bir değer görünür.
IMPORTXML'ın artık başa çıkamadığını gösteren 7 belirti
Daha karmaşık bir çözüme geçmeden önce, sorunun gerçekten limitlerden kaynaklandığından emin olun, formülde bir yazım hatası olmadığını kontrol edin. İşte bunun belirlenmesine yardımcı olacak somut belirtiler:
- Toplu #N/A — aynı anda %30-50 oranında formül çalışmayı durdurur, oysa dün her şey yolundaydı ve sayfa yapısı değişmemişti.
- Güncelleme gecikmesi artıyor — daha önce veriler 5-10 dakikada güncelleniyordu, şimdi tablo "düşünüyor" 30-40 dakika veya manuel yeniden hesaplama olmadan hiç güncellenmiyor.
- "Resource at url contacted too many times" hatası — Google'dan, bir alan adına yapılan iç isteklere takıldığınızın doğrudan mesajı.
- Veriler eski geliyor — tablodaki fiyat, Google'ın güncel sayfa yerine önbelleğe alınmış bir versiyonunu vermesi nedeniyle gerçek sitedekinden farklıdır.
- Satır sayısı 300-500'ü aşıyor — bir belgede daha fazla IMPORTXML formülü varsa, alan adı bazında toplu yasaklanma olasılığı artar.
- Saate birden daha sık güncelleme gerektiriyor — IMPORTXML fiziksel olarak gerçek zamanlı izleme için tasarlanmamıştır, IP döndürme mekanizması yoktur.
- Site kimlik doğrulama veya captcha talep ediyor — Wildberries ve Ozon, giderek daha fazla JavaScript kontrolü ile sayfalar gösteriyor, bu da IMPORTXML'in geçemediği bir durumdur.
Eğer listedeki en az 2-3 madde sizinle örtüşüyorsa — bu geçici bir Google Sheets hatası değil, teknolojinin yapısal bir sınırıdır. Daha fazla formül düzeltmek, IFERROR eklemek ve manuel olarak yeniden hesaplamak sonsuz bir çaba haline gelebilir, ancak manuel iş yükü, faydalı verilerin miktarından daha hızlı artacaktır.
Web siteleri neden Google Sheets'ten gelen istekleri engelliyor
Wildberries ve Ozon gibi pazar yerleri, her gün rakiplerden, analiz servislerinden ve botlardan milyonlarca otomatik istek almaktadır. Sunucuları aşırı yüklenmekten korumak ve fiyat verilerini toplu parse etmelerden korumak için birkaç koruma seviyesi uygularlar:
- IP başına oran sınırlaması — eğer bir adresten dakikada N'den fazla istek gelirse, IP geçici olarak engellenir.
- User-Agent analizi — IMPORTXML için Google botlarından gelen istekler, başlıklardan normal bir tarayıcıdan kolayca ayırt edilebilir.
- JavaScript renderleme — içeriğin bir kısmı dinamik olarak scriptler aracılığıyla yüklenir ve IMPORTXML yalnızca JS çalıştırılmadan kaynak HTML'yi görür.
- Coğrafi filtreleme — Google'ın sunucu IP'lerinden gelen istekler genellikle "gerçek bir alıcıya benzemiyor" filtresine takılır.
Temel sorun, tüm dünyadaki IMPORTXML kullanıcılarının teknik olarak aynı sınırlı Google sunucu IP adresi havuzunu kullanmasıdır. Binlerce tablo aynı anda Wildberries'in aynı alanını sorguladığında, sitenin koruması belirli bir kullanıcıyı değil, bir IP aralığını yasaklar — ve siz de dahil olmak üzere herkes etkilenir.
IMPORTXML vs no-code parser vs kendi parser'ınız: karşılaştırma tablosu
Google Sheets'in yerleşik işlevinden geçiş yapmak, mutlaka bir programcıyı işe almak anlamına gelmez. Ara seçenekler de vardır. Üç yaklaşımı ana parametreler açısından karşılaştıralım:
| Kriter | IMPORTXML | No-code parser (Octoparse, ParseHub) | Kendi parser'ınız proxy ile |
|---|---|---|---|
| Kod gerekli mi | Hayır | Hayır | Evet (veya yüklenici) |
| İstek limiti | Sert, gizli | Tarife bağlı | Kendiniz kontrol edersiniz |
| IP döndürme | Mevcut değil | Kısmen yerleşik | Proxy ile tam kontrol |
| JS sayfaları ile çalışma | Hayır | Evet | Evet (Selenium/Playwright ile) |
| Güncelleme sıklığı | Saate bir ve daha az | Ayar yapılabilir | Herhangi bir, gerçek zamanına kadar |
| Ölçek (SKU) | 200-300'e kadar | Birkaç bin'e kadar | Pratik sınırlama yok |
No-code parser'lar, geliştirici olmadan hızlı bir şekilde bir görevi kapatmak için iyi bir ara adımdır. Ancak fiyat izleme, sürekli bir iş süreci ise ve tek seferlik bir görev değilse, proxy ile kendi parser'ınız veri kontrolü ve başka bir servisin limitlerine bağımlılığın olmaması açısından geri dönüş sağlar.
Pazar yerlerini parse etmek için hangi proxy'ler gerekir
Kendi parser'ınızın IMPORTXML'den daha stabil çalışmasının ana nedeni, istekleri Google'ın tek bir sunucu havuzu yerine farklı IP adresleri arasında dağıtma imkanıdır. Ancak proxy türü de önemlidir:
- Veri merkezi proxy'leri — başlangıç için en hızlı ve en uygun seçenek. Pazar yeri henüz otomatik isteklerin kalıbını tanımadıysa uygundur. Parser'ın ilk testleri ve az sayıda SKU için iyidir.
- Konut proxy'leri — gerçek ev sağlayıcılarının IP adreslerini kullanır, bu nedenle Wildberries ve Ozon için normal alıcılar gibi görünür. Bu, coğrafi veya trafik kalıbı nedeniyle yasaklanmamak için düzenli fiyat izleme için ana seçenektir.
- Mobil proxy'ler — pazar yerlerinin çok isteksiz bir şekilde yasakladığı mobil operatörlerin IP'leridir, çünkü bir mobil IP'nin arkasında genellikle binlerce farklı kullanıcı bulunur. Mobil web siteleri veya uygulamalar üzerinden parse etme gerekiyorsa geçerlidir.
Wildberries ve Ozon'da fiyat izlemeye başlamak için en uygun kombinasyon: her istekte veya birkaç dakikada bir IP döndürme ile konut proxy'leri. Bu, rate limit'e takılma riskini azaltır ve binlerce isteği yüzlerce farklı adres arasında dağıtarak farklı bölgelerden gelen normal kullanıcı davranışını taklit eder.
Kendi parser'ınıza geçiş için adım adım plan
IMPORTXML'den geçiş, çalışmayı tamamen durdurmayı gerektirmez — tabloyu yeni parser test edilirken yedek bir kanal olarak bırakabilirsiniz.
- IMPORTXML'de kullanılan SKU ve XPath seçicilerinin listesini kaydedin — bu, yeni çözüm için hazır bir veri haritasıdır.
- Parser formatını seçin: hızlı bir başlangıç için no-code hizmet (Octoparse, ParseHub, Apify) veya ekibinizde bir geliştirici veya serbest çalışan varsa Python/Node.js'de bir script.
- IP döndürme ile proxy'leri bağlayın. Bunu yapmazsanız, yeni parser aynı engellerle karşılaşacaktır, sadece biraz daha geç.
- İsteklerin zamanlamasını ayarlayın — istekler arasında küçük rastgele gecikmeler (2-5 saniye) ile — bu, kalıp koruma mekanizmasının devreye girme olasılığını azaltır.
- Verileri Google Sheets'e geri aktarın — Google Sheets API veya Zapier/Make gibi bir hizmet aracılığıyla, ekibin alışık olduğu raporları ve panoları bozmadan.
- 10-15% ürün üzerinde bir hafta boyunca test edin — eski IMPORTXML formüllerinden gelen verilerle doğruluğu karşılaştırarak tamamen geçmeden önce.
- Hatalar için uyarılar ayarlayın — parser captcha veya 403 kodu almaya başladığında proxy'yi hemen değiştirmek veya istek sıklığını azaltmak için Telegram veya e-posta ile bildirim.
Proxy ile Python'da minimum parser
Eğer ekibinizde bir geliştirici varsa, temel parser versiyonu birkaç on satır kod alır. Aşağıda, requests kütüphanesini kullanarak proxy ile bir ürün sayfası isteği için basitleştirilmiş bir örnek verilmiştir:
import requests
import time
import random
proxies = {
"http": "http://login:password@proxy_host:port",
"https": "http://login:password@proxy_host:port",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"
}
urls = [
"https://example-marketplace.com/product/12345",
"https://example-marketplace.com/product/67890",
]
for url in urls:
try:
response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
if response.status_code == 200:
# ardından fiyatı BeautifulSoup veya lxml ile parse etme
print(f"OK: {url}")
else:
print(f"{url} için durum {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"İstek hatası: {e}")
time.sleep(random.uniform(2, 5)) # istekler arasında duraklama
JavaScript aracılığıyla dinamik olarak fiyat yükleyen sayfalar için (Wildberries ve Ozon için tipik) normal requests yerine, gerçek bir tarayıcı gibi sayfayı renderlayabilen Selenium veya Playwright gerekecektir ve proxy'yi başlatma parametreleri aracılığıyla geçirebilir.
Başlatmadan önce kontrol listesi
- Eski IMPORTXML formüllerinden URL ve veri seçici listesi taşındı
- Proxy'ler IP döndürme ile bağlandı (pazar yerleri için konut veya mobil)
- İstekler arasında rastgele gecikmeler ayarlandı (2-5 saniye)
- Her istekte gerçekçi User-Agent ve tarayıcı başlıkları
- Hataların günlüğü ve 403/captcha kodu için uyarılar ayarlandı
- Veriler alışık olunan formatta (Google Sheets, CRM, BI panosu) aktarılıyor
- Tam geçişten önce 1-2 haftalık bir test yapıldı
Sonuç
IMPORTXML — başlangıç için harika bir araçtır, ürün listesi küçükken ve güncelleme sıklığı kritik değilken. Ancak, toplu #N/A'lar, artan gecikmeler ve limit hatası mesajları görmeye başladığınızda — bu, Google Sheets'in yerleşik işlevinin mimari sınırına ulaştığının bir işaretidir. Teknik olarak, tablo ayarlarıyla bu sorun düzeltilemez, çünkü sorun Google'ın sınırlı IP adresi havuzundadır ve pazar yerleri bunları topluca yasaklar.
Kendi parser'ınıza geçiş, ister no-code hizmet olsun ister Python'da bir script, isteklerin IP adresleri üzerinde kontrol sağlaması açısından bu sorunu çözer. Eğer Wildberries, Ozon veya Avito'da düzenli fiyat izleme yapmayı planlıyorsanız, konut proxy'leri ile başlamanızı öneririz — bunlar gerçek alıcıların trafiği ile benzerlik gösterdiği için en düşük yasaklama riskini sunar. Başlangıçta hızlı testler için daha bütçe dostu veri merkezi proxy'leri ile idare edebilir, mobil versiyonlar için ise mobil proxy'lere göz atabilirsiniz.