WordPress主机迁移 - 动态页面怎样确认可见内容
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8025224f1441.html
📄
WordPress主机迁移 - 动态页面怎样确认可见内容
迁移后确认动态页面可见内容，不能只看浏览器里是否显示正常，而要在“未登录、无缓存、模拟搜索引擎”的条件下，检查服务器实际返回的 HTML 中是否包含正文。很多迁移后的问题恰恰是：页面在管理员登录状态下看起来一切正常，但搜索引擎或未登录访客拿到的却是空白、报错或旧内容。
常见误解：页面能打开就等于内容可见
这是第一次处理迁移问题时最容易踩的坑。动态页面（如文章页、产品页、分类页）的内容由 PHP 查询数据库后实时生成，浏览器能打开只说明请求链路通了，不代表返回内容正确。以下几种情况会让“看起来正常”的页面实际不可见：
- 页面被缓存插件返回了迁移前的旧 HTML，或返回空白缓存。
- 对象缓存（如 Redis）仍指向旧主机的数据，查询结果为空。
- 数据库连接配置指向旧库，页面框架渲染出来但正文为空。
- 服务器返回 200 状态码，但正文位置是报错信息或占位内容。
因此判断标准要从“浏览器能显示”改为“响应正文是否包含预期内容”。
用源码而不是肉眼确认正文
最直接的做法是查看页面源码，而不是看渲染后的画面。在未登录浏览器的隐私窗口中打开目标动态页面，右键查看网页源代码，搜索正文中一段独有的文字，例如文章第一句或产品名称。
判断结果：
- 源码中能找到该文字，说明服务器返回的 HTML 包含正文，可见性基本正常。
- 源码中没有该文字，但页面视觉上显示正常，说明内容很可能是由 JavaScript 后续加载或被缓存层替换，需要进一步确认搜索引擎能否拿到。
- 源码中只有模板框架、没有正文，说明动态查询失败，应检查数据库连接与缓存。
适用条件：该方法对服务端渲染的 WordPress 动态页面有效。如果站点大量依赖前端异步加载，源码检查只能作为起点，还要结合抓取工具验证。
模拟搜索引擎抓取，区分“能访问”与“能读到”
搜索引擎抓取时通常不带登录状态，也不执行完整的前端脚本。可以用命令行工具模拟一次抓取，核对返回内容：
curl -A "Mozilla/5.0" -s https://example.com/sample-post/ | grep "正文中的独有文字"
把网址和文字替换成实际内容。如果命令有输出，说明该页面在无登录、无浏览器环境的请求下仍返回了正文；如果没有输出，需要排查是缓存、重定向还是动态查询的问题。
需要注意两点：
- robots.txt 限制抓取不等于内容被移除，也不等于能可靠地从索引中删除页面，两者是不同机制。
- 站点地图提交不保证收录，它只帮助发现网址，是否索引由搜索引擎自行判断。
迁移后逐项检查动态页面的可见性
建议按下面的顺序排查，每一项都有明确的通过条件：
- 固定链接：打开一篇文章，确认 URL 结构与迁移前一致，没有 404 或跳转到首页。
- 数据库连接：查看
wp-config.php中的数据库主机、库名、用户是否指向新环境，页面正文能查出即通过。 - 缓存清理：清空页面缓存与对象缓存，再重复源码检查，确认返回的是当前内容而非旧缓存。
- 未登录访问：用隐私窗口或无痕模式打开，排除登录态带来的差异。
- 抓取模拟：用上面的 curl 命令核对返回正文，确认无登录请求也能拿到内容。
如果某一步不通过，先解决该步再继续，不要跳步判断。动态页面的可见性问题往往由多个环节叠加，逐项确认比整体猜测更可靠。
下一步
选一个迁移后最有代表性的动态页面，按“源码检查 → 未登录访问 → curl 模拟抓取”三步走一遍，记录每一步的实际返回结果。若三步都通过，再抽样检查其他类型页面；若某步失败，就停在那一步排查对应的缓存、数据库或重定向配置。
