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

第一輪只確認事實

檢查下降發生在哪一天，是否與網站發佈、域名變更、統計腳本更新或假期重合。對比 Search Console 的搜索點擊和站內訪問數據。若只有站內統計下降，先確認採集是否正常，而不是馬上認定搜索排名出問題。

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

將下降拆成可定位的範圍

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

核對更新，但不自動歸因

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

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

給行動設置風險邊界

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

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

與服務團隊溝通的材料

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

排查清單

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