Googlebot 是怎麼找到你的網站
很多人第一次開網站，以為只要發布了文章，Google 就會自動找上門。現實是，Googlebot 發現你的頁面靠的是具體的線索，不是定期掃描整個網路。如果這些線索不夠清晰，頁面可能放了好幾個月，爬蟲都沒來過。
Googlebot 是 Google 用來抓取網頁內容的程式，每天在全球爬取約 20 億個網頁。它不是一隻蟲子，而是分散在 Google 伺服器上的大型分散式系統。爬取的頻率和範圍，由 Google 根據每個網站的品質、更新頻率和伺服器回應速度決定。
根據 Googlebot 官方說明，Googlebot 本身還分幾種類型：負責網頁的 Googlebot，負責圖片的 Googlebot-Image，以及負責影片的 Googlebot-Video。你在 robots.txt 設定封鎖規則時，這些是不同的 user agent，封鎖一個不代表全部都封鎖。完整的 8 種 Googlebot 類型（含 Storebot-Google、Google-Extended）和驗證方式，詳見 Googlebot 爬取完整指南。
URL 發現的 4 個管道
Googlebot 發現新 URL 的管道，主要有四條：
- 站內內部連結：從 Google 已知的頁面跟著連結往下爬，這是最主要的來源。新頁面沒有任何其他頁面連到它，Google 就很難主動發現它。
- XML Sitemap：你主動提交到 Google Search Console 的 sitemap，等於給了 Googlebot 一份地圖，告訴它哪些頁面存在、最後更新時間是什麼。
- 外部反向連結：如果其他網站連到你的頁面，Googlebot 爬取那個外部網站時也會順帶發現你的 URL。
- 手動提交：透過 Google Search Console 的 URL 檢查工具，直接要求 Google 爬取特定頁面。
一般來說，新網站或新頁面被首次爬取，通常需要 1-4 週。如果同時提交了 Sitemap 並且有外部網站連到新頁面，時間可能縮短。孤島頁面（沒有任何內部連結指向它）有時等了好幾個月都沒有動靜。如要系統性診斷哪些頁面缺乏站內入口，可參考內部連結 SEO 診斷指南。
爬取佇列的排隊邏輯
Googlebot 不是發現一個 URL 就立刻去爬。所有被發現的 URL 都進入一個爬取佇列，Google 再根據優先順序決定何時處理。影響排隊順序的因素包括：頁面的歷史更新頻率、PageRank 估算值、上次爬取後伺服器回應是否穩定，以及 Sitemap 裡標示的 lastmod 日期。
老站的重要頁面排在佇列前面，新站或長期沒更新的頁面通常排在後面。行動裝置優先索引（Mobile-First Indexing）已是預設，Googlebot 現在主要用行動版的 user agent 爬取內容。如果你的行動版和桌機版內容不同，Google 索引的是行動版。
也要注意，Google 爬蟲與 User Agent 說明中列出的不同類型爬蟲，會在不同情況下被派出。Googlebot Smartphone 和 Googlebot Desktop 的行為有細微差異，但主索引走的是 Smartphone 版本。
爬取到不代表收錄了：兩件事不要搞混
之前有個客戶說他的文章都寫完了，但 GSC 顯示有一半頁面根本沒被 Google 收錄。他以為是 Google 不喜歡他的內容，一直在改文章。結果排查下來，問題根本不在內容，而是 canonical 標籤設定錯誤，把自己的頁面指向了別的 URL。
爬取和索引是兩個獨立的關卡。Google 爬取一個頁面，代表它把頁面的 HTML 下載下來分析了。但分析完之後，Google 還要決定要不要把這個頁面的內容加入索引資料庫。爬取是輸入，索引才是輸出。
爬取、索引、排名：三個不同關卡
| 階段 | Google 做什麼 | 你能直接影響嗎 |
|---|---|---|
| 爬取（Crawl） | 下載頁面 HTML，分析連結和內容 | 部分（robots.txt、速度、內部連結） |
| 索引（Index） | 評估頁面是否值得納入搜尋資料庫 | 有（內容品質、canonical、noindex） |
| 排名（Rank） | 根據查詢相關性和品質決定排序 | 有，但間接（EAT、連結、相關性） |
被排名是結果，被索引是前提，被爬取是更前面的前提。這三個階段出問題的原因和解法完全不同。很多人排查 SEO 問題時跳過了爬取這層，直接在排名層面糾結，結果事倍功半。
「爬取到但沒收錄」最常見的 5 個原因
頁面被爬取到、但 Google 決定不收錄，通常因為以下其中一個原因：
- noindex 標籤：頁面 HTML 或 HTTP header 裡有
noindex指令，Google 爬完就跳過，不會索引。這個問題最常見於 WordPress 網站，某些外掛會在沙盒模式或測試環境時自動加上 noindex，上線後忘記關掉。 - Canonical 指向別的頁面：canonical 標籤告訴 Google「這頁的正版是另外那頁」，被指向的來源頁就不會被獨立索引。設定錯誤時，等於自己把頁面排除在外。
- 重複內容：多個 URL 的內容幾乎相同（例如分頁問題、URL 參數產生重複版本），Google 只會索引它認為的「代表頁」。
- 內容品質不足（Thin Content）：頁面字數極少、大量廣告、或是對使用者幾乎沒有資訊價值，Google 可能爬完後選擇不收錄。
- 伺服器不穩定或回應太慢：爬取時伺服器回應 5xx 錯誤或逾時，Googlebot 會放棄並記錄問題。反覆發生時，Google 會降低爬取優先順序，索引自然跟著延遲。
這裡是關鍵：這 5 個原因裡，前 3 個跟爬取本身無關，是你主動告訴 Google「這頁不要收」或「這頁是重複的」。排查時要先釐清問題出在爬取層還是索引決策層。
延伸閱讀：noindex 和 nofollow 差在哪？差異、設定方式與 SEO 檢查流程
爬取預算：Google 不是無限地爬你的網站
每個網站的爬取預算，可以粗略理解成「Google 願意在你的網站上花多少資源」。這個資源不是無限的，尤其對頁面數量多的網站來說，如何讓 Googlebot 把時間花在有價值的頁面上，是架構設計的核心問題之一。爬取預算（Crawl Budget）診斷與優化指南有完整的 GSC 診斷步驟與症狀識別框架可以參考。
Google 官方把爬取預算的機制分成三個部分，這個模型在 Google 爬取預算官方說明 中有詳細定義。
爬取預算的三元模型
官方模型裡，爬取預算由三個元素組成：
- Crawl Capacity Limit（爬取容量限制）：Googlebot 基於你的伺服器狀況決定的上限。如果爬太快會拖垮伺服器，Google 會自動降速。如果伺服器回應穩定、速度快，Google 就願意爬更多。這個上限你可以在 GSC 裡手動調整，但一般不建議。
- Crawl Demand（爬取需求度）：Google 對你的網站有多大興趣。新頁面、有外部連結、有更新紀錄的頁面，需求度高。長期沒變動、PR 值低、沒人連到的頁面，需求度低。需求度決定 Googlebot 多常想來拜訪。
- Crawl Budget（爬取預算）：上面兩者的交集。不管你的伺服器再強，如果 Google 認為你的頁面不重要，爬取需求度低，實際爬取量也不會高。
理解這個模型的實際意義是：提升爬取效率有兩條路，一是讓伺服器跑得更快（影響 Capacity Limit），二是讓更多頁面對 Google 有價值（影響 Demand）。只改速度、不清理低品質頁面，效果有限。
哪些網站需要擔心爬取預算
Google 自己說，頁面數量在幾千頁以下的一般網站，不需要特別擔心爬取預算。這個數字的非正式門檻通常被引用為 1,000 頁以上才值得認真關注。
以下幾種情況是例外：
- 電商網站有大量分類篩選頁（?color=red&size=M 這類 URL 可能產生數萬個重複頁面）
- 論壇或 UGC 平台，每天有大量新產生的低品質頁面
- 有複雜的分頁系統，產生幾百個 /page/1 /page/2... 的 URL
- 有重複的動態 URL（session ID 出現在 URL 裡）
有個電商客戶的案例很典型。他有 5,000 個實際商品頁，但因為顏色、尺寸、排序參數的組合，URL 數量膨脹到超過 50,000 個。Googlebot 大部分時間都在爬這些參數頁，真正重要的商品頁反而爬得不夠頻繁，新上架商品要等很久才進索引。
5 種最常見的爬取預算浪費行為
- URL 參數沒有管控，產生大量重複或低價值的 URL 變體
- 404 頁面還在 Sitemap 裡，Googlebot 反覆確認這些 URL 是否存在
- 重定向鏈過長（A→B→C→D），每次爬取都消耗多個 URL 的配額
- 低品質頁面（薄內容、幾乎沒有正文）被大量爬取但沒有索引價值
- 非正式的暫存或測試頁面沒有 noindex，被爬取但沒有任何意義
讓 Googlebot 卡住的常見障礙
爬取問題排查有個規律：先看 robots.txt，再看 HTTP 狀態碼，最後看速度。大多數嚴重的爬取問題都集中在這三個地方，而且 robots.txt 問題出現的頻率高得令人意外。
robots.txt 設定錯誤
robots.txt 放在網站根目錄，告訴爬蟲哪些路徑不要爬。問題是，它只阻止爬取，不阻止索引。Googlebot 如果從其他地方（比如外部連結）得知某個被 robots.txt 封鎖的 URL 存在，它還是會在搜尋結果裡顯示這個 URL，只是沒有內容說明。
這步驟不能跳過：用 GSC 的 robots.txt 測試工具，確認你的 robots.txt 有沒有不小心封鎖了 CSS 或 JS 檔案。之前碰到一個電商站，robots.txt 裡有一行 Disallow: /wp-content/，導致 Googlebot 看不到整個網站的樣式表和 JavaScript。結果頁面在 Google 眼裡幾乎是空的 HTML，排名直接崩掉。
常見的 robots.txt 錯誤：
- 用
Disallow: /封鎖整個網站（測試環境複製到正式環境時最容易發生） - 封鎖了包含重要資源的路徑（CSS、JS、圖片資料夾）
- 使用了不正確的萬用字元語法，結果封鎖範圍超過預期
要系統性排查 robots.txt 語法錯誤與誤封鎖問題，可以參考robots.txt 設定完整指南：語法教學、常見錯誤與 GSC 診斷流程。
HTTP 錯誤碼和重定向鏈
404 頁面本身不是問題，Google 遇到 404 只是記錄「這個 URL 不存在」，然後繼續。問題在於：如果你有大量內部連結指向 404 頁面，Googlebot 會反覆去確認這些頁面，浪費爬取配額。
重定向鏈（A 跳轉到 B，B 再跳轉到 C）問題更嚴重。Google 官方建議重定向鏈不要超過 3-4 個跳轉。過長的鏈會讓 Googlebot 放棄中途，後面的 URL 直接沒有爬到。用 Screaming Frog 或類似工具全站掃描，找出所有超過 2 跳的重定向鏈，直接修成一跳。
網站速度太慢：Googlebot 的等待時間
Googlebot 等待伺服器回應的時間不是無限的。如果 TTFB（首字節時間）持續超過 2 秒，Google 會降低對這個網站的爬取頻率。不是說排名直接掉，但爬取變少就代表新內容被發現的速度變慢、修復問題的確認也要更久。
一個常見的誤區是，很多網站主花大量時間優化頁面載入的前端速度（CSS 動畫、圖片壓縮），但忽略了 TTFB。TTFB 是伺服器接到請求後回傳第一個位元組的時間，主要受伺服器運算能力、資料庫查詢、快取設定影響。Googlebot 最在意的是這個時間，不是頁面整體載入完成的時間。
孤島頁面：沒有連結指向的頁面
如果一個頁面除了 Sitemap 之外，沒有任何其他頁面的連結指向它，Googlebot 幾乎不會定期重訪。Sitemap 可以讓 Google 發現這個 URL，但如果頁面完全孤立，Google 也可能降低它的爬取優先順序。
根據 SEO 爬取分析工具 Botify 的研究數據，平均只有 5 條以下內部連結的頁面，被 Google 忽略的機率明顯較高。內部連結不只是 UX 問題，也是爬取效率的核心訊號。
Search Console 的爬取報告怎麼看
GSC 裡有三個和爬取直接相關的工具，但很多人只知道第一個。了解這三個工具的差別，是診斷爬取問題的基本功。想深入了解 GSC 的完整功能，可以先看 GSC 是什麼 這篇的基礎介紹，再回來這裡做爬取診斷。
爬取統計資料報告
路徑：GSC 左側選單 → 設定 → 爬取統計資料
這個報告顯示 Google 在過去 90 天裡爬取你的網站的狀況，包含每日請求次數、下載量、平均回應時間。正常情況下，這三條線應該相對穩定。如果某天爬取量突然暴跌，通常代表伺服器出了問題或 robots.txt 被修改了。
這裡是關鍵：看爬取統計時，同時注意「依回應分類」的分頁。如果有大量 5xx 或重定向次數突然增加，就要順著這條線去查原因。
索引涵蓋範圍報告：6 個「已排除」狀態的含義
路徑：GSC 左側選單 → 索引 → 網頁
這個報告把你所有已知的 URL 分成四個狀態：Valid（有效）、Valid with warnings（有效但有警告）、Excluded（已排除）、Error（錯誤）。大部分的問題藏在「已排除」這一欄。Google Search Console 完整教學 裡有更詳細的 Coverage 報告操作說明。
最常見的 Excluded 原因和對應行動：
- Crawled - currently not indexed（已爬取，目前未收錄）：Google 爬完了，但決定暫時不收錄。通常代表內容品質不足或是新頁面等待評估。先確認頁面內容是否有實質價值，再等幾週看看是否自動改善。
- Discovered - currently not crawled（已發現，目前未爬取）：Google 知道這個 URL 存在，但還沒有去爬。通常是佇列排隊中，或是爬取預算不足。對重要頁面可以用 URL 檢查工具手動要求爬取。
- Duplicate without user-selected canonical（重複，未選取標準版本）：頁面是重複內容，而且沒有 canonical 標籤，Google 自己選了一個版本作為代表頁。檢查是否需要加 canonical 標籤指向正確的版本。
- Excluded by noindex tag（noindex 已排除）：頁面有 noindex 標籤，Google 正確執行你的指令。確認是否是預期的設定，如果不是，移除 noindex。
- Blocked by robots.txt（robots.txt 已封鎖）：robots.txt 阻止了爬取。確認這個 URL 是否真的要被封鎖，還是誤封。
- Alternate page with proper canonical tag（具有適當標準標籤的替代頁）：頁面有 canonical 指向另一個 URL，Google 把它當成替代版本，不獨立索引。通常是正常行為，除非 canonical 指錯了對象。
URL 檢查工具：即時測試一個頁面的爬取狀態
在 GSC 上方搜尋框輸入任何頁面 URL，就可以看到這個頁面目前的索引狀態、上次爬取時間、canonical 設定、以及 AMP 狀態。
更重要的是「測試即時網址」按鈕，Google 會即時發起一次爬取，讓你看到 Googlebot 現在實際看到的頁面內容。這個工具在懷疑 robots.txt 或 noindex 問題時特別有用，因為你能看到 Googlebot 的實際視角，而不只是看你自己瀏覽器看到的版本。
提升爬取效率的 5 個具體做法
改善爬取效率不是一次性的工作，而是架構層面的持續維護。下面 5 個做法，每一個都有對應的機制理由，不只是清單。
1. 提交並維護正確的 XML Sitemap
Sitemap 不保證收錄，但確實能加速爬取。原理是，Google 不需要靠連結慢慢爬到你的頁面，可以直接從 Sitemap 裡看到所有 URL 清單和更新時間。
Sitemap 裡的 URL 必須是有效的、正式的 URL，有幾個常見的坑：
- 把 noindex 的頁面也放進 Sitemap（Google 看到矛盾訊號，會混亂）
- 把 404 或重定向的 URL 放進 Sitemap
- Sitemap 超過 50,000 個 URL 或 50MB 沒有分割
- lastmod 日期沒有隨內容更新而更新（Google 會慢慢不信任你的 lastmod）
2. 壓縮內部連結深度
連結深度是指從首頁出發，需要點幾次才能到達某個頁面。Google 對深層頁面的爬取需求度較低，因為這些頁面通常 PageRank 也低。
一般建議重要頁面的連結深度不超過 3 clicks（首頁 → 分類頁 → 文章頁）。對大型網站來說，用導覽麵包屑（Breadcrumb）和橫向相關文章連結，是壓縮深度的常見手法，同時也符合使用者體驗設計。
3. 清理重定向鏈和 4xx 錯誤
用爬取工具（Screaming Frog 免費版支援 500 個 URL）掃描整個網站，找出所有 4xx 錯誤頁面和重定向鏈。4xx 頁面要修：如果是有效的舊 URL 被刪除，做 301 重定向到最相關的現有頁面；如果是真的已廢棄，回傳 410 告訴 Google 這個頁面永久消失了，讓 Google 比 404 更快從索引裡移除。
重定向鏈盡可能壓縮成一跳。A→B→C 改成 A 直接跳到 C，減少 Googlebot 的等待時間，也減少 PageRank 在中間跳轉點的損耗。
4. 提升伺服器回應速度
TTFB 目標是在 200ms 以內，超過 500ms 就應該認真排查。常見做法：啟用頁面快取（WordPress 可用 WP Rocket 或 LiteSpeed Cache）、升級到有 SSD 的主機、把靜態資源搬到 CDN。
有個 B2B 網站的情況是，他們在高流量時段 TTFB 會飆到 3-4 秒，而 Googlebot 也是在這段時間最常來爬（因為流量高代表需求度高）。結果就是每次 Googlebot 來都遇到慢速伺服器，爬取頻率持續下降。解法是把資料庫查詢優化加上 Redis 快取，TTFB 降到 150ms，一個月後爬取頻率回升了。
5. 整理 robots.txt，只擋真正不需要的路徑
定期審查 robots.txt，問自己每一條 Disallow 規則的理由是什麼。很多 robots.txt 裡有歷史遺留規則，當初可能有意義，但現在那個路徑已經不存在或已經有其他方式管理。
封鎖 CSS 和 JS 是最危險的做法。Google 需要渲染你的頁面才能完整理解內容，如果關鍵的 JS 被封鎖，Googlebot 看到的和使用者看到的會差很多，這個落差有時候很難從 GSC 的報告裡察覺，需要用 URL 檢查工具的「測試即時網址」才看得出來。
JavaScript 網站的特殊爬取挑戰
如果你的網站用 React、Vue 或 Angular 建的，爬取問題的複雜度會直接升一個等級。這不是說 Google 爬不了 JavaScript，而是 Google 爬 JS 的方式和爬普通 HTML 完全不同，而且這個差異有很多潛在的陷阱。
Googlebot 的兩波渲染是什麼
Googlebot 爬取 JavaScript 網站時分兩波進行。第一波是普通的 HTML 爬取，Googlebot 下載 HTML 原始碼分析。如果頁面是用 JavaScript 動態生成的（CSR，客戶端渲染），第一波抓到的 HTML 通常幾乎是空的，或只有最基本的 shell 結構。
第二波是 JavaScript 渲染。Googlebot 把第一波爬取到的頁面放進一個獨立的渲染佇列，等到資源允許時，才用 Chromium 把頁面的 JavaScript 全部執行一遍，生成最終內容。問題在於，這第二波可能在第一波爬取的幾天甚至幾週後才執行。
這個延遲的實際影響：你的頁面發布了，第一波 HTML 爬取後，Google 看到的是空頁面，所以沒有收錄。等到第二波渲染完，Google 才看到真正的內容，再決定要不要收錄。這中間可能有 1-4 週的空窗期。
SPA 和靜態/SSR 頁面的爬取差異
| 渲染方式 | 第一波爬取內容 | 索引速度 | 建議 |
|---|---|---|---|
| CSR（客戶端渲染，純 SPA） | 空 HTML shell | 慢（等第二波） | 不建議 SEO 關鍵頁面 |
| SSR（伺服器端渲染） | 完整 HTML 內容 | 快 | SEO 友善，推薦 |
| SSG（靜態生成，如 Next.js） | 完整 HTML 內容 | 最快 | SEO 最友善 |
| ISR（增量靜態再生） | 完整 HTML | 快 | 適合內容更新頻繁的頁面 |
之前有個 Vue SPA 的案例，整個網站的 meta tag 和正文都靠 JavaScript 動態生成。Googlebot 第一波抓到的 HTML 裡連 title 都沒有，只有一個空的 <div id="app">。等到第二波渲染完，才看到完整內容。這個網站剛遷移過來後，索引量掉了近 40%，花了兩個月才完全恢復。
怎麼檢查你的網站是否有 JS 渲染問題
最直接的方法：在 GSC 裡用 URL 檢查工具，點「測試即時網址」，然後選「HTML」和「截圖」兩種視角比較。HTML 視角是 Googlebot 第一波看到的，截圖是渲染後的版本。如果兩者差異很大，就代表你的內容依賴 JavaScript 渲染。
第二種方法：在瀏覽器裡，把 JavaScript 停用（Chrome DevTools → Settings → Preferences → Debugger → Disable JavaScript），重新整理頁面，看到什麼就是 Googlebot 第一波看到的。如果頁面幾乎是空的，你有 JS 渲染問題。
這步驟不能跳過：確認後，和開發團隊討論是否可以為 SEO 關鍵頁面（首頁、重要分類、產品詳情）開啟 SSR 或預渲染（Pre-rendering），把 HTML 內容在伺服器端就準備好，不讓 Googlebot 等第二波。
常見問題
Googlebot 多久會重新爬取我的網站？
沒有固定時間表。對更新頻繁、有高品質外部連結、伺服器穩定的網站，Google 可能每天多次回訪。對長期沒有更新的低流量網站，可能幾個月才爬一次。提升爬取頻率最直接的方法，是讓頁面內容定期更新，並確保伺服器回應速度穩定。
爬取了但沒有收錄，應該怎麼辦？
先確認頁面是否有 noindex 標籤、canonical 是否指向別的 URL、以及內容是否有實質價值。在 GSC 的 URL 檢查工具查看 Googlebot 看到的版本，確認內容是否正確渲染。如果一切正常，可能只是 Google 還在評估，等幾週再觀察。
robots.txt 的 Disallow 會讓 Google 刪掉已索引的頁面嗎？
不會。robots.txt 只阻止爬取，不阻止索引，也不會讓已索引的頁面被移除。如果你想讓 Google 移除一個頁面，需要回傳 410 狀態碼，或在頁面 HTML 裡加 noindex 標籤，讓 Googlebot 爬到後自行移除。只靠 robots.txt，已索引的頁面會繼續存在於搜尋結果。
小型網站（100 頁以下）需要擔心爬取預算嗎？
基本上不需要。Google 對小型網站的爬取資源是夠用的，爬取預算問題通常在幾千頁以上才會浮現。小型網站更值得優先關注的是內容品質、內部連結結構和頁面速度，這些對排名的直接影響更大。
Sitemap 提交之後多久會被爬取？
通常幾天到幾週。Sitemap 提交後，Google 會把裡面的 URL 加入爬取佇列，但不保證立刻爬取，也不保證爬完就收錄。GSC 的 Sitemap 報告會顯示 Google 最後一次讀取你的 Sitemap 的時間，以及從中發現了多少 URL。
爬取速度和網站排名有直接關係嗎？
間接有關係，但不是直接排名因素。爬取頻率影響的是新內容被發現和索引的速度，不直接決定排名。但如果伺服器太慢導致爬取頻率下降，新發布或更新的內容要等更久才能反映在搜尋結果裡，這對時效性重要的內容影響較大。
如何用 Search Console 手動要求 Google 爬取某個頁面？
在 GSC 上方搜尋框輸入目標 URL，進入 URL 檢查工具，點「測試即時網址」確認爬取沒有問題後，再點「要求建立索引」。這個功能每天有使用次數限制，建議只對真正重要的頁面使用，或是在大規模更新後針對關鍵頁面送出。
什麼是 Crawl Anomaly？出現代表什麼？
Crawl Anomaly 是 GSC 爬取統計報告裡的一種回應分類，代表 Googlebot 在爬取時遇到了無法正確分類的錯誤，通常是伺服器回傳了不預期的狀態碼或連線異常。偶爾出現正常，如果數量突然大增，建議查伺服器日誌找出問題原因。
動態生成的網址（帶參數的 URL）會影響爬取預算嗎？
會，而且影響相當大。URL 參數（?sort=price&color=red 這類）如果沒有管控，會產生大量內容相似的 URL 變體，讓 Googlebot 把配額浪費在重複頁面上。解法是在 GSC 的舊版 URL 參數設定裡告知 Google 哪些參數不影響內容，或直接用 canonical 標籤把所有變體指向無參數的標準版 URL。
伺服器日誌能用來分析爬取問題嗎？
可以，而且這是最直接的方式。伺服器 access log 裡記錄了所有對你網站發出的請求，Googlebot 的請求可以用 user agent 篩選出來。你可以看到 Googlebot 實際爬取了哪些 URL、爬取頻率、回傳狀態碼，這些資訊比 GSC 報告更接近原始數據。Screaming Frog Log Analyser 是一個常用的日誌分析工具，適合中大型網站做爬取稽核。
如果你的網站使用 JavaScript 框架，Googlebot 的爬取和索引行為會有額外的渲染步驟需要確認。延伸閱讀：JavaScript SEO 診斷指南：JS 網站的爬取、渲染與索引問題。
如果你想用工具對網站做全站爬取分析，Screaming Frog SEO Spider 完整教學 整理了 12 個頁籤的診斷流程與修復優先順序，適合搭配爬取概念一起閱讀。