站点跑得久了，連結失效几乎是必然的事：栏目調整、文章下线、产品停售、外部引用寫错地址，都會留下打不開的連結。這些地址不會自己消失，蜘蛛每次来訪都可能再撞一次，用戶從搜尋结果点進来也只會看到报错。把失效連結当成一項常規自查，比等到流量下滑再回头翻舊帳要省力得多。
為什么失效連結值得單獨查一遍
失效連結的影响不只是“不好看”，它會在几個地方持續消耗站点的效率：
- 蜘蛛把抓取预算花在打不開的地址上，真正有新内容的頁面反而排不上队；
- 用戶從搜尋、外鏈或收藏夹進来直接撞墙，很可能不會再给第二次机會；
- 内鏈指向死頁，原本應该传递下去的结构线索就断在了半路；
- 大量死鏈堆在日誌里，會干扰你判断哪些目錄真的被重视。
先把“找不到”分成几類
真 404：服務器明确说没有
請求返回 404 狀態碼，頁面内容也是“不存在”的提示。這是最干净的情况，處理起来没有歧义。
软 404：頁面回来了，但内容是空的
常见于空搜尋结果頁、已下架商品的詳情頁模板、無權限或參數错誤时仍然渲染出的框架頁。它們返回 200，看上去“正常”，但對用戶和蜘蛛来说都是空壳。软 404 比真 404 更麻烦，因為從狀態碼上看不出問题，只能靠内容层面的判断去發現。
410、301 與 302 的選擇
如果内容确實永久下线、且没有可替代的頁面，用 410 表達“永久移除”比 404 更明确；如果内容只是換了地址，用 301 指向新地址，並且尽量做到一對一，不要把几十個舊地址全部堆到首頁；302 是临时跳轉，不适合用来做長期的内容迁移，否則舊地址會一直留在索引里摇摆。
去哪里找失效連結
- 服務器日誌：筛出狀態碼為 404、410 以及频繁 301 的請求，按訪問次數排序，先處理被反复請求的那批；
- 站長平台類工具：索引报告和抓取異常里通常能看到被标记的無效地址，注意区分“已刪除”和“抓取失敗”；
- 站内爬取：用爬虫工具把整站跑一遍，能發現日誌里看不见的問题，比如内鏈里的死鏈、模板里批量生成的错誤地址；
- 人工走查：導航、面包屑、頁脚、专题聚合頁手工点一遍，重点看改版後没同步更新的入口；
- 外鏈與投放渠道：看看外部引用的地址是否還成立，尤其是合作方寫的舊版連結。
找到之後怎么處理
- 有對應新頁面：配置 301，跳到内容最接近的那一個，而不是统一跳首頁；
- 确實不再提供：明确返回 404 或 410，並保證頁面本身可用；
- 誤删或临时下线：優先恢复原文，比做跳轉更省事，也不會损失已有的外部引用；
- 内鏈里的死鏈：直接在模板或正文里改掉，避免以後每一頁都带着同一個坏連結；
- 站点地图與聚合頁：把已失效的 URL 從站点地图和列表頁中清理出去，別让它們繼續被推荐。
處理顺序上，建议先動被频繁請求、且有外部引用的地址，再處理只在站内偶尔出現的死鏈。批量跳轉要谨慎，一次改太多容易把本来正常的鏈路也带偏。
404 頁面本身也该做点什么
允许頁面不存在，但這張“此路不通”的牌子可以做得更有用：
- 用一句清楚的话說明頁面不存在或已下线，不要寫得含糊；
- 提供搜尋框、主要栏目入口和几條近期更新，让用戶有路可走；
- 返回碼必须是 404，不要用 200 伪装成正常頁面，也不要用 JS 跳轉把狀態盖掉；
- 不要自動跳首頁，那會让用戶以為点错了連結，也让狀態碼失去意义。
把它變成長期机制
失效連結不是一次性任務。每次改版、每次批量下线内容，都應该顺手跑一遍检查；把狀態碼異常加進日常监控，按周或按月看一眼趋势，比出了大問题再全站排查轻松得多。检查记錄留個简單台帳，寫清哪些地址做了跳轉、哪些是永久移除，下次遇到同样的問题就不用重新判断一遍。
死鏈本身不可怕，可怕的是没人知道它存在。定期把死胡同标出来、该通的通、该封的封，站点的路径才會一直清楚。