用途：当 GSC 仪表盘出现异常变化时，traffic-anomaly 提供可重复的核查手段，将近期已定稿的 GSC 窗口数据与观测基线在点击量和展现量上做对比，用统计显著性判断是否需要深入调查。它不定位原因、不诊断站点缺陷，也不证明外部事件影响了该资源。
主要能力：输出 anomalies 列表，包含指标名、基线与对比日期、均值与总量、percentChange、zScore、significanceMethod、direction 和 significant。零基线导致的空百分比与零变化不同；outside-flat-baseline 处理观测基线无方差的情况，且仍只描述所提供的数据。
使用方式：MCP 下先调用 seo_list_reports 并传 {"category":"diagnosis"}，再用 seo_describe_report 传 {"id":"traffic-anomaly"} 选择窗口，然后调用 seo_run_report，示例参数为 {"id":"traffic-anomaly","params":{"site":"sc-domain:example.com","days":90,"recentDays":7,"refresh":false}}。CLI 使用同一报告定义：seo reports describe traffic-anomaly --json 与 seo reports run traffic-anomaly --params '{"site":"sc-domain:example.com","days":90,"recentDays":7,"refresh":false}' --json。发现 schema 目前对这些窗口字段只暴露宽泛的数值类型，应使用合理的正整数天数。
解读与限制：先看覆盖率，确认请求日期、预期与实际天数、缺失天数、无效行、重复行和状态；部分覆盖会改变基线，必须写入结论，rows 不是质量结论。若变动显著且覆盖充分，可继续做页面与查询的 segment-impact，并检查站点变更、季节性、索引和跟踪；若正常则持续监控，不要强行叙事。没有独立证据时，不得将其结论称为惩罚、算法更新、恢复或因果诊断。