在去年的 2021–11–25 那天,Google 終於把 Search Console 的檢索統計給更新了,在那天就寫了一篇 『Search Console 對 "檢索統計/Crawler Stats" 真除後的重新檢視』,而在那天也把 KPI 總表的檢索數從舊表的『平均每日檢索數』改成最近一天的檢索數。
但也知道 Google 那次的改版會把原本的檢索數、下載大小與回應時間整合在一張表,也會呈現區間,只是期望會有一個功能就是可以設定時間區間,因為原本的表都是用 90 天來統計,而之前的表都可以設定時間週期,因此預期也是會有可以調整天數來去統計,很可惜的並沒有。
因此在 11/1 的 90 天後,發現這張表就固定是 90 天,無法去設定時間區間,就把檢索數改成『檢索要求總次數』,但實務上知道 KPI 總表若直接改動是很危險的,事實上是增加一個欄位,只是有的網站同時兩個數字一起填,有的就改填這張表。
也提到有一個很認真的人,真的下載這個表格,然後計算最近的七天平均,然後填入,這是最標準的作法,只是連我自己都做不到,因此也不敢要求別人也這樣做。
只是隨著這張總表透過這樣的 KPI 去發現問題及找出解決方式時,就發現 90 天真的過於不夠敏感,而最後一天的變動性過高無法呈現趨勢,因此只好兩筆資料都同時記錄,90 天統計的專看趨勢,最近一天的專看現狀,這也是種折衷的方法。
而隨著一次又一次的 Troubleshooting 時,發現回應時間是相當重要的事,以前因為舊表同時出現而可以去發現到問題,而現在要刻意去點擊才會出現,因此在這種情形下,KPI 總表就又加計了回應時間,其中也是平均回應時間與最近一次的回應時間同時記錄。
而檢索統計報表有六張表格:
這六張表加起來扣掉主機的不同,就可能會有 30 個以上的不同數字,而實務上不會把這 30 個數字都記下來,只能當發現有問題時回過頭來看看從這些數字可以看出甚麼端倪。
經過了這 10 個月來,也發現有幾個常會須要注意的數字,雖然目前不會記在 KPI,但或許有考慮在總表記錄下來。
在檢索要求分析的『依回應』這邊,大部份的情形應該都是 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% 之間才對,除非有幾種狀況:
當然這上面的都是好的,雖然改變網址最好還是要避免,但這都是在屬於可以控制的範圍,只是有幾個狀況是不好的:
一個網站在經營一段時間新增網頁內容是有限的,這個比例不可能太高,即使有些網頁可能是屬於會員的 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』是不對的,因為一個好的報表還是希望能夠一目了然,不然就沒意義了。