换建站系统最容易出问题的不是页面内容，是链接形式和 URL 写法同时变了。官方甚至建议准备新站时尽量沿用旧站的同一套系统，理由就摆在这句话里。下面这套核对表按"先保链接、再保 URL、最后保内容"的顺序走，每一步都有明确的验收点。
换系统真正会动的是这三样
换 CMS 影响外链的路径只有三条，别的都可以事后补。
- URL 的形态。大小写、末尾斜杠、目录层级、参数名、是否强制加前缀，任意一项变了就是一批新 URL。
- 链接的输出形式。同样是导航链接，旧系统可能直接输出
<a href>，新系统可能改成脚本点击或路由属性。 - 分页、筛选、标签这类页面的生成规则。规则一改，同一份内容会对应出数量级不同的 URL 集合。
上线前后的核对顺序
顺序本身就是重点，颠倒会让问题互相掩盖。
- 导出旧站对外暴露的 URL 全集。来源包括站点地图、服务器日志、分析工具，官方在带 URL 变更的站点迁移指南里给的路径也是这几条：看站点地图、看服务器日志或分析工具里访问量较高的地址、看 Search Console 的指向你站点的链接报告，再用内容管理系统导出一份内容 URL 列表。
- 生成新旧 URL 映射表。同一份文档把"从当前 URL 映射到对应新格式"列为迁移准备的标准动作，并建议把新 URL 清单和指向旧 URL 的站点链接清单两份都先存下来备用。
- 逐条验证链接形式。Google 关于链接写法的说明写明，Google 通常只能抓取带
href属性的a元素，其他形式的链接不会被解析提取；它还特别说明，如果用 JavaScript 插入锚文本，要用 URL 检查工具确认这些文本确实出现在渲染后的 HTML 里。这一条是换系统后最常被忽略的验收项：链接在浏览器里点得动，不代表它以可抓取的形式输出了。 - 检查 URL 结构本身是否合理。Google 的 URL 结构最佳实践要求 URL 遵循 IETF STD 66、用可读词而非长 ID、用连字符分隔词、尽量少带不改变内容的参数，并且明确 URL 是大小写敏感的——
/APPLE与/apple被当作两个各自有内容的不同 URL。该文档还警告，过度复杂的 URL 会制造大量指向相同或相似内容的 URL，可能导致抓取效率下降甚至内容无法被完整收录。分页与筛选页的 URL 规则要按这一条重排。 - 补齐规范标签。Google 关于指定规范 URL 的说明把重定向和
rel="canonical"都列为强信号、把写进站点地图列为弱信号，并建议在规范页自身也加一条自指的rel="canonical"、使用绝对路径、站内链接一律指向规范 URL 而不是重复 URL。多套参数版本的站点，这一步的收益最大。
一张可以逐行打勾的核对表
| 核对项 | 验收标准 | 不通过时改哪里 |
|---|---|---|
| URL 大小写与斜杠 | 旧 URL 请求后到达正确的同一页 | 服务器规则或新站路由 |
| 旧 URL 的跳转 | 目标是对应的新页，不是首页 | 映射表 |
| 链接输出形式 | 渲染后 HTML 里有 a href | 模板层，不是内容层 |
| 参数版本 | 同内容只留一个对外 URL | 规范标签加重定向 |
| 内链指向 | 全站内链都指向规范 URL | 内容与导航模板 |
| 站点地图 | 只提交规范 URL | 地图生成规则 |
最后两项容易被跳过，但它们决定了这套映射会不会在半年后失控。参数多的站点还要把产品目录分页怎么做 SEO里的分页判断一起用上，否则映射表会越滚越长。
换了系统也不用做的事
- 不用重做外链建设计划。换系统的产出如果只有技术侧问题，外链节奏不用动。真要调整的是投入的页面顺序，参考站内关于外链预算优先级的判定方法。
- 不用重新解释历史链接。新站上线后该做的是让旧链接能打到新址，而不是给每一个来源重发一遍说明。
怎么确认旧链接没被打断
上线后按固定间隔复核三次，两周一次，不要只在当天验一次。具体做法：抽 20 条旧站带来引荐访问最多的 URL，逐条请求并记录状态码与落地页面，看它们是否一跳到达、内容主题是否与原链接描述一致；再核对渲染后的 HTML 确认链接形式合格；最后把两次结果并排放进外链追踪表，同一批 URL 的状态从异常回到正常才算通过。若这批链接还没被抓到，顺序见站内外链发出去了却没被收录该按什么顺序查；换系统涉及账号与权限交接的部分，参照换 SEO 服务商前的交接清单。