Scraping 200 OK Dönüyor Ama Veri Yok: Yanıt Doğrulama

Scraping 200 dönüyor ama veri yok şikâyetinin kaynağı hemen her zaman aynıdır: 200 kodu yalnız sunucunun bir yanıt ürettiğini söyler, o yanıtın beklediğiniz sayfa olduğunu söylemez. Hedef site ürün bulunamadı sayfasını, çerez onay ekranını, giriş formunu ya da bakım duyurusunu da 200 ile gönderebilir. İstemci yalnız durum koduna bakıyorsa bu sayfaları başarı sayar, ayrıştırıcı boş alanlar döndürür ve hata tablonuzda tek bir satır bile görünmez.

Proxy’nin devrede olup olmadığı ve IP’nin gerçekten değişip değişmediği ayrı sorunlardır; aşağıdaki adımlar isteğin hedefe ulaştığını ve bir gövde döndüğünü varsayar. Buradaki soru şudur: gelen gövde, ayrıştırıcının beklediği sayfa mı? Bu soruya kod yazmadan cevap verilemez, çünkü HTTP katmanı içeriğin anlamını bilmez.

Sorunun bedeli iki yerde çıkar. Birincisi veri tarafında: boş fiyat, null stok ve eksik başlık raporlara sessizce girer, farkına çoğu zaman rapor okuyan kişi varır. İkincisi kota tarafında: RotatingProxy kataloğundaki IPv4 datacenter, IPv4 residential ve mobile ürünler GB bazlı satılır ve gateway onay ekranını da, ürün sayfasını da aynı sayaçta toplar. Yalnız durum koduna bakan bir yeniden deneme politikası bu sayfaları hiç yeniden denemez; doğrulama katmanı eklenmeden sorun kendiliğinden görünür olmaz.

Birinci görünüm yumuşak 404’tür: ürün kaldırılmış, sayfa “bu ürün artık satışta değil” metniyle ve 200 koduyla dönüyor. İkincisi çerez onayı ya da bölge seçimi ekranıdır; gövde yalnız onay bandı ve boş bir iskelet taşır, asıl içerik onaydan sonra yüklenir. Üçüncüsü 200 ile dönen giriş, yaş doğrulama ya da bülten formudur; hedef, oturumsuz ziyaretçiyi yönlendirmek yerine formu doğrudan basar.

Dördüncü görünüm JavaScript iskeletidir. HTML gelir, kapsayıcılar yerindedir, ama veri sayfa açıldıktan sonra ayrı bir istekle çekilir; düz HTTP istemcisi yalnız boş kutuları görür. Beşincisi doğrulama ara sayfasıdır: “bir saniye, bağlantınız kontrol ediliyor” türü bir metin 200 ya da 403 ile döner. Bu sayfa çözülmez; tanınır ve kendi sınıfına yazılır.

Altıncısı yanlış varyanttır: sayfa dolu, veri var, ama başka ülkenin dili ya da para birimiyle, ya da yeni bir A/B düzeniyle gelmiştir; seçicileriniz tutmaz, alanlar boş kalır. Yedincisi 200 ile dönen bakım sayfası ya da “sonuç bulunamadı” yazan boş listedir; bazı hedefler hız sınırını açık bir 429 yerine boş sonuç sayfasıyla uygular. Bunlara bir de kesik gövdeyi ekleyin: bağlantı yarıda kopmuş, gövde Content-Length’in altında kalmış, ayrıştırıcı yarım HTML’de hiçbir şey bulamamıştır.

Taşıma katmanı durum kodunun yanında dört alanı daha okur. Yönlendirmeler sonrası varılan son URL beklenen desende mi (ürün sayfası isterken /giris ya da /onay yolunda mı bittiniz)? Content-Type beklenen tür mü (HTML beklerken JSON, JSON beklerken HTML gelmesi tek başına hata sayılır)? Gövde uzunluğu sayfa tipi için koyduğunuz alt sınırın üstünde mi (ürün sayfaları 40 KB civarındayken 3 KB gelen gövde incelenmeden geçemez)? Gövde sıkıştırma hatasız açılıyor ve Content-Length ile eşleşiyor mu?

Yapı katmanı sayfanın iskeletine bakar. HTML’de sayfa tipinin zorunlu seçicileri (ürün başlığı, fiyat kapsayıcısı, görsel listesi) var mı? JSON’da zorunlu anahtarlar yerinde, dizi uzunluğu mantıklı mı? Liste sayfasında eleman sayısı en az bir mi, değilse hedefin kendi “sonuç yok” işareti görünüyor mu? Ne eleman ne de boş sonuç işareti varsa elinizdeki şey iskelettir.

İçerik katmanı alan değerlerini sınar. Fiyat metni sayıya çevriliyor ve sıfırdan büyük mü? Tarih alanı ayrıştırılıyor mu? Başlık bir yer tutucu mu (“Loading”, “undefined”, tek boşluk)? Para birimi ve dil işaretleri hedeflediğiniz pazarla uyumlu mu? Bu katman ayrıştırıcının çıktısını, ayrıştırıcıdan bağımsız kurallarla ikinci kez okur.

Tutarlılık katmanı koşunun bütününe bakar. Önceki koşuyla kıyasla gövde boyutu dağılımı aynı mı? Boş alan oranı tabanınızın kaç katına çıktı? Bir alanın değeri tek koşuda sayfaların büyük çoğunluğunda aynı anda değiştiyse düzen değişikliği ihtimali, gerçek değişiklik ihtimalinden yüksektir. Bu katman koşu sırasında çalışır ve eşik aşılınca koşuyu durdurur; bin sayfayı yanlış ayrıştırdıktan sonra fark etmek yerine onuncu sayfada durursunuz.

Dört katmanı her sayfa tipi için tek bir imzada toplayın: zorunlu seçiciler, en az gövde uzunluğu, yasak ifadeler listesi, beklenen son URL deseni, dil ve para birimi işareti. Bir ürün sayfası imzası şöyle görünebilir: başlık ve fiyat seçicisi bulunmalı, gövde 20 KB’den uzun olmalı, son URL /urun/ içermeli, gövdede “ürün bulunamadı”, “erişiminiz engellendi”, “lütfen bekleyin” ve “çerezleri kabul” geçmemeli, fiyat alanında ₺ ya da TL bulunmalı. İmza ayrı bir yapılandırma dosyasında durur; hedef şablonunu değiştirdiğinde yalnız imzayı güncellersiniz, ayrıştırıcı koduna dokunmazsınız.

Gerçek boş sonuç ile iskeleti ayırmak için imzaya bir de “geçerli boş” işareti ekleyin: hedefin kendi “aramanızla eşleşen ürün yok” metni ya da boş dizi döndüren JSON alanı. Bu işaret varsa sayfa geçerli-boş olarak kaydedilir ve yeniden denenmez; yoksa doğrulama başarısızdır. Bu ayrım yapılmadığında ya gerçek boş listeler sonsuza kadar yeniden denenir ya da iskeletler boş liste sanılır.

İmzayı çıkarmak için her sayfa tipinden yirmi kadar örneği tarayıcıda açıp HTML’lerini kaydedin; başarılı örnekleri ve yakaladığınız her boş 200 örneğini ayrı klasörlerde tutun. Bu klasörler imzanızın test setidir: imzayı ya da ayrıştırıcıyı her değiştirdiğinizde set üzerinde çalıştırın, başarılı örneklerin hepsi geçmeli, boş örneklerin hiçbiri geçmemeli. Yeni bir boş 200 biçimiyle karşılaştığınızda örneği sete ekleyip imzayı o örnek düşene kadar sıkılaştırın.

Doğrulama, istek ile ayrıştırma arasında durur ve başarısız olduğunda sonuç bir istek hatası gibi işlenir; yeniden deneme politikanız durum kodlarının yanında doğrulama sınıflarını da tanımalıdır. Her sınıfın eylemi farklıdır. Yumuşak 404 yeniden denenmez; kayıt “kaldırılmış” işaretiyle saklanır ve bir sonraki planlı koşuda bir kez daha kontrol edilir, çünkü ürün geri gelebilir. Onay, giriş ve bölge ekranı aynı ayarlarla tekrar edilince aynı sonucu verir; bu sınıfta Accept-Language başlığı, hedefin bölge çerezi ya da ülke filtresi değiştirilerek yeniden denenir, hepsi aynı ülkeden geliyorsa filtre ayarı sorundur.

Doğrulama ara sayfası sınıfında eylem tempo tarafındadır. O hedefte eşzamanlılığı düşürün, aynı oturumu bırakın, istek aralığını açın ve oranı izleyin; oran bir ürün sınıfında yüksek, diğerinde düşükse hedef o IP sınıfına kural koymuş demektir ve karar datacenter ile residential arasında verilir. Hedefin resmî bir API’si ya da veri akışı varsa doğru yol odur. JavaScript iskeleti sınıfı istemci kararıdır: ya sayfanın kendi JSON uç noktasını kullanırsınız ya da o sayfa tipi için tarayıcı tabanlı istemciye geçersiniz; iskeletin yeniden denenmesi anlamsızdır, aynı iskelet gelir.

Yanlış varyant sınıfı ülke ve dil ayarına gider: ülke filtresi, Accept-Language ve gerekiyorsa sticky oturum birlikte kurulur, çünkü hedef dili bazen IP’den bazen başlıktan seçer. Bakım sayfası ve kesik gövde geçicidir; üstel bekleme ile yeniden denenir, deneme bütçesi dolunca koşunun sonuna ertelenir. Her sınıf için ayrı sayaç tutun ve günlük rapora boş 200 oranını sınıf bazında yazın; toplam oran tek sayı olarak size neyi düzelteceğinizi söylemez.

Her başarısız doğrulamayı istekte kullanılan ülke filtresi, oturum parametresi ve ürün sınıfıyla birlikte kaydedin. Boş yanıtlar bütün filtrelerde ve oturumlarda aynı anda başlıyorsa hedef değişmiştir: şablon, seçici ya da URL düzeni güncellenmiştir ve iş sizin tarafınızdadır. Yalnız belirli bir ülke filtresinde boşsa pazar varyantı ya da o ülkeye özgü onay ekranıyla karşı karşıyasınızdır. Yalnız bir oturum kimliğinde boşsa oturum eskimiş ya da o çıkış adresi hedef tarafında işaretlenmiştir; oturumu bırakıp yenisiyle devam edersiniz.

Beş istekli bir deney ayrıştırmayı hızlandırır. Aynı URL’yi önce proxysiz kendi bağlantınızdan, sonra hedef pazarın ülke filtresiyle rotating gateway üzerinden, sonra farklı bir ülke filtresiyle, en son aynı sticky oturumla art arda iki kez isteyin ve beş gövdeyi aynı imzayla değerlendirin. Proxysiz istek de boşsa hedef değişmiştir. Yalnız proxy üzerinden boşsa IP sınıfı ya da ülke etkilidir. Tek bir ülkede boşsa varyant sorunudur. Sticky oturumun iki isteği farklı sonuç veriyorsa hedef içeriği oturumdan bağımsız, isteğe göre değiştiriyordur.

Kota etkisini de aynı kayıttan okuyun. Bir ürün sayfası 60 KB, bir onay ekranı 8 KB olsun; 10.000 sayfalık koşuda sayfaların yüzde 30’u onay ekranı dönerse boşa giden trafik 3.000 × 8 KB, yani yaklaşık 24 MB’dir. Rakam küçük görünür, asıl bedel 3.000 eksik kayıt ve onları doldurmak için yapılacak ikinci koşudur: 3.000 × 60 KB, yaklaşık 180 MB daha. Doğrulama koşu sırasında çalışıp onuncu onay ekranında durduğunda ikinci koşu ilk koşunun yerine geçer, iki koşu ödemezsiniz.

Varsayımsal bir fiyat izleme koşusu düşünün: 1.000 ürün sayfası, tamamı 200. Doğrulama olmadan rapor 88 satırda boş fiyat gösterir ve bu 88 satır “ürün geçici olarak fiyatsız” diye yorumlanır. Doğrulama ile aynı koşu şöyle okunur: 912 sayfa geçerli; 41 sayfa yumuşak 404, hepsi aynı kategoriden ve ürünler gerçekten kaldırılmış; 29 sayfa onay ekranı, hepsi ülke filtresi verilmemiş isteklerden; 12 sayfa JavaScript iskeleti, hepsi hedefin geçen hafta yeni şablona taşıdığı bir alt kategoriden; 6 sayfa kesik gövde, koşunun aynı iki dakikasında.

Her satırın eylemi hazırdır. 41 kayıt kaldırılmış olarak işaretlenir ve ürün listesi güncellenir. 29 istek için ülke filtresi zorunlu hale getirilir. 12 sayfa için yeni şablonun imzası ve ayrıştırıcısı yazılır, o alt kategori bir sonraki koşuya kadar bekletilir. 6 sayfa üstel beklemeyle koşu içinde yeniden denenir ve büyük olasılıkla geçer. Rapordaki 88 boş fiyat dört ayrı nedene bölündüğünde dördünün de çözümü farklıdır ve ikisi sizin tarafınızda, biri hedefte, biri ağdadır.

Durum kodu 200 olan her yanıt doğrulamadan geçiyor; geçmeyen yanıt ayrıştırıcıya hiç gitmiyor. Her sayfa tipinin yazılı bir imzası var: zorunlu seçiciler, en az gövde boyutu, yasak ifadeler, son URL deseni, dil ve para birimi işareti, geçerli boş işareti. İmza ayrı dosyada ve başarılı ile boş örneklerden oluşan bir test setiyle sınanıyor. Doğrulama başarısızlığı sınıflara ayrılıyor ve her sınıfın yeniden deneme kararı ayrı. Her başarısız kayıt ülke filtresi, oturum kimliği ve ürün sınıfıyla birlikte saklanıyor. Koşu sırasında tutarlılık eşiği çalışıyor ve aşılınca koşu duruyor. Günlük rapor boş 200 oranını sınıf bazında gösteriyor. Doğrulama ara sayfası sınıfında eylem tempo, oturum ve ürün sınıfı kararıyla sınırlı.

Durum kodu 200, gövde dolu, seçiciler tutuyor ama veri yine yanlışsa? Bu içerik katmanının işidir: fiyat sayıya çevriliyor mu, sıfırdan büyük mü, para birimi beklenen mi, tarih ayrıştırılıyor mu. Bir de tutarlılık katmanı: aynı koşuda alanın değeri sayfaların çoğunda birden değiştiyse ayrıştırıcı yanlış öğeyi okuyor olabilir.

Doğrulama her isteği yavaşlatır mı? Taşıma ve yapı katmanları birkaç seçici sorgusu ve uzunluk karşılaştırmasıdır; ayrıştırmanın kendisinden ucuzdur. Pahalı olan, doğrulama olmadan bin sayfayı boş ayrıştırıp koşuyu baştan almaktır.

Yumuşak 404’ü gerçek sayfadan nasıl ayırırım? Hedefin kaldırılmış ürün sayfasını bir kez tarayıcıda açıp metnini imzanın yasak ifadeler listesine yazın; çoğu sitede bu sayfanın şablonu sabittir. Son URL çoğu zaman da değişir: ürün yolu yerine kategori ya da ana sayfaya yönlendirip 200 dönen hedefler yaygındır, son URL deseni bunu yakalar.

Doğrulama ara sayfasını geçmek için ne yapmalıyım? Geçmeye çalışmak yerine sayfayı tanıyıp sınıfına yazın, o hedefte tempoyu düşürün, oturumu değiştirin ve oranı ürün sınıfına göre karşılaştırın; hedefin kullanım şartlarına ve varsa resmî API’sine bakın.

Boş 200 oranı için bir eşik var mı? Sabit bir sayı yoktur; kendi tabanınızı ölçün. Birkaç koşu boyunca sınıf bazında oranları kaydedin, tutarlılık eşiğini tabanın birkaç katına kurun ve eşik aşıldığında koşuyu durdurup yukarıdaki beş istekli deneyi yapın.