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

淮北网站建设：网站迁移应准备哪些记录

网站迁移前最该准备的不是服务器账号，而是一份能对照旧站与新站的完整记录。记录应覆盖域名解析、页面地址、内容清单、功能配置和验证结果，迁移后逐项比对，才能判断哪些页面正常、哪些需要修正。

准备阶段：先建立旧站基线记录

在动任何文件之前，先把旧站现状固定下来。没有基线，迁移后无法判断问题是迁移造成的，还是原本就存在。

• 域名与解析记录：当前DNS服务商、A记录、CNAME记录、MX记录、TTL值，截图或抄录保存。
• 服务器信息：源站IP、Web服务器类型与版本、运行环境、数据库类型与版本。
• 页面地址清单：用爬虫工具或站点地图导出全部URL，标注哪些返回200、哪些是301、哪些是404。
• 内容与文件：页面数量、图片路径、附件目录、上传文件的存储位置。
• 功能配置：表单接收邮箱、伪静态规则、重定向规则、缓存设置、SSL证书信息。

这份基线记录是后续所有比对的依据，建议存成表格，每项写明旧值，留一列填新值。

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

迁移过程中最容易丢信息。每改一项就记一项，包括改了什么、什么时候改的、由谁操作。

• 数据库导出文件名称与导出时间，导入到新库后的表数量、数据行数。
• 文件迁移方式：打包下载还是直接同步，目标目录路径。
• DNS改动的具体记录值，改前与改后分别是什么。
• 若更换了CMS或框架，记录旧系统与新系统的对应关系，例如旧栏目对应新栏目、旧文章ID对应新文章ID。

这里最关键的一步是建立新旧URL一一对应表。网站迁移对访问影响最大的通常是地址变化，只要旧地址能正确跳到新地址，大部分已有链接就不会失效。对应表至少包含三列：旧URL、新URL、跳转类型。迁移完成后按这张表逐条测试。

验证阶段：按记录逐项检查

验证不是打开首页看一眼，而是拿准备阶段的基线记录逐条核对。

1. 解析检查：用命令行工具查询域名，确认返回的IP与记录一致。
2. 状态码检查：批量请求旧URL清单，确认预期跳转的返回301，保留的页面返回200，不该存在的返回404而不是500。
3. 内容抽查：随机抽取若干页面，对比标题、正文、图片是否完整，重点看含表单和附件的页面。
4. 功能测试：提交一次表单，确认邮件能收到；测试搜索、分页、登录等依赖数据库的功能。
5. 证书与安全：确认HTTPS可访问，证书域名匹配，没有混合内容警告。

如果某项检查结果与记录不符，先判断是配置遗漏还是数据本身缺失，再决定修复方式。同一现象可能有多种原因，例如页面打不开，可能是解析未生效、服务器未启动，也可能是防火墙拦截，需要逐项排除，不要凭第一反应下结论。

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

迁移完成后记录不要删。旧URL对应表、DNS变更记录、数据库版本信息，在之后排查问题时仍然有用。

• 保留旧域名解析至少一个完整周期，确认没有遗漏的跳转需求后再考虑调整。
• 定期查看服务器错误日志，关注404和500的出现位置，判断是否有未覆盖的旧地址。
• 若后续还要改版，把这次的记录作为新的基线，继续沿用同样的对照方法。

记录的价值在于可追溯：出问题时能快速定位是解析、文件、数据库还是跳转规则的问题，而不是从头猜测。

下一步可以先把旧站URL清单导出，做成新旧对应表的空模板，再开始迁移操作。