Web Sitelerini Yapay Zekaya Beslemek için Web Crawler Benchmarkı

Dört crawl API'sini üç farklı zorluktaki alan adında, üç maksimum derinlik seviyesinde (5, 10, 20) 1.000 sayfa sınırıyla test ettik; crawl kapsamını, yürütme süresini, bağlantı keşfini, markdown bağlantı kalitesini ve başlık çıkarma doğruluğunu ölçtük.

Amacınız şunlarsa:

• Web sayfalarını yapılandırılmış verilere dönüştürmek istiyorsanız, web scraping rehberimize bakın.
• Web sitelerinin tamamını crawl etmek istiyorsanız okumaya devam edin.

Web crawler benchmarkı

Benchmark metodolojimize göz atabilirsiniz.

Ortalama crawl edilen sayfa sayısı ile 1.000 sayfa başına maliyet

Maksimum derinliğe göre alan adları genelinde taranan sayfalar

Firecrawl, maksimum derinlikten bağımsız olarak theregister.com'da sürekli yaklaşık 100 sayfa, entrepreneur.com'da tüm derinlik seviyelerinde yaklaşık 90 sayfa ve amazon.com'da yalnızca yaklaşık 30 sayfa taradı; bu büyük olasılıkla Amazon'un agresif bot korumasından kaynaklanıyor. Dikkat çekici şekilde, maksimum derinliği artırmak Firecrawl'ın herhangi bir alan adında tarayabildiği sayfa sayısı üzerinde neredeyse hiçbir etki yaratmadı.

Apify, Amazon gibi yoğun korunan sitelerde bile belirgin bir zorluk yaşamadan her alan adında ve her derinlik seviyesinde 1.000 sayfalık maksimum crawl sınırına ulaşarak en tutarlı performansı gösterdi.

Cloudflare testlerde tutarsız davranışlar sergiledi:

• theregister.com'da maksimum derinlik 5'te yalnızca 100 sayfa taradı, ancak maksimum derinlik 20'de yaklaşık 1.000 sayfaya ulaştı.
• Daha önceki testlerde gözlemlediğimiz gibi, Cloudflare zaman yalnızca 1 sayfa tarayıp işi tamamen sonlandırıyor. Bunun bir önbellek sorunu olmadığını doğruladık (önbellek devre dışı bırakıldı) ve çalıştırmalar arasında 1 dakikaya kadar bekleme süreleriyle test ettik, ancak davranış devam etti. theregister.com'da maksimum derinlik 10'da bu sorun aynen yaşandı; Cloudflare durmadan önce yalnızca 1 sayfa taradı.
• entrepreneur.com'da Cloudflare, derinlik 5'te 780 sayfa taradı, derinlik 10'da 885'e yükseldi, ancak daha sonra derinlik 20'de yalnızca 172 sayfaya sert bir şekilde düştü. Bu düşüş, Cloudflare'in crawl zamanlayıcısının daha derin bağlantı zincirlerini düşük önceliklendirmesi veya zaman aşımına uğratmasıyla ilgili olabilir ya da yüksek derinliklerde crawl frontier'ı çok büyüdüğünde işin erken sonlanmasına neden olan bir iç eşzamanlılık sınırını yansıtabilir.
• amazon.com'da Cloudflare, derinlik 5'te 905 sayfa taradı, ancak maksimum derinlik arttıkça sayı istikrarlı şekilde azaldı; derinlik 10'da 809'a ve derinlik 20'de 795'e düştü. Bu da daha derin crawl yapılandırmalarının Cloudflare'in gerçek sayfa getirme yerine bağlantı keşfi ek yüküne daha fazla zaman harcamasına neden olabileceğini gösteriyor.

Nimble, theregister.com'da tüm derinlik seviyelerinde 1.000 sayfa sınırına ulaştı veya yaklaştı (1.000 / 1.000 / 999). entrepreneur.com'da derinlik 5'te 1.000 sayfa taradı ancak daha yüksek derinliklerde hafif düşüşler gösterdi (derinlik 10'da 896, derinlik 20'de 983); bunun nedeni muhtemelen daha derin seviyelerde tam crawl tamamlanmadan 7 saatlik zaman aşımına ulaşılmasıydı. Tüm Nimble çalıştırmaları zaman aşımı durumuyla sona erdi. Amazon daha zorlayıcı oldu:

• Derinlik 5'te yalnızca 319 sayfa tarayabildi, ancak derinlik 10'da 988 sayfaya fırladı, ardından derinlik 20'de 906'ya düştü
• Bu tutarsızlık muhtemelen Amazon'un bot koruma mekanizmaları ile Nimble'ın zaman aşımı kısıtlamalarının birleşimini yansıtıyor; daha derin crawl'lar her sayfayı işlemek için daha uzun sürüyor ve yol boyunca daha fazla anti-bot zorluğuyla karşılaşabiliyor.

Maksimum derinliğe göre alan adları genelinde yürütme süresi

Firecrawl, tüm alan adlarında en hızlı sağlayıcıydı; crawl'ları 5 dakikanın altında, tipik olarak 75-265 saniye arasında tamamladı. Bu hız kapsamdan ödün verilmesi pahasına geliyor; çünkü Firecrawl aynı zamanda en az sayfayı taradı. Esasen erken durduğu için hızlı bitiriyor.

Apify, 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 yürütme süreleri belirgin şekilde daha uzundu: 8.300-15.900 saniye (2-4 saat); bu da daha büyük ve daha karmaşık site yapılarını yansıtıyor. Daha uzun sürelere rağmen Apify sürekli olarak 1.000 sayfa sınırına ulaştı ve kapsama-süre oranı açısından en güvenilir sağlayıcı oldu.

Cloudflare'in süreleri, tutarsız crawl sayılarını yansıtıyordu:

• theregister.com'da derinlik 10'da, durmadan önce yalnızca 1 sayfa taradığı için yalnızca 1 saniyede tamamladı.
• entrepreneur.com'da derinlik 20'de yalnızca 172 sayfa taradıktan sonra 10 saniyede bitti.
• Cloudflare tam bir crawl tamamladığında süreler 3.500 ila 25.200 saniye arasında değişiyor.
• Maksimum derinlik arttıkça, Cloudflare genişlikten çok daha derin sayfalara ulaşmaya öncelik veriyor gibi görünüyor; daha az sayfa tarıyor ancak daha hızlı tamamlıyor. amazon.com'da derinlik 5'te 25.200 saniyeden (zaman aşımı) derinlik 20'de yalnızca 5.660 saniyeye düştü; taranan sayfalar da 905'ten 795'e geriledi. Bu, Cloudflare'in crawler'ının daha yüksek derinliklerde stratejisini değiştirdiğini, geniş keşif yerine derin gezinmeye daha az zaman harcadığını gösteriyor.

Nimble, tüm alan adlarında ve derinlik seviyelerinde her bir çalıştırmada 7 saatlik zaman aşımına (25.200 saniye) takıldı. Bu dikkat çekici; çünkü daha önceki maksimum derinlik 1 ile yaptığımız hızlı testlerde Nimble zaman aşımına uğramadan tamamlamıştı. Derinliklerin 5-20 olduğu ve 1.000 sayfa sınırının bulunduğu tam benchmark'ta, zaman aşımına ulaşılana kadar sürekli çalıştı. Buna rağmen Nimble çoğu durumda hâlâ yüksek sayıda sayfa taramayı başardı (theregister.com ve entrepreneur.com'da ~900-1.000); bu da 7 saat boyunca aktif olarak crawl yaptığı ancak tamamlanma sinyali hiç vermediği anlamına geliyor.

Maksimum derinliğe göre sağlayıcılar genelinde bağlantı metni doldurma oranı

Markdown çıktı kalitesini değerlendirmek için, her sağlayıcının markdown'undaki bağlantıların yüzde kaçının anchor metni, yani bir bağlantının tıklanabilir metin kısmını içerdiğini ölçtük. Eksik anchor metni (ör. [About Us](/about) yerine [](/about)) crawler'ı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 anchor metni eksik

Crawl derinliğinin hiçbir sağlayıcı için doldurma oranları üzerinde minimum etkisi oldu; bu da bunun bir crawl ayarından ziyade her sağlayıcının ayrıştırma motorunun bir özelliği olduğunu gösteriyor.

Alan adına göre sağlayıcılar genelinde bağlantı metni doldurma oranı

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

• Nimble tüm alan adlarında %100 seviyesini korudu.
• Apify en fazla değişkenliği gösterdi; amazon.com'da %89 iken entrepreneur.com'da %66'ya düştü; bu, o sitedeki bağlantılarının üçte birinde anchor metninin eksik olduğu anlamına geliyor. Bu, Apify'ın karmaşık navigasyon yapılarına sahip içerik ağırlıklı sitelerde daha fazla zorlandığını gösteriyor.
• Firecrawl theregister.com'da en iyi performansı gösterdi (%98), ancak entrepreneur.com'da %81'e düşerek Apify ile benzer bir model izledi.
• Cloudflare, Nimble'dan sonra en tutarlısıydı; alan adından bağımsız olarak 89-%94 arasında kaldı.

Entrepreneur.com bağlantı metni çıkarma için en zorlu alan adı oldu; hem Apify (%66) hem de Firecrawl (%81) en düşük skorlarını burada aldı. Bunun nedeni muhtemelen sitenin iç içe geçmiş navigasyon menülerini ve markdown'a temiz şekilde dönüştürülmesi daha zor olan dinamik içerik öğelerini yoğun olarak kullanması.

Maksimum derinliğe göre alan adları genelinde markdown çıktısındaki toplam bağlantılar

Sağlayıcılar arasındaki bağlantı sayısı değişkenliği sürekli olarak yüksekti (74-%97); bu, sağlayıcıların aynı sayfalardan çok farklı sayıda bağlantı çıkardığını gösteriyor. Bu eşitsizliği daha ayrıntılı görmek için sağlayıcı başına 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 derinlik 5'te 420K'den fazla bağlantı (sayfa başına ~423) elde etti. entrepreneur.com'da derinlikten bağımsız olarak yaklaşık 63K bağlantıda dengelendi. Çıktısı, sayfa içeriği bağlantılarının yanında reklam izleyicileri ve izleme pikselleri içeriyor.
• Cloudflare, entrepreneur.com'da derinlik 10'da 303K ile zirve yaptı ancak derinlik 20'de 53K'ya düştü. Aynı entrepreneur.com ana sayfasında Cloudflare, Apify'ın 143 bağlantısına karşılık 434 bağlantı çıkardı ve tam navigasyon menüleri ile alt menüleri yakaladı.
• Firecrawl, düşük sayfa sayısı nedeniyle sınırlı kalarak tüm yapılandırmalarda sürekli olarak 5-9K bağlantı döndürdü.
• Nimble, toplamda 3-40K bağlantı döndürdü; diğer sağlayıcıların 60-420 bağlantısına kıyasla sayfa başına ortalama 5-28 bağlantı elde etti. entrepreneur.com ana sayfasında Nimble, Cloudflare'in 434 bağlantısına karşılık 13 bağlantı döndürdü ve yalnızca ana makale başlıklarıyla sınırlı kaldı. %100 doldurma oranı, kapsamlı bağlantı kapsamına işaret etmekten çok dahil ettiği bağlantıların tümünün anchor metnine sahip olduğunu gösteriyor. Nimble standart markdown bağlantıları çıkarmaz. Sayısı, markdown çıktısında bulunan kaçışlı HTML bağlantılarını içerir.

Sağlayıcılar genelinde başlık bulunma oranı

Sağlayıcılar arasındaki başlık benzerliği tüm testler ve alan adlarında %1'den az sapma gösterdi; bu da sağlayıcılar bir başlık çıkardığında sürekli aynı sonucu döndürdüğünü doğruluyor. Başlık bulunma oranı da tüm maksimum derinlik seviyelerinde 98-%100 arasında kaldı; bu, crawl derinliğinin başlık çıkarma üzerinde anlamlı bir etkisi olmadığını gösteriyor.

Alan adına göre ayrıştırıldığında 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 ve Nimble %95,9'a düşerken Apify %99,6 seviyesini korudu. Bu, Amazon'un sayfa yanıtlarını engelleyebilen veya bozabilen daha ağır bot korumasıyla örtüşüyor; bazı sağlayıcılar bu nedenle çıkarılabilir başlığı olmayan sayfalar döndürüyor.

Web crawler nedir?

Bazen “spider” veya “agent” olarak adlandırılan bir web crawler, içeriği dizinlemek için internette gezinen bir bot'tur.

Crawler'lar arama motorlarının ötesine geçti ve artık Agentic Data Layer olarak hizmet veriyor. Claude Code ve OpenAI Operator gibi otonom yapay zeka ajanları için göz işlevi görüyor; rekabet araştırması ve çok adımlı işlemler gibi gerçek zamanlı görevlerde yardımcı oluyor.

Web crawler ne yapar?

Web crawling, her biri farklı bir crawler hedefi için tasarlanmış üç moda ayrılmıştır.

1. Keşif modu (geleneksel): Googlebot gibi arama motoru bot'ları, dizinleme için URL'leri tarar ve insanların arama motorları aracılığıyla sonuçları bulmasına yardımcı olur.
2. Getirme Modu (RAG): ChatGPT-User veya PerplexityBot gibi yapay zeka bot'ları, kullanıcı prompt'larını yanıtlamak için belirli sayfaları gerçek zamanlı olarak getirir. Yapay zeka modelinin token sınırlarına uymak için HTML yerine markdown kullanırlar.
3. Ajan Modu (Eylem Odaklı): 2026'daki bu yeni crawler türü yalnızca içerik okumaktan fazlasını yapar. Model Context Protocol (MCP) kullanarak bu bot'lar web siteleriyle etkileşime geçip uçuş rezervasyonu yapabilir veya yazılım komutları çalıştırabilir.

Geçmişte crawler'lar veri çıkarmak için XPath veya CSS gibi seçiciler kullanıyordu. Yapay Zeka Yerel Çıkarımı norm haline geldi.

Firecrawl ve Crawl4AI gibi araçlar, veri bulmak için doğal dil talimatları kullanır. Geliştiriciler her öğe için kural yazmak yerine crawler'a “ürün fiyatını çıkar” diyebilir ve web sitesinin kodu değişse bile yapay zeka doğru değeri bulur.

Yapay zeka çağında web crawler'ları geliştirmek mi, satın almak mı?

1. Kendi Crawler'ınızı Geliştirmek

Çekirdek fikri mülkiyeti korumak ve derin özelleştirme sağlamak için idealdir. Günümüzde geliştirme, yalnızca temel Scrapy script'leri yazmayı değil, özel bir ajan katmanı geliştirmeyi gerektiriyor.

• Ne zaman geliştirmeli: Crawler'ı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 ya da düzenlemeye tabi veriler üzerinde tam denetim gerekiyorsa kendiniz geliştirin.
• Araç seti: Artık sıfırdan başlamanıza gerek yok. Geliştiriciler, dahili yapay zeka ajanlarının web ile etkileşime girmesini sağlamak için Model Context Protocol'ü (MCP) kullanıyor.

2. Web Crawling Araçları ve API'leri Kullanmak

Yönetilen araçlar temel scraper'lardan otonom ajanlara dönüştü.

• Sıfır bakım çıkarımı: Kadoa ve Firecrawl gibi modern araçlar kendini onaran yapay zeka kullanır. Kod içindeki konumu yerine “Ürün Fiyatı” gibi gereken veriyi 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ı ile yerleşik uyumluluk sunar. Bağımsız olarak uygulanması zor olan gerekli denetim günlüklerini ve telif hakkı devre dışı bırakma kontrollerini yönetirler.
• Değere ulaşma hızı: Bir platform satın almak projenizi konseptten üretime haftalar içinde taşıyabilir.

Web crawler'lar yasal mı?

Genel olarak web crawling yasaldır, ancak neyi ve nasıl taradığınıza bağlı olarak hızla yasal bir açmaza düşebilirsiniz. Crawling'in (ve genellikle ardından gelen scraping'in) yasal olup olmadığını belirleyen dört temel sütun vardır:

1. Genel ve özel: Yalnızca hesap olmadan kamuya açık olan verileri tarayın.

2. Kişisel bilgiler: Yasal bir dayanağınız olmadıkça PII'den (adlar, e-postalar ve adresler) uzak durun.

3. Sunucu sağlığı: Sunucuyu yavaşlatmamak için oran sınırları kullanın; bir web sitesine “DDOS” yapmaktan kaçının.

4. Telif hakkı: Makaleler ve görseller telif hakkıyla korunur, ancak olgular (fiyatlar, tarihler) korunmaz.

Web crawling ile web scraping arasındaki fark nedir?

Web scraping, hedeflenen bir web sayfasındaki tüm içeriği taramak ve depolamak için web crawler'ları kullanmaktır. Başka bir deyişle web scraping, yatırım analizi için tüm finans haberlerini çekmek ve belirli şirket adlarını aramak gibi hedeflenmiş bir dataset oluşturmak amacıyla web crawling'in belirli bir kullanım durumudur.

Geleneksel olarak, bir web crawler web sayfasının tüm öğelerini tarayıp dizinledikten sonra, bir web scraper dizinlenen web sayfasından veri çıkarırdı. Ancak günümüzde scraping ve crawling terimleri birbirinin yerine kullanılıyor; aralarındaki fark, crawler teriminin daha çok arama motoru crawler'larını ifade etme eğiliminde olmasıdır. Arama motorları dışındaki şirketler web verilerini kullanmaya başladıkça web scraper terimi web crawler teriminin yerini almaya başladı.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Web crawling'in zorlukları nelerdir?

1. Veritabanı tazeliği

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

2. Crawler tuzakları

Web siteleri, web crawler'ların belirli web sayfalarına erişmesini ve bunları taramasını önlemek için crawler tuzakları gibi farklı teknikler kullanır. Crawler tuzağı veya spider tuzağı, web crawler'ın sonsuz sayıda istek yapmasına ve kısır bir tarama döngüsüne hapsolmasına neden olur. Web siteleri istemeden de crawler tuzakları oluşturabilir. Her durumda, bir crawler bir crawler tuzağıyla karşılaştığında crawler'ın kaynaklarını boşa harcayan sonsuz bir döngüye girer.

3. Ağ Bant Genişliği

Çok sayıda ilgisiz web sayfasını indirmek, dağıtılmış bir web crawler kullanmak veya birçok web sayfasını yeniden taramak, ağ kapasitesinin yüksek oranda tüketilmesine neden olur.

4. Yinelenen sayfalar

Web crawler bot'ları web üzerindeki tüm yinelenen içeriği çoğunlukla tarar; ancak bir sayfanın yalnızca bir sürümü dizinlenir. Yinelenen içerik, arama motoru bot'larının hangi yinelenen içerik sürümünü dizinleyip sıralayacağını belirlemesini zorlaştırır. Googlebot bir arama sonucunda bir grup özdeş web sayfası bulduğunda, kullanıcının arama sorgusuna yanıt olarak görüntülemek üzere bu sayfalardan yalnızca birini dizinler ve seçer.

En iyi 3 web crawling uygulaması

1. Nezaket/Crawl oranı

Web siteleri, web crawler bot'ları tarafından yapılan istek sayısını sınırlamak için bir crawl oranı belirler. Crawl oranı, belirli bir zaman aralığında bir web crawler'ın web sitenize kaç istek yapabileceğini gösterir (ör. saatte 100 istek). Bu, web sitesi sahiplerinin web sunucularının bant genişliğini korumasını ve sunucu aşırı yükünü azaltmasını sağlar. Bir web crawler hedef web sitesinin crawl sınırına uymalıdır.

2. Robots.txt uyumluluğu

Robots.txt dosyası, bir web sitesinin kök dizinine yerleştirilen ve crawler'lara hangi sayfalara erişmelerine izin verildiğini veya verilmediğini söyleyen bir metin dosyasıdır. Gönüllü bir standarttır; uyumlu bot'lar buna saygı gösterir, ancak erişimi teknik olarak engellemez. Bir web sitesinin robots.txt dosyasına uymak en iyi uygulama olarak kabul edilir ve birçok yargı bölgesinde bunu yok saymak yasal veya itibari risk doğurabilir.

3. IP rotasyonu

Web siteleri, crawler trafiğini yönetmek ve web scraping faaliyetlerini azaltmak için CAPTCHA'lar gibi anti-scraping teknikleri kullanır. Örneğin tarayıcı parmak izi, web sitelerinin ziyaretçiler hakkında oturum süresi veya sayfa görüntülemeleri gibi bilgileri toplamak için kullandığı bir izleme tekniğidir.

Bu yöntem, web sitesi sahiplerinin “insan dışı trafiği” tespit etmesine ve bot'un IP adresini engellemesine olanak tanır. Tespit edilmemek için rotating proxy'leri, örneğin residential proxy'leri, web crawler'ınıza entegre edebilirsiniz.

Web crawler'lar benchmark metodolojisi

Zorluk derecesi değişen üç alan adında dört crawl API'sini (Apify, Nimble, Cloudflare, Firecrawl) test ettik: amazon.com (ağır bot koruması), entrepreneur.com (karmaşık içerik sitesi) ve theregister.com (haber sitesi).

Ortak yapılandırma

Adil bir karşılaştırma sağlamak için tüm sağlayıcılar aynı çekirdek ayarları aldı:

• Sitemap: Devre dışı; sağlayıcılar sayfaları yalnızca HTML bağlantıları aracılığıyla keşfetmelidir
• Dış bağlantılar: Devre dışı; crawler'lar hedef alan adı içinde kalır
• Alt alan adları: Etkin; alt alan adı sayfaları takip edilir (ör. india.entrepreneur.com)
• JavaScript oluşturma: Etkin; tüm sağlayıcılar headless tarayıcı kullanır
• Önbellek: Devre dışı
• Sayfa sınırı: Çalıştırma başına 1.000 sayfa
• Zaman aşımı: 7 saat (25.200 saniye)
• Oran sınırı yönetimi: HTTP 429'da en fazla 3 yeniden deneme ile 20 saniye bekleme

Her sağlayıcı, üç alan adının tamamında üç maksimum derinlik seviyesinde (5, 10, 20) test edildi; toplam 36 crawl çalıştırması yapıldı. Sağlayıcılar sırayla (paralel değil) test edildi, her kombinasyon bir kez çalıştırıldı ve crawl durumu her 1 saniyede bir sorgulandı.

Apify, headless tarayıcı olarak Playwright/Firefox kullanan website-content-crawler actor'ı ile yapılandırıldı. Alt alan adı erişimi glob desenleri aracılığıyla kontrol edildi ve tüm istekler için Apify'ın yerleşik proxy'si kullanıldı.

Nimble, Cloudflare ve Firecrawl, yukarıda açıklanan paylaşılan ayarlarla kendi REST API'leri kullanılarak yapılandırıldı. Standartlaştırılmış parametrelerin ötesinde sağlayıcıya özel ek yapılandırma uygulanmadı.

Cloudflare için Workers Paid planını kullandık. Bildirilen maliyet, bu plan kapsamında 1.000 sayfayı taramak için harcadığımız tutarı yansıtıyor. Cloudflare, sayfa sayısı yerine tarayıcı oluşturma süresine göre ücretlendiriyor.

Firecrawl için Hobby planını kullandık. Bildirilen maliyet, bu planda sağlanan kredilerden 1.000 kredi için orantılı tutardır. Etkili sayfa başına maliyet, plan kademesine ve ekstra kredi paketlerinin satın alınıp alınmadığına bağlı olarak değişir.

Bu benchmarkı kaynak gösterin

Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Web Sitelerini Yapay Zekaya Beslemek için Web Crawler Benchmarkı}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Erişim tarihi: 11 Ağustos 2026}
}

Değişiklik günlüğü

9 güncelleme

Tümü9Genel8Metodoloji1

1. 20267 Nis

   Sektör trendleri, tarayıcı türleri ve web tarama örnekleri bölümleri kaldırıldı.

2. 6 Nis

   Dört tarama API'sinin üç alan adı ve üç derinlik seviyesinde karşılaştırıldığı; kapsam, hız, bağlantı ve başlık grafikleri içeren bir kıyaslama eklendi.

3. 6 Nis

   Dört sağlayıcı, üç alan adı ve üç derinlik düzeyindeki tarama kurulumunu ayrıntılandıran bir metodoloji bölümü eklendi.

4. 25 Şub

   Makaleye "Web tarayıcıları yasal mı?" başlıklı bir bölüm eklendi.

5. 11 Şub

   Yeni trendler ve çalışma modları ile "Web tarayıcısı nedir?" bölümü güncellendi.

6. 202411 Eki

   “En iyi web tarayıcıları” bölümündeki yıl güncellendi.

7. 202313 Eki

   Girişe 2023'ün en iyi web tarayıcılarının hızlı bir özetini ekledi.

8. 29 Ağu

   “Web taraması neden önemli?” bölümü kaldırıldı.

9. 9 Oca

   Giriş, web tarayıcısı ve web kazıma tanımıyla genişletildi.

Cem Dilmegani

Baş Analist

Takip Et

Cem, 2017'den beri AIMultiple bünyesinde baş analisttir. Cem'in AIMultiple'daki çalışmaları; Business Insider, Forbes, Morning Brew ve Washington Post gibi önde gelen küresel yayınlar, Deloitte ve HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslarüstü kuruluşlar tarafından alıntılanmıştır. [1], [2], [3], [4], [5] Kariyeri boyunca Cem; teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yaptı. On yılı aşkın süre boyunca McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararlarında danışmanlık yaptı. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayımladı. CEO'ya rapor verirken bir telekom şirketinin teknoloji stratejisini ve satın alma süreçlerini yönetti. Ayrıca 2 yıl içinde 0'dan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetti. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınları tarafından ele alındı. Cem, uluslararası teknoloji konferanslarında düzenli olarak konuşma yapmaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisi olarak mezun oldu ve Columbia Business School'dan MBA derecesine sahiptir.

Tam Profili Görüntüle

Teknik olarak inceleyen

Nazlı Şipi

Yapay Zeka Araştırmacısı

Takip Et

Nazlı, AIMultiple'da veri analistidir. Çeşitli sektörlerde veri analizi konusunda önceden deneyime sahiptir; burada karmaşık dataset'leri eyleme dönüştürülebilir içgörülere dönüştürme üzerine ç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. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder

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.

Yanıtla