優化大型網站的爬取預算：Google 爬蟲資源分配原理與 5 個實務調整方向

爬取預算...這件事真的重要嗎？

最近很多人在談「爬取預算」[Crawl Budget]。老實說，我自己是覺得，這個詞有點被過度渲染了。Google 自己都說，對絕大多數網站來說，你根本不用擔心這件事。

不過呢...這個「絕大多數」顯然不包含我們。如果你手上管的是一個動不動就幾十萬、幾百萬頁的電商、新聞或內容平台，那爬取預算就從一個「理論名詞」變成一個「每天都在燒錢」的實際問題。真的。

簡單講，Googlebot 不是無限的。它分配給你網站的資源...就是那麼多。如果它把時間都浪費在一些沒用的頁面，像是帶有一大堆參數的篩選結果、過期的活動頁、或是根本一模一樣的重複內容...那你的重要頁面，比如新上架的商品、或是剛發布的重點文章，可能就要等很久...非常久，才會被看到。

所以，優化爬取預算，對我們來說，重點不是去「增加」那個總量，說真的，我們能做的有限。核心是「引導」。是把 Googlebot 這位很忙的客人，聰明地帶到你真正重要的房間裡。

先說結論：別想控制，要想引導

我們能做的，其實就是三件事：減少浪費、指明重點、確保通路順暢。下面這五個方向，算是我自己整理出來，比較實際的切入點。不是什麼高深的魔法，就是些硬功夫。

實務調整的 5 個方向

好，我們來一個一個看。這些不是步驟，比較像是你可以動的幾個控制桿。

1. 一切的基礎：誠實面對你的伺服器日誌 [Log Files]

這一步最無聊，但也最重要。真的，沒看日誌就做爬取預算優化，都是在通靈。你得知道 Googlebot 到底每天在你家幹嘛。

它最常去哪些目錄？是你預期的嗎？
它是不是花了一堆時間在爬一堆 `?filter=blue&size=xl` 這種帶參數的垃圾 URL？
伺服器回應給它最多的是 200 OK，還是其實有一大堆 404 [Not Found] 或 301 [Moved Permanently]？
它來的頻率跟你的主機健康狀況有關嗎？是不是主機一慢，它就懶得來了？

我自己是覺得，沒動手分析過 log，你做的所有決策都只是猜測。現在有很多工具可以用，從 Splunk、Screaming Frog SEO Log File Analyser 到一些開源的方案...重點是去看。去面對真相。

2. 被遺忘的王者：內部連結結構

大家都在講 Sitemap，但 Sitemap 對 Google 來說，更多是「建議」。真正決定一個頁面權重的，很大程度是你的內部連結。

一個被網站內幾千個頁面連結到的頁面，跟一個只在網站地圖裡出現的孤兒頁面，Google 會怎麼看？答案很明顯。

所以，檢查一下你的網站：

你的首頁、核心分類頁，是不是有清楚地連結到你的重點產品或文章？
你的麵包屑導航 [Breadcrumb] 結構清楚嗎？
文章跟文章之間，有沒有做相關內容的互連？
是不是有很多重要的頁面，要點個五六七八次才到得了？這對使用者和爬蟲都不好。

大型網站的內部連結是個大學問，但基本原則就是，把連結的「權重」，集中灌溉給你最重要的那些頁面。

3. 技術面的衛生習慣：狀態碼、Canonical 和 Noindex

這部分就是基本功了。但大網站的恐怖之處在於，基本功沒做好，問題會被放大一百倍。

重複內容：篩選、排序、追蹤碼...都會產生大量內容一樣但 URL 不一樣的頁面。用 `rel="canonical"` 標籤跟 Google 說清楚：「嘿，這幾個頁面，內容都跟這個標準版一樣，算它的就好。」
不想被看的內容：搜尋結果頁、使用者登入後的個人中心、購物車...這些頁面對 Google 沒意義。用 `noindex` 標籤直接告訴它「這頁不用收錄」。
消失的內容：過期的商品或活動頁，不要只是放著讓它變 404。如果這個內容是「永久」消失，而且你確定不會再有，可以考慮回傳 `410 Gone` 狀態碼。 Google 看到 410，會比 404 更快放棄這個 URL。不過這招要小心用，下手別太重。
搬家的內容：舊的 URL 換到新的了，務必用 `301 Moved Permanently` 做好轉址。不要用 302，那是暫時的。

這點跟我們在台灣看到的很多大型電商網站情況很不一樣，很多平台喜歡把下架商品直接變 404，但其實如果同類型商品還在，做個 301 轉到分類頁對使用者和 SEO 都更好。反過來說，美國的一些大型內容網站如 CNET 在做內容清理時，就比較積極地使用 410 來處理整個被裁撤的舊單元，這能更明確地釋放爬取資源。

4. 重新思考 Sitemap 的角色

Sitemap 不是萬靈丹。你丟一百萬個 URL 進去，Google 也不會照單全收。對大型網站來說，Sitemap 的角色更像是一個「訊號發射器」。

我的用法是這樣：

只放重要的東西：把 Sitemap 當成你的 VIP 名單。只放你希望 Google「優先」處理的標準化（Canonical）URL。
搭配 `lastmod`：誠實地告訴 Google 這個頁面最後的更新時間。如果你改了文章，就更新 `lastmod`。這會讓 Google 知道，喔，這個頁面有新東西，我該去看看。但千萬別亂寫，一直謊報更新時間，久了 Google 就不信你了。
拆分管理：不要一個 Sitemap 檔塞到底。按文章、商品、分類頁等不同區塊拆分成多個 Sitemap 檔，這樣在 Google Search Console 後台，你才能看清楚不同區塊的索引狀況。

5. 最終的瓶頸：主機效能與速度

前面做的再好，如果你的網站慢得像烏龜，Googlebot 也會失去耐心。Google 在它的文件中提到一個概念叫「Crawl capacity limit」或「host load」，簡單講就是你的伺服器能承受的爬取量上限。

如果 Googlebot 發現每次來你家，你家都反應很慢，甚至超時，它就會自己調低爬取頻率，免得把你家搞垮。這是一種保護機制。

所以，優化網站速度，特別是伺服器的回應時間（TTFB），不只是為了 Core Web Vitals 和使用者體驗，它也直接影響了你的爬取預算天花板。

一個簡單的檢查清單

在開始大刀闊斧之前，可以先問自己幾個問題：

檢查項目	我的觀察點
伺服器日誌分析	我真的知道 Googlebot 在看什麼嗎？還是我只是「覺得」我知道？是不是一堆 404 或參數頁？
索引狀況（Search Console）	「已索引」和「已發現但尚未建立索引」的頁面數量比例健康嗎？後者是不是異常地多？
網站結構深度	從首頁到我最重要的頁面，需要點幾次？超過 4 次可能就太深了。
重複頁面問題	隨便找個商品頁，在 URL 後面加上 `?from=test`，頁面內容會變嗎？如果不會，Canonical 標籤有設對嗎？
頁面載入速度（TTFB）	我的伺服器回應時間是多少？是不是時好時壞？Googlebot 體驗到的速度，可能比你想像的還慢。