先定義可證明的問題，才寫修復建議。
方法論不是保證結果；它規定每一個結論需要什麼資料、缺少資料時應保留什麼不確定性，以及如何回測。
這套診斷流程不是從 SEO 最佳實踐手冊改的。它是工程師除錯思維在技術 SEO 上的直接應用。我在 2013 年第一次遇到技術 SEO 問題時，處理方式和軟體 bug 完全一樣：確認症狀、讀 log、找最小可重現路徑、測假設、驗結果。後來發現這個順序在所有案子裡都適用，因為搜尋引擎處理網站的方式本來就是可觀察、可重現、可除錯的系統。—— Kevin Wu
#五階段診斷流程
01 SCOPE — 定義症狀、URL 群組、時間範圍與不在範圍內的問題
02 COLLECT — 標示每項資料是公開觀察、站方授權或推論
03 TEST — 用可重複步驟排除相近機制，不只列出錯誤碼
04 PRESCRIBE — 提出可回退、可驗收的變更與相依條件
05 VERIFY — 在相同或明示不同的條件下，重新量測與記錄結果
02 COLLECT — 標示每項資料是公開觀察、站方授權或推論
03 TEST — 用可重複步驟排除相近機制，不只列出錯誤碼
04 PRESCRIBE — 提出可回退、可驗收的變更與相依條件
05 VERIFY — 在相同或明示不同的條件下，重新量測與記錄結果
為什麼叫 Clinic？
我把網站當病人，不是當分數。分數告訴你「這個數字不好」；診斷告訴你「這個症狀的機制是什麼，怎麼驗證，修了之後怎麼確認好了」。2013 年我遇到的第一個 SEO 問題是一個客戶網站做了域名遷移之後完全消失。當時我不是去看 SEO checklist，我是去看 robots.txt 和 redirect chain——因為那是工程師遇到「不見了」這個症狀的標準第一步。結果確認是 robots.txt 誤封了 Googlebot 加上 redirect 設定錯誤，一天之內修復。這個診斷邏輯就是這套流程的原型。—— Kevin Wu
#證據分級
A．可直接觀察
HTTP、HTML、robots、sitemap、canonical 與公開可重現的渲染輸出。
B．站方授權資料
GSC、日誌、Analytics、部署紀錄。報告必須說明存取日期與範圍。
C．待驗證假設
尚無法取得資料時，只能列為測試假設，不能包裝成根因。
#結論如何跨過判讀門檻
我有一條規則：永遠不要在搞清楚「症狀 → 根因 → 機制」之前動任何東西。2016 年有個新聞網站找我，說索引量掉了 40%，所有人都在猜是不是內容品質問題。我的第一步不是看文章，是拉 server log。結果是 Googlebot 在爬分頁時收到 soft 404——2 萬個 URL 在回傳空內容。沒有人注意到，因為用瀏覽器打開頁面是正常的，只有 bot 觸發了那個條件。修了 canonical 和分頁邏輯之後，六週內索引覆蓋率恢復。如果當時直接從內容下手，這個問題可能今天還在。
| 命題類型 | 最低需要 | 結論可以寫到哪裡 |
|---|---|---|
| 可觀察症狀 | 可回查的 URL、時間與輸出 | 「在這個範圍觀察到 X」 |
| 可能機制 | 至少一個能區分相近機制的測試或資料需求 | 「X 與此機制相符，仍待排除 Y」 |
| 修復建議 | 變更範圍、相依條件、回退方式與驗收輸出 | 「可先測試此變更，成功條件為 Z」 |
| 已驗證結果 | 變更後在相同或已聲明不同的條件下重測 | 「此輸出已改變；搜尋系統採納與時間仍另行觀察」 |
#兩種常見情境，兩種不同的第一步
情境：改版後一批頁面不見
先不要假設：所有問題都來自 redirect。
先比較：舊新 URL 對照、redirect chain、canonical、內部連結、sitemap 與部署日期。
可接受的下一步：挑選跨模板樣本，找出未對應或相互矛盾的狀態，再指定修復範圍。
先比較：舊新 URL 對照、redirect chain、canonical、內部連結、sitemap 與部署日期。
可接受的下一步：挑選跨模板樣本，找出未對應或相互矛盾的狀態，再指定修復範圍。
情境：頁面看得到，搜尋呈現卻異常
先不要假設：任何 markup 錯誤都是原因。
先比較：可見主體內容、JSON-LD、驗證器、模板差異與 GSC 增強功能資料。
可接受的下一步：先修正可見內容與標記不一致，再確認該呈現類型的資格與觀察時間。
先比較：可見主體內容、JSON-LD、驗證器、模板差異與 GSC 增強功能資料。
可接受的下一步：先修正可見內容與標記不一致，再確認該呈現類型的資格與觀察時間。
#限制與修復驗證
不做的承諾
不以單次工具分數判定全站健康，不把正確 markup 等同搜尋展示，也不承諾排名或收錄日期。
完成的定義
變更有明確範圍、可回退紀錄、相同條件下的回測，以及仍未能確認的限制說明。
校正不是刪除不方便的結果
如果後續 log、GSC 或重測與原先判讀衝突，紀錄應保留原始觀察、說明更新的資料與受影響的結論。無法確認的部分繼續標為限制，而不是被新的敘述覆蓋。
#常見問題
公開觀察和站方資料衝突時，哪一個比較準？
先檢查觀察時間、URL、權限範圍與資料定義是否相同。它們可能在回答不同問題，不應直接挑一個作為唯一真相。
沒有 GSC 或 log，還能做什麼？
可以先完成公開可重現的觀察與提出資料需求，但任何需要權限資料才能確認的根因，必須維持為假設。
為什麼不直接給一個全站健康分數？
單一分數會混合不同 URL、環境與風險，無法指出要改什麼、怎麼回退或如何驗證。診斷需要可操作的範圍與證據。