檢索預算（crawl budget）是 Google 願意且能夠在一段時間內檢索的網址數量，本身不是排名因素。
Google 現行文件把它拆成兩條獨立的軸：檢索容量上限（capacity limit，又稱 hostload 或主機負載）與檢索需求（demand）。
伺服器回應時間與錯誤率決定容量上限；更新頻率、品質與規模決定需求。
多數中小型網站根本不會觸及容量上限，真正該認真看待的是大型網站與高更新頻率站點。
「檢索預算」聽起來像一個會被消耗的配額，其實是 Google 在「能抓多少」與「想抓多少」兩條軸上的動態調度結果。Google 在 2026 年 7 月更新了檢索預算相關文件，把舊的 large-site-crawling-budget 頁面改組成《檢索預算管理》，並把兩條軸的觸發訊號寫得更明白。理解這兩條軸，才知道該改善伺服器回應速度，還是該提升內容品質，也才知道自己的站到底需不需要擔心。官方現行措辭、HTTP 304 機制、AI 爬蟲時代的擠壓效應，以及常見的 robots.txt 與 noindex 誤解，正是幾個最常被講混的環節。
文章目錄
檢索預算的核心定義：能抓，加上想抓
Google 從 Gary Illyes 在官方部落格發表的基礎文章起，就一直把檢索預算定義為「Googlebot 能抓且想要抓的網址集合」。這個定義到 2026 年的現行文件仍然一致，只是用詞從早年的檢索速率限制（crawl rate limit）演進成更完整的檢索容量上限（crawl capacity limit，又稱 hostload、主機負載）。
能抓，是技術問題：伺服器多快、多穩、能同時開多少連線。想抓，是價值問題：這個站的內容有多新鮮、多重要、對使用者多相關。Google 在現行文件把這兩條軸寫得很直接：先給每個網站同一個保守的預設容量上限，然後觀察網站回應穩不穩定、快不快，再隨時間自動調整。這套調度邏輯可以回推到更早的 索引系統演進，核心精神一直是「在不大爆伺服器的前提下，盡可能抓到值得抓的內容」。
也因為兩條軸獨立，常見的「我內容寫得好，檢索預算就會變大」其實只對了一半。內容品質影響的是 Google 想不想來抓（demand），伺服器回應速度影響的是 Google 能不能多抓（capacity）。把這兩者混在一起，就會把力氣花在錯的方向。
容量與需求：兩條不能混為一談的軸
把兩條軸放在一起比較，差異最清楚：
| 比較軸 | 檢索容量上限（capacity limit／hostload） | 檢索需求（demand） |
|---|---|---|
| 本質 | Google 能從你伺服器抓多少 | Google 想不想抓你這個站 |
| 起始 | 每站同一個保守預設值 | 依站規模、更新頻率、品質、相關性計算 |
| 調升訊號 | 回應時間穩定或改善、TTFB 低、回應一致 | 持續更新、品質提升、規模合理、相關性高 |
| 調降訊號 | latency 變長、5xx、HTTP 429 | 內容停滯、品質低落、大量低價值網址 |
| 共用範圍 | 跨所有 Google 爬蟲共用、每個 hostname 獨立 | 每個爬蟲各自有 demand，按 Google 產品分配 |
| 你能做什麼 | 壓低回應時間、上 HTTP 快取、回 304 | 刪減無價值網址、穩定更新有價值的內容 |
這張表把 Google 現行文件最關鍵的一句話拆開來看：雖然每個爬蟲的 demand 不同，但容量上限是所有 Google 爬蟲共用的同一個池子，某一個爬蟲需求高，會擠壓其他爬蟲可用的額度。網站規模屬於 demand、更新頻率屬於 demand、頁面品質也屬於 demand；影響容量上限的只有回應時間與錯誤率。
這條區分重要，因為它決定改善的方向。如果你發現 Googlebot 抓得少，先問是回應變慢了，還是內容沒人想看；前者去調伺服器與快取，後者去清理低價值頁面、提升更新頻率，而不是兩個一起做然後不知道哪個有效。把這條因果想清楚，比記住任何 SEO 清單都實用。
Google 近期更新了什麼，以及為何不能逐條考證
舊的官方文件路徑 developers.google.com/search/docs/crawling-indexing/large-site-crawling-budget 已經回 404，整份文件被改組成新的 large-site-managing-crawl-budget，現行英文標題是 “Crawl Budget Management | Google Crawling Infrastructure”，繁中版標題是「檢索預算管理 | Google 檢索基礎架構」，被併入新的「Google 檢索基礎架構」文件群。頁面底部顯示 Last updated 2026-07-22，也就是近期確實更新過。
不過 Google 並沒有隨頁提供 changelog，所以沒辦法逐條比對「哪一句改成什麼」。可以確認的是現況文件已經把容量上限與需求兩條軸寫得更清楚，並把 hostload 明確定義為「並行連線數乘以持續時間」這個綜合指標，而不只是早年「同時連線數」的口語描述；至於回應時間（含 latency 與 TTFB）是另一條獨立的 Crawl health 訊號，決定這個上限要不要調升或調降。如果想看 Google 自己怎麼說，現行官方文件是唯一權威來源。
對讀者來說，「文件近期更新過」比「改了哪幾行」更重要。現況文件的措辭直接影響你怎麼診斷自己的站，而不是去考據版本差異。如果你看到網路上有人宣稱「Google 這次改了三件事」卻沒有官方 changelog 來源，那多半是推測，不是官方聲明。把這條底線抓穩，比較不會被各種二次解讀帶著走。
哪些站根本不用擔心檢索預算
這是多數文章沒講清楚、卻最該先問的問題。Google 在 2017 那篇文章就明說：多數網站根本不用擔心檢索預算。實務上的判準不是單一頁數門檻，而是幾個訊號同時出現。
不用擔心的情況大致是：網站規模在數千頁以內、更新頻率正常、沒有大量重複網址或篩選頁面、Search Console 的檢索統計資料裡沒有主機負載警示、Page Indexing 報告裡「Discovered – currently not indexed」佔比不高。這種站 Googlebot 通常抓得很從容，再怎麼調校檢索預算也感覺不到差異。
真正該認真看待的有幾種場景。第一是電商與大型內容站，動輒數萬到數百萬網址，faceted navigation（篩選導覽）會組合出大量變體頁面。第二是高更新頻率的資訊站，例如新聞、論壇、社群動態。第三是網站剛改版或大規模遷移，短期內出現大量新網址。第四是你在 GSC 看到主機狀態亮黃燈或紅燈、或 URL Inspection 出現 hostload 相關訊息。這些情境才值得花力氣做檢索層面的工程。
如果你的站不在這幾種場景裡，與其花心力調檢索預算，不如把時間花在 技術 SEO 基礎 與 常被忽略的技術錯誤。判斷門檻永遠比盲目調校重要，這條原則在 SEO 圈被反覆驗證。
提升容量上限：把回應時間與 HTTP 快取做對
容量上限是 Google 觀察你伺服器健康後決定要不要放寬的，所以你能做的就是讓它看起來健康。Google 現行文件給出的觸發條件很明確：網站回應穩定、回應時間（含 latency 與 TTFB）穩定或改善，容量上限就會調升；回應變慢、回 5xx、或回 HTTP 429，上限就會調降，Google 會減少檢索。
回應時間裡最關鍵的是 TTFB（Time to First Byte，第一位元組時間）。web.dev 給的診斷門檻是 good 小於等於 0.8 秒、poor 大於 1.8 秒（以 p75 計算）。Googlebot 看到的回應時間也差不多落在這個區間，Search Console 的檢索統計資料會顯示平均回應時間，John Mueller 粗略提到的目標大約在 100ms 上下；逼近 1000ms 就代表 Googlebot 沒辦法爬得那麼多。這條數字與 web.dev 對 TTFB 的診斷門檻完全重疊，不是另一套標準；TTFB 本身不是 Core Web Vitals 的官方指標（CWV 是 LCP、INP、CLS），但它會直接影響 LCP，也是 Googlebot 評估回應健康時看的同一條數字。
把回應時間壓下來的方法不外乎是調校資料庫查詢、升級 PHP 或應用伺服器、上 CDN、啟用伺服器端快取、移除外掛衝突。對 WordPress 站來說，網站速度 與 程式碼層級調校 裡的 TTFB 改善手法幾乎都會同時提升檢索容量。這也是為什麼技術圈常說「對 Googlebot 友善」與「對使用者友善」在這條軸上是同一件事，兩者都看同一個回應時間。
Google 在現行檢索預算文件裡列的三項最佳做法之一，就是支援 HTTP 快取與 304 Not Modified 狀態碼。當頁面自上次檢索後沒變，伺服器回 304 告訴 Google 重用快取版本，省下頻寬與伺服器運算。對 Googlebot 來說，這代表同樣的容量上限可以「處理」更多網址，因為每個未變動的網址只花很少時間就完成重新驗證。
304 的觸發機制記在 Google 檢索基礎架構的另一份官方文件裡。Google 支援 HTTP 標準的啟發式快取，具體透過兩組標頭運作：ETag 回應標頭配上 If-None-Match 請求標頭，以及 Last-Modified 回應標頭配上 If-Modified-Since 請求標頭。Google 自己的建議是兩組都設，不要管爬蟲偏好哪一個。
兩組標頭各有特性。ETag 是資源某個特定版本的不透明識別字（通常是內容雜湊），每次請求 Googlebot 把上次的 ETag 放進 If-None-Match 送回，若仍與伺服器目前的 ETag 相符就回 304。Last-Modified 是資源上次變更時間，解析度只有 1 秒，遇到部署時大量檔案被重新產生但內容其實相同，時間戳仍會更新，這時 ETag 比較可靠。多機部署要特別注意 ETag 各自生成的問題：如果每台機器算出不同的 ETag，跨機的 304 會失效，要改用基於內容雜湊的共用 ETag，或關掉 ETag 改靠 Last-Modified。
當 If-None-Match 與 If-Modified-Since 同時存在時，依 HTTP 標準 If-None-Match 優先。這裡還要分清楚 Cache-Control 指令：max-age 是對所有快取（瀏覽器加共享）都有效的時間；s-maxage 只對共享快取（CDN、反向代理）生效，並會在那裡覆寫 max-age；no-cache 是「使用前必須重新驗證」而不是「不儲存」；no-store 才是真正完全不儲存。
理解了 304 與 Cache-Control，再往上一層是 CDN。私有（瀏覽器）快取只服務單一使用者；共享快取（CDN edge、反向代理如 Varnish）用一份回應服務多名使用者。當 Googlebot 撞到 CDN edge 命中，那個請求根本不會到源站，也就完全不吃源站的 hostload，Googlebot 仍會記錄這次請求與回應，但源站無感。對檢索預算來說，這是很實際的槓桿。常見的 HTML 快取模式是「瀏覽器 max-age 設很短或 0、CDN s-maxage 設長」，讓瀏覽器每次重新驗證、CDN 卻能長時間供應新鮮副本。Googlebot 拿到的是 CDN 上的那份，源站只要在背景 refresh 即可。Cloudflare、Fastly、Varnish 都能用這個模式，但登入或個人化內容一定要標 private，否則會把不同使用者的資料混進共享快取。
附帶一提，不少站長擔心 Cloudflare 會不會擋 Googlebot。預設情況下 Cloudflare 把 Googlebot 列為 verified bot 不擋；但如果你設了過度激進的 rate-limit 或 bot fight mode，可能誤判 Googlebot 為異常流量，這時就要在規則裡放行已知爬蟲。這條設定看似邊角，卻是台灣大量使用 Cloudflare 的站長最常踩到的雷。
與容量上限相關的另一個細節是 hostname 切分。Google 對 site 的定義是 unique hostname，這意味著 www.example.com、m.example.com、code.example.com 是各自獨立的檢索預算。如果你把內容分散在多個子網域，每個子網域拿到的是保守預設容量，而不是共享一個大池子。這對 子網域與子目錄 的決策有實際影響：子目錄共用一份 hostload，子網域各自獨立。對小型多語系站點，把所有語系放在子目錄通常比分散到子網域更省檢索資源。另一個極端是用單一 hostname 承載太多功能（主站、API、媒體資源全部擠在同一個 hostname），這會讓所有功能共用同一個 hostload 上限，把靜態資源切到 CDN 或專用 hostname 可以釋放主站的容量給 HTML 頁面。
提升需求：更新頻率、品質與規模
談完容量，回頭看需求這條軸。Google 現行文件明說，Googlebot 的需求因素是網站規模、更新頻率、頁面品質與相關性，而且是「與其他網站比較後」的相對值。這條軸改善的重點不是假裝很活躍，而是真正提升 Google 認為值得抓的比例。
幾個有效方向。第一是穩定產出有價值的新內容，讓 Google 學會「這個站每週都會長出新東西，值得常來」。第二是更新舊內容裡過時、錯誤或單薄的段落，Google 對 staleness（陳舊度）有感，重新檢索後發現實質更新會調整需求優先序。第三是減少低價值網址佔比，包括 soft 404（軟性 404）、重複內容、篩選導覽變體、站內搜尋結果頁、無實質內容的分類與標籤頁。第四是確保 sitemap 裡的 lastmod 真實反映內容變動，而不是每天自動刷新卻沒實際更新。Google 在 sitemap 官方文件裡明說，人為頻繁改日期對 demand 沒有幫助，反而會讓 lastmod 失去參考價值。
實作上，canonical 與 soft 404 是兩個最常被忽略的著力點。當多個網址指向高度相似的內容（例如同一商品的顏色與尺寸變體頁、行動版與桌面版的關係、或列印友善版本），正確指向 canonical 可以告訴 Google「這些是同一份內容，請把需求集中在主版本」，等於把 demand 集中而不是分散。soft 404 則是回 200 卻沒有實質內容的頁面，例如「找不到結果」的搜尋頁、被清空的分類、過期的活動頁；這類頁面會被 Google 計入需求計算卻不帶價值，把它們改成真正的 404 或 410、或補上實質內容，等同釋出 demand 額度給值得抓的頁面。
要把這條軸想成「值得抓的網址佔比」，而不是「發文頻率」。一個每週更新一篇深度文章的站，比一個每天搬運十篇薄內容的站，更容易拿到穩定的 demand。內容品質的累積效果也會回頭強化 站內 SEO 的其他面向，但這是 ranking 的事，不是檢索預算本身。把這兩件事分清楚，才不會誤以為「提升檢索預算就會排名變好」。
跨爬蟲共用容量：AI 時代的具體含義
Google 在現行文件寫了一句很容易被忽略的話：雖然每個爬蟲的 demand 不同，但容量上限是所有 Google 爬蟲共用的一個池子。也就是說，Googlebot、AdsBot、Google Shopping 各自有想抓的東西，但它們從你伺服器抓的總量，受同一個 hostload 限制。某一個爬蟲需求高，就會壓縮其他爬蟲能用的額度。
這條機制在 AI 爬蟲時代有新的含義。GPTBot、ClaudeBot、PerplexityBot、Google-Extended 這些 AI 爬蟲不是 Google 系統，不會直接吃 Google 的 hostload，但它們會吃你源站的同一份頻寬、CPU 與 TTFB。當 AI 爬蟲流量爆衝，源站回應變慢，Google 觀察到的 latency 與 TTFB 也會變差，進而壓低 Google 對你站的容量上限。這是間接擠壓，但效果真實，也直接關係到 加速索引與內容品質 的穩定度。
對站長來說，這代表兩件事。第一，AI 爬蟲要不要擋不再只是「要不要被 AI 摘要引用」的 AEO 問題，還牽涉到 Google 檢索與索引的容量穩定，與「好的 SEO 是否就等於好的 AI 搜尋曝光」這個 SEO 與 GEO 的交集 直接相關。第二，如果你想觀測 AI 爬蟲對源站的影響，應該在伺服器端或 CDN 層記錄各個 bot 的請求量與回應時間，而不是只看 Google Search Console，GSC 只看得到 Google 爬蟲。
實務上的折衷是給 AI 爬蟲單獨的速率限制，例如在 CDN 層針對 GPTBot、ClaudeBot 各自設上限，避免它們把源站打到回應變慢。以 Cloudflare 為例，可以用 WAF 自訂規則比對 cf.botManagement.verifiedBot 或 http.user_agent，對特定 AI bot 設每分鐘請求數上限，超過才回 429，而不是無上限放行。這比直接用 robots.txt 全擋 AI 爬蟲更細緻，也能兼顧 AI 搜尋曝光與 Google 檢索穩定。如果你完全不在乎 AI 摘要，擋掉 AI 爬蟲是合理的；如果你在乎，就要做速率管理而不是放任。
要判斷 AI 爬蟲目前對你源站的影響，最直接的方式是看 CDN 或源站日誌裡各 bot 的請求佔比與尖峰時段。如果 AI 爬蟲在特定時段吃掉可觀的頻寬，而 GSC 同一時段又顯示主機狀態波動，這條擠壓效應就差不多被驗證了。反之，如果 AI 爬蟲流量穩定、源站回應時間也穩定，就代表你的站還在駕馭範圍內，不必急著設限。
用 Search Console 檢索統計資料實際診斷
講了這麼多機制，落地還是要會看報表。Search Console 的檢索統計資料（Crawl Stats）報告顯示總檢索要求數、總下載位元組、平均回應時間，可以依回應碼、檔案類型、檢索目的、Googlebot 類型分組，並提供 90 天主機狀態與範例網址。這份報告只對根層級資源（Domain property 或根層級 URL-prefix）開放，子路徑資源看不到，這是常見的誤解。
看這份報告的順序大致是這樣。先看主機狀態是不是綠燈，黃燈或紅燈代表 Google 已經觀察到回應不穩。再看平均回應時間的趨勢，是不是在慢慢爬升；如果是，通常代表源站或資料庫有退化。接著看依回應碼分組的檔案類型，如果 5xx 或 429 佔比突然變高，要立刻找原因。最末看依檢索目的分組，了解 Google 主要在抓哪些類型的網址，與你的重要頁面是否一致。如果同時收到 GSC 速度通知，多半是同一個源頭的問題。
URL Inspection 工具能看個別網址的狀態。如果 URL Inspection 出現「Hostload exceeded」訊息，代表 Google 當下對你站的容量已達上限，連 URL Inspection 的即時測試都無法執行，這是大站才會看到的訊號。另一個相關訊號在 Page Indexing 報告的「Discovered – currently not indexed」，代表 Google 知道這個網址存在但還沒抓。如果這個分類佔比偏高，可能是 demand 不足或 capacity 不夠，要交叉比對主機狀態判斷。
有時候報表看起來一切正常，但個別網址還是沒被索引。這時要回頭看是不是網址本身讓 Google 沒有動機抓：頁面是不是距離主分類太遠、內部連結是否稀薄、是不是有價值的 anchor 不夠、是不是被 canonical 或 noindex 指到別處。檢索預算解決的是「Google 有沒有頻寬與動機來抓」，沒辦法解決「Google 來了，但認為這個頁面不值得索引」的問題。
如果報告數字都正常，你卻還是懷疑「Google 都不來抓」，多半不是檢索預算的問題，而是 Googlebot 被擋、已索引卻無內容 或 JavaScript 連結爬取 的問題。Googlebot 不會爬的頁面，往往是它根本看不到的頁面，這跟「檢索預算用完」是兩回事。
robots.txt、noindex 與 404：誰才真的省預算
這裡是台灣多數文章講錯的地方。用 robots.txt 封鎖 URL 可以阻止它被檢索，但「不會」把省下來的額度挪給其他頁，除非 Google 本來就已經觸及你站的容量上限。對一般站來說根本沒到上限，封不封鎖對其他頁面的檢索量沒有影響。這條精確機制幾乎沒有在地文章講清楚，多數停在「robots.txt 擋爬、noindex 擋索引」的二分。
noindex 更糟。Google 仍會發出請求、抓下頁面、看到 noindex 才丟棄，等於浪費一次 fetch。要從索引移除頁面，noindex 是正確指令；但如果是想「省檢索預算」，noindex 完全沒幫助，反而多花了一次抓取。這也是 robots.txt 與 noindex 經常被誤用的 重複內容 場景。
真正能釋出預算給重要頁面的做法，是減少無價值網址的存在。把重複內容用 canonical 收斂、把 soft 404 改成真正的 404 或 410、把篩選導覽加上 robots.txt 或 noindex 防止變體擴散、清理站內搜尋結果頁、把低品質分類頁整併。這些動作降低的是「Google 想抓的無價值網址數量」，讓有限的容量集中在有價值的頁面上。
至於「回什麼狀態碼給 Googlebot 才能讓它慢下來又不傷索引」，答案是 429 與 5xx（特別是 503）。429 與 503 會讓 Googlebot 暫時放慢，已索引的網址會被保留；但要注意，如果 5xx 或 429 持續過久，Google 最終仍會把這些已索引網址從索引移除，所以 503 只適合短期維護使用，不能當長期降速工具。一旦伺服器回到 2xx，Google 會逐步調回原本的檢索速率。相對之下，用 403 或 404 做 rate limiting 是錯的。4xx（429 除外）不會讓 Google 慢下來，而是讓該網址退出索引。如果你用 Cloudflare 或 WAF 的 rate-limit 規則對 Googlebot 回 403，等於在不知不覺中把自己的內容移出 Google。詳細的 HTTP 狀態碼 對應關係，可以對照 Google 官方的 HTTP 狀態碼與檢索行為文件。
執行清單與限制：依站點規模分流
不同規模的站，該做的事不同。把常見的站點類型、主要風險與對應動作整理在一起，重點不是把每欄都做完，而是先定位自己在哪一欄，再挑出真正會影響你站的少數幾項執行。
| 站點類型 | 主要風險 | 該做什麼 | 不需要做什麼 |
|---|---|---|---|
| 小站（數百到數千頁） | 幾乎無檢索預算風險 | 維持回應時間、定期更新有價值內容 | 大規模 robots.txt 工程、繁重的篩選頁清理 |
| 中型站（數千到數萬頁） | 重複網址累積、外掛浪費 | 上 CDN、清重複內容、定期看 Crawl Stats | 過度頻繁改 lastmod、壓縮 sitemap |
| 大型電商（十萬到百萬頁） | 篩選頁變體、soft 404、hostload exceeded | 嚴格篩選頁管理、404/410 清理、AI 爬蟲速率限制 | noindex 大規模封鎖、403 rate-limit Googlebot |
| 高更新頻率資訊站 | demand 排程擠壓 | 穩定 XML sitemap lastmod、穩定回應時間 | 把舊文章每週改一次日期 |
| 剛遷移或改版站 | 短期 hostload 波動 | 301 對應、維持 2xx、觀察主機狀態 | 同時大改 URL 結構與內容 |
這張表的重點不是逐條照做，而是先判斷你在哪一欄，再決定力氣花在哪裡。多數中小企業站、部落格、品牌官網都落在第一欄，那欄的「不需要做什麼」比「該做什麼」更重要，因為它告訴你不要過度調校。
WordPress 站的常見浪費
WordPress 是台灣市占最高的 CMS，也是檢索預算浪費的肥沃土壤。常見的浪費來源有幾個。第一是分頁與分類標籤 archive 自動產生的大量無價值頁面。第二是外掛造成的重複網址，例如同一篇文章有 ?utm_source、?share、?replytocom 等多種查詢字串版本。第三是 media attachment 頁面，每張圖都會自動產生一個 attachment URL，對 SEO 幾乎沒價值卻會被檢索。第四是搜尋結果頁被索引，產生大量 soft 404。
清理方向很具體。把無用的 archive 設為 noindex 或 canonical 到主分類；用 canonical 把查詢字串變體收斂到乾淨網址；在 WordPress 的閱讀設定把搜尋結果與 attachment 設為 noindex；移除沒在使用的佈景主題與外掛。這些動作都不直接增加檢索預算，但會讓 Google 願意抓的網址比例提高。更多細節可以參考 WordPress SEO 調校。
對 WordPress 來說還有一個隱藏好處：快取外掛（WP Rocket、LiteSpeed Cache、W3 Total Cache）通常會同時實作 304、ETag 與 CDN 整合，等於一次處理容量與需求兩條軸的常見問題。對本站這類已經上 LiteSpeed 的 WordPress 站長，這條幾乎是免費的槓桿。
哪些改善對檢索預算無感
並不是所有「技術調校」都會讓檢索預算變好。有些動作對使用者體驗有幫助，但對 Googlebot 的容量或需求幾乎沒影響，做之前要有心理預期。
壓縮 XML sitemap 不會增加檢索預算。把 sitemap 拆小、用 gzip 壓縮，是為了讓 Google 容易讀取，但 capacity limit 是依伺服器健康與 demand 計算，與 sitemap 是否 gzip 無關，不會因此多給額度。人為頻繁改頁面或改 lastmod 日期也騙不過 Google，Googlebot 會比對內容指紋，如果實質內容沒變，頻繁改日期只會讓 Google 學會「這個站的 lastmod 不可信」，反而降低 lastmod 在 demand 計算裡的權重。
把圖片壓到極小、把 CSS 與 JS 合併到極簡，對使用者體驗是好的，但對檢索預算影響有限，因為現代網頁的渲染資源（CSS、JS、XHR）都計入檢索預算，過度合併有時反而讓單次抓取變大。AMP 不是檢索預算的解藥；hreflang 是給同語系不同地區的訊號，也不會直接增加預算；結構化資料 是給排名與結果呈現用的訊號，跟檢索預算沒有直接關係。
遷移網站或大改 網站架構 時，檢索預算會出現短期波動，因為大量新網址同時出現，Google 需要時間重新建立 demand 模型。這段期間看到檢索量下降是正常的，不代表網站被懲罰，通常幾週內會回穩。如果你正好在 演算法更新 期間遷移，會更難判斷原因，建議錯開。
檢索、索引、渲染與排名：四件事的邊界
SEO 圈常把「檢索預算」「索引預算」「渲染預算」混用，其實是三個不同階段的資源，再加上排名訊號，是四件事。把它們拆開，才知道自己在處理哪一段，也才不會把「被索引」與「排名上升」混為一談。
檢索預算處理的是「Google 願不願意、能不能從你伺服器抓 HTML」。索引預算處理的是「抓下來的內容要不要被收進 Google 的索引庫」，這牽涉到品質判斷、canonical 判定、是否為重複或低價值內容，而不是頻寬。渲染預算處理的是「Google 處理 JavaScript、CSS 與圖片以理解頁面最終樣貌的運算資源」，Google 的 Web Rendering Service 會把執行 JavaScript 後的 DOM 拿來索引，而渲染佇列是有上限的，重度依賴 JS 渲染的頁面會排在渲染佇列裡等待。
對一般站來說，索引預算的實際表現是 GSC 的「Crawled – currently not indexed」與「Discovered – currently not indexed」兩個狀態，代表 Google 抓到了網址（或知道它存在），但還沒決定要不要收進索引。這時要處理的是內容品質、獨特性與內部連結，而不是繼續叫 Google 多抓幾次。渲染預算則對 JavaScript 連結的場景特別重要，如果重要連結是靠 JS 動態插入，Google 需要二次渲染才看得到，等於多消耗一份渲染資源。
把這幾個預算分清楚，就會知道為什麼「我的檢索預算很充足，卻還是沒被索引」不是檢索層的問題，也會知道 行動優先索引 與頁面體驗訊號為什麼獨立於檢索預算存在：它們是索引與排名層的訊號，不是「能不能被抓」的訊號。
Google 從 2017 年的 Gary Illyes 那篇文章起，就不斷重複一句話：檢索不是排名因素。檢索預算決定的是 Google 能不能、會不會來抓你的頁面；至於抓到之後要排第幾名，是完全另一套訊號。頁面沒被檢索，就不會被索引，也就不會出現在搜尋結果裡，所以檢索是進入結果的必要條件。但檢索得多、被抓得勤，並不會讓排名變好。Google 的排名系統看的是內容品質、連結、相關性、使用者體驗，而不是「這個站很常被爬」。
把這條邊界抓穩，就知道哪些調校是對的、哪些是白費。壓低 TTFB、上 CDN、回 304、清理低價值網址，這些都是對的，它們改善檢索健康，讓重要頁面更容易被收錄。但「為了提升排名而調檢索預算」這個命題本身不成立，因為檢索預算不是排名輸入。如果你的目標是排名，應該把同等心力放在 頁面速度與排名 與 行動裝置速度 這類真正的排名訊號上。
常見問題
Q：我的網站只有 500 頁，需要擔心檢索預算嗎？
幾乎不用。Google 對多數中小型網站都會給出從容的檢索量，500 頁的站除非有大量重複網址、篩選頁面或外掛造成的查詢字串變體，否則不會觸及容量上限。判斷方式是打開 GSC 的檢索統計資料看主機狀態與每日檢索量：主機狀態綠燈、檢索量穩定波動、重要頁面都能在 URL Inspection 看到「Indexed」就代表預算充足。與其調檢索預算，不如把時間花在內容品質、網站速度與技術基礎。
Q：為什麼 Googlebot 抓了頁面，卻還是沒被索引？
這通常是索引層的問題，不是檢索層。Googlebot 抓下頁面後會做品質、獨特性與意圖判斷，如果頁面被認定為重複、薄內容、soft 404、或價值低於已收錄的同主題頁面，就會進入「Crawled – currently not indexed」狀態。改善方向是補實內容、強化獨特性、用內部連結與 anchor 提升頁面主題訊號、檢查是不是被 canonical 或 noindex 指到別處，再請求重新檢索。
Q：robots.txt 跟 noindex，哪一個才能真正省下檢索預算？
都不會直接「省下來」給其他頁。robots.txt 封鎖的網址不會被檢索，但除非你本來就觸及容量上限，否則省下來的額度不會挪給其他頁；noindex 更糟，Google 仍會發出請求抓下頁面、看到 noindex 才丟棄，等於浪費一次 fetch。真正能釋出預算的做法是減少無價值網址的存在。
Q：GSC 的平均回應時間多少才算正常？
John Mueller 粗略提到的目標大約在 100ms 上下，逼近 1000ms 代表 Googlebot 沒辦法爬得那麼多。web.dev 給 TTFB 的診斷門檻是 good 小於等於 0.8 秒、poor 大於 1.8 秒（以 p75 計算）。如果你的回應時間在逐步爬升，就算還沒到紅燈，也該提早處理。
Q：用 Cloudflare rate-limit 對 Googlebot 回 403 會怎樣？
會把你的內容移出 Google 索引。4xx（429 除外）不會讓 Googlebot 慢下來，而是讓該網址退出索引。如果你真的需要對 Googlebot 降速，例如伺服器正在維修或被打爆，正確的狀態碼是 429 或 503，這兩個會讓 Googlebot 暫時放慢並保留已索引網址，等伺服器回到 2xx 後逐步調回原本的檢索速率；官方未公開明確時程，實務上多數站長回報落在數天到數週之間，但你的站可能不同。
Q：AI 爬蟲會吃掉我的 Google 檢索預算嗎？
不會直接吃，但會間接擠壓。GPTBot、ClaudeBot 這類 AI 爬蟲不是 Google 系統，不佔 Google 的 hostload，但它們會吃你源站的同一份頻寬、CPU 與 TTFB。AI 爬蟲流量爆衝會讓源站回應變慢，Google 觀察到的 TTFB 變差，會壓低對你站的容量上限。實務上建議在 CDN 層對 AI 爬蟲做單獨速率限制（例如每分鐘請求數上限，超過才回 429），而不是放任或全擋。
理解檢索預算的兩條軸之後，能做的第一步其實很樸素：打開 Search Console 的檢索統計資料，看主機狀態與平均回應時間。綠燈就先把心力放在內容與其他排名訊號；黃燈或紅燈才回頭處理伺服器回應與 HTTP 快取。檢索預算的調整是「天到週」為單位的動態過程，給自己至少四到八週觀察期再判斷調整有沒有效，比每天盯著數字更有意義，也更容易看出 SEO 見效時間 上真正的變化。
把這套觀念落地，還可以做一件成本低但效果長期累積的事：在伺服器端或 CDN 層持續記錄 Googlebot 與 AI 爬蟲的請求量、回應時間與狀態碼分佈，每個月定期回頭看趨勢。這份紀錄不只能驗證容量調整的方向是否正確，也能在 Google 下次更新檢索預算文件時，提供自己站台的實際資料對照，而不是只憑官方措辭推測。畢竟文件描述的是整套系統的一般化行為，你的站台真正會被怎麼對待，永遠要回到自己看到的數字。
