Loading article…
ウェブクローラーは、スパイダーまたはスパイダーボットとも呼ばれ、クローラーと略されることが多いインターネットボットで、ワールドワイドウェブを体系的に閲覧し、通常は検索エンジンによってウェブインデックス作成（ウェブスパイダリング）の目的で運用されます。[ 1 ]
ウェブ検索エンジンや一部のウェブサイトは、ウェブクローリングまたはスパイダーリングと呼ばれるソフトウェアを使用して、自社のウェブコンテンツや他のサイトのウェブコンテンツのインデックスを更新します。ウェブクローラーは検索エンジンが処理できるようにページをコピーし、検索エンジンはダウンロードしたページをインデックス化することで、ユーザーがより効率的に検索できるようにします。
クローラーは訪問先のシステム上でリソースを消費し、多くの場合、指示なしにサイトを訪問します。大量のページにアクセスする場合、スケジュール、負荷、および「礼儀」といった問題が生じます。クロールを希望しない公開サイトは、クロールエージェントにその旨を伝えるための仕組みが用意されています。例えば、特定のファイルを含めることで、ボットにウェブサイトの一部のみをインデックス化するよう、あるいは全くインデックス化しないようrobots.txt要求できます。
ウェブページの数は非常に多く、検索エンジンはすべてのウェブコンテンツをインデックス化しているわけではありません。1990年代後半の検索エンジンの調査では、個々のエンジンが当時インデックス化可能だったウェブのごく一部しかインデックス化していなかったことが分かりました。[ 2 ] [ 3 ]現代の検索エンジンは、クローリング、インデックス化、ランキングシステムを使用して関連性の高い結果を迅速に返しますが、すべてのページがクローリング、インデックス化、または配信されるわけではありません。[ 4 ]
クローラーはハイパーリンクやHTMLコードを検証できます。また、ウェブスクレイピングやデータ駆動型プログラミングにも利用できます。
ウェブクローラーは、スパイダー[ 5 ]、アリ、自動インデクサー[ 6 ]、または（FOAFソフトウェアの文脈では）ウェブスカッター[ 7 ]とも呼ばれます。
ウェブクローラーは、訪問するURLのリストから始まります。これらの最初の URL はシードと呼ばれます。クローラーはこれらの URL を訪問し、これらの URL に応答するウェブサーバーと通信することで、取得したウェブページ内のすべてのハイパーリンクを識別し、訪問する URL のリスト(クロールフロンティアと呼ばれます) に追加します。フロンティアの URL は、一連のポリシーに従って再帰的に訪問されます。クローラーがWeb サイト(またはウェブアーカイブ) のアーカイブを実行している場合、クローラーは移動しながら情報をコピーして保存します。アーカイブは通常、ライブ Web 上にあるかのように表示、読み取り、ナビゲートできる方法で保存されますが、「スナップショット」として保存されます。[ 8 ]
データ量が多いということは、クローラーが一定時間内にダウンロードできるWebページ数に限りがあるため、ダウンロードの優先順位付けが必要になることを意味します。更新頻度が高いということは、ページが既に更新されているか、あるいは削除されている可能性があることを示唆しています。
サーバーサイドソフトウェアによって生成されるクロール可能なURLの数が増えたことで、Webクローラーが重複コンテンツの取得を回避することが難しくなっています。HTTP GET（URLベース）パラメータの組み合わせは無数に存在し、実際に一意のコンテンツを返すのはそのうちのごく一部だけです。たとえば、シンプルなオンラインフォトギャラリーでは、URLのHTTP GETパラメータで指定されるように、ユーザーに3つのオプションが提供される場合があります。画像の並べ替え方法が4種類、サムネイルサイズが3種類、ファイル形式が2種類、ユーザー提供コンテンツを無効にするオプションがある場合、同じコンテンツセットにアクセスできるURLは48種類にもなり、それらはすべてサイト上でリンクされている可能性があります。このような数学的な組み合わせはクローラーにとって問題となります。クローラーは、一意のコンテンツを取得するために、比較的小さなスクリプト変更の無数の組み合わせを選別しなければならないからです。
Edwardsらが指摘しているように、「クロールを実行するための帯域幅は無限でも無料でもないため、ある程度の品質や鮮度を維持するには、スケーラブルであるだけでなく効率的な方法で Web をクロールすることが不可欠になりつつある」[ 9 ]。クローラーは、各ステップで次に訪問するページを慎重に選択する必要がある。
ウェブクローラーの動作は、ポリシーの組み合わせの結果です。[ 10 ]
現在のウェブの規模を考えると、大規模な検索エンジンでさえ、公開されている部分の一部しかカバーしていません。2009年の調査では、大規模な検索エンジンでさえ、インデックス可能なウェブの40～70%しかインデックスしていないことが示されました。[ 11 ]スティーブ・ローレンスとリー・ジャイルズによる以前の調査では、1999年にはどの検索エンジンもウェブの16%以上をインデックスしていなかったことが示されています。 [ 12 ]クローラーは常にウェブページのごく一部しかダウンロードしないため、ダウンロードされる部分にはウェブのランダムなサンプルではなく、最も関連性の高いページが含まれていることが非常に望ましいです。
これには、Webページの優先順位付けのための重要度指標が必要です。ページの重要度は、そのページ本来の品質、リンク数や訪問数といった人気度、さらにはURL（後者は、単一のトップレベルドメインに限定された垂直型検索エンジンや、固定されたWebサイトに限定された検索エンジンの場合）によって決まります。優れた選択ポリシーを設計するには、さらに困難が伴います。クローリング中にWebページの完全なセットがわからないため、部分的な情報に基づいて作業する必要があるからです。
Junghoo Choらは、クローリング スケジューリングのポリシーに関する最初の研究を行った。彼らのデータセットは、stanford.edu異なる戦略でクローリング シミュレーションを行ったドメインからの 180,000 ページのクローリングであった。[ 13 ]テストされた順序付け指標は、幅優先、バックリンク数、部分PageRank計算であった。結論の 1 つは、クローラーがクローリング プロセスの早い段階で高い PageRank を持つページをダウンロードしたい場合、部分 PageRank 戦略が優れており、次に幅優先とバックリンク数が続くということであった。ただし、これらの結果は単一のドメインのみに関するものである。Cho はスタンフォード大学でウェブ クローリングに関する博士論文も執筆した。[ 14 ]
Marc Najorkと Janet Wiener は、幅優先順序を使用して 3 億 2800 万ページに対して実際のクロールを実行しました。[ 15 ]彼らは、幅優先クロールでは PageRank が高いページがクロールの早い段階で捕捉されることを発見しました (ただし、この戦略を他の戦略と比較していません)。この結果に対する著者らの説明は、「最も重要なページには多数のホストから多くのリンクがあり、クロールの開始ホストやページに関係なく、それらのリンクは早い段階で見つかる」というものです。
Abiteboul はOPIC (Online Page Importance Computation) と呼ばれるアルゴリズムに基づいたクローリング戦略を設計しました。 [ 16 ] OPIC では、各ページに初期値として「キャッシュ」が与えられ、それが指し示すページに均等に分配されます。これは PageRank 計算に似ていますが、より高速で、1 つのステップで実行されます。OPIC 駆動のクローラーは、クローリング フロンティア内で「キャッシュ」の値が高いページを最初にダウンロードします。実験は、インリンクがべき乗則分布に従う 100,000 ページの合成グラフで行われました。ただし、他の戦略との比較や実際の Web での実験は行われませんでした。
Boldiらは、ドメインからの 4,000 万ページと WebBase クロールからの 1 億ページの Web サブセットでシミュレーションを使用し.it、幅優先探索と深さ優先探索、ランダム順序付け、全知探索戦略を比較しました。比較は、部分的なクロールで計算された PageRank が真の PageRank 値にどれだけ近似しているかに基づいています。PageRank が非常に速く蓄積される訪問 (特に幅優先探索と全知探索) は、非常に悪い漸進的近似を提供します。[ 17 ] [ 18 ]
Baeza-Yatesらは、 Web の 2 つのサブセット (300 万ページ) でシミュレーションを行い、いくつ.grか.clのクローリング戦略をテストしました。[ 19 ]彼らは、OPIC 戦略とサイトごとのキューの長さを使用する戦略の両方が幅優先クローリングよりも優れていること、また、以前のクローリングが利用可能な場合は、それを使用して現在のクローリングをガイドすることも非常に効果的であることを示しました。
Daneshpajouhらは、優れたシードを発見するためのコミュニティベースのアルゴリズムを設計しました。[ 20 ]彼らの方法は、ランダムなシードから開始するクロールと比較して、異なるコミュニティから PageRank の高い Web ページを少ない反復回数でクロールします。この新しい方法を使用すると、以前にクロールされた Web グラフから優れたシードを抽出できます。これらのシードを使用すると、新しいクロールが非常に効果的になります。
クローラーは、HTML ページのみを検索し、他のMIME タイプをすべて回避したい場合があります。HTML リソースのみを要求するために、クローラーは HTTP HEAD リクエストを実行して Web リソースの MIME タイプを判別してから、GET リクエストでリソース全体を要求することがあります。多数の HEAD リクエストを回避するために、クローラーは URL を調べ、URL が .html、.htm、.asp、.aspx、.php、.jsp、.jspx、またはスラッシュなどの特定の文字で終わる場合にのみリソースを要求することがあります。この戦略により、多数の HTML Web リソースが意図せずスキップされる可能性があります。
クローラーによっては、ウェブサイトから無数のURLをダウンロードしてしまうスパイダートラップを回避するため、「?」を含むリソース（動的に生成されるリソース）のリクエストを避ける場合があります。ただし、サイトがURL書き換えを使用してURLを簡略化している場合は、この戦略は信頼できません。
ウェブサイトの所有者は、 robots.txtファイルを使用して、クローラーが要求できるリソースと要求できないリソースを指示できます。クローラーはその情報に基づいて、どのリンクをたどるべきか、どのリンクを避けるべきかを選択できます。
クローラーは通常、同じリソースを複数回クロールしないように、何らかのURL 正規化を実行します。URL正規化（URL カノニカリゼーションとも呼ばれる）とは、URL を一貫した方法で変更および標準化するプロセスを指します。URL を小文字に変換したり、「.」と「..」セグメントを削除したり、空でないパス コンポーネントに末尾のスラッシュを追加したりするなど、いくつかの種類の正規化が実行される場合があります。[ 21 ]
一部のクローラーは、特定の Web サイトから可能な限り多くのリソースをダウンロード/アップロードすることを目的としています。そのため、クロール対象とする各 URL のすべてのパスを遡るパス上昇クローラーが導入されました。 [ 22 ]例えば、シード URL がhttp://llama.org/hamster/monkey/page.htmlの場合、/hamster/monkey/、/hamster/、および / をクロールしようとします。Cothey は、パス上昇クローラーが、孤立したリソース、または通常のクロールではインバウンドリンクが見つからないリソースを見つけるのに非常に効果的であることを発見しました。
クローラーにとってのページの重要性は、ページと特定のクエリとの類似性の関数としても表現できます。互いに類似したページをダウンロードしようとするウェブクローラーは、フォーカスクローラーまたはトピッククローラーと呼ばれます。トピッククロールとフォーカスクロールの概念は、Filippo Menczer [ 23 ] [ 24 ]と Soumen Chakrabartiら[ 25 ]によって初めて導入されました。
フォーカスクローリングの主な問題は、Web クローラーのコンテキストでは、ページを実際にダウンロードする前に、特定のページのテキストとクエリの類似性を予測できることです。考えられる予測方法は、リンクのアンカー テキストです。これは、Web の初期の頃の最初の Web クローラーでPinkerton [ 26 ]が採用したアプローチです。Diligentiら[ 27 ]は、既に訪問したページの完全なコンテンツを使用して、駆動クエリとまだ訪問していないページとの類似性を推測することを提案しています。フォーカスクローリングのパフォーマンスは、主に検索対象の特定のトピックのリンクの豊富さに依存し、フォーカスクローリングは通常、開始点を提供するために一般的な Web 検索エンジンに依存します。
集中型クローラーの例としては、 CiteSeer X検索エンジンのクローラーであるciteseerxbotなど、無料でアクセスできる学術関連文書をクロールする学術クローラーがあります。その他の学術検索エンジンには、Google ScholarやMicrosoft Academic Searchなどがあります。ほとんどの学術論文はPDF形式で公開されているため、このようなクローラーは、PDF、PostScriptファイル、Microsoft Wordおよびそれらの圧縮形式をクロールすることに特に関心があります。このため、Heritrixなどの一般的なオープンソース クローラーは、他のMIME タイプを除外するようにカスタマイズするか、ミドルウェアを使用してこれらの文書を抽出し、集中型クロール データベースとリポジトリにインポートする必要があります。[ 28 ]これらの文書が学術文書かどうかを識別することは困難であり、クロール プロセスにかなりのオーバーヘッドを追加する可能性があるため、機械学習または正規表現アルゴリズムを使用して、ポスト クロール プロセスとして実行されます。これらの学術文書は通常、教員や学生のホームページ、または研究機関の出版物ページから取得されます。学術文書はすべてのウェブページのごく一部を占めるにすぎないため、これらのウェブクローラーの効率を高めるには、適切なシードの選択が重要です。[ 29 ]他の学術クローラーは、タイトル、論文、要約などの学術論文のメタデータを含むプレーンテキストファイルとHTMLファイルをダウンロードする場合があります。これにより論文の総数は増加しますが、かなりの割合の論文は無料のPDFダウンロードを提供しない可能性があります。
もう一つのタイプのフォーカス型クローラーはセマンティックフォーカス型クローラーで、ドメインオントロジーを使用してトピックマップを表現し、選択と分類の目的でWebページを関連するオントロジー概念にリンクします。[ 30 ]さらに、オントロジーはクロールプロセスで自動的に更新できます。Dongら[ 31 ]は、Webページをクロールする際にオントロジー概念の内容を更新するためにサポートベクターマシンを使用する、オントロジー学習ベースのクローラーを紹介しました。
ウェブは非常に動的な性質を持っており、ウェブのごく一部をクロールするだけでも数週間から数ヶ月かかることがあります。ウェブクローラーがクロールを完了するまでに、作成、更新、削除など、多くのイベントが発生している可能性があります。
検索エンジンの観点からすると、イベントを検出できず、リソースの古いコピーを持つことにはコストがかかります。最もよく使用されるコスト関数は、鮮度と経過時間です。[ 32 ]
鮮度：これは、ローカルコピーが正確かどうかを示す二値尺度です。時刻tにおけるリポジトリ内のページpの鮮度は、次のように定義されます。
経過時間：これは、ローカルコピーがどれだけ古いかを示す指標です。リポジトリ内のページpの時刻tにおける経過時間は、次のように定義されます。
コフマンらは、ウェブクローラーの目的の定義を鮮度と同等と定義したが、異なる表現を用いている。彼らは、クローラーはページが古いままになっている時間の割合を最小限に抑える必要があると提案している。また、ウェブクローリングの問題は、ウェブクローラーがサーバー、Webサイトがキューとなる、マルチキュー、シングルサーバーのポーリングシステムとしてモデル化できることも指摘している。ページの変更は顧客の到着であり、切り替え時間は単一のWebサイトへのページアクセス間の間隔である。このモデルでは、ポーリングシステムにおける顧客の平均待ち時間は、ウェブクローラーの平均年齢に相当する。[ 33 ]
クローラーの目的は、収集したページの平均鮮度をできるだけ高く保つこと、またはページの平均経過時間をできるだけ短く保つことです。これらの目的は同義ではありません。前者の場合、クローラーは単に古いページの数に関心があるのに対し、後者の場合、クローラーはローカルに保存されているページの古さに関心があります。
ChoとGarcia-Molinaは2つの単純な再訪政策を研究した。[ 34 ]
どちらの場合も、ページの繰り返しクロール順序は、ランダムな順序でも固定された順序でも実行できます。
ChoとGarcia-Molinaは、平均的な鮮度という点では、均一ポリシーが比例ポリシーよりも、シミュレーションされたWebと実際のWebクロールの両方で優れているという驚くべき結果を証明しました。直感的に言えば、Webクローラーは一定時間内にクロールできるページ数に制限があるため、（1）更新頻度の低いページを犠牲にして、頻繁に更新されるページに多くの新しいクロールを割り当て、（2）頻繁に更新されるページの鮮度は、更新頻度の低いページよりも短い期間しか持続しない、という理由です。言い換えれば、比例ポリシーは頻繁に更新されるページのクロールに多くのリソースを割り当てますが、それらのページからの全体的な鮮度持続時間は短くなります。
鮮度を向上させるには、クローラーは変更頻度が高すぎる要素にペナルティを課すべきである。[ 35 ]最適な再訪問ポリシーは、均一ポリシーでも比例ポリシーでもない。平均鮮度を高く保つための最適な方法は、変更頻度が高すぎるページを無視することであり、平均経過時間を低く保つための最適な方法は、各ページの変更率とともに単調に（かつ準線形に）増加するアクセス頻度を使用することである。どちらの場合も、最適な方法は比例ポリシーよりも均一ポリシーに近い。Coffmanらが指摘するように、「予想される陳腐化時間を最小限に抑えるには、特定のページへのアクセスをできるだけ均等な間隔に保つ必要がある」。[ 33 ]再訪問ポリシーの明示的な式は一般には得られないが、ページ変更の分布に依存するため、数値的に得られる。Cho と Garcia-Molina は、指数分布がページ変更の記述に適していることを示しているが、[ 35 ] Ipeirotis らは、この分布に影響を与えるパラメータを発見するために統計ツールを使用する方法を示します。[ 36 ]ここで検討されている再訪問ポリシーは、すべてのページを品質に関して均質であるとみなしています（「Web 上のすべてのページは同じ価値がある」）。これは現実的なシナリオではないため、より良いクローリング ポリシーを実現するには、Web ページの品質に関する詳細情報を含める必要があります。
クローラーは人間の検索者よりもはるかに速く、より詳細なデータを取得できるため、サイトのパフォーマンスに深刻な影響を与える可能性があります。単一のクローラーが毎秒複数のリクエストを実行したり、大きなファイルをダウンロードしたりする場合、サーバーは複数のクローラーからのリクエストに対応しきれなくなることがあります。
コスターが指摘するように、ウェブクローラーの使用は多くのタスクに役立ちますが、一般コミュニティにとってはコストがかかります。[ 37 ]ウェブクローラーの使用コストには以下が含まれます。
これらの問題に対する部分的な解決策は、robots.txt プロトコルとしても知られるロボット排除プロトコルであり、管理者が Web サーバーのどの部分にクローラーがアクセスすべきでないかを示すための標準です。 [ 38 ]この標準には、同じサーバーへの訪問間隔に関する提案は含まれていませんが、この間隔はサーバーの過負荷を回避する最も効果的な方法です。最近では、Google、Ask Jeeves、MSN、Yahoo! Searchなどの商用検索エンジンが、 robots.txtファイルに「Crawl-delay:」パラメータを追加して、リクエスト間の遅延秒数を示すことができるようになりました。
連続するページ読み込み間の最初の提案された間隔は60秒でした。[ 39 ]しかし、遅延ゼロで帯域幅が無限の完璧な接続を介して10万ページを超えるウェブサイトからこの速度でページをダウンロードした場合、そのウェブサイト全体をダウンロードするだけで2か月以上かかります。また、そのウェブサーバーのリソースのごく一部しか使用されません。
Cho はアクセス間隔として 10 秒を使用し、[ 34 ] WIRE クローラーはデフォルトで 15 秒を使用します。[ 40 ] MercatorWeb クローラーは適応型礼儀ポリシーに従います。特定のサーバーからドキュメントをダウンロードするのにt秒かかった場合、クローラーは次のページをダウンロードする前に10 t秒待ちます。 [ 41 ] Dillらは1 秒を使用します。[ 42 ]
研究目的でウェブクローラーを使用する場合は、より詳細な費用対効果分析が必要であり、クロールする場所とクロール速度を決定する際には倫理的配慮を考慮に入れる必要がある。[ 43 ]
アクセスログからの逸話的な証拠によると、既知のクローラーのアクセス間隔は20秒から3～4分まで変動します。非常に丁寧に対応し、Webサーバーの過負荷を避けるためのあらゆる安全対策を講じたとしても、Webサーバー管理者から苦情が寄せられることがあるのは注目に値します。Sergey BrinとLarry Pageは1998年に、「...50万台以上のサーバーに接続するクローラーを実行すると、かなりの量の電子メールや電話が発生します。オンラインになる人の数が非常に多いため、クローラーが何であるかを知らない人が常にいます。これは、彼らが初めて目にするクローラーだからです。」と述べています。[ 44 ]
並列クローラーとは、複数のプロセスを並列に実行するクローラーのことです。その目的は、並列処理によるオーバーヘッドを最小限に抑えつつダウンロード速度を最大化し、同じページの繰り返しダウンロードを回避することです。同じページを複数回ダウンロードすることを避けるため、クロールシステムは、クロール処理中に発見された新しいURLを割り当てるためのポリシーを必要とします。これは、同じURLが2つの異なるクロールプロセスによって検出される可能性があるためです。
前述のセクションで述べたように、クローラーは優れたクロール戦略を備えているだけでなく、高度に最適化されたアーキテクチャも備えている必要がある。
ShkapenyukとSuelは次のように指摘した。[ 45 ]
短時間であれば毎秒数ページをダウンロードするような低速なクローラーを構築するのは比較的容易だが、数週間にわたって数億ページをダウンロードできる高性能システムを構築するには、システム設計、I/Oとネットワークの効率性、堅牢性、管理性など、多くの課題が存在する。
ウェブクローラーは検索エンジンの中心的な要素であり、そのアルゴリズムやアーキテクチャの詳細は企業秘密として扱われています。クローラーの設計が公開される場合でも、多くの場合、他者がその成果を再現できないように、重要な詳細情報が欠落しています。また、「検索エンジンスパム」に対する懸念も高まっており、主要な検索エンジンがランキングアルゴリズムを公開することを躊躇する要因となっています。
ウェブサイトの所有者のほとんどは、検索エンジンでの存在感を高めるために、できるだけ広範囲にページをインデックス登録してもらいたいと考えていますが、ウェブクローリングは意図しない結果を招く可能性があり、検索エンジンが公開すべきでないリソースや、潜在的に脆弱なバージョンのソフトウェアを公開するページをインデックス登録した場合、情報漏洩やデータ侵害につながる可能性があります。
標準的なウェブアプリケーションのセキュリティ推奨事項に加えて、ウェブサイトの所有者は、検索エンジンがウェブサイトの公開部分のみをインデックスできるようにし（robots.txtを使用）、トランザクション部分（ログインページ、プライベートページなど）をインデックスしないように明示的にブロックすることで、日和見的なハッキングのリスクを軽減できます。
ウェブクローラーは通常、 HTTPリクエストのUser-agentフィールドを使用してウェブサーバーに自身を識別します。ウェブサイト管理者は通常、ウェブサーバーのログを調べ、User-agentフィールドを使用して、どのクローラーがウェブサーバーにアクセスしたか、またその頻度を判断します。User-agentフィールドには、ウェブサイト管理者がクローラーに関する詳細情報を取得できるURLが含まれている場合があります。ウェブサーバーのログを調べるのは面倒な作業であるため、一部の管理者はウェブクローラーを識別、追跡、検証するためのツールを使用します。スパムボットやその他の悪意のあるウェブクローラーは、User-agentフィールドに識別情報を含めることはまずなく、ブラウザやその他のよく知られたクローラーとして自身の身元を偽装する可能性があります。
ウェブサイト管理者は、必要に応じて所有者に連絡できるよう、ウェブクローラーが自身を識別してくれることを好みます。クローラーが誤ってクローラートラップに引っかかったり、リクエストでウェブサーバーに過負荷をかけたりする場合、所有者はクローラーを停止する必要が生じます。また、特定の検索エンジンにウェブページがインデックス登録される時期を知りたい管理者にとっても、識別情報は役立ちます。
膨大な数のウェブページがディープウェブまたは見えないウェブに存在します。[ 46 ]これらのページは通常、データベースにクエリを送信することによってのみアクセス可能であり、それらを指すリンクがない場合、通常のクローラーではこれらのページを見つけることができません。GoogleのSitemapsプロトコルとmod oai [ 47 ]は、これらのディープウェブのリソースの発見を可能にすることを目的としています。
ディープウェブクローリングでは、クロール対象となるウェブリンクの数も増加します。クローラーによっては、URLの一部のみをフォーム形式で取得するものもあります。Googlebotのように、ハイパーテキストコンテンツ、タグ、またはテキストに含まれるすべてのテキストに対してウェブクローリングを行う場合もあります。<a href="URL">
ディープウェブのコンテンツをターゲットにするには、戦略的なアプローチが取られることがあります。スクリーン・スクレイピングと呼ばれる技術では、特定のウェブフォームに自動的かつ繰り返しクエリを実行するように専用ソフトウェアをカスタマイズし、結果として得られるデータを集約することができます。このようなソフトウェアは、複数のウェブサイトにわたる複数のウェブフォームに使用できます。1つのウェブフォームの送信結果から抽出されたデータは、別のウェブフォームへの入力として適用することができ、従来のウェブクローラーでは不可能な方法でディープウェブ全体に連続性を確立できます。[ 48 ]
AJAXで構築されたページは、ウェブ クローラーに問題を引き起こすもののひとつです。Googleは、ボットが認識してインデックスできる AJAX 呼び出しのフォーマットを提案しています。[ 49 ]
ウェブ上には、ユーザーの要求に基づいてページをクロールし、データを列と行に構造化する「ビジュアルウェブスクレイパー／クローラー」製品が数多く存在します。従来のクローラーとビジュアルクローラーの主な違いの一つは、クローラーの設定に必要なプログラミングスキルのレベルです。最新世代の「ビジュアルスクレイパー」は、ウェブデータをスクレイピングするためのプログラミングとクロールの開始に必要なプログラミングスキルの大部分を不要にしています。
ビジュアルスクレイピング/クローリング方式は、ユーザーがクローラー技術を「学習」させることに依存しており、クローラーは半構造化データソース内のパターンをたどります。ビジュアルクローラーを学習させる主な方法は、ブラウザでデータをハイライト表示し、列と行を学習させることです。この技術自体は新しいものではなく、例えばGoogleが買収したNeedlebase（ITA Labs [ 50 ]の大規模買収の一環として）の基盤となっていましたが、投資家やエンドユーザーによるこの分野への継続的な成長と投資が見られます。
以下は、汎用クローラー（特定のWebクローラーを除く）向けに公開されているクローラーアーキテクチャの一覧です。各アーキテクチャには、各コンポーネントの名称と主な特徴を含む簡単な説明が添えられています。
以下のウェブクローラーは有料で利用可能です。
{{cite book}}: CS1 maint: 複数の名前: 著者リスト (リンク){{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）