Bize Ulaşın
Sonuç bulunamadı.

2026 Web Tarayıcı Performans Testi: İndekslemeden Aracılığa Intelligence

Cem Dilmegani
Cem Dilmegani
güncellendi Nis 10, 2026
Bakınız etik normlar

Üç farklı zorluk seviyesindeki (amazon.com, entrepreneur.com, theregister.com) üç farklı alan adında, üç farklı maksimum derinlik seviyesinde (5, 10, 20) ve 1.000 sayfa sınırında dört tarama API'sini karşılaştırmalı olarak test ettik. Testlerde tarama kapsamı, yürütme süresi, bağlantı keşfi, Markdown bağlantı kalitesi ve başlık çıkarma doğruluğunu ölçtük.

Eğer amacınız şuysa:

  • Web sayfalarını yapılandırılmış verilere dönüştürün, web kazıma kılavuzumuza bakın.
  • Tüm web sitelerini tarayın, okumaya devam edin.

Web tarayıcıları performans testi

Loading Chart

Karşılaştırma yöntemimizi okuyabilirsiniz.

Ortalama taranan sayfa sayısı ile 1.000 sayfa başına maliyet arasındaki ilişki

Alan adları genelinde taranan sayfalar, maksimum derinliğe göre

Firecrawl, maksimum derinlikten bağımsız olarak theregister.com'da sürekli olarak yaklaşık 100 sayfa, entrepreneur.com'da tüm derinlik seviyelerinde yaklaşık 90 sayfa ve amazon.com'da ise muhtemelen Amazon'un agresif bot koruması nedeniyle sadece yaklaşık 30 sayfa taradı. Dikkat çekici bir şekilde, maksimum derinliğin artırılması, Firecrawl'ün herhangi bir alanda tarayabildiği sayfa sayısını neredeyse hiç etkilemedi.

Apify en tutarlı performansı göstererek, Amazon gibi yüksek düzeyde korunan sitelerde bile, her derinlik seviyesindeki her alanda 1.000 sayfalık maksimum tarama sınırına herhangi bir zorluk çekmeden ulaştı.

Cloudflare testler arasında tutarsız davranış sergiledi:

  • theregister.com'da maksimum 5 derinlikte yalnızca 100 sayfa tarandı, ancak maksimum 20 derinlikte neredeyse 1.000 sayfaya ulaşıldı.
  • Daha önceki testlerde gözlemlediğimiz gibi, Cloudflare bazen sadece 1 sayfa tarıyor ve ardından işi tamamen sonlandırıyor. Bunun bir önbellekleme sorunu olmadığını doğruladık (önbellek devre dışı bırakıldı) ve çalıştırmalar arasındaki bekleme sürelerini 1 dakikaya kadar uzatarak test ettik, ancak davranış devam etti. theregister.com'da maksimum 10 derinlikte, tam olarak bu sorun meydana geldi; Cloudflare durmadan önce sadece 1 sayfa taradı.
  • entrepreneur.com'da, Cloudflare 5 derinlikte 780 sayfa taradı, 10 derinlikte 885 sayfaya çıktı, ancak daha sonra 20 derinlikte sadece 172 sayfaya düştü. Bu düşüş, Cloudflare'nin tarama zamanlayıcısının daha derin bağlantı zincirlerini önceliklendirmemesi veya zaman aşımına uğratmasıyla ilgili olabilir veya tarama sınırı daha yüksek derinliklerde çok büyüdüğünde işin erken sonlanmasına neden olan dahili bir eşzamanlılık sınırını yansıtabilir.
  • Amazon.com'da, Cloudflare 5 derinlikte 905 sayfa taradı, ancak maksimum derinlik arttıkça bu sayı sürekli olarak azaldı ve 10 derinlikte 809'a, 20 derinlikte ise 795'e düştü. Bu durum, daha derin tarama yapılandırmalarının Cloudflare'nin gerçek sayfa alımından ziyade bağlantı keşfiyle ilgili ek yük üzerinde daha fazla zaman harcamasına neden olabileceğini düşündürmektedir.

Nimble, theregister.com'da tüm derinlik seviyelerinde (1.000 / 1.000 / 999) 1.000 sayfa sınırına ulaştı veya yaklaştı. entrepreneur.com'da ise 5. derinlikte 1.000 sayfa taradı, ancak daha yüksek derinliklerde hafif düşüşler gösterdi (10. derinlikte 896, 20. derinlikte 983), muhtemelen daha derin seviyelerde tam tarama tamamlanmadan önce 7 saatlik zaman aşımına ulaşılması nedeniyle, tüm Nimble çalıştırmaları zaman aşımı durumuyla sonuçlandı. Amazon daha zorlu çıktı:

  • 5. derinlikte sadece 319 sayfaya ulaşabildi, ancak 10. derinlikte 988 sayfaya sıçradı, ardından 20. derinlikte 906 sayfaya düştü.
  • Bu tutarsızlık muhtemelen Amazon'un bot koruma mekanizmaları ve Nimble'in zaman aşımı kısıtlamalarının birleşimini yansıtıyor; daha derin taramalar her sayfayı işlemek için daha uzun süre alıyor ve yol boyunca daha fazla bot karşıtı engelle karşılaşabiliyor.

Maksimum derinliğe göre etki alanları genelinde yürütme süresi

Firecrawl , tüm alan adları arasında en hızlı sağlayıcıydı ve taramaları 5 dakikadan kısa sürede, genellikle 75-265 saniye arasında tamamladı. Bu hız, kapsama alanının azalması pahasına elde edildi, çünkü Firecrawl aynı zamanda en az sayıda sayfayı taradı. Esasen, erken durduğu için hızlı bir şekilde bitiriyor.

Apify araması , derinlikten bağımsız olarak theregister.com'da yaklaşık 2.200-2.400 saniye (~40 dakika) sürdü. entrepreneur.com ve amazon.com'da ise yürütme süreleri, daha büyük ve karmaşık site yapılarını yansıtacak şekilde 8.300-15.900 saniye (2-4 saat) ile önemli ölçüde daha uzundu. Daha uzun sürelere rağmen, Apify araması sürekli olarak 1.000 sayfa sınırına ulaştı ve bu da onu kapsama-süre oranı açısından en güvenilir arama yöntemi haline getirdi.

Cloudflare tutarsız tarama sayımlarını yansıtan bir zamanlama gösterdi:

  • theregister.com sitesinde 10. derinlikte, yalnızca 1 sayfayı taradıktan sonra durduğu için arama sadece 1 saniyede tamamlandı.
  • Entrepreneur.com sitesinde 20. derinlikte, yalnızca 172 sayfa tarandıktan sonra 10 saniyede tamamlandı.
  • Cloudflare tam bir tarama işlemini tamamladığında, süreler 3.500 ile 25.200 saniye arasında değişmektedir.
  • Maksimum derinlik arttıkça, Cloudflare tarayıcısının genişlikten ziyade daha derin sayfalara ulaşmaya öncelik verdiği, daha az sayfa taradığı ancak daha hızlı tamamladığı görülüyor. Amazon.com'da, yürütme süresi 5. derinlikte 25.200 saniyeden (zaman aşımı) 20. derinlikte sadece 5.660 saniyeye düşerken, taranan sayfa sayısı da 905'ten 795'e düştü. Bu, Cloudflare tarayıcısının daha yüksek derinliklerde stratejisini değiştirdiğini, geniş keşif için daha az zaman harcadığını ve daha çok derin taramaya odaklandığını gösteriyor.

Nimble, tüm alan adları ve derinlik seviyelerinde her çalıştırmada 7 saatlik zaman aşımına (25.200 saniye) ulaştı. Bu durum dikkat çekicidir çünkü daha önceki hızlı testlerimizde, maksimum derinlik 1 ile Nimble zaman aşımına uğramadan tamamlanmıştı. 5-20 derinlik ve 1.000 sayfa sınırı ile yapılan tam kıyaslamada, zaman aşımına ulaşılana kadar sürekli olarak çalıştı. Buna rağmen, Nimble çoğu durumda yüksek sayıda sayfa taramayı başardı (~theregister.com ve entrepreneur.com'da 900-1.000 sayfa), yani 7 saat boyunca aktif olarak tarama yapıyor ancak hiçbir zaman tamamlanma sinyali vermiyor.

Markdown çıktısının kalitesini değerlendirmek için, her sağlayıcının markdown'ındaki bağlantıların yüzde kaçının bağlantı metni (bağlantının tıklanabilir metin kısmı) içerdiğini ölçtük. Eksik bir bağlantı metni (örneğin, [About Us](/about) yerine [](/about)), tarayıcının bağlantının etiketini çıkaramadığı anlamına gelir.

  • Nimble : Tüm derinliklerde %100
  • Cloudflare : %91-94
  • Firecrawl : %90
  • Apify : %77-78, yaklaşık her 5 bağlantıdan 1'inde bağlantı metni eksik

Tarama derinliğinin, herhangi bir sağlayıcı için doluluk oranları üzerinde minimum düzeyde etkisi oldu; bu da bunun tarama ayarından ziyade her sağlayıcının ayrıştırma motorunun bir özelliği olduğunu düşündürmektedir.

Farklı alan adlarındaki doluluk oranlarına bakmak, site karmaşıklığının her sağlayıcının bağlantı çıkarma kalitesini nasıl etkilediğini ortaya koymaktadır.

  • Nimble tüm alanlarda %100 oranında korunmuştur.
  • Apify en fazla varyasyonu gösterdi; amazon.com'da %89, entrepreneur.com'da ise %66'ya düştü. Bu da o sitedeki bağlantılarının üçte birinde bağlantı metninin eksik olduğu anlamına geliyor. Bu durum, Apify'un karmaşık gezinme yapılarına sahip, içerik açısından zengin sitelerle daha fazla zorlandığını gösteriyor.
  • Firecrawl, theregister.com'da en iyi performansı gösterdi (%98), ancak entrepreneur.com'da %81'e düştü ve Apify ile benzer bir seyir izledi.
  • Cloudflare, alan fark etmeksizin %89-94 arasında kalarak Nimble'den sonra en istikrarlı olanıydı.

Entrepreneur.com, bağlantı metni çıkarma konusunda en zorlu alan adı olduğunu kanıtladı; hem Apify (%66) hem de Firecrawl (%81) en düşük puanlarını burada aldı. Bunun nedeni muhtemelen sitenin iç içe geçmiş gezinme menülerini ve dinamik içerik öğelerini yoğun olarak kullanması ve bunların Markdown'a temiz bir şekilde dönüştürülmesinin daha zor olmasıdır.

Sağlayıcılar arasında bağlantı sayısı varyansı sürekli olarak yüksekti (%74-97), bu da sağlayıcıların aynı sayfalardan çok farklı sayıda bağlantı çıkardığını gösteriyor. Bu farklılığın daha ayrıntılı bir görünümünü elde etmek için, her sağlayıcı için toplam Markdown bağlantı sayısını ölçtük.

  • Apify genel olarak en fazla bağlantıyı döndürdü, özellikle amazon.com'da 5 derinlikte 420.000'den fazla bağlantı (~sayfa başına 423) ile öne çıktı. entrepreneur.com'da ise derinlikten bağımsız olarak 63.000 civarında sabit kaldı. Çıktısı, sayfa içeriği bağlantılarının yanı sıra reklam izleyicilerini ve izleme piksellerini de içeriyor.
  • Cloudflare, entrepreneur.com'da 10. derinlikte 303 bin bağlantıya ulaşarak zirve yaptı, ancak 20. derinlikte 53 bine düştü. Aynı entrepreneur.com ana sayfasında, Cloudflare, Apify'un 143 bağlantısına kıyasla 434 bağlantı çekti ve tüm gezinme menülerini ve alt menülerini yakaladı.
  • Firecrawl , düşük sayfa sayısı nedeniyle tüm yapılandırmalarda sürekli olarak 5-9 bin bağlantı döndürdü.
  • Nimble , diğer sağlayıcılara kıyasla sayfa başına ortalama 5-28 bağlantı (diğer sağlayıcılarda 60-420 bağlantı) ile toplamda 3-40 bin bağlantı döndürdü. entrepreneur.com'un ana sayfasında, Nimble, ana makale başlıklarıyla sınırlı olmak üzere 13 bağlantı döndürürken, Cloudflare 434 bağlantı döndürdü. %100 doluluk oranı, kapsamlı bağlantı kapsamını göstermekten ziyade, içerdiği tüm bağlantıların bağlantı metni içerdiğini yansıtmaktadır. Nimble, standart Markdown bağlantıları üretmez. Sayımı, Markdown çıktısında bulunan kaçış karakterli HTML bağlantılarını da içerir.

Başlık, sağlayıcılar genelindeki mevcut oranı sunmaktadır.

Sağlayıcılar arasında başlık benzerliği, tüm testler ve alan adları genelinde %1'den az sapma göstererek, sağlayıcılar bir başlık çıkardığında tutarlı bir şekilde aynı sonucu döndürdüklerini doğruladı. Başlık bulunma oranı da tüm maksimum derinlik seviyelerinde %98-100 arasında kaldı ve bu da tarama derinliğinin başlık çıkarımı üzerinde anlamlı bir etkisinin olmadığını gösterdi.

Alanlara göre incelendiğinde bazı farklılıklar ortaya çıktı:

entrepreneur.com ve theregister.com'da çoğu sağlayıcı %99-100 başlık bulunma oranına ulaştı. Anlamlı farklılıkların görüldüğü tek alan adı Amazon.com oldu; Firecrawl %93'e, Nimble ise %95,9'a düştü, Apify ise %99,6'lık oranını korudu. Bu durum, Amazon'un daha güçlü bot korumasıyla örtüşüyor; bu koruma, sayfa yanıtlarını engelleyebilir veya bozabilir ve bazı sağlayıcıların çıkarılabilir başlık içermeyen sayfalar döndürmesine neden olabilir.

Web tarayıcısı nedir?

Bazen "örümcek" veya "ajan" olarak da adlandırılan web tarayıcısı, internette içerikleri indekslemek için internette gezinen bir bottur.

Tarayıcılar arama motorlarının ötesine geçerek artık Otonom Veri Katmanı olarak hizmet veriyorlar. Claude Code ve OpenAI Operator gibi otonom yapay zeka ajanları için göz görevi görerek rekabet araştırması ve çok adımlı işlemler gibi gerçek zamanlı görevlerde yardımcı oluyorlar.

Web tarayıcısı ne yapar?

Web tarama işlemi, her biri farklı bir tarama hedefi için tasarlanmış üç moda ayrıldı.

  1. Keşif modu (geleneksel): Googlebot gibi arama motoru botları, dizinleme için URL'leri tarar ve insanların arama motorları aracılığıyla sonuç bulmasına yardımcı olur.
  2. Geri Alma Modu (RAG): ChatGPT-User veya PerplexityBot gibi yapay zeka botları, kullanıcı isteklerini yanıtlamak için belirli sayfaları gerçek zamanlı olarak getirir. Yapay zeka modelinin belirteç sınırlarına uyması için HTML yerine Markdown kullanırlar.
  3. Ajan Modu (Eylem Odaklı): 2026'da ortaya çıkan bu yeni tip tarayıcı, yalnızca içerik okumaktan daha fazlasını yapıyor. Model Bağlam Protokolü (MCP) kullanarak, bu botlar uçuş rezervasyonu yapmak veya yazılım komutları çalıştırmak için web siteleriyle etkileşim kurabiliyor.

Geçmişte, web tarayıcıları veri çıkarmak için XPath veya CSS gibi seçiciler kullanıyordu. Yapay zeka tabanlı veri çıkarma artık standart hale geldi.

Firecrawl ve Crawl4AI gibi araçlar, veri bulmak için doğal dil talimatlarını kullanır. Geliştiriciler, her bir öğe için kurallar yazmak yerine, tarayıcıya "ürün fiyatını çıkar" diyebilir ve yapay zeka, web sitesinin kodu değişse bile doğru değeri bulacaktır.

Yapay zekâ çağında web tarayıcılarını geliştirmek mi yoksa satın almak mı daha mantıklı?

1. Kendi Paletli Aracınızı İnşa Etmek

Temel fikri mülkiyeti korumak ve derinlemesine özelleştirmeyi sağlamak için idealdir. Artık geliştirme, yalnızca temel Scrapy komut dosyaları yazmakla kalmayıp, özel bir aracı katmanı geliştirmeyi gerektiriyor.

  • Ne zaman oluşturulmalı: Tarayıcınız benzersiz bir rekabet avantajı sağlıyorsa bu yaklaşımı seçin. Örneğin, özel bir arama motoru geliştiriyorsanız veya hassas veya düzenlemeye tabi veriler üzerinde tam kontrole ihtiyacınız varsa kendi tarayıcınızı oluşturun.
  • Araç seti: Artık sıfırdan başlamanıza gerek yok. Geliştiriciler artık dahili yapay zeka ajanlarının web ile etkileşim kurmasını sağlamak için Model Bağlam Protokolü'nden (MCP) yararlanıyor.

2. Web Tarama Araçları ve API'lerin Kullanımı

Yönetilen araçlar, temel veri çekme araçlarından otonom ajanlara doğru evrim geçirdi.

  • Sıfır bakım gerektiren veri çıkarma: Kadoa ve Firecrawl gibi modern araçlar, kendi kendini onaran yapay zeka kullanır. Kod içindeki konumunu belirtmek yerine, "Ürün Fiyatı" gibi gerekli verileri belirtirsiniz. Web sitesi düzeni değişirse, araç otomatik olarak uyum sağlar.
  • Hizmet olarak uyumluluk: Birçok sağlayıcı, AB Yapay Zeka Yasası'na uyumluluğu yerleşik olarak sunmaktadır. Bağımsız olarak uygulanması zor olan gerekli denetim kayıtlarını ve telif hakkı feragat kontrollerini yönetirler.
  • Değer yaratma hızı: Bir platform satın almak, projenizi haftalar içinde konsept aşamasından üretime geçirebilir.

Şekil 5: Bir URL sınırının nasıl çalıştığının açıklaması.

Web tarayıcıları yasal mı?

Genel olarak, web tarama yasaldır , ancak nasıl ve neyi taradığınıza bağlı olarak, kendinizi hızla yasal bir çıkmazda bulabilirsiniz. Taramanın (ve genellikle bunu takip eden veri kazımanın) yasal olup olmadığını belirleyen dört temel unsur vardır:

1. Herkese açık vs. özel: Yalnızca herkese açık ve hesap gerektirmeyen verileri tarayın.

2. Kişisel bilgiler: Yasal bir dayanağınız olmadığı sürece kişisel tanımlayıcı bilgilerden (isimler, e-postalar ve adresler) kaçının.

3. Sunucu sağlığı: Sunucunun yavaşlamasını önlemek için hız sınırlamaları kullanın; bir web sitesine "DDOS saldırısı" yapmaktan kaçının.

4. Telif Hakkı : Makaleler ve görseller telif hakkı ile korunmaktadır, ancak bilgiler (fiyatlar, tarihler) korunmamaktadır.

Web tarama ve web kazıma arasındaki fark nedir?

Web kazıma, hedef bir web sayfasındaki tüm içeriği taramak ve depolamak için web tarayıcıları kullanmaktır. Başka bir deyişle, web kazıma, yatırım analizi için tüm finans haberlerini çekmek ve belirli şirket adlarını aramak gibi hedefli bir veri kümesi oluşturmak için web taramanın özel bir kullanım örneğidir.

Geleneksel olarak, bir web tarayıcısı web sayfasının tüm öğelerini tarayıp dizine ekledikten sonra, bir web kazıyıcı dizine eklenmiş web sayfasından veri çıkarırdı. Ancak günümüzde kazıma ve tarama terimleri birbirinin yerine kullanılmaktadır; aradaki fark ise tarayıcı teriminin daha çok arama motoru tarayıcılarını ifade etmesidir. Arama motorları dışındaki şirketler de web verilerini kullanmaya başladıkça, web kazıyıcı terimi web tarayıcısının yerini almaya başladı.

Web tarama işlemlerinin zorlukları nelerdir?

1. Veritabanı güncelliği

Web sitelerinin içeriği düzenli olarak güncellenir. Örneğin, dinamik web sayfaları, ziyaretçilerin etkinliklerine ve davranışlarına bağlı olarak içeriklerini değiştirir. Bu, web sitesinin kaynak kodunun, web sitesini taradıktan sonra aynı kalmadığı anlamına gelir. Kullanıcıya en güncel bilgileri sağlamak için, web tarayıcısının bu web sayfalarını daha sık yeniden taraması gerekir.

2. Sürüngen tuzakları

Web siteleri, web tarayıcılarının belirli web sayfalarına erişmesini ve bunları taramasını engellemek için tarayıcı tuzakları gibi farklı teknikler kullanır. Bir tarayıcı tuzağı veya örümcek tuzağı, bir web tarayıcısının sonsuz sayıda istekte bulunmasına ve kısır bir tarama döngüsüne girmesine neden olur. Web siteleri ayrıca istemeden de tarayıcı tuzakları oluşturabilir. Her durumda, bir tarayıcı bir tarayıcı tuzağıyla karşılaştığında, tarayıcının kaynaklarını boşa harcayan sonsuz bir döngüye girer.

3. Ağ Bant Genişliği

Alakasız çok sayıda web sayfasını indirmek, dağıtılmış bir web tarayıcısı kullanmak veya birçok web sayfasını yeniden taramak, ağ kapasitesi tüketiminde yüksek bir orana yol açar.

4. Yinelenen sayfalar

Web tarayıcı botları çoğunlukla web üzerindeki tüm yinelenen içerikleri tarar; ancak bir sayfanın yalnızca bir sürümü dizine eklenir. Yinelenen içerik, arama motoru botlarının hangi yinelenen içerik sürümünü dizine ekleyeceğini ve sıralayacağını belirlemesini zorlaştırır. Googlebot, arama sonuçlarında bir grup özdeş web sayfası keşfettiğinde, kullanıcının arama sorgusuna yanıt olarak görüntülenecek bu sayfalardan yalnızca birini dizine ekler ve seçer.

En iyi 3 web tarama uygulaması

1. Nezaket/Tarama hızı

Web siteleri, web tarayıcı botlarının yaptığı istek sayısını sınırlamak için bir tarama hızı belirler. Tarama hızı, bir web tarayıcısının belirli bir zaman aralığında (örneğin, saatte 100 istek) web sitenize kaç istek yapabileceğini gösterir. Bu, web sitesi sahiplerinin web sunucularının bant genişliğini korumalarına ve sunucu aşırı yüklenmesini azaltmalarına olanak tanır. Bir web tarayıcısının hedef web sitesinin tarama sınırına uyması gerekir.

2. Robots.txt uyumluluğu

Robots.txt dosyası, bir web sitesinin kök dizinine yerleştirilen ve arama motoru botlarına hangi sayfalara erişmelerine izin verildiğini veya verilmediğini bildiren bir metin dosyasıdır. Gönüllü bir standarttır; yani uyumlu botlar buna saygı duyar, ancak teknik olarak erişimi engellemez. Bir web sitesinin robots.txt dosyasına uymak en iyi uygulama olarak kabul edilir ve birçok yargı bölgesinde bunu göz ardı etmek sizi yasal veya itibar riskine maruz bırakabilir.

3. IP rotasyonu

Web siteleri, tarayıcı trafiğini yönetmek ve web kazıma faaliyetlerini azaltmak için CAPTCHA gibi farklı kazıma önleme teknikleri kullanır. Örneğin, tarayıcı parmak izi alma, web sitelerinin ziyaretçiler hakkında oturum süresi veya sayfa görüntülemeleri gibi bilgiler toplamak için kullandığı bir izleme tekniğidir.

Bu yöntem, web sitesi sahiplerinin "insan dışı trafiği" tespit etmelerine ve botun IP adresini engellemelerine olanak tanır. Tespit edilmekten kaçınmak için, konut proxy'leri gibi dönen proxy'leri web tarayıcınıza entegre edebilirsiniz .

Web tarayıcıları kıyaslama metodolojisi

Dört tarama API'sini (Apify, Nimble, Cloudflare, Firecrawl) farklı zorluk seviyelerine sahip üç alanda test ettik: amazon.com (yoğun bot koruması), entrepreneur.com (karmaşık içerikli site) ve theregister.com (haber sitesi).

Paylaşılan yapılandırma

Adil bir karşılaştırma sağlamak amacıyla tüm sağlayıcılara aynı temel ayarlar uygulandı:

  • Site haritası: Devre dışı bırakıldı, sağlayıcılar sayfaları yalnızca HTML bağlantıları aracılığıyla keşfetmelidir.
  • Harici bağlantılar: Devre dışı bırakıldı, tarayıcılar hedef alan adı içinde kalır.
  • Alt alan adları: Etkinleştirildiğinde, alt alan adı sayfaları takip edilir (örneğin, india.entrepreneur.com)
  • JavaScript oluşturma: Etkinleştirildi, tüm sağlayıcılar başsız tarayıcı kullanıyor.
  • Önbellek: Devre dışı bırakıldı
  • Sayfa sınırı: Her çalıştırmada 1.000 sayfa
  • Zaman aşımı: 7 saat (25.200 saniye)
  • Hız sınırlaması yönetimi: HTTP 429'da 20 saniye bekleme ve en fazla 3 yeniden deneme.

Her sağlayıcı, üç alanın tamamında üç farklı maksimum derinlik seviyesinde (5, 10, 20) test edildi ve toplamda 36 tarama çalıştırıldı. Sağlayıcılar ardışık olarak (paralel değil) test edildi, her kombinasyon bir kez çalıştırıldı ve tarama durumu her 1 saniyede bir sorgulandı.

Apify, Playwright/Firefox'u başsız tarayıcı olarak kullanan web sitesi içerik tarayıcısı aktörüyle yapılandırılmıştır. Alt alan adı erişimi glob desenleri aracılığıyla kontrol edilmiş ve tüm istekler için Apify'un yerleşik proxy'si kullanılmıştır.

Nimble, Cloudflare ve Firecrawl, yukarıda açıklanan ortak ayarlar kullanılarak ilgili REST API'leri aracılığıyla yapılandırıldı. Standartlaştırılmış parametrelerin ötesinde, sağlayıcıya özgü ek yapılandırmalar uygulanmadı.

Cloudflare için Çalışanlar İçin Ücretli planı kullandık. Bildirilen maliyet, bu plan kapsamında 1.000 sayfayı taramak için harcadığımız tutarı yansıtmaktadır. Cloudflare, sayfa sayısına değil, tarayıcı oluşturma süresine göre ücretlendirme yapar.

Firecrawl için Hobi planını kullandık. Bildirilen maliyet, bu planda sağlanan kredilerden 1.000 kredi için orantılı tutardır. Sayfa başına etkin maliyet, plan kademesine ve ek kredi paketlerinin satın alınıp alınmamasına bağlı olarak değişir.

Cem Dilmegani
Cem Dilmegani
Baş Analist
Cem, 2017'den beri AIMultiple'da baş analist olarak görev yapmaktadır. AIMultiple, her ay Fortune 500 şirketlerinin %55'i de dahil olmak üzere yüz binlerce işletmeye (benzer Web'e göre) bilgi sağlamaktadır. Cem'in çalışmaları, Business Insider, Forbes, Washington Post gibi önde gelen küresel yayınlar, Deloitte, HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslararası kuruluşlar tarafından alıntılanmıştır. AIMultiple'ı referans gösteren daha fazla saygın şirket ve kaynağı görebilirsiniz. Kariyeri boyunca Cem, teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yapmıştır. On yıldan fazla bir süre McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararları konusunda danışmanlık yapmıştır. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayınlamıştır. Bir telekom şirketinin CEO'suna bağlı olarak teknoloji stratejisi ve tedarikini yönetmiştir. Ayrıca, 2 yıl içinde sıfırdan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetmiştir. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınlarında yer aldı. Cem düzenli olarak uluslararası teknoloji konferanslarında konuşmacı olarak yer almaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisliği diplomasına ve Columbia Business School'dan MBA derecesine sahiptir.
Tam Profili Görüntüle
Teknik olarak inceleyen
Nazlı Şipi
Nazlı Şipi
Yapay Zeka Araştırmacısı
Nazlı, AIMultiple'da veri analisti olarak çalışmaktadır. Daha önce çeşitli sektörlerde veri analizi alanında deneyim kazanmış olup, karmaşık veri kümelerini eyleme dönüştürülebilir içgörülere dönüştürme konusunda çalışmıştır.
Tam Profili Görüntüle

Yorumlar 1

Düşüncelerinizi Paylaşın

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.

0/450
Aggeliki
Aggeliki
Jan 12, 2022 at 16:15

Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.