报表里六月以前的数据不见了，先查统计还是先查收录

报表里六月以前的数据不见了，先查统计还是先查收录——先查报表侧。平台侧的数据缺陷并不罕见，十月发布的站长月报里就有一条被确认的问题：索引报表缺失六月以前的旧数据。这类问题的特征是「历史段整块消失，近期数据正常」，而站点侧的收录异常通常表现为新增页面进不去、覆盖范围逐渐缩小，两者形态不同。看到旧数据断档就动手改站点，是这类排查里最容易白做功的一种。

先排除报表侧故障

第一步是二次核对，用同口径再看一次：换一个报表模块看同期数据是否仍在，换一台设备或另一个账号确认不是界面筛选条件所致，再把日期范围拉到更早，看断点是整齐落在某月首日还是零散分布。断点整齐、跨模块一致、只影响历史段，这三条同时成立时，基本可以判断是报表侧的问题。

第二步是查是否已有公开说明。站长月报与官方帮助页会记录这类已知问题，例如索引报表漏旧数据这类条目，以及同期上线的新报表功能。看到公告就不要改站点：等平台修复后数据回补，中途的任何「补偿动作」都会让后续复盘失真。

第三步是做旁证留档。报表之外，站点自身的后台数据、抓取日志与接口读数都可以作为对照。把断档窗口的起止日期与观察到的现象写成一条记录，方便修复后判断是否真的补齐。

再核站点侧的收录与推送

只有当报表侧被排除后，才进入站点排查。顺序仍然由外而内：先看站点地图是否仍然可访问、条数是否与当前内容量匹配，站点地图应随内容增删自动更新，手工维护的旧图最容易在改版后失真；再看主动推送通道是否仍在工作，新内容没有推送时，收录滞后会表现为「近期页面缺席」，这与「旧数据消失」是完全相反的形态。

接着核对 robots 配置与页面可达性，历史页面若被批量改为不可抓取或返回异常状态，报表里的旧数据确实会减少，这属于站点侧原因，需要按地址逐条核对而不是整批回滚。

生成式表现数据和传统数据不同表

新上线的生成式表现类报表与传统的展示、点击报表不是同一张表，口径也不同：前者统计的是内容在生成式回答特性中的出现情况，样本窗口和起始日期通常晚于传统报表。把两类数据放在同一个趋势里比对，很容易得出「旧数据丢了」的误判——实际上是新生成的报表根本没有那么长的历史。排查时先确认自己在看的是哪张表，再看数据起止范围。

留档比对的做法

把核对做成固定动作，比一次性追查更省事。按周或按月导出一份报表读数存档，字段固定；同时通过接口文档调用列表与详情类接口，把后台的文章数、收录相关配置项读数存成同日快照，两边口径一比就能看出问题在平台侧还是站点侧。API 调用得到的站内数据不受外部报表故障影响，是天然的对照面。出现异常窗口时，在存档里追加一条说明：现象、起止时间、已排除的可能、待观察项。修复后回补与否，一看便知。

常见问题

旧数据断了，要不要重新提交站点地图补救？ 先别。若断点整齐且只影响历史段，属报表侧故障，重复提交不会改变结果，反而会在抓取日志里留下无意义的波动。

怎么确认是平台故障不是自己改错了？ 三条判据同时成立即可高度怀疑平台侧：断点落在整月边界、多个模块同时看不到该时段、同期有公开说明或他人同样反馈。缺一条再考虑站点侧。

新报表看不到半年前的数据，正常吗？ 正常。新生成的报表有起始日，历史段不存在，不能与传统报表按同一时间轴比较。