用 Claude Code 擴充 Oncrawl：四個進階 MCP 提示情境

By

來源聲明：本文根據 Philippe Traversac〈Joins, alerts, and multi-MCP: 4 advanced prompts to extend Oncrawl with Claude Code〉（Oncrawl，2026-06-02）編譯整理，不是逐句翻譯。原文連結：https://oncrawl.com/technical-seo/joins-alerts-multi-mcp-4-advanced-prompts-oncrawl-claude-code。頁面未見開放授權。文中「編輯解讀」為本站觀點。

Model Context Protocol（MCP）是讓大型語言模型透過標準介面呼叫外部工具與資料的協定1。Philippe Traversac 這篇是 Oncrawl MCP 入門文的續篇：假設你已能用 agent 做結構稽核、用自然語言寫 OQL，再往四個「平台原生介面還做不到或不方便」的情境推進。

作者先提醒：LLM 在較小資料集上表現較穩。他建議大約 10 萬 URL、連結來源不超過約 100 萬條；再上去 token 成本與計算時間會快速上升。

情境一：把頁面資料集與連結資料集 join

文中指出，撰寫當下 Data Explorer 可用切換鈕在 pages 與 links 之間切換，但不能用 URL 當鍵做站內 join。若能 join，就能同時看頁面的 inrank、深度，以及連結的來源位置、錨文字等。

作者給出可用自然語言問的方向，例如：哪些頁面有來自正文（body）的連結，指向 inrank 1 到 5 的頁？也可交叉 GSC 表現，找出「有編輯區內部連結、但瀏覽量落在全站較低四分位」的頁，當作未充分利用的編輯機會。另一類是找出指向不可索引、4XX、5XX 或 3XX 的內部連結，或「來源已是 3XX、最終目標卻是 4XX/5XX」的有害重新導向鏈。

視覺化可用開源 chart-visualization-skills 等與 Claude Code 相容的模組；本篇不詳述安裝步驟。

情境二：以日誌為基礎的機器人告警

作者舉一例：某使用者花了六天才發現 JavaScript 轉譯更新讓整區頁面從網站地圖「消失」，且沒有告警。若 MCP 同時接上 Slack 與 Oncrawl，可用自然語言定義告警邏輯。

get_data_search_logs 可查 pages（依 URL 聚合）或 events（原始紀錄）。查 pages 時需指定粒度：days、weeks 或 months。文中提供可套用的提示模板：依機器人與日彙總約 14 天曲線，標記突升、突降、緩慢下滑、連續兩天以上歸零等，再摘要送到指定 Slack 頻道。

情境三：爬取對爬取的結構差異告警

進階使用者常要的是：跟上一次爬取比什麼變了、用自己能控制的閾值、送到 Slack/Teams，且不必在匯出資料上自幹整套排程。模板可追蹤新增/移除頁、狀態碼轉換、新孤兒頁、深度偏移、inrank 下滑、GSC 點擊下滑等，並用絕對數量、百分比或標準差當觸發條件。排程可透過 MCP 的 CronCreate，讓週期任務在工作階段重啟後仍保留。

情境四：多 MCP 交叉診斷

單一 MCP 不夠時，可同時接 Oncrawl 與社群維護的 Google Search Console MCP（作者連到 AminForou/mcp-gsc，並提醒這不是 Google 官方 MCP，使用前應做安全稽核）2。重點是交叉「實際索引狀態、上次 Googlebot 造訪、GSC 回報的索引問題」與爬取結構。

文中把診斷分成三桶：結構內但抓不到（技術阻擋）、結構外孤兒卻有點擊/sitemap 等發現訊號（內部連結問題）、已抓取但不可索引（canonical、noindex、重新導向等）。GSC URL Inspection 有每日約 2000 URL 的配額，取樣時要遵守。

收尾原則

定義範圍（抽樣、分群、OQL 過濾）再分析；週期告警上線前先手動跑一到兩週核對閾值與 OQL；任何 Oncrawl alone 算不出的指標，再考慮多 MCP。

常見問題

  • 這篇文章假設讀者已經會什麼？作者寫明這是上一篇 Oncrawl MCP 入門之後的進階篇，適合已熟悉 MCP 與 Oncrawl 的使用者，不是從零介紹產品。
  • 為什麼介面裡的 pages 與 links 資料集要用 MCP join？文中說 Data Explorer 目前不能用 URL 當鍵把頁面資料集與連結資料集做站內 join；MCP 可交叉比對 inrank、深度與錨文字等欄位。
  • 作者建議的資料集規模上限是多少？作者建議大約 10 萬個 URL、連結來源不超過約 100 萬條連結；再大會讓 token 成本與計算時間急遽上升。
  • 多 MCP 診斷分成哪三個 bucket？Bucket A 是結構內但 Oncrawl 抓不到；Bucket B 是結構外孤兒卻有 GSC 發現訊號；Bucket C 是已抓取但不可索引。文中並提醒 GSC URL Inspection 每日配額約 2000 個 URL。

編輯解讀

一句話重點：MCP 的價值不在「再多一個聊天窗」，而在把介面做不到的 join、告警與跨工具診斷變成可重跑的工作流。

這對你的網站意味著什麼：

  • 先確認日誌有正確進 Oncrawl，再談機器人告警。
  • Join 與多 MCP 分析一律先縮小範圍，避免一次性餵入全站。
  • 週期 Slack 告警上線前，用一到兩週手動結果校正誤報。
  • 社群 GSC MCP 不算官方元件，客戶專案前要做權限與安全評估。

適用與不適用的情境：已有 Oncrawl 專案、熟悉 Claude Code 的技術 SEO 團隊最有用。還沒穩定爬取與日誌管線的團隊，應先補基礎監控。

需要注意的限制：發布者 Oncrawl 可能在銷售爬蟲平台與 MCP 整合；文中提示與配額以撰寫當日為準，介面能力之後可能改變。

延伸閱讀：

名詞與資料來源

1. Model Context Protocol（MCP）— modelcontextprotocol.io：〈Getting started〉 https://modelcontextprotocol.io/docs/getting-started/intro（檢索日期：2026-09-30） 2. 社群 GSC MCP — AminForou：〈mcp-gsc〉 https://github.com/AminForou/mcp-gsc（檢索日期：2026-09-30）

Similar Posts