网站恶意代码检测：被删除页面的数据应怎样保留在历史对比中
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a24b39a0c74a.html
📄
网站恶意代码检测：被删除页面的数据应怎样保留在历史对比中
被删除页面的数据要保留在历史对比中，核心不是继续让原网址返回内容，而是把“删除前最后一次可信快照”与“删除动作、删除时间、删除原因”绑定成一条可追溯记录。只留一份页面副本往往不够，因为对比时无法区分是恶意代码被清掉、内容被正常下架，还是抓取口径变化。下面用一个假设情境说明遗漏条件与处理顺序。
假设情境：删掉页面后，历史对比为什么失真
假设某站点在检测到一批页面被注入恶意脚本后，直接删除这些页面，并只保留服务器上的最新备份。两周后复查，站内统计显示这些网址访问量归零，第三方估算流量也下降，于是判断“问题页面已处理完”。但此时要回答“恶意代码是否真的消失”“删除是否误伤正常内容”，却缺少删除前的页面级证据：备份可能已被覆盖，第三方估算只到目录级，搜索引擎报告只说明抓取异常，三者无法拼出被删页面的原始状态。
这里遗漏的条件是：删除动作本身没有留下可对比的页面快照和变更日志。访问量归零可以解释为页面已删除、跳转生效、抓取减少、统计代码未触发，甚至统计口径切换，不能单独证明恶意代码处理正确。因此，历史对比要保留的不是“流量数字”，而是能互相校验的证据链。
要保留的三层数据：页面快照、变更记录、抓取证据
第一层是页面快照。删除前应对每个受影响网址保存可离线打开的响应正文、HTTP 状态、响应头和最终 URL。快照要带采集时间，并与网址一一对应。若页面包含动态渲染内容，还应保存渲染后的 DOM，但必须注明采集方式，避免把不同口径的快照直接对比。
第二层是变更记录。至少记录删除人、删除时间、删除原因、原网址、替代网址或 410/404 选择。若删除是为了清除恶意代码，还要记录注入位置、疑似入口和清理动作。没有这层记录，后续只能看到“页面没了”，无法判断删除是否覆盖了全部风险。
第三层是抓取证据。保留搜索引擎报告、站点日志和第三方估算的原始导出文件，并标注各自口径。搜索引擎报告通常反映其抓取与索引状态，站点日志反映服务器实际收到的请求，第三方估算多为模型推算，三者不能互相替代。对比时应先对齐时间窗口和网址范围，再讨论差异。
历史对比的正确对象：删除前快照对删除后状态
对比时不要拿“删除前流量”对“删除后流量”就结束。更可靠的做法是建立一张按网址排列的对照表，字段包括删除前快照哈希、删除前状态码、删除后状态码、删除后是否可访问、删除后是否仍被引用、日志中是否仍有请求。这样可以把“页面已删除”与“恶意代码已清除”分开验证。
实际动作可以这样落地：先冻结删除前快照，再执行删除，随后在固定时间点复查状态码和日志。若删除后原网址返回 404 或 410，且日志中不再出现对恶意脚本路径的请求，同时搜索引擎报告显示该网址逐步退出索引，这组证据比单看访问量归零更有说服力。若删除后仍收到对原网址的请求，下一步应检查外部链接、站点地图、内部链接和重定向链，而不是直接认定删除失败。
短例：一次对比如何影响下一步
假设某网址删除前快照显示页面底部有一段外链脚本，删除后状态码为 410。复查日志时发现，删除后一周内仍有请求命中该网址，但请求的是旧脚本路径。此时合理推断是：页面入口已移除，但脚本文件或缓存引用仍在。下一步应检查同目录资源、CDN 缓存和引用该脚本的其他页面，而不是恢复原页面。若日志中没有任何旧脚本请求，且快照哈希与清理后版本一致，才可以把该网址标记为“已删除且无残留引用”。这个判断只适用于该假设情境，真实站点需按自身日志和快照核对。
保留期限与最小可用记录
如果人力有限，优先保留最小可用记录：每个被删网址一行，包含原网址、删除时间、删除原因、删除前快照文件、删除前状态码、删除后状态码、最后一次日志命中时间、证据来源。快照文件可按日期和网址命名，避免只留“备份”这种无法定位的压缩包。
- 删除前快照必须与网址绑定，不能只保留整站备份。
- 删除原因要写成可复核的事实，例如“页面含未授权外链脚本”，而不是“有问题”。
- 删除后复查要记录状态码和日志，不能只截一张访问量归零的图。
- 第三方估算、搜索引擎报告和站内统计分别标注口径，对比时先对齐范围。
当这些记录齐备后，历史对比才能回答“删除了什么、为什么删除、删除后是否还有残留”。如果只保留访问量曲线，删除动作与恶意代码清除之间仍然是断开的，后续排查只能靠猜。把快照、变更记录和抓取证据一起留存，才是被删除页面进入历史对比的最低条件。
