iT邦幫忙

2021 iThome 鐵人賽

DAY 24
0
IT管理

從 IT 技術面細說 Search Console 的 27 組數字 KPI 系列 第 24

從 IT 技術面細說 Search Console 的 27 組數字 KPI (24) :檢索統計報表 KPI 外的重點項目

在去年的 2021–11–25 那天,Google 終於把 Search Console 的檢索統計給更新了,在那天就寫了一篇 『Search Console 對 "檢索統計/Crawler Stats" 真除後的重新檢視』,而在那天也把 KPI 總表的檢索數從舊表的『平均每日檢索數』改成最近一天的檢索數。

https://ithelp.ithome.com.tw/upload/images/20210924/20000065xNqDnbd2mV.png

但也知道 Google 那次的改版會把原本的檢索數、下載大小與回應時間整合在一張表,也會呈現區間,只是期望會有一個功能就是可以設定時間區間,因為原本的表都是用 90 天來統計,而之前的表都可以設定時間週期,因此預期也是會有可以調整天數來去統計,很可惜的並沒有。

因此在 11/1 的 90 天後,發現這張表就固定是 90 天,無法去設定時間區間,就把檢索數改成『檢索要求總次數』,但實務上知道 KPI 總表若直接改動是很危險的,事實上是增加一個欄位,只是有的網站同時兩個數字一起填,有的就改填這張表。

也提到有一個很認真的人,真的下載這個表格,然後計算最近的七天平均,然後填入,這是最標準的作法,只是連我自己都做不到,因此也不敢要求別人也這樣做。

只是隨著這張總表透過這樣的 KPI 去發現問題及找出解決方式時,就發現 90 天真的過於不夠敏感,而最後一天的變動性過高無法呈現趨勢,因此只好兩筆資料都同時記錄,90 天統計的專看趨勢,最近一天的專看現狀,這也是種折衷的方法。

而隨著一次又一次的 Troubleshooting 時,發現回應時間是相當重要的事,以前因為舊表同時出現而可以去發現到問題,而現在要刻意去點擊才會出現,因此在這種情形下,KPI 總表就又加計了回應時間,其中也是平均回應時間與最近一次的回應時間同時記錄。

而檢索統計報表有六張表格:

  • 檢索統計
  • 主機檢索狀況
  • 檢索回應狀況
  • 檢索檔案類型
  • 檢索目的
  • Googlebot 類型

這六張表加起來扣掉主機的不同,就可能會有 30 個以上的不同數字,而實務上不會把這 30 個數字都記下來,只能當發現有問題時回過頭來看看從這些數字可以看出甚麼端倪。

經過了這 10 個月來,也發現有幾個常會須要注意的數字,雖然目前不會記在 KPI,但或許有考慮在總表記錄下來。

Not Modified

在檢索要求分析的『依回應』這邊,大部份的情形應該都是 OK (200) 才對,但實務上應該還會以很高的 Not Modified (304) 才對。

這個沒有修改是正確的,通常是代表的 Cache 機制有正常運作,這邊雖然不ˋ見得包含到網頁 HTML,但很多靜態檔案,如圖片、CSS、javascript 是最常見不會更動的內容,因為通常若是更動或不一樣,就會用不同的檔案名或是 URI 才對,這也是說當透過 cache 的機制,如日期、Header、ETag、…… 等等都可以減少讀取的資源,讓讀者瀏灠速度加快、也對伺服器降低大量的負荷才對。

因此這部份的數字應該都會有 20%~40% 才對,當然這邊也要有一個前提,這些有做好 Cache Control 的檔案都在同一個網域,也就是說有些網站的圖庫檔案不在同一個網域底下時就不會被計算,因為檢索統計資料是以網域為單位,也就是若是子目錄的話就不會有這份報表。

所以當發現網站這個數字不在這個區間,且這些靜態檔案 (或是可以 Cache 的檔案) 比例過少時,必然是有問題的,應該去做修正,事實上除了對負荷有影響外,這影響所產生的效應也是會再影響 SEO,其中包含 Crawler 的狀態與使用者體驗。

重新整理

在檢索統計報表『依目的』的表格中只有兩個項目,一個是 Refresh (重新整理),一個是 New Discover (發現方式),大家可以乎略這個翻得很爛的中文,這應該是程式或 UI 在 i18n 時沒有做好。

重新整理的是 Google 去爬已經在資料庫或是已經在索引裏面的網址,再去抓取更新資料,理論上一個網站應該絕大多數都是如此,這數字應該是在 95%~98% 之間才對,除非有幾種狀況:

  • 網站有新功能,因此會有新的網址出現,爬蟲發現新的網址就會去爬取,因此 Refresh 的比例就降低了。
  • 更改網址,雖然沒有新功能,但新網址出現了,因此 Google Crawler 就會去爬取新的網址,舊的更新比例也會降低。

當然這上面的都是好的,雖然改變網址最好還是要避免,但這都是在屬於可以控制的範圍,只是有幾個狀況是不好的:

  • 新網址異常的出現,其中比較常見的是在追蹤碼大量疊迨產生,因此出現了大量的新網址,只是這些網址是不應該的,尤其是沒有做好 Canonical (制式網址) 時。
  • Crawler Budget 不夠,當網站過新,或是流量過小,或是前面的 Cache Control 沒做好時,爬蟲爬新的網頁都爬不完了,也沒資源分配給 Refresh 的重新更新,此時要好好避免沒有意義的網址出現讓 Google 去爬,此時就要適時的在連結上加 『no-follow』,讓爬蟲不須要爬意義不高的網址。

一個網站在經營一段時間新增網頁內容是有限的,這個比例不可能太高,即使有些網頁可能是屬於會員的 UGC (User Generated Content),但這部份才更須要 No-Follow 或是直接加 UGC 的這個屬性,或是在網頁中加 no-index,甚至在 robots.txt 直接 disallow 都是可以的,這樣讓爬蟲有效率的爬到有意義的網頁。

當然這個 SEO KPI 報表的精神是統整 Google Search Console 的資訊,而 GSC 是做為網站經營與搜尋引擎溝通的橋樑,因此從這份報表不只可以看到網站經營的狀況,更可以知道 Google 是怎麼看我們網站的,因此其他的項目到底怎樣是合理的,取決於網站經營者對自己的認知跟這份報表有沒有誤差,若是有很大的差別,必然是某一個環節有問題。

這個 SEO KPI 總表的演化基本上真的是跟著 SEO 的錯誤學習而改變,而檢索統計報表是屬於較新的 UI,因此在面對挑戰找出問題的經驗是較少的,其中這 30 項以上的資料,包含上面說的這兩項到底要不要列入 KPI,也是要隨著被證實須要關注且有價值再來討論。

不然真的 Ranking Factor 有人也列出過上千項,只是這種上千項的的報表已經是『Noise』雜訊等級了,真的要去做『儀表板/Dashboard』是不對的,因為一個好的報表還是希望能夠一目了然,不然就沒意義了。


上一篇
從 IT 技術面細說 Search Console 的 27 組數字 KPI (23) :KPI 總表
下一篇
從 IT 技術面細說 Search Console 的 27 組數字 KPI (25) :Search Console 可以看到到多少 Ranking Factor 呢?
系列文
從 IT 技術面細說 Search Console 的 27 組數字 KPI 30

尚未有邦友留言

立即登入留言