curl -sS -D - -o /dev/null "$OLD_URL"

跟随跳转，查看沿途响应头

curl -sS -L -D - -o /dev/null "$OLD_URL"

输出最终状态与最终地址，便于登记结果

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

验收记录应同时保存首次响应、目标地址、最终响应及页面内容。永久搬迁的规则类型，应由技术负责人按实际部署环境确认，不能只用浏览器“似乎跳过去了”作结论。

把不必要的连续跳转、跳回旧地址、跳到测试域名、目标页面不存在等情况列为上线阻断项。特别注意不要只检查首页规则，而漏掉文章和产品详情页。

## 五、页面内容与 canonical 如何一起验收？

地址能够打开，只是最低要求。建议从每种页面模板抽取代表页，核对标题、主标题、正文、图片替代文本、内部链接和咨询按钮是否完整，避免导入后只剩页面壳。

canonical 可作为规范地址检查项，但不要把它当作处理所有迁移问题的替代方案。验收时记录页面声明的规范地址，并确认它与项目确定的正式页面一致；尤其排查仍指向旧域名、预览域名或不相关页面的情况。

多语言网站应额外核对语言版本之间的对应关系。中文版产品页不应因为批量替换而链接到英文首页；语言切换、页脚链接与正文推荐链接都要实际点击测试。

同时比较迁移前后的核心信息。价格条件、服务范围、案例依据与联系方式不能在模板替换时被无意删掉。对于销售依赖的页面，建议让业务负责人参与验收，而不只由开发检查技术响应。

## 六、站点地图检查什么？先与正式页面名单对账

建议先整理“计划公开并供搜索发现的正式页面名单”，再与生成的站点地图对照。不要把“已经生成一个 XML 文件”当成检查完成。

重点检查以下事项：

- 地图中的地址是否属于正式域名和正式环境。
- 迁移后的新路径是否已按计划列入。
- 已删除、仍在跳转或尚未准备公开的地址是否混入。
- 地图列出的页面，是否与页面声明的规范地址一致。
- 多语言目录、文章分页或产品分类是否存在整类遗漏。
- 更新地图和重新发布的责任人是否明确。

地图条目数量变化时，应追问变化来自哪里：是内容有计划地合并，还是导入遗漏、筛选条件错误？建议保存迁移前后的文件副本，以便逐项比较。

站点地图只是迁移验收的一部分。提交操作完成后，仍要检查具体页面的访问、内容和后续状态，不能据此承诺收录、排名或流量结果。

## 七、Search Console 上线前后分别查什么？

![七、Search Console 上线前后分别查什么？](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)


上线前，先确认团队能访问相关站点资源，负责人员的权限不会随旧供应商退出而丢失。记录迁移前的重要落地页、查询词、点击和展示表现，并保存观察日期，作为后续比较的起点。

上线后，建议按以下顺序检查和登记：

1. **资源与权限**：当前查看的是否为本次迁移涉及的站点，责任人是否仍有访问权限。
2. **代表性网址**：检查关键页面的抓取、索引状态及规范地址信息，区分历史记录与后续变化。
3. **站点地图**：核对提交对象、处理状态及相关提示，遇到异常再回到实际文件排查。
4. **页面问题**：按目录和模板整理异常，不要只盯着总量。
5. **效果表现**：结合旧页面与对应新页面比较查询、点击和展示，不只比较首页。

如果同时更换域名，应另行确认地址变更相关流程是否适用于自己的迁移情形，不要把同域更换建站工具与跨域迁移混为一谈。

发现问题时，把页面地址、看到的提示、观察时间和复测结果放进同一张工单。不要仅凭某一次截图就删除页面或反复修改规则。

## 八、上线当天如何安排验收与回退？

建议把上线划分为准备、切换、复测和观察阶段。准备阶段冻结重要内容变更，备份页面数据与配置，确认旧站的必要访问能力仍可保留。

切换后先测试关键业务链路：旧入口进入、产品说明阅读、表单提交、通知接收、销售跟进。SEO 检查与线索检查应同步进行，避免页面可访问但咨询无人收到。

上线阻断条件应提前约定，例如关键产品页无法访问、大批旧入口没有预定去向、正式页面仍受测试环境限制，或咨询流程失效。出现这些情况时，由负责人决定修复还是回退，而不是边上线边争论标准。

回退也应有操作说明：谁能执行、需要恢复哪些配置、如何确认恢复成功。不要在迁移当天才发现旧站已经删除，或原供应商账户权限已经失效。

## 九、迁移后表现变化，怎样排查才不乱？

建议先排查可重复出现的技术和内容问题，再讨论更广泛的搜索表现。顺序可以是：页面能否访问、旧入口去向是否正确、内容是否完整、内部链接是否更新，以及站点地图与页面声明是否一致。

比较数据时，应把同一业务页面的旧地址与新地址放在一起看。如果只看新地址的历史记录，容易忽略迁移前的数据；如果只看全站总量，又可能掩盖一个重要目录的损失。

还应记录同期的广告变化、内容删改、季节性活动和统计配置调整，避免把所有变化都归因于更换平台。建议每轮只修复一组明确问题，并登记复测结果，减少多个改动叠加后无法判断原因的情况。

没有统一适用于所有网站的恢复期限。迁移验收可以设定内部复查节奏，但不宜把这个节奏包装成搜索引擎的处理承诺。

## 十、选择 AI 建站平台时，要怎样问迁移能力？

生成页面和承接旧站是两项不同的验收工作。[we0 官网](https://we0.ai/zh)介绍了自然语言描述需求、多 Agent 搭建、可视化调整与域名部署流程。企业可以据此评估建站方式，但仍应单独要求演示旧路径保留、跳转配置及迁移后的测试方法，不能直接推定这些事项会自动完成。

作为另一类产品参考，[Readdy 官网](https://readdy.ai/zh)介绍了代码导出、域名托管以及 SEO、GEO 相关工具。采购时应进一步询问：导出后由谁维护部署配置，路径规则由谁管理，异常由谁排查。功能名称不能代替项目责任书。

[阿里云开发者社区的万小智介绍文章](https://developer.aliyun.com/article/1773673)涉及对话式建站与部署流程，但页面注明内容由用户贡献。它适合帮助团队理解建站场景，不宜被当作厂商对本项目迁移交付范围的承诺。

建议让候选平台或实施方拿一小组真实旧页面做演示，再决定采购和上线计划。演示应覆盖不同模板与异常情况，而不只是生成一个新首页。

## FAQ

### 不换域名，只换建站平台，也需要迁移清单吗？

需要。建议核对路径、正文、页面声明、内部链接和咨询流程是否保持一致。域名未变，并不意味着所有部署结果都会自动符合原方案。

### 能不能把全部旧页面都导向首页？

不建议将它作为默认方案。应先判断每个旧页面是否有相关的新页面承接；没有替代内容时，也要明确记录处理方式，而不是用首页掩盖缺失。

### 提交站点地图后就算迁移完成了吗？

不算。还应完成旧入口测试、关键页面检查和业务链路验收，并持续记录 Search Console 中的状态变化。提交动作不能替代实际访问测试。

## Related Tools

- **URL 对照表**：管理旧路径、新路径、处理方式与负责人。
- **curl**：查看响应头、跳转过程和最终地址。
- **Google Search Console**：整理站点相关状态与搜索表现检查记录。
- **浏览器开发者工具**：复测页面加载、链接与表单请求。

## Related Links

- [we0：建站、页面调整与部署流程](https://we0.ai/zh)
- [Readdy：建站、代码导出与运营工具介绍](https://readdy.ai/zh)
- [阿里云开发者社区：万小智 AI 建站场景介绍](https://developer.aliyun.com/article/1773673)

## Summary

更换建站平台的验收对象，不只是新网站，而是旧入口到新内容、再到咨询动作的完整路径。先建立 URL 对照表，再测试跳转、页面内容、站点地图和业务链路，最后结合 Search Console 持续排查。平台能力应通过真实页面演示确认，迁移责任与回退条件则应在上线前写清楚。