GEO project scoping 的做法，是先把「這次要觀測什麼、交付什麼、由誰負責」寫清楚，再談工具、服務或時程。範圍要寫出市場、語言、AI 引擎、題目意圖、目標頁面、資料保存、內容與工程角色、交接方式，以及明確排除的事項。這適用於跨角色、跨團隊的 GEO 專案；範圍中途變動時，新增一列和責任，別用一句「順便處理」帶過。本文提供的是可以直接寫進 scope 文件的東西：七個範圍層、一張交付與不包含對照表、六種責任角色的邊界、五步處理範圍變動，以及哪些話不該寫進 scope。
裝潢報價單會寫清楚哪幾面牆要打掉、哪幾扇窗不動、誰申請許可。沒寫的那一面牆，通常就是後來吵架的那一面。GEO 專案也一樣——「想做 GEO」和「這次要觀測台灣繁中的五題服務選擇題、交出證據卡、不含頁面發布」，是兩份完全不同的合約。
本文提供的是討論範圍的編輯方法，不估算固定天數、不設定固定價格，也不把 AI 回答中的提及或引用寫成可承諾的成果。
Otlex 示範帳戶總覽，僅用來示範 scope 需核對的範圍與狀態；畫面資料不代表客戶成果，也不單獨證明因果效益。
先把專案問題寫成一句話
範圍討論的第一步，是把「想做 GEO」改成一個可查證的工作問題。例如：
- 想知道台灣繁體中文題目中，品牌在某一組服務選擇回答裡如何被描述。
- 想核對產品頁的公開事實是否能支持常見比較題。
- 想建立 Day 0 觀測、把證據交給內容團隊，再決定是否需要修改頁面。
- 想比較多個 AI 引擎的回答和引用，但先限定某個主題與市場。
這一句話會往下決定題目、資料、角色和交付。寫成「提高 AI 可見度」的話，範圍就還是空的——觀測、內容、工程和發布四種工作會被打包成一項服務，而它們的責任人、工時和授權全都不同。
Google 官方 AI features 文件指出，AI Mode 和 AI Overviews 建立在一般搜尋的索引和內容處理上，也可能使用查詢展開；頁面是否被索引或顯示不由專案單方面決定。scope 因此要把可控工作和外部搜尋結果分開列出。Google AI features 官方說明
GEO project scoping 的七個範圍層
一、研究問題
先定義要查什麼現象，例如品牌描述、產品比較、服務選擇、引用來源或內容缺口。研究問題要連得到題目和判讀。判斷方法：這個問題能不能直接寫成一題 prompt？不能的話，它還是一個目標詞，不是研究問題。
二、市場與語言
列出地區、語言、文字系統、必要的裝置或上下文。台灣繁中和其他市場的題目分開放。題目語境、品牌資料和內容責任都可能不同——混成一組之後，報表上的每個數字都要附一段解釋才看得懂。
三、引擎與觀測條件
列出這次會觀測的 AI 引擎、帳號或公開條件、執行日期和保存方式。若使用 Otlex，公開產品定位包含 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個引擎；實際方案和範圍仍要逐項確認，不應從產品定位推導每一項條件都會相同。EthorX GEO 工具頁
四、題目與意圖
說明題目來源、題目數量的組成方式、意圖分類、版本和責任角色。題庫由多個團隊共用時，另外建立 prompt library 的審核和退役規則。一次性研究題目直接丟進長期追蹤集合，半年後那個集合裡會有一批沒人記得為什麼在跑的題目。
五、頁面與內容工作
列出可能被核對的頁面，例如公司介紹、產品頁、服務頁、比較頁或 FAQ。每個頁面寫責任角色、允許的修改類型、需要的品牌或產品核准。內容建議、編輯修改、工程實作和發布分成四格——它們常常由四個人做，卻很容易在 scope 裡被寫成一句「更新頁面」。
六、資料與交付
說明會保存哪些回答、引用、日期、執行狀態、人工分類、任務和匯出檔。交付可以是 baseline 包、證據卡、缺口清單、內容規格或交接摘要。每一項寫出「誰用」和「怎麼算完成」——少了這兩欄的交付項目，最後都會變成一個沒有人打開的檔案。
七、責任與排除
寫出誰提供品牌事實、誰核准主張、誰改內容、誰改網站、誰負責正式發布，以及哪些事項不在本次範圍。被列進協作名單，和擁有發布或部署授權，是兩件事。名單上的名字不會自動帶著權限。
把交付和不包含事項列成表
一張 scope 表可以讓業務、客戶、內容和工程角色用同一份文字討論：
| 範圍項目 | 本次要交付 | 需要誰提供或核准 | 明確不包含 |
|---|---|---|---|
| 觀測 | 指定市場、語言、題目和引擎的結果 | 題庫責任角色、資料責任角色 | 所有市場與所有題目 |
| 證據 | 回答、引用、日期、狀態和限制 | 觀測執行者 | 搜尋系統內部資料 |
| 判讀 | 品牌事實與內容缺口的待辦 | 品牌、產品或內容角色 | 自動批准品牌主張 |
| 內容 | 內容規格、編輯建議或指定頁面修改 | 內容責任角色 | 未核准全站改寫 |
| 網站 | 已授權的技術檢查或工程任務 | 工程責任角色 | 自動部署、重導或 URL 變更 |
| 追蹤 | 約定條件下的後續觀測 | 觀測與分析角色 | 保證提及、引用或排名 |
「不包含」那一欄不是在縮小合作，它是在保護每個角色知道自己要做什麼。真的要增加範圍時，新增一列和責任——「順便處理」這四個字免費開始，最後由某一個沒被問過的人結帳。
Otlex 示範帳戶行動清單，僅用來示範 scope 變動時可回查的工作項目；畫面資料不代表客戶成果，也不單獨證明因果效益。
依責任角色安排工作邊界
範圍文件可以用 RACI 類似的思路，但要以團隊真的使用的角色名稱為準：
- 資料或研究角色：定義觀測條件、保存材料、標記執行狀態。
- 品牌或產品角色：確認公司、產品、功能與服務事實。
- 內容角色：判斷頁面是否支持主張、提出修改建議、完成編輯。
- SEO 或網站角色：處理頁面結構、內部連結、可抓取性或其他已核准工作。
- 工程角色：處理網站程式、整合、權限、部署前檢查。
- 發布責任角色：批准正式公開變更並完成獨立發布流程。
一個人可以兼任多個角色，範圍文件仍然寫出兼任關係。它擋的是兩種誤會：客戶以為「服務方會完成所有修改」，以及內容角色被推去批准自己沒有權限核對的產品主張。
Day 0 baseline 可作為範圍的第一個交付，但要把起始觀測與後續內容改動分開。若需要交給內容團隊，參考 GEO client handoff的證據卡；若要設計 dashboard 欄位，參考 AI 搜尋監測 dashboard。
遇到範圍變動怎麼處理
範圍變動很常見，重點是保留變動前後的語境。可以按以下五步處理：
步驟一：指出變動來源
記清楚是新增市場、換語言、增加引擎、修改題目、加入頁面、增加角色，還是更改交付。「需求增加」這四個字，兩週後沒有人還原得出當初改了什麼。
步驟二：檢查受影響的資料
判斷變動會不會讓舊結果不能直接比較、讓題目需要重新審核，或讓原本的責任人不再適用。把受影響的基準和報表列出來。
步驟三：更新交付與排除
新增工作時，同時寫出新增的驗收條件、責任角色和不包含事項。若縮小範圍，也要保留被移出的項目和原因。
步驟四：重新確認授權
內容修改、工程變更、正式 URL、重導、部署或外部資料處理都可能需要不同的責任角色。scope 更新不會順便產生授權——這兩件事各自要有人簽名。
步驟五：告訴接收者哪些結果不可直接比較
交接文件或 dashboard 應標示條件改變的日期。新結果獨立呈現。默默接在舊趨勢後面的那一段，日後只有當初做的人看得懂。
如果需要比較工具能力，使用 GEO 工具評估框架；如果需要先核對採購交付，使用 AI 搜尋監測工具採購清單。這些文章分別處理能力、採購和 scope，不互相替代。
常見問題
GEO project scoping 應該先定市場還是先選工具？
先定研究問題和範圍，再選工具。市場、語言、題目、引擎和證據欄位決定了工具要展示什麼能力——順序反過來的話，scope 會被示範畫面和功能名稱帶著走，最後買到的是介面，不是答案。
scope 要不要列出所有七個 AI 引擎？
專案 scope 可以按問題、語言、資料和資源選一部分。Otlex 公開定位觀測七個引擎，那是產品範圍；這次實際涵蓋哪幾個要列出來，沒涵蓋的寫成排除或後續範圍——兩份清單長度不同是正常的。
GEO project scoping 可以直接寫固定完成日期嗎？
已經有核准資源、依賴和工作量證據時，可以給計畫日期。題庫審核、品牌事實、內容修改、工程和發布各有各的依賴——先寫完成條件、再回推日期，比先答應一個日期再想辦法可靠。
scope 文件要包含內容改寫全文嗎？
本次交付是研究和內容規格的話，scope 列出頁面、問題、證據和編輯輸出就夠。真的包含全文改寫，再把語氣、來源、核准與發布責任另列——一份 scope 同時當研究報告和發布授權，等於讓寫報告的人替發布簽名。
範圍變動後要重新做所有觀測嗎？
看變動影響。如果市場、語言、引擎、題目或條件改變，原本結果可能要分組或另立基準；如果只是補充交付格式，可以保留原觀測並更新文件。由資料責任角色按受影響欄位判斷，並留下理由。
結語
GEO project scoping 的目的，是把研究問題、觀測範圍、內容責任、工程邊界和交付條件寫成所有角色都能核對的文字。先定義可控工作，再標示外部搜尋結果和未包含事項，遇到變動時留下前後差異，團隊就能在不誇大承諾的前提下推進。若需要討論實際市場、頁面或角色範圍，可到 EthorX 聯絡頁提供需求，正式 scope 仍以核對後的授權和交付為準。
scope 討論可先看 GEO 服務頁 的公開工作範圍，再用 Otlex 產品頁 核對觀測定位。
查證邊界
本文查證日期為 2026-09-21。Google AI features 文件支持可抓取、索引資格與 AI 顯示的公開邊界；EthorX GEO 工具頁支持 Otlex 公開列出的七個 AI 引擎產品定位，但不支持任何專案必須涵蓋七個引擎、固定期程或成效保證。文中的裝潢報價比喻與五題服務選擇題是說明用的假設情境。本文的 scope 表與交付／排除條件是依研究問題、資料、責任和資源提出的編輯方法；實際方案與權限仍要在專案開始前核對。示範帳戶介面圖不代表客戶成果，也不單獨證明工具有效性。
參考來源
- Google Search Central：AI features and your website（支持 AI 顯示與索引邊界）
- EthorX：GEO 工具類別頁（支持產品公開引擎定位，不替專案 scope 或工具有效性背書）