自然搜尋流量突然下降：先排故障，再判斷內容問題

第一輪只確認事實

檢查下降發生在哪一天，是否與網站釋出、域名變更、統計指令碼更新或假期重合。對比 Search Console 的搜尋點選和站內訪問資料。若只有站內統計下降，先確認採集是否正常，而不是馬上認定搜尋排名出問題。

用未登入狀態訪問首頁、分類、產品和詢盤頁面，檢查證書、狀態碼、跳轉和內容載入。伺服器故障或錯誤的 noindex 可能影響大量頁面，應優先處理。

將下降拆成可定位的範圍

總流量圖只能告訴你出現變化，不能說明原因。儲存受影響與未受影響的樣例，有助於排除不相關假設。

核對更新，但不自動歸因

可以檢視 Google 官方排名更新資訊與相關指導，記錄時間是否重合。時間重合只是線索，不是證明。若變化發生在一次錯誤部署後，不能因為同周有演算法訊息就忽略自己的技術問題。

對於內容與搜尋需求變化，先評估頁面能否更好回答採購問題。避免為了所謂“恢復權重”大批刪除仍有用的資料，或購買連結試圖快速逆轉趨勢。

給行動設定風險邊界

技術修復應保留前後證據並及時驗證；內容最佳化可以先選一組明確有問題的頁面。需要合併或刪除時，檢查原連結、資料價值與替代關係，制定對映，而不是全部跳轉首頁。

教學示例：某產品目錄因模板更新丟失正文，優先恢復模板；若頁面正常但需求季節性降低，則應比較更長時間與相近季節。兩種情況的行動完全不同。

與服務團隊溝通的材料

向雲典或內部 SEO 團隊提供變化日期、受影響地址、近期釋出記錄和可用資料範圍。月報應把“已證實原因”“待驗證假設”“執行動作”分開寫，避免把猜測包裝成確定結論。

排查清單

• 已確認統計指令碼、站點訪問與索引規則正常。
• 已按頁面、國家、裝置或查詢縮小範圍。
• 更新訊息僅作為線索，沒有自動歸因。
• 高風險內容改動有備份、依據和觀察計劃。