📍 WDQWDWQD987AAAAA:216.73.216.73
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9543837357c1.html
📄

优化型网站搭建网站迁移应准备哪些记录

网站迁移前应准备四类记录：资产与版本、URL与重定向、SEO与流量基线、环境与回滚。缺任何一类，迁移后就无法判断“是迁移出错还是本来如此”，也无法在出问题时快速恢复。第一次接触这个问题，起点是先把现有站点状态记录下来，再决定迁移方式和时间窗口。

先分清迁移类型，再决定记录深度

迁移不只是换服务器，还包括换域名、换CMS、改URL结构、改协议或换主机。不同类型要记录的侧重点不同：

• 换主机、URL不变：重点是环境配置、DNS、证书、回滚方案，SEO记录用于事后对比。
• 换域名：必须记录全量URL映射和301规则，并保留旧域名解析一段时间。
• 改URL结构：需要完整的旧URL清单和一一对应的新地址，逐条验证跳转。
• 换CMS或框架：记录模板、字段、结构化数据、分页与参数规则，确认新系统能输出等价页面。

代价上，记录越细，迁移准备时间越长，但故障定位时间越短。只做主机迁移且URL不变时，可以适当精简SEO清单；一旦涉及域名或路径变化，URL与重定向记录就不能省。

必须落盘的记录清单

建议在迁移前一周内完成以下记录，并保存在迁移团队都能访问的位置：

1. 资产与版本：程序版本、数据库版本、主题与插件清单及版本号、自定义代码位置。目的是迁移后能核对是否漏装或版本不一致。
2. URL清单：从XML站点地图、服务器日志和后台导出三处交叉获取，合并去重。记录每个URL的状态码、是否有流量、是否被外链引用。
3. 重定向映射表：旧URL到新URL的一对一表格，标注哪些是301、哪些是410。不要只写“全部跳首页”。
4. SEO基线：迁移前记录主要页面的标题、描述、canonical、robots指令、结构化数据类型、内链数量。这是事后对比的参照。
5. 流量与收录基线：记录各页面近30天的自然搜索点击、展示、主要落地页和索引状态。数据来源可以是搜索平台后台或分析工具，按自己能拿到的口径记录。
6. 环境与配置：DNS记录、SSL证书类型与到期时间、服务器重写规则、CDN缓存规则、邮件相关解析。
7. 回滚方案：旧环境的保留期限、数据库备份位置、切回DNS的操作步骤和预计生效时间。

记录做完后如何验证

记录不是写完就结束，迁移前应先在测试环境验证一遍。可执行步骤：

1. 在测试环境导入数据库和文件，用 hosts 或本地解析把测试域名指向新环境。
2. 随机抽取20个URL，检查状态码、标题、canonical是否与基线一致。
3. 用 curl -I 检查重定向链，确认没有多跳或跳错目标。
4. 检查 <link rel="canonical"> 和 <meta name="robots"> 是否被测试环境配置误改。
5. 确认站点地图可访问且URL数量与清单一致。

判断结果：如果测试环境与基线一致，说明记录可用；如果出现大量404或canonical指向测试域名，说明配置未清理干净，此时不应正式切换。

迁移当天的检查项

切换后按顺序核对：DNS是否生效、证书是否有效、首页与关键落地页是否返回200、旧URL是否按映射表跳转、站点地图是否更新、robots.txt是否误封。发现问题时优先判断是解析未生效、缓存未刷新还是规则写错，不要同时改动多项配置。若30分钟内无法定位，按回滚方案切回旧环境，保留现场日志再排查。

下一步：把上面的清单整理成一张迁移检查表，逐项标注负责人和完成状态，再确定切换时间窗口。