Adaptif seçicilerin kredisi çoğu zaman yanlış araçlara yazılıyor. Okuduğum scraper karşılaştırmalarının yarısında, "bir site tasarımı değişse de ayakta kalır" iddiası, bunu gerçekte yapmayan büyük bir AI crawler’a atfediliyor. Bu özelliği açıkça öne çıkaran Python kütüphanesi ise Scrapling. 2026-07-09 itibarıyla yaklaşık 68,7 bin GitHub yıldızına ulaşmış, hızla büyüyen bir proje.
Bu yüzden, böyle bir iddianın gerçekten ne kadar doğru olduğunu görmek için tek anlamlı testi yaptım. Bir örnek sayfa kurdum, bir seçiciyi kaydettim, ardından hedef öğenin class adını değiştirdim — yani bir sitenin yenilenmesinden sonraki sabah bir scraper’ı sessizce boş döndüren tam o senaryo. Düz bir seçici boş sonuç verdi. Scrapling’in adaptif eşleştirmesi ise öğeyi yine buldu. Bu kısım gerçek, rakamları da göstereceğim. Ancak neredeyse kimsenin ölçmediği asıl konu, bu toparlanmanın nerede durduğu. Aslında tüm incelemenin omurgası da tam olarak bu sınır.
Scrapling aslında nedir?
Scrapling kendini, "tek bir istekten tam ölçekli bir taramaya kadar her şeyi" yönetebilen adaptif bir web scraping framework’ü olarak tanımlıyor. Etiketi bir kenara bırakırsak, iki katmandan oluşuyor: sayfaları çeken bir HTTP Fetcher ve bunları ayrıştıran, lxml tabanlı bir Selector. CSS/XPath desteği ve kullanışlı ::text / ::attr() pseudo-seçicileri de var. BSD-3-Clause lisansıyla geliyor; yani açık kaynak dünyasındaki en esnek lisanslardan biri. Ben 0.4.10 sürümünü test ettim; o tarihteki güncel sürümdü, dolayısıyla "eski bir sürümü benchmark etmişsin" diye bir dipnot düşmeye gerek yok.
Asıl ilginç katman, bu ayrıştırıcının üstüne eklenen adaptif bölüm. Normal bir seçicinin nasıl çalıştığını düşünün: sabitlenmiş bir sokak adresi gibi. "product-name class’ına sahip öğeyi al." Binayı yeniden numaralandırın — yani class adını değiştirin — adres boş bir arsayı göstermeye başlar. Scrapling ise bir çalıştırmada öğenin parmak izini kaydedip, sonraki çalıştırmada markup değişmiş olsa bile o öğeyi artık geçersiz olmuş adresiyle değil, parmak iziyle yeniden bulabiliyor. Scrapling adaptive scraping dokümantasyonuna göre eşleştirme aşaması; öğenin tag’ı, metni, öznitelikleri, kardeş öğeleri ve konumu arasında benzerlik puanlıyor — arada bir model yok, sadece kaydedilen yapıya karşı yapısal karşılaştırma yapılıyor.
Burada köken konusunda açık olmakta fayda var; çünkü özelliği nasıl yorumlamanız gerektiğini değiştiriyor. Adaptif yeniden bulma gerçekten var olan, belgelenmiş bir yetenek; benim keşfettiğim bir şey değil. Satıcı dokümanları, kaydetme ve SQLite’a yazma ile benzerliğe göre eşleştirme mekanizmasını baştan sona anlatıyor; bağımsız üçüncü taraf yazılar da bunu adım adım gösteriyor. Kendi kendini onaran seçiciler fikri de Scrapling’den çok önce test otomasyonu dünyasında vardı. Fark yaratan şey, Scrapling’in bunu yerleşik bir kütüphane özelliği olarak sunması: lxml, parsel ve BeautifulSoup gibi düz ayrıştırıcılar size statik seçiciler verir, ama kendi kendine yer değiştiren bir mekanizma vermez. Yani bu, tekrarlayıp doğruladığım ve stres testinden geçirdiğim ayırt edici ama belgeli bir özellik; kimsenin daha önce sahip olmadığı bir şey değil.
Adaptif testin ayrıntısı
Kurulum şöyleydi. Bir örnek katalog ayağa kaldırdım ve bir ürün öğesini class adı product-name iken izlemeye aldım. Sonra bu class’ı product-title olarak değiştirdim ve aynı kodu yeniden çalıştırdım. Sıradan bir .product-name seçicisi 0 öğe döndürdü — yani artık var olmayan bir class’a bakınca alacağınız o beklenen boş sonuç. Scrapling’in adaptif yeniden eşleştirmesi ise önceki sürümde kaydettiği parmak izini kullanarak izlenen öğeyi geri getirdi. Ham sonuç benchmark deposunda local_adaptive_selector.json içinde yer alıyor.
Web Veri Çekmek için Thunderbit’i Deneyin
Şimdi çoğu incelemenin atladığı kısma gelelim. Bunu sentetik, çok öğeli bir testle biraz daha ileri götürdüm — tek bir öğe yerine üç izlenen öğe vardı. Scrapling üçünden ilk kaydedilmiş olanı yeniden buldu, ama üçünün hepsini değil. Bu bir başarısızlık ya da hata değil; dokümanlar auto-match’i öğe takibi olarak tanımlıyor, kaydedilen her öğe için ayrı bir parmak izi kullanıyor. Bu yüzden varsayılan ayarlarda 3’te 1 sonucu, özelliğin tam da tasarlandığı gibi çalıştığı anlamına geliyor. Ama bu aynı zamanda doğru tanımın "tüm yeniden tasarlanmış sayfayı otomatik kurtarma" değil, "dayanıklı öğe takibi" olduğunu da gösteriyor. Auto-match, takip etmesini söylediğiniz öğeyi takip ediyor. Çok öğeli dayanıklılık ise sizin ayrıca ayarladığınız bir konu.
Bu ayrım, ilk bakışta göründüğünden daha önemli. "Markup değişse de hayatta kalır" bir manşet. "Markup değişiklikleri boyunca tek bir parmak izi alınmış öğeyi izlemeye devam eder, gerisini siz yönetirsiniz" ise gerçekten satın aldığınız kabiliyet. İlkini bekleyerek girerseniz hayal kırıklığı yaşarsınız. İkincisini bekleyerek girerseniz gayet iyi iş çıkarır.
Kurulum: kimsenin uyarmadığı sürtünme
Bu kısım bana gerçek zaman kaybettirdi, o yüzden siz ona takılmadan önce bilin. pip install scrapling yalnızca ayrıştırıcıyı kuruyor — ve sadece onu. from scrapling.fetchers import Fetcher yazdığım anda, eksik bağımlılıklar zinciri yüzünden hata aldım: önce curl_cffi, sonra playwright, sonra browserforge; her biri ancak bir öncekini çözdükten sonra ortaya çıktı.
Çözüm, ekstra paketi kurmak: pip install "scrapling[fetchers]" ya da tam HTTP + tarayıcı fetcher yığınını çeken scrapling install CLI adımını çalıştırmak. Bundan sonra her şey çalıştı. Ama temel kurulumun sorunsuz görünüp ilk fetch çağrısında patlaması gerçek bir durum ve bunu baştan söyleyen pek yok. İlk komuttan itibaren [fetchers] ekstrasını ve ağır transitif bağımlılıklarını hesaba katarsanız bu detour’un tamamını atlamış olursunuz.
Düz HTTP çıkarımda ne kadar sağlam?
Fetcher’lar yerli yerine oturduğunda, sıradan çıkarım yolu gayet sağlamdı — recall değeri her testte 1.0:
| Test | Sonuç |
|---|---|
| Statik katalog + sayfalama | 12/12 ürün |
| Makale çıkarımı | başlık + 3/3 paragraf |
| Dinamik JSON API | 8/8 öğe |
| Books to Scrape (public) | 20 ürün |
| HTTP 500 işlemesi | durum açıkça gösterildi, çökme yok |
Burada lxml tabanının etkisi net şekilde hissediliyor. CSS ve XPath beklendiği gibi davranıyor; ::text ve ::attr() pseudo-seçicileri de çıkarım kodunu iç içe fonksiyon yığınlarına dönüştürmeden kısa ve okunabilir tutuyor. 500 senaryosu küçük ama öğretici: Fetcher, stack trace fırlatmak yerine HTTP durum kodunu gösterdi. Bu, bir scraper’ı zamanlanmış görev olarak çalıştırabilmek ile onu sürekli başında beklemek zorunda kalmak arasındaki fark. Tüm sayılar scrapling-test-summary.json içinde.
Bunların hiçbiri göz alıcı değil. Sadece doğru. Doğru olmak da yeterince kıymet görmüyor.
Tasarım gereği yapmadıkları
HTTP Fetcher JavaScript çalıştırmaz. Onu JS ile render edilen bir örnek sayfaya yönelttim ve 0 kart aldım; aynı sonuç, herkese açık Quotes to Scrape JS sayfasında da oldu. Bu bir kusur değil — HTTP Fetcher HTML indirir, tarayıcı çalıştırmaz; dolayısıyla istemci tarafında render edilen içerik orada görünmez. Scrapling, JS sayfalar için ayrı bir DynamicFetcher (tarayıcı destekli) sunuyor. Bu testte onu kullanmadım, o yüzden performansı hakkında yorum yapmayacağım. Sadece HTTP yolunu istemci tarafında render edilen bir uygulamaya doğrultup içeriğin orada olmasını beklemeyin.
Bir de anti-detection odaklı StealthyFetcher var. Ben bunu açıkça bir uyumluluk / mevzuat konusu olarak görüyorum; öne çıkarılacak bir özellik olarak değil. Nerede ve nasıl scrape yapmanıza izin verildiği sizin sorumluluğunuzda ve hukuki zemininize bağlı. Bu inceleme ise kaçınma değil, çıkarım kabiliyetini test ediyor. Onu çalıştırmadım ve puanlamıyorum.
Artılar ve eksiler
Artılar:
- Adaptif seçiciler, düz bir seçicide 0 veren class değişikliğinden sonra izlenen öğeyi gerçekten geri getirdi — Scrapling’e yönelmenin ayırt edici nedeni.
- Statik sayfalarda, makalelerde ve JSON API’lerde recall 1.0 düzeyinde HTTP çıkarımı.
- Okunabilir
::text/::attr()pseudo-seçicileriyle temiz lxml tabanlı CSS/XPath. - HTTP 500’i çökmeden, durumu göstererek düzgün ele alması.
- Test edilen sürüm en güncel sürümdü; sürüm kayması yok.
- BSD-3-Clause lisansı, ticari kullanım açısından oldukça esnek.
Eksiler:
- Auto-match tüm sayfayı değil, tek bir kaydedilmiş öğeyi takip ediyor; üç öğeli test birini kurtardı. İddianızı buna göre kurun.
pip install scraplingyalnızca parser kuruyor; fetcher’lar için[fetchers]ekstrası ve ağır bağımlılık zinciri gerekiyor, bunu acı şekilde öğrendim.- HTTP Fetcher JavaScript render etmez; istemci tarafı içerik için tarayıcı destekli
DynamicFetchergerekir, bu incelemede test edilmedi. - Manşet özelliğin çok öğeli senaryolarda manuel ayar gerektirmesi gerekiyor.
Kimler için uygun, kimler uzak durmalı?
Scrapling, sık yeniden tasarlanan sitelerle çalışan scraper’ları yönetiyorsanız ve tek bir class değişikliğinin çıkarımınızı sessizce bozmasından yorulduysanız gerçekten yerini hak ediyor. En büyük sorununuz "seçicilerim birkaç haftada bir bozuluyor, ben de sadece ilgilendiğim öğe yeniden bulunsun istiyorum" ise, tam size göre. Adaptif katmanı hiç açmasanız bile statik sayfalar ve JSON API’ler için temiz, hafif bir lxml çıkarıcısı olarak iş görüyor.
Ama iki durumda beklentinizi sıfırlayın ya da başka yere bakın. Adaptif seçicilerin yeniden tasarlanmış bir sayfanın tamamını otomatik onaracağını umuyorsanız — bunlar öğeleri takip eder, layout’u yeniden kurmaz — zihinsel modelinizi değiştirmeniz gerekir. Hedefleriniz JavaScript ağırlıklıysa ve tarayıcı destekli DynamicFetcher’ı kurmak istemiyorsanız, yalnızca HTTP yolu sizi hedefe götürmez. Her iki durumda da kurulum yapacaksanız, [fetchers] ekstrasını en başta ekleyin.
Yönetilen bir AI scraping API’si nerede devreye girer?
Scrapling, sizin çalıştırıp bakımını üstlendiğiniz ücretsiz, açık kaynak bir kütüphane. Kodu, bağımlılık zincirini ve ince ayarı siz sahiplenirsiniz; karşılığında istek başına ücret ödemezsiniz ve her şeyi kurum içinde tutarsınız. Bu, tamamen savunulabilir bir tercih ve birçok ekip için doğru olan da bu.
Sormaya değer asıl soru şu: dayanıklılık problemini kim sahipleniyor? Scrapling’in cevabı, bunun size ait olduğu; öğeleri fingerprint edip takibi sizin ayarladığınız yönünde. Yönetilen bir AI scraping API’si ise farklı cevap verir — markup değişikliğini karşılama işi sunucu tarafına taşınır. Teknik ekipler için Thunderbit'in developer stack’i tam bu noktaya yerleşiyor. POST /extract, sizin tanımladığınız JSON Schema’ya göre yapılandırılmış JSON döndürür; render, anti-bot ve markup drift’i sunucu tarafında emilir. renderMode bayrağı da çıkarımdan önce sayfanın ne kadarının çalıştırılacağını kontrol eder. AI ajanları ve kodlama asistanları için Thunderbit MCP server da mevcut — thunderbit_suggest_fields ücretsizdir ve önce çalışarak çıkarımı planlar. Terminal, script ve CI için de npx @thunderbit/thunderbit-cli üzerinden bir CLI var. Üç yüzeyin de arkasında aynı AI motoru çalışıyor.
Gerçek ödün şu: hangisi daha iyi, hangisi daha kötü değil; dayanıklılık mantığının nerede yaşamasını istediğiniz. Scrapling ile bunu kendi kodunuzda tutarsınız; fingerprint’lenmiş ve sizin ayarladığınız şekilde, çağrı başına sıfır maliyetle. Ama bunun bakımını da üstlenirsiniz. Yönetilen API’de ise drift-handling’i devredersiniz ve istek başına ödeme yaparsınız. Küçük ölçekte, self-hosted ve ayarı sahiplenmeyi seviyorsanız? Scrapling’in kontrol modeli doğru cevap. Yüzlerce siteye yayılıyorsanız ve her birinde selector fingerprint’lerini tek tek kollamak istemiyorsanız? Yönetilen yaklaşım bu bakım yükünü ortadan kaldırır.
Alanı karşılaştırıyorsanız, tam açık kaynak scraper benchmark’ı Scrapling’i diğerleriyle aynı örneklerde yan yana koyuyor; Scrapy incelemesi ve Colly incelemesi de HTTP öncelikli iki başka framework’e bakmak için iyi bir başlangıç.
Son karar
Scrapling’i kullanmalı mısınız? Evet — eğer açık kaynak bir Python çıkarıcısı istiyorsanız ve onun öne çıkan hilesi, altındaki markup değişse bile izlenen öğeyi bulmaya devam etmesi ise. Normal bir scraper’ın verisini sessizce kaybettirecek bir class değişikliğinde, bozulmuş bir seçicinin bulamadığı öğeyi geri getirdi. Düz HTTP çıkarımı temizdi ve her örnekte tam recall sağladı. Lisans esnek ve test ettiğim sürüm günceldi.
Sadece iddiayı doğru boyutlandırırsanız memnun kalırsınız. Öğeleri takip eder, sayfaları otomatik yeniden kurmaz — üç öğeli test birini kurtardı. [fetchers] ekstrasını en başta kurmazsanız benim girdiğim bağımlılık duvarına siz de çarparsınız. Sayfalarınız JavaScript gerektiriyorsa, bu iş HTTP Fetcher’ın değil, tarayıcı destekli fetcher’ın alanı. Bu sınırlar içinde Scrapling, bilinen işi tam da gerektiği gibi yapıyor; Python scraping kütüphaneleri arasında da herkesin ona yakıştırdığı ama nadiren gerçekten sunduğu özelliği gerçekten getiren araç o.
Web Veri Çekmek için Thunderbit’i Deneyin Get Started Free
SSS
Scrapling’in adaptif seçicileri gerçekten bir web sitesi yeniden tasarlanmasını atlatır mı?
İzlenen bir öğe için class değişikliğini atlatırlar — testte doğrulandı. product-name class’ını product-title olarak değiştirdikten sonra, düz bir seçici 0 sonuç verirken adaptif yeniden eşleştirme izlenen öğeyi kurtardı. Ancak bunlar kaydedilmiş öğeleri takip eder; tüm sayfayı yeniden inşa etmez. Üç öğeli sentetik testte bir öğe kurtarıldı. Bu özelliği tam sayfa otomatik kurtarma değil, dayanıklı öğe takibi olarak düşünün.
Neden pip install scrapling komutundan sonra fetcher import edince hata alıyorum?
Çünkü temel kurulum yalnızca parser’ı içeriyor. scrapling.fetchers import etmek, curl_cffi, ardından playwright, ardından browserforge olmak üzere eksik bağımlılık zincirini tetikliyor. Tam fetcher yığınını çekmek için pip install "scrapling[fetchers]" komutunu ya da scrapling install CLI’sini kullanın; import sorunsuz çalışır.
Scrapling JavaScript ile render edilen sayfaları scrape edebilir mi?
HTTP Fetcher ile değil — hem JS örnek sayfada hem de herkese açık Quotes JS sayfasında 0 döndürdü; çünkü tarayıcı çalıştırmadan HTML indiriyor. Scrapling, JS sayfalar için ayrı bir tarayıcı destekli DynamicFetcher sunuyor; bu testte onu kapsam dışı bıraktım, dolayısıyla performansı hakkında henüz yorum yapamam.
Scrapling normal çıkarım için hızlı ve doğru mu? Testlerde doğruydu — statik kataloglarda, makale sayfalarında ve JSON API’lerde recall 1.0; ayrıca lxml tabanlı CSS/XPath de temiz çalıştı. HTTP 500 durumunu da çökmeden, durumu yüzeye taşıyarak ele aldı. Adaptif katmana hiç dokunmasanız bile statik içerik için sağlam ve hafif bir çıkarıcı.
Scrapling ticari kullanım için ücretsiz mi? BSD-3-Clause lisanslı; yani esnek ve ticari kullanım açısından dostça. Yine de üzerine inşa etmeden önce repo üzerindeki güncel lisansı mutlaka doğrulayın.
