網站改版、換域名、調整目錄结构，這些動作在业務上很常见，但對搜尋引擎来说，是一次大規模的地址變動。如果處理得草率，原本能正常抓取的頁面會變成 404，已经积累的内鏈會指向失效地址，蜘蛛再来时看到的是一片断头路。下面按迁移的時間顺序，整理一份可执行的自查思路。

一、迁移前：先把現有地址盘清楚

迁移最容易出問题的环节，是没搞清楚自己到底有哪些頁面。凭印象整理必然遗漏，尤其是运营多年、栏目反复調整過的站点。

從日誌和 sitemap 取並集

把服務器訪問日誌中近期被請求過的地址導出来，去掉静態资源、參數頁和明顯的垃圾請求，得到一個真實被抓取過的地址列表。同时把現有 sitemap 里的地址也導出来。两份清單取並集，才是需要逐條處理的资产，而不是只盯着 sitemap。

给每個地址定去向

建议把舊地址分成三類，逐條标注：

• 保留：新版仍有對應内容，地址尽量不動，或做 301 到新地址。
• 合並：多個舊頁面並入一個新頁面，選一個主目标做 301，其余同向跳轉。
• 废弃：内容确實不再提供，返回 410 或 404，不要全部硬跳首頁。

把所有舊地址统一 301 到首頁，是最常见的偷懒做法。它會让蜘蛛在每個舊地址上都被送到同一個頁面，既浪費抓取，也让跳轉失去语义。

二、映射表：迁移的核心文档

舊地址與新地址的對應關系，應该落在一張表里，而不是散落在開發同学手改的配置中。這張表至少包含舊 URL、新 URL、跳轉類型、负责人、上线狀態。

• 跳轉類型统一用 301，除非是临时活動頁；302 传递不出地址變更的信号。
• 跳轉目标必须是最终地址，避免 A 跳 B、B 再跳 C 的鏈式跳轉。
• 表里的每一行都要在測試环境實际驗證一次，確認狀態碼和目标地址都正确。

三、切換时：顺序比速度重要

切換当天最忌讳的是一次性全改完再看效果。建议按下面的顺序推進，每一步留出观察時間。

1. 先在新环境完成内容、结构、跳轉配置的部署，用临时域名或 hosts 驗證。
2. 確認新站可正常訪問後，再開啟跳轉規則，並让舊站保留一段時間可讀，便于比對。
3. 更新 sitemap，只保留迁移後的有效地址，刪除已废弃的老地址。
4. 检查站内連結、導航、面包屑里是否還有指向舊地址的硬编碼。
5. 如果涉及域名變更，同时更新 robots.txt 中的 sitemap 地址和頁面上的 canonical。

跳轉規則上线後，不要立刻删掉舊站内容。保留一段時間，方便對照日誌確認蜘蛛确實按 301 走了新地址。

四、迁移後：用日誌驗證，而不是凭感觉

迁移完成後的一到两周，重点看三件事。

看舊地址的响應

抽样請求一批舊 URL，確認返回 301 且 Location 指向正确，没有 302、没有跳回自身、没有跳到 404 頁面。批量检查可以用脚本跑，逐條记錄狀態碼。

看新地址的抓取

日誌里新地址的請求量應该逐步上升，舊地址的請求量逐步下降。如果舊地址仍被大量抓取却没有跳轉，說明映射表有遗漏，或者規則没有真正生效。

看内鏈是否干净

站内連結如果還指着舊地址，蜘蛛會顺着這些連結重新走一遍跳轉鏈，等于把迁移的工作量翻倍。用抓取工具跑一遍站内連結，把残留的舊地址替換掉。

五、容易遗漏的几個点

• 頁面的 canonical、社交分享用的 URL 等元信息還寫着舊域名。
• 图片、CSS、JS 等资源仍從舊域名加载。
• 移動版或其他渲染版本的地址没有同步迁移。
• 第三方後台、投放落地頁里配置的連結未更新。
• sitemap 里混着新舊两套地址，互相矛盾。

迁移不是一次性動作，而是一段需要持續观察的過程。把地址盘点、映射表、切換顺序和事後驗證這几件事做實，能减少很多改完之後流量慢慢下滑、却找不到原因的情况。