如何從 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 清單換成一個預定查詢和 `engines ["bing"]`，設定 `maxResultsPerExecutedQuery 2`、預定的 country、language 和相同的布林值，並留意並不存在擴展設定或公開的頁數上限輸入。

原生結果欄位與輸出摘要

每筆資料集結果列包含這些確切欄位：`runId`、`country`、`language`、`safeSearch`、`engine`、`executedQuery`、`page`、`rankOnPage`、`rank`、`title`、`canonicalUrl`、`resultDomain`、`snippet`、`isSponsored`、`advertiserDomain`、`observedAt` 和 `schemaVersion`。一列代表在某個引擎、查詢、頁面和位置上的一次觀察。`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`
• 傳回結果：兩個直接的 `docs.python.org` URL，排名為 1 和 2。

這只證明一份範圍有限的 Bing 中繼資料樣本。它沒有測試所有市場、搜尋運算子、重複排名或目的地擷取。主要來源包括 Google Search Scraper Actor 和 Bing Search Results Task。

1. 在搜尋之前，先界定你需要的頁面和納入規則。Bing 在此是受支援的發現來源。使用中性主題和有限的列數上限，不要承諾數百個有效網站。搜尋發現提供候選項目，並不承諾每個頁面都能收集。
2. 使用只含一個預定片語的查詢，把 engines 設為 bing，並設定較小的列數上限。檢查已執行的查詢、引擎、時間戳和輸出。查詢用字會改變你的來源樣本。除非你自行測試搜尋引擎如何解讀查詢用字，否則使用普通詞語。
3. 在選取目標之前，保留傳回的結果列。保留標題、候選網址、來源主機、排名、查詢、時間和來源停止狀態。依你的規則拒絕損壞或非網頁的網址。把不透明的重新導向或目的地不清楚的項目保持為未解決。像標準網址這類正規化欄位名稱，並不能證明原頁面的真實身分。把傳回的字串保持不變，作為來源證據。
4. 按你的收集目的檢查每個候選主機和路徑。搜尋標題和摘要可能過時或錯誤。有需要時，透過你自行執行的頁面收集流程檢查公開目的地。記錄最終 URL、內容類型和頁面證據。不要只憑標題猜測產品內容。登入頁和私人頁面仍然無法取得。
5. 為每個目標指定已接受、已拒絕或需要覆核，並寫明原因。已接受表示它在該時刻符合你的檢查。這不保證爬取成功、完整權利或準確的產品資料。把失敗的目的地檢查和來源缺口留在已接受佇列之外。
6. 只在安全規則下合併已覆核的重複目標網址，同時保留所有結果參照。觀察紀錄和目標紀錄要分開保存。不要刪除可識別不同頁面的不同路徑或查詢參數。相同主機不代表相同頁面。相同標題不代表相同目標。
7. 用目標網址、來源參照、接受證據、所需擷取和狀態建立小型佇列。把已接受的目標交給專為那些頁面而設的另一個範圍有限的爬蟲。搜尋 Actor 不會執行該次爬取，也不會提供主要文字。
8. 核對你收集到的觀察、不重複的已覆核候選、已接受、已拒絕和未解決的目標，以及上限狀態。已接受目標為零可以是正常的缺口，不是要用猜測頁面填滿的清單。結束前先檢查一個目標，再擴大你的發現預算。

原創虛構的演算示例

本節所有網域、用詞和計數都是原創虛構。七筆傳回的觀察在精確目標規則下指向六個不同的候選網址。兩筆觀察共用網址 `https://garden.example/products`. 其餘五筆觀察分別指向一個產品頁、一篇網誌指南、一個不透明重新導向、一個登入頁和一個無效網址。

1. 七筆結果觀察

2. 六個不重複的目標候選及狀態

3. 兩個已接受的佇列目標

核對結果顯示，六個候選得出兩個已接受目標、兩個已拒絕目標和兩個未解決目標。產品索引的兩筆觀察仍然附在同一個佇列目標上，並同時保留查詢、排名和時間參照。不要把七筆觀察說成七個爬取網站，也不要丟掉重複參照。如果產品索引在稍後獨立爬蟲執行時失敗，記錄該次失敗；較早的接受並不保證擷取成功。