站点換域名、把 /product/ 改成 /p/、把带參數的動態地址改成静態路径，這些動作在開發侧可能几天就完成了，但對搜尋引擎来说，看到的是成千上萬個舊地址突然失效、一批新地址凭空出現。收錄能不能顺利迁移，主要取决于一件事：新舊 URL 的對應關系是否清晰、稳定、可長期维持。

先把映射表做出来，再動线上

很多迁移事故的根源是邊改邊想。比較稳妥的做法是先導出一份舊 URL 清單（sitemap、服務器日誌、索引报告里都能拿到），然後逐條标注處理方式：

• 保留：URL 不變，只是内容更新。
• 迁移：内容搬到新地址，舊地址 301 到新地址。
• 合並：多個舊地址内容相似，统一指向一個新地址，形成多對一。
• 下线：确實不再提供，返回 410 或 404，不要硬跳到首頁。

映射表的價值在于它能在上线前被检查：有没有同一個新地址被几十個舊地址指向、有没有舊地址跳到了完全不相關的頁面、有没有新地址在表里出現两次但對應内容不同。

跳轉怎么设：301 是預設答案，但要用對

永久迁移用 301，临时調整用 302 或 307，這一点没有争议。真正容易出問题的是跳轉的形態：

• 避免鏈式跳轉：舊地址 A 跳到 B，B 又跳到 C，蜘蛛要多走一步，信号也被稀释。映射表里應直接寫成 A 到 C。
• 不要全站跳首頁：把失效的深层頁面统一 301 到首頁，對用戶和搜尋引擎都等于「這個頁面没了」，還可能被当成软 404 處理。
• 跳轉目标要相關：商品下架就跳到同類目列表，而不是全站首頁，用戶和蜘蛛都更容易理解。
• 跨域要確認解析與證书：HTTPS 證书、DNS、CDN 配置没到位时跳轉可能中断，蜘蛛抓到的是错誤頁而不是 301。

站内信号要一起改

跳轉只是兜底，真正决定新 URL 能不能被顺利接管的，是站内還有多少地方指向舊地址：

• 全站内鏈和導航，尤其是硬编碼在模板里的绝對地址。
• sitemap 要換成新地址，並在迁移後重新提交。
• canonical、hreflang、og:url 以及结构化資料里的 URL。
• RSS、站内搜尋、分頁组件、面包屑、分享按钮带的連結。

如果這些還停留在舊地址，就會出現「新 URL 已经在跳轉鏈條末端，站内所有入口却還指向舊 URL」的局面，新地址很难积累到足够的抓取和点击。

容易漏掉的几類地址

下面這些往往不在 sitemap 里，但确實會被訪問，迁移时最容易被忘：

1. 图片、PDF、附件的直鏈，常被外部頁面引用。
2. CSS、JS 里寫死的资源或接口路径。
3. 结构化資料、站点驗證文件、广告落地頁里的 URL。
4. App 深鏈、QR Code、邮件模板、线下物料上的短鏈。
5. 外部網站上的舊連結，這部分你控制不了，只能靠 301 兜住。

分批迁移還是整体切換

整体切換的優点是映射關系简單，缺点是一旦出错影响面大。分批迁移（比如按目錄或按語言站点切分）可以在小范围内驗證跳轉、日誌和收錄反應，再逐步推廣。無论選哪種，都建议保留舊域名或舊路径的可訪問狀態至少几個月，並且不要在同一時間做跳轉、大改版和内容重寫三件事。

迁移之後看什么

迁移完成不等于結束，接下来几周要盯的是過程指标而不是结果指标：

• 日誌里新 URL 的抓取量是否逐步上升，舊 URL 是否逐步下降。
• 跳轉是否稳定返回 301，有没有出現 5xx 或超时。
• 索引报告里新 URL 的數量變化，以及舊 URL 是否在减少。

如果舊 URL 的抓取量一直不降、新 URL 迟迟没有抓取，通常說明站内入口或外鏈還没跟上，而不是搜尋引擎没發現這些地址。

收錄迁移的本质不是把舊地址改掉，而是让新地址在連結、sitemap、日誌三個层面都被稳定地看见。