自定义404错误页：临时维护页撤下后残留信号核对与取舍
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eb153a079f80.html
📄
自定义404错误页：临时维护页撤下后残留信号核对与取舍
临时维护页撤下后，真正需要核对的不是“页面是否恢复”，而是维护期间留下的响应头、缓存指令、状态码和站内链接是否还在影响自定义404错误页的判断。若维护页曾以200状态返回，撤下后应优先核对原URL是否恢复为404或410；若维护页以503加Retry-After返回，撤下后应核对缓存层是否仍保留旧响应。两种做法的取舍取决于维护页是否曾长期替代错误页，以及缓存和CDN是否参与。
先判断维护页撤下后残留信号属于哪一类
残留信号通常分三类：状态码残留、缓存残留、链接与入口残留。状态码残留指维护页撤下后，原本应返回404的URL仍返回200；缓存残留指CDN或反向代理仍返回维护页内容；链接与入口残留指站内导航、站点地图或外部链接仍指向维护页地址。三类信号的核对顺序不同，不能只靠一次抓取就下结论。
如果维护页只是短时间替代首页，且没有对全站返回200，那么撤下后重点核对首页和关键入口即可。如果维护页曾以通配方式接管所有路径，撤下后必须逐类核对：已删除内容、拼写错误路径、旧参数URL、静态资源路径。自定义404错误页的职责是接住这些路径，而不是继续显示维护公告。
条件一：维护页曾用200返回，撤下后优先核对状态码
当维护页以200状态返回时，搜索引擎可能把维护内容当作正常页面处理。撤下后，如果原URL仍返回200，自定义404错误页就不会被触发。此时应做一次实际动作：选取维护期间被替代的典型URL，分别用带和不带参数的请求查看响应状态。若返回200且内容为维护公告的缓存副本，下一步应清理缓存并确认源站返回404或410。
选择清理缓存还是直接改源站，取决于缓存层级。若源站已返回404但边缘节点仍返回200，优先清理边缘缓存；若源站本身仍返回200，应先改源站逻辑，再清理缓存。例外是：某些URL本身有合法内容，只是维护期间被临时替换，这类URL撤下后应恢复原内容，而不是让它进入自定义404错误页。
条件二：维护页曾用503返回，撤下后优先核对缓存与重试指令
503加Retry-After的本意是告诉抓取方稍后再来，但它不保证抓取方一定遵守，也不保证缓存层不保留旧响应。撤下维护页后，应核对响应头中是否仍带有维护期间设置的Cache-Control、Retry-After或自定义标记。如果这些头仍存在，自定义404错误页可能被缓存层覆盖，用户看到的是维护页而不是错误页。
实际动作是：先检查源站响应头，再检查CDN回源后的响应头。若两者不一致，说明边缘缓存未刷新。此时应清除相关路径的缓存，并确认下一次请求返回404或410。例外是：若维护页撤下后站点仍处于灰度发布阶段，部分节点返回维护页可能是预期行为，这时不应把自定义404错误页当作唯一兜底，而应保留明确的维护状态说明。
核对站内链接、站点地图与外部入口的残留指向
维护页撤下后，站内导航、页脚、站点地图和外部链接可能仍指向维护页地址。若这些入口继续返回200，自定义404错误页不会被触发，但用户会进入一个已经失效的维护公告。应核对站点地图中是否仍包含维护页URL，以及站内搜索和分页是否仍输出该地址。站点地图不保证收录，但包含失效维护页地址会增加核对成本。
若发现残留指向，应把入口改回目标页面或删除。对于已删除内容，应让入口指向自定义404错误页或返回410。对于仍有价值的旧URL，应设置301到新地址，而不是让它进入404。这个动作的结果会直接影响下一步：若入口仍指向维护页，后续的状态码核对会被掩盖；若入口已修正，才能准确判断自定义404错误页是否真正生效。
用一组假设例子说明核对顺序与代价
假设某站点在维护期间对所有路径返回200并显示维护公告，撤下后只恢复了首页。此时若直接检查自定义404错误页，可能发现它没有触发，因为其他路径仍返回200。正确顺序是先核对全站状态码，再核对缓存，最后核对入口。代价是核对时间更长，但能避免把缓存残留误判为404页失效。
另一种假设是维护页用503返回，撤下后源站已恢复404，但CDN仍缓存503。此时若只核对源站，会误以为问题已解决；用户侧仍看到维护页。应同时核对源站和边缘节点，并清除缓存。例外是：若CDN缓存规则不允许清除单条URL，只能等待过期，这时应在监控中记录该路径，而不是反复修改自定义404错误页。
核对完成后保留哪些信号作为后续判断依据
核对完成后，应保留三类记录：撤下时间点、关键URL的响应状态、缓存清理范围。这些记录用于区分“维护页残留”和“自定义404错误页本身失效”。若后续再次出现异常，可先比对这三类记录，而不是重新全站扫描。若维护页曾长期替代错误页，还应核对日志中404和410的数量变化，但数量归零不能单独证明处理正确，因为可能是抓取减少或缓存未刷新。
最终判断标准是：原应返回404的URL在源站和边缘节点都返回404或410，且自定义404错误页内容可见；原应保留的URL恢复原内容或正确跳转。满足这两个条件后，维护页残留信号才算清理完毕，后续再调整自定义404错误页才有可靠依据。
