WordPress主机迁移：临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a7856b104327.html
📄
WordPress主机迁移：临时维护页面恢复后哪些残留信号需要核对
先给结论：临时维护页面撤下后，最该核对的不是首页能不能打开，而是那些被维护模式“掩盖”过的残留信号——缓存层、重定向链、抓取响应和站点地图是否仍指向旧主机或旧状态。只有当这些信号全部回到正常站点该有的样子，才能判断迁移真正完成。如果只看首页返回 200 就收工，很可能把问题留到几天后才暴露。
为什么维护页面恢复后反而更容易误判
维护模式期间，整站对爬虫和用户返回的是统一的状态码和内容，很多异常被这层“外壳”挡住了。撤下维护页后，流量恢复，但缓存、CDN、对象存储里可能还留着维护期间生成的副本，或者旧主机的 DNS 记录仍有残余解析。此时你看到的“正常”，可能只是某一层缓存的旧结果。
一个反直觉的现象是：恢复后抓取量不降反升，或者某些页面持续返回维护页的 HTML。前者可能是爬虫重新发现站点，后者则说明边缘缓存没有失效。两者原因不同，不能用同一个动作处理。
需要逐项核对的残留信号
响应头与缓存层
用 curl -I 检查首页和几个代表性内页，重点看状态码、Cache-Control、Age 和 X-Cache 一类头信息。如果 Age 很大，说明命中的是旧缓存；如果返回 503 或维护页特征内容，说明缓存没有随维护页撤下而失效。动作：先清 CDN 和页面缓存，再重复请求同一 URL，观察头信息是否变化。若清缓存后仍返回旧内容，问题在源站或 DNS，而不是缓存层。
重定向链与协议跳转
维护页常伴随临时跳转或 302。恢复后要确认这些跳转已经移除，而不是叠加成多级链。检查 http 到 https、带 www 与不带 www、旧域名到新域名这几组关系是否各自只跳一次。多级跳转不一定立刻报错，但会让抓取和判断变慢。
抓取响应与索引状态
robots.txt 的抓取限制不等于可靠的索引移除，维护期间如果用过 Disallow，撤下后要确认规则已删除，而不是只改了注释。站点地图不保证收录，所以不要用地图片段是否出现来判断恢复成功。更可靠的做法是抽查若干 URL 的实际响应内容，确认返回的是正常页面而非维护页残留。
站点地图与旧主机残留
站点地图里如果还列着旧主机的绝对地址，或者 DNS 仍有一条指向旧 IP 的记录，爬虫可能被引向已经停用的环境。核对方式是解析域名并比对当前主机 IP，同时检查站点地图中的 URL 前缀是否统一。HTTPS 不保证安全无漏洞或排名，所以证书正常不代表迁移无残留。
一个会让上述结论失效的反例
上面的核对逻辑成立的前提是：新旧主机使用同一域名，且维护页是站点级统一返回。如果迁移时改了域名，或者维护页只覆盖部分目录，那么“恢复后”的判断基准就不同——旧域名的重定向、新域名的抓取响应、以及两套站点地图需要分开核对。此时若仍按单域名思路检查，会漏掉跨域名的残留信号。先确认迁移是否涉及域名变更，再决定用哪套核对清单。
假设例子：如何用一组证据区分两种解释
假设撤下维护页后，某内页持续返回维护页内容。解释 A 是边缘缓存未失效；解释 B 是源站仍处于维护状态。区分方法：直接请求源站 IP 并带上 Host 头，绕过 CDN。如果源站返回正常页面，则偏向 A；如果源站也返回维护页，则偏向 B。动作：按结论分别处理——清缓存或检查源站维护配置。这个对比只用来说明判断方法，不代表任何真实项目结果。
下一步动作
完成上述核对后，把仍异常的项按“缓存层、跳转层、源站层”归类，一次只改一层并复测。若某层修改后异常消失，记录该层为本次迁移的残留点；若修改后无变化，说明原因在更靠后的层，继续向内排查。只有当你绕过所有中间层、直接拿到源站的正常响应，并且各层头信息一致时，才能认为维护页残留已清理完毕。
