ウェブクローラーはどのように機能しますか？

シードとURLフロンティア

クローラーはシードURLと候補リソースを保持するフロンティアから始まります。シードは承認された在庫、サイトマップ、または選択された公開ページから来る場合があります。フロンティアはまだ完了していない作業を表し、しばしば発見元や優先度などの情報とともにあります。

スケジューラーはクロールの目的に応じて候補を選択します。サイトの在庫は広範な探検を優先するかもしれませんが、焦点を絞った収集は特定のページタイプに合致する可能性のあるリンクを優先するかもしれません。どちらの戦略もすべての関連ページが見つかることを保証するものではありません。

その ウェブクロールアーキテクチャ はフロンティアをダウンロードとリンク処理から分離します。その分離は、いくつかのワーカーによってフェッチが行われている間でも、ジョブが保留中の作業を記録するのに役立ちます。

シードの出所を保持します。サイト所有者によって提供されたURLは、フッター内にあるものとは異なる発見の基盤を持っています。カバレッジを説明するのに役立つ関係があるときは、候補を導入したリソースがどれであるかを保存します。制約された監査のために、フロンティアは候補が除外された理由も保持しておくべきです。

リソースが取得される前のスコープチェック

クローラーは、フェッチのスケジューリングの前にスコープとアクセスルールに対して候補URLをチェックします。一般的なスコープの次元には、ホスト、パスプレフィックス、リソースタイプ、およびクエリパターンが含まれます。これらはプロジェクトの決定であり、クロールが拡張する前に書き留めておくべきです。

ページの適用可能なベースURLを使用して相対リンクを解決します。 URI参照解決標準 は、参照が絶対アドレスになる方法を説明しています。解決されたURLをスコープルールと比較してください；相対的に見えるリンクは、意図された領域の外で解決される場合があります。

初期の候補だけでなくリダイレクトも評価します。承認されたURLは、別のホストまたは制限されたパスに導くことがあります。最終的な宛先は、開始アドレスからの承認を継承するのではなく、同じスコープレビューを受けるべきです。

クローラーのアイデンティティについてロボットルールを確認します。 ロボット除外プロトコル はパスマッチングとルールファイルの取り扱いを定義します。サイトの好みは契約上および法的制約とともに保持してください。技術的な許可の決定は、コンテンツのあらゆる可能な下流の使用が許可されていることを確立するものではありません。

最も狭い実用的なスコープを適用してください。所有する文書監査のためには、文書ホストと合意されたセクションのみを収集する方が、リンクされたすべての宛先を許可するよりも確認が容易です。

取得、ページアイデンティティ、およびオプションのレンダリング

取得は、リソースを検査し、さらにリンクを発見するために必要な表現を取得します。クローラーは、適切なページにはHTTPクライアントを使用し、リンクがJavaScriptに依存する場合にはブラウザ実行を使用できます。

最初に何が到着したかを判断します。応答ステータス、最終URL、および適切なページ分類を記録します。認証へのリダイレクトやチャレンジ応答は、クローラーに有効なトランスポートデータを残すことができ、使用可能な発見入力を持たない場合があります。そのリソースはバイトが返されたからといって成功裏に検査されたものとして数えないでください。

レンダリングは、初期のマークアップから発見リンクが欠けている場合に目的が必要です。すべてのリソースにブラウザが必要だと仮定する前にページを検査します。ブラウザ実行はネットワーク作業を追加し、単なるドキュメントの取得では持ち運ばれない状態を導入する可能性があります。

動的ワークフローのために、 Scrapeless Agent Browser はブラウザベースの収集に使用される実行層を提供します。 Scrapelessウェブサイトクロール設定 は管理されたクロールサーフェスを説明します。完全性の主張のためにそれらに依存する前に、そのスコープ制御と結果の意味を確認してください。

レンダリングされたページは、タスクに必要なリンクまたはコンテンツに結びついた準備の決定がまだ必要です。クローラーは、意図された文書、明示的な空の状態、または無関係な応答を検査したかどうかを知っておくべきです。

リンクの発見とURLの重複排除

リンクの発見は、検査されたリソースから候補参照を抽出し、重複排除はどの候補が既に知られている作業を表すかを決定します。クローラーは、URLレベルと、一部のプロジェクトではコンテンツレベルの推論の両方が必要です。

適切な場合、通常のHTTPフェッチアイデンティティからフラグメントを削除します。フラグメントは位置やクライアント側の解釈を特定するものであり、別のサーバーリクエストではありません。クエリパラメータには注意してください。一部のパラメータは帰属を追跡するだけであり、他のものは製品のバリアントやカテゴリの内容を変更します。すべてのクエリを削除するルールは、異なるリソースを統合する可能性があります。

URLポリシーが正当化できるものだけを正規化します。元のアドレスと最終アドレスを正規化されたスケジューリングキーとともに保持します。これにより、発見の跡を失うことなく誤った同等ルールを修正できます。

コンテンツの重複は別の問題です。いくつかのURLが類似のドキュメントを提供する場合があり、1つのURLを2回取得した場合、地域やセッションによって異なることがあります。レコードをマージする前に、どのような区別がタスクに重要かを判断してください。コンテンツハッシュを使用すると、同一のバイトを検出できますが、同一のバイトだけが重複情報の唯一の定義ではありません。

申し訳ありませんが、翻訳したいテキストを提供していただけますか？ ウェブサイトのURL発見方法 インベントリがなぜ複数の入力を必要とすることが多いのかを説明します。リンクとサイトマップはサイトの異なるビューを示しており、両方とも関連するリソースを省略する可能性があります。

ホスト負荷のスケジューリングとクロールトラップの制御

クローラスケジューラーは、集約されたホストの負荷を制御し、役に立たない範囲での発見の拡大を防ぎます。ホストごとの制限は、ワーカーやネットワーク出口全体に適用されるべきです。なぜなら、宛先は結合された収集作業負荷を経験するからです。

承認されたリクエストのペース、ページ予算、および作業の時間予算を設定します。これは運用上の制約であり、普遍的な安全値ではありません。小規模な公開サイトと合意されたエンタープライズデータフィードでは、非常に異なる制限がある可能性があります。選ばれた制限の出所を文書化してください。

クロールトラップは、常に新しい組み合わせを生成できるURLスペースからしばしば発生します。カレンダー ナビゲーション、ソートオプション、およびファセット フィルターは一般的な例です。クローラーは、その目的にあまり情報を追加しない無限に異なるアドレスを見るかもしれません。

ページの意味に関連するルールを使用してください。カタログの在庫に関しては、標準の製品詳細パスが有用ですが、フィルターパラメータの任意の組み合わせは範囲外です。その区別が信頼性高く推測できない場合は、ソース所有者に承認済みの在庫を提供させるか、発見をさらに制限してください。

ストップ理由を保存します。ページバジェットに達することは、適格なフロンティアを使い果たすこととは異なります。オペレーターは、クロールが意図的に停止したのか、リクエストされた範囲に達したのか、まだ保留中の作業があるのかを確認できるべきです。

クローリング結果、チェックポイント、およびカバレッジ

クローリング結果は、発見されたもの、訪問されたもの、除外されたもの、受け入れられたものを説明する必要があります。「完了」というラベルのみでは、意図されたインベントリがカバーされているかどうかを示すことはできません。

候補者とリソースの状態を追跡します。候補者は、範囲外、ポリシーによって拒否されている、保留中、取得済み、またはコンテンツ検査後に拒否される可能性があります。状態遷移を理解しやすく保ちます。オペレーターがチェックポイントからジョブを再開する場合、その記録は完了したリソースとまだ決定を待っているリソースを区別するべきです。

カバレッジは常に定義に対して相対的です。クロールは、承認されたシードリスト、パスルールの下で到達可能なリンク、またはサイトマップに宣言されたリソースをカバーすることができます。キューの終わりに到達するだけでは、孤立ページが存在しないことを証明することはできません。

観察されたインベントリを、完全性が重要な場合は他の適切なソースと比較してください。所有しているCMSのエクスポートは、インバウンドリンクがないページを明らかにすることができます。サイトマップは、クロールが見逃した宣言されたページを特定できます。違いを解決するには、カウントを説明なしにマージするのではなく、ソースを調査してください。

選択された実行レイヤーの予算を使用して 現在のScrapeless料金レンダリングされたディスカバリーとスタティックフェッチングは異なるリソースニーズを持つため、コストを定義されたカバレッジの成果と比較します。

イラストによるドキュメンテーションクロール

所有されたドキュメンテーションクローラーは、すべてのコントロールを可視化できます。この計画の例は、合意されたドキュメンテーションセクションとサイトオーナーが提供したサイトマップから始まります。これは、測定されたライブクローラーを表しているわけではありません。

フロンティアは、発見ソースと共にそれらの種を受け取ります。スコープチェックは、承認されたホストとパスでジョブを維持します。取得された各ページは分類され、そのリンクは解決され、適格な候補者はURLの同等性ポリシーに従ってフロンティアに入ります。

クロールラーはリダイレクトを記録し、アカウントルートを除外します。実際に依存するナビゲーションのためにのみブラウザレンダリングを使用します。別の監査段階では、見出し、内部リンク、および移行タスクに必要なその他のプロパティをチェックします。

適格なフロンティアが尽きると、オペレーターは訪問したインベントリをサイトマップおよびCMSリストと比較します。欠落しているリソースには、特定の理由が示されます：リンクされていないページ、範囲外のパス、拒否されたレスポンス、または利用できないソース。最終報告書は、その後、所有者が確認できる形でのカバレッジを説明できます。

このワークフローは、クローラーが発見と取得を担当し、監査が解釈を担当します。これらの責任を分離することで、別の認可された分析のために同じインベントリを再利用することが容易になります。

結論

ウェブクローラーは、スケジューリング、フェッチ、リンク発見、および重複排除の制御されたループを通じて動作します。その範囲ルールと停止条件は、そのループが何をカバーしたと主張できるかを決定します。

明示的なシードと合意されたインベントリ定義から始めます。候補の決定、最終目的地、及び却下理由を結果に含めます。クローリングは、そのカバレッジが説明可能であり、開始点の目的と照らし合わせて確認できるときに有用です。

参考文献

• スクレイプレスウェブサイトクロール設定
• 動的ページのエージェントブラウザ実行
• ウェブサイトURL発見方法