大多數團隊其實已經有一份 Google 排名報告。那就是 Search Console 的「成效」分頁，按點擊排序，截圖貼進簡報。它顯示了排名。它沒有顯示什麼變了、為什麼變、以及誰該做什麼。
這套流程一次坐下來就能解決這個問題。你定義一組查詢，把一份寫好的報告契約交給 Codex，然後讓它每週產出形狀完全相同的報告。首次建置大約 90 分鐘，之後每次執行不到十分鐘。
整套流程：原始匯出進去，固定形狀的報告出來，最後人工做一次判斷。
做完之後你會得到什麼
適合誰： 負責站點報告、並且已經有 Search Console 權限的人。你不需要是開發者，但需要有一個 Codex 能讀取的檔案存放位置。
做完時你手上有什麼： 一份儲存好的報告範本、一份 Codex 每次都會遵循的書面指令檔案，以及一份來自真實某一週的完整報告。
前置條件： 一個已驗證的 Search Console 資源、一份你真正在意的 20 到 50 個查詢清單、一個能存取專案資料夾的 Codex；如果想做進階版，還需要對自家站點儲存庫的讀取權限。
完成的定義： 你能把報告交給一個不做 SEO 的人，而他能說出該看哪三個查詢以及為什麼。
耗時： 首次建置約 90 分鐘，之後每次執行不到 10 分鐘。
為什麼「成效」報告不是排名報告
Search Console 給你四欄：點擊次數、曝光次數、點擊率、平均排名。那是一張測量表。而排名報告必須回答的是另一組問題，2026 年的訊號讓這個差距比過去更大。
Zyppy 於 2026 年 9 月 9 日發布的專家調查，從 131 位從業者那裡收集了 13,665 個資料點。點擊與行為訊號為 29.4%，品牌訊號為 27.0%，技術 SEO 健康度為 17.5%。在這三個排名高於技術健康度的訊號裡，有兩個在排名欄裡是看不見的。這些數字會帶來什麼改變，我們在實作指南裡有單獨拆解；但就報告而言，簡短版本是這樣的：如果你的報告只展示排名，那你報告的正是變動最小的那個訊號。
這就是 Codex 補上的缺口。它不會告訴你 Google 為什麼改了東西。它會把變化的證據組裝得足夠一致，讓你能自己說出來。
開始之前：四個決定
在動筆之前先把這些定下來，因為之後改動意味著重做報告。
- 查詢集合。 20 到 50 個查詢，分成兩到三個符合業務思考方式的桶。「產品」「比較」「支援」比「高流量 / 中流量 / 低流量」更好用。
- 對比視窗。 用最近 28 天對比此前 28 天。視窗更短雜訊大，更長則會掩蓋你要找的變化。
- 門檻值。 決定什麼才算值得報告。查詢移動超過五個位次，或者點擊持平而曝光次數變動超過 30%，都是可用的預設值。
- 存放位置。 一個資料夾，一條命名規則。
reports/ranking/YYYY-MM-DD.md，再加一個放原始匯出的data/子資料夾。Codex 需要一個穩定的寫入位置。
第 1 步：匯出原始資料
打開 Search Console，選中你的資源，進入「成效」頁面。把日期範圍設為 56 天，這樣一次匯出就能做 28 天對 28 天的比較；然後用「匯出」按鈕下載「查詢」分頁的 CSV。
「網頁」也照做一遍；如果你打算報告行動裝置與桌機的拆分，「裝置」也做一遍。
預期產出： data/ 裡三個 CSV 檔案，檔名帶上匯出日期。
品質檢查： 打開查詢 CSV，確認第一列資料不是一個包含 "anonymous" 一詞的查詢。Search Console 會隱去冷門查詢，否則這些列會在報告裡顯示為無名的變動。
如果失敗： 如果匯出被截斷，說明你的日期範圍相對於列數上限太寬了。分次匯出 28 天視窗，讓 Codex 把它們拼接起來。
第 2 步：寫下報告契約
這一步決定了這套流程能否活過第三週。把契約放進一個 Codex 每次執行都會讀取的檔案裡——專案根目錄的 AGENTS.md，或者報告資料夾裡一份專門的指令檔案。
契約只需要五樣東西，別的都不要：
契約區塊 | 寫什麼 | 為什麼重要 |
|---|---|---|
輸入 | 確切的檔案路徑和日期範圍規則 | 阻止代理自己發明視窗 |
門檻值 | 你的分檔，用數字寫 | 把一張表變成一次決策 |
輸出形狀 | 三個小節，按順序 | 讓第 30 週和第 1 週可比 |
信心規則 | 資料解釋不了變化時該怎麼寫 | 防止自信的胡說 |
邊界 | 代理絕對不能做的事 | 在信任它之前保持唯讀 |
一個能用的版本長這樣：
## 排名報告契約
輸入: data/queries-*.csv, data/pages-*.csv
視窗: 最近 28 天對比此前 28 天。兩個日期都要寫在報告標頭。
只報告三件事:
1. 變動的查詢: 移動超過 5 個位次的，或點擊持平而曝光次數
上漲超過 30% 的，或任何跌出前十的查詢。
2. 可能的原因: 只用檔案裡的資料。如果檔案解釋不了這次變動，
就寫「本資料無法解釋」。
3. 下週檢查: 每個被標記的查詢一列，指名要檢查的確切頁面或
查詢。
絕對不要陳述你在資料裡指不出來的原因。絕對不要建議站點改動。
絕對不要編輯 reports/ranking/ 之外的任何檔案。預期產出： 一個指令檔案，提交到版本庫，或儲存在資料旁邊。
品質檢查： 把契約朗讀一遍。如果任何一列在不做修改的情況下也能適用於另一個站點，那它就模糊到約束不了任何東西。
如果失敗： 如果 Codex 總在加小節，說明輸出形狀不夠具體。把三個標題按你想要的措辭原樣寫出來。
報告的結構。列出所用確切檔案的頁尾是複核者最信任的部分，也是大多數範本會漏掉的部分。
第 3 步：生成第一份報告
把 Codex 指向那個資料夾，讓它按契約產出一份報告。要檔案，不要聊天裡的回覆，這樣產出才可複核、可比對差異。
第一次執行正是你發現自己的資料實際長什麼樣的地方。預計會有兩三輪修正。這很正常，也是整套流程裡最便宜的部分。
預期產出： reports/ranking/YYYY-MM-DD.md，帶一個標頭、三個小節，以及一個列出所用確切檔案的頁尾。
品質檢查： 挑兩個被標記的查詢，在 Search Console 裡手工核對數字。如果對得上，管線就是可靠的。如果對不上，停下來先修資料步驟。不要在壞掉的輸入上去排查分析。
如果失敗： 最常見的失敗是匯出與契約之間的日期不一致。每次執行都把兩個日期釘在標頭，這樣兩天的偏移就不會悄悄把一個持平的月份變成一場崩塌。
我建的第一版，在一個其實沒怎麼動過的星期裡報告了十一個變動查詢。契約沒問題，是匯出有問題。一個 30 天的檔案拿去和 28 天視窗比，兩天缺失的資料看起來就像全站崩塌。現在契約在兩個範圍不一致時會拒絕執行，那個故障再沒出現過。
第 4 步：加上代理寫不了的那一列
每份報告都要有一段人寫的文字：我們上週上線了什麼、改了什麼、弄壞了什麼。
這不是裝飾。這是抓住「把你自己發的版本歸咎於演算法更新」的代理最快的辦法。當報告說一批產品頁掉了，而你的備註說範本在週二改過，解釋範圍立刻就收窄了。
預期產出： 報告頂部由人寫下的兩到三句話。
品質檢查： 如果備註和變動小節互相矛盾，那個矛盾就是整份報告裡最有價值的一列。讓它留在那裡，別抹平。
第 5 步：發送之前先驗證
在報告離開你的桌子之前，跑完這三項檢查。
- 日期。 兩個視窗都寫在標頭，並且與匯出相符。
- 兩次抽查。 兩個被標記的查詢已人工核對。
- 一次矛盾檢查。 有沒有哪個聲稱的解釋引用了底部檔案清單裡沒有的資料？
三項全過，報告就可以放心分享。它是你判斷的草稿，不是判斷的替代品。
準備好了再走進階路線
先手工跑四週。等你把同一類錯誤改了兩次之後，再考慮自動化。
之後的升級是漸進的：
- 把執行排進排程。 每週定時執行會在你打開筆電之前把報告寫好。把人工段落設為必填欄位，這樣報告不帶上它就發不出去。
- 把快照存進版本控制。 每次執行都是一個提交。兩週之間的差異比任何一份報告都讀得更快。
- 加上第二個資源。 競品或品牌查詢放在一份用同一契約的獨立報告裡，不要合併進主報告。
- 加一個外部訊號。 品牌搜尋或回答佔有率的檢查，能讓 2026 年調查裡的品牌訊號從理論變成可測量。
不要自動化的東西：建議這一步。代理一旦開始提議站點改動，你就已經從報告跨到了發布，而複核負擔的增長速度會快過省下的時間。
疑難排解
症狀 | 可能原因 | 處理 |
|---|---|---|
每個查詢看起來都在跌 | 兩次匯出之間的日期範圍偏移 | 把兩個視窗同時釘在契約和標頭裡 |
報告是空的 | 相對於你的流量水準門檻值太嚴 | 先調低曝光次數門檻值，再考慮調低位次門檻值 |
每週都是同樣那五個查詢 | 查詢集合太窄 | 往桶裡加入長尾詞和比較類查詢 |
有變動但沒有解釋 | 對低流量查詢來說很正常 | 保留「本資料無法解釋」這個輸出，繼續往下走 |
數字與 Search Console 不一致 | 匯出時的資源或篩選器不匹配 | 每次都從同一個資源、同一組篩選器匯出 |
維護這套流程
三個維護習慣能讓它在第一個季度之後繼續有用。
每季度審查查詢集合。 一份還在追蹤去年優先順序的報告是歷史課，不是排名報告。
Search Console 一變就重讀契約。 Google 會定期更新「成效」報告的介面和匯出欄位。如果某個欄位消失了，契約當天就要改。
保留舊報告。 拿本季度的報告對比去年同季度，是區分真實下滑與季節性最便宜的辦法。
常見問題(FAQ)
一定得用 Codex 嗎? 不一定。只要一個代理能讀檔案、能按排程執行、能寫出可複核的產出，這套流程就能跑。如果你的站點本來就放在儲存庫裡，Codex 很合適，因為報告會變成一個可以比對差異的提交。
只用免費工具能做到嗎? 可以。整套流程跑在免費的 Search Console 資料加上代理之上。只有當你需要競品排名、或在自己資源裡看不到的排名時，才需要付費的排名追蹤工具。
這和 Search Console 的「成效」報告有什麼不同? 「成效」報告給你一張表。這套流程產出一個決策：哪些查詢越過了門檻值、資料解釋了和解釋不了什麼、下週該檢查什麼。它還留下了紀錄，而介面不會留。
如果我的站點流量很少呢? 調低曝光次數門檻值，並且用 28 天對比去年的同一段 28 天，而不是對比此前 28 天。低流量站點從同比比較裡拿到的訊號，比從週環比裡拿到的更多。
報告裡該包含 AI 總覽或 AI 引用嗎? 想加就加一個獨立小節，給它自己的契約。別放進排名報告裡，因為來源和度量方式都不同，混在一起會讓兩邊都更難讀。
作者：Leo Harrington，Auspia 的 SEO 分析轉譯者，處理過 500 多份高階主管報告。Leo 寫的是如何把搜尋資料變成非專業人士也能據以行動的報告。
