Agent Ready 雖然得 83 分(T_T)，但我們正確實推進讓 AI 閱讀的準備！

Liberogic 正在推進將自有網站改造為易於 AI 代理和 LLM 閱讀的結構。

現在，不僅搜尋引擎，Claude、Gemini、ChatGPT 等 LLM 和 AI 代理閱讀網站、整理資訊、進行比較，以及代替使用者進行調查的情況已成為常態。

Liberogic 網站也正在準備讓 AI 閱讀，包括 robots.txt、sitemap、Link headers、llms.txt 和按文章生成 Markdown 檔案等措施。

這次我們撰寫文章介紹 Cloudflare 在前兩週公開的「Is Your Site Agent-Ready?」。

作為內容網站進行檢查

Liberogic 的網站是公司資訊、服務介紹、消息、專欄、案例研究等內容的企業網站和內容網站。它不是電商網站，也不是涉及 OAuth 認證的 API 應用程式。

因此在檢查時網站類型選擇 「Content Site」。

Commerce、API / Auth / MCP 相關的項目本次評估範圍外，主要以以下觀點進行確認。

• Discoverability
• Content Accessibility
• Bot Access Control

結果是……..分數為 83 分，等級 2「Bot-Aware」 😭

為什麼不是 100 分呢！！

立即進行驗證/確認

本次檢查中 Discoverability 獲得 100 分，Bot Access Control 也獲得 100 分。

robots.txt、sitemap、Link headers、AI bot rules、Content Signals 等項目都已對應，AI bot 能夠發現網站並理解存取方針的基本導引已經完備。

簡而言之，

• 讓網站被發現
• 告訴 bot 內容位置在哪裡
• 向 bot 展示存取方針
• 為 AI 輸出信號

等項目已經完成對應。

另一方面，Content Accessibility 項目得到了 0 分（TT）

單看這個分數會讓人想「咦，內容讀不了嗎？」但實際情況有點不同。

Markdown 內容本身已經準備好了

在 Liberogic 的網站上，針對文章內容和案例研究，AI 已經以容易讀取的 Markdown 格式文件生成了一定比例的內容。
文章和案例研究都有相應的 Markdown 文件，各頁面的 head 標籤內也設定了指向 Markdown 版本內容的 link 標籤，實際的 AI 代理也有路徑可以到達 Markdown 文件。

不是說不支援 Markdown，而是以 LLM 易於讀取的形式提供本文，所以不是「還沒做好讓 AI 讀取的準備」的狀態。

那麼為什麼沒有得到 100 分呢 👺

這次沒有得到 100 分的原因不是網站方沒有採取任何行動，而是由於目前的實裝構成與檢查工具側的判定規格的相容性問題。

Liberogic 的網站是用 Astro 的 SSG 實裝，預覽頁面使用 SSR 進行混合構成。

關於 Markdown negotiation，通常由中間件處理，但由於採用混合配置，我們使用了 Cloudflare 適配器，其輸出的 _worker.js 優先級更高。因此中間件無法被載入，檢查工具側無法反映 Markdown negotiation 的設定。

實際上確實存在 Markdown 檔案，也可以通過 head 內的 link 標籤訪問，但從檢查工具的角度來看，會判定為「無法確認 Markdown negotiation！」的狀態。

真是令人無奈！竟然做出了這麼不完整的東西！

「……」這樣說或許有點想法，但當然我們每天都在受惠於 Cloudflare。

感謝貴公司給予合作夥伴認證的批准。

但身為一直在 lighthouse 上追求 100 分的人，這裡確實有些不甘心。

實現 100 分是可能的！但不想只為了分數而降低運營效率，也不想增加成本。

作為對應方法，有幾種可以考慮。

• 另外構建 Cloudflare Workers 來處理 Markdown 返回
• 將預覽頁面轉為 CSR 方式，以完全的 SSG 配置為目標
• 將 Cloudflare 的服務方案升級至商業方案，並使用 Transform Rules 重寫 URL

就是這樣的方法。

沒錯，如果將 Cloudflare 的服務升級一個等級，確實可以讓檢查工具的評分接近滿分。
不過，為了只是達到這個目標而額外支付費用，這個判斷似乎有點微妙呢！

我們的目的畢竟不是在檢查工具上取得滿分，而是讓 AI 代理和 LLM 能夠適當地讀取 Liberogic 網站上的資訊。從 LLM 讀取內容的角度來看，我們認為本公司的必要對應已經進展得相當順利。

與其只為了取得滿分而增加成本，還不如確保內容能被正確閱讀。

還要能夠確實運營。

Liberogic 希望重視這種平衡。

別忘了 llms.txt 喔！

這次的檢查項目中雖然沒有包含，但 Liberogic 也有對應 /llms.txt。

llms.txt 是一個目錄檔案，用來告訴 LLM「這個網站有什麼資訊，應該讀哪個頁面」。

概念上與搜尋引擎的sitemap.xml相似，但針對 LLM 的特性，負責整理網站概要和引導使用者找到重要內容的角色。

檢查工具的檢查項目中並未包含此項，但 Cloudflare 重視「能否以低雜訊方式取得內容（是否已轉換為 Markdown）」這類資料品質，可能是基於這個原因而刻意未將其納入。

直接讓 AI 讀取 HTML 就好了？

讓 AI 代理讀取網站時，當然可以直接解析 HTML。

但實際的網頁中包含了導覽列、頁首、頁尾、裝飾元素、JavaScript 控制等本文以外的大量資訊，即使視覺上看起來簡潔，對 LLM 來說往往會產生大量雜訊。
將複雜的 HTML 強行轉換為 Markdown 時，標題結構、列表和表達意圖可能會破損，最終導致 LLM 難以讀取這些資料。

在這段時間內，隨著 AI 進步，這些問題應該也會迅速改善。但我認為重點是現在要一步步做好該做的事。各位的網站推進到什麼程度了呢？