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

网站建设与优化_网站迁移应准备哪些记录：一份可执行清单

网站迁移前最该准备的是一份能对照核验的记录清单，而不是只备份数据库和文件。记录要覆盖迁移前的现状、迁移中的操作、迁移后的验证三部分，每一项都写清查什么、怎么查、结果说明什么。迁移完成后，只要拿这份清单逐条核对，就能判断迁移是否完整、是否引入了新问题。

迁移前：先记录现状，才有对照基准

迁移最容易出的问题不是“搬不过去”，而是搬完之后发现少了东西却不知道少了什么。所以第一步是把当前状态记录下来。

• URL 清单：查什么——站点所有可访问页面的地址。怎么查——从 XML 站点地图、导航菜单、内链抓取工具三处取并集。结果说明什么——这份清单是迁移后做 301 跳转和核对收录的底稿，数量对不上就说明有页面被漏掉。
• 页面标题与描述：查什么——每个重要页面的 <title> 和 meta description。怎么查——导出为表格。结果说明什么——迁移后逐条比对，标题被模板覆盖或截断时能立刻发现。
• 收录与流量基线：查什么——迁移前一段时间的收录页数、主要入口页的自然流量。怎么查——搜索资源平台的索引报告与统计工具。结果说明什么——迁移后流量波动时，有基线才能判断是迁移导致还是正常起伏。
• 服务器与解析信息：查什么——当前 IP、DNS 记录、证书签发信息、伪静态规则。怎么查——在服务器面板和域名解析后台导出。结果说明什么——新环境配置不一致时，可据此逐项复现。

迁移中：记录每一次改动，而不是只记结果

迁移过程本身要留痕，否则出问题时无法回溯是哪一步引入的。

1. 操作时间线：记录切换 DNS、上传文件、导入数据库、修改配置的具体时间点。判断依据是，出现异常时能对应到某个操作，而不是笼统地“迁移后就这样了”。
2. 跳转规则表：记录旧地址到新地址的映射关系，包括带参数、带斜杠、大小写不同的变体。检查项是随机抽 20 条旧地址访问，看是否都跳到对应新页而非首页。
3. 数据库与文件版本：记录导出时间、文件大小、字符集。适用条件是迁移周期超过一天时尤其必要，否则容易把旧数据覆盖到新数据上。
4. 配置差异对照：把新旧环境的 PHP 版本、伪静态规则、目录权限列成两列。结果说明什么——页面 404 或 500 报错时，先看差异列而不是盲目重装。

迁移后：按清单验证，而不是凭感觉

验证要分“能访问”和“能被找到”两层，前者是技术问题，后者是优化问题。

• 可访问性抽查：查首页、栏目页、详情页、表单页各若干。判断结果是返回 200 且内容正确；若返回 301 到首页，说明跳转规则写错。
• 跳转链路检查：旧地址应一次跳到新地址，不应出现 A→B→C 的多级跳转。多级跳转会让抓取效率下降，属于需要修正的记录项。
• 站点地图与 robots 文件：确认新站点地图只包含新地址，robots 没有误屏蔽整站。结果说明什么——若屏蔽了，收录会长时间不恢复，这是迁移后最常见的自伤操作。
• 内链检查：抽查正文内链是否仍指向旧域名。适用条件是内容量大的站点，手工查不完时可用抓取工具筛出含旧域名的链接。
• 证书与混合内容：确认 HTTPS 证书覆盖新域名，页面内没有残留的 HTTP 资源。判断结果是浏览器地址栏无警告、控制台无混合内容报错。

记录该保留多久，以及怎么用

这份清单建议至少保留到迁移后完成一轮完整的收录与流量对比。使用方式是：每周对照基线记录一次收录页数和主要入口流量，连续观察数周。若收录持续下降且跳转、屏蔽均无问题，再排查内容是否被大幅改动。需要区分的是，收录变化属于搜索引擎侧的表现，不能仅凭单日数据断定迁移失败；而 404、跳转错误属于已定位的技术问题，应当立即修复。记录的价值在于把“可能原因”和“已经确认的原因”分开，避免在无关方向上反复调整。

下一步：把上面三类记录整理成一张表格，迁移前填现状列，迁移中填操作列，迁移后填验证列，每完成一项就打钩。表格填满且验证项全部通过，才算迁移收尾。