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

衢州网站开发：网站迁移应准备哪些记录？一份可核对的证据清单

网站迁移前应准备的记录，核心是能证明“迁移前是什么状态、迁移中改了什么、迁移后是否一致”的三类材料：原站完整备份、域名与解析信息、页面与流量基线、服务器与数据库配置、301跳转规则、迁移操作日志、迁移后验证结果。缺少其中任何一项，出问题时都很难判断是数据丢失、配置错误还是外部因素，定位周期会被拉长。

先看一个假设例子：迁移后排名掉了，怎么查

假设某企业把站点从旧主机迁到新主机，两周后发现部分栏目页从搜索结果中消失。此时如果没有记录，只能猜测；如果有记录，排查路径会清晰很多。

1. 对比迁移前后的URL清单，确认消失的页面是否改了路径。若改了路径却未做301，属于跳转缺失。
2. 检查迁移前的抓取与索引基线记录，确认这些页面原本是否已被收录。原本未收录，就不是迁移造成的。
3. 核对服务器返回状态码记录，看是否出现大量404或500。状态码异常会直接影响抓取。
4. 对比robots.txt与meta robots的历史版本，确认是否误加了屏蔽规则。
5. 检查域名解析记录，确认是否同时存在新旧两套解析导致访问不稳定。

常见错误是只备份了数据库，没备份上传目录和配置文件；或者只记了“迁移完成”，没记具体时间点，导致日志无法与流量变化对齐。

迁移前必须固定的基线记录

基线的作用是给迁移后的对比提供参照。建议在动手前完成以下记录，并标注采集时间：

• 完整文件与数据库备份：记录备份时间、存放位置、校验方式（如文件大小、校验值），并确认备份可还原。
• URL清单：导出主要页面地址，至少覆盖栏目页、详情页、重要落地页。
• 收录与流量基线：通过搜索资源平台和统计工具记录当时的收录量、主要入口页面访问量。这是判断迁移影响的参照，不是排名保证。
• 域名与解析信息：记录域名注册商、DNS服务商、当前解析记录、TTL值、证书到期时间。
• 服务器环境：记录程序版本、数据库版本、PHP或其他运行环境版本、伪静态规则。

迁移过程中要留的操作记录

迁移不是一步完成的，中间动作要能追溯。建议记录：

• 每一步操作的时间点与执行人，便于和日志、流量曲线对齐。
• 新旧服务器的IP、路径、数据库连接方式的变化。
• 301跳转规则表：旧地址对应新地址，逐条列出，而不是只写“已配置跳转”。
• robots.txt、sitemap、canonical标签的修改前后内容。
• DNS切换的具体时间与TTL设置，因为解析生效存在延迟。

如果使用内容管理系统，迁移后要确认固定链接结构是否与原来一致。结构变化时，跳转规则必须覆盖旧结构，否则会出现大量死链。

迁移后的验证记录与判断标准

验证不是看一眼首页能打开就结束。可按下面几项逐条检查并记录结果：

1. 随机抽取若干旧地址访问，确认返回200或正确的301，而不是404。
2. 检查页面源代码中的canonical地址是否指向正确域名。
3. 确认robots.txt未误屏蔽整站，sitemap地址可正常访问。
4. 对比迁移前后的URL清单，确认没有遗漏页面。
5. 观察服务器日志中的状态码分布，异常比例升高时继续排查。

判断结果时要区分“可能原因”和“已定位原因”。例如流量下降可能来自迁移、季节波动或搜索需求变化，只有在记录能对应上具体时间点和具体改动时，才能把原因落到迁移动作上。

适用条件与记录粒度

站点规模小、页面少时，URL清单可以手工整理；页面数量多时，应借助爬虫工具或日志导出。若迁移只换服务器、不改域名和路径，跳转记录可以简化，但备份、环境记录和验证步骤不能省。若同时更换域名或改版，记录要求会明显提高，因为变量增多，定位难度也随之上升。

下一步可以做的，是把上述清单整理成一张迁移检查表，在迁移前逐项打勾，迁移后逐项复核，并把每次结果留存到同一个目录，方便后续对比。