網站被 Google 漏掉時，先找證據，再修復。
把爬取、索引、渲染、結構化資料與遷移問題，整理成可驗證的修復順序。 我們不在這裡假裝替你的網站跑完掃描；先選出症狀，取得該蒐集的證據與下一步。
Kevin 從工程師時代就有一個習慣：不在看到症狀的當下就決定怎麼修。他把這個習慣帶進技術 SEO 的工作——先確認機制，再安排修復順序。
#從症狀選擇診斷路徑
這個工具只整理公開且可由你取得的證據，不會連線掃描你的網站，也不會產生排名保證。
#每條路徑先看哪些證據
#同一個症狀，可能來自不同機制
這張表不是故障資料庫；它用來阻止「看到症狀就直接下結論」。每一列的第一步都應留下可回查的輸出。
| 可見症狀 | 先拆開的問題 | 第一份證據 | 暫時不能說的話 |
|---|---|---|---|
| 一批 URL 未被收錄 | 是抓取、索引選擇、canonical、內容近似，還是站內發現路徑不同？ | 跨模板 URL 樣本、HTTP、canonical、robots、sitemap、GSC Page indexing 狀態 | 「Google 處罰了整站」 |
| 主要內容看似沒有被讀到 | 內容是否在初始 HTML、是否被 JS／資源／條件式流程阻斷？ | 原始 HTML、渲染 DOM、資源請求、console 與對照 screenshot | 「JavaScript 網站一定不能被索引」 |
| 改版或換網域後下滑 | URL 對照、redirect、canonical、內鏈與部署時間線是否一致？ | 舊新 URL manifest、redirect chain、sitemap、部署與索引時間線 | 「所有波動都由 301 造成」 |
| 特殊搜尋呈現消失 | 可見主體資訊、標記、資格與模板差異是否同時成立？ | 可見內容、JSON-LD、驗證器、GSC 增強功能資料 | 「修正 markup 就一定恢復展示」 |
| 曝光或點擊突然變少 | 是查詢組、頁面組、索引狀態、呈現還是量測定義改變？ | 按日期、查詢、頁面群組拆分的 GSC 與變更紀錄 | 「單一總流量證明某個技術根因」 |
#診斷不是一次分數，而是一段可回查的流程
02 COLLECT — 標示每項證據來自公開資料或站方授權
03 EXPLAIN — 區分症狀、可能根因與仍待排除的假設
04 CHANGE — 指定可回退的修復動作與責任邊界
05 VERIFY — 以相同條件重新測量並記錄限制
#範圍與交接
#交接紀錄與公開校正
首頁工具只幫忙形成這份摘要，不會讀取登入資料、遠端掃描網址或代替站方做修復決策。
#公開診斷筆記
文章是方法的延伸；首頁不以時間排序取代診斷任務。已設定 server-only CMS 憑證時，這裡才顯示最近發佈的報告。
#診斷師
Kevin 本科念的是台科大電腦工程，畢業後做了三年網站開發，2013 年接到第一個 SEO 委託：客戶的網站在網域遷移後從 Google 消失了。他用除錯軟體 bug 的方式拆解問題——錯誤的重定向加上 robots.txt 擋住了 Googlebot——一天之內修好，問題解決。那次讓他意識到技術 SEO 的核心是工程邏輯，不是排名猜測。
另一個轉捩點是某家新聞網站：40% 的已收錄頁面突然消失，大家都在懷疑內容品質，Kevin 卻去拉了伺服器日誌，發現 Googlebot 在兩萬個分頁 URL 上拿到 soft 404，用 canonical 標籤修正後，六週內恢復。
「Nitikarn Clinic」這個名字來自泰文「นิติกาล」（niti-kaan），意思是程序秩序——反映他做診斷的方式：每一個症狀都有一個機制，每一個機制都有一個修復順序，不跳步驟。
他的診斷哲學是：分數是快照，不是診斷；要找的是機制，不是數字。