重點摘要

• 現代網站必須同時服務兩類受眾：一是需要視覺化、快速且具互動體驗的人類訪客；另一類則是 AI 爬蟲，它們需要的是乾淨、結構化，而且不必執行用戶端 JavaScript 就能讀取的資料。

• 如果網站無法提供 AI Bot可解析的資料，就可能無法出現在 AI 生成的搜尋結果與推薦內容中。

• 然而，如果把 Bot 路由、預先渲染與快取新鮮度等邏輯都放在來源站處理，會增加伺服器負載、延遲與維運成本。

• 搭配 Akamai Functions 與Akamai Bot Manager，網站可以在網路邊緣辨識訪客類型，立即提供適合人類瀏覽的頁面，或針對 AI 最佳化的內容，同時避免犧牲網站速度與來源站資源。

你的網站現在有兩種受眾

你的網站現在有兩種受眾。

第一種，是你最初打造網站時所服務的對象：使用瀏覽器的人類訪客。

第二種則是近年快速增加、重要性也不斷提升的新受眾：AI Agent 與 AI 爬蟲。

這兩種受眾都很重要，但它們需要的東西卻截然不同。

• 人類訪客需要快速、精緻的使用體驗。他們往往只花幾秒鐘，就會根據版面配置、易用性、圖片，以及頁面回應速度來判斷網站好不好用。

• AI Agent
  並不在意視覺版面。它們需要的是結構化資料、最新內容，以及能夠容易解析的乾淨回應。

在本系列先前的文章中，我們曾提出一項觀點：相當一部分應用程式邏輯，其實應該放在網路的「前門」——也就是每一個請求都必須經過的網路邊緣。

而「同時服務兩種不同網站受眾」，正是驗證這個觀點非常好的案例。

透過位於這個「前門」的 Akamai Functions，搭配 Bot Manager 的分類能力與其他Akamai服務，網站可以辨識每一個請求究竟來自哪一類受眾，並提供對方真正需要的內容，同時不必犧牲回應時間、不必拆分來源站，也不必維護第二套獨立渲染流程。

網站現在必須同時服務人類與 AI

今天的網站，必須同時服務人類與 AI。

問題是，你很難用完全相同的回應，同時滿足這兩種受眾。

• 如果網站針對人類最佳化，AI 爬蟲往往會拿到不容易解析的標記內容。

• 如果網站針對 AI 最佳化，人類頁面反而可能承擔額外負擔，導致載入速度變慢。

兩種受眾都不能忽略。

人類仍然會搜尋網站、瀏覽頁面、購買商品並註冊服務。因此，透過版面、圖片與互動性提供優質使用體驗，依然非常重要；而Core Web Vitals 也仍然會影響搜尋排名與轉換率。

但另一方面，愈來愈多的資訊探索行為正透過 AI 發生。

Gartner 曾於 2024 年預測，隨著使用者轉向 AI 助理，到 2026年，傳統搜尋引擎的搜尋量將下降 25%。

Adobe 的數據則顯示，2024 年 7 月至 2025 年 2 月期間，美國零售網站來自生成式 AI 的流量增加了1,200%。

Akamai 的觀察也顯示，光是 2025 年，AI Bot 活動量就增加了 300%。

當使用者詢問 AI 助理「該買哪一個產品？」或「該閱讀哪一篇文章？」時，AI 會結合其訓練資料與 Web 爬蟲取得的資訊來產生答案。

而這兩種資訊來源，都仰賴你的網站是否容易被 AI 解析。

AI 爬蟲需要能夠輕易解析、具有明確結構的資料。

如果 AI 無法解析你的網站，它就無法推薦你的網站。

傳統上，許多團隊會在來源站解決這個問題。

例如：

• 在應用程式程式碼中偵測 Bot

• 部署預先渲染服務

• 使用 Headless Browser 產生爬蟲友善頁面

• 另外維護供機器流量使用的 Feed 或 API Endpoint

但整個處理方式仍然是高度集中式的。

每一次 Bot 請求都必須一路送回你的基礎架構；預先渲染服務也需要自行擴充與負擔成本，而 Bot 偵測邏輯則由應用程式團隊自行維護。

為不同受眾產生不同回應

其實有更好的做法。

利用 Akamai Functions 作為連接 Bot Manager 等服務的「黏著層」，你可以直接在網路邊緣為不同受眾產生適合它們的回應，而不需要讓每一個請求都回到來源站。

如此一來，就能同時讓人類訪客與 AI 受眾獲得適合自己的體驗。

• Rust

• Go

• JavaScript

• Python

• 以及更多語言

Akamai Functions 可與 Akamai 的 CDN、安全、AI 與儲存服務整合。

Functions 會在 Akamai Cloud Region 中執行，Cold Start 約為 0.5 毫秒，並透過 Akamai 內部網路與 Edge 連接，因此無論請求從網路的哪一個位置進入，都能快速抵達對應的 Function。

AI 爬蟲時代下，Akamai Functions 的三種應用情境

若要在維持人類訪客快速、流暢體驗的同時，也讓網站對 AI 爬蟲友善，就需要調整整體架構。

以下三個情境說明 Edge Functions 如何解決現代網站在內容渲染、快取與效能方面常見的瓶頸：

1. 網站使用主要為人類設計的 JavaScript Framework

2. AI 爬蟲為了取得最新內容，頻繁回到來源站

3. 動態頁面必須同時為人類與 AI 爬蟲維持高速

情境一：網站使用主要為人類設計的 JavaScript Framework

許多網站使用以 Client-side Rendering 為主的 JavaScript Framework 建置，主要目的是服務人類使用者。

當伺服器收到請求時，通常只會回傳一個「骨架」：

也就是幾乎空白的 HTML 文件，加上一些 Script Tag。

瀏覽器下載並執行這些 Script 後，才開始建立頁面、擷取產品資料，並將價格與產品描述寫入文件。

換句話說，頁面的完整內容，要等到用戶端 JavaScript 執行之後才會真正出現。

傳統架構

這種做法對人類使用者沒有問題。

但多數 AI 爬蟲並不會執行 JavaScript，因此通常看不到完整內容。

針對主要 AI 爬蟲的獨立測試顯示，包括 GPTBot、ClaudeBot
與多數同類爬蟲，主要讀取的仍是原始 HTML。

因此，AI Bot 從產品頁面看到的可能只是：

• 一個空白的 Content DIV

• 一串 Script Tag

結果就是：

這個頁面可能在傳統搜尋中表現良好，但 AI 助理卻可能直接略過你的網站，或改從其他來源補足資訊，最終導致使用者得到錯誤答案。

Akamai Functions 的解決方式

透過 Akamai Functions 作為整合層，整個流程可以完全不同。

首先，Bot Manager 在 Edge 辨識 AI 爬蟲。

接著，請求會被導向 Function。

這個 Function 會：

1. 接收 Bot Manager 的分類結果

2. 取得產品資料

3. 在 Akamai Cloud 上完成資料結構化處理

4. 將適合機器解析的回應快取在 Edge

如此一來，下次 AI 爬蟲再次造訪時，就能直接命中快取。

分類、渲染與快取，可以在同一次流程中完成。

資料會被渲染成乾淨的 HTML，搭配 schema.org markup，或直接產生純 Markdown。

而只有人類才需要的項目，例如：

• 導覽選單

• Script

• 視覺樣式

則可以全部移除。

對 AI Bot 而言，它們取得的內容與人類頁面來自同一個資料來源，只是輸出成更適合機器解析的格式。

更重要的是，這些內容是在 Edge 即時產生並快取，而不是另外維護第二套網站。

人類訪客則完全不會感受到這個流程，其原本的頁面體驗維持不變。

圖 1：透過 Bot Manager 與 Akamai Functions，在網路入口即辨識人類或 AI，並分別提供適合的內容。

情境二：AI 爬蟲頻繁回到來源站取得最新內容

AI 爬蟲會頻繁重新造訪網站，以取得最新的動態資訊，包括：

• 價格

• 商品庫存

• 最新內容更新

傳統架構

傳統網站通常依賴快取。

但快取一直存在一項基本取捨：

內容新鮮度 vs. 回應速度。

AI 流量讓這個問題變得更加明顯。

團隊通常會透過調整 Cache Time to Live（TTL）來取得平衡。

但如果 TTL 設太長，AI 助理可能提供的是「上週的價格」。

如果 TTL 設太短，每次 AI 爬蟲重新造訪都會直接打到來源站。

這代表企業必須承擔更多：

• Server Load

• Egress Cost

• Latency

而且這些成本會隨著不同 AI 爬蟲的數量不斷累積。

兩種作法都不理想。

Akamai Functions 的解決方式

透過 Akamai Functions 組合回應，可以消除這項取捨。

經常變動的欄位可以儲存在 Key-Value（KV）Store 中，並同步複寫至 Akamai Cloud 各個 Region。

例如價格發生變化時，Commerce 或 Content System 只需要寫入一次更新，變更就會傳播至各個區域。

Function 每次收到請求時，都直接讀取最新欄位。

由於 KV Store 與 Function 位於相同 Akamai Cloud Region，因此只需要非常短的存取距離。

結果是：

經常變動的欄位，例如：

• 價格

• 庫存數量

• 標題

可以保持最新。

而不常變動的內容，則直接從 Edge Cache 提供。

Function 成為連接 KV Store 即時資料與快取頁面的整合層，將兩者組合成完整的 AI-ready Response。

因此，即使 AI 爬蟲頻繁造訪，每一次都能取得接近即時的資料，而無需每次重新回到來源站。

來源站只需要在資料變更時寫入一次，偶爾進行快取補充即可，不必為每一次 AI Re-crawl 付出額外成本。

來源伺服器只需寫入一次更改，並偶爾進行快取填充；它不再為每次重新抓取付費（圖 2）。
圖 2：Akamai Functions 將 KV Store 的即時資料與快取內容組合，讓 AI爬蟲無需回到來源站也能取得最新資料。

情境三：動態頁面必須同時為人類與 AI 維持高速

不論是人類還是 AI，都需要快速的動態頁面。

例如：

• 個人化 Landing Page

• 依庫存狀況動態變化的產品頁

• 依訪客條件即時組合的 Campaign Page

這些頁面往往最有可能促成人類轉換，也最有可能被 AI 助理引用。

但同時，它們通常也是網站中速度最慢的頁面。

傳統架構

在集中式架構中：

• 個人化

• 庫存查詢

• 內容組合

通常需要多次往返中央來源站 Region。

每一個 Hop 可能增加約 50 至 100 毫秒。

當多個請求串接在一起時，可能為人類與 AI 爬蟲額外增加 250
毫秒以上的頁面渲染時間。

結果可能導致：

• Core Web Vitals 惡化

• 自然搜尋排名下降

• Paid Search Quality Score 下降

• Conversion Rate 降低

而 AI 爬蟲通常不會長時間等待或重新嘗試。

因此，回應速度太慢，甚至可能直接導致該頁面被 AI 爬蟲略過。

Akamai Functions 的解決方式

透過 Akamai Functions，大部分邏輯都能在更接近使用者的位置執行。

Function 可以：

1. 從 KV Store 查詢訪客 Segment

2. 呼叫執行於 Akamai Cloud GPU 上的 Recommendation Model

3. 查詢庫存狀態

4. 組合頁面

整個流程都不需要離開 Akamai Network。

根據 Akamai Benchmark，傳統集中式 Personalization 架構的一次典型往返約需 200毫秒。

將邏輯移至 Edge 後，可將延遲縮短至約 40 毫秒。

同時，Inference Cost 最高可降低 86%。

透過 Akamai Functions，可以：

• 加速頁面渲染

• 改善 Core Web Vitals

• 提升自然搜尋排名

• 降低付費搜尋成本

• 提升轉換率

• 為 AI 爬蟲提供快速回應

使用 Akamai Functions 可以加快頁面渲染速度，改善核心 Web 指標，優化自然搜尋排名，降低付費搜尋成本，提高轉換率，並為 AI 爬蟲提供快速反應（圖 3）。

圖 3：集中式 Personalization 需要三次串行往返，約 200 ms；透過 Akamai Functions 在網路前門一次完成，可縮短至約 40 ms。

從網路「前門」同時服務兩種受眾

你的網站一直以來都在服務人類。

現在，它也需要服務 AI Agent。

但這項改變並不代表你必須另外建立一個專門給機器使用的網站，也不代表必須犧牲人類頁面的速度。

相反地，你可以在每一個訪客抵達網站的第一時間辨識其身分，讓 Akamai Functions
負責處理兩種受眾所需要的：

• 渲染方式

• 內容新鮮度

• 回應速度

如此一來，就能同時滿足人類與 AI。

Akamai Functions：更智慧、更緊密連結的 Edge

準備好看看你的網路「前門」還能做些什麼了嗎？

可進一步查看 Functions Quick Start Guide，或與 Akamai 團隊聯繫。

延伸閱讀

如果尚未閱讀本系列其他文章，可進一步了解：

• The Internet Has a Front Door: The Edge Is Now
  Intelligent

• Your Origin Server Might Be Your Most Expensive
  Decision

• What Changes When You Move Your Logic to the Smarter, More Connected
  Edge?

• The Hidden Latency Tax in Retail
  Personalization

• Solve Multi-CDN Entitlement Drift with Edge Functions Without Losing
  Viewers