Search Console六月那几天的数据没了，官方说不回填

摘要：9月11日早上打开页面收录报表，6月里有好几天是空的。官方的回应只有一句要紧话：那段时间数据延迟，报表没有更新，而收录数据不回填。也就是说那几天永久没有了。真正麻烦的不是缺，是缺得看不出来——图上的空白和一串零长得完全一样，而官方文档里还写着导出成文件时不可用的值会写成0。同一周里另外两次数据异常，一次自己补上了，一次只是一夜之间的显示错误，三件事在界面上的样子几乎无法区分。

9月11日一早，不少人发现谷歌页面收录报表的曲线左边缺了一块：6月里连着好几天没有数据。这不是某个站的问题，所有资源都一样。

谷歌搜索关系团队的John Mueller给了个说法，大意是这段大概来自6月里数据延迟的那段时间，那个时期页面收录报表没有更新过，所以那几天就是没有数据；而且收录数据不回填。他还补了一句会再找团队确认。

这句话里真正该被划重点的是不回填三个字。数据延迟是常事，延迟之后补上也是常事，但这一次明说了不补。你的站在6月那几天到底被收录了多少页、有多少页掉进已抓取未收录，这个问题从此没有答案，不是查不到，是不存在。

这件事为什么比听上去严重？

先把它和大家熟悉的那几种数据限制分清楚。本站以前拆过Search Console的三大数据黑洞，那讲的是1000行上限、网址分组、阈值过滤——共同点是数据在平台那边存在，只是没全给你。这一次不一样：那几天的记录本身就没写进去。前者是取数问题，后者是存数问题，后者没有任何绕行方案。

再对照另一件事。点了验证修复到底验证了什么那篇讲的是动作与结果之间的错位，你按了按钮但复核不一定发生。这一次连动作都没有，只有一段安静的空白。

最要命的是空白的呈现方式。如果报表在那几天画一段灰色的、写着无数据的区间，事情就简单了。实际上曲线只是低下去，然后回来，和真正掉到零长得一模一样。

页面收录报表本来是用来干什么的？

按这份报表的官方文档，它的职责是告诉你站内有多少网址被编入了索引、多少没有，以及没有的原因分成哪些类。它是排查收录问题的起点，几乎所有页面不被收录时的急救流程都是从这张图开始往下走的。

正因为它是起点，它的历史曲线才特别要紧。判断一次收录下滑是从哪天开始的，靠的就是把曲线往回拉。曲线上少了几天，等于起点少了几块砖。

图上那段空白和一串零，怎么分得清？

分不清，这就是问题。而且官方文档里有一条规则让它更难分。

在效果报告的数据口径说明里写着一句：报表中显示为波浪号或者短横线的值，也就是不可用或者不是数字的那些，在下载下来的数据里会变成0。

把这句话摊开：界面上那个符号至少还在说我这儿没有这个数；一旦你把它导出成表格、丢进数据仓库、接进看板，它就变成了一个货真价实的0。缺失在传递过程中被静默地转成了一个数值，而且是一个语义完全相反的数值。

同一份文档里还有一条容易读错的规则：报表上那个最后更新日期，指的是报表拥有任何数据的最后一天。注意是任何数据，不是完整数据。某一天只要有一条记录进去，这个日期就会往前走，而那一天的数据是不是齐的，它不负责告诉你。

这两条规则叠在一起，结果就是你的时间序列里可以同时存在三种东西，而它们在图上是一个样子：真实的零、因为延迟还没写进去的空、以及永远不会写进去的空。

同一周里三次数据异常，为什么只有一次补回来了？

把9月上旬发生的三件事放在一起看，这条线索会清楚很多。

第一件：9月8日夜里的那次显示错误

那天晚上有一段时间，大量页面在报表里从已编入索引变成了已抓取但未编入索引，首页都中招。有人立刻在社交平台上问是不是出事了，也有人跟着确认自己看到同样的现象。一个多小时后它自己恢复了。

Mueller后来确认这是一次短暂的故障，在那些帖子发出来之前就已经在夜里修复了。他还说了一句挺实在的话：如果索引本身工作正常，只是报告方式不同，那就没什么坏掉；首页的收录情况很容易自己复核一下，不是每一个潜在问题都值得放下手头所有事去救火。

第二件：谷歌商家资料的9月数据整月空着

差不多同一时间，商家资料后台的洞察报表整个9月都没有数据。通常这类报表延迟几天是正常的，但那次已经到了月初第8天还是一片空白。9月11日它恢复了，数据补齐。

第三件：就是6月那几天，永久缺失

三件事放在一起，得到的是一张很不舒服的对照表：现象几乎一样，结局完全不同，而且在事发当时，你没有任何办法判断自己碰上的是哪一种。

第三件事最刺眼的地方在于时间差：缺口发生在6月，被大范围注意到是在9月。中间隔了三个月，没有告警，没有横幅提示，没有任何人被通知。

正好在那一刻拉接口的人，拿到的是什么？

9月8日那次夜间故障还有个后续，我觉得比故障本身更值得说。

有人当时正好用接口批量拉了自己管理的一批资源的收录数据，拉回来的结果是大量页面从已编入索引变成了已抓取但未编入索引，小站里最高有两成的页面中招，而且集中在偏薄和偏老的页面上。这个结论看起来非常像一次算法调整。实际上它只是一次持续一小时的显示错误，那批数字是在错误窗口里取到的。

这件事的可怕之处在于，取数这个动作把一个瞬时状态永久地写进了自己的记录。平台那边一小时后恢复了，而你的数据仓库里那一天就是这个样子，除非你记得回头重跑。等到半年后有人翻出这张表做趋势分析，没有任何字段能告诉他当天平台正在闹脾气。

做过网址检查接口批量监控的人对这个场景应该不陌生。定时任务的本质就是在某个固定时刻取一次快照，而它取到的东西是否可信，取决于那一刻平台那边的状态，这件事脚本无法感知。

这类坑的形态和用户扫完一整屏商品却一个都没点开那件事是反着的：那一次是真实发生的行为在报表里等于没发生，这一次是没发生的事情在报表里被记成了发生。两种错误都不会报错，也都不会有人通知你。

官方文档里还有两条限制值得一并记住。接口的数据说明写着：搜索分析方法每天每种搜索类型最多返回5万行，按点击量排序；而且如果你想要更细的维度，比如带上页面和查询，官方的原话是代价是丢掉一部分数据。

换句话说，你的历史记录从写下来的那一刻起就已经是有损的，而损在哪儿不写在数据里。

你自己这一侧，能自证到什么程度？

平台丢了一段，第一反应通常是从自己这边找补。我把这件事在自己的服务器上认真跑了一遍，结果比想象中难看。

访问日志能留多久？

这台服务器上跑着好几个站，nginx的访问日志按天轮转。查看轮转配置，保留份数写的是14。也就是说任何时刻手里最多握着14天的历史，再往前的自动删掉。

更让人清醒的是那份配置文件的头部注释：这套轮转规则是2026年8月29日才建立的，在那之前服务器上根本没有任何针对站点日志的轮转规则，日志一路累积到接近10GB，其中一个错误日志单文件2.6GB。

所以这台机器上关于本站访问的全部历史，起点是2026年8月29日晚上9点28分。谷歌那边6月的数据没了，我这边6月的日志也一条不剩。两边都没有，那几天就真的不存在了。

文件名上的日期，就是里面数据的日期吗？

不是，这一条我以前也想当然了。把15个日志文件逐个翻开看首尾两行的时间戳，得到的是下面这张表。

规律很清楚：名字里写着9月12日的那个文件，装的是9月11日凌晨3点07分到9月12日凌晨3点38分之间的请求。轮转发生在凌晨3点多，而且每天的具体时刻还会漂——从03:06到03:46，十五天里没有两天是一样的。

把所有文件合起来按自然日重新数一遍，结论是：这段时间里的每一个自然日，数据都横跨两个文件。唯一的例外是8月29日，因为那天正好是轮转规则建立的当天，只有晚上9点28分之后的1851行。

这就是那条原语在自家机器上的样子：我按天查，它按批次写，而批次的边界既不在午夜，也不固定。想统计某一天的完整数据，必须同时打开两个文件并且按时间戳过滤，只读一个文件会少掉三个小时左右的记录。

日期序列里的那个缺口，是丢了还是本来就没有？

这是本轮最有意思的发现。访问日志的文件名从20260830一路排到20260912，一天不缺。但是同一目录下的错误日志，序列是这样的：20260829、20260831、20260901一直到20260908、20260910、20260911、20260912。

20260830和20260909这两个日期不存在。

原因在轮转配置里：那份配置写了notifempty，按这个工具的手册页，它的意思是文件为空就不做轮转。那两天没有产生任何错误，于是没有文件被生成，于是日期序列里出现了两个洞。

问题来了：缺口的含义是那天没有错误，还是那天的错误日志丢了？光看目录列表，这两种完全相反的事实长得一模一样。想分清得去读配置，而配置和数据从来不放在一起。谷歌那边的情况和这个一模一样，只不过它的配置我读不到。

三层记录分别能撑多久？

把手头所有能当证据的东西列一遍，会发现留存窗口比想象中短得多。

效果报告那一行需要补一句：官方说明里写的是默认视图给最近三个月，日期范围可以自己往回拉，但拉得到哪里是另一回事。这张表里前三行是别人定的，后两行是自己定的——而自己定的那两行更短。很多人抱怨平台不给数据，转头一看自己的保留期只有两周，这就有点像埋怨银行不肯给二十年前的流水，而自己的账本每半个月撕一次。

第三方档案这条路我也试了，从本机和服务器两边都访问不了那个公共档案接口，请求直接超时。所以这条退路在我这儿是验证不了的，写在这里只是说明它不该被当成默认兜底。

那到底该自己长期留什么？

不是全都留，磁盘和心力都不允许。按能不能重建这条标准分三类：能从别处重建的不留原件，只留结论；不能重建又便宜的原样留；不能重建又贵的抽样留。

落到具体：搜索引擎抓取记录属于第二类，压缩后一天几百KB，留一年也不过几百MB，而它是唯一能独立复核收录情况的东西，把日志收上来做成可检索的样子之后价值会再翻一倍。慢查询日志属于第一类，本站测过攒了783MB而真正超过1秒的只有32条，留结论就够。完整响应体属于第三类，抽样即可。

这套判断落地成脚本并不难，用定时任务把备份、日志归档串起来一次写好能用很久，难的是先想清楚自己要往回看多远。

报表里哪些空是真的没有，哪些只是没写？

判断方法只有一条：找一个同期的、独立的第二来源去对。对得上就是真的没有，对不上就是没写进去。

对收录数据，用什么当第二来源？

最直接的是站点日志里Googlebot的抓取记录。一个页面在报表里显示为未编入索引，但你的日志里那几天它被抓了好几次，这两件事不矛盾，但如果整站的抓取量在那几天完全正常，而报表说一半页面掉出了索引，那多半是报表的问题。做这件事的前提是你手里有那几天的日志，而按上面那张表，这个窗口只有两周。

再退一步可以用站内检索运算符与后台数据的三源校准那套办法交叉核对，虽然运算符给的数字精度很差，但它至少是一条独立的通道，能把量级级别的错误挑出来。

对流量数据，什么时候该怀疑报表？

标准是同期的其他通道有没有一起动。如果自然搜索曝光掉了三成，而同期你的服务器日志里来自搜索引擎的请求量没变、独立访客没变、下单量没变，那就先怀疑报表。本站写过同一个推荐位两套报表算出相反结论，那件事的解法也是这个：先找第二把尺子，而不是先解释第一把尺子给的数。测量工具自己有盲区这件事也很常见，页面上近一半资源在性能监控里是一排零就是同一类毛病。

什么情况下不该急着解释？

异常只持续了几个小时、只出现在一个报表里、其他所有指标都正常——这三条同时成立的时候，最合理的动作是等一天再看。9月8日夜里那次如果有人当场写了复盘文档发给老板，第二天就得再发一封更正。多平台一起盯能省掉不少这种尴尬，三个搜索平台后台的分级诊断那篇里的做法是同一现象在两个平台同时出现才升级处理。

该怎么改自己的做法？

下面这几条是我自己这轮之后改掉的。

把留存期这件事从默认改成决定

日志保留14天是安装时的默认值，不是任何人认真选过的数字。真正该问的是：出了问题我需要往回看多久？对做SEO的站来说，一次核心算法更新的观察周期通常是四到八周，那么两周的日志就是不够的。把份数改到60天，代价是几个G的磁盘，比事后找不回来便宜得多。日志轮转的完整配置方法那篇里有各个参数的取舍。

取数的时候，把取数时刻也存下来

接口拉回来的每一行，除了业务字段，至少还要存三样：取数的时间戳、取数用的口径、以及这次请求返回了多少行。最后这一项尤其重要，因为5万行封顶是静默的，你只会拿到一个看起来很完整的结果。存了行数才能在事后发现某天正好顶格。

给关键指标加一条无数据的判定，而不是零的判定

大部分监控规则写的是数值低于阈值就告警。这条规则对缺失是失效的，因为缺失在导出之后就是0，0当然低于阈值，于是你会收到一条内容完全错误的告警：它会告诉你流量暴跌，而真相是数据没写。正确的做法是把无数据单独判一类，告警文案也分开写。监控告警体系那篇里的分级逻辑可以直接套。

在自己的时间线上标注断点

每一次平台侧的口径变更、故障、数据缺口，都在自己的数据表里留一行注记，字段就三个：起止时间、影响范围、当时的处置。这件事的价值在一年后才显现——本站拆过一条五年趋势线上的三处口径变更，当时能把三处都找出来，靠的就是有人当年留了记录。

别把不可核的数字写进对外结论

6月那几天的收录数据已经不存在，那么任何一份跨6月的同比报告，都必须在方法说明里写清楚这一段的处理方式：是剔除、是插值，还是照原样计入。这不是严谨性表演，是为了半年后有人拿这份报告做决策时，他知道哪一格不能信。本站拆过一份样本里根本没有非会员、结论却写给非会员看的调研，翻车的根源同样是没人回头看一眼分母是怎么来的。

这件事接下来会怎么演变？

有三个趋势值得盯着。

第一，报表的数量在涨，而每一份报表的口径说明都在自己那一页里。生成式AI的效果数据、商家资料的洞察、各种新展现类型，各有各的延迟规律和各自的补数规则，没有一处统一说明。本站把平均排名与生成式AI的计数规则并到一处读过一遍，光那一组就横跨五份文档。谁的口径最短、谁最容易缺，只能一页一页自己读。

第二，结果页本身在按地区分叉。欧洲那一版结果页9月8日已经改完，这意味着同一条曲线上不同国家的数据可比性也在变。缺口是时间上的洞，分叉是空间上的洞，两者叠加之后，一条全站总曲线能说明的事情越来越少。

第三，越来越多的人把平台报表直接接进自动化流程，中间没有人看一眼。自动化流程会悄悄走形这件事在AI工具铺开之后只会更常见，而缺失变成零这条规则，恰好是自动化最容易吃进去的那种错误。

说到底，这次的教训不复杂：你以为自己拥有一份连续的历史，其实你拥有的是别人替你保管的、按批次写入的、有保质期的副本。批次没跑，那段就没有；保质期到了，那段就删了。而这两件事发生的时候，界面上什么都不会说。

常见问题解答

6月那几天的数据，真的一点办法都没有吗？

从平台那边没有。官方的原话是收录数据不回填，也就是那几天的记录根本没有被写入过，不存在一个可以再跑一次的批次。能做的只有从自己这边找同期的替代证据：服务器日志里的抓取记录、当时的排名监控快照、第三方工具在那段时间存下来的数据。前提是这些东西的保留期覆盖得到6月，而大多数默认配置覆盖不到。

我的报表里某天是零，怎么判断是真零还是缺失？

看三件事。一是这一天在界面上显示的是数字0还是那个波浪号或者短横线，界面上还保留着区别，导出之后才会都变成0。二是同期其他指标有没有一起归零，真实的零通常伴随着整站流量的同步变化。三是过几天再看一眼，延迟造成的空会自己补上，永久缺失不会。

把数据导出成表格之后，还有办法区分吗？

基本没有。所以正确的做法是在导出的那一步就做好标记：自己写的取数脚本不要直接用平台给的下载文件，而是走接口，把返回为空和返回0分开存成两个不同的值。已经混在一起的历史文件，只能按日期区间人工打标。

接口的5万行上限，会影响我吗？

小站几乎碰不到，大站每天都在碰。它的坏处不是数据少，而是它静默：请求成功、格式正确、没有任何警告，你只是拿不到点击量排在5万名之后的那些行。判断方法很简单，把每次请求的返回行数存下来，只要有一天正好等于上限，就说明那天被截断了。

我的日志该保留多久才合适？

按你最长的观察周期倒推。看核心算法更新的影响通常要四到八周，做季度同比要覆盖上一个季度，查一次收录异常的溯源窗口一般是一个月。取最长的那个再留一点余量，60到90天是个比较稳的档位。压缩之后的文本日志占不了多少地方，一个中等流量的站一天几百KB到几MB。

日志文件名上的日期和内容对不上，会造成什么实际问题？

最常见的是统计少算。你写脚本统计9月11日的抓取量，顺手打开名字里带11日的那个文件，实际上里面装的是10日凌晨3点到11日凌晨3点的数据，你少算了11日凌晨3点到午夜的全部记录，多算了10日的一段。正确做法是把相邻两个文件都读进来，然后按行里的时间戳过滤，别信文件名。

为什么商家资料那次能补上，页面收录报表这次补不上？

官方没有解释原因。从表现上看，一个是数据已经采集但处理管线堵住了，堵通之后自然补齐；另一个是那一段时间的处理批次根本没跑，原始素材过期之后也就无从重建。这个区别对用户是完全不可见的，遇到同类情况时，唯一能做的是先等几天看它会不会自己回来，同时保存好自己这一侧的证据。

权威参考资料