GeoCheck GEO（生成式引擎優化）產品與方法論白皮書
從單一分數改為四項分開判讀：MCAC 量測架構、題型與判讀規則
推薦題 2 題、事實題 1 題、行動題 1 題，分別判讀提及、引用來源、資訊正確性與行動資訊。資料契約沒有總分（total 固定為 null），未知不等於 0。
重要聲明與研究邊界
- 非商業成效保證：GeoCheck 量測的是特定條件下「可觀測的搜尋與引用證據」，絕不承諾或保證任何搜尋引擎或 AI 平台的特定排名、推薦率、點擊流量、獲客量或營收轉換。
- 非模型內部認知：四項判讀記錄的是 AI 公開回答中可觀測的事件，包括有沒有提到品牌、來源清單有沒有官網、電話地址和品牌頁面是否一致，以及有沒有給出下一步。它們不代表大型語言模型（LLM）內部的信念或偏好，來源出現次數也不是信任權重。
- 未知不等於零：平台服務中斷、網路逾時、API 拒答或無法解析之回答，均歸類為「未知（unknown）」，不假定為表現為零。網站讀不到時，這次不詢問 AI，四項都標未知。
1. 緒論：為什麼要分開量測？
1.1 從傳統 SEO 到 GEO（生成式引擎優化）
傳統搜尋引擎（如 Google、Bing）的核心是「排序藍色連結（Ranked Blue Links）」，其評估體系以關鍵字排名、展示次數（Impressions）與點擊率（CTR）為中心。
生成式 AI 搜尋（如 ChatGPT Search、Google AI Overviews）改變了答案的呈現方式：AI 直接生成綜合解答，而非僅列出網頁清單。
在生成式回答中，品牌至少會遇到四件可以分開觀察的事：
- 提及（Mention）：顧客沒說店名時，AI 有沒有主動講到這個品牌？提到不等於推薦，也可能是比較或批評。
- 引用來源（Citation）：回答列出的來源裡，有沒有品牌的官網？還是都來自食記、地圖與評論？
- 資訊正確性（Accuracy）：AI 給的地址、電話，和品牌自己的頁面一不一致？
- 行動資訊（Conversion-readiness）：AI 有沒有給出電話、網址、地圖或訂位等可執行的下一步？
檢索機制報告在六家台北牛肉麵店、單一 API 的探索性試驗中觀察到：未確認自有網域的店仍被提及，也取得與參照表一致的地址與電話；有官網的店，官網也不一定出現在來源清單。合成單一分數會遮住這些差別，所以 GeoCheck 分開判讀四項。報告也提醒，這四個構面是操作性整理，尚未經統計證明彼此獨立。
1.2 當前市場痛點：黑盒巫術與過度承諾
當前市場對 GEO 充滿焦慮與投機，常見問題包括：
- 虛假因果承諾：宣稱「填寫特定 Schema 標籤或改寫內容，即可 100% 登上 AI 推薦第一名」。事實上，生成式引擎具備隨機取樣（Temperature > 0）與即時 RAG 動態重排序特性，不存在確定性的排名保證。
- 混淆指標與構念：將網站內部的技術分數（例如 HTML 結構、結構化資料完整度）直接混充為「AI 已經喜愛並推薦你的網站」。
- 無效填補與偏誤：測試 API 一旦拒答或連線失敗，許多工具直接把該次查詢記為 0 分，等於把「沒拿到資料」誤判成「品牌表現為零」。
2. 量測架構：三種題型、四項分開判讀
MCAC 不把四項壓成一個分數。一次檢測分成題組、判讀與網站條件三層：
1. 三種題型，共 4 題
- 推薦題 2 題（不帶店名）
- 事實題 1 題（地址與電話）
- 行動題 1 題（下一步）
- 不做比較題（受順序影響）
2. 四項分開判讀
- 提及：看推薦題
- 引用來源：看四題的來源
- 資訊正確性：事實題對照你的頁面
- 行動資訊：看行動題
3. 輔助技術診斷：網站條件
200 / 301 重定向與伺服器回傳
搜尋與 AI 爬蟲存取規則
Organization / Schema 實體對齊
H1–H3 階層與可閱讀內文深度
2.1 每次只問一個 AI 搜尋
出題與回答分開：一個模型依網站內容規劃推薦題，另一個被量測的 AI 搜尋回答 4 題。每次檢測只用一個被量測的 AI 搜尋，其他引擎一律不用；出題失敗時，也不改用其他模型。
3. 單站檢測流程（MCAC 0.2.0）
使用者在首頁輸入網址後，系統依序執行：
- 讀網站：以一般抓取或瀏覽器渲染讀取首頁。所有讀取方式都失敗時直接停止，不詢問 AI，四項標為未知。
- 規劃推薦題：依頁面內容規劃不帶店名的候選題，系統優先選「推薦型」題目，並略過太相近的題目；使用者自訂的推薦題優先採用，最多 2 題。規劃失敗時推薦題標為未知，事實題與行動題照常執行。
- 組成事實題與行動題：用網站上的店名與地區提問，題目不放網域，避免把 AI 引向官網而灌高引用。
- 詢問 AI：4 題依序送給被量測的 AI 搜尋；遇到可重試的錯誤，每題最多重試 1 次。
- 讀出頁面資料並判讀：從網站的結構化資料（JSON-LD）與頁面文字讀出電話、地址與營業時間，最多再讀兩個門市頁或聯絡頁，再與 AI 的回答比對，產出四項判讀與報告。
品牌的別名只取自網站資料與推薦題的規劃結果，不另外花一題確認身分。別名可能抓不全，提及因此可能偏保守；報告會列出所用的品牌名稱。
4. 判讀規則（mcac-flags-v0）
判讀門檻為 v0 暫定，可能依實測資料調整。每項只看指定的題目，分母只計有效回答：
| 項目與題目 | 記錄什麼 | 標記 |
|---|---|---|
| 提及（Mention） 看推薦題 | 提到品牌的題數／有效推薦題數；有清單時記錄名次 | 全部提到為「有」，部分提到為「部分」，都沒提到為「無」，沒有有效回答為「未知」 |
| 引用來源（Citation） 看四題 | 官網出現在幾題的來源中，以及官網、地圖、社群、訂位平台、評論論壇等各類來源的數量 | 至少一半為「有」，至少一題為「部分」，都沒有為「無」；沒有有效回答，或輸入的是平台頁（例如粉專），為「未知」 |
| 資訊正確性（Accuracy） 看事實題 | 電話與地址各判為正確、和你的頁面不一致、未提供或無法核對；營業時間只記錄、不判定 | 任一項不一致為「不一致」；否則任一項正確為「正確」；兩項都無法核對為「無法核對」；其餘為「未提供」；事實題沒有回答為「未知」 |
| 行動資訊（Conversion-readiness） 看行動題 | 回答中的電話、網址、地址、地圖、訂位、訂購或 LINE 等入口；官網入口另列 | 至少一個可執行入口為「有」，沒有為「無」，行動題沒有回答為「未知」 |
4.1 為什麼稱「和你的頁面不一致」
資訊正確性以使用者自己的頁面為準，也就是官網，或輸入粉專時的粉專。AI 給的電話或地址出現在頁面上，判為「正確」；沒有出現，判為「和你的頁面不一致」；頁面沒寫的項目標「無法核對」，不算錯。
不一致不稱為錯誤，因為工具無法判斷哪一方才對：可能是頁面資料過時，也可能是 Google 地圖等其他平台列的資料不同。檢索機制報告也指出，第一方不天然等於正確，未維護的官網可能過時，第三方資料則可能較新。報告會列出 AI 給的值，並提醒店家確認後把官網、粉專、Google 商家等各平台的資料統一。
比對方式沿用研究的分析規則：電話只比數字（+886 視同 0）；地址統一「臺／台」、全形與半形、郵遞區號與「四段／4段」等寫法後，從路名比到門牌號。頁面列出的每一組電話與地址都算正確答案，傳真除外。
4.2 沒有總分
MCAC 的資料契約沒有總分，total 固定為 null。四項判讀各自附題數與原始回答；被提到不等於被推薦，來源出現次數也不是 AI 的信任權重。
5. 網站條件：基礎建設與非因果限制
網站條件檢查網站的機器可讀性（HTTP 存取性、Robots、Sitemap、Schema.org JSON-LD 與內容密度），在報告中獨立列出。
頁面能被抓取與索引，是搜尋系統引用它的前提，但不是保證。結構化資料可以協助表達店名、地址等資訊；Google 也說明，它的 AI 搜尋功能不需要特殊標記，結構化資料不保證顯示。網站條件不計分，也不影響四項判讀。
6. 白皮書研究批次流程：凍結題組與嚴謹母體
當進行跨品牌、跨產業的基準調查或研究白皮書時，嚴禁使用單站檢測的動態題目。批次研究恪守以下原則：
- 受控題組（Frozen Query Set）：全體受測樣本面對完全相同的提示詞（Prompts）。題目一旦審定封存，不可事後調整以迎合特定品牌。
- 實體主檔鎖定（Entity Master Lock）：在啟動 API 批量測試前，必須完成人工實體主檔審查，明確定義品牌正式名稱、已知別名、官方主網域與專屬路徑。
- Preflight 覆蓋防護：執行前進行程式化預檢。凡有未對齊實體或母體定義模糊者，系統直接阻擋執行。
- 禁止靜默備援（No Silent Fallback）：研究批次中，搜尋供應商若連線中斷，一律記為失敗，禁止自動切換至其他模型，確保樣本處於同一模型基準線。
7. 研究限制與治理規範
- 快檢不是研究結論：每項只有 1 到 2 題、跑一次，推薦題自動產生、未經人工審題。結果是一次快照，不能當成研究結論或長期趨勢引用。
- 時間波動性（Temporal Drift）：生成式搜尋每週微調模型或更新索引。量測結果代表特定時點的可觀測狀態，不代表永久排名。
- 單一引擎限制：每次檢測只問一個 AI 搜尋，結果不能直接外推到其他 AI 平台。
- 資料只比對使用者的頁面：資訊正確性只以使用者自己的頁面為準；研究版另外核對 Google 商家檔案，快檢沒有。
- 探索性相關分析：若探討四項結果與客流量的關係，嚴格定性為探索性相關，嚴禁宣稱因果關係。
- 可重算：判讀規則公開，報告保留每一題的原始回答與來源，可以由原始回答重算四項結果；研究資料集另計算 SHA-256 雜湊值，並揭露未知與失敗紀錄。
8. 舊版方法（Classic，已退出公開快檢）
8.1 指標定義：AI 信任值
在經審定的非品牌發現查詢集中，針對所有取得有效且可見回答的執行次數（\(N_{\text{valid}}\)），「AI 信任值」定義如下：
$$\text{答案採用率} = \frac{\sum \text{提及已對齊品牌之有效查詢數}}{N_{\text{valid}}}$$
$$\text{來源證據率} = \frac{\sum \text{引用經核實第一方官方 URL 之有效查詢數}}{N_{\text{valid}}}$$
樣本不足封頂防呆（Coverage Cap at 69 分）：單次偶發的成功無法代表穩定的市場能見度。若受測網站有效查詢次數 \(N_{\text{valid}} < 2\)，前端產品顯示分數嚴格封頂於 69 分，防止單一題目偶然被提及時產生虛假的滿分誤導。
8.2 Classic 單站檢測流程
- 多重抓取彈性保障：優先以輕量 HTTP 抓取目標頁面 HTML；遇客戶端渲染自動退回 Headless 瀏覽器渲染模式。
- 非品牌題目生成與防呆：使用結構化 LLM 依頁面證據產出 5～8 個候選題，並以確定性正規表示式嚴格剔除包含受測品牌的題目。若兩輪無法湊齊可選出 4 題的合規非品牌題，系統主動停止搜尋並標示
unknown。 - 實體查詢隔離：額外執行 1 次帶品牌名稱的實體查詢（Direct Entity Query），但僅用於綁定官方別名與網域，不併入非品牌發現的評分分母中。
8.3 證據判定：答案採用 vs. 來源證據四象限
Classic 將 AI 的輸出拆解為兩個維度：答案層是否提及品牌（65%）、來源層是否引用官方網域（35%）。
8.4 為什麼退出公開快檢
Classic 每次問 4 題不帶店名的發現題，四題量的都是同兩件事，也就是有沒有提到品牌、有沒有引用官網，再以 65／35 加權成一個分數；資訊正確性與行動資訊沒有量測。檢索機制報告指出單一分數看不出品牌缺在哪裡，公開快檢因此改用第 2 至 4 章的 MCAC。