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 會犯得錯誤，我們反而是多太多了。