Bingの検索結果からクロールキューを作成する方法

初回確認の設定と、情報源が提供するデータの範囲

公開版Google Search Scraperのビルド1.0.15は、Google、Bing、Brave、DuckDuckGoに対応しています。ただし、ここで紹介する方法で適合を確認できているのはBingだけです。現在の公開Taskの入力は、`queries ["AI agents", "small business automation"]`、`engines ["bing"]`、`maxResultsPerExecutedQuery 20`、`country "US"`、`language "en"`、`safeSearch true`、`includeSponsoredResults false`です。この試行では、queriesとenginesのリスト全体を、目的の検索クエリ1件と`engines ["bing"]`に置き換えてください。`maxResultsPerExecutedQuery 2`を設定し、対象の国と言語を指定してください。真偽値の設定は同じにします。検索の拡張設定や、公開されたページ数上限の入力項目はありません。

標準の検索結果フィールドと出力サマリー

データセットの各検索結果行には、次の正確なフィールド名が含まれます。`runId`、`country`、`language`、`safeSearch`、`engine`、`executedQuery`、`page`、`rankOnPage`、`rank`、`title`、`canonicalUrl`、`resultDomain`、`snippet`、`isSponsored`、`advertiserDomain`、`observedAt`、`schemaVersion`です。1行は、ある検索エンジン、クエリ、ページ、掲載位置での1回の観測を表します。`canonicalUrl`フィールドが提供するのは正規化された候補アドレスであり、確認済みのHTML canonicalタグや元のリンクではありません。スニペットは検索結果のテキストであり、取得したページの内容ではありません。

出力される実行サマリーには、`queriesRequested`、`searchesCompiled`、`executionsPlanned`、`enginesSuccessful`、`enginesFailed`、`pagesAttempted`、`pagesParsed`、`resultsSaved`、`engineStatusCounts`、`engineResultCounts`、`queryResultCounts`、`stopReason`が記載されます。

参考：Bingの対照実行

`Python asyncio documentation`を使った対照実行の正確な結果は、次のとおりです。

• `queriesRequested`: 1
• `searchesCompiled`: 1
• `executionsPlanned`: 1
• `enginesSuccessful`: 1
• `enginesFailed`: 0
• `pagesAttempted`: 1
• `pagesParsed`: 1
• `resultsSaved`: 2
• `engineStatusCounts`: `{"bing": {"ok": 1}}`
• `engineResultCounts`: `{"bing": 2}`
• `queryResultCounts`: `{"Python asyncio documentation": 2}`
• `stopReason`: `result_caps_reached`
• 返された結果：順位1と2に、`docs.python.org`へ直接つながるURLが2件。

ここで確認できたのは、範囲を限定したBingのメタデータサンプルだけです。すべての地域、検索演算子、順位の重複、リンク先の取得は検証していません。一次情報には、Google Search Scraper ActorとBing Search Results Taskがあります。

1. 検索する前に、必要なページと採用基準を決めてください。この方法では、ページ候補の発見にBingを利用できます。中立的なトピックを使い、取得行数に上限を設けてください。数百件の有効なサイトが得られると約束しないでください。検索で見つかるのは候補であり、各ページを収集できる保証はありません。
2. queriesには目的の語句を1つ指定し、enginesにはbingを設定し、取得行数の上限を小さくしてください。実行されたクエリ、検索エンジン、タイムスタンプ、出力を確認してください。クエリの表現によって、得られる情報源のサンプルは変わります。検索エンジンでの解釈を自分で検証しない限り、通常の語句を使ってください。
3. 収集対象を選ぶ前に、返された検索結果の行を保存してください。タイトル、候補アドレス、情報源のホスト、順位、クエリ、時刻、検索処理の停止理由を残してください。壊れたアドレスやウェブ以外のアドレスは、自分の基準に従って除外してください。転送先が分からないリダイレクトや、不明確なリンク先は判断保留にしてください。「canonical address」のような正規化フィールドの名前だけでは、元のページの実際の同一性は証明できません。返された文字列は、情報源の証拠として変更せずに保存してください。
4. 各候補のホストとパスが、収集目的に合うか確認してください。検索結果のタイトルやスニペットは、古い場合や誤っている場合があります。必要に応じて、読者自身の収集手順で公開されたリンク先を確認してください。最終URL、コンテンツタイプ、ページ上の証拠を記録してください。タイトルだけで商品内容を推測しないでください。ログインページや非公開ページは、引き続き利用できません。
5. 各対象を、明確な理由とともに採用、除外、要確認に分類してください。採用は、その時点で確認基準を満たしたことを意味します。クロールの成功、必要な権利がすべてそろっていること、商品データの正確性を保証するものではありません。リンク先の確認に失敗した対象や、情報源のデータが不足している対象は、採用済みのキューに入れないでください。
6. 安全な基準に従い、確認済みの重複対象アドレスだけを統合し、検索結果への参照はすべて保持してください。観測レコードと対象レコードは分けて管理してください。異なるページを識別するパスやクエリパラメーターを削除しないでください。同じホストでも、同じページとは限りません。同じタイトルでも、同じ対象とは限りません。
7. 対象アドレス、出典参照、採用の根拠、抽出したい内容、状態を含む小規模なキューを作成してください。採用した対象を、それらのページに適した、実行範囲を限定した別のクローラーに渡してください。検索Actorは、そのクロールを実行せず、本文も提供しません。
8. 収集した観測、重複を除いた確認済み候補、採用・除外・判断保留の対象、上限への到達状況を照合してください。採用対象が0件でも、該当する対象がないという正常な結果の場合があります。推測したページで一覧を埋めないでください。候補発見にかける予算を増やす前に、最後に対象を1件確認してください。

独自に作成した架空の具体例

このセクションのドメイン、語句、件数は、すべて独自に作成した架空のものです。返された観測は7件あり、対象アドレスの完全一致を基準にすると、重複を除いた候補アドレスは6件です。2件の観測が、同じアドレス`https://garden.example/products`を指しています。残る5件の観測は、商品ページ、ブログのガイド記事、転送先が分からないリダイレクト、ログインページ、無効なアドレスをそれぞれ指しています。

1. 検索結果の観測7件

2. 重複を除いた対象候補6件とその状態

3. キューに採用した対象2件

照合すると、候補6件は、採用対象2件、除外対象2件、判断保留の対象2件に分かれます。商品一覧ページの2件の観測は、キュー内の1件の対象にひも付けたままにし、両方のクエリ、順位、時刻の参照を保持します。7件の観測を7件のクロール対象サイトと呼んだり、重複する参照を捨てたりしないでください。後で別のクローラーを実行した際に商品一覧ページの処理が失敗した場合は、その失敗を記録してください。事前に採用したことは、抽出の成功を保証しません。