Crawl4AI’ı Beş Farklı Sayfa Türünde Test Ettim — Güçlü Olduğu Yerler ve Tökezlediği Noktalar

Bazı üçüncü taraf karşılaştırmalar, Crawl4AI’a “Adaptive Intelligence” — yani bir siteyi öğrenip işaretleme yapısı değiştikten sonra kendini onaran seçiciler — gibi özellikler atfediyor. Ben test ettiğim API yüzeyinde böyle bir davranış görmedim. Crawl4AI’ın sunduğu şey, tarayıcı destekli Markdown üretimi ve CSS/XPath ile veri çekme. Scrapling, kendi incelemesinde sınırları belirtilen ayrı bir uyarlanabilir seçici özelliği sunuyor.

Crawl4AI 0.9.0 sürümünü, doğruluğu bilinen beş sayfa türü üzerinde denedim: sabit bir katalog, JavaScript ile render edilen bir katalog, kalıp içeriklerin içinde yer alan bir makale, bilerek oluşturulmuş bir 500 hatası ve bağlantılı çok sayfalı bir grafik. Test edilen Markdown ve schema yolları beklenen örnek içerikleri döndürdü. Ham Markdown, kalıp içerikleri de içinde tuttu; derin tarama sayfaya özel bekleme gerektirdi ve sıradan bir 500 hatası, anti-bot tarzı bir hata etiketiyle döndü.

Crawl4AI aslında nedir?

Kurulumda çoğu kişinin yanlış anladığı yerle başlayalım. Crawl4AI küçük bir Python ayrıştırıcısı değil. İlk crawl4ai-setup, sessizce iki tam tarayıcı yığınını — Playwright ve Patchright — indiriyor. Bunu gördüğünüz anda araç yerli yerine oturuyor: Bu, üstüne bir Markdown dönüştürücü eklenmiş, scraper kılığına girmiş kontrollü bir headless tarayıcı.

Resmî olarak bu, web sayfalarını RAG iş akışları, agent’ler ve veri süreçleri için Markdown’a dönüştüren açık kaynaklı, Apache-2.0 lisanslı bir kütüphane. Ben v0.9.0 sürümünü test ettim. Temel bileşenleri arasında AsyncWebCrawler, BrowserConfig, CrawlerRunConfig, Markdown üretimi ve resmî hızlı başlangıca göre CSS/XPath ya da LLM tabanlı çıkarım stratejileri yer alıyor.

Burada önemli olan zihinsel model şu: Çoğu ayrıştırma kütüphanesi bir HTTP isteği gönderir ve dönen baytları işler; Crawl4AI ise gerçek bir tarayıcıyı çalıştırır. Tarayıcı render’ı yerleşik olduğu için kurulum, saf bir HTTP ayrıştırıcısından daha ağırdır; ancak asenkron render edilen öğelerden güvenilir veri çekmek için yine de açık bir bekleme tanımlamak gerekebilir. Burada test ettiğim hiçbir şey, bir tasarım değişikliğinden sonra seçicileri yeniden yazmadı. Kendini onarma iddiasını, ortada belirli bir resmî kaynak ve tekrarlanabilir API yoksa, üçüncü taraf karşılaştırma hatası olarak değerlendirin.

Temel özellikler ve içeride nasıl çalıştıkları

Tek sayfa akışı, işin kalbidir. AsyncWebCrawler’a bir URL verirsiniz, sayfayı tarayıcıda yükler ve size Markdown olarak geri verir. Resmî example.com hızlı başlangıcında bu gidiş-dönüş 1.81 saniye sürdü ve temiz bir 200 döndü. Olağanüstü bir şey değil ama en yalın yolun neredeyse sıfır yapılandırmayla çalıştığını doğruluyor — schema yok, bekleme yok, tarayıcı yapılandırması yok.

Video eğitimi (1:02:38): Crawl4AI Resmî Eğitimi, Hızlı Başlangıç Örnekleriyle Tam 1 Saat.

Yapılandırılmış çıkarım ikinci sütundur ve Crawl4AI’ın bir sayfayı “anlamaya” en çok yaklaştığı yerdir — yani çıkarım yapmaktan değil, sizin yazdığınız bir schema’dan söz ediyoruz. Sadece Markdown dökmek yerine, JsonCssExtractionStrategy üzerinden CSS schema verirsiniz ve istediğiniz alanlarla birebir eşleşen JSON nesneleri alırsınız. Yerel sabit katalog testimde 6 temiz JSON kayıt döndürdü — ürün adı, kategori, fiyat, puan, detay URL’si — ve beklenen 6 ürünün tamamıyla eşleşti. Bu, “işte sayfanın metni” ile “işte satırlar halinde veri” arasındaki farktır; Crawl4AI ikisini de aynı taramada yapabiliyor. Ancak seçicileri sizin tanımlamanız gerekir; araç, verdiğinizi eşleştirir, şemayı sizin yerinize tahmin etmez.

Dinamik render tarafında ise tarayıcı altyapısının faydası ortaya çıkıyor. wait_for="css:.product-card" ile JavaScript render’lı bir katalogu işaret ettiğinizde, istemci tarafı render bitene kadar bekliyor ve ardından veriyi çıkarıyor. Yerel JS örneğimde hem Markdown hem de schema çıktısında 8/8 ürün geri çağırımı elde edildi; bu işlem yaklaşık 1.56 saniye sürdü. Kamuya açık Quotes to Scrape JS sayfasında render edilmiş alıntıları yakaladı ve kullanılabilir bir ekran görüntüsü kaydetti — çünkü başlangıç HTML’sinde ayrıştırılacak bir şey yokken, düz bir HTTP isteği bunu asla göremezdi.

Sonra ölçek ve tarama geliyor. arun_many(), altı yerel detay sayfasını eşzamanlı çalıştırdı ve 6/6 tam geri çağırımı 3.76 saniyede tamamladı. Ayrıca Crawl4AI; BFS, DFS ve BestFirst gibi, bağlantı grafiğini derinlik sınırları, sayfa limitleri, filtreleme ve puanlama ile gezen deep-crawl stratejileri de sunuyor. Bir BFS derin tarama, örnek ana sayfamın bağlantı grafiğini dolaştı ve beş sayfa çekti. Ama işte burada vaat ile gerçeklik ayrışmaya başlıyor; birazdan ona geleceğim.

Kurulum: README girişinde kimsenin bahsetmediği kısım

Makinemde kurulum bir açıdan beklediğimden sorunsuz, başka bir açıdan ise daha ağırdı. pip install -U crawl4ai ve test çalışması macOS arm64 üzerinde Python 3.14.2 ile başarılı oldu. PyPI’daki >=3.10 şartı zaten 3.14’ü kapsıyor; bu sonuç yalnızca test edilen kurulum ve iş akışını doğrular, daha geniş uyumluluğu değil.

Asıl sürtünme kurulum adımında. crawl4ai-setup, hem Playwright hem de Patchright için tarayıcı varlıklarını indiriyor — Chrome for Testing, FFmpeg ve Headless Shell. Eğer disk alanı kısıtlı bir dizüstü bilgisayar kullanıyorsanız veya bağlantınız kota tabanlıysa, bu gerçek bir maliyet. Dokümantasyon bunu önden anlatmaktan ziyade üstünkörü geçiyor. crawl4ai-doctor ise başarılı oldu ve crawl4ai.com üzerinde 14.65 saniyede tarama yaptı; bu, güzel bir uçtan uca testtir ama performans ölçütü değildir — bu sayıdan hız çıkarımı yapmazdım.

Kendi değerlendirmenizin kurulum bölümündeki çıkarım şu olmalı: Sadece pip install için değil, tarayıcı indirmesi için de bütçe ayırın. Bu, bir kütüphaneyi betiğe eklemekten çok, headless bir tarayıcı ortamı kurmaya benziyor. Tek bir gerçek sayfayı taramadan önce diske iki tarayıcı yığını iniyor ve bu, iş yükünüzün Patchright’in gizlilik katmanına ihtiyaç duyup duymadığına bakmaksızın ödeyeceğiniz tek seferlik bir maliyet.

Uygulamada: ne işe yaradı, neyi not etmek gerekir?

Dört sonuç özellikle dikkat çekmeye değer; çünkü bunlar pazarlama sayfalarının genelde yuvarladığı nüansları gösteriyor — ve bir durumda yanlış etiketlemeyi.

İki kamu demo sayfası da sorunsuz geçti. Books to Scrape ana sayfasında Crawl4AI, 2.43 saniyede 13.476 karakter Markdown üretti. Kamuya açık Quotes JS sayfası ise yaklaşık 3.1 saniyede 1.666 karakterlik render edilmiş Markdown döndürdü. Bunların hiçbiri ölçek, düşmanca siteler, uzun süreli kararlılık, oturumlar, proxy’ler, yeniden denemeler ya da bellek davranışı hakkında kanıt değildir.

Makale örneği, Markdown kalitesi açısından bir uyarı veriyor. Crawl4AI başlığı ve tüm 3/3 paragrafı yakaladı — bu iyi. Ama ham Markdown içinde gezinme metni, ilgili bağlantılar, abonelik satırı ve altbilgi metni de kaldı. Bu bir hata değil; bir içerik filtresi ya da hedef seçici olmadan “bu sayfayı Markdown’a çevir” ifadesi gerçekten de tüm sayfayı anlamına gelir. Buradaki ders, ham Markdown dönüşümü ile temiz makale çıkarımını birbirinden ayırmaktır. İkincisini istiyorsanız PruningContentFilter gibi bir içerik filtresine veya bir hedef seçiciye başvurursunuz — fakat bunu henüz stres test etmedim, bu yüzden onun için temizlik numarası vermeyeceğim.

Bozuk sayfa en öğretici sonuçtu. Küçük gövdeli kasıtlı bir HTTP 500 sayfası servis ettim. Crawl4AI success=false ve 500 durum koduyla döndü — bu doğru — ama hata mesajı bunu “Blocked by anti-bot protection: Structural: minimal_text on small page.” şeklinde çerçeveledi. Ortada anti-bot duvarı yoktu; sadece küçük bir hata sayfası vardı. Crawl4AI’ın yapısal sezgisi çok az görünür metin gördü ve anti-bot açıklamasına yöneldi. Bunun üstünde bir şey geliştirenler için bu önemli: “anti-bot” etiketine olduğu gibi güvenmeyin. Bir sitenin sizi gerçekten engellediği sonucuna varmadan önce durum kodunu ve gerçek yanıtı inceleyin. Ham sonuç benchmark deposunda results/local_failure_500.json içinde yer alıyor.

Deep crawling’in bilinçli yapılandırmaya ihtiyacı var. Doğrudan yapılan dinamik tarama wait_for ile temizce çalışırken, BFS derin taraması dinamik kataloğu keşfetti ve başarısız oldu. Minimal metin sınıflandırması, kartlar render olmadan önce okumaya uyuyor; deep crawl ise doğrudan taramadaki beklemeyi uygulamadı. Beş sayfadan üçü başarılı, ikisi başarısız oldu. Bekleme yapılandırılmış bir yeniden deneme burada gösterilmediği için, bu teşhis kanıtlanmış neden değil, çıkarım olarak kalıyor.

Sayılar ne söylüyor?

Bunlar performans benchmark’ı değil, smoke-test zamanlamalarıdır: makale donanımı, tekrar sayısını, sıcak/soğuk durumunu, önbellek durumunu, eşzamanlılık kontrollerini ya da varyansı belgelemiyor. Yalnızca listelenen iş akışlarının bu makinede tamamlandığını gösteriyorlar. Tam çalışma artefaktları benchmark depo dizininde bulunuyor.

Karar düzeyinde bir performans koşusu için, her iş akışını yeni ve yeniden kullanılan tarayıcı oturumlarında tekrarlayın, tek ondalık yerine dağılımları raporlayın, tarayıcı sürümlerini sabitleyin ve CPU, bellek, önbellek durumu ve eşzamanlılığı kaydedin. Bu, kütüphane yükünü tarayıcı başlatma maliyetinden ve ağ değişkenliğinden ayırır.

Artılar ve eksiler

Artılar:

• Tek bir kütüphane hem ham Markdown hem de CSS schema tabanlı yapılandırılmış JSON üretir — iki aracı birbirine yapıştırmanız gerekmez.
• Tarayıcı render’ı yerleşik gelir; asenkron render edilen hedefler için açık bir wait_for gerekebilir.
• Test edilen tek sayfalık iş akışları yukarıda gözlenen sürelerde tamamlandı; herhangi bir göreli hız iddiası yapılmıyor.
• Apache-2.0 lisansı — ticari kullanım için uygun, copyleft sürprizi yok.
• Son sürümü olan, aktif bir proje ve geniş, ilgili bir topluluk.

Eksiler:

• İlk kurulum ağırdır (iki tarayıcı yığını) ve giriş kısmında bunun üstü biraz örtülüyor.
• Ham Markdown, içerik filtreleri ayarlanmadıkça kalıp içerikleri de içerir.
• Deep crawling, dinamik sayfalar için kendiliğinden beklemez — bunu her taramada siz yapılandırırsınız, yoksa başarısızlık alırsınız.
• Hata mesajları düz bir hatayı “anti-bot” olarak yanlış etiketleyebilir; bu loglarda kafa karıştırıcıdır.
• Bazı karşılaştırmalar aksini ima etse de, kendi kendine uyarlanan seçiciler yoktur — schema’lar elle yazılır ve statiktir.
• Tarayıcı ortamını güncellemeleri ve bozulmalarıyla birlikte siz çalıştırır ve siz sürdürürsünüz.

Kimler için uygun, kimler uzak dursun?

Crawl4AI, RAG ya da agent hattı kuran bir geliştiriciyseniz, headless tarayıcı ortamı çalıştırmaya rahatsanız ve aynı taramadan hem Markdown hem de yapılandırılmış JSON almak istiyorsanız değerlendirmeye değer. Testler, düşmanca site dayanıklılığını, uzun süreli kararlılığı, belleği, oturumları, yeniden denemeleri, proxy’leri veya üretim dağıtımını kapsamıyordu; dolayısıyla öneri yalnızca burada uygulanan iş akışlarıyla sınırlıdır.

Eğer küçük, bağımlılığı düşük bir HTTP ayrıştırıcısı istiyorsanız — ki bu onun tam tersidir —, tarayıcı indirmeleri için disk ve bant genişliği ayıramıyorsanız ya da üretimde bir tarayıcı yığınının bakımını üstlenmek istemiyorsanız uzak durun ya da en azından durun ve düşünün. Özellikle de self-healing seçiciler için geldiyseniz uzak durun: Bu araç o değil ve olmayan bir özellik etrafında iş akışı kurmak sonra sizi ısırır. Kalıp içeriklerden arındırılmış saf makale metni çıkarmak için, tam o işe odaklanan daha hafif bir araç daha iyi olabilir.

Alternatifler ve Thunderbit’in konumu

Dürüst çerçeve şu: Crawl4AI, kendi barındırdığınız ve kendiniz sürdürdüğünüz ücretsiz, açık kaynaklı bir kütüphanedir. Tam kontrol sizde olur ve kullanım ücreti ödemezsiniz; ancak bunun karşılığında işlem gücü, bant genişliği, depolama, tarayıcı güncellemeleri, schema’lar ve operasyonel iş yükü de size aittir.

Diğer uçta ise Thunderbit gibi yönetilen bir scraping hizmeti vardır; burada çekme ve çıkarım bir API’nin arkasında çalışır. Thunderbit bu örnek veri setlerinde çalıştırılmadı, dolayısıyla bu makale render, anti-bot yönetimi, CAPTCHA’lar, doğruluk veya hız konusunda eşleşmiş bir iddia sunmuyor. İlgili karşılaştırma operasyonel sahipliktir: tarayıcı destekli kütüphaneyi kendiniz barındırırsınız ya da o katmanı işletmesi için bir hizmete ödeme yaparsınız.

Farkı yaratan şey tarayıcıyı kimin çalıştırdığıdır. Crawl4AI ile render, beklemeler, schema’lar ve bakım sizdedir. Yönetilen bir API’de ise isteğe göre ödeme yapar ve bazı operasyonel sorumluluğu sağlayıcıya kaydırırsınız. Bu deney, iki yolu sonuçlar açısından kıyaslamadı.

İlgili benchmark incelemeleri: tam açık kaynak scraper karşılaştırması, Firecrawl’ın self-hosted incelemesi ve trafilatura’nın makale çıkarım incelemesi.

Web Verisi Çıkarmak İçin Thunderbit’i Deneyin

Sonuç

Açık kaynaklı, tarayıcı destekli bir çıkarım arıyorsanız ve hem Markdown hem de schema biçimli JSON üretmesini istiyorsanız Crawl4AI makul bir adaydır; ancak tarayıcı ortamını sahiplenmeye hazır olmanız gerekir. Doğrudan yapılan sabit ve beklemeli dinamik iş akışları bu örneklerde başarılı oldu. Apache-2.0 esnektir; yine de normal bağımlılık ve dağıtım incelemesi geçerlidir.

Tarayıcı varlıkları için bütçe ayırın. Ham Markdown, makale temizliğine ulaşmadan önce filtrelenmelidir. Deep-crawl beklemeleri bilinçli yapılandırma ister ve “anti-bot” diyen bir log, durum kodu ve yanıtla birlikte kontrol edilmelidir. Schema seçicileri yazmak ve sürdürmek size kalır. Bunlar test edilmiş karar sınırlarıdır; üretim ölçeği ve düşmanca site davranışı ise hâlâ açık sorular olarak duruyor.

Web Verisi Çıkarmak İçin Thunderbit’i Deneyin Get Started Free

SSS

Crawl4AI’da uyarlanabilir veya kendini onaran seçiciler var mı? Hayır. Bazı karşılaştırmalarda “adaptive intelligence” kredisi verilmesine rağmen Crawl4AI, yazdığınız CSS/XPath schema’sıyla eşleşir — öğeleri parmak iziyle tanımaz ve işaretleme değişikliğinden sonra yeniden bulmaz. Testlerde yapılandırılmış çıkarım, elle tanımladığım schema’larla 6/6 ve 8/8 geri çağırımı yakaladı. Bir sitenin sınıfları değişirse, siz güncelleyene kadar schema’nız bozulur. Kendi kendine onaran öğe takibi bu kütüphanenin değil, başka bir kütüphanenin özelliğidir.

Kurulum neden bu kadar büyük? crawl4ai-setup, hem Playwright hem de Patchright için tam tarayıcı varlıklarını indirir — Chrome for Testing, FFmpeg ve Headless Shell. Bu, gerçek tarayıcı render’ı sunmanın bedelidir. Disk ve bant genişliği için bunu hesaba katın; saf bir HTTP ayrıştırıcısından daha ağırdır ve çalışma yükünüz gizlilik katmanını hiç kullanmasa bile bu maliyeti ödersiniz.

Crawl4AI JavaScript ile render edilen sayfaları işleyebiliyor mu? Evet, çünkü gerçek bir headless tarayıcı çalıştırıyor. Testlerde wait_for="css:.product-card" tanımlanan dinamik katalog tam 8/8 ürün geri çağırımı verdi ve kamuya açık Quotes JS sayfası sorunsuz render oldu. Ancak derin taramalar keşfedilen sayfalara bu beklemeyi otomatik uygulamıyor — BFS taraması, bulduğu dinamik sayfada beklemediği için başarısız oldu. Beklemeyi her tarama için kendiniz tanımlıyorsunuz.

Crawl4AI bana temiz makale metni mi verir, yoksa tüm sayfayı mı? Varsayılan olarak tüm sayfayı verir. Testte tüm gövde paragraflarını yakaladı ama gezinme, ilgili bağlantılar ve altbilgi metnini de tuttu. Temiz makale çıkarımı için ham Markdown’a güvenmek yerine bir içerik filtresi (örneğin PruningContentFilter) ya da hedef seçici kullanırsınız.

Crawl4AI’ın hata mesajlarına güvenebilir miyim? Biraz şüpheyle okuyun. Küçük gövdeli kasıtlı bir 500 hata sayfası, tamamen düşük görünür metin sezgisi nedeniyle “Blocked by anti-bot protection” olarak etiketlendi — ortada anti-bot engeli yoktu. Ham sonuç benchmark deposunda. Bir sitenin sizi engellediği sonucuna varmadan önce mutlaka gerçek HTTP durum kodunu ve yanıt gövdesini kontrol edin.