伺服器日誌分析 SEO：從 Googlebot 請求紀錄找出爬取浪費

伺服器日誌分析在 SEO 裡看的是什麼？

「Search Console 只說頁面已探索、還沒建立索引，我怎麼知道 Googlebot 到底有沒有來過？」這個問題的答案就在你主機每天自己寫下的檔案裡。伺服器日誌分析（Log File Analysis）是把伺服器收到的每一筆請求整理成可判讀的資料，回答搜尋引擎實際爬了哪些網址、什麼時間爬、拿到哪個 HTTP 狀態、回應花了多久。它給的是請求證據，不是排名報表。

日誌能回答的，是爬取過程那一段

每一次請求都像一張收據，上面寫了時間、要了哪個網址、伺服器最後給了什麼結果，收據本身不會告訴你這筆往來划不划算。access log 就是這些收據的集合，用來查搜尋引擎實際拿了哪些頁面。Googlebot 有沒有爬到最核心的那批商品頁、多久回來一次、回來時收到 200 還是 500，這些都是一行一行的紀錄，不是估算。大型網站、抓取異常、網站改版與大量參數網址的技術稽核，最能從日誌裡拿到別處看不到的細節。

適用性跟網站規模、更新節奏有關。內容量少、更新不頻繁的小型網站，Search Console 的索引狀態與檢索統計多半已經夠用，大約一千頁以下的站通常不需要把日誌分析當成常態工作。真正會讓人想拉日誌的小站情境很具體：改版或換網域、新頁上線好幾週還沒被收錄、檢索量突然明顯下降。這時候取一到兩週的 access log 做小範圍檢查，就足以看出 Googlebot 是不是一直在敲舊網址。

有一家代理商的公開紀錄提過一個匿名案例：日誌顯示 Googlebot 連續三週被某個外掛擋在 robots.txt 後面，而業主問過的其他檢查都沒找出這件事。來源把當時的情況記成網站排名莫名下滑、業主先後找過三家公司都沒查出原因，最後是實際的請求紀錄揭露了爬取被阻擋這一段。這屬於單一代理商的觀察，適合當成「日誌能看到其他工具沒看到的爬取過程」的舉例，不適合推成通用規律，也不代表類似狀況一定靠日誌就能解決。

取得日誌前，資料範圍要確認哪些事？

先確認這份日誌涵蓋哪一層，再開始統計。網站如果經過 CDN、負載平衡器或多台主機，請求可能在 CDN 邊緣節點就被回應，根本沒到達原始伺服器，只看主機日誌會漏掉大量爬蟲請求，算出來的爬取頻率自然偏低。舉例來說，站方用 Cloudflare 擋掉了大部分爬蟲的 HTML 請求，主機端完全看不到 Googlebot 的造訪，統計出來的結果會讓你以為爬蟲根本沒來。資料來源的完整度，直接決定後面每一句結論可不可信。

片段資料會讓統計失準

最常見的失誤是拿到一個檔案就開始統計，最後得出「Googlebot 很少來」的結論，其實那份檔案只記錄了其中一台伺服器。申請或下載之前，這幾件事先講定：

• 涵蓋層級：確認要從 CDN、負載平衡器還是主機取資料，多層架構必要時得合併。
• 保存期間：至少涵蓋事件前後各兩到四週，不少主機預設只留七到十四天就自動輪替刪除。
• 格式一致：Apache、Nginx、IIS 與各家 CDN 的欄位與順序都不同，同一站換過主機也可能出現兩種格式。
• 時區統一：有的記 UTC，有的記伺服器當地時間，合併後時間序列會錯位，影響「修正後爬取有沒有回升」的判斷。
• 隱私處理：IP 位址與可能夾在參數裡的 email、session ID 都算敏感資料，遮蔽方式與分析後的刪除時間先談好。

拿到單一檔案，只代表特定主機、特定期間的片段。把範圍寫清楚，例如「8 月 1 日到 31 日、CDN 與主機合併、已排除靜態資源」，後面的結論才有明確的適用邊界。如果網站架構多層、不確定少了哪一段紀錄，這類盤點通常會跟整體的技術 SEO 稽核一起做，技術 SEO 稽核與修復的服務內容處理的就是這種跨層級的抓取問題。

SEO 日誌分析要留哪些欄位？核心與選用欄位對照表

核心四欄是時間戳記、請求 URL（含參數）、HTTP 狀態碼與 user-agent；IP 位址、回應時間、來源頁 referer 屬於選用，看你要回答什麼問題再拉進來。只是想驗證新上線的分類頁有沒有被爬，前四欄就夠；欄位留得精簡，檔案小、處理快，隱私風險也低。

欄位	必要性	能協助判斷的 SEO 問題
時間戳記	核心	爬取頻率變化、改版後爬蟲何時開始造訪新網址、錯誤是否集中在特定時段
請求 URL（含參數）	核心	哪些頁面或區段被爬、參數網址是否大量消耗爬取、重要頁有沒有被漏掉
HTTP 狀態碼	核心	失效頁、重新導向與伺服器錯誤的比例與分布
user-agent	核心	區分 Googlebot Smartphone、Googlebot Desktop、Bingbot 與其他爬蟲
IP 位址	視需要	驗證爬蟲身分真偽、排除偽裝流量
回應時間	視需要	找出回應特別慢的頁面類型，對應伺服器負載問題
來源頁 referer	視需要	了解真人流量的進站路徑，爬蟲請求通常不帶這個欄位

欄位定義要先跟伺服器或 CDN 的實際格式對齊，順序讀錯會把回應大小當成狀態碼，整批統計跟著歪掉。選用欄位不是升級版，而是為特定問題加開的：想驗證爬蟲真偽就留 IP，想找出拖慢爬取效率的頁型就留回應時間。爬蟲請求通常不帶 referer，這也是它能拿來區分真人與機器人的原因之一。

怎麼過濾並驗證真正的 Googlebot？

日誌裡大多數請求來自真人、監控服務與各種工具，先分流再談爬取。第一步把真人瀏覽、監控服務、第三方工具爬蟲與搜尋引擎爬蟲分成不同組，靜態資源（圖片、CSS、JS、字型）獨立一組，因為圖片和 CSS 請求量大不代表 HTML 頁面被爬到，混在一起算會讓爬取預算的分配看起來比實際樂觀。第二步用 user-agent 字串挑出自稱 Googlebot、Bingbot 的請求，觀察請求節奏穩不穩定、有沒有先去讀 robots.txt。第三步才用可驗證的資訊確認身分。

user-agent 只是自稱，驗證要看 IP

user-agent 字串任何人都能填，它不能當成唯一的身分證明。Google 官方提供兩種驗證方式：對 IP 做反向 DNS 查詢，確認網域落在 googlebot.com、google.com 或 googleusercontent.com，再做一次正向 DNS 查詢，確認解回來的是同一個 IP；另一個方式是把 IP 與 Google 公開的 IP 範圍檔比對，資料量大、需要自動化處理時，後者更適合。

跳過驗證最常見的代價，是把惡意掃描器打出來的大量 404 誤判成「Googlebot 爬了很多錯誤頁」，接著花時間修一個搜尋引擎根本沒遇到的問題。先確認對方是誰，後面的統計才有意義。

爬取分布要怎麼統計，浪費藏在哪裡？

統計的起點是一份「應該被索引的 URL 清單」，來源可以是 XML sitemap、CMS 匯出的已發布頁面，或網站爬蟲找到的 200 且可索引頁面；把清單跟一段期間內經驗證的 Googlebot 請求紀錄比對，落差就是線索。清單裡有、日誌裡從未出現，通常是爬蟲沒找到這條路，常見原因是內部連結層級太深、只能靠 JavaScript 產生的連結抵達，或頁面根本沒進 sitemap。清單裡有、日誌裡出現但頻率極低，代表頁面被發現了，只是被排在優先度後面，可能來自內鏈權重不足，或內容與其他頁高度相似。

另一邊：吃掉請求量的低價值網址

浪費不只看誰沒被爬，也要看誰被爬太多。把日誌裡的 URL 依路徑模式分組統計，就看得出哪些群組吃掉大量請求卻不該被索引：篩選與排序參數、站內搜尋結果頁、大小寫與結尾斜線造成的重複路徑，以及已下架卻仍回傳 200 的過期頁。電商站很常見一個商品頁有顏色、尺寸、排序三個參數，排列組合就能生出幾百條 URL，每一條都被 Googlebot 抓一次，預算就這麼用完了。處置前有個前提要確認：請求量高不等於該擋，某個參數網址被頻繁請求，也可能是它其實承接了外部連結或站內主要導覽。「沒被爬」與「被爬了卻沒收錄」的判讀方向不同，抓取與索引的判讀整理把兩邊分開來談。

日誌和 Search Console 要怎麼分工？

兩邊看的粒度不同，是互補關係。Search Console 的檢索統計是 Google 彙整、抽樣後的報表，適合觀察整體趨勢與索引涵蓋範圍；日誌是你伺服器端的逐筆紀錄，能回答單一 URL 在什麼時間被哪個爬蟲請求、拿到什麼回應，而且不限 Google，Bing 等其他爬蟲的造訪也一樣看得到。想確認某個新分類頁到底有沒有被碰過，日誌比報表直接。

AK SEO Labs 在內容盤點上的做法，是把 sitemap、逐頁內容與 GSC 查詢資料接在一起，讓每個 URL 同時有頁面內容、曝光、點擊與排名脈絡。實際跑起來的畫面是：一個 URL 旁邊同時顯示它講什麼、被搜到幾次、被點了幾次、目前排第幾。你手上如果也有日誌，把同一份盤點再對上爬取紀錄，哪個環節對不上就從那個環節查起。這是診斷流程，不會因為單一指標不好看就決定刪頁或改頁；它屬於方法立場，不是已證明的排名因果。

數字對不上時，先查資料層級

該拉日誌出來對的時機通常是：Search Console 指出某類網址有問題，但看不出細節，例如整體檢索量下滑、某個區段的錯誤比例升高，或一批 URL 卡在「已探索、尚未建立索引」。兩邊趨勢對不上，先確認日誌來源是不是漏掉 CDN、負載平衡器或代理層，再確認兩邊的統計口徑是不是在講同一件事。索引涵蓋、檢索統計與搜尋成效這幾張報表怎麼讀，Search Console 的指標與報表說明有完整的對照。

找到問題之後，修正和追蹤要怎麼安排？

排序原則是先讓重要且可索引的頁拿到合理爬取，再處理大量消耗資源的區段。重要性高、日誌異常也高的一組最優先，例如核心商品頁整整一個月沒被爬、主要分類頁回傳 5xx；重要性高但異常輕微的持續監測；重要性低卻異常偏高的排進規劃。有些站是月底做完活動，舊活動頁的網址掛著仍回傳 200，Googlebot 隔兩三週就回來一次，每次都在那些沒有轉換價值的頁面上耗掉一輪爬取，累積下來數字很可觀。

先修重要頁，再處理浪費

日誌能定位哪些實際被爬取的路徑出了問題，卻看不到原因。一批 404 可能來自模板裡的錯誤連結、外部網站的舊連結，或 sitemap 殘留的舊網址，三種根因的修法完全不同。修正前要搭配網站爬蟲檢查頁面設定、看伺服器監控與部署紀錄，確認根因再動手；日誌本身不能證明因果。

處置方式要配合問題性質。robots.txt 擋的是爬取，不保證網址不被索引，被擋的頁面也讀不到頁面上的 noindex 或 canonical；如果目的是整併重複內容，canonical 通常比 robots.txt 合適。要擋哪些參數模式、擋下去會影響什麼，robots.txt 的規則與常見誤用整理得很清楚。

修正後用同一口徑回測

判讀門檻以同一網站、同一來源、相同長度期間的前後比較為準，換算成通用數字就失去意義。每次分析固定資料長度與來源，修正後用同樣方式再量一次，例如 8 月 12 日對排序參數加上規則，之後看參數網址的請求量是否下降、重要頁爬取是否回升；沒有改善的項目回到問題設定重新來過。如果你希望有人用同一套口徑把日誌讀完、排出優先順序，讓 AK SEO Labs 接手你的爬取診斷。

FAQ

一定要買付費工具才能分析日誌嗎？

不一定，日誌本身是純文字，用試算表就能篩出 Googlebot 的請求與狀態碼分布。開源工具裡 GoAccess 能在終端機或瀏覽器產生即時報表；AWStats 是老牌的 HTML 報表工具，不少主機商預設就裝好，但它的官方站已說明原作者不再發布新版本，選用前要接受這個狀態。想把爬蟲行為跟網站結構放在一起比對，則是 Screaming Frog 的 SEO Log File Analyser，那是商用軟體，免費版只能分析一千筆 log 事件，要解除上限得買年費授權。除非每天上百萬 PV 需要企業級方案，中小型網站先從免費或開源的那一組開始通常就夠，維護成本往往才是選擇時的關鍵。

小型網站也需要做日誌分析嗎？

不一定，內容量少、更新不頻繁的網站，多數情況 Search Console 已經夠用，大約一千頁以下的站不必為這件事焦慮。判斷可以看三個條件：問題的複雜度、內容與結構的變動頻率、有沒有出現索引或錯誤跡象。真的遇到換網域、新頁久未收錄、檢索量異常下降，取一到兩週的 access log 篩出 Googlebot 請求，常會發現爬蟲一直在敲已下線的舊網址。

怎麼確認日誌裡的 Googlebot 不是偽裝的？

看 IP，不能只看 user-agent：反向 DNS 查詢要解到 googlebot.com、google.com 或 googleusercontent.com 網域，再正向查一次，確認解回來的是同一個 IP。資料量大、想自動化時，直接拿 IP 跟 Google 公開的 IP 範圍檔比對更省事。差別很實際：驗證前會以為某批 404 是 Google 爬錯頁，驗證後常發現那是一個掃描器。

日誌出現大量 404，是不是要全部清掉？

不一定，日誌只顯示哪些路徑被請求卻找不到，原因要看別的地方。同樣一批 404，可能來自模板裡的錯誤連結、外部網站留著的舊連結，或 sitemap 殘留的舊網址，處理方式分別是修模板、設導向或更新 sitemap。先按路徑分組，看它集中在哪個區段，再回頭查部署紀錄與頁面設定，比較不會修錯地方。

某頁被爬過卻沒被索引，日誌能回答嗎？

不行，日誌回答的是爬取過程，不是索引結果。它會告訴你 Googlebot 什麼時候來過、拿到什麼狀態碼、多久回來一次；至於這頁有沒有進索引、哪個版本被選為代表，得看 Search Console 的索引報告。兩邊涵蓋範圍也不同，日誌連 Bing 等其他爬蟲的造訪都記得到。

日誌分析要多久做一次？

跟著網站事件走，不必照表操課：每週看 Googlebot 總請求量與 5xx 比例有沒有突變，數字怪的時候再對照 Search Console 的檢索統計。每月把各 URL 群組的爬取分布、重要頁覆蓋率、低價值網址的消耗比例看一輪。搬遷或重大更新後的前兩到四週改成每天或隔天看，錯誤通常集中在這段時間爆發。

日誌裡有 IP 和參數，可以直接交給外部的人分析嗎？

不一定，日誌裡的 IP、可能夾帶在參數中的 email 或 session ID 都屬於要謹慎處理的資料。實務上的順序是先確認對方需要哪些欄位、能不能只給完成目的所需的最小範圍，把 IP 遮蔽或雜湊、約定傳輸與存放方式，以及分析結束後的刪除時間。範圍講清楚通常不影響診斷結果，資料也不會在外停留太久。