多數人只看分析工具，因為它有圖表、有介面。但分析工具依賴前端腳本，看不到爬蟲、看不到失敗的請求、也看不到被封鎖的訪問。這些看不到的部分，經常正是問題所在。
先講兩者的差別。分析工具記錄的是「成功載入頁面且腳本有執行」的訪問；伺服器日誌記錄的是「所有抵達伺服器的請求」，包含機器人、錯誤、重新導向與被拒絕的存取。兩份資料的用途完全不同。
七個欄位裡最重要的是狀態碼與使用者代理。前者告訴你哪裡出錯，後者告訴你是誰來的。多數的初步判讀只需要這兩欄加上路徑。
把一段期間內的狀態碼統計出來，看四百與五百開頭的比例。四百零四代表找不到，通常來自失效連結；三百零一與三百零二是轉址，過多代表結構有問題；五百開頭是伺服器錯誤，任何比例都值得立刻處理。
日誌裡通常有一半以上的請求來自機器。要把它們分出來，先依使用者代理字串分組，再對可疑的來源做反向解析驗證。驗證的方式是：把 IP 做反向解析取得網域名稱，再把那個名稱做正向解析，看是否回到同一個 IP。
分出來之後，機器流量本身也有分析價值：哪些爬蟲來過、來的頻率、抓了哪些頁面。這是判斷內容是否被發現的第一手資料。
把全站的網址清單和日誌裡出現過的路徑做比對，差集就是從來沒有被請求過的頁面。這份清單通常會讓人意外，多數站都有一到三成的頁面長期沒有任何請求。
相反的情況也值得看。如果某些頁面被抓取的次數遠高於其他頁面，通常有兩種原因：它是重要的入口，或者它產生了大量參數化的變體。後者會浪費抓取資源，應該用規範化的方式處理。
不需要專門的日誌分析軟體。把日誌匯出成文字檔，用試算表或幾行命令列就能完成上述四項判讀。真正的門檻不是工具，是取得日誌本身，很多託管平台不直接提供，需要透過內容傳遞網路或自建記錄。
每月一次，二十到三十分鐘。重點不在深度，在於固定。連續六個月之後，你會擁有一組趨勢資料，可以判斷改動是否真的有效。單次的日誌分析只能發現當下的問題，連續的紀錄才能驗證改善。
若你想針對 AI 爬蟲做更細的判讀，站內的 三十天日誌的六個判讀點 提供了完整流程。
格式建議是五行：本月總請求數與機器佔比、狀態碼分布、被造訪的獨立頁面數與佔比、新增與消失的頁面各三筆、以及需要處理的問題清單。五行，每月同一天更新。
「新增與消失的頁面」這一項是最有預警價值的。某一頁原本每週都被抓，突然連續三週沒有紀錄，通常代表它出了問題，可能是內部連結被移除、可能是被誤設為不索引、也可能是回應變慢導致被降低優先序。
第四項的處理要謹慎。降低頻率的設定如果套用得太寬，可能連需要的抓取一起擋掉。建議先確認來源是否為已驗證的正規爬蟲，再決定處理方式。
兩者對照時最有價值的一個問題是：日誌顯示被大量請求、分析工具卻幾乎沒有訪問紀錄的頁面是哪些？答案通常是兩類，被機器大量抓取但人不看的頁面、以及腳本沒有正確載入的頁面。
第二類是真正的問題。分析工具依賴前端腳本，如果某些頁面的腳本沒有執行，那些頁面的人類訪問就完全消失在報表裡。這種問題只有靠日誌才能發現。
日誌包含來源位址，在部分法規下屬於個人資料。實務上的處理原則有三：只保存分析所需的欄位、設定明確的保存期限、以及在不影響分析的前提下考慮匿名化處理。
分析競業或爬蟲行為時，多數情況不需要完整的位址，只需要能夠驗證來源是否為正規爬蟲。可以在保存時就把位址部分遮蔽，只保留驗證結果。
本文不提供法律意見，實際的保存政策應依適用法規並諮詢具備資格的專業人士。
最後一個提醒：日誌看到的是機器的行為，分析工具看到的是人的行為。兩份資料回答的是不同的問題，只看其中一份，就會有一整類的問題永遠發現不了。
最後提醒看伺服器日誌不必一次看懂全部。剛開始只要固定看三件事就有價值：哪些網址被抓最多次、哪些網址回傳非二百的狀態碼、以及機器人與真人的比例有沒有異常變化。這三項就足以抓出多數的結構問題與資源浪費。等到習慣之後再往下鑽研，也不遲。日誌的價值在於它記錄的是實際發生的事，而不是工具推估出來的事，這一點是任何報表都取代不了的。