SEO审计服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7a6feb0c7c43.html
📄
SEO审计服务：项目结束后历史文档需要保留到什么粒度
历史文档的保留粒度不是越细越好，而是按“能否独立复现一次结论”来定。若审计结论只服务一次改版、且后续不再追责或复用，保留到“结论+关键证据索引”即可；若结论会进入长期迭代、多人接手或需要向外部解释，则要保留到“原始抓取样本+判定规则+变更前后对照”这一层。判断标准是：换一个人、隔六个月，能否不靠口头补充就还原当时为什么这样判断。
先分清两种条件：一次性交付与可追溯交付
一次性交付通常发生在改版窗口很窄、审计只为某次上线服务的情况下。此时文档的核心任务是让执行方知道改什么，而不是让未来的人重建审计过程。可以只保留三类内容：结论清单、每条结论对应的页面或模板范围、以及判定时使用的规则版本。原始导出文件如果体积大、字段多，可以只留抽样页和字段说明，但必须在文档里写清楚抽样比例和抽样方式，否则后续看到结论会误以为它覆盖全站。
可追溯交付则出现在审计结论会被反复引用、多人接力或需要对外解释的场合。这时粒度要下沉到“证据单元”：每个问题至少保留一条可定位的证据，例如具体URL、抓取时间、响应状态、页面模板标识和判定阈值。动作上，可以按问题类型建立索引，把原始文件放在固定目录，文档只记录文件路径、字段含义和生成条件。这样做的结果是，后续有人质疑某条结论时，不需要重新跑一遍全站，只要按索引调出对应证据即可；下一步的复核成本会明显下降。
用“复现测试”决定保留到哪一层
一个可操作的判断方法是做一次复现测试：假设原审计人员已经离开，接手者只拿到你计划保留的文档，能否在半天内回答三个问题——这条结论覆盖哪些页面、当时依据什么规则判定、如果现在重跑需要哪些输入。如果三个问题里有两个答不上来，说明粒度偏粗；如果三个问题都能答上，但文档已经膨胀到没人愿意读，说明粒度偏细，应该把细节下沉到附件索引，而不是全部塞进主报告。
假设某次审计发现一批模板页存在重复标题问题。若只保留“重复标题若干”这一句，接手者无法判断是模板层问题还是内容层问题，下一步可能误改内容。若保留到“模板标识+抽样URL+判定规则+抓取日期”，接手者可以先核对模板是否仍在使用，再决定是改模板还是改内容。这个例子说明，粒度影响的不只是存档完整性，还直接影响下一步动作的方向。
不同角色的分歧要转成可核对的项目
项目结束后常见的分歧是：执行方认为结论已经落地，复核方认为证据不足，管理层只关心是否还有遗留风险。三种角色对“保留”的理解不同，容易各说各话。把分歧转成可核对的项目，可以这样做：先列出争议结论，再为每条结论标注证据位置、判定规则和当前状态，最后约定一个复核动作，例如抽查若干页面确认问题是否仍然存在。动作的结果会决定下一步：如果抽查发现结论仍成立，就保留对应证据并进入修复队列；如果结论已不成立，就标记为已失效并说明失效条件，而不是直接删除。
保留期限与删除条件要写进文档本身
粒度之外，还要写清楚保留多久、什么条件下可以删。常见做法是按用途分档：结论摘要长期保留，原始抓取文件按项目周期保留，临时对比文件在复核完成后删除。删除条件不能只写“项目结束”，而要写成可判断的条件，例如“连续两次复核均未再出现同类问题，且相关模板已下线”。这样做的结果是，后续清理文档时有依据，不会因为某个人觉得没用就误删关键证据。
需要说明的是，抓取量下降、某类问题数量归零，都不能单独证明处理正确。它们也可能是抓取范围变化、规则调整或页面结构改动带来的结果。因此，保留文档时要把当时的抓取范围和规则版本一并留下，否则后续看到数字变化会得出错误结论。
一个可执行的保留清单
- 结论层：每条结论一句话，注明影响范围和优先级。
- 证据层：抽样URL、抓取日期、判定规则版本、模板或目录标识。
- 规则层：阈值、排除条件、字段含义，避免后人误读。
- 变更层：修复前后的对照记录，只保留能说明差异的最小集合。
- 失效层：写明什么条件下可以删除或归档，避免无限期堆积。
如果只能记住一个原则：保留粒度以“能否独立复现结论”为下限，以“是否还有人会读”为上限。超过上限的细节放进附件索引，低于下限的结论不要单独存档。按这个原则执行，项目结束后的文档既不会变成无人敢删的负担，也不会在需要解释时找不到依据。
