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

wordpress建站空间网站迁移应准备哪些记录：一份可核对的交接清单

迁移 WordPress 建站空间，需要准备的记录包括：原主机的空间参数与账户信息、数据库导出文件、网站文件完整备份、域名与 DNS 解析记录、SSL 证书状态、WordPress 后台管理员账号、插件与主题清单、定时任务与邮件配置。准备这些记录的目的不是留档，而是让新空间能复现原站运行条件，并在出问题时快速定位是文件、数据库、解析还是配置造成的差异。

先明确迁移要交付什么结果

从结果倒推，迁移完成应满足：域名访问到新空间、页面内容与原来一致、后台能正常登录、表单能发信、固定链接不 404、HTTPS 不报错。围绕这几个结果，记录就分成四类：空间与账户、文件与数据库、域名与证书、程序配置。缺少任何一类，迁移后都可能出现“页面能开但后台进不去”或“首页正常但内页 404”这类局部故障。

空间与账户记录：新环境要能对上原环境

这部分记录用于判断新旧空间是否兼容，而不是简单抄一份账号密码。

• 原空间类型：共享主机、VPS 还是云服务器；这决定迁移方式是自己打包上传还是用面板工具。
• PHP 版本与 MySQL/MariaDB 版本：新空间版本低于原空间时，部分主题或插件可能报错。
• 磁盘占用与数据库大小：用来判断新空间容量是否够用，也影响导出方式。
• FTP/SFTP 账号、主机面板登录地址与账号：用于下载文件和排查权限。
• 是否开启缓存、CDN 或对象存储：这些若不在新空间重建，迁移后可能出现旧内容或图片缺失。

检查项：在新空间建一个测试目录，上传一个 phpinfo 文件，核对 PHP 版本、内存限制、上传大小限制是否满足原站要求。判断结果：如果新空间 PHP 版本更低或内存限制更小，先调整环境再迁移，否则容易在导入数据库时中断。

文件与数据库记录：迁移的核心证据

文件备份应包含 WordPress 根目录下的全部内容，重点是 wp-content 中的 themes、plugins、uploads。数据库导出建议用 SQL 文件，并记录以下信息：

• 数据库名、用户名、密码、主机地址（通常是 localhost 或独立地址）。
• 表前缀，例如 wp_ 或自定义前缀；导入后要对应修改 wp-config.php。
• 导出时间与导出方式：命令行 mysqldump、面板导出还是插件导出。
• 网站地址与 WordPress 地址两项配置值，迁移后若域名不变通常无需改，换域名则必须替换。

假设示例：原站数据库 80MB，用面板导出时提示超时，只得到一个不完整的 SQL 文件。导入新库后后台能登录但文章列表为空。此时应重新用命令行导出，并核对 SQL 文件末尾是否有完整的建表语句，而不是先怀疑新空间有问题。

域名、DNS 与证书记录

记录当前域名的 DNS 解析：A 记录指向的 IP、CNAME 记录、MX 邮件记录、TXT 验证记录。迁移时只改 A 记录指向新空间 IP，不要动 MX，否则企业邮箱会中断。同时记录 SSL 证书是自签、免费证书还是付费证书，以及到期时间。新空间若用不同方式签发证书，要确认证书覆盖带 www 和不带 www 两个主机名。

判断结果：修改解析后，用 ping 或在线 DNS 查询确认已指向新 IP，再访问网站。若解析已生效但访问仍是旧站，可能是本地 DNS 缓存或新空间未绑定该域名，需要分别排查，而不是直接判定迁移失败。

迁移后必须逐项验收的记录

把下面每一项写成可勾选的检查表，验收时逐条记录结果和现象：

1. 首页、文章页、分类页、搜索页各打开一个，确认无 404 和白屏。
2. 登录后台，检查固定链接设置是否仍为“文章名”，保存一次刷新规则。
3. 测试联系表单发信，确认收件邮箱能收到。
4. 检查图片是否显示，特别是 uploads 目录中的历史图片。
5. 确认 HTTPS 锁标正常，页面内没有混合内容警告。
6. 记录迁移前后数据库表数量与文章数量，用于判断数据是否完整。

如果某项不通过，先记录具体现象：是全部页面异常还是个别页面异常，是前台异常还是后台异常。现象范围本身就是定位依据，比笼统地说“迁移后有问题”更容易找到原因。

下一步怎么做

按上面的四类记录整理成一份迁移清单，先在本地或测试目录完成一次导入演练，确认数据库和文件能还原，再动正式域名的解析。演练中出现的报错信息、缺失文件和版本差异，都应补进记录，作为正式迁移时的判断依据。