無伺服器架構如何優化邊緣 SEO：CDN 部署與動態渲染策略

開場白... 或結論

嗯... 今天想聊聊無伺服器跟邊緣運算，怎麼用在 SEO 上。老實說，這題目有點硬。簡單講，就是把網站的一部分運算工作，從遙遠的主機，搬到離使用者最近的 CDN 節點上處理。這樣做，最直接的好處是速度變快。對 Google 來說，速度是個很重要的排名訊號，所以這自然對 SEO 有幫助。

所以結論就是：用無伺服器架構跑在 CDN 邊緣，可以讓網站更快、更安全，同時解決現代前端框架（像 React）天生對 SEO 不太友善的問題。特別是透過「動態渲染」這個策略。這整件事的核心，就是讓爬蟲跟使用者都能拿到最適合他們的內容版本，而且速度要快。

為什麼這件事變重要了？

以前的網站很單純，就是 HTML、CSS。伺服器產生好 HTML，丟給瀏覽器，結束。SEO 也簡單，Google 爬蟲拿到的就跟使用者看到的一樣。

但現在流行用 JavaScript 框架，也就是所謂的 Jamstack。頁面內容很多是靠使用者瀏覽器裡的 JS 動態產生的。這對互動體驗很好，但對 Google 爬蟲是個災難。因為爬蟲一開始只拿到一個空殼 HTML 跟一大包 JS，它得自己想辦法執行這些 JS 才能看到完整內容。這個過程叫「渲染」，很耗資源，而且 Google 不保證每次都願意幫你做，或做得好。常常就有個延遲，內容要等第二波索引才能被收錄，甚至直接失敗。

所以我們需要一個方法，在爬蟲來的時候，直接給它一個渲染好的、完整的 HTML 頁面。這就是動態渲染 (Dynamic Rendering) 的作用。它會判斷來訪的是真人還是爬蟲，然後給予不同版本的內容。給爬蟲伺服器端渲染好的靜態 HTML，給真人則是可互動的 JavaScript 版本。Google 官方也說，只要內容最終一致，這就不算作弊 (Cloaking)。

怎麼做：無伺服器 + CDN 邊緣函數

傳統上做動態渲染，你得自己架一台伺服器，或用像 Rendertron 這樣的服務。但這又回到老問題：管理伺服器很麻煩。無伺服器架構就是為了解決這個問題。你不用管主機，程式碼丟上去，它會自動擴展。

而現在更進一步，我們可以把這個「判斷爬蟲並提供預渲染內容」的邏輯，寫成一個「邊緣函數」(Edge Function)，直接部署在 CDN 網路上。像 Vercel 的 Edge Functions 或 Cloudflare 的 Workers 都屬於這類服務。這些函數跑在離使用者最近的 CDN 節點，所以反應速度極快，幾乎沒有冷啟動問題。

整個流程大概是：

請求到達 CDN 邊緣節點。
邊緣函數被觸發，檢查請求的 User-Agent。
如果 User-Agent 是 Googlebot 或其他爬蟲，函數就從後端 API 抓資料，或者直接在邊緣用一個無頭瀏覽器 (Headless Browser) 渲染出完整的 HTML。Cloudflare Workers 現在甚至提供了 Browser Rendering API，讓這件事更容易。
把這個靜態 HTML 回傳給爬蟲。
如果 User-Agent 是普通使用者，就直接回傳原本的 JavaScript App，讓使用者的瀏覽器去渲染。

這樣做的好處是，SEO 需要的靜態 HTML 由最快的邊緣網路來提供，完全不影響真實使用者的互動體驗，也省去了自己維護渲染服務器的麻煩。

不同渲染策略的比較

嗯... 說到渲染，其實有好幾種方法，常常會搞混。這裡簡單整理一下，用我自己的理解說。

渲染方式	我的理解（口語版）	優點	缺點
客戶端渲染 (CSR)	就是瀏覽器自己搞定。伺服器只給個空殼跟一堆 JS。	互動體驗好，像 App 一樣。伺服器壓力小。	SEO 天生殘廢。Google 不一定想幫你跑 JS。
伺服器端渲染 (SSR)	每次請求，伺服器都產生一份完整 HTML。	對 SEO 非常友善。	伺服器壓力大，成本高。TTFB (Time to First Byte) 可能比較慢。
靜態網站生成 (SSG)	在「建置」階段就把所有頁面都生成好 HTML。	速度最快，超安全。對 SEO 也很棒。	內容更新了就要重新建置一次，不適合變動頻繁的網站。
動態渲染 (Dynamic Rendering)	看人下菜碟。給爬蟲看 SSR 版，給真人看 CSR 版。	兩全其美，解決 CSR 的 SEO 問題。	設定比較複雜，要小心內容不一致被當成作弊。

所以，用無伺服器邊緣函數來實現動態渲染，算是在成本、效能和 SEO 之間取得一個很好的平衡點。

風險與注意事項

聽起來很美好，但還是有幾個坑要注意。

首先，內容一致性。動態渲染給爬蟲和使用者的內容，核心資訊必須一樣。如果差太多，Google 可能會判定這是「掩飾 (Cloaking)」，是一種黑帽 SEO 手法，會被處罰。所以，拿來做 A/B 測試或根據地理位置顯示不同內容時，要很小心。

再來是成本。雖然無伺服器是「隨用隨付」，但如果你的網站流量很大，或是爬蟲訪問非常頻繁，邊緣函數的執行次數和運算時間累積起來，也是一筆開銷。各家 CDN 廠商，像是 Vercel、Cloudflare 的定價模型都不太一樣，要先算清楚。像 Cloudflare Workers 有免費額度，但超出後的計價方式需要研究一下。

還有，這東西在台灣或亞太地區的表現如何？雖然全球 CDN 節點很多，但主要服務商（如 Vercel、Cloudflare）在北美和歐洲的節點還是最密集的。在地化的延遲還是要實際測試。相較之下，一些中國大陸的雲服務商，如騰訊雲、阿里雲，他們也有類似的邊緣產品，對於服務中國境內的使用者和百度爬蟲，可能會有更好的在地化表現。例如，uni-app 框架的官方文件就提到，與其自己做 SEO，不如發佈一個百度小程序版本，權重可能更高。這點顯示了不同市場下的策略差異。