建站规划方案：网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /aee0f5ee1e5e.html
📄
建站规划方案：网站迁移应准备哪些记录
网站迁移前最容易被低估的工作，不是传文件，而是把“原站点是什么状态”记录下来。常见误解是：只要备份了数据库和网站目录，迁移就能顺利完成。实际上，数据库和文件只保存了内容本身，域名解析、服务器环境、重定向规则、外部服务授权、页面索引状态等信息并不会自动跟着走。缺少这些记录，迁移后往往出现页面打不开、图片丢失、旧链接失效、邮件收不到、统计断档等问题。因此，建站规划方案中应把迁移记录列为独立环节，而不是等出问题再回头查。
先记录原站运行环境，避免新服务器不兼容
迁移前应逐项记录原站的技术环境，包括服务器操作系统及版本、Web 服务器类型及版本、程序语言版本、数据库类型及版本、依赖扩展和伪静态规则。判断依据是：新环境能否安装相同或兼容版本。如果原站使用较旧的程序语言版本，而新服务器只提供更高版本，就需要先确认程序是否兼容，再决定迁移方案。
可执行的检查项：
- 记录原站根目录路径、站点配置文件位置和伪静态规则文件。
- 记录数据库字符集、排序规则和当前占用大小。
- 记录计划任务、定时脚本和队列进程的触发时间。
- 记录 SSL 证书类型、到期时间和签发方式。
适用条件是：新服务器由自己管理或可自定义环境。若使用托管型建站服务，无法查看底层环境，则应改为记录服务商提供的迁移说明和可导出数据范围，不能套用自行管理服务器的检查清单。
记录域名与解析信息，区分两种迁移方案
网站迁移常见两种处理方案：一是保留原域名，只更换服务器；二是同时更换域名。两者需要准备的记录不同。
方案一：保留原域名，更换服务器。需要记录原域名的 DNS 服务商、解析记录类型和值、TTL 设置、CDN 或防护服务的接入状态。适用条件是：希望尽量保持原有链接和用户访问习惯。判断结果是：迁移后只需调整解析指向，旧链接结构可以继续沿用，但仍需检查服务器内部路径是否一致。
方案二：更换域名并迁移站点。除上述记录外，还要记录旧域名下所有需要保留的页面地址、已对外发布的链接、邮件域名记录和第三方回调地址。适用条件是：品牌域名变更或业务合并。判断结果是：必须为旧域名设置重定向，并逐一核对第三方平台中填写的回调地址，否则登录、支付或接口调用可能失败。
无论哪种方案，都应记录域名注册商、到期时间和管理账号归属，避免迁移后无法修改解析。
记录内容与链接结构，防止迁移后流量断层
迁移不是复制文件那么简单。页面 URL、栏目层级、图片路径、附件地址和内部链接都会影响访问。应记录以下内容：
- 原站主要栏目和页面 URL 规则，例如是否带日期、分类目录或文件扩展名。
- 已收录页面的地址范围，可通过站点地图和服务器访问日志整理。
- 图片、视频、文档等静态资源的存放目录和引用方式。
- 站内搜索、分页、标签页等动态参数的 URL 形式。
一个可执行的短例子：假设原站文章地址为 /news/2024/01/example.html，新站改为 /article/example。迁移前应导出旧地址清单，迁移后为每条旧地址建立对应重定向。若只改程序不记录旧地址，用户从外部链接进入时会看到 404 页面。这里的例子仅用于说明记录方法，不代表任何真实项目结果。
记录外部服务与权限，避免功能静默失效
网站通常依赖多项外部服务，例如邮件发送、短信通知、对象存储、统计代码、支付接口、地图接口和第三方登录。迁移前应记录每项服务的账号、密钥存放位置、回调地址、白名单 IP 和配额限制。判断方法是：在新服务器上逐项测试，而不是只看页面能否打开。
检查项包括：
- 邮件发送是否仍能送达，发信域名记录是否完整。
- 第三方登录回调地址是否已加入新域名。
- 统计代码是否仍能正常收集数据。
- 接口白名单是否包含新服务器 IP。
如果某项服务无法查看配置，应记录当前可用状态和联系人，而不是假设迁移后自动恢复。
迁移后核对记录，确认问题是否真正解决
迁移完成后，应拿迁移前的记录逐项核对，而不是凭感觉判断成功。核对顺序可以是：先确认首页和主要栏目可访问，再抽查旧链接重定向，然后测试表单、登录、邮件和支付等交互功能，最后观察服务器错误日志和访问日志。
判断结果时要注意：页面能打开不代表迁移完成；旧链接返回 200 也不代表内容正确，可能是重定向到了错误页面。只有记录、核对、修正三步都完成，迁移才算闭环。下一步可以整理一份迁移记录表，把环境、域名、链接、外部服务和核对结果放在同一份文档中，迁移前后各填写一次，便于对比和交接。
