GEO 的結果不是「頁面排第幾名」，而是 AI 搜尋在回答真實問題時，是否找到你的內容、引用正確段落，並把使用者帶到正確頁面。這使得傳統只看排名或流量的報表不足以診斷問題。
Google Search Central 的指南說明一般搜尋原則仍然適用；GEO 研究綜述則把生成引擎描述為部分可觀測的多階段流程。本文將公開說明轉成固定題庫與證據記錄方法，並不聲稱能從外部答案看見平台內部的檢索或重排決策。
先定義「引用成功」
每次觀測分開記錄欄位與證據：
mentioned：是否提到品牌或產品，可填 true、false 或 unknown。cited_urls：實際來源網址清單；完整取得但沒有來源時為空清單，未完整取得時保留未知。faithful：逐項判斷來源是否支持對應說法，未完成核對時保留 unknown。actionable：另測使用者能否完成閱讀或聯絡等下一步，不把它當成已發生轉換。
品牌提及、本站引用與目標頁引用分開判定。沒有引用可能涉及問題意圖、平台選擇、索引時差或網站內容等因素，不能單憑答案推定 canonical 或內鏈有錯。引用錯誤也要先核對來源版本，再判斷是否需修正文案。
建立固定查詢集
用同一份 CSV 保存 query_id、query、locale、engine、run_at、page_version 與 answer_url；answer_url 是回答的位置，不是來源頁。另保存原始回答、完整來源、引擎模式、搜尋設定、登入條件、重複次數及失敗原因。題目分成四類：
- 品牌定義：公司解決什麼問題？適合誰？
- 服務比較：與替代方案相比，差異與限制是什麼？
- 問題排解：遇到具體錯誤時，應先檢查哪些步驟？
- 購買意圖：台灣中小企業如何估算導入成本與風險？
同一題至少在兩個允許網路搜尋的引擎執行，保存答案與引用連結。不要用一次回答宣稱成功：生成答案會變動，應在相同條件下重複比較。模式或覆蓋不同時分開呈現；改版後差異也可能來自索引延遲或平台變動，不能直接當作因果證據。
提及率以可判定提及的回答為分母；本站或目標頁引用率以來源完整且可判定的回答為分母。另列原定數、成功數、失敗數及未知數；沒有有效分母時標示無法計算。
對每個引用做三層回歸
1. HTTP 與可抓取性
對 cited_urls 中的來源頁取得 GET 回應，保存狀態、最終網址、內容類型與正文，再檢查 canonical 及索引指令。不要對 AI 回答頁的 answer_url 做本站來源檢查。HEAD 僅能初篩；HTTP 200 也可能是挑戰頁。初始 HTML 與瀏覽器渲染分開檢查，不能假設所有引擎都無法處理 JavaScript。
2. 語意一致性
解析 Article、Organization 與 BreadcrumbList JSON-LD，逐欄比對可見標題、作者、日期、URL 與圖片。Schema 是語意提示，不應加入正文沒有的價格、評價或資格。
3. 引用保真性
把答案中的主張切成最小片段，逐一對回頁面段落。若答案遺漏「僅限」「截至某日」等條件，將 faithful 設為 false，並保存對照證據。若原文已清楚表達，可能是引擎誤讀；不要未經診斷就重寫。修正確認存在的內容問題後再重跑。這比追逐單次引用率更能找到可修復的缺口。
端點初篩與版本記錄範例
下列使用假設網址，執行時需替換。命令輸出是初篩資料，不代表完整驗收。
# 1. 入口與內容
curl -sS -L https://example.com/robots.txt
curl -sS -L https://example.com/sitemap.xml
curl -sS -L https://example.com/core-page | sed -n '1,120p'
# 2. 發布後保存版本與端點結果
git rev-parse HEAD
curl -sS -o /dev/null -w '%{http_code} %{content_type} %{url_effective}\n' \
https://example.com/core-page
將每次結果寫入以日期標示的 CSV；欄位至少包含 http_content_ok、schema_ok、mentioned、cited_urls、faithful、actionable、error_type。按引擎、模式與題型聚合，用於提出後續查核方向；不能單憑統計確定平台內部原因。git HEAD 只代表本機提交，若有未提交內容或部署版本不同，另行記錄；它也不能證明引擎索引版本。
llms.txt 應放在哪裡
llms.txt 可以是文件型網站的人工導覽，但不是 robots.txt 的權限控制，也不是 Google AI 搜尋的排名保證。發布後應測試 agent 能否沿著索引在有限請求內找到正確頁面，並把測試結果和引用 QA 放在同一筆版本紀錄。若沒有文件可維護，先修正 sitemap、canonical、初始 HTML 與內部連結，收益通常更容易驗證。
來源與判讀界線
- Google Search Central：針對 Google 搜尋中的生成式 AI 功能進行優化的指南，2026-09-09 回讀。官方技術要求與常見迷思。
- arXiv：Optimizing Visibility in Generative Engines: A Critical Survey，提交日期為 2026-07-15。GEO 流程與評估問題的研究綜述。
上述來源分別是平台指南與研究觀點；固定查詢集、CSV 欄位與回歸步驟是本文的 YOTRON 實務分析，不是任何平台公布的排名公式。
結語
把 GEO 當成引用品質檢查，而不是一次性的關鍵字專案：固定問題、保存版本、檢查端點、比對原文，最後才看引用趨勢。這條管線能指出真正要修的地方，也能在 AI 平台改變時保留可比較的證據。
相關推薦與延伸閱讀
- GEO 實作：把網頁做成可被 AI 引用的技術契約：AI 搜尋能否正確引用網站，取決於可索引內容、主張與來源、引用驗證及可執行答案是否形成完整契約。本文提供可落地的頁面與評估方法：拆解四層頁面契約，說明如何讓代理
- GEO 實作：用多代理 RAG 建立可驗證的引用流程：多代理 RAG 不只要找到資料，還要驗證跨來源一致性與引用保真度。本文提供一套可重複的 GEO 評估流程，說明為什麼要拆成檢索、推理、驗證與合成四個角色、如何分
- AI Agent 可讀性與 GEO：把可讀性變成可測試的內容契約：建立 AI agent 可讀性的驗收方法：分開檢查 HTTP 內容、瀏覽器操作、資料一致性及實際引用，避免把技術檢查通過誤當成引擎採用證據。本文先定義四個可測試
- GEO 引用回歸測試：把 AI 搜尋答案變成可驗證的工程訊號：AI 搜尋的引用結果會受查詢、索引與檢索上下文影響。本文建立一套可重跑的 GEO 引用回歸測試，分開驗證可取得性、主張忠實度與引用品質，說明如何建立固定查詢與證
- GEO 實作：把 AI 搜尋偏好來源變成可驗證的引用訊號：Google 的 preferred sources 讓使用者能指定偏好來源。本文示範如何把來源一致性、可引用段落與事件追蹤整合成 GEO 驗證流程，說明按鈕互