- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
AI 翻译的文章。
durumis AI 总结的文章
- 為了有效利用 Google 搜尋的爬蟲預算,我們改進了網頁傳輸速度並導入了基於 Cloud Run 的重新導向服務。
- 將 robots.txt、favicon.ico 等靜態檔案和重新導向邏輯遷移到 Cloud Run,與先前使用 GKE Autopilot 相比,回應速度從 200 毫秒提升到 20 毫秒。
- 透過在全球各地不同的區域部署 Cloud Run,從靠近使用者的伺服器提供服務,從而提高速度並降低成本。
所有以內容為主的服務都希望在 Google 的搜尋結果中獲得更高的曝光率。
但是,要讓 Google 搜尋引擎顯示您的內容,就必須讓 Googlebot(搜尋引擎爬蟲)經常造訪您的網站,抓取最新的數據,並將其正確反映到搜尋結果中。
此時,為了讓 Googlebot 更頻繁地造訪網站,可以使用「爬蟲預算」的概念,預算越高,爬蟲造訪的頻率就越高,而要提高預算,網站的流量就需要達到一定的水平。
那麼,如何有效利用有限的「爬蟲預算」,在相同預算下讓爬蟲更頻繁地造訪呢?
那就是網站的網頁傳輸速度必須很快。例如,與頁面下載時間為 200 毫秒的網站相比,頁面下載時間為 20 毫秒的網站會被更頻繁地抓取頁面。
我們的 Durumis(ドゥルミス)服務本質上是面向「全球」的,因此在全球 8 個區域提供基本的流量服務。
GCP 伺服器區域
目前,我們的服務主要使用Google 的 40 個區域中的亞洲首爾、新加坡、孟買、歐洲比利時、美國洛杉磯和南卡羅來納州的區域。無論您從世界任何地方訪問,通常都能夠快速順暢地連線。
但是,出於前面提到的原因,為了追求更極致的速度,我們決定進行進一步的調整。
目前,我們的服務正在經歷從初始發佈時的 URL 方式轉換到新的子網域方式的過程中,因此存在一些重定向,並且 Googlebot 的許多訪問都集中在這個部分。我們需要讓 Google 儘快識別舊 URL 與新 URL 之間的關係。
因此,為了最大限度地利用提供的爬蟲預算,重定向流量需要保持盡可能快的速度。
之前,上述 8 個區域都部署了 GKE,每個 GKE 都使用 Google 的GKE Autopilot處理不與數據庫相關聯的數據,並進行重定向。
因此,我們決定將 GKE 上以及之前部署在其他 Cloud Run 上的一些邏輯遷移到新的 Cloud Run 中。要遷移的清單如下:
- robots.txt:雖然是靜態檔案,但多個子網域會使用特定邏輯提供內容。
- favicon.ico:純粹的靜態檔案。
- durumis.com/[lang]/@userId/postID:重定向到新的 URL -> userId.durumis.com/[lang]/postID
之前,當使用 GKE Autopilot 上相對較重的框架提供服務時,響應時間約為 200 毫秒。
新的方法是使用 Cloud Run 運行,並且由於邏輯非常簡單,因此不使用框架,而是使用 node:http,並利用基本代碼而沒有使用任何庫。
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
(如果直接複製上面的代碼,它將無法運行。您只需要了解其基本概念。)
對於 favicon.ico,由於它是圖像檔案,因此我們選擇從檔案中讀取並將其保留在記憶體中,然後使用它進行傳輸。
利用 Shell 腳本和 gcloud 工具,我們可以同時將其部署到多個區域。
瞧!
部署的結果如下所示:
Cloud Run 畫面
我們已將其部署到美國的「所有區域」,並在每個大陸部署了多個區域:歐洲 2 個、亞洲 2 個、非洲 1 個和南美洲 2 個。事實上,這是 Serverless 的優勢之一,即使這樣做,成本也不會增加。(如果為附近的流量提供服務,成本甚至可能會降低。)
那麼,這樣做之後速度提高了多少呢?
之前的伺服器端響應速度如下:
GKE Autopilot
改進後的速度如下:
利用 Cloud Run 的靜態檔案
您可能會認為,既然 Cloud Run 是 Serverless,那麼肯定存在冷啟動時間……但實際上,在持續不斷地定期抓取的情況下,這並不是什麼大問題。這是 GCP Serverless 的特性之一,它通過在備用和閒置狀態之間切換來保持等待。(而且成本也不會增加。)
在下一次文章中,我們將介紹除了上面提到的小型靜態檔案或 301 重定向之外,圖像檔案和其他檔案的處理方式。