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

外贸网站建设网站迁移应准备哪些记录：先盘点域名、DNS、文件与数据库

外贸网站迁移前，最该先准备的是一份可核对的记录清单，而不是急着上传文件。记录至少覆盖域名与DNS、服务器与账号、网站文件、数据库、邮件与第三方服务、旧站URL与重定向、以及迁移前后的验证结果。时间和人手有限时，优先处理域名、DNS、数据库和URL这四类记录，因为它们一旦出错，恢复成本最高。

先观察：旧站现在依赖哪些外部记录

在动任何文件之前，先把旧站的外部依赖列出来。外贸站常见的外部依赖包括：域名注册商账号、DNS解析记录、SSL证书、企业邮箱、Google Search Console或Bing Webmaster Tools验证记录、支付或询盘表单接口、CDN或防火墙配置。

判断方法：打开旧站，逐项确认它是否依赖某个独立服务。例如，询盘表单提交后发到哪个邮箱、是否调用第三方API、是否有独立子域名用于邮件或下载。把这些写成一张表，字段包括“服务名称、用途、管理账号、到期时间、迁移后是否继续使用”。

这一步不需要技术权限也能做，适合时间和人手有限时最先启动。记录不完整会导致迁移后表单失效、邮件收不到、搜索平台验证掉线。

判断：哪些记录必须原样保留，哪些可以重建

不是所有记录都要照搬。判断标准是：改动后是否影响用户访问、邮件收发或搜索平台对站点的识别。

• 必须原样保留或提前规划：域名所有权记录、DNS中MX记录（邮件）、TXT记录（验证与邮件安全）、旧站主要URL结构。
• 可以重建：服务器上的临时文件、缓存、日志、测试环境配置。
• 需要重新生成：SSL证书、CDN缓存、搜索平台提交的新站点地图。

假设旧站有mail.example.com用于企业邮箱，迁移时如果只改了A记录却删掉MX记录，邮件就会中断。这类记录必须单独标注“不可动”。

如果旧站使用CMS，还要记录后台管理员账号、插件清单、主题名称和版本。不编造某插件能自动完成迁移，只记录它当前是否参与URL生成或表单提交。

处理：按优先级准备四类记录文件

时间和人手有限时，按下面顺序执行，每完成一项就打勾。

1. 域名与DNS记录。导出或截图当前DNS解析列表，标注每条记录的类型、主机名、值和TTL。重点标记MX、TXT、CNAME。迁移前先确认域名注册商账号可登录，避免迁移中无法改解析。
2. 服务器与账号记录。记录旧服务器IP、SSH端口、面板地址、数据库主机名、数据库名、数据库用户名。不要只记密码，还要记连接方式。
3. 网站文件与数据库备份记录。记录备份时间、备份文件存放位置、文件大小、数据库导出方式。验证方法：在本地或临时环境尝试恢复一次，确认备份可用。
4. 旧站URL与重定向记录。导出旧站主要页面URL，尤其是产品页、分类页、询盘页。迁移后逐条检查是否返回200或正确301。可以用curl -I检查单个URL状态码。

如果旧站有搜索平台验证文件，记录它放在根目录的哪个路径。迁移后需要重新验证或保留原文件，否则会失去旧数据查看权限。

复查：迁移后逐项核对记录是否生效

迁移完成后，不要只看首页能否打开。按记录清单逐项复查：

• 域名解析是否已指向新服务器，MX记录是否仍指向原邮件服务。
• 数据库连接是否正常，后台能否登录，产品数据是否完整。
• 旧URL是否按计划重定向，随机抽10条产品页检查状态码。
• 询盘表单是否仍能提交并送达指定邮箱。
• SSL证书是否覆盖主域名和必要子域名。
• 搜索平台是否已提交新站点地图，验证文件是否可访问。

判断结果：如果某项复查失败，先回看对应记录是否遗漏或写错，而不是直接改代码。记录的价值在于能快速定位是哪一层出了问题。

下一步：把上面四类记录整理成一个表格文件，标注负责人和完成状态。迁移开始前，先确认域名、DNS、数据库和URL这四项记录完整，再安排文件上传和切换。