网站建设案例网站迁移应准备哪些记录：先分清整站切换与分批搬迁
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /303b8eda77c5.html
📄
网站建设案例网站迁移应准备哪些记录：先分清整站切换与分批搬迁
网站迁移要准备的记录，核心是能证明“旧站原来是什么样、新站现在是什么样、两者差异如何处理”。至少应保存旧站页面清单、URL与状态码、页面标题与正文样本、重定向映射表、DNS与服务器配置、数据库和文件备份、迁移前后抓取结果。缺少这些记录，迁移后一旦出现流量或收录波动，就无法判断是技术故障、内容缺失还是正常重新评估。
先观察：迁移前必须留档的六类记录
观察阶段的目标是建立可对比的基线。建议在动手前完成以下记录，并统一存放到一个带日期的文件夹中：
- URL清单：从旧站地图、服务器日志或抓取工具导出全部可访问地址，标注栏目、层级和是否返回200。
- 状态码记录：对旧站主要URL逐个记录HTTP状态，区分正常页、404、301、302，避免把已失效页误当成有效页迁移。
- 内容样本：每个栏目抽取若干页面，保存标题、描述、正文首段和图片地址，用于迁移后核对是否丢失。
- 重定向映射表：一行对应一条旧URL到新URL的对应关系，注明是301永久跳转还是保留原路径。
- 服务器与DNS配置：记录域名解析记录、证书类型、服务器软件版本和伪静态规则，便于回滚。
- 备份文件：数据库导出文件、网站根目录压缩包、配置文件，分别记录生成时间和校验值。
这些记录不是形式主义。迁移后如果某个栏目页面大量404，有URL清单和映射表就能快速定位是漏配跳转，而不是重新猜测旧站结构。
判断：整站切换与分批搬迁各需要什么额外记录
两种处理方案的适用条件不同，记录重点也不同。
整站切换适合旧站结构清晰、页面数量可控、新站已完整验证的情况。除上述六类记录外，还要额外准备：切换时间点、DNS生效等待时间、旧服务器保留期限、切换后首轮抓取结果。判断是否适合整站切换，可以看旧站是否仍有大量未迁移的独立页面；如果超过两成页面没有明确新地址，整站切换风险偏高。
分批搬迁适合栏目多、页面量大或需要边迁移边验证的情况。额外记录包括：每批次涉及的URL范围、批次切换顺序、批与批之间的跳转关系、旧路径在新批次完成前的保留方式。判断依据是能否在不影响其他栏目的前提下独立验证一个批次；如果批次之间共享模板或数据库表，就不适合简单分批。
假设示例：某站点有“产品”和“文章”两个栏目，先迁移“文章”栏目并保留“产品”旧路径，此时映射表只需覆盖文章URL；若两个栏目共用同一套详情页模板，分批迁移可能导致模板冲突，应改为整站切换或先拆分模板。
处理：迁移执行时的记录动作
执行阶段要边操作边记录，而不是事后补。可按以下顺序进行：
- 冻结旧站内容变更，记录冻结时间；此后新增内容单独标记，避免迁移遗漏。
- 导入数据库和文件后，先在新环境用临时地址访问，核对页面数量与内容样本。
- 逐条配置重定向，配置完成后用工具抽查旧URL是否返回301并指向正确新地址。
- 切换DNS前，记录当前解析值；切换后记录生效时间，便于必要时回退。
- 提交新站地图，并保留旧站地图作为对照，不要立即删除旧站可访问内容。
技术配置中如果涉及页面模板修改，例如调整<h2>层级或规范链接，应先在测试环境记录修改前后的页面源码，再同步到正式环境。这样出现异常时可以比对是哪一步改动引入的。
复查：迁移后如何用记录判断是否正常
复查不是看一次首页能否打开，而是用迁移前记录逐项对比。检查项包括：
- 旧URL访问后是否到达内容对应的新页面，而不是统一跳首页；
- 新站主要页面状态码是否为200，是否存在跳转链过长；
- 标题、描述、正文样本与迁移前记录是否一致，是否有整段丢失；
- 地图中的URL是否都能访问，是否出现大量软404；
- 服务器日志中旧路径的访问是否被正确重定向，错误比例是否在可接受范围。
如果复查发现某类页面收录下降，先对照记录判断是“旧页已301到新页”还是“旧页直接404”。前者属于正常迁移过程，后者是配置遗漏，应优先修复。不同搜索引擎处理迁移的节奏不同，不能仅凭某一天的抓取量下结论，应结合多轮日志和抓取结果观察。
下一步：把上述记录整理成一张迁移检查表，按“迁移前基线、执行记录、复查结果”三列填写，每完成一项就标注时间和结果，再决定是继续整站切换还是退回分批处理。
