Cloudflare Browser Run Crawl 400 怎麼查？看 Content Signals

先知道 400 是哪一種 Content Signal#

如果不填 crawlPurposes，/crawl 預設宣告三種用途：search、ai-input、ai-train。如果不填 contentUse，預設是最寬鬆的 full。因此一個「只是建立搜尋索引」的工作，可能因為預設還宣告了 AI training 而被拒絕；一個只允許 use=reference 的網站，也可能因為你採用預設 full 而被拒絕。

用最小意圖發出請求#

如果工作的確只是搜尋索引與引用，請在請求中明確縮小用途與使用層級：

1
curl -X POST \
2
  'https://api.cloudflare.com/client/v4/accounts/<account_id>/browser-rendering/crawl' \
3
  -H 'Authorization: Bearer <api_token>' \
4
  -H 'Content-Type: application/json' \
5
  -d '{
6
    "url": "https://example.com/docs/",
7
    "crawlPurposes": ["search"],
8
    "contentUse": "reference",
9
    "formats": ["markdown"],
10
    "limit": 20
11
  }'

上面的範例故意只宣告實際需要的權限。reference 代表內容可以被保留、建立索引或引用；full 則是更寬鬆的使用層級。immediate 是 Content Signals 的層級之一，但 /crawl 不接受它，因為 crawl job 會儲存擷取內容。

不要為了讓請求通過而把用途改成與實際工作不符的值。Cloudflare 文件把這些欄位描述為對網站擁有者的用途宣告，Content Signals 是信任式規則；它不是繞過網站政策的技巧。

直接檢查目標的 robots.txt#

先用瀏覽器或 curl 讀取目標網域的 robots.txt，再找 Content-Signal: 行。Cloudflare 文件中的例子如下：

1
User-Agent: *
2
Content-Signal: search=yes, ai-train=no
3
Allow: /

使用層級則可能長這樣：

1
User-Agent: *
2
Content-Signal: use=reference
3
Allow: /

如果網站設定 ai-train=no，但你的 crawlPurposes 仍包含 ai-train，啟動請求會被拒絕。把它縮成 ["search"]，只有在你的工作真的只需要搜尋用途時才合理。

如果網站設定 use=reference，contentUse: "reference" 可以符合它；預設的 full 則會超過目標允許的層級。若網站設定 use=immediate，/crawl 因為不接受 immediate，所有 crawl 都會被拒絕，這時應尊重網站限制或改用經授權的資料交換方式。

400 以外的問題不要混在一起#

Content Signals 只解釋其中一類 400。Browser Run /crawl 仍需要具備 Browser Rendering Edit 權限的 API token；而且它會遵守一般 robots.txt 的 Disallow、crawl-delay、網站的 WAF／Turnstile 與其他 bot protection。

排錯時可用這個順序：

1. 先記錄完整 400 response body，確認是否包含 Crawl disallowed by Content-Signal directive (purpose or use level)。
2. 直接讀取目標 robots.txt，檢查 Content-Signal 和一般 Disallow，不要只看首頁 HTML。
3. 把 crawlPurposes 改成工作的最小實際用途，把 contentUse 降到目標允許的層級。
4. 若仍失敗，再檢查 token 的 Browser Rendering - Edit 權限、帳號 ID 與 endpoint。
5. 若工作已成功建立但結果是 disallowed、skipped 或 errored，改查 crawl job 結果，不要把它和啟動時的 400 混為一談。

/crawl 使用的 User-Agent 是 CloudflareBrowserRenderingCrawler/1.0，而且不可自訂。若你需要更完整的 Browser Run 限制與 render／Browser time 排查，可以接著看 Browser Run Free／Paid 與 Quick Actions 限制；Content Signals 解決的是內容用途判斷，不是並行數或瀏覽器時數。

讓每個 crawl job 都留下用途紀錄#

若團隊有多種 crawler，建議在自己的工作設定中保留：

1
{
2
  "jobName": "docs-search-index",
3
  "crawlPurposes": ["search"],
4
  "contentUse": "reference",
5
  "targetRobotsCheckedAt": "2026-09-02T00:00:00Z"
6
}

這不會取代 Cloudflare 的檢查，但能讓日後看到 400 時快速回答三個問題：誰發出請求、原本宣告什麼用途、最近一次檢查目標政策是什麼。網站的 robots.txt 會變動，所以不要只把用途寫在程式碼註解裡。

結論：把 400 當成政策不匹配來查#

Browser Run /crawl 新增 Content Signals 檢查後，最重要的改變不是多了一個要背的參數，而是 crawler 必須把「要怎麼用內容」說清楚。crawlPurposes 對應 search／AI input／AI training，contentUse 對應 reference／full；兩者都應按照實際工作使用最小宣告。這樣遇到 400 時，才能先修正用途不匹配，而不是無限重發同一個請求。

常見問題#