网站开发流程 - 网站迁移应准备哪些记录：从观察异常到复查的完整清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9200a2b2bd33.html
📄
网站开发流程 - 网站迁移应准备哪些记录：从观察异常到复查的完整清单
网站迁移前应准备的核心记录包括：原站与新站的技术环境清单、URL映射表、内容与数据库备份说明、DNS与证书变更记录、迁移前基线数据、迁移操作日志以及回滚方案。这些记录的目标不是“留个档案”，而是在迁移后出现收录下降、页面报错或流量异常时，能快速判断问题出在内容、解析、服务器还是配置环节。
先明确要观察什么：迁移前必须采集的基线记录
没有迁移前的数据，迁移后就无法判断变化是否异常。建议在正式切换前至少采集并留存以下内容：
- 可访问性基线：主要栏目、核心页面的HTTP状态码、响应时间、页面大小。
- 收录与索引基线：主流搜索引擎中已收录的URL数量与代表性URL列表。
- 流量基线：迁移前2至4周的自然搜索点击、展示、主要落地页数据。
- 内容基线：页面总数、图片与附件数量、表单与评论等动态数据量。
- 技术基线：服务器环境版本、CMS或框架版本、已启用插件或模块、伪静态规则。
这些记录用于迁移后对比。若某项数据在迁移前没有留存，后续出现波动时只能凭印象判断，定位效率会明显下降。
URL映射表：迁移中最容易被忽略却最关键的一份记录
URL映射表记录“旧地址对应哪个新地址”。它的作用是让旧链接通过301跳转到新页面，避免用户和搜索引擎访问到404页面。
映射表至少应包含四列：旧URL、新URL、页面类型、跳转类型。例如假设旧站栏目页为/news/list-1.html，新站对应页为/news/，则应记录为301跳转，而不是直接删除。
判断映射是否完整的检查方法：随机抽取旧站各栏目20至30个URL，逐个访问，确认是否跳转到内容相关的新页面。若跳转到首页或无关页面，应视为无效映射，需要修正。
DNS、证书与服务器变更记录
域名解析和HTTPS证书是迁移后故障的高发环节。应记录：
- 原DNS解析记录：A记录、CNAME记录及其对应IP或目标。
- 变更时间点：何时修改解析、预计生效范围。
- 证书信息：证书覆盖的域名、签发时间、到期时间、部署位置。
- 服务器信息：新服务器的Web服务软件及版本、PHP或运行环境版本、数据库版本。
迁移后若出现“部分地区打不开”或“浏览器提示证书错误”，可先核对解析是否已全部指向新服务器、证书是否包含当前访问的域名。注意，解析生效时间受TTL设置影响，不同网络环境下的结果可能不一致，这属于可能原因之一，需要结合具体现象排查，而不是直接断定。
迁移操作日志与回滚方案
操作日志按时间顺序记录每一步动作：备份时间、数据导入时间、文件上传时间、解析修改时间、跳转规则启用时间。每条记录注明操作人和结果。
回滚方案要写明：如果迁移后出现严重错误，恢复到原站的步骤是什么、需要多长时间、由谁执行。回滚方案不是形式文件，而是出现问题时能否快速恢复的判断依据。
迁移后复查：用记录逐项对比
复查阶段按以下顺序执行：
- 访问核心页面，确认状态码为200，页面内容与预期一致。
- 抽查旧URL，确认301跳转指向正确的新页面。
- 检查网站地图与robots文件是否指向新地址，是否误屏蔽重要目录。
- 对比迁移前后的收录数据与流量数据，观察是否存在持续异常。
- 检查表单提交、搜索、登录等功能是否正常。
若发现异常，先回到对应记录中查找变更点，再判断是配置问题、内容问题还是解析问题。记录越完整，定位范围越小。
下一步建议：按上述清单整理一份迁移记录表，在正式切换前完成基线数据采集和URL映射核对，确认无误后再执行解析变更。
