GEO 的最低可驗證單位不是「網站有沒有被 AI 提到」，而是：對一個固定問題，AI 是否找到正確頁面、抽取正確主張，並把引用指向仍然有效的來源。這三件事彼此相關，卻不能用同一個 HTTP 200 或排名數字代替。
Google 對生成式搜尋功能的官方說明仍把基礎工作放在一般 Search 技術：可索引內容、清楚的頁面主體與良好的結構。Cloudflare 最近則把搜尋、agent 使用與訓練的 crawler 意圖分開管理。兩者共同指向一個工程結論：GEO 需要內容品質與存取政策，也需要可重跑的驗證紀錄。
先定義三個不同訊號
1. 可取得性
確認公開 URL 能穩定回傳預期內容：狀態碼、Content-Type、canonical、標題、更新日期、主要正文與結構化資料。這是必要條件，不是引用證據。
curl -L -sS -D /tmp/headers https://example.com/blog/guide -o /tmp/page.html
rg -n "200|content-type|canonical|<h1|updatedDate|application/ld\+json" \
/tmp/headers /tmp/page.html
同一輪也應檢查 robots.txt、sitemap 與 WAF 規則。Cloudflare 將 search crawler 與 agent crawler 的意圖拆開，表示「允許搜尋」不必然等於「允許所有 agent 工作」；團隊應把這些政策記錄成版本化設定，而不是只看一次瀏覽器結果。
2. 主張忠實度
為頁面建立 3–5 個可判定主張，每個主張包含原文句子、限制條件與來源位置。例如：
claim_id: geo-01
question: llms.txt 能控制 crawler 存取嗎？
expected: 不能；存取政策由 robots.txt、WAF 或驗證層處理
source_url: https://example.com/blog/guide
checked_at: 2026-09-11T08:30:00+08:00
測試答案時，不只記錄「有沒有提到品牌」。應逐項判斷答案是否保留數字、日期、適用範圍與否定句。最容易造成 GEO 誤判的案例，是模型引用了正確頁面，卻省略「不保證」、「僅供測試」等限制。
3. 引用品質
引用品質至少包含四個欄位：引用 URL 是否正確、是否是 canonical 版本、引用段落是否支持主張、頁面目前是否仍公開。若答案出現舊 URL、重導向鏈或只支持一半的句子，應視為回歸失敗，而不是成功曝光。
建立固定查詢與證據表
固定查詢要以使用者任務表達，而不是只測品牌名。每個查詢配對預期頁面與核心主張：
query,expected_url,claim_ids,required_constraints,checked_at,result
如何驗證 AI 搜尋引用,https://example.com/blog/guide,geo-01|geo-02,保留限制,false,2026-09-11T08:30:00+08:00
每次執行保存四份證據：原始問題、完整答案、引用 URL 清單、檢查時間與引擎／地區。不要只保存截圖；截圖適合目視確認，文字與 URL 才能支援差異比較。若使用 API 或瀏覽器自動化，應同時保存請求版本與登入狀態，避免把一次性的個人化結果當成趨勢。
用差異分類取代單一分數
建議把每次失敗分成四類：
- Discovery：找不到目標頁，或只找到過期索引。
- Extraction：找到頁面，但標題、日期、數字或限制被抽錯。
- Attribution：主張大致正確，但引用 URL 或段落不支持它。
- Policy：crawler 被 robots、WAF、登入或地區規則阻擋。
這種分類能直接對應修復責任：前兩類通常回到頁面與內容；第三類檢查段落邊界、來源連結與 canonical；第四類則由網站與安全設定負責。Nature 近期對多代理 RAG 的研究也把 retrieval、reasoning、validation 與 synthesis 分成不同角色；這不是網站 GEO 的標準規格，但可作為設計測試管線的合理類比：不要讓「找到」和「驗證」共用一個布林值。
最小可行的發布閘門
每次文章或網站契約變更後，至少跑以下檢查：
[ ] 目標 URL 200，Content-Type 與正文正確
[ ] canonical、sitemap、robots 與結構化資料一致
[ ] 3 個固定問題仍能對應到預期頁面
[ ] 每個核心主張都保留限制與日期
[ ] 引用 URL 不為重導向、草稿或舊版本
[ ] 失敗案例包含分類、原始答案與修復 owner
通過這個閘門後，才適合比較週與週之間的引用率。引用率本身仍會受查詢抽樣、索引更新與引擎版本影響，因此報表應同時呈現樣本數、失敗分類與原始證據，不要宣稱單次測試就是排名保證。
結論：把 GEO 當成可回歸的內容介面
網站對 AI 搜尋的介面包含公開內容、存取政策、來源關係與可觀測紀錄。最實用的起點不是追逐一個神奇標記，而是為重要問題建立固定查詢，將可取得性、主張忠實度與引用品質拆開驗證，並在每次內容部署後重跑。這會讓 GEO 從模糊的曝光觀察，變成內容、平台與安全團隊都能共同處理的工程訊號。
來源與判讀界線
- AI features and your website（Google Search Central，持續更新）：說明 AI features 仍建立在 Search 的可索引與內容最佳實務上；本文據此提出可取得性檢查，不把它解讀為特定引用排名因素。
- Cloudflare Allows the Agentic Internet to Flourish with a Simple Philosophy: Your Content, Your Rules（Cloudflare，2026-07-16）：說明 search、agent use 與 training crawler 意圖的分離；本文將其轉成政策回歸檢查建議。
- Multi agent retrieval validation and knowledge reasoning for enhanced retrieval augmented generation（Scientific Reports，2026-09-01）：提出將 retrieval、reasoning、validation、synthesis 分工的 MARCO 架構；本文只借用分層測試的工程類比，不主張該研究驗證了網站 GEO 成效。
本文的固定查詢、證據表與失敗分類是 YOTRON 的工程建議，不是來源宣稱的排名因素或引用保證。實際結果仍會受 crawler、查詢、地區、登入狀態與索引更新影響。
相關推薦與延伸閱讀
- AI Agent 可讀性與 GEO：把可讀性變成可測試的內容契約：從 HTTP 內容、瀏覽器操作、資料一致性與實際引用四個面向建立驗收方法。
- 多代理 RAG 引用驗證：從檢索到答案的 GEO 實作：延伸說明多代理檢索與跨來源驗證如何轉成可觀測流程。
- GEO 頁面契約：讓 AI 搜尋正確理解、引用你的網站內容：整理頁面主體、canonical、來源與限制條件的內容契約。