WordPress主机迁移：页面内容相同但响应头不同会影响哪些判断

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

WordPress主机迁移：页面内容相同但响应头不同会影响哪些判断

页面正文看起来一模一样，响应头却在新旧主机上不同，最直接的影响是：你不能再把“内容相同”当作迁移成功的证据。响应头决定浏览器、爬虫和中间缓存如何理解这个页面，一旦它变了，访问结果、缓存行为和抓取判断都可能跟着变，而你在页面上看不到任何差异。

先分清：哪些响应头差异可以忽略，哪些必须处理

不是所有响应头变化都值得停下来排查。判断依据是：这个头是否参与“谁可以看、看多久、以什么身份看”的决策。

实际操作：在新旧主机上分别用 curl -I 请求同一个 URL，把两次输出并排比对。如果只有 Date 和 Server 不同，迁移对响应层的影响可以判定为低；如果 Cache-Control 或 Vary 不同，下一步必须查清是哪一层加上的，而不是直接改主题文件。

两种条件：缓存头不同时，该改源站还是改边缘

假设旧主机返回 Cache-Control: max-age=3600，新主机返回 Cache-Control: no-cache, must-revalidate，页面内容完全一致。这时有两种成立的选择，取决于差异来自哪里。

条件一：差异来自源站配置

如果新主机的 Web 服务器、PHP 或缓存插件主动输出了 no-cache，而旧主机没有，那么这是源站行为改变。动作是检查新主机上的缓存插件设置、.htaccess 或 Nginx 配置，确认是谁在覆盖默认值。结果是：改回一致后，边缘缓存才可能重新按预期工作；如果只改边缘不改源站，边缘会持续收到不可缓存的信号。

条件二：差异来自边缘或代理层

如果源站两边都返回 max-age=3600，但经过新主机的 CDN 后变成 no-cache，那么问题在边缘规则。动作是检查 CDN 的缓存规则和回源头改写。结果是：修边缘规则即可，源站不需要动。反过来，如果先改源站，边缘仍会按自己的规则覆盖，排查会绕远路。

区分这两种条件的证据很简单：直接请求源站 IP（绕过 CDN）看响应头，再请求域名看响应头。两次不一致，说明边缘参与了改写；两次一致，说明差异在源站。

Vary 和 Set-Cookie 变化会改变“同一页面”的含义

页面内容相同，但如果新主机多返回了 Vary: Cookie 或额外的 Set-Cookie，缓存系统会把原本可以共用的副本拆成多份，命中率下降，回源增多。你看到的页面没变，但缓存层看到的是不同对象。

动作：对比新旧响应中的 Vary 和 Set-Cookie。如果新主机对匿名访问也下发 Cookie，先确认这是否必要。结果是：去掉不必要的 Cookie 后，缓存可以重新合并副本；如果确实需要，就要接受缓存粒度变细，并相应调整缓存策略，而不是继续按旧假设估算回源量。

例外：如果站点本身依赖登录态或个性化内容，Vary: Cookie 可能是正确行为，此时不应为了“和旧主机一致”而移除它。

X-Robots-Tag 和重定向头：内容相同也可能被区别对待

最容易被忽略的是 X-Robots-Tag。页面 HTML 里没有 noindex，但新主机在响应头里加了这个字段，抓取端看到的就是不可索引信号。此时页面内容相同，判断却完全相反。

动作：检查新旧响应头中是否存在 X-Robots-Tag，以及 Location 是否指向了不同目标。结果是：如果新主机多出限制性头，需要定位是服务器、插件还是安全策略加入的；如果 Location 目标变了，要确认重定向链是否仍然指向最终页面，而不是中途落到其他地址。

注意：robots.txt 的抓取限制不等于索引移除，站点地图也不保证收录。响应头里的限制信号和这些机制各自独立，不能互相替代判断。

一个可复用的判断顺序

  1. 固定一个 URL，用同样的请求方法分别打到旧主机、新主机源站、新主机域名入口。
  2. 只标记会改变缓存、身份、重定向和抓取许可的头，忽略环境噪声。
  3. 对每个差异头，先判断它由源站还是边缘产生，再决定改哪一层。
  4. 改完后重复同一请求，确认差异头已经收敛或已被有意保留。

如果做完这些，页面内容相同但响应头仍存在你无法解释的差异，那么下一步不是继续改页面，而是把差异头按产生层归类，逐层排除。只有确认差异不再影响缓存、身份和抓取判断，迁移在响应层才算处理完毕。

图1 图2
nginx