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

三亚做网站：网站迁移应准备哪些记录

网站迁移前最该先做的一件事，是建立一份可核对的迁移记录清单。它至少应包含域名与DNS记录、服务器与数据库信息、文件与数据库备份、页面URL对照表、账号权限、邮件与第三方服务、验证结果和回滚方案。对三亚做网站的企业或个人站来说，如果时间和人手有限，优先整理域名解析、数据库备份和URL对照表，这三项直接决定迁移能否顺利恢复和访问。

准备阶段：先记录什么，后动什么

迁移不是先传文件，而是先记录现状。准备阶段的目标是让任何一步出问题时都能回到原点。

• 域名与DNS记录：记录域名注册商、到期时间、当前DNS服务商、A记录、CNAME记录、MX记录、TXT记录。MX和TXT常被忽略，迁移后可能导致企业邮箱收不到信。
• 服务器信息：记录原主机商、服务器IP、操作系统、Web服务器类型、PHP或运行环境版本、站点根目录路径。
• 数据库信息：记录数据库类型、版本、库名、用户名、字符集，以及是否需要导出存储过程或触发器。
• 账号权限：记录域名管理后台、主机控制面板、CMS后台、数据库管理工具的账号归属和权限级别，确认至少两人可操作。
• 第三方服务：记录统计代码、支付接口、短信接口、地图接口、CDN、SSL证书签发方式。迁移后这些配置可能仍指向旧环境。

人手有限时，把上述内容写进一张表，每项标注“已确认/待确认/不适用”。不要只靠记忆，迁移中很容易漏掉一个CNAME或一条TXT记录。

实施阶段：备份与URL对照表最关键

实施阶段最容易出错的地方，是只备份了网站文件，没备份数据库，或者迁移后URL结构变了却没有记录。建议按以下顺序执行：

1. 先做完整备份：网站文件打包，数据库单独导出，两者都下载到本地或另一台机器，不要只留在原服务器。
2. 记录原站URL结构：用站点地图或爬虫工具导出主要页面URL，形成“旧URL→新URL”对照表。如果迁移后路径不变，也要记录，方便验证。
3. 在新环境恢复文件和数据库，修改配置文件中的数据库连接、站点地址等参数。
4. 暂不修改DNS，先用临时地址或hosts绑定测试新站是否能正常打开、登录、提交表单。
5. 确认无误后再切换DNS，并保留旧环境至少一周，作为回滚条件。

这里的关键判断是：如果新站页面能打开但样式错乱，可能是站点地址或资源路径仍指向旧域名；如果后台能登录但文章打不开，可能是伪静态规则或数据库前缀未同步。不同现象对应不同原因，不要一看到打不开就断定是DNS问题。

验证阶段：逐项检查，别只看首页

迁移完成后，首页能打开不代表迁移成功。验证要覆盖用户实际会走的路径：

• 首页、栏目页、文章页、搜索页各抽查若干条，确认内容完整、图片显示正常。
• 用旧URL对照表逐条访问，检查是否返回正常页面，而不是404或跳转到无关页面。
• 测试表单提交、用户登录、评论、支付等交互功能，确认数据库读写正常。
• 检查HTTPS证书是否对新域名生效，浏览器是否提示不安全。
• 检查企业邮箱收发是否正常，MX记录是否已随DNS切换生效。
• 查看统计代码是否在新站触发，避免迁移后数据断档。

如果某条旧URL打不开，先判断是路径未同步、重定向未配置，还是服务器规则未生效。只有确认原因后再修改，不要反复切换DNS来“试试看”。

维护阶段：迁移后仍要保留的记录

迁移结束不等于记录可以删除。至少保留以下内容一段时间：

• 旧环境备份和旧DNS记录，保留到新站稳定运行后再清理。
• URL对照表，后续做重定向调整或排查收录问题时仍会用到。
• 账号权限变更记录，明确哪些账号已停用、哪些已移交。
• 迁移时间点和操作人，方便出现问题时回溯。

对三亚做网站的用户来说，如果网站还涉及本地服务展示、预约或联系方式，迁移后要额外确认这些页面和接口在新环境下仍能正常工作。判断标准很简单：用手机和电脑各访问一次，实际提交一次表单，看结果是否到达指定邮箱或后台。

下一步，建议先打开当前域名管理后台和主机控制面板，把DNS记录、数据库版本、站点根目录三项抄进一张迁移记录表，再开始做备份。这一步做完，后面的迁移和排查才有依据。