深夜時分

Q: 爬取普查如何執行？

普查使用 Cloudflare 的 GraphQL 分析 API（httpRequestsAdaptiveGroups），依使用者代理程式模式（%Googlebot% 和 %bingbot%）進行篩選，按 URL 路徑前綴分類頁面，並彙總狀態碼。腳本在30秒內完成，產出 Google 與 Bing 爬取行為的並排比較。

太平洋時間凌晨3點，我的正式環境處理的請求量超過整個工作日的任何時段。這些請求不是來自使用者，而是來自機器人。

Googlebot 正在爬取21,000個頁面。Bingbot 正在爬取10,000個。我的綜合夜間檢查正在掃過15,000篇部落格文章和公司頁面。暖快取程序正在為 Cloudflare 邊緣快取預熱，準備迎接隔天的流量。這些夜間程序觸及的頁面總數，超過所有真人訪客的總和。

我白天建構的網站，並不是最重要的那個。最重要的是爬蟲在凌晨3點看到的那個。

爬取普查

我每天執行一次爬取普查，統計機器人在過去24小時內的造訪情況。普查使用 Cloudflare 的分析 API，依使用者代理程式進行篩選。這些數字揭示了搜尋引擎重視什麼：

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

職缺頁面消耗了一半的爬取預算。Googlebot 每天爬取10,654個職缺頁面。職缺的 sitemap 沒有上限，每個符合條件的職缺列表都被納入其中。爬取預算的分配告訴我，Google 認為網站上最有價值的內容是什麼。

部落格文章每天只獲得298次爬取，儘管它們是品質最高的內容。爬取投入的比例（職缺是部落格的50倍）與內容投入的比例（部落格每頁所需心力是職缺的100倍）完全不對等。搜尋引擎爬取的是能大規模索引的內容，而非投入最多心力的內容。

公司頁面每天只有14次爬取，儘管 sitemap 中有超過7,000個頁面。這是爬取預算飢餓問題：職缺頁面消耗了太多預算，公司頁面幾乎無法被發現。夜間數據揭露了這個問題。若非普查，我根本不會知道7,000個公司頁面對爬蟲而言幾乎是隱形的。

410 告訴你什麼

普查追蹤 HTTP 狀態碼。最值得關注的是 410：Gone。

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

超過三分之一的爬蟲請求命中了已過期的職缺頁面，這些頁面回傳 410。這些職缺在爬蟲最初發現時確實存在，被索引後已被移除。410 告訴爬蟲：「這個頁面曾經存在，但已永久消失，請停止請求。」

410 的比率正在下降。上週 Google 為 8,858，本週降至 7,614。爬蟲正在學習。隨著搜尋引擎更新索引，幽靈請求的數量逐日減少。但學習速度緩慢。Bing 的 410 比率（42.3%）高於 Google（35.5%），因為 Bing 處理移除訊號的速度較慢。

410 趨勢是最清晰的夜間訊號。它告訴我搜尋引擎收斂至網站當前狀態的速度。410 比率上升代表我移除內容的速度超過爬蟲的適應能力；下降則代表索引正在追上。平衡點是零 410，意味著爬蟲請求的每個頁面仍然存在。

524 問題

當來源伺服器在逾時視窗內未回應時，Cloudflare 回傳 524。在一個大量部署日（87次提交），普查顯示：

Google 524s:  68  (0.3%)
Bing 524s:    0

24小時內68次來源逾時。每一次都代表 Googlebot 請求了一個頁面，Cloudflare 將請求轉發至 Railway，而 Railway 未能及時回應。最可能的原因是頻繁部署期間 Railway worker 的重啟。每次部署都會重啟應用程式，產生一個短暫的請求逾時視窗。

在0.3%的爬取中，Google 看到的是一個故障的網站。這些 524 錯誤不會出現在任何應用程式日誌中，因為錯誤發生時應用程式根本沒有在執行。這個錯誤僅存在於 Cloudflare 與 Railway 之間的間隙，唯有透過爬取普查才能觀察到。

隔天早上，524 計數歸零。部署已停止，worker 趨於穩定。夜間數據確認這是短暫的部署波動，而非結構性問題。

暖快取程序

在爬蟲抵達之前，暖快取程序先行啟動。它透過 Cloudflare 邊緣快取擷取每篇部落格文章、每個語言變體，以及50個公司頁面。目標是確保當 Googlebot 造訪頁面時，能獲得快取回應，而非等待來源伺服器渲染。

這個差異影響甚鉅。快取的部落格文章在80毫秒內回應，未快取的則需要1.5秒從來源伺服器取得。Googlebot 的爬取速率預算以每秒請求數計算。回應越快，同一時間視窗內爬取的頁面就越多。暖快取使有效爬取覆蓋率翻倍。

暖快取程序對使用者是透明的。沒有任何真人訪客會因為凌晨2點快取的部落格文章而受益。但暖快取決定了 Googlebot 在夜間視窗中是發現300篇還是600篇部落格文章。即使沒有任何人看到這個機制，SEO 的影響卻是實實在在的。

夜晚揭示的真相

每天早上我閱讀夜間日誌。模式大同小異：大部分綠燈，幾個異常，一兩件值得深入調查的事。這個節奏很無聊。但價值恰恰在於這份無聊的規律。

無聊的夜晚意味著部署沒有破壞任何東西、爬蟲找到了預期的內容、快取正常運作、網站已準備好迎接隔天的流量。有趣的夜晚意味著某些事情發生了變化：新的錯誤模式、停止運作的快取規則、或暗示排名訊號變化的爬取預算位移。

爬取普查告訴我7,000個公司頁面對 Google 是隱形的。白天的任何指標都不會揭露這一點。使用者分析顯示公司頁面零流量，我原本歸因於需求不足。普查顯示的是零爬取量，意味著 Google 甚至還沒評估過這些頁面。問題不在需求，而在發現。

524 分析告訴我 Railway 部署會產生來源逾時視窗，而 Googlebot 恰好命中。任何應用程式監控都不會揭露這一點，因為逾時期間應用程式並未執行。問題存在於部署與可用性之間的基礎設施空隙中。

410 趨勢告訴我 Bing 處理移除訊號的速度比 Google 慢20%。這對 SEO 至關重要：過期的職缺頁面在 Bing 的索引中停留更久，可能對使用 Bing 驅動的搜尋介面（DuckDuckGo、Yahoo）的使用者提供過時的結果。

這些洞察全部來自夜間數據。白天告訴你使用者做了什麼，夜晚告訴你基礎設施在無人看守時做了什麼。兩者都重要，但對 SEO 而言，夜晚更為關鍵。

常見問題

爬取普查如何執行？

普查使用 Cloudflare 的 GraphQL 分析 API（httpRequestsAdaptiveGroups），依使用者代理程式模式（%Googlebot% 和 %bingbot%）進行篩選，按 URL 路徑前綴分類頁面，並彙總狀態碼。腳本在30秒內完成，產出 Google 與 Bing 爬取行為的並排比較。

為什麼不使用 Google Search Console 的爬取數據？

Google Search Console 的爬取統計有2-3天的延遲，且粒度有限。Cloudflare 普查是即時的（過去24小時），包含 GSC 未報告的狀態碼、內容分類和快取狀態。GSC 適合觀察趨勢，普查適合做營運決策。

暖快取程序會增加 Cloudflare 費用嗎？

不會。Cloudflare 快取由任何請求觸發填充，無論來源為何。暖快取使用標準 HTTP 請求，計入正常的請求配額。免費方案對快取回應沒有請求數限制。暖快取期間的來源請求計入 Railway 的頻寬，但以15,000個頁面平均每頁50KB計算，每次暖快取總計約750MB。

如果爬蟲改變行為怎麼辦？

普查捕捉爬蟲的一切行為，不受變化影響。爬取模式的轉變（更多職缺頁面、更少部落格頁面）會立即反映在下一次普查中。跨天的趨勢數據能揭示這是一次性異常還是持續性變化。

資料來源

本文基於自2026年3月起透過 Cloudflare GraphQL API 收集的每日爬取普查數據。普查工具：~/Projects/Utility/crawl_census.py。夜間檢查工具：~/.claude/skills/nightcheck/。