Google 虽然已经是在网路圈是稳定度相当高的一间公司与服务，但事实上挂的机会还是很高，主要也是 Google 的服务很多，且一直在进步与开发，就有在经营的人就知道，系统更新时出现问题的机会是变高的，更何况当服务一复杂，任何一个环节若没注意好就很容易出问题。

事实上在写这铁人赛的 25 天中，Google 还真遇到了一个长达四、五天的资料不及更新的状况，也就是在九月 20 日时，应该会有九月 18 日的资料，因为 Google Search Console 会晚约两、三天才会更新，但那天就一直停留在 17 日，一直到九月 24 日才恢复正常。

不只是那段时间资料无法更新，那几天也很常 500 Server Error 进不去，这个让想要透过 Google Search Console 去进化搜寻流量的人是很伤脑筋的事。

只是这个事件会被记录下来吗？事实上不会，因为在九月 24 日後这资料就复原了，至少是看不出明鲜的影响，这种不会造成事後资料一致性的问题 Google Search Console 是不会记录的，因为通常不会造成资讯不一致造成无法解读的问题。

而 Google Search Console 在这两三年发生过多少次资料错误造成无法复原的问题呢？

Google Search Console 今年迄今的问题

从 2019 年 12 月到今年的 9 月这 22 个月中，发生了 9 次资料无法正确记录或呈现的问题，而须要解读者注意的事件，也就是平均约每 2 个半月会发生这样的事情一次。

最近的一次是在 8 月 23～24 日之间，那两天的流量资料是有问题的，因此所有人的报表都会发生像上图那样的一个低谷，而这低谷虽然说是无法复原资料，但对真实的流量并不会影响，也就是说去看 Google Analytics 的报表不会有这现像。

当然不是每一次的问题都会影响到所有人，甚至是长时间的，就像是去年 2020 年 10 月 28 日做的调整，这部份是 Google Search Console 长达超过一年以上的资料都有错，因为 Google 不小心把影片的流量加总到 Discover (探索) 其中，这问题是必须要有探索流量很高的网站，或是影片流量很高的网站才会资料极度偏差失准。

这种偏差失准也会让我们解读探索流量有很大一部份是靠『影片』，但事实上是完全没有，虽然当时我们也一直在猜 Google 是怎应用到影片的资料或是呈现在 Discover，最後发现是误会一场。

像这种 Google 资料的 Bug，或是不清楚，造成解读上的问题，甚至是要去找出解决方法是吃尽了苦头，这边大概说三个曾遇过的情境：

Case C：网站速度解读错误

这是发生在三年前之前，那时 AMP 刚推出，那时网站的指标还是以『速度』为主，还没有用後来的 Core Web Vitals 取代，因此有关速度的指标虽然也是红黄绿三个象限，但那时是用快中慢来代表网站速度。

而有一天 C 网站在网站速度发现这个报表显示读者浏灠网页须要 20 秒以上，甚至是越来越慢到 1~2 分钟，但除了这个报表在实务上完全感觉不出来，在 Google Analytics 报表也是没问题，虽然 GA 报表在速度的面像是不一样的。

因此那个网站过不久就被降权了，流量大减，而当时也找不出原因，更不用说找出方法，这样过了两三个月，Google 说在 AMP 的 Infinity Scroll 中，会让 Google 速度判断失准，因此 Google 决定废止网站速度的用法，也请大家不要用那个 Library，且 Google 会用 Core Web Vitals 取代网站速度。

当然那个 C 网站後来流量回来了，但也是超过半年等 Google 把这问题解决，而这个教训也让我们知道 Google Search Console 不能尽信，但这资料是『真』的有影响 Ranking Factor 排名因子，虽然是『假』的。

Case M：网页其他错误无法解读

这是发生在 2019 年底，从 Google Search Console 看到这个 M 网站的网页数大量减少，明明应该有超过 10 万个内容与网页，但 Google 只收录不到 1/3，甚至有时起起浮浮还要更低过。

当然有效网页数不只很低，从行动装置可用性看的有效页面更低，而网站流量直接剩下 1/3，这是非常严重的事。

但事实上透过 Google Search Console 的 Inspect 有发现，没有收录的网页 Google 都说『Mobile Friendly Failure』，也就是行动装置在解读网页是有问题的，可是当我们一直拿这些页面去测试，所有工具都跟我们讲是正常的。

而这问题一直追了一两个月，发现到在 Inspect 提到这网页的 CSS 是有『其他的问题』，只是这个甚麽是其他的问题是甚麽，比较常见的 Crawler Budget 不够，但这个网站看起来不像有这问题。

因此就做了一个猜测，这些档案可能在 IDC 或是 Server 或是 Firewall 的设定有跟 Google 爬虫相冲突，因此最後把这些档案换到其他地方就迎刃而解了。

很可惜的当时没有检索统计报表，不然或许在 Trouble Shooting 的时间会更短，包含测试的方法，但这又是另外一个故事了。

Case P：AMP 的错误写在 Mobile

这件事就是在一年内发生的，这个网站因为要做大符度改版，这包含前後台，只是这工程浩大，因此就分了很多阶段完成，其中也包含版面与版型的问题。

而在某一天，Google Search Console 显示行动装置可用性发生错误，所以有效网页突然大量降低，进去 Inspect 看，Google Search Console 说这网页的宽度太宽，所以就失效，这感觉是一个超级简单的问题，只要把网页调好就好，只是当真的仔细看，用工具检查，也是完全没问题。

有了上面 M 网站的经验，在想会不会是防火墙等等之类的问题，但怎麽修正也是无法解决。

这问题困扰了一段时间，虽然流量有稍微下降，但也因为改版整个网页都在改善，流量也一直在上升，但可以感受到那期间成长幅度慢下来了。

而也是在某一天，在用结构化资料测试工具时，发现有一个栏位资料格式有问题，因此就开单修正，但从修正那天後，行动装置可用性错误的资料就消失了，最後这个网站也慢慢恢复该有的成长。

因此从上面看来，可以知道 Google Search Console 也是常常出错的，甚至这个错误会很麻烦，因为错误的是他们，但影响流量的是我们网站，但如何把这种 Bug 当作是 Feature，去拆解他避免他也是很重要的。

但也不要因为这样看到 Google Search Console 所说的错误而不相信，因为就经验来看，99% 的问题都是出在我们网站身上，须要开单解决的，相较 Google 会犯得错误，我们反而是多太多了。