流量来源统计方法：被删除页面的数据应怎样保留在历史对比中
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6593764c8333.html
📄
流量来源统计方法：被删除页面的数据应怎样保留在历史对比中
被删除页面不应从历史对比里直接消失，而应保留为“已删除”状态的历史记录：把删除前的最后一份站内统计、搜索端报告和日志快照按同一口径归档，并在后续对比中把它单独标记，而不是继续当作活跃页面参与排名变化计算。如果缺少完整数据或后台权限，最小动作是至少保留删除日期、原URL、删除前最后一次可获得的来源构成，以及删除原因；这些信息能支撑“该页退出后总量如何变化”的判断，但推不出“删除直接导致了多少流量损失”。
先明确一个假设情境：删除后总量下滑，问题出在哪
假设某站点在三月下线了一批旧内容页，四月总流量比三月下降。团队想判断这是删除造成的，还是季节性波动或统计口径变化。此时若直接把这些页面从报表中剔除，历史对比会失真：三月包含它们，四月不包含，下降幅度被系统性放大，后续任何归因都建立在错误的基数上。
正确做法是保留两条时间线。第一条是“全站口径”，删除页的历史数据继续计入，只是标记状态；第二条是“活跃页口径”，仅统计未删除页面。两条线同时看，才能区分“总量因页面减少而下降”和“单页效率下降”这两类完全不同的原因。
删除前必须冻结哪几类数据
删除动作一旦执行，站内统计往往随之断流，搜索端报告也可能因URL失效而停止累积。因此要在删除前完成一次快照，按来源分层保存：
- 站内统计：该页在删除前一个完整周期（建议覆盖一个自然月或一个完整业务周期）的访问量、入口来源构成、平均停留与跳出。
- 搜索端报告：该URL获得的展现、点击及主要查询词，导出为静态文件而非依赖后台留存。
- 服务器日志：删除前一段时间的请求记录，用于核对站内统计是否遗漏了被过滤的访问。
- 元信息：原URL、标题、发布时间、删除日期、删除原因（合并、过期、迁移或纯清理）。
这四类数据口径不同，第三方估算、搜索端报告与站内统计对同一页面的计数本就不一致，归档时要标注各自来源，不能混成单一数字。
归档后怎样放进历史对比
把快照写入一张独立的“已删除页面”表，字段与活跃页报表对齐，但增加状态列和删除日期列。做月度或季度对比时，按以下顺序操作：
- 先算全站总量同比或环比，删除页数据保留在内，观察整体趋势。
- 再算活跃页口径，把已删除页面排除，观察剩余内容的真实变化。
- 最后单独列出已删除页贡献的流量差额，作为解释两条线差距的说明项，而不是损失结论。
如果某页被合并到新URL，应在快照中记录目标URL，并在对比时把新旧页视为同一内容的前后两段，避免同一批流量被重复计算或凭空消失。
缺少权限时能做什么，不能推出什么
没有后台导出权限或日志访问权时，仍可执行的最小动作是：用公开可查的页面存档、内部沟通记录或内容管理系统里的编辑历史，固定删除日期与原URL，并记录当时可见的来源构成（例如从站内报表截图或同事留存的文件中获取）。这份记录不完整，但足以防止历史对比中出现“这段数据完全空白”的断裂。
需要警惕的是，请求量或某项统计归零，并不能单独证明删除处理正确，也不能证明该页此前没有价值。归零还可能来自抓取频率变化、统计脚本调整、缓存失效或权限变更。把归零当作删除效果的证据，是把统计现象误当因果。
同理，第三方估算流量、搜索端报告与站内统计三者口径不同，不能靠其中任一指标单独还原搜索算法对删除页的处理方式。归档的目的是保留可核查的证据链，让后续诊断有据可依，而不是给删除行为下一个确定性结论。
一个可复用的判断顺序
遇到“删了页面之后历史对比怎么做”的问题，按这个顺序走：先冻结快照，再分全站与活跃页两条线，然后把删除页作为独立说明项而非损失项，最后检查归零现象是否还有其他合理解释。做完这几步，下一步无论是评估删除决策还是排查其他流量异常，基数都是干净的。缺少完整数据时，保留最小记录并明确标注缺口，比强行补齐一个看似完整的数字更可靠。
