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

404状态码 - 短横线排除缓存假象的协作清单

要排除缓存造成的假象，核心做法是：先用带随机查询串的请求绕开缓存，再对比不同网络、不同工具和不同账号看到的响应，最后回到服务器日志确认返回的究竟是真实的404还是被缓存下来的旧结果。只有多个独立来源都指向同一个状态码，才能把结论交付出去。

先区分你看到的404来自哪一层

同一现象可能有多种解释，不要一看到404就断定页面已删除。常见来源包括：浏览器本地缓存、CDN或反向代理缓存、服务端应用缓存、搜索引擎结果页的旧快照。它们都可能让已经恢复的页面继续显示404，也可能让刚上线的页面被旧的404覆盖。排查顺序应从离你最近的一层开始，逐层向外确认。

可执行清单：每项都写清查什么、怎么查、结果说明什么

1. 查浏览器缓存。用无痕窗口或强制刷新重新访问同一URL。如果无痕下返回200、普通窗口仍是404，说明本地缓存是可能原因，需要清缓存后再验证。
2. 绕过缓存发请求。在命令行执行 curl -I "https://example.com/page?cachebust=20240101"。查询串每次换一个随机值。若返回200，说明原URL的404很可能来自缓存层；若仍返回404，缓存解释的权重下降。
3. 换网络和换设备。用手机流量、另一台电脑分别访问。若只有某一网络下是404，可能是该网络节点的缓存或代理问题，而非源站状态。
4. 查CDN或反向代理的缓存状态。看响应头中的 Cache-Control、Age、X-Cache 等字段。若 Age 大于0且命中缓存，说明返回的是缓存副本，需要按缓存键规则刷新或等待过期。
5. 查服务器访问日志。找到对应时间点的请求记录，确认源站实际返回的状态码。日志显示200而外部显示404，基本可定位为缓存或中间层问题；日志本身就是404，则要查页面是否真的不存在。
6. 分别核查不同搜索引擎。不同搜索引擎的抓取与缓存机制不同，一个平台显示旧404不代表其他平台同样如此。应分别用各自的抓取测试或URL检查工具核对，不要用一个平台的结果推断全部。

协作交付时怎么记录，减少返工

多人协作最容易返工的地方，是每个人只写“我这边看是404”。交付记录应包含：完整URL、请求时间、使用的网络或工具、带不带缓存绕过参数、看到的响应码与关键响应头。这样下一位同事可以直接复现，而不是重新猜一遍。若结论是缓存问题，还要写清是哪一层缓存、依据是什么、下一步由谁清理或等待。

容易混淆的边界

robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取行为，不能替代状态码判断。站点地图不保证收录，提交了也不代表页面会立即被访问。HTTPS 不保证安全无漏洞或排名。这些机制与缓存假象不是一回事，排查404时不要把它们混进结论。判断缓存是否清除，最终仍要回到源站日志和独立请求的响应码。

下一步：挑一个当前显示404的URL，按上面清单逐项记录一次，把“哪一层缓存、依据是什么”写成一句话结论，再交给同事复核。