同ip网站：临时维护页面恢复后哪些残留信号需要核对，先核对响应头：200 状态码不等于维护逻辑已撤
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7b30f2045a52.html
📄
同ip网站：临时维护页面恢复后哪些残留信号需要核对，先核对响应头：200 状态码不等于维护逻辑已撤
临时维护页恢复后，最该核对的是那些“看起来已恢复、实际仍被旧状态覆盖”的残留信号。先别急着重新提交或改代码，按下面顺序检查响应头、缓存、HTML 与日志，才能分清是服务器已放行、还是中间层仍在拦截。
先核对响应头：200 状态码不等于维护逻辑已撤
维护页常见做法是让所有请求返回 503 并带 Retry-After。恢复后如果只删掉页面模板，而入口脚本、反向代理或 CDN 规则仍返回维护响应，就会出现“浏览器看到正常页面、爬虫仍拿到 503”的反常结果。此时应分别用带正常 UA 和爬虫 UA 的请求对比响应头，重点看状态码、Retry-After、Cache-Control 和 Location 是否一致。
如果两个 UA 得到的响应头不同，说明拦截发生在边缘层或 UA 判断逻辑，而不是源站内容本身。下一步应去边缘配置里找维护开关，而不是继续改页面。
再核对缓存层：旧维护响应可能仍被缓存
维护期间返回的 503 或跳转页，可能被浏览器、CDN 或中间代理缓存。恢复后你本机看到正常，是因为本地缓存过期了；其他地区或爬虫仍拿到旧响应。可区分的证据是：同一 URL 在不同网络、不同缓存节点返回的状态码不一致，且响应头里带有较长的 max-age 或 s-maxage。
处理动作是先在边缘层对维护路径执行一次精确清除，再重新请求同一 URL。若清除后状态码统一变为 200，说明残留来自缓存；若仍有个别节点返回 503，则要回到上一节检查边缘规则是否真正关闭。
核对 HTML 与跳转残留：页面内容恢复不代表入口恢复
维护页常伴随临时跳转，比如把首页 302 到 /maintenance.html。恢复时如果只删了跳转页面、没删跳转规则，用户会看到 404 或循环跳转。逐项检查以下位置：
- 入口脚本或中间件里是否还有维护判断分支；
- 服务器配置里是否还有针对维护路径的
rewrite或return； - HTML 中是否残留指向维护页的
canonical或meta refresh； - 站点地图或导航里是否还挂着维护页链接。
如果 canonical 仍指向维护页，即使正文已恢复，搜索引擎也可能把维护页当成规范版本。修正后应重新抓取该 URL 并确认返回的 HTML 中不再出现维护页地址。
核对 robots.txt 与站点地图：抓取限制不等于索引移除
维护期间有人会临时在 robots.txt 里加 Disallow: /，恢复后忘记删除。这会阻止后续抓取，但不会移除已经建立的索引；反过来，删掉 Disallow 也不保证旧维护页立即从索引消失。站点地图同理，把维护页从地图里去掉，不等于搜索引擎已经放弃该 URL。
可区分的原因是：抓取工具报告“被 robots.txt 阻止”属于抓取层问题，而搜索结果里仍出现维护页摘要属于索引层问题。两者需要分别处理，不能靠一次提交解决。
最后用日志确认：请求归零不能单独证明恢复正确
恢复后如果维护页访问日志突然归零，可能表示跳转已撤，也可能只是缓存命中、爬虫降频或监控探针换了目标。要结合来源 IP、UA、状态码和请求路径一起看。假设你观察到维护页请求从每小时若干次降到零，同时正常首页请求上升，这更支持“跳转已撤”；若两者都下降，则可能是抓取整体减少，需要继续观察而不是立即判定完成。
把上述检查结果记成一张对照表：响应头、缓存状态、HTML 残留、robots 与站点地图、日志趋势各一行，每行写明“已核对/待处理”。只有全部行都指向同一结论时，才能把这次维护恢复视为结束；否则按仍未通过的那一行继续排查。
