伺服器回應碼稽核怎麼做：一份每季可照著勾的十二項檢核清單

伺服器回應碼稽核，是定期把網站每個重要網址的回應碼抓出來，比對「應該是什麼」與「實際是什麼」。重點不在背代碼，而在找出三種落差：該正常卻報錯、該轉址卻沒轉、轉址繞了好幾圈。一份季度檢核清單就能做完。

這篇是一份可以照著勾的檢核清單，分成稽核前、稽核中、稽核後三段。每一項都寫了要看哪裡、看到什麼算異常。各代碼的意義與選用判斷，我在HTTP 狀態碼判斷表寫過，這裡不重複，只談怎麼稽核。

為什麼回應碼要定期稽核，而不是出事再查？

回應碼出錯通常沒有聲音。網站看起來正常，老闆點首頁也打得開。可是某個商品分類頁回了錯誤，某批舊文章的轉址指向已刪除的頁面，搜尋引擎與 AI 摘要工具就會慢慢少抓這些網址。等流量掉了才查，往往已經過了好幾週。

中小企業網站最常出問題的時間點，是外掛更新、主機搬家、改網址結構、下架商品之後。這些事每季都可能發生，所以稽核也以季為單位最實際。Google 在搜尋引擎最佳化入門指南中說明了網址結構與搜尋引擎如何找到網頁，這是稽核的背景知識。

稽核前：準備四份清單

沒有基準就無從比對。稽核前先備好下面四份資料，放在同一個試算表的不同分頁。

• 網址總表：從網站地圖匯出所有提交給搜尋引擎的網址
• 高價值網址表：首頁、服務頁、熱門文章、主要商品分類，通常不超過五十條
• 歷史轉址表：過去改版或改名時設定的所有轉址規則，含來源與目的地
• 下架紀錄：過去一年刪除或停售的頁面，以及當時的處理方式

高價值網址表最重要。全站可能上千條網址，人力有限時，先確保這五十條全部正常。歷史轉址表常常不存在，若找不到，就從主機或外掛的轉址設定直接匯出。

稽核中：十二項檢核清單

以下十二項，依處理優先順序排列。每一項都附上「異常長什麼樣」，勾選時直接在試算表標記。

第一組：該正常的網址

檢核項目	看哪裡	異常的樣子
一、高價值網址是否都回應正常	爬蟲工具逐條抓取	任何一條出現錯誤或轉址
二、網站地圖內是否只有正常網址	網站地圖與爬蟲結果交叉比對	地圖裡混了已轉址或已刪除的網址
三、軟性錯誤頁	Search Console 網頁索引報表	頁面顯示「找不到商品」卻回應正常
四、伺服器錯誤是否集中在特定時段	主機錯誤紀錄	某些時段集中出現伺服器錯誤

第三項最容易漏。電商商品下架後，頁面還在，只是寫著「此商品已下架」，回應碼卻是正常。搜尋引擎會把這種頁面當成內容很薄的頁面。處理方式要依有沒有替代商品決定。

第二組：該轉址的網址

檢核項目	看哪裡	異常的樣子
五、歷史轉址是否仍有效	把歷史轉址表的來源網址逐條抓取	來源網址變回錯誤，或指向錯誤頁面
六、轉址鏈	爬蟲工具的轉址路徑欄位	一個網址轉了兩次以上才到終點
七、轉址迴圈	爬蟲工具錯誤清單	A 轉到 B，B 又轉回 A
八、暫時轉址用在永久情境	轉址規則設定頁	改版已半年，規則仍設為暫時轉址

轉址鏈在改過兩次以上網址結構的網站很常見。舊網址先轉到第二版，第二版再轉到現行版。修法是讓所有舊網址直接指向最終網址，並同步更新歷史轉址表。

第三組：該消失的網址

檢核項目	看哪裡	異常的樣子
九、已刪除頁面的處理方式	下架紀錄與實際抓取結果	刪除的頁面全部轉到首頁
十、內部連結是否指向錯誤頁	爬蟲工具的內連來源欄位	文章內文仍連到已刪除網址
十一、測試站與暫存頁是否外露	搜尋引擎的網站指令查詢	測試網域或草稿頁被索引
十二、參數網址	網址總表與爬蟲結果	追蹤參數產生大量重複網址

第九項是常見的偷懶做法。把所有刪除頁轉到首頁，看起來沒有錯誤，搜尋引擎卻可能把這種轉址當成軟性錯誤。沒有對應替代頁時，讓它明確回應「已不存在」比較誠實。

用什麼工具做稽核？

免費工具就夠用。下表是我常用的組合，不需要付費授權。

• Google Search Console：網頁索引報表、網址檢查工具，看搜尋引擎實際看到的狀態
• 免費版網站爬蟲工具：多數有網址數量上限，小型網站足夠，大型網站可分段抓
• 瀏覽器開發者工具的網路分頁：逐條確認單一網址的回應碼與轉址路徑
• 主機控制台的錯誤紀錄：看伺服器錯誤發生的時間與頻率
• 試算表：所有結果集中在這裡，方便比對與交接

Search Console 的資料有延遲，爬蟲工具看到的是當下狀態。兩者不一致時，以當下狀態為準先修，再等 Search Console 更新。

稽核後：修正順序與紀錄

十二項全部勾完，通常會有一串待修清單。不要一次全修，依影響範圍排序。

• 先修高價值網址的錯誤與轉址迴圈，這兩類會直接讓重要頁面無法被抓取
• 再修轉址鏈與網站地圖內的錯誤網址
• 接著處理內部連結，把內文連結改成最終網址
• 最後處理參數網址與測試站外露
• 每修一批，用爬蟲工具重抓一次確認，再更新歷史轉址表

修完後在試算表新增一個分頁，記下日期、修了什麼、誰修的。下一季稽核時，先看上一季的紀錄，確認同樣的問題沒有復發。這份紀錄也是換主機、換外包時最重要的交接文件之一，可對照網站搬家三十天的風險清單。

稽核時最常見的三個誤判

第一個誤判，是只看首頁。首頁通常最穩定，問題多半藏在分類頁、標籤頁、舊文章與商品頁。稽核一定要用清單逐條抓，不能靠隨手點。

第二個誤判，是把瀏覽器看到的畫面當成回應碼。有些網站的錯誤頁做得很漂亮，有搜尋框、有推薦商品，看起來像正常頁面，回應碼卻是錯誤；也有反過來的情況，畫面寫著找不到，回應碼卻是正常。只有工具抓出來的代碼才算數。

第三個誤判，是修完不重抓。轉址規則改了，快取沒清，抓到的還是舊結果；或是外掛設定被另一個外掛覆蓋。每一批修正後都要重抓一次，把結果貼回試算表，才能算這一項完成。

示範情境：一次季度稽核找到的問題

以下是示範情境。一家賣辦公家具的中小企業，網站約四百條網址。季度稽核時，高價值網址全部正常，但歷史轉址表裡有一批兩年前的舊分類網址，先轉到去年的分類頁，再轉到今年的新分類頁，形成轉址鏈。另外有十幾篇舊文章，內文還連著已下架的商品頁。

處理順序是先改轉址規則，讓舊分類直接到新分類。接著逐篇改文章內連結。整個過程沒有動到網站外觀，也沒有新增頁面，只是讓每條路都走最短的那一條。

適用與不適用的情況

適用：網址數在數千條以內、使用常見架站系統、一年內有改版或搬家紀錄的企業網站與電商網站。這類網站最容易累積轉址與錯誤頁。

不適用：只有幾頁的形象網站，人工點一遍即可，不需要整套清單。大型電商或內容平台則需要搭配伺服器日誌分析，本文的免費工具組合不夠。

限制：回應碼正常不代表頁面會被索引，內容品質、重複內容、標準網址設定都會影響結果。若需要協助規劃稽核或交接，可參考服務項目與常見問題。寫內容時也請回到以使用者為優先的內容原則。