設計 GEO 內容實驗的第一步，是先寫清楚這次比較要回答什麼，再選執行安排：要問「改動是否比未改條件多帶來某個事件」，才需要對照；只能保存修改前後觀測的話，問題就縮成「兩個窗口看到哪些差異」。這適用於一次只動一個明確內容單位的修改；分母、停止規則和污染標記都要在看到結果之前寫好。本文提供的是可以在執行前填完的東西：六個事前決策欄位、有對照與無對照各能回答什麼、分析單位與分母的資料契約、五種污染的處理、觀測窗與停止規則，以及結果的三層判讀語句。
有一條規則貫穿整篇：分母和停止條件要在看結果之前決定。理由很實際——看到有利的差異之後才決定「資料夠了」，那不是實驗，那是挑一個時間點截圖。
這些是編輯與研究設計建議，不是任何平台保證的排名或引用公式。本篇只處理執行前的比較設計與判讀規則；實際的前後版本執行與結果解讀，在後續的執行與評估工作中另行完成。
GEO 內容實驗先做哪個決策
把「優化 GEO 內容」改寫成一個判讀得動的設計問題，例如：「產品頁的實體段落改版後，指定的產品描述題在同一引擎與語系下，正確性事件是否和未改頁面的對照題呈現不同方向？」
這句話指定了變更、問題集合、事件和比較方式，而且沒有預設結果會變好——後面這點很重要，題目本身先假定了方向的話，之後每一個判讀都會往那邊靠。
事前決策至少要留下這六欄：
| 欄位 | 先寫清楚什麼 | 未寫清楚的風險 |
|---|---|---|
| 變更單位 | 哪一頁、哪個段落、哪個版本 | 改了整頁卻只歸因一個句子 |
| 主要事件 | 正確描述、品牌提及、來源 URL 或其他可觀測事件 | 把不同事件加成一個模糊分數 |
| 比較設計 | 有未改對照、只有前後，或僅做現況觀測 | 事後才挑對自己有利的比較 |
| 分析單位 | 題目、引擎、模式、語系、時間如何組成一筆 | 同一回答被重複計數 |
| 判定規則 | 何時是有效回答、no_data、服務錯誤或未知 | 把資料缺失當成未提及 |
| 停止規則 | 何時完成、重設版本或停止下強結論 | 看到好結果就提早結案 |
這是本文的編輯方法建議，欄位名稱不是 Google、OpenAI 或其他引擎公開的共同實驗標準。
有對照與無對照各能回答什麼
有對照時，可以在同一觀測窗比較「改動組」和「未改組」的事件差異。它能回答的是：在目前固定的題目、引擎、模式、語系和判定規則下，改動組有沒有呈現和對照組不同的變化。比單純前後比較多一層背景——但它證明不了內容改動是唯一原因。
無對照時，能回答的是修改前後的事件有沒有同時變化、變化落在哪些題目或引擎、資料夠不夠安排下一次查核。它排除不了模型、索引、來源頁、題庫或其他頁面在同一時段的變動。只有目前版本、沒有基線的話，最多描述當下狀態。
| 設計 | 可以問 | 不應直接寫成 |
|---|---|---|
| 改動組＋未改對照 | 同期兩組的事件差異是否一致、方向是否不同 | 「對照已消除所有外部變因」 |
| 同一題前後比較 | 版本變更前後出現哪些事件差異 | 「差異一定由內容造成」 |
| 只有改版後觀測 | 新版本在指定條件下呈現什麼狀態 | 「改版帶來提升」 |
| 沒有有效基線 | 現況資料有哪些可用欄位、哪些缺失 | 「改版前是零」 |
對照題和主要題的意圖、頁面可取得性或引擎分布若不同，對照只能當背景資料。分組規則在比較前就記下來——看到結果後才把某些未改題目命名為「控制組」，那組對照是你挑出來的，不是設計出來的。
分析單位與事前分母怎麼定
一筆資料至少要回得到 prompt_id、題庫版本、內容版本、引擎、模式、語言或地區、觀測時間和原始回答。跨引擎的題庫，分析單位可以先定義成「題目 × 引擎 × 模式 × locale × 觀測時間」；同一題在同一窗口重跑時再加 run_id，否則重跑會被算成新增題目。
分母在看結果前寫好，並且按事件拆開：
| 事件 | 分子 | 分母 | 另列狀態 |
|---|---|---|---|
| 正確描述 | 有效回答中被人工規則判為正確的筆數 | 同一題型的有效回答筆數 | no_data、服務錯誤、判讀不確定 |
| 自有來源被引用 | 有效回答中出現且可回查的自有 URL 筆數 | 有效回答筆數 | URL 無法讀回、redirect 或來源不明 |
| 品牌被提及 | 有效回答中符合事前名稱規則的筆數 | 有效回答筆數 | 名稱歧義、截斷回答 |
「未適用」不是零，「未知」也不是「未發生」。題目沒有推薦意圖，就別把 recommendation 欄位放進那一題的分母；服務錯誤讓回答不存在時，保留錯誤狀態並從該事件的有效分母排除——為了湊滿題數把它當成未提及，是把一個技術故障算成了一次行銷失敗。
污染與引擎變動怎麼處理
污染是指本來要比較一個內容變更，卻同時混進了其他變因。常見的有：同週改了首頁或 FAQ、canonical 或內鏈變動、來源 URL 內容更新、題目文字被重寫、回應受快取或提示洩漏影響，以及引擎模型、模式、地區或引用呈現規則改變。
這些不必然讓觀測作廢，但要事前定義怎麼標記：
| 變因 | 事前處理 | 讀回時怎麼寫 |
|---|---|---|
| 同期其他頁面更新 | 列為 concurrent_change，必要時另開版本 | 不能只歸因目標段落 |
| prompt 或題庫改動 | 新增 prompt version，舊新分開 | 不把不同題目合併 |
| 引擎／mode／locale 改變 | 分層比較或重開觀測窗 | 不把跨條件差異當內容效果 |
| 頁面或來源不可取得 | 標為 invalid、no_data 或 unknown | 不改寫成負面事件 |
| 平台回答格式變動 | 保存原始回答和查核日期 | 結論縮小到該窗口 |
Google 的生成式 AI 搜尋官方指南指出，符合技術要求與最佳實務後，Google 仍可能不抓取、索引或提供頁面——那是平台官方界線。本文把「固定條件、保存原始回應、將污染分開」列為編輯方法建議；反過來宣稱已經控制住所有平台變動，是這套方法做不到的事。
觀測窗與停止規則怎麼預先寫
觀測窗沒有適用所有網站的固定天數。可以按內容變更速度、平台可取得性與資料成本，選固定日期窗、固定有效觀測單位，或由明確事件觸發重查。重點在先寫結束條件——理由前面說過了，這裡再點一次：先寫，你才有辦法在結果不如預期時繼續跑完。
停止規則可以包含：
- 已收集事前設定的有效觀測單位，且原始回答、來源 URL 和版本欄位可回查。
- 題目、引擎、模式、locale 或內容範圍改變，停止目前版本並重開新版本。
- 服務錯誤、空回答或來源無法讀回超過事前品質門檻，先處理資料品質。
- 發現同期重大改版或污染，保留現有資料但停止強因果解讀。
- 沒有看到差異或資料不足時，停止的是「下強結論」——不是把結果寫成內容無效。
最後一條最容易被跳過。沒有差異和「改壞了」是兩個結論，證據量也不一樣。
窗口結束後至少保存題庫版本、內容差異、原始回答、分子與分母、失敗或未知筆數、查核日期和下一個問題。這份紀錄的目的是可重查，不是把一次實驗變成長期成效承諾。
synthetic 表格如何標記非實測
下表是 synthetic 教學資料，不是實測、不是客戶案例、也不是 Otlex 正式讀回；它只示範怎麼在同一題與同一引擎下記錄日期和布林欄位。表中 ChatGPT 從 2026-09-10 到 2026-09-21 的 own_domain_cited 由 false 變 true，是資料格式示例——它支持不了「內容改版有效」或任何因果。
| observed_at | engine | prompt_id | content_version | valid_answer | own_domain_cited | evidence_status |
|---|---|---|---|---|---|---|
| 2026-09-10 | ChatGPT | GEO-ENTITY-01 | v1 | true | false | synthetic，非實測 |
| 2026-09-21 | ChatGPT | GEO-ENTITY-01 | v2 | true | true | synthetic，非實測 |
日期、引擎、false → true 全是示意值，不是 EthorX、Otlex 或任何客戶的結果。正式報告要把每一格連到原始回答、來源 URL、判讀者與查核時間；缺任何一項就改列 unknown 或 no_data。
結果如何分層判讀
把結果分成三種語句，設計選擇就不會超出證據：
| 層次 | 可寫的句子 | 還不能寫什麼 |
|---|---|---|
| 觀察 | 某題、某引擎、某窗口出現或未出現某事件 | 擴大成所有題目或所有平台 |
| 編輯推論 | 變化和目標修改方向一致，值得按固定條件重查 | 直接說改動造成事件 |
| 未知／限制 | 有效分母不足、來源無法讀回或同期有污染 | 把缺資料填成零或成功 |
只有前後資料、沒有對照時，結論通常停在「在指定窗口觀察到差異」與「這個差異可能和修改一致」這兩句。有完整對照、穩定的分析單位、事前分母和污染紀錄，才有條件把解讀往上提一層；能不能提出因果主張，仍取決於實際設計與資料品質。這是方法條件——不是在說「一般內容團隊只能做到哪一層」。
相關閱讀與 Otlex 入口
要先理解 GEO 的範圍，可讀 什麼是 GEO；要保存回答中的來源 URL，可讀 Citation Tracking；要理解為什麼同一題需要分次觀測，可讀 為什麼要重複 AI 觀測。這些既有公開頁提供背景，補不了本篇實驗資料缺的證據。
Otlex 是由 EthorX（伊索斯科技有限公司）開發的 AI 搜尋優化平台，公開產品描述涵蓋 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個 AI 引擎的回答觀測。這項產品能力描述當不了任何單一實驗的因果證明；題庫、分組、窗口與判讀規則仍按專案條件決定。產品公開資訊可見 Otlex 產品頁；若要討論題庫、頁面修改和觀測範圍，可由 聯絡我們 提供資料。
常見問題
什麼情況值得安排未改對照？
問題是「改動組是否比同期未改組多出某個事件」的時候。對照題要在執行前定義，意圖、引擎和有效回答規則要可比較；即使如此，它也排除不了所有外部變因，只是多給你一層同期背景。
沒有對照時，前後差異還能寫嗎？
可以寫成指定題目、引擎與窗口中的觀察差異，並保留原始回答、分母與同期變動。兩件事不能寫：把它當成內容改動造成結果，以及把「沒觀察到差異」寫成內容無效。
分母為什麼要在實驗前決定？
先看結果才刪錯誤、換題目或改事件定義的話，前後數字就不再可比。事前分母讓讀者知道哪些是有效回答、哪些是 no_data 或服務錯誤；狀態缺失時保留未知——補零會讓一個資料問題長得像一個結果。
引擎或 mode 中途更新要怎麼辦？
把變動日期、版本或可觀察的模式差異記下來，停止目前窗口的強結論。條件變動大到會改變問題的話，就開新版本或分層報告——不同模式的回答直接合併成一個內容效果，那個效果是算出來的，不是觀測到的。
synthetic 表格可以放進正式成效報告嗎？
只能當欄位格式或教學示例，而且表格旁要標明 synthetic、非實測、非客戶結果。正式成效報告改用可回查的原始回答、來源 URL、日期、分子、分母和判讀狀態；沒有這些資料就報告未知。
查證邊界
本文查核日期為 2026-09-21。Google 生成式 AI 搜尋官方指南、Search 更新紀錄與可抓取內容依 Google Search Central；ChatGPT 搜尋引用的限制依 OpenAI Help Center；EthorX 與 Otlex 描述依公開公司與產品頁。對照設計、分析單位、分母、污染、觀測窗與停止規則是本文編輯方法建議，沒有宣稱跨平台控制資料、客戶成果、統計顯著性或內容改版保證。synthetic 表格與 GEO-ENTITY-01 僅供示意，並非實測或正式讀回。
參考來源
- Google’s Guide to Optimizing for Generative AI Features on Google Search，Google Search Central。
- Latest Google Search documentation updates，Google Search Central。
- Searching the web with ChatGPT，OpenAI Help Center。