谷歌在 2026 年 10 月 6 日改寫了「降低 Google 抓取頻率」文件。按更新日誌的說法，這次重組了緊急降速一節，並把 Retry-After 回應標頭的說明和範例直接寫進了這篇指南。日誌也說明 Retry-After 的支援不是新功能，原來寫在「暫停或停用網站」那篇裡，這次只是放到更容易找到的地方。對用小機器跑網站的人來說，這是一份值得收藏的官方「煞車」說明。
先找原因，再踩煞車
文件說，根據過去收到的回饋，抓取量突然暴漲最常見的原因是網站自身的 URL 設計：分面導航和各種排序、篩選功能，按日期生成大量 URL 的日曆，以及動態搜尋廣告的目標頁。谷歌建議先聯絡主機商、檢視伺服器最近的存取日誌，確認流量來源是不是這些情況。查日誌的思路可以參考 VPS CPU 佔用 100% 怎麼排查；如果來的其實是 AI 爬蟲或冒充的爬蟲，那是另一類問題，見 AI 爬蟲正在吃掉你的伺服器頻寬。
緊急降速：回傳 500、503 或 429
- 怎麼做：在短時間內（文件舉的例子是幾個小時，或 1-2 天），對谷歌的抓取請求回傳
500、503或429，而不是200。 - 效果：谷歌遇到大量這類狀態碼時，會對整個主機名稱（例如
subdomain.example.com）降低抓取頻率，回傳錯誤的 URL 和正常回傳內容的 URL 都算在內；錯誤減少後會自動恢復。 - Retry-After：回傳
503或429時可以帶上Retry-After，寫秒數（如Retry-After: 120）或一個 UTC 絕對時間，告訴爬蟲什麼時候再來。
代價也寫得很清楚
- 對搜尋來說，降速期間谷歌發現的新頁面變少，已有頁面重新整理變慢（比如價格、庫存的變化要更久才能反映出來），已刪除的頁面會在索引裡停留更久；對 Google Ads，廣告活動可能被取消或暫停，廣告可能無法投放。
- 不要超過 1-2 天。如果谷歌連續多天在同一個 URL 上看到這些狀態碼，這個 URL 可能被移出索引。
- 如果沒法對爬蟲回傳錯誤碼，可以提交特殊請求反映抓取量異常，但不能申請提高抓取頻率，而且處理可能要好幾天。
落到 VPS 上
回傳 503 要做在 Web 伺服器或應用程式這一層，只針對爬蟲、只在緊急時段生效，事後記得撤掉。User-Agent 可以被冒充，谷歌文件提供了用反向 DNS 或對照公布的 IP 位址來核實谷歌爬蟲的方法。如果負載已經讓網站出現 502 / 504，先按 502 / 504 排查指南把服務救回來；長期看，機器本身扛不住正常抓取，就該按業務重新估算 VPS 規格，或者用 CDN 分擔靜態資源。