Çoğu kişi Crawlee ile, aslında bambaşka bir soruya yanıt ararken tanışıyor: “Hangi headless browser’ı kullanmalıyım?” Aslında bu yanlış soru; Crawlee’nin varlık nedeni de tam olarak bu. Crawlee bir tarayıcı değil. İhtiyaç duyduğunuzda bir tarayıcıyı sarmalayan, gerekmediğinde ise onu tamamen devre dışı bırakabilen Node/TypeScript tabanlı bir framework.
Ben de birkaç gün boyunca Crawlee 3.17.0’ı, kontrollü bir fixture seti ve birkaç herkese açık demo site üzerinde, Node v22.22.3 ve macOS ortamında test ettim. Ana vaat — tek bir kütüphane, tek bir API, altında ister HTTP crawler ister gerçek bir browser — en çok sınamak istediğim şeydi. Çünkü Crawlee’nin teknoloji yığınınıza eklemeye değer olup olmadığını ya da doğrudan Playwright kullanmanın daha mantıklı olup olmadığını belirleyen asıl iddia bu. Kısa cevap: iki motorlu yaklaşım gerçekten çalışıyor; ama birazdan değineceğim birkaç not düşmek gerekiyor.
Crawlee Aslında Nedir, Nedir Değildir?
Crawlee kendini Node.js için geliştirilmiş, güvenilir crawler’lar oluşturmayı kolaylaştıran bir web scraping ve browser otomasyon kütüphanesi olarak tanımlıyor. Resmî konumlandırması oldukça geniş: AI, LLM, RAG veya GPT için veri çıkarmak; HTML, PDF, JPG, PNG ve diğer dosyaları indirmek; Puppeteer, Playwright, Cheerio, JSDOM ve ham HTTP ile çalışmak; headful ya da headless kullanım; proxy rotation desteği gibi birçok yetenek sunuyor. Alanı bu kadar geniş olunca, Crawlee’nin ne olmadığını söylemek daha da önemli hale geliyor.
Crawlee bir rendering motoru değildir. Kendi browser’ı yoktur. JavaScript çalıştırmanız gerektiğinde, Crawlee Playwright veya Puppeteer’ı kullanır; onlar da sırasıyla Chromium’u ya da başka bir tarayıcıyı kontrol eder. Ayrıca ağ üzerinden çağırdığınız barındırılan bir servis de değildir — kurup kendi ortamınızda çalıştırdığınız bir bağımlılıktır. Crawlee’nin tam olarak ne olduğu ise fetch katmanının üzerindeki o ara katmandır: crawler sınıfları, request queue, storage, link takip mantığı. Kısacası, altında takılabilir bir motor yuvası olan crawl framework’üdür.
Kayıt için söyleyeyim: test ettiğim sürüm 3.17.0’dı (yayın tarihi 2026-06-04), TypeScript ile yazılmış, lisansı Apache-2.0 ve depo 2026-07-09 itibarıyla apify/crawlee üzerinde yaklaşık 24,6k yıldız seviyesindeydi. Yıldız sayıları hareketlidir — ben izlerken iki günde 53 yıldız eklenmişti — bu yüzden bu sayıyı sabit bir gerçek değil, anlık bir görüntü olarak değerlendirin.
İki Motor: CheerioCrawler ve PlaywrightCrawler
Tasarımın gerçekten değer kazandığı yer tam da burası; ben de zamanımın çoğunu burada harcadım.
CheerioCrawler HTTP yoludur. Ham HTML’i ağ üzerinden çeker ve Cheerio ile ayrıştırır — tarayıcı yok, JavaScript çalıştırma yok, rendering yok. Hızlı ve ekonomiktir. PlaywrightCrawler ise browser yoludur. Gerçek Chromium’u açar, sayfayı JavaScript’in DOM’u oluşturduğu haliyle render eder ve hatta ekran görüntüsü bile alabilir.
İki farklı motor, gerçekten farklı yetenekler. Crawlee’nin söylemek istediği şey, bu motorların aynı kıyafetleri giydiği: İkisi de requestHandler alır. İkisi de run() metodunu sunar. İkisi de enqueueLinks ile bağlantıları tarar. Bir motordan diğerine geçmek bir sınıf değişimidir, yeniden yazım değil — ben de extraction mantığımı byte seviyesinde aynı tutup sadece etrafını saran crawler sınıfını değiştirerek bunu doğruladım.
Burada küçük ama önemli bir ayrımı net söylemek gerekiyor: içerik erişim noktası farklıdır. CheerioCrawler handler’ı içinde size jQuery benzeri sorgular yapabildiğiniz statik, önceden ayrıştırılmış bir DOM olan $ verilir. Browser handler’ı içinde ise canlı bir page nesnesi alırsınız. Yani kuyruk, yönlendirme ve “bu veriyi al, şu linkleri takip et” altyapısı aynı kalır; fakat sayfayı gerçekten okuduğunuz katman değişir. Crawlee’nin kendi dokümantasyonu da bunu açıkça söyler — ortak arayüzü crawl işlemleri için tanımlar, içerik erişimini ise farklılaşan kısım olarak belirtir.
| Motor | Nasıl çeker | JavaScript çalıştırır mı? | Benim testim (1 dinamik sayfa) | En uygun kullanım |
|---|---|---|---|---|
CheerioCrawler | Ham HTTP + Cheerio ayrıştırma | Hayır | ~0.035 sn | Statik HTML, JSON API’ler, hız |
PlaywrightCrawler | Playwright üzerinden gerçek Chromium | Evet | ~4.967 sn | JavaScript ile render edilen sayfalar, ekran görüntüsü |
Bu süreler tek bir makinede, tek bir çalıştırmadan alınmıştır — benchmark değil, yalnızca maliyet farkının yönünü gösteren bir örnek. Browser yolu aynı URL’de yaklaşık iki büyüklük mertebesi daha fazla zaman harcadı. Rendering’in bedeli budur; bu yüzden onu varsayılan tercih olarak seçmezsiniz.
Test: Aynı URL, 0’a Karşı 8/8
İddialar ucuzdur. İki motorlu yaklaşımın gerçekten çalıştığına, onu bozmayı deneyip sadece bir sınıf değiştirerek düzeltebildiğim için inanıyorum.
Yerel bir dinamik fixture oluşturdum — ürün kartlarının sayfa yüklendikten sonra JavaScript ile eklendiği bir katalog sayfası, modern web’in artık varsayılanı gibi davranan türden. CheerioCrawler’ı buna yönlendirdim. Sonuç: 0 ürün kartı. Bu bir bug değil; fizik. Cheerio JavaScript’i çalıştırmadığı için, parser’ın gördüğü HTML’de kartlar hiç oluşmadı. Ardından aynı URL’ye bu kez PlaywrightCrawler’ı gönderdim, başka hiçbir şeyi değiştirmedim ve bu kez 8/8 ürünü render edip kanıt olarak bir ekran görüntüsü aldı.
Bunun yalnızca kendi fixture’ıma özgü bir durum olmadığından emin olmak için aynı deseni herkese açık bir sitede de denedim — Quotes to Scrape JavaScript demo sayfası, alıntıları client-side oluşturan bir sayfa. Sonuç yine aynı yönde oldu: CheerioCrawler 0 alıntı gördü, PlaywrightCrawler ise 10 alıntıyı geri getirdi.
Burada neyi kanıtladığımı dikkatli ifade etmek isterim. Bu, Crawlee’nin zaten dokümante ettiği bir iddianın temiz bir yeniden üretimidir — framework, 3.0 sürümünden beri crawler türleri arasında aynı temel sınıfı ve arayüzü paylaşıyor. Yani bu keşif değil, doğrulama. Ama tam da bu yüzden değerli: “tek arayüz, HTTP ya da browser” söylemi gerçek; hem kontrol ettiğim fixture’da hem de kontrol etmediğim bir sitede 0’dan tam veriye geçişin somut kanıtı var.
HTTP Yolunun Kazandığı Noktalar
Yukarıdaki bölümün “o zaman hep browser kullan” şeklinde okunması kolay olur. Öyle yapmayın. İki motorlu tasarımın anlamı zaten browser’ın varsayılan değil, pahalı bir yedek olmasıdır.
Statik içerikte CheerioCrawler hem doğru hem de hızlıydı. Statik katalog fixture’ım, enqueueLinks({ selector: '.next-page' }) ile sayfalama takip edilerek, yaklaşık 0.155 saniyede 12/12 ürünü eksiksiz döndürdü. Bir makale sayfası ise başlığını ve 3/3 gövde paragrafını temiz bir şekilde verirken, login/abonelik/telif hakkı kalıplarını içerikten ayrıştırdı.
Özellikle akılda tutulması gereken örnek şu: JavaScript ile yüklenen bir sayfanın verisi çoğu zaman aslında arka planda bir JSON API’de durur. Benim dinamik fixture’ımın verisi de bir endpoint’teydi; CheerioCrawler’ı doğrudan o API’ye yönlendirdiğimde, browser kullanmadan, yaklaşık 0.035 saniyede 8/8 ürünü geri aldı. Aynı veriyi browser yolu neredeyse beş saniyede render etti. Ders eski ama hâlâ doğru: Alttaki isteği yeniden üretebiliyorsanız, Chromium başlatmak yerine bunu yapın. Crawlee size bu seçimi framework değiştirmeden, crawler bazında yapma imkânı veriyor.
Crawl Framework Tarafı (Crawlee’yi saf browser kütüphanesinden ayıran neden)
Eğer tek ihtiyacınız bir sayfayı render etmek olsaydı, Crawlee’ye gerek duymazdınız — Playwright ya da Puppeteer’ı tek başına kullanırdınız. Saf bir browser kütüphanesinin vermediği şey crawl’un kendisidir: kuyruk, deduplication, derinlik kontrolü, yeniden deneme mantığı. Crawlee’nin motorlardan bağımsız olan kısmı tam olarak budur.
Bir fixture kökünden başlayıp enqueueLinks ve depth takibiyle aynı host üzerinde bir crawl çalıştırdım. Crawlee 11 sayfa dolaştı; derinlik dağılımı {0:1, 1:3, 2:7} şeklindeydi — bir kök, bir tık uzaklıkta üç sayfa, iki tık uzaklıkta yedi sayfa — ve maxRequestsPerCrawl sınırını durdurma koşulu olarak uyguladı. RequestQueue tüm kayıt tutma işini üstlendi. HTTP 500 dönen bir sayfaya istek gönderdiğimde ise Crawlee yeniden denedi ve sonunda başarısızlığı sessizce yutmak ya da tüm çalışmayı çökertmek yerine failedRequestHandler üzerinden yüzeye çıkardı.
Bu, Crawlee’nin bağımsız bir browser aracına göre en güçlü avantajıdır: crawl orkestrasyonu yerleşik gelir ve en önemlisi, altta HTTP de olsa browser da olsa aynı orkestrasyondur. Kuyruk ve takip mantığını bir kez yazarsınız. Her crawler’ın JavaScript render edip etmeyeceğine ise ayrı karar verirsiniz.
Kurulum ve Gizli Browser İndirimi
Kurulum genel olarak sorunsuzdu; ancak ilk kez kullanacakları yakalayabilecek bir tuzak var.
npm install crawlee playwright komutu temiz şekilde kuruldu ve 0 güvenlik açığı raporlandı. Ancak PlaywrightCrawler’ın çalışması için ayrıca npx playwright install chromium komutunu da çalıştırmanız gerekir; bu da yaklaşık 81.7 MiB’lik bir Chromium binary’si indirir. Sadece crawlee paketini kurmak browser indirmez. Bu adımı atlayıp doğrudan browser crawler çalıştırırsanız, Playwright’ın paketleme modeline aşina değilseniz çok da açık olmayan bir başlatma hatasıyla karşılaşırsınız. Bu Crawlee hatası değil, Playwright davranışının mirasıdır; yine de ilk çalıştırmada gerçek bir sürtünme noktası olduğu için belirtilmeye değer.
Bir operasyon notu daha: Crawlee varsayılan olarak yerel bir storage/ dizinine yazar. Test altyapım bunu geçici bir klasöre yönlendirdi ve temiz kalması için kalıcılığı kapattı; ancak sade bir çalıştırma proje içinde bir storage/ klasörü bırakır. Sorun değil, sadece git status içinde görünmeden önce bilmeniz gereken bir detay.
Kısaca Üçüncü Motor
Crawlee’nin benzerlik hikâyesi Cheerio ve Playwright ile sınırlı değil. Bir de PuppeteerCrawler var; ben de “aynı arayüz” iddiasının buna ne kadar uzandığını inceledim — canlı crawl ile değil, sınıf ve API yüzeyi seviyesinde.
Üç crawler sınıfının tamamı aynı BasicCrawler temel sınıfına dayanıyor. CheerioCrawler, HttpCrawler üzerinden çalışıyor; PlaywrightCrawler ve PuppeteerCrawler ise ortak bir BrowserCrawler katmanına yönleniyor. Yüklenmiş paketi inceleyince, kuyruk ve storage işlemleri dâhil tasarımın tamamının dayandığı 24 ortak public method gördüm: run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. PuppeteerCrawler ve PlaywrightCrawler’ın public method set’i ise birebir aynı. Motorlar arası farklar yalnızca HTTP ile browser arasındaki sınırda ortaya çıkıyor; olması gerektiği gibi.
Burada açıkça belirtilmesi gereken sınır şu: PuppeteerCrawler ile canlı bir crawl çalıştırmadım. puppeteer peer dependency’si isteğe bağlıydı ve test paketimde kurulu değildi; ayrıca bunu denemek bir browser indirmesini daha gerektirecekti. Bu yüzden Puppeteer uyumluluğu burada yapısal olarak doğrulandı — aynı temel sınıf, aynı ortak methodlar, aynı handler context yapısı — ama gerçek çalıştırma ile değil. Ve arayüz aynı olsa bile, alt davranış birebir aynı değildir: Crawlee’nin kendi rehberinde Playwright’ın elementler için otomatik beklediği, Puppeteer’ın ise beklemeyi sizin açıkça yönetmeniz gerektiği belirtilir. Bu Crawlee kusuru değil, motor farkıdır; ama “aynı API”nin “her handler içinde aynı iç mantık” anlamına gelmediğini gösterir.
Neleri Test Etmedim
Bu turda bazı şeyleri özellikle masada bıraktım; böylece sonuçlarımı olduğundan geniş okumazsınız.
- Ölçek. Her şey küçük fixture’larda ve kısa public crawl’larda çalıştı. 100–1.000 sayfalık uzun bir koşu yapmadım; dolayısıyla Crawlee’nin autoscaling kabiliyeti ya da gerçek yük altındaki stabilitesi hakkında yorum yapamam.
- Queue kalıcılığı ve devam ettirme. Bir crawl’u ortasında bilerek öldürüp
RequestQueue’nun çökmeden sonra temizce devam edip etmediğini test etmedim. Uzun işler için önemli bir özellik ve burada denenmedi. - Dataset ve KeyValueStore export. JSON/CSV dışa aktarımlarını test ortamında elle yazdım. Crawlee’nin yerleşik
Dataset/KeyValueStoreexport kullanım kolaylığını — ki framework kullanmanın asıl pratik kazanımlarından biri olabilir — denemedim. - Proxy ve session pool’ları. Crawlee proxy rotation ve fingerprinting özellikleri sunuyor. Bunları sıkı biçimde sadece uyumluluk ve operasyon konusu olarak görüyorum, “anti-bot aşma” vaadi olarak değil; bu yüzden hiçbir yönde stres testine sokmadım.
Üstelik tüm süreler tek makine, tek çalıştırma verisi. HTTP ile browser arasındaki maliyet farkının şeklini gösteriyorlar. Benchmark değiller; bu şekilde alıntılamazdım.
Artıları ve Eksileri
Artılar
- HTTP ve browser crawl için tek bir API yüzeyi — motor değişimi gerçekten bir sınıf değişimi; hem yerel fixture’da hem de herkese açık sitede 0’dan tam veriye geçişle doğrulandı.
- Gerçek bir crawl framework’ü:
RequestQueue, derinlik kontrollüenqueueLinks, retry’lar vefailedRequestHandlerile sadece sayfa render eden bir araç değil. - JavaScript engel değilken doğru HTTP extraction (statik 12/12, makale paragrafında 3/3, JSON API üzerinden 8/8).
- Browser yolu, HTTP yolunun fiziksel olarak göremediği içeriği geri getirebiliyor ve ekran görüntüsü alabiliyor.
- Apache-2.0, TypeScript, aktif olarak geliştiriliyor.
Eksiler
- Browser crawler’lar için
npm install crawlee’nin otomatik halletmediği ayrı birnpx playwright install chromiumadımı gerekiyor (~81.7 MiB) — gözden kaçması kolay. - Browser rendering, sayfa başına gerçek bir maliyet getiriyor (tek sayfalık testimde ~5 sn’ye karşılık alt saniye).
- Sade çalıştırmada varsayılan
storage/dizini yan etkisi oluşuyor. - Ölçek, queue kalıcılığı/devam ettirme ve Dataset export ergonomisi testimde doğrulanmadı.
- Proxy ve fingerprinting özellikleri, bir sitenin şartları ve yasalar çerçevesinde kullanılmalıdır — dayanak değil, sorumluluk alanıdır.
Crawlee’yi Ne Zaman Seçmeli, Ne Zaman Yönetilen Bir API?
Crawlee, kendi içinde kurup yönetebileceğiniz bir araçtır ve birçok ekip için doğru seçim budur. Kendi Node kod tabanınızda crawler’ı sahiplenmek, HTTP ve browser crawl’u aynı projede framework değiştirmeden karıştırmak ve queue ile storage üzerinde tam kontrol sahibi olmak istiyorsanız Crawlee mantıklıdır. Browser filosunu çalıştırmayı ve zamanla ölçeklemeyi göze alabiliyorsanız, bunu düzgün tasarlanmış sağlam bir iskelet üzerinde yapmanızı sağlar.
Diğer yol ise bütün bu altyapıyı hiç çalıştırmamaktır. Chromium instance’larını idare etmek, proxy rotation yönetmek ve anti-bot meseleleriyle uğraşmak mühendislik zamanınızı harcamak istediğiniz şey değilse, yönetilen bir API alternatif olur — ve Thunderbit üzerindeki kendi geliştirici yığınınız tam da burada devreye girer. Teknik kullanıcılar için Thunderbit, Chrome uzantısı değil; AI tabanlı bir scraping API’si, MCP server’ı ve CLI aracıdır. Bir sayfayı temiz, LLM’ye hazır Markdown’a çevirmek için POST /distill, yapılandırılmış veri almak için ise JSON Schema ile POST /extract çağırırsınız. renderMode değerini none, basic veya full olarak seçebilir, tam browser render’ın ne zaman gerçekten gerekli olduğuna siz karar verirsiniz. MCP server sayesinde bir AI ajanı (Claude, Cursor ve diğer MCP istemcileri) görev ortasında scrape işlemi yapabilir; CLI ise terminalden veya CI ortamından çalıştırılır:
Web Veri Çıkarmak için Thunderbit’i Deneyin
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Geliştiriciler için fark şudur: Crawlee size ham malzemeyi — render edilmiş HTML, ayrıştırılmış node’lar — verir ve siz pipeline’ın sahibi olursunuz; yönetilen API ise JS rendering, CAPTCHA ve anti-bot işlemlerini sunucu tarafında halledip size şemaya uyan yapılandırılmış JSON döndürür. Bunlar farklı işler. Maksimum kontrol istiyor ve operasyon yükünü dert etmiyorsanız Crawlee. Tarayıcı filosunu kendiniz işletmeden veriyi almak istiyorsanız yönetilen yol. Pek çok ekip sonunda ikisini birden kullanıyor: biri özel crawl’lar, diğeri de “bana sadece yapılandırılmış veriyi getir” senaryoları için. Maliyet tarafındaki farkı Thunderbit fiyatlandırmasında görebilirsiniz.
Sonuç
Crawlee kullanılmalı mı? Evet — eğer HTTP ve browser crawl’u aynı framework içinde, altında gerçek bir crawl kuyruğu olan bir çözümle yönetmek isteyen bir Node veya TypeScript geliştiricisiyseniz. İki motor vaadi Crawlee’yi seçmek için en güçlü neden; benim fixture’larımda da bu vaat net biçimde doğrulandı: aynı URL, tek sınıf değişimiyle 0’dan tam veriye geçti, statik extraction hızlı ve doğruydu, kuyruk ve derinlik bazlı crawl beklendiği gibi çalıştı.
Ama iki şeyi akılda tutarak başlayın. PlaywrightCrawler’ı ilk kullandığınızda gizli browser indirmesi için bütçe ayırın; ayrıca test etmediğim kısımların — ölçek, çökmeden sonra devam etme, yerleşik export’lar — benim doğruladıklarım kadar iyi çalıştığını varsaymayın; önce kendi iş yükünüzde deneyin. Kendi crawler’ınızı inşa etmek için bir temel olarak Crawlee güçlü ve iyi tasarlanmış bir mühendislik ürünü. Ancak tamamlanmış, tamamen elinizden çıkmış bir veri hattı olarak değil; daha çok iyi bir başlangıç noktası.
Web Veri Çıkarmak için Thunderbit’i Deneyin Get Started Free
SSS
Crawlee ücretsiz mi, lisansı nedir?
Evet. Crawlee açık kaynaklıdır ve Apache-2.0 lisansı altındadır; npm üzerinden kurulur (npm install crawlee). Test ettiğim sürüm 3.17.0’dı. Browser crawler’ları çalıştırmak için Playwright üzerinden ayrıca bir Chromium indirmeniz gerekir; bu da ücretsizdir ancak kurulumunuza yaklaşık 81.7 MiB ekler.
CheerioCrawler ve PlaywrightCrawler — hangisini kullanmalıyım?
Veri ham HTML’de veya alttaki bir JSON API’deyse CheerioCrawler kullanın — çok daha hızlıdır ve browser başlatmaz. İçerik JavaScript ile render ediliyorsa PlaywrightCrawler kullanın; bunu HTTP yolunun boş sonuç döndürmesinden anlayabilirsiniz. Benim testimde HTTP motoru JavaScript ile render edilen sayfada 0 öğe döndürdü, browser motoru ise her şeyi aldı. Aynı API’yi paylaştıkları için geçiş bir sınıf değişimidir, yeniden yazım değil.
Crawlee çalışmak için browser ister mi?
Yalnızca browser crawler’ları için ister. CheerioCrawler için browser gerekmez. PlaywrightCrawler (ve PuppeteerCrawler) için bir browser binary’si gerekir — bunu npx playwright install chromium ile kurarsınız. npm install crawlee tek başına browser indirmez; ilk kullanımda en sık karşılaşılan sürpriz budur.
Crawlee sayfalama ve çok sayfalı crawl’ları destekler mi?
Evet; hatta bu, bağımsız bir browser kütüphanesine göre onu seçmenin temel nedenlerinden biridir. enqueueLinks linkleri takip eder (.next-page gibi sayfalama seçicileri dâhil), RequestQueue deduplication yapar ve crawl’u yönetir; ayrıca depth kontrolü ile maxRequestsPerCrawl sınırları elde edersiniz. Testte aynı host üzerinde yapılan bir crawl, 0–2 derinliklerinde 11 sayfa dolaştı ve başarısız istekler failedRequestHandler üzerinden görüldü.
Crawlee, barındırılan bir scraping API ile nasıl karşılaştırılır?
Crawlee self-hosted bir çözümdür: crawler’ı siz yazarsınız ve çalıştırırsınız; ölçekleme, proxy’ler ve anti-bot yönetimi size aittir. Thunderbit’in distill/extract uçları gibi yönetilen bir API ise rendering ve anti-bot işlemlerini sunucu tarafında halledip size temiz Markdown veya şemaya uygun yapılandırılmış JSON döndürür; bunu API, MCP server ve CLI üzerinden sunar. Kendi pipeline’ınız üzerinde maksimum kontrol istiyorsanız Crawlee; browser altyapısını kendiniz çalıştırmak istemiyorsanız yönetilen API daha uygundur.
