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

湛江网站设计：网站迁移应准备哪些记录

网站迁移前最该准备的记录是一份“迁移台账”，至少覆盖域名与解析、服务器环境、程序与数据库、页面与链接、账号权限、邮件与第三方服务六类信息。有了这份记录，迁移后才能逐项核对，而不是靠记忆判断是否完成。下面先说明两种常见处理方案的适用条件，再给出可直接执行的记录清单与验收信号。

两种处理方案：整站搬迁与重建迁移

网站迁移通常有两种做法，选择哪一种取决于原站的健康程度和你的目标。

• 整站搬迁：把原程序、数据库、附件整体复制到新环境。适用条件是原站结构清晰、无大量死链、程序版本仍可维护。优点是改版成本低，缺点是历史问题会被一起带走。
• 重建迁移：在新环境重新搭建，只保留内容和必要数据。适用条件是原站存在大量冗余页面、程序老旧或结构混乱。优点是能顺带清理，缺点是工作量大，链接映射必须做细。

判断依据可以看三点：原站是否存在大量无流量页面、程序是否还能升级、迁移后是否需要改版。如果三点都是否，整站搬迁更省事；如果有两点以上为是，重建迁移更划算。

迁移前必须留存的记录清单

以下记录建议在动手前整理成表格，逐项填写并保存副本。

1. 域名与解析记录：域名注册商、到期时间、当前 DNS 服务商、A 记录、CNAME 记录、MX 记录、TXT 记录。迁移前先截图或导出解析列表，迁移后逐条比对。
2. 服务器与环境记录：操作系统版本、Web 服务器类型与版本、PHP 或其他运行环境版本、数据库版本、已安装扩展。这些决定新环境能否直接跑起来。
3. 程序与数据库记录：程序名称与版本、数据库表前缀、数据库大小、附件目录路径、伪静态规则。数据库导出后要校验表数量与总行数是否一致。
4. 页面与链接记录：栏目结构、URL 规则、重要页面清单、内链分布。重建迁移时，这份记录直接决定重定向映射表怎么写。
5. 账号与权限记录：后台管理员、数据库账号、FTP 或 SSH 账号、CDN 账号。迁移后要逐一确认权限是否可用，并删除临时账号。
6. 邮件与第三方服务记录：企业邮箱解析、统计代码、支付接口、短信接口、地图接口的配置项。这些最容易在迁移后被遗漏。

如果原站使用了内容管理系统，先记录当前使用的版本号和已启用模块，不要假设新环境装上同款程序就能直接运行，版本差异可能导致数据表结构不兼容。

迁移执行中的核对步骤

准备一份可执行的核对流程，按顺序做，每步留下结果记录。

1. 在新环境部署程序，导入数据库，确认后台可登录、文章列表可打开。
2. 复制附件目录，抽查图片和下载文件是否能正常访问，重点看中文文件名和大小写敏感问题。
3. 配置伪静态规则，逐条测试栏目页、内容页、搜索页的 URL 是否与原站一致。
4. 修改解析前，先用本地 hosts 指向新服务器测试，确认无误后再切换 DNS。
5. 切换后检查邮件收发、统计代码上报、接口回调是否正常。

技术排查时要区分“可能原因”和“已经定位的原因”。例如页面打不开，可能是解析未生效、伪静态未配置、数据库连接失败中的任意一种，需要逐项排除后再下结论，不要一上来就断定是服务器问题。

验收信号与常见遗漏

迁移完成的判断标准不是“首页能打开”，而是以下信号同时成立：

• 重要页面的 URL 与原站一致，或已配置 301 跳转且跳转目标正确。
• 数据库表数量、附件数量与迁移前记录一致。
• 后台可正常发布内容，前台能即时显示。
• 邮件能正常收发，第三方接口回调无报错。
• 旧域名与新域名都能访问，且最终指向同一站点。

常见遗漏集中在三处：MX 记录未同步导致邮箱中断、伪静态规则未复制导致内容页 404、统计与接口代码未更新导致数据断档。这三项都应在迁移台账中单独列出并打勾确认。

下一步建议：先按上面的六类记录整理出你当前网站的迁移台账，再根据原站健康程度决定采用整站搬迁还是重建迁移，最后按核对步骤逐项执行并留存结果。