AI agent 可讀性是特定工具能否取得並正確使用網站內容的能力。驗收時分開檢查 HTTP、瀏覽器操作與回答引用，保存測試條件及證據；本機檢查通過，不能代表所有 AI 搜尋都已讀取或理解。
先定義四個可測試結果
把「AI 友善」拆成四個獨立結果，不要用單一分數掩蓋問題：
- 可發現：公開 URL 出現在 sitemap 或可追蹤的內部連結中。
- 可取得：在受測 HTTP 或瀏覽器環境取得預期內容，並比對標題、正文、作者、日期與 canonical。
- 可正確使用：用受控問題驗證受測 agent 是否保留條件與來源；公共搜尋是否實際引用另行記錄。
- 可驗證：每次內容或設定變更，都能用同一組 HTTP 檢查與查詢集重跑。
這四項是工程驗收條件，不是任何平台公開的排名公式。可驗證的失敗比「GEO 分數下降」更能指向修復位置。
初始 HTML 與瀏覽器分開測試
Google 對生成式 AI 功能的官方指南仍要求沿用一般 Search 的基礎做法：頁面要能被抓取、索引，重要內容要以文字形式呈現。初始 HTML 可減少部分工具對 JavaScript 的依賴，但不能由此推論所有引擎都只讀初始 HTML。Google 也能處理未被阻擋的 JavaScript 內容；受測工具的能力需逐一確認。
發布前可以用不執行瀏覽器 JavaScript 的請求做最小檢查：
curl -sS -L https://example.com/blog/your-slug \
| rg -n '<title>|canonical|article|datePublished|AI agent'
檢查結果至少要能回答：頁面標題是否正確、正文是否存在、canonical 是否指向正式 URL、日期是否和 frontmatter 一致。關鍵字匹配只是初篩，仍須確認回應不是挑戰頁或錯誤頁。若正文依賴 JavaScript，分別驗證目標搜尋工具與瀏覽器是否能取得，再決定是否調整渲染。
結構化資料要與可見內容一致
Schema 的價值是減少語意歧義，不是提供一個神奇的 AI 排名開關。Article 的 headline、datePublished、dateModified、作者與圖片，應和頁面可見資訊及 frontmatter 對得上；FAQ 的問題與答案也應真的出現在頁面內容中。
建立內容契約時，把每個欄位對應到一個可檢查來源：
| 契約欄位 | 頁面證據 | 失敗時先查什麼 |
|---|---|---|
identity | 標題、作者、組織 | frontmatter 與 JSON-LD 是否分叉 |
freshness | 發布日、更新日 | 日期格式與時區 |
scope | 正文中的條件與限制 | 是否被摘要截斷 |
source | 外部來源連結與日期 | 主張是否可回溯 |
文件中的外部連結、版本與操作指令也要維護。本文建議定期檢查失效網址，並核對指令是否仍適用；能下載文件並不表示其中的建議可信。
用固定查詢驗證引用，而不是猜測
每次觀測保存原始回答與來源。以下是假設格式，不是實測結果；網址欄位填實際網址，無法判定的欄位保留 unknown：
query_id,engine,locale,run_at,page_version,mentioned,cited_url,faithful,answer_url
geo-001,example-engine,zh-TW,2026-09-02T09:00:00+08:00,example-version,true,https://example.com/article,unknown,https://example.com/answer
另外保存引擎模式、搜尋設定、重複次數與失敗原因。page_version 表示觀測時網站版本，不代表引擎已更新到該版本。提及率與引用率使用各自可判定的分母，來源未完整取得時不填成零引用。
faithful 要逐句比對：答案是否保留原文的時間、適用範圍與例外。Optimizely 的 GEO Auditor 文件也把 AI crawler accessibility、內容結構、Schema 與 citation readiness 放在同一個稽核範圍；實務上可把它們當成分開的檢查項，而不是混成「有沒有被推薦」。
建議的發布閘門
- 解析所有 MDX frontmatter，確認 slug、日期、圖片與來源欄位。
- 以
curl檢查 robots、sitemap、文章 HTML 與圖片回應。 - 解析 JSON-LD，逐欄比對標題、日期、作者與 canonical。
- 用固定查詢集記錄提及、引用 URL 與忠實度。
來源與判讀界線
- Google Search Central：AI features and your website，頁面持續更新：說明生成式 AI 功能沿用 Search 基礎與可索引內容要求。
- Optimizely：GEO Auditor agent，2026-07-17 更新：列出 crawler accessibility、Core Web Vitals、Schema、內容結構與 citation readiness 等稽核面向。
上述來源分別是平台指南與工具功能文件，不證明某項檢查會提升引用；四個契約欄位、CSV schema 與發布閘門是 YOTRON 的工程分析，不是平台公布的排名演算法。
結語
GEO 的可讀性工作可以被工程化：先讓頁面可發現，再讓初始 HTML 和 Schema 說同一件事，接著用可引用段落與固定查詢驗證結果。llms.txt 可以是補充文件，但不能取代可讀的正式頁面與持續的來源治理。
相關推薦與延伸閱讀
- GEO 引用驗證：用固定查詢找出 AI 搜尋的真實缺口：AI 搜尋的曝光不是單一排名。本文把 GEO 轉成固定查詢、引用證據與正確性回歸測試，分開觀測條件、有效分母與失敗原因，避免從單次答案推定成效。內容包含如何定義
- GEO 不只是 llms.txt：建立可驗證的 AI 檢索與引用管線：llms.txt 不是 AI 搜尋排名捷徑。本文拆解網站如何被抓取、檢索、重排、引用，並提供可執行的 GEO 量測清單：從發現與抓取、理解與檢索、引用與保真到
- GEO 實作：把網頁做成可被 AI 引用的技術契約：AI 搜尋能否正確引用網站，取決於可索引內容、主張與來源、引用驗證及可執行答案是否形成完整契約。本文提供可落地的頁面與評估方法：拆解四層頁面契約，說明如何讓代理
- llms.txt v2 實作指南：讓 AI Agent 找到正確內容，而不是只增加一個檔案：llms.txt v2 透過 link relation 與路徑範圍改善 Agent 發現內容的方式，但它不是 robots.txt，也不保證 AI 搜尋引用。
- SEO 文章怎麼寫？從讀者問題到發布驗收的五步指南：SEO 文章先回答讀者問題，再查核資料、組織內容與驗證頁面。本文提供五步寫作流程及編輯檢查表，分開觀察搜尋成效與 AI 引用：定義讀者要完成的決定、建立主張與證
- SEO 費用怎麼算？服務範圍、計價與預算比較指南：比較 SEO 報價，先對齊交付範圍與完整成本。本文整理月費、專案與成效計價的驗收問題，說明 GEO 額外工作及假設預算算例，並拆解報價應拆成哪些工作項目、三種計
- AI SEO 工具怎麼選？資料來源、功能與試用驗收指南：選 AI SEO 工具先確認工作需求、資料來源與輸出證據。用同一份樣本比較查詢分群、內容草稿、技術診斷與 GEO 觀測，避免把工具分數當成排名保證。本文提供三步