Scrapy, JavaScript çalıştırmadığı için çoğu zaman “modern sitelerle baş edemez” diye etiketleniyor. Oysa bu bakış biraz ters köşe. Sayfayı render etmemesi aslında bütün yaklaşımın kendisi; çalışırken görünce, eksik bir özellikten çok bilinçli bir tasarım tercihi gibi duruyor.
Bunu tek bir test çalıştırmasında ben de doğruladım. JavaScript ile render edilen bir katalog örneği hazırladım, Scrapy’yi tarayıcının göstereceği sayfaya yönlendirdim ve karşılığında 0 ürün kartı aldım. Sonra aynı spider’ı, sayfanın arka planda sessizce çağırdığı JSON uç noktasına çevirdim ve 8/8 öğeyi tertemiz şekilde çektim. Aynı araç, aynı oturum, tamamen zıt sonuçlar — bu incelemenin tam merkezini de işte bu fark oluşturuyor.
Scrapy gerçekte nedir, nedir değildir?
Scrapy, siteleri taramak ve yapılandırılmış veriyi çekmek için kullanılan bir Python framework’üdür. Bu, geliştiricilerin kendi genel bakış dokümanlarında verdiği tanım ve gerçekten de denediğinizde bunun cuk oturduğunu görüyorsunuz — ortada düzeltilecek bir pazarlama abartısı yok. Python geliştiricisi “ciddi işler için ne kullanılır?” diye sorduğunda akla ilk gelen araçlardan biri olacak kadar köklü ve yerleşik; bunu repo verileri de destekliyor: 2026-07-07 itibarıyla yaklaşık 62.981 GitHub yıldızı, aynı tarihte 11.773 fork ve 590 açık issue. BSD-3-Clause lisansı, Python 3.10 veya üzeri ve benim testten geçirdiğim sürüm 2.17.0 idi; üstelik bu sürüm testleri yaptığım sabah yayımlanmıştı — yani bu incelemede “eski sürüm” diye bir dipnot yok.
Onu yeni nesil AI tabanlı crawler’lardan ayıran çizgi şu: Scrapy varsayılan olarak yalnızca HTTP ile çalışır. Tarayıcı yok. Render motoru yok. HTML’i ağ üzerinden indirir, bir parser’a verir ve alanları CSS seçiciler ya da XPath ile çekmenize izin verir. Buna sınırlama demek kısmen doğru olur ama tasarım mantığını kaçırmış olursunuz. Scrapy’nin temel varsayımı, basit bir veri çekimi için headless Chrome açmanın çoğu zaman yanlış tercih olduğu; daha akıllıca yolun, sayfanın zaten yaptığı veri isteğini bulup doğrudan ona gitmek olduğudur.
Bu, benim aracı kafama göre yorumlamam değil. Resmî dinamik içerik dokümanları bunu açıkça söylüyor: Önce alttaki veri isteğini bulun ve yeniden oluşturun; bunu yapmak pratik değilse ancak o zaman headless tarayıcıya başvurun. Çoğu scraper önce tarayıcıyı açar ve API’yi düşünmez bile. Scrapy ise varsayılan yaklaşımı tersine çeviriyor.
Temel özellikler ve her birinin arkasındaki tasarım tercihi
Scrapy’nin içinde her parça sizden tek bir şey bekliyor: kodla kontrol isteyen, tek tıkla çalışan bir sihirbaz aramayan bir geliştirici olmanız.
Spider’lar. Bir sınıf yazarsınız, başlangıç URL’lerini verirsiniz ve öğe döndüren ya da daha fazla bağlantıyı takip eden bir parse callback’i tanımlarsınız. Bu, kodsuz bir çıkarıcıya göre daha çok emek demek — çıkarım kurallarını sizin yazmanız gerekir — ama karşılığında neyin alınacağını ve taramanın nereye gideceğini nokta atışı kontrol edersiniz.
Seçiciler. Ayrıştırma katmanı, temelde lxml üzerine kurulu olan parsel ile çalışır. CSS ve XPath ikisi de birinci sınıf yurttaştır; sonradan eklenmiş eklentiler değillerdir. lxml desteği, seçimin hızlı kalmasını ve çıkarım kodunun karmaşık string kesmelerinden ziyade niyeti anlatır gibi okunmasını sağlar.
Feed export’ları. Bir spider’ı bir dosyaya yönlendirin; Scrapy öğelerinizi ekstra bir altyapı kurmadan JSON, JSON Lines, CSV veya XML olarak serileştirir. Benim denememde, tek bir statik katalog spider’ı hiç export kodu yazmadan hem JSON hem CSV üretti — feed export özelliği gerçekten var ve sözünü tutuyor.
AutoThrottle ve tarama kontrolleri. İstekler Twisted üzerinde asenkron olarak planlanır; concurrency sınırları, indirme gecikmeleri, derinlik kısıtları, uyarlamalı hız sınırlama için AutoThrottle ve robots.txt uyumu elinizin altındadır. Bunlar, geniş kapsamlı bir taramanın sunucuya yük bindiren bir olaya dönüşmesini engelleyen kontrollere dönüşür.
HTTP-only yaklaşımını bir özellik olarak yeniden okumak. Tarayıcı olmaması; düşük bellek kullanımı, yüksek işlem hacmi ve bakım gerektiren bir render motorunun olmaması anlamına gelir — tabii istediğiniz veri düz HTTP üzerinden erişilebiliyorsa. Ve tarayıcı-öncelikli yaklaşımın sandığınızdan çok daha sık, bu gerçekten mümkündür.
Kurulum: kimsenin ekran görüntüsü almadığı bağımlılık yığını
Kurulum sorunsuz geçti; bu kadar büyük bir framework için bunu özellikle söylemek gerekir. pip install Scrapy==2.17.0, macOS arm64 üzerinde yeni bir sanal ortamda, binary wheel’leri çekerek ve herhangi bir derleme hatası olmadan tamamlandı. Dramatik bir şey yaşanmadı — ve zaten amaç da buydu.
Ama indirdiği bağımlılıklara bakınca tablo netleşiyor. scrapy version -v, Scrapy 2.17.0’ın lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 ve cryptography 49.0.0 üzerinde çalıştığını; yanına parsel, cssselect ve tldextract’i de eklediğini gösterdi. Bu ciddi bir ayak izi — tek dosyalık bir HTML ayrıştırıcı değil, başlı başına bir crawling framework’ü. Benim makinada hepsinin wheel’leri hazırdı ve kurulum zahmetsizdi. Farklı ortamlarda ise resmî dokümanlar hâlâ platforma özgü bağımlılık sürtünmelerine dikkat çekiyor. Tarihsel olarak en çok sorun çıkaran katmanlar cryptography ve Twisted tarafı olduğu için, sıra dışı bir sistem kullanıyorsanız bunu hesaba katın. Burada kurulum rahattı; yine de ne kadar şey yüklendiğini bilmek önemli, çünkü bir framework indiriyorsunuz ve ağırlığı da tam framework ağırlığında oluyor.
Uygulamalı test: ne dayandı?
Kurulumdan sonra statik yol pürüzsüzdü. Tam geri çağırım, hiçbir şey düşmedi.
| Test | Sonuç | Çalışma Süresi |
|---|---|---|
| Yerel statik katalog + sayfalama | 12/12 ürün | 0.557s |
| Statik katalog CSV export | 12 satır yazıldı | (aynı çalışma) |
| Makale çıkarımı | başlık + 3/3 gövde paragrafı | 0.416s |
| Crawl grafiği, DEPTH_LIMIT=2 | 0/1/2 derinliklerinde 11 sayfa | 0.904s |
| Yerel 500 sayfası | durum 500 yakalandı, çökme yok | 0.424s |
| Books to Scrape (genel demo) | 20 ürün | 2.053s |
| Quotes to Scrape spider’ı (genel demo) | 12 alıntı öğesi | 3.465s |
Statik katalog spider’ı, birinci sayfadan ikinci sayfaya sayfalama akışını takip edip beklenen 12/12 kaydı aldı; ardından aynı çalıştırmada bunları JSON ve CSV olarak dışa aktardı. En dikkat çeken örnek makale örneğiydi. Scrapy, sayfayı otomatik olarak temizleyip düzgün bir Markdown’a dönüştürmeye çalışmadı; bunun yerine article alanlarını açık seçicilerle hedeflememe izin verdi ve nav ile footer metnini ayrı alanlara ayırdı. Böylece 3/3 gövde paragrafını aldım, kalıp metinler çıktıya bulaşmadı. Takas tam da bu: Seçicileri siz yazarsınız, araç size tam olarak istediğinizi verir; istemediğinizi değil.
Küçük ölçekte crawl kontrolü de sorunsuzdu. DEPTH_LIMIT=2, kısa bir indirme gecikmesi, alan başına concurrency ve robots.txt açıkken, crawl grafiği 0, 1 ve 2. derinliklerde toplam 11 sayfa gördü ve derinlik sayımı doğru işledi. Hata yönetimi de aynı derecede sakindi. Bilerek hazırladığım 500 sayfası, handle_httpstatus_list üzerinden status 500 bilgisi ortaya çıkan yapılandırılmış bir öğe olarak döndü — exception yok, süreç çökmesi yok. Scrapy, hata durumunu tüm crawl’ı aşağı çeken bir sürpriz değil, spider mantığının içinde ele almanız gereken bir durum olarak görüyor.
Uygulamalı test: JavaScript duvarı ve yanındaki kapı
Şimdi incelemenin asıl dayanağı olan sonuca gelelim.
Scrapy’nin HTTP fetcher’ını JavaScript ile render edilen bir katalog örneğine yönlendirdim. Kaynak HTML’i indirdi, 0 .product-card düğümü buldu ve yoluna devam etti — çünkü o kartları çizecek script’i hiç çalıştırmadı. Genel Quotes to Scrape JS sayfası da aynı şeyi söyledi: 0 render edilmiş quote düğümü. Testi burada bıraksanız, Scrapy’yi bu döneme uygun olmayan bir araç diye rafa kaldırırdınız.
Ama burada bırakmamak gerekiyor. O JS kataloğu arka planda, çoğu örnekte olduğu gibi bir JSON API tarafından besleniyordu. Aynı Scrapy spider’ını bu uç noktaya yönlendirdim ve 0.416s içinde 8/8 ürün aldım — tarayıcı yok, render yok; sadece sayfanın zaten çağırdığı URL’ye istek atıldı ve dönen JSON ayrıştırıldı.
Bu yan yana sonuçlar, isteği yeniden oluşturma felsefesinin küçük bir özeti. Render edilen sayfa bir yem; veri başından beri bir API’nin arkasındaydı ve Scrapy’nin tasarımı sizi, headless tarayıcıya sayfanın kendi kendini oluşturmasını izletmek yerine doğrudan o API’ye gitmeye yönlendiriyor. Daha hızlı, daha hafif ve daha az kırılgan — bir API sözleşmesine güvenmek, istemci tarafında şişen DOM yığınlarına güvenmekten daha sağlamdır. Eksi tarafı ise manuel oluşu. Ağ sekmesini açıp isteği bulmanız, başlıkları ve parametreleri kendiniz yeniden kurmanız gerekir. Scrapy API’yi sizin yerinize keşfetmez; ama siz bulduğunuz anda ona vurmayı inanılmaz kolaylaştırır.
Burada açıkça söylenmesi gereken iki sınır var. Eğer gerçekten yeniden oluşturulacak alttaki bir istek yoksa — veri sadece istemci tarafı render ile üretiliyor ve arkada API bulunmuyorsa — Scrapy’ye ayrıca bağlayacağınız bir headless browser entegrasyonu gerekir; bu incelemede o yolu denemedim. Ayrıca yukarıdaki tüm testler küçük örnekler ve genel demo sayfaları üzerinde yapıldı. 100 ila 1.000 sayfalık bir crawl çalıştırmadım; dolayısıyla bellek, throughput ya da retry davranışı hakkında ölçek düzeyinde bir iddiada bulunmuyorum — asenkron çekirdek ve crawl kontrolleri güçlü sinyaller veriyor, ama sinyal ölçüm değildir.
Artılar ve eksiler
Artılar:
- HTTP-only tasarım hızlı ve hafif — statikte 12/12 geri çağırım yaklaşık yarım saniyede, JSON API üzerinden 8/8 sonuç 0.416s’de, sıfır tarayıcı yükü.
- İsteği yeniden oluşturma yaklaşımı gerçekten işe yarıyor: 0 sonuç dönen bir JS sayfası, arka plandaki API’den 8 öğenin tamamını verdi.
lxmltabanlı CSS ve XPath seçiciler, çıkarım kodunu hem okunur hem hızlı tutuyor.- JSON/CSV/XML’ye feed export, ekstra export altyapısı yazmadan çalışıyor.
- Açık hata yönetimi — 500 bir çökme değil, yakalanabilir bir durum olarak geri dönüyor.
- Olgun crawl kontrolleri: concurrency, gecikmeler, derinlik sınırları, AutoThrottle, robots.txt.
- BSD-3-Clause lisansı; güncel bir makinada temiz kurulum.
Eksiler:
- Tasarım gereği JavaScript render etmez — istemci tarafı render edilen sayfalarda, API’yi siz bulana kadar 0 düğüm görebilirsiniz.
- Alttaki isteği bulmak manuel iştir; Scrapy sizi uç noktaya yönlendirmez.
- Bağımlılık yığını epey büyük (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — burada sorunsuzdu ama alışılmadık platformlarda tarihsel olarak sürtünme noktası olabilir.
- Kodsuz ya da otomatik çıkarım araçlarına göre daha fazla kod ister; spider’ları yazmak ve sürdürmek size kalır.
- Testlerim küçük örnekler ve demo siteleriyle sınırlıydı, büyük crawl’larla değil — ölçek güvenilirliği bu çalışmada kanıtlanmadı.
Kimler için uygun, kimler geçmeli?
Scrapy, kontrolü kod seviyesinde isteyen ve sayfalardan çok istekler üzerinden düşünen geliştiriciler içindir. Yavaş bir JavaScript sitesi gördüğünüzde aklınıza ilk gelen şey “burada bir API olmalı” ise, bu araç tam o sezgi için tasarlanmıştır. Seçiciler yazmaya, ağ sekmesini okumaya ve çıkarım mantığını uçtan uca sahiplenmeye rahat olan insanları ödüllendirir. Statik siteler, sayfalı kataloglar ve keşfedilebilir JSON uç noktalarıyla beslenen her şey için hızlı ve nettir.
Spider kodu yazmak ve bakımını yapmak zamanınızı harcamak istediğiniz bir iş değilse, ya da hedefleriniz veriyi tamamen istemci tarafında render ediyor ve arkalarında yeniden üretilebilir bir istek bulunmuyorsa, en azından bunu başka bir araçla birlikte kullanmayı düşünün. Eğer hayaliniz bir URL’ye araç yöneltip çıkarım kuralları yazmadan tertemiz yapılandırılmış çıktı almaksa, bu Scrapy’nin görevi hiç olmadı ve hiçbir zaman da bunu iddia etmedi.
Alternatifler ve Thunderbit’in konumu
Web Verisi Çıkarma için Thunderbit’i Deneyin
Neye imza attığınızı baştan netleştirmek gerekir: Kendi çalıştırdığınız ve bakımını yaptığınız ücretsiz, açık kaynak bir framework. Spider’lar, bağımlılık yığını ve her sitenin veri isteğini bulma işi size aittir. Karşılığında istek başına ücret ödemezsiniz, her şeyi kurum içinde tutarsınız ve tam kontrol elde edersiniz. Pek çok ekip için bu doğru tercihtir; bu inceleme de kimseyi bundan vazgeçirmeye çalışmıyor.
Takasın asıl kısmı render ve drift probleminde ortaya çıkar; Scrapy’nin cevabı ise bunu sizin çözmenizdir: API’yi bulursunuz, isteği yeniden oluşturursunuz ve API olmayan durumlarda tarayıcıyı kendiniz eklersiniz. Yönetilen bir AI scraping API ise bu katmanı omuzlarınızdan alır. Teknik okurlar için Thunderbit’in geliştirici yığını tam burada konumlanıyor — satış veya operasyon tarafının kullandığı tarayıcı eklentisi değil, bir AI scraping API + MCP server + CLI kombinasyonu. POST /distill, bir sayfayı temiz ve LLM’ye hazır Markdown’a dönüştürür; POST /extract, sizin tanımladığınız şemaya göre yapılandırılmış JSON döndürür; ikisi de JavaScript render’ını, anti-bot önlemlerini ve dinamik içeriği sunucu tarafında yönetir — Scrapy’nin tarayıcı kullanmanızı beklediği istemci tarafı render senaryosu da buna dahildir. AI ajanları ve kodlama asistanları için bir MCP server bulunur (sayfayı harcamadan önce kapsamı belirlemek için ücretsiz thunderbit_suggest_fields ile), ayrıca terminal, CI veya cron işleri için npx @thunderbit/thunderbit-cli üzerinden bir CLI vardır.
Fark kalite değil, sahiplik meselesidir. Scrapy, açıkça mühendislik odaklı bir framework’tür: spider’ı, pipeline’ı ve JavaScript stratejisini siz yönetirsiniz; karşılığında çağrı başı sıfır maliyetle tam kontrol alırsınız. Thunderbit’in yığını ise render ve çıkarım katmanını yönetilen bir hizmet olarak devralır; böylece ağ sekmesinde iz sürmekten kurtulursunuz ve bunun yerine çağrı başına ödeme yaparsınız. Küçük, kod-öncelikli ve her adımın sahibi olmak size uygunsa, Scrapy’nin kontrol modeli daha iyi uyar. Yüzlerce siteye ölçeklenmek istiyor ve her site için istekleri tek tek yeniden üretmek istemiyorsanız, yönetilen yol bu iş yükünün tamamını ortadan kaldırır.
Daha geniş kıyaslar için şu incelemelere de göz atabilirsiniz: tam açık kaynak scraper karşılaştırması, Colly’nin tarayıcısız Go crawler incelemesi ve Scrapling’in uyarlamalı seçici incelemesi.
Son karar
Scrapy kullanılmalı mı? Evet — eğer kontrol isteyen bir geliştiriciyseniz ve şu bakış açısını benimsiyorsanız: sayfayı render etme, onun arkasındaki isteği bul. Testlerde bu yaklaşım vaat edildiği gibi karşılığını verdi. JavaScript kataloğu HTTP fetcher’a 0 kart verdi; onu besleyen JSON API ise aynı spider’a 8 öğenin tamamını sundu. Statik çıkarım 12/12 başarıya ulaştı, makale seçicileri 3/3 paragrafı kalıp metinlerden temiz tuttu, crawl grafiği 11 sayfalık akışta derinlik sınırına uydu ve 500, çökme yerine işlenmiş bir durum olarak geri döndü.
Yine de iddiaları doğru ölçmek gerekir. Scrapy JavaScript render etmez ve API’yi sizin yerinize bulmaz — bu refleksi kendiniz geliştirmeniz gerekir. Bağımlılık yığını bir framework’ün ağırlığını taşır ve burada temiz çalışsa da alışılmadık platformlarda sorun çıkarabilir. Ayrıca bin sayfalık bir crawl değil, örnekler ve demo sayfaları test ettim; bu yüzden ölçek hikâyesini umut verici ama henüz kanıtlanmamış olarak değerlendirin. Bu sınırlar içinde Scrapy, sessizce radikal bir fikre en sıkı şekilde bağlı kalan araçtır: Bir web sayfasını geçmenin en hızlı yolu çoğu zaman web sayfasının içinden geçmek değildir.
Web Verisi Çıkarma için Thunderbit’i Deneyin Get Started Free
SSS
Scrapy JavaScript ile render edilen sayfaları çekebilir mi? Varsayılan HTTP fetcher ile hayır — hem bir JS örneğinde hem de herkese açık Quotes JS sayfasında 0 düğüm döndürdü; çünkü bir tarayıcı çalıştırmadan yalnızca HTML indiriyor. Tasarlanan yol, sayfanın çağırdığı alttaki veri isteğini bulup doğrudan ona gitmektir; benim testimde, bir JS kataloğunun arkasındaki JSON API tüm 8 öğeyi verdi. Yeniden üretilebilir bir istek olmayan sayfalarda ise headless browser’ı kendiniz eklersiniz.
“İsteği yeniden üretmek” tam olarak ne demek? Çoğu dinamik sayfa, veriyi arka planda bir JSON API’den çeker, sonra bunu istemci tarafında render eder. Bunun gerçekleşmesini izlemek için tarayıcı çalıştırmak yerine ağ sekmesini açar, o API çağrısını bulur ve Scrapy’yi doğrudan ona yönlendirirsiniz. Bu yöntem render etmeye göre daha hızlı ve daha stabildir — bir API sözleşmesi DOM’a göre daha az bozulur — ama manuel iştir ve Scrapy uç noktayı sizin yerinize bulmaz.
Scrapy’nin kurulumu zor mu?
Benim için sorunsuzdu — pip install Scrapy==2.17.0, yeni bir venv içinde ve binary wheel’lerle derleme hatası olmadan tamamlandı. Ancak büyük bir yığınla gelir (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) ve resmî dokümanlar bazı sistemlerde platforma özgü bağımlılık sürtünmelerine dikkat çekmeye devam ediyor; sıra dışı bir ortam kullanıyorsanız bunu hesaba katın.
Scrapy hangi çıktı formatlarını destekliyor? Feed export’lar kutudan çıktığı haliyle JSON, JSON Lines, CSV ve XML sunar — spider’ı bir dosyaya yönlendirin, öğeleri ekstra kod yazmadan serileştirir. Benim çalışmamda bir spider tek geçişte hem JSON hem CSV üretti. Ancak seçtiğiniz alanları dışa aktarır; sayfayı otomatik olarak Markdown’a temizlemez.
Scrapy ticari kullanım için ücretsiz mi? Evet, BSD-3-Clause lisansına sahip; bu da esnek ve ticari kullanıma uygun bir lisans demektir. Her zamanki gibi, üzerine bir şey inşa etmeden önce repo üzerindeki güncel lisansı doğrulayın ve user-agent, proxy ve rate-limit tercihlerinizde sorumlu davranın — bir şeye gücünüz yetmesi, onu kullanma izniniz olduğu anlamına gelmez.
