Claude 整合 Search Console：MCP 設定與查詢實戰

把 Search Console 接進 Claude 的正規路線，2026 年 9 月的現況是：Google 沒有推出官方的 Search Console MCP 伺服器，實務上走的是官方 Search Console API，搭配一套社群維護的 MCP 伺服器，再從 Claude Desktop、Claude Code 或遠端連接器接上。完成初次設定後，即可在對話框裡用自然語言查搜尋成效、比較期間與進行頁面索引診斷，但權杖失效或相依套件改版時仍可能需要維護。

這條工作流成立的前提，是 MCP 已經是 AI 工具串接資料源的共通標準。Claude 支援它，Search Console API 提供資料，中間缺的那一截，就是社群 MCP 伺服器補上的。行文順序先確認 Google 官方路線的現況，接著拆解三條接線路線的取捨，然後是把 API 憑證與伺服器設定做完的實際步驟，再進入查詢實戰與資料解讀的眉角，收尾是額度、安全邊界與導入判斷。所有規格與數字以各官方文件與專案頁面在 2026 年 9 月的內容為準。

先確認事實：Google 沒有官方 Search Console MCP

動手之前先把一個常見誤解拆掉。很多教學文章會寫「Google 官方 MCP」，但對照官方來源，這個說法目前不成立。Google 在 GitHub 上的google/mcp 儲存庫自我定位是收錄 Google 官方 Model Context Protocol 伺服器的清單，裡面的遠端伺服器清單列了 BigQuery、Bigtable、Cloud SQL、Firestore、Spanner、Cloud Storage、Compute Engine 這類雲端資料與運算產品，開源清單列了 Google Workspace、Firebase、Go、Chrome DevTools 等專案。兩份清單從頭到尾沒有 Search Console。另一份官方文件Google Cloud MCP 支援產品頁寫明，頁面列出的是可以透過遠端 MCP 伺服器存取的 Google 產品與服務，這些伺服器跑在 Google 基礎架構上，同樣找不到 Search Console 的影子。

更有說服力的對照來自 Google 自己的行銷測量產品線。開源清單裡的googleanalytics/google-analytics-mcp是 Google Analytics 團隊維護的官方專案，README 寫得很清楚：這個儲存庫提供在本機執行、與 Google Analytics API 互動的 MCP 伺服器原始碼，底層用 Google Analytics Admin API 與 Data API 提供工具給 LLM 呼叫。同一家公司，同樣是網站分析資料，GA 拿到了官方 MCP，Search Console 沒有。截至 2026 年 9 月，這個對照只能證明官方清單有 Google Analytics MCP，沒有 Search Console MCP，無法據此判定 Google 的產品決策原因。

沒有官方伺服器，不等於這條路走不通。MCP 是開放標準，任何人都能為任何 API 寫一層 MCP 包裝，社群也確實做了，而且不只一套，後面會介紹三套 README 提供安裝與使用資料的社群伺服器。誠實的結論是：Claude 串 Search Console 的 MCP 工作流是真的，但它的地基是官方 API 加社群伺服器，不是 Google 官方代管的服務。這個區別影響你怎麼評估信任邊界與維運責任，採購或導入前把這句話記住，可以省掉後面很多誤會。

這條工作流在解決什麼問題

Search Console 的成效報表本身不難用，難用的是「反覆查」。看起來像簡單提問的任務，在介面裡要點好幾下：換日期範圍、切維度、套篩選、匯出、再貼到試算表做第二次整理。官方成效報告說明指出，報表預設顯示點擊與曝光資料，想看其他日期範圍必須手動調整。需要跨資源與維度反覆查詢的團隊，操作時間會耗在這些重複動作上。

接上 MCP 之後，這些動作收斂成一句話。對 Claude 說「列出某網址近三十天點擊前二十的查詢字，標出平均排名在十一到二十之間的」，模型會自己組查詢、帶參數、呼叫伺服器、把回傳的列整理成結論。查詢的彈性來自對話，資料的正確性來自 API，兩邊各做自己擅長的事。若要降低模型改寫或計算造成的誤差，應要求回覆附上 API 回傳列、資源、日期範圍與維度，並在發布前核對數字。

定位上，這也是系列文章的第三塊拼圖。用 Claude 查第三方搜尋量估算，走的是Claude 配 DataForSEO 的關鍵字研究。把廣告帳戶的結構化資料丟給 Claude 健檢，看Google Ads 的 Claude 稽核流程。第三塊，就是你在讀的這個組合，處理自家網站在 Google 搜尋裡的真實成效資料。三者疊起來，等於把關鍵字估算、付費投放、自然搜尋三個資料面都接進同一個對話介面。DataForSEO 給的是估算值，Search Console 給的是自己網站的實際點擊與曝光，兩者互相印證而不是互相取代。

三條接線路線，按使用情境選一條

路線一，本地 stdio 伺服器。你在自己的電腦跑一支 MCP 伺服器程式，Claude Desktop 或 Claude Code 以子程序的方式啟動它，資料從你機器上的憑證直接打到 Google，不經過第三方雲端。優點是信任邊界最小、不用架伺服器，缺點是只綁在裝置上，換電腦要重設。

路線二，自架遠端伺服器。把同一支伺服器用 HTTP 或 SSE 傳輸部署到一台對外可達的主機，好處是任何裝置上的 Claude 都能連，團隊共用一份設定，claude.ai 網頁版也走得通。代價是要處理主機、網域、憑證與更新，等於多背一個小型維運責任。

路線三，直接用別人代管的連接器。具體選項是社群專案 README 提到的代管版本，這種做法可省去自架伺服器，但仍要完成連接與授權，並查明費用及資料政策，你的 Search Console 資料會經過第三方服務。

怎麼選，可以簡化成兩個問題。你能不能接受資料路徑上多一家廠商，能接受又想省事，走路線三。不能接受，再看使用場景：只有自己一兩台機器要用，路線一的設定量其實不大。要團隊共用或要在網頁版用，才值得為路線二架主機。

選路線二的人，部署形態可以照抄社群專案給的範本。以其中一套為例，遠端模式是把傳輸環境變數設成 SSE，繫結主機與埠（預設 3001）後直接啟動伺服器程式，專案同時提供 Dockerfile，可以用容器把同樣的環境變數與憑證掛載進去跑。自架主機必須能從公網連線，且不可被 VPN 或防火牆擋住，傳輸與 TLS 設定則依所選用戶端及部署環境的文件處理。憑證檔在容器裡的路徑要跟環境變數一致，這個小地方卡過不少人。

Search Console API：整條路的地基

不管走哪條路線，底層都是同一支 API。官方說明對 Search Console API 的定位是：以程式化方式存取 Search Console 大部分的功能，可以用來檢視、新增或移除資源與 Sitemap，對你在 Search Console 管理的資源執行 Google 搜尋結果資料的進階查詢，以及測試個別頁面。開發者首頁的說法相同：查搜尋分析、列出已驗證的網站、管理 Sitemap。

權限模型要注意。官方明寫，你必須對任何想透過 API 存取的 Search Console 帳戶具備適當存取權，等級分擁有者、完整、唯讀三種。API 可以存取 Search Console 的多數功能，能看到哪些資源取決於使用者權限，搜尋分析回傳仍受資料列省略與查詢參數限制。技術形態上，這是一支 HTTP REST 服務，可以直接呼叫，官方也建議用現成的用戶端程式庫。MCP 伺服器扮演的角色，就是把這些 REST 端點包成模型能呼叫的工具，中間沒有再發明新資料。

核心是搜尋分析查詢方法。查詢方法參考文件的描述是：這個方法回傳零或多列資料，按你定義的維度分組，而且必須定義一或多天的日期範圍。可用的分組維度包含國家、裝置、頁面、查詢字，也能加上日期與小時做時間切分，篩選器可以用你沒拿來分組的維度過濾。回傳的指標是點擊、曝光、點閱率與平均排名。理解這個模型，後面對 Claude 下指令時就會知道哪些要求做得到、哪些要求超過資料本身的顆粒度。

搜尋類型是容易被忽略的第二個查詢參數。預設的 web 對應介面裡的「全部」分頁，涵蓋 Google 搜尋的綜合結果，但不包含 Discover 與 Google 新聞。想看 Discover 的表現要指定 discover，Google 新聞應用程式與 news.google.com 的資料走 googleNews，搜尋結果「新聞」分頁則是另一個 news，圖片與影片也各有對應類型。多數 SEO 分析只用 web，但內容站與媒體站的流量結構裡，Discover 占比可能很可觀，漏看等於漏掉一大塊。對 Claude 下指令時把類型講明白，拿到的數字才會對得上你腦中的報表。

回傳的排序規則也值得先知道，免得誤讀模型整理出來的表。預設按點擊數由高到低排，唯一的例外是把日期納入分組時，改按日期從舊到新排，兩列數字相同時順序則是任意決定。日期在分組維度裡的行為也值得注意，沒有資料的天數會直接缺席，不是補零，文件建議想確認哪些天有資料，就先對日期範圍發一個以日期分組、不帶篩選的查詢。做時間序列比對時，缺列與補零的差異會影響解讀，這個小知識能省掉一輪迷惑。

把時間顆粒拉近到小時，是查詢方法比較少人知道的能力。維度可以用 date 加上 hour 切分，搭配 dataState 設成 hourly_all 時回傳會包含小時級細分，官方文件提醒這類資料含部分初步值，適合與小時維度搭配使用。實務場景是新聞稿、活動頁這種生命週期以小時計的內容，發布後頭幾個小時的搜尋反應只有這個顆粒度看得到。一般內容站的週期分析用日資料就夠，知道這個開關的價值，在於臨時要查短時段異常時知道往哪裡看。

事前準備：兩種憑證，選一種

共用前置動作只有一個：到 Google Cloud Console 建立或選一個專案，然後在API 媒體庫裡的 Search Console API 頁面把它啟用。這一步不管用哪套伺服器、哪種憑證都一樣，差別只在之後發哪種金鑰。

憑證一，OAuth 桌面應用程式，適合個人使用者。流程是到憑證頁面建立 OAuth 用戶端 ID，設定同意畫面時選桌面應用程式，建立後下載 JSON 檔存好。第一次使用的時候會開瀏覽器視窗要求登入 Google 帳號，之後權杖快取起來，不再需要互動。這條路的好處是你用自己在 Search Console 裡的權限查自己的資源，看到什麼跟介面一致。

憑證二，服務帳戶，適合自動化與團隊共用。建立服務帳戶、在金鑰分頁產生 JSON 金鑰下載，然後做關鍵的一步：把服務帳號的電子郵件加進需要存取的 Search Console 資源，路徑是設定、使用者與權限、新增使用者，權限等級依所選伺服器的 README 設定：mcp-gsc 的範例要求完整存取，sarahpark 的唯讀伺服器要求受限制存取。服務帳戶自己不是任何人，它是靠被加為資源使用者才拿得到資料，所以權限邊界其實比 OAuth 更好控制，你可以只加特定資源。要注意它加進來的是一個身分，會出現在使用者清單裡，離職或輪替時記得移除。

兩種憑證的選擇判斷很直觀。只是自己查資料，OAuth 點一點就好。要放進排程、要給 CI 或團隊共用伺服器，服務帳戶才是對的工具。有些社群伺服器只支援其中一種，安裝前先看清 README 的需求欄位，例如有幾套 Node 系的伺服器就只吃服務帳戶，前置需求寫的是 Node.js 18 以上加服務帳戶憑證。

OAuth 路線的使用體驗值得先講清楚，很多人擔心每次查詢都要登入一次，實際不是。專案的設計是第一次使用時開一個瀏覽器視窗，要求登入 Google 帳號並確認授權，之後權杖存起來，不再需要瀏覽器互動。你要做的只有兩件事：把第一次的授權畫面看完，以及把下載的 JSON 檔放在一個不會被清理的固定路徑。權杖失效時，依錯誤訊息呼叫 reauthenticate，再完成瀏覽器登入。

社群 MCP 伺服器怎麼挑

挑伺服器的第一個建議：挑有維護紀錄的。MCP 生態迭代快，SDK 一改版，沒人維護的伺服器會直接開不起來。一個實際案例：MCP Python SDK 2.0.0 在 2026 年 7 月 28 日改版，移除了 mcp.server.fastmcp 模組，當時所有新安裝的某套 GSC 伺服器全部啟動即崩，維護者後續發版，將相依版本限制在 mcp 2.0.0 以下後恢復運作。會看 changelog 的專案，出事才有人修。

mcp-gsc（套件名 mcp-search-console）是三個候選之一。它是 Python 專案，用 uvx 一行指令就能跑，OAuth 與服務帳戶兩種憑證都支援。工具面涵蓋：列出資源、查搜尋分析、比較兩個期間、查特定頁面的查詢字、進階篩選分析、單一網址檢查、批次檢查、Sitemap 查詢與提交管理。README 列出的完整工具清單共有二十項，不確定有哪些可用時，先叫模型呼叫 get_capabilities 這支工具，它會回報完整工具清單與目前的授權狀態，這在除錯時很好用。

第二套是 mcp-server-gsc，Node 系，走 npx 啟動，只支援服務帳戶。特色在查詢參數的包裝：一次最多拉 25,000 列資料，維度參數直接吃查詢字、頁面、國家、裝置、搜尋外觀、日期的組合，搜尋類型可以選網頁、圖片、影片、新聞、Discover、Google 新聞，篩選器支援用 regex 前綴做正規表示式過濾。它還內建一種叫 quick wins 的偵測，自動從資料裡撈出符合門檻的機會字，三個門檻都可以自訂，預設值落在排名四到二十、一百次曝光、百分之一點閱率這組數字上，這組門檻會先列出符合條件的優化候選查詢字。

第三套是 sarahpark 的 google-search-console-mcp，訴求是徹底唯讀。README 明寫：唯讀存取，這套伺服器不能提交網址、不能修改設定、不能對你的 Search Console 資源做任何變更。它用服務帳戶驗證，服務帳戶必須被加為每個想存取的資源的使用者。工具組有列出網站、搜尋分析、單頁檢查、Sitemap 清單，走的是小而美的路線，還附了一段可以直接貼給 Claude Code 的設定提示詞，讓模型自己完成安裝設定。

三套的共同點：都開源、都免費、都把 REST API 包成幾支到二十支不等的工具。挑選的原則按順序是：先挑唯讀或可寫符合需求的，再挑憑證類型符合使用場景的，再挑工具顆粒度符合查詢習慣的。要提交 Sitemap、要批次檢查網址，選功能全的那套。只是查資料做報表，唯讀那套反而睡得著覺。

伺服器	執行方式	憑證	權限範圍	特色
mcp-search-console	uvx（Python）	OAuth 或服務帳戶	查詢加管理（三項寫入操作預設關）	工具約二十支，含批次檢查與期間比較
mcp-server-gsc	npx（Node.js 18+）	服務帳戶	查詢為主	25,000 列上限、regex 篩選、quick wins 偵測
google-search-console-mcp	從原始碼建置	服務帳戶	徹底唯讀	小而美，附 Claude Code 一鍵設定提示詞

Claude Desktop 接本地伺服器：設定檔實做

路線一的標準接法是改 Claude Desktop 的設定檔。macOS 的設定檔位於使用者資源庫下的 Application Support 資料夾，檔名是 claude_desktop_config.json，Windows 使用者則在 AppData 對應路徑。在 mcpServers 物件裡加一個條目，command 填 uvx 或 npx 的完整路徑，args 填伺服器套件名，env 填憑證檔的絕對路徑變數。以 mcp-search-console 為例，OAuth 走 GSC_OAUTH_CLIENT_SECRETS_FILE 指向 client_secrets.json，服務帳戶走 GSC_CREDENTIALS_PATH 加上 GSC_SKIP_OAUTH 設 true。

新手最常卡住的一個坑是路徑。uvx 這類工具裝在使用者家目錄的 .local 資料夾，而 Claude Desktop 這種圖形介面程式啟動時不會讀 shell 設定檔，所以它不知道 .local 裡有什麼。解法是把 command 寫成完整路徑，macOS 或 Linux 在終端機裡 which uvx 查一下就是。如果看到 spawn uvx ENOENT 這個錯誤，答案幾乎都是這個。同樣的道理，憑證檔路徑要寫絕對路徑，不能用波浪號縮寫，更不能只寫檔名。

改完設定檔的標準動作是完整離開再重開。只關視窗不等於結束程式，macOS 上用 Cmd 與 Q 的組合鍵或選單列的結束，讓程式重讀設定檔。重開後先下一句最簡單的測試：列出我的 Search Console 資源。有回清單就是通了，沒有回應就讓模型呼叫 get_capabilities 看授權狀態，錯誤訊息通常會直接指出缺哪個檔或哪個權杖過期。

Claude Code 的接法

在 Claude Code 裡，MCP 伺服器用指令管理，不用手改檔案。官方Claude Code 的 MCP 文件建議遠端伺服器走 HTTP 傳輸，指令是 claude mcp add 加 --transport http 加名稱加網址。自架遠端 GSC 伺服器的人用這條。接本地伺服器則用 stdio 形式，claude mcp add 後面接名稱與啟動指令，用雙連字號把 Claude 自己的選項與伺服器的參數分開，憑證之類的環境變數用 --env 傳進去。

設定完的驗證靠兩個指令。claude mcp list 會在每台伺服器旁顯示健康狀態，例如已連線、需要驗證、連線失敗。claude mcp get 加名稱則看單台的細節與錯誤訊息。這些狀態講的是連線結果，不是指令本身成敗，讀的時候別搞混。另一個值得知道的行為：移除一台遠端伺服器時，Claude Code 會一併刪掉它為那台伺服器存放的 OAuth 權杖與用戶端註冊資料，換帳號重連是乾淨的。

如果你已經在 Claude Desktop 設好伺服器，搬過來不必重抄。Claude Desktop 用的 mcpServers JSON 區塊，把內層物件餵給 claude mcp add-json 就能轉成 Claude Code 的設定，文件裡還提醒了一個常見修正：有 url 但沒有 type 欄位的條目要補上傳輸類型，否則會被當成 stdio 伺服器讀取而失敗。同一段文件也指出，Anthropic 目錄裡審核過的連接器與 Claude Code 用同一套 MCP 基礎建設，清單上的遠端伺服器都可以用同一個 claude mcp add 指令接上。

網頁版 Claude：遠端連接器路線

想在 claude.ai 網頁版或手機版用，就必須走遠端。官方自訂連接器說明寫得明白：當你新增自訂連接器，Claude 是從 Anthropic 的雲端基礎架構連向你的遠端 MCP 伺服器，而不是從你的本機裝置發出連線。這代表伺服器必須放在公開網路可達的位置，家裡筆電上跑的 stdio 伺服器不在此列。

可用方案範圍比很多人以為的寬：自訂連接器功能在 Claude、Cowork 與 Claude Desktop 上，對免費、Pro、Max、Team、Enterprise 方案的使用者開放，免費方案限制只能加一台自訂連接器。個人 Pro 或 Max 使用者的設定路徑是自訂選單裡的連接器頁，點加號選新增自訂連接器，貼上遠端伺服器網址就完成。Team 與 Enterprise 則限定由擁有者在組織設定裡統一新增，成員再各自連接啟用。啟用之後，每一個對話都可以用輸入框旁的加號開關連接器，要用才開。

連接器與本地 MCP 是兩套並存機制。官方文件特別澄清：Claude Desktop 透過 claude_desktop_config.json 設定的本地 MCP 伺服器是另一套機制，走本機網路，但這些本地伺服器在 Cowork 與 claude.ai 上不可用。所以「桌面版設好的本地 GSC 伺服器，網頁版為什麼看不到」這個問題，答案不是設定錯，是設計如此。想兩邊通吃，就得把伺服器架成遠端，或者分開設定。

查詢實戰：五種對話模式

模式一，查詢字總覽與點閱率機會。開場句型是「列出某網址近三十天點擊數前二十的查詢字，附曝光、點閱率與平均排名」。拿到清單後接第二句「把平均排名十一到二十、點閱率低於百分之三的挑出來，按曝光排序」。平均排名落在十一到二十且曝光量足夠的查詢字，可列為後續評估標題與描述的候選名單。有伺服器內建這種偵測就直接叫它跑，沒有的用兩句話組合也一樣。

模式二，頁面與查詢字的下鑽。先看哪個頁面吃掉了流量，再問「這個網址的流量是哪些查詢字貢獻的」。對內容整治特別有用：檢視一個頁面帶入的查詢字，有助於判斷查詢意圖是否集中，是否拆頁或改寫仍要搭配頁面內容與搜尋結果判斷。搭配 regex 篩選，還能只看品牌字或非品牌字，品牌字占比的變化可作為市場認知的觀察指標之一。

模式三，期間比較。問法是「比較這個月與上個月的點擊與曝光，按查詢字列出漲跌最大的前十名」。週對週與月對月的比較是內容衰退的警報器，一支舊文從排名第五滑到第十，總點擊的變化可能不明顯，但逐字比較會現形。做這種查詢時，日期範圍要講清楚，資料有 finalized 與 fresh 之分，最近幾天的數字還會變，拿來比漲跌會誤判。

模式四，裝置與國家切片。同一批查詢字在手機與桌機的表現可以差很遠，問「把近九十天的查詢字按裝置分組，找出手機排名明顯差於桌機的前十名」，手機與桌機的排名差異可列為調查線索，後續仍要檢查查詢組成、搜尋結果版型與行動版體驗，不能只憑這份清單判定原因。國家切片則適合多市場網站，先看哪個國家的曝光漲最快，再決定內容在地化的順序。

模式五，網址層級的索引診斷。對特定頁面做單頁檢查，看檢索狀態、索引狀態與上次爬取時間，批次版一次可以丟十個網址。用法是把模式二發現的異常頁面丟進來，問「這些頁面有沒有索引問題，有的話給我一份按嚴重度排序的修復清單」。索引問題的修復優先序，讓模型按回傳的檢查結果排，比人工一頁頁點快得多。

五種模式共用的提示句心法只有三條。講清楚日期範圍與維度，模型才組得出正確的查詢。指定回傳數量與排序方式，避免模型自作主張截短。要求每個數字附上資源與日期口徑，進報告的數字要能回溯。把這三條練成反射動作，查詢品質就穩定了。

資料解讀的六個眉角

眉角一，單次回傳上限。查詢方法的 rowLimit 參數有效範圍是一到兩萬五千列，預設一千列，要更多就用 startRow 做分頁。長尾字很多的網站，一千列常常不夠，記得提醒模型翻頁，或直接叫它拉到上限。

眉角二，匿名查詢。官方說明直說：有些查詢字為了保護使用者隱私而被省略，稱為匿名查詢。它們計入圖表總數，但套用查詢字篩選時不會出現。所以「維度加總」與「逐字列出」的數字對不起來是正常現象，不是伺服器壞掉。

眉角三，資料截斷。官方同頁說明，基於內部限制，Search Console 只儲存與顯示最重要的資料列，查詢字報表顯示的並不是全部，最完整的查詢字清單要用大量資料匯出才能取得。大量資料匯出能取得較完整的查詢字清單，MCP 查詢不適合用來追求完整列舉。

眉角四，標準網址歸屬。多數成效資料會記在頁面的標準網址上，而不是重複網址。使用者點了重複網址，點擊仍計入標準網址。查某個網址沒數字時，先想它是不是被別的網址標準化掉了，問模型「這個網址的標準網址是哪個」通常能解謎。

眉角五，聚合層級改變數字。同一份資料，按資源聚合與按頁面聚合的點閱率與平均排名會不一樣，官方資料說明頁講得直接：如果同一網站的多個頁面出現在搜尋結果裡，按資源聚合時點閱率與平均排名通常比較高。API 端對應的是 aggregationType 參數，能選 auto、按資源、按頁面等模式。比較兩個來源的數字前，先確認兩邊的聚合層級一樣，否則是在比兩個不同的東西。

官方給的例子可以把差異具象化。假設某個搜尋只回三個結果，全部來自同一個資源的三個頁面，一位使用者三個連結都點了。按資源聚合時，點閱率是百分之百，因為整個網站算一次，所有點擊合在一起。按頁面聚合時，每個網址各算一次，三個頁面各分到三分之一的點閱率。平均排名也隨聚合層級改變：資源層級回報整個網站最好的位置，官方例子裡頁面層級把三個位置平均，三個網址同樣算出 2。同一個動作，兩套算法都對，數字卻差了三倍，這就是聚合層級要講清楚的原因。跟主管或客戶對數字之前，先對齊你們看的是哪一套。

眉角六，資料狀態與歷史視窗。查詢方法的 dataState 參數決定回什麼：設為 all 會包含新鮮資料，設為 final 或省略參數則只回定案資料，而最新資料可能仍在收集並繼續變動。歷史視窗的硬限制是十六個月，這個數字從新版 Search Console 上線時就是如此，2018 年 1 月的改版公告直接用「搜尋成效，有十六個月資料」當標題小節，目的就是讓較長期的趨勢分析做得起來。超過十六個月就查不到了，實務做法是自己排程定期把資料拉下來存，存了才是你的。

額度與成本

額度的窄門在網址檢查：URL 檢查 API 的公告寫明配額按 Search Console 網站資源計，限制值為 QPD 2,000 與 QPM 600。把幾百個網址掃一輪沒問題，更大規模的反覆掃描就要自己節流。

社群伺服器端，三套都是開源免費，成本是安裝與維護的時間。自架遠端路線還要計入主機或容器服務費用，以及憑證更新等維運成本。代管連接器路線則依服務定價，評估時把「資料經過誰」與「斷線時誰負責」兩個問題一起問。

整條工作流的成本結構，跟 DataForSEO 那種按量計費的第三方資料 API 完全不同。GSC 查的是自家資料，能放心地反覆查、探索性地下指令。真正的成本上限是設定的前置時間，以及你對資料口徑的把關時間。

安全與權限邊界

預設原則是唯讀優先。只需要讀取功能時，可優先選用明載唯讀的伺服器，以縮小可執行操作的範圍。功能全的那套，破壞性工具的處理方式值得參考：新增資源、刪除資源、刪除 Sitemap 這三個操作預設停用，要另開環境變數才會啟用。這種設計把「查資料」與「動設定」的邊界畫在組態層，比靠提示詞自律可靠。

服務帳戶的權限要給得剛好。README 的標準流程把服務帳戶加為完整存取，但如果你只查一個資源，就只把服務帳戶加進那個資源，不要圖方便全加。服務帳戶的 JSON 金鑰等於那個身分的密碼，放在誰能讀到的位置、備份到哪裡，都要照對待密碼的標準處理。

用自訂連接器掛第三方端點時，信任邊界要再想一層。官方文件提醒，自訂連接器讓 Claude 連上未經 Anthropic 驗證的服務，連線等於授權它讀取甚至變更你在該服務裡有權限的資料。更要警覺的是提示注入：惡意的 MCP 伺服器可能藏著指示，試圖讓 Claude 執行非預期的動作。自架伺服器自己看得見程式碼，這個風險可控。用來路不明的代管端點，等於把你的 Search Console 權杖交給陌生人。

研究功能與連接器的互動是另一個容易被忽略的角落。官方說明註明，進階研究目前無法呼叫本地 MCP 伺服器的工具，也就是說深度研究與你機器上的 GSC 伺服器無緣，這是遠端路線的一個實質誘因。反過來，研究過程中 Claude 會自動呼叫已連接連接器的工具，不再逐次徵求同意，官方因此建議在開研究之前，先停用任何會在外部服務裡執行寫入動作的工具。對 GSC 場景的落地版建議就是：選唯讀伺服器，或在開研究前把提交 Sitemap 這類工具關掉，讓自動化只碰得到讀取型操作。

常見錯誤排解

遇到 spawn uvx ENOENT 時，macOS 或 Linux 用 which uvx 查完整路徑，Windows PowerShell 用 Get-Command uvx | Select-Object -ExpandProperty Source，再更新 command。成因是圖形介面程式不讀 shell 設定，command 欄位寫短名稱就會炸。憑證路徑則照同樣標準檢查：相對路徑與波浪號都算錯，一律改成從根目錄開始的絕對路徑。

授權過期的表現是查詢突然回 401 或一直要求重新登入。OAuth 流程的解法是叫模型呼叫重新驗證的工具，或刪掉快取的權杖檔重跑一次瀏覽器登入。服務帳戶查不到資料時，先確認它仍在資源的使用者清單中，並檢查金鑰設定。

若查得到資源卻查不到某個網址，應依序檢查 siteUrl 格式、標準網址歸屬與資料截斷。siteUrl 的格式要跟資源類型一致：網址字首資源要填入 Search Console 顯示的完整網址與協定，網域資源則使用 sc-domain: 前綴，寫錯會對不到資源。格式對了還是沒資料，回頭想標準網址歸屬與資料截斷這兩個眉角，資料可能記在別的網址上，或者那個字的量太小被截掉了。

導入流程與判斷

整套流程收斂成四步。第一步做憑證，OAuth 或服務帳戶擇一，把 JSON 存到固定路徑。第二步接伺服器，路線一改一個設定檔、路線二或三貼一個網址，用列出資源這句話驗收。第三步跑五種模式各一次，用真實資料確認每種查詢回得來，順便熟悉自己網站的資料形狀。第四步把有效的提示句固定下來，變成團隊的查詢範本，固定報表可用排程執行，對話介面留給探索性查詢。

團隊導入時，帳號與範本的管理比個人場景多兩件事。第一件是憑證的責任歸屬，服務帳戶由誰建立、金鑰存在哪、誰有權輪替，要有明確答案，人員異動時同步更新 Search Console 裡的使用者清單，避免出現沒人認得的孤兒帳號。第二件是查詢範本的版本管理，有效的提示句存在共用的文件裡，附上每個範本適用的問題類型與口徑注意事項，新人接手時照著問就能得到同品質的答案。這兩件事沒做好，團隊可能各自發展不同查法，造成數字難以對齊。

值不值得長期用，三個問題自我檢核。查詢頻率高不高，頻率很低的人，把報表介面開著手動點可能還比較快。查詢型態偏不偏探索，臨時、組合式或需要反覆試查的問題較適合對話介面，制式報表則適合固定流程。數字要不要進正式報告，要的話口徑與來源標註得自己把關，模型的排版不會改變原始資料的定義。三題都過，這條工作流會變成日常。有一題猶豫，先小規模試用再決定。

收尾把它放回工具地圖。Search Console 自己也在演進，2026 年 6 月的生成式 AI 效能報告公告推出了專屬檢視，讓站方看見自己在 AI Overviews 與 AI Mode 等生成式功能裡的曝光，官方後記註明到 2026 年 8 月 31 日已推向全部網站。這類原生報表回答的是「AI 時代的能見度長什麼樣」，MCP 工作流回答的是「把既有成效資料變成可以對話的分析」，兩者互補。GSC 的基礎操作與報表解讀，站上的Search Console 完整指南與操作技巧有整理，MCP 協議本身的架構，請看MCP 協議深度介紹。對 Claude 生態的整體認識，可以從Claude 完整使用指南與Claude 桌面版指南補齊，終端機路線的深入操作則在Claude Code 教學。工具把查詢的摩擦降下來，判斷品質仍是使用者的責任，這條界線畫清楚，串接才是加分項。