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

巴中做网站：网站迁移应准备哪些记录？先备好这五类清单

网站迁移前最该准备的不是服务器密码，而是一份能还原现状的记录：域名与解析、原站文件与数据库、页面清单、重定向规则、验证结果。缺少这些记录，迁移后一旦出现打不开、收录下降或表单失效，很难判断是迁移操作出错，还是原本就存在的问题。对巴中做网站的项目来说，迁移往往同时涉及域名、主机和后台，记录越完整，定位原因越快。

准备阶段：先记录迁移前的基线状态

基线记录的作用是给迁移后的对比提供参照。迁移前至少保存以下内容：

• 域名注册商、DNS 服务商、当前解析记录（A、CNAME、MX、TXT），截图或导出文本。
• 原主机的系统类型、程序版本、数据库版本，以及网站根目录结构。
• 完整文件备份和数据库导出文件，记录备份时间与文件大小。
• 当前可访问的页面清单，包括首页、栏目页、内容页、表单页和 404 页面。
• 迁移前一周的访问与收录概况，例如搜索资源平台里的索引量、抓取异常数。

这一步的关键是先记录，再动手。如果先改了解析再回头找原记录，很多信息已经无法还原。备份文件建议放在与原主机不同的位置，避免迁移过程中两边同时丢失。

实施阶段：记录每一次改动

迁移实施时，最容易出问题的是“改了什么没人记得”。建议用一张改动记录表，逐条写下：

1. 改动时间与操作人。
2. 改动对象，例如某条 A 记录、某个数据库连接配置、某个伪静态规则。
3. 改动前后的值，直接写清楚，不要只写“已修改”。
4. 改动原因，例如更换主机、修复 404、统一域名。

如果迁移涉及域名更换，需要提前准备重定向规则记录：哪些旧地址对应哪些新地址，是整站规则还是逐条规则。规则写好后先在测试环境验证，确认返回状态码正确，再应用到正式环境。这里要区分“可能原因”和“已经定位的原因”：页面打不开可能是解析未生效，也可能是程序报错或防火墙拦截，不能只凭一个现象就断定是 DNS 问题。

验证阶段：用检查项确认迁移结果

迁移完成后，按下面的检查项逐条核对，并把结果记录下来：

• 域名解析是否已指向新主机，可用 ping 或在线 DNS 查询工具查看。
• 首页与主要栏目页能否正常打开，返回状态码是否为 200。
• 旧地址是否按规则跳转到新地址，跳转是否为 301。
• 表单提交、登录、搜索等交互功能是否正常。
• 图片、样式、脚本等静态资源是否加载完整。
• 搜索资源平台中的抓取与索引数据是否出现异常波动。

判断结果时要看条件：如果解析已生效但页面仍打不开，问题更可能在主机配置或程序本身；如果页面能打开但样式错乱，通常是资源路径或缓存问题。把每个检查项的结果写进记录，后续排查才有依据。

维护阶段：保留记录并持续观察

迁移不是一次动作，而是一段观察期。建议在迁移后继续记录：

• 每天或每几天的抓取异常、404 数量、索引量变化。
• 用户反馈的报错页面与出现时间。
• 后续每次调整的原因和结果。

这些记录能帮助区分“迁移遗留问题”和“新出现的问题”。如果迁移后收录下降，先核对重定向规则和页面可访问性，再考虑内容或其他因素，不要直接归因于某一个原因。

最关键的一步：迁移前导出完整页面与解析清单

如果只能做一件事，那就是在迁移前把当前可访问页面清单和 DNS 解析记录完整导出。页面清单决定迁移后要验证哪些地址，解析记录决定出问题时能否快速还原。缺少这两项，后续排查会变成凭印象猜测。

下一步可以做的，是打开域名管理后台和搜索资源平台，把解析记录与索引概况分别导出保存，再开始迁移操作。