SEO监控服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8f9eb3d88571.html
📄
SEO监控服务：项目结束后历史文档需要保留到什么粒度
项目结束后的历史文档，保留粒度应当以“能否独立复现一次异常判断”为下限，以“能否支撑下一轮交接”为上限。也就是说，原始抓取数据、日志和临时导出文件通常不必全量长期保存，但每次监控结论所依据的指标口径、时间范围、样本页面和判定阈值，应当保留到可追溯的程度。如果缺少完整数据或权限，至少先保留一份结论索引和口径说明，而不是把整个项目目录原样封存。
先拿一个页面做粒度测试
假设你手边有一个已结束项目的监控页面，比如某栏目在三个月内被标记为“标题重复率上升”。不要先问“文档要不要全留”，而是拿这一个页面做测试：只保留最终报告，三个月后你还能不能判断当时是哪些URL被算作重复、重复是按完全匹配还是近似匹配统计、样本量是多少。如果答案是不能，说明粒度太粗。反过来，如果把每次抓取的HTML快照、全部中间CSV和脚本运行日志都留下，占用会迅速膨胀，而且大部分文件在复盘时不会被打开。
一个可执行的判断方法是：让一个没有参与该项目的人，只依靠保留的文档，回答三个问题——异常发生在哪个时间窗、依据哪一批页面、按什么规则判定。能回答，粒度就够；不能回答，就需要补一层。
建议保留的三层粒度
- 结论层：每期监控的最终结论、异常清单、处理动作和关闭原因。这一层必须保留，且建议用统一字段记录，便于跨项目检索。
- 口径层：指标定义、筛选条件、样本范围、对比周期和阈值。没有这一层，结论层在换人后就无法解释。
- 证据层：原始导出、抓取快照、日志和脚本。这一层按需保留，通常只保留异常样本和关键时间点，而不是全量。
三层之间的关系是：结论层回答“发生了什么”，口径层回答“凭什么这么判断”，证据层回答“能不能重新算一遍”。项目结束后，优先保证前两层完整，第三层可以按异常等级抽样保留。
缺少数据和权限时的最小动作
如果项目结束时你已经失去后台权限，或者原始数据已经被清理，仍然可以做一件最小动作：把现有报告、邮件、聊天记录和导出文件中能确认的信息，整理成一份口径说明。具体包括监控覆盖的页面范围、统计周期、使用的指标名称，以及哪些结论当时无法验证。这份说明不需要重新抓取，也不需要访问原系统。
做完这一步后，下一步的影响是：后续接手的人可以判断哪些结论仍可引用，哪些必须重新验证。需要明确的是，历史请求量或抓取量归零，不能单独证明监控对象已经消失，也可能是权限回收、任务停跑、统计口径变更或数据被归档造成的。因此，不要把“没有新数据”直接写成“问题已解决”。
保留期限与删除边界
保留多久取决于文档的用途，而不是统一年限。如果这些文档只用于内部复盘，结论层和口径层保留到下一次同类项目结束即可；如果涉及对外交付或合同约定，应按约定执行。证据层中的大体量原始文件，可以在确认结论层和口径层完整后删除，但删除前应记录删除了什么、删除依据是什么。
一个常见的取舍是：保留全部原始快照，还是只保留异常样本。前者适合需要反复重算的场景，后者适合只需要解释历史结论的场景。两种选择都成立，区别在于你是否还需要用同一批数据回答新问题。如果不确定，先保留异常样本和一份样本清单，这比全量封存更容易维护。
交接时用一份索引代替目录树
项目结束后，最容易被忽略的不是文件本身，而是文件之间的对应关系。与其保留一个层级很深的目录树，不如做一份索引：每条结论对应哪个口径、哪个时间范围、哪份证据文件。索引可以很短，但必须能让接手人从结论反查到依据。
如果只能保留一样东西，保留这份索引和口径说明，而不是最大的那个数据文件。因为数据文件没有上下文就无法解释，而索引能告诉你还需要什么、缺什么、哪些结论不能直接沿用。
