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

WordPress主机迁移日志中应该核对哪些字段 - 迁移后日志排查清单

迁移WordPress主机后，日志里最该优先核对的是请求时间、客户端IP、请求方法、请求URI、HTTP状态码、响应大小、User-Agent、Referer这几类字段，再结合PHP错误日志中的时间戳、错误级别、文件路径与行号交叉比对。判断迁移是否成功，不看日志有没有内容，而看同一批URL在迁移前后这些字段是否出现异常变化。

访问日志：先确认请求有没有打到新主机

访问日志（常见为access log）记录每次HTTP请求。迁移后第一件事是确认流量确实到了新环境，而不是仍被解析到旧IP。

• 要查什么：客户端IP、请求时间、请求方法、请求URI、HTTP状态码。
• 怎么查：用grep筛出首页和几个内页的URI，例如grep "GET /about" access.log，观察状态码分布。
• 结果说明什么：如果大量出现404，可能是固定链接规则或伪静态未随迁移配置；如果出现301跳转到旧域名，说明站点地址仍指向原域名；如果状态码正常但响应体为空，问题更可能在PHP或数据库层，而非Web服务器。

注意日志时间字段通常按服务器时区记录，与本地时间可能不一致。核对时先确认时区，否则会把正常请求误判为异常时段。

状态码与响应大小：识别迁移后的隐性故障

状态码200不代表页面内容正确。迁移中常见的情况是页面返回200，但实际输出的是错误页或空白页。

• 要查什么：HTTP状态码、响应字节数（body bytes）。
• 怎么查：对同一URL，把迁移前后的响应大小做对比；若某页从数万字节骤降到几百字节，往往意味着模板或数据未正确加载。
• 结果说明什么：响应大小骤降配合200状态码，指向主题文件缺失、插件未启用或数据库表未完整导入；若配合500状态码，则更可能是PHP版本不兼容或权限问题。

状态码本身有多种解释。同样一个500，可能是PHP致命错误，也可能是Web服务器配置错误，需要结合错误日志才能定位，不能只看状态码下结论。

PHP错误日志：定位迁移引发的代码层问题

WordPress运行在PHP之上，迁移后PHP版本、扩展或文件权限变化都会写入错误日志。

• 要查什么：时间戳、错误级别（Notice/Warning/Fatal error）、出错文件路径、行号、错误信息。
• 怎么查：在wp-config.php中开启调试日志（WP_DEBUG_LOG），复现问题后读取wp-content/debug.log；同时查看服务器PHP错误日志。
• 结果说明什么：若错误集中在某个插件目录，说明该插件与新环境不兼容；若报“Cannot modify header information”，通常是文件末尾多余空白或输出提前发生；若报数据库连接失败，核对数据库主机、用户名与密码是否已更新。

错误级别要区分对待：Notice通常不致命但可能暴露代码陈旧；Fatal error会直接导致页面中断，优先级最高。

User-Agent与Referer：判断流量来源是否异常

迁移后如果搜索引擎或外部链接带来的流量行为突变，这两个字段能提供线索。

• 要查什么：User-Agent字符串、Referer来源。
• 怎么查：统计迁移前后User-Agent的分布，观察主流搜索引擎爬虫的抓取频率和抓取到的状态码。
• 结果说明什么：若爬虫请求大量返回404或503，说明抓取受阻，需要检查robots.txt和服务器限流配置；若Referer中出现旧域名，说明部分外链或站内跳转仍指向原地址，需要更新。

这里要分清：robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。日志能反映抓取行为，但不能据此推断排名结果。

可执行核对清单

1. 确认日志时间字段的时区，与操作时间对齐。
2. 筛出首页、栏目页、文章页各若干URL，记录状态码与响应大小。
3. 与迁移前同URL的响应大小对比，标记骤降项。
4. 读取PHP错误日志，按Fatal error优先排序处理。
5. 核对数据库连接配置与文件权限是否随环境更新。
6. 观察搜索引擎爬虫的抓取状态码，确认无大面积404或503。
7. 检查站内链接与跳转是否仍指向旧域名。

完成上述核对后，下一步是修复日志中已定位的具体问题，再重新抓取同一批URL，对比状态码与响应大小是否恢复正常，而不是仅凭“页面能打开”就结束迁移验收。