站点运营到一定阶段，總會遇到需要把内容拿下来的情况：過期的活動頁、寫错方向的舊文、合並掉的栏目、下架的产品。刪除本身不难，难的是删完之後不留尾巴。很多站点的問题不是内容少，而是删過的地址在連結、地图、導航里還残留着，蜘蛛顺着爬過去撞到一堆狀態不一的响應，站点结构的清晰度就是這样一点点被磨掉的。
先判断：刪除、合並還是保留
拿到一條要下线的内容，先別急着点刪除，按下面三類過一遍，處理方式完全不同。
- 彻底刪除：内容本身没有價值，也没有替代頁面。比如临时公告、重复的活動頁、誤發的測試稿。
- 合並：内容主题還在，只是並進了另一篇更完整的文章。這时舊地址應当指向新的目标頁，而不是简單消失。
- 保留但降級：内容仍有人查，只是不再更新。可以留在站内，但從導航和列表頁里撤下来，让它靠搜尋和長尾自然触達。
三類混在一起處理，是最常见的問题来源。把该合並的直接删掉，等于自己砍断了一條老連結；把该删的留在列表頁，則會让栏目頁一直挂着没人维護的入口。
刪除之後返回什么狀態碼
内容真的不保留了，服務器回應要明确。這里有两個常见選項：
- 410 Gone：明确告诉對方這個地址不會再回来。适合已经确定放弃、不會复活的内容。
- 404 Not Found：通用做法，兼容性好。如果只是暂时拿不准，用 404 也没有問题。
需要避開的是另一種操作：把一批删掉的頁面统一 301 跳轉到首頁。表面上訪問者不會遇到错誤頁，實际上是把一堆不相關的内容信号全挤到首頁上，首頁的定位反而變模糊。
刪除頁面的處理，重点不是"別让用戶看到 404"，而是让這個地址的去向和它原本的内容有合理的對應關系。没有合理的對應，就不要硬接。
還有一種情况是批量下架。如果涉及几百條地址，建议先整理成清單，按批處理，別指望一次性跳轉全搞定。
清掉指向它的残留引用
頁面删了，指向它的痕迹往往還在。這些痕迹不清理，蜘蛛還是會一圈圈爬進来。
站内連結與導航
用站内搜尋或爬取工具把指向舊地址的内鏈找出来。重点看導航栏、侧邊推荐、相關阅讀、文章正文里的手動連結。栏目頁和标簽頁里如果還挂着入口，也要一起下线。
Sitemap 與 RSS
Sitemap 通常是自動生成的，但自動生成的前提是資料源里已经剔除了舊地址。如果内容只是從頁面上撤下、資料库狀態没改，地图文件里可能還留着它。RSS 同理，已经刪除的文章不應该繼續出現在订阅源里。
Canonical 與结构化資料
做頁面合並时，新頁面上的 canonical 要指向自己，而不是繼續指向舊的、已经删掉的地址。结构化資料里的 URL 字段也容易忘记同步，這類不一致不一定會立刻出問题，但排查时會很难找。
归档頁別做成空壳
有些站点會保留一個"往期内容"栏目，把舊文章都塞進去。保留入口本身没問题，但頁面上最好说清楚這是什么、為什么不再更新、有没有更相關的新内容可以看。一個只有标题列表、没有任何說明、也点不進正文的頁面，對訪問者和蜘蛛都讀不出信息。
如果归档内容确實没有繼續保留的價值，直接下线比堆在角落更干净。
一個可以照着走的下线流程
- 確認這條内容属于刪除、合並還是保留降級。
- 决定目标狀態：410、404，或 301 到明确對應的新頁面。
- 如果合並，先把新頁面寫好，確認内容能承接舊頁面的主题，再做跳轉。
- 撤下導航、列表、相關阅讀里的入口，检查正文内鏈。
- 確認 Sitemap、RSS、结构化資料里的舊地址已剔除或更新。
- 观察一段時間訪問日誌，看這個地址還有没有持續的訪問請求，以及請求来源是哪。
内容下线看起来是收尾動作，實际對站点结构的整洁度影响不小。把每條下线内容都当作一次小型的结构维護，删得清楚、跳得合理、清得彻底，站内地址的质量才會随着時間往前走，而不是越积越乱。