WordPress主机迁移 - 怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2fc39454a0e3.html
📄
WordPress主机迁移 - 怎样取得可复查的状态证据
取得可复查的状态证据，核心是围绕迁移前后的域名解析、源站与目标站响应、数据库内容、文件完整性四条线，分别留下带时间戳的原始记录。判断标准不是“看起来正常”，而是同一项检查在迁移前后都能被另一个人按相同步骤复现，并得出相同结论。
先明确要复查什么，再决定记录什么
WordPress主机迁移涉及四类状态，缺一类就无法定位问题：
- 解析状态：域名当前指向哪个IP，TTL是多少。用
dig或nslookup记录，不要只看本地浏览器结果。 - 服务响应状态：目标主机返回的HTTP状态码、响应头、重定向链。用
curl -I保存完整输出。 - 数据状态：数据库表数量、关键表行数（如
wp_posts、wp_options）、siteurl与home的值。 - 文件状态：核心文件校验和、
wp-content目录下主题与插件目录数量、上传目录文件总数。
只记录“首页能打开”不足以复查。首页能打开时，内页404、图片丢失、后台登录跳回旧域名都可能同时存在，而这些恰好是迁移最常见的故障点。
用可对比的基线记录，而不是一次性截图
可复查的关键在于“前后可比”。迁移前先在源站执行一次完整记录，迁移后在目标站执行同样命令，逐项对比。假设迁移前 wp_options 中 siteurl 为 https://example.com，迁移后查询结果若变成 http://example.com，这就是一条可复查的证据，而不是猜测。
具体可执行的记录步骤：
- 在源站导出数据库前，执行
SELECT COUNT(*) FROM wp_posts;并保存结果与执行时间。 - 在源站用
curl -sI https://example.com/保存响应头，重点看server、location、content-type。 - 在源站记录
wp-content/uploads的文件总数，可用find命令统计。 - 迁移完成后，在目标站重复以上三项，把两组数据并排保存。
- 用
dig +short example.com记录解析IP，并注明查询时间，因为TTL未到期时不同网络看到的IP可能不同。
适用条件：这些步骤适合能登录服务器或主机面板、能执行命令行或数据库查询的情况。如果只有后台访问权限，至少可以记录后台“站点地址”设置、文章总数、媒体库文件数，虽然粒度较粗，但仍比截图首页更有复查价值。判断结果的方法很直接：同一项数据前后不一致，就说明该环节需要进一步定位；全部一致也不等于没有问题，还要看下一条。
区分“已经定位的原因”与“可能原因”
迁移后出现异常时，同一现象往往有多种解释，不能只凭一个现象下结论。例如内页打不开，可能原因包括固定链接未刷新、伪静态规则未随主机环境调整、数据库未完整导入。要区分它们，需要分别取证：
- 访问一个具体内页，记录返回状态码。返回404且首页正常，指向固定链接或重写规则问题；返回500，指向PHP或数据库连接问题。
- 查询
wp_options中permalink_structure的值，确认是否为空。 - 查看目标主机的错误日志，记录与访问时间对应的条目。
只有当日志条目、状态码、数据库值三者指向同一环节时，才能说“已经定位”。否则只能列为“可能原因”，继续补充证据。把可能原因写成确定结论，会让后续复查的人无法验证。
robots、站点地图与HTTPS不能当作迁移成功的证据
迁移后常有人用“robots.txt 能访问”“站点地图已生成”“HTTPS 已开启”来证明迁移完成。这三项都不能作为状态证据：
- robots.txt 中的抓取限制不等于可靠的索引移除，也不反映内容是否完整。
- 站点地图生成成功不保证页面会被收录，它只说明文件可访问。
- HTTPS 正常握手不保证站点无漏洞，也不代表迁移中的数据问题已解决。
它们可以作为附加检查项，但不能替代数据库行数、文件数量和响应头对比。不同搜索引擎对站点地图和索引的处理方式需要分别核查，不能用一个平台的结果推断另一个平台。
把证据整理成可交接的记录
最终的可复查状态证据应包含：检查时间、执行命令或操作路径、原始输出、与基线的差异、以及差异对应的待查环节。记录里不要只写“正常”或“已修复”，要写清楚哪一项数据从什么值变成了什么值。
下一步：选定迁移前的基线记录时间点，把上述四类检查各执行一次并保存原始输出，迁移完成后按相同顺序重复，先对比差异，再决定是否需要回滚或调整配置。
