网站迁移前最该准备的,不是一句“备份好了”,而是一份能让人接手、能回滚、能核对结果的记录清单。对山西网页制作项目来说,无论换服务器、换域名、换程序还是换维护人员,先记录现状,再动手迁移,才能避免页面打不开、表单收不到、收录掉光却找不到原因。
时间和人手有限时,优先记录“迁移后无法凭记忆恢复”的信息。建议用一张表格或一个文本文件,按下面几类逐项填写。
记录时以“原样可查”为标准。比如DNS记录,不要只写“解析到某主机”,要写记录类型、主机记录、记录值。迁移后逐条比对,才能判断是解析没生效还是记录填错。
记录齐全后,按影响面排序,而不是按操作难易排序。判断依据可以看三点:
如果原网站还能正常访问,先做一次完整快照:数据库导出文件、网站文件压缩包、当前DNS记录截图或文本导出。快照不是迁移本身,而是迁移失败时的回退依据。人手有限时,至少保证数据库和上传目录各有一份可恢复的副本。
迁移动作可以拆成四步,每一步都对应前面的记录项。
第一步,在新环境还原程序与数据。按记录的PHP版本、数据库版本创建环境,导入数据库,上传网站文件,修改配置文件中的数据库连接信息。配置文件里常见的是数据库名、用户名、密码、表前缀,改完先不要动域名解析。
第二步,用临时地址验证。通过修改本地hosts文件或使用临时域名访问新站,检查首页、栏目页、内容页、搜索页、表单提交是否正常。这一步能发现数据库没导全、伪静态规则没配、上传目录权限不对等问题。
第三步,切换解析并保留旧记录。确认新站可用后,再修改DNS解析。修改前把旧解析值完整记录,万一新服务器异常,可以快速改回。MX记录如果指向邮箱服务,不要跟着A记录一起乱改。
第四步,处理URL变化。如果迁移后URL结构变了,需要为旧URL设置301跳转到新URL。记录旧URL清单和对应新URL,逐条配置。没有URL变化的迁移,也要检查robots.txt是否误屏蔽、sitemap是否指向新域名。
迁移完成不等于结束。按下面清单逐项检查,结果要写回记录表,方便下次迁移或交接。
复查中发现异常,先对照迁移前的记录判断是“配置漏了”还是“新环境不支持”。例如页面空白可能是数据库连接失败,也可能是PHP版本不兼容,不要只归因于一个原因。逐项排除后,把最终可用的配置更新到记录表中。
下一步,把这份记录整理成一份可交接的迁移文档,放在团队能共同访问的位置,并注明最后更新时间和下次检查时间。这样即使换人操作,也能按记录复现迁移过程,而不是靠回忆和猜测。