這一課會完成什麼
- 分清楚技術 SEO、讀者價值、結構化資料與生成式搜尋可見度各自解決的問題。
- 建立固定查詢集、基準快照與可重跑的引用檢查，不用單次手動搜尋宣告成效。
- 把頁面修改、索引狀態、答案出現、引用正確性與商業結果串成同一筆實驗紀錄。
開始前先準備
- • 一個可修改且允許量測的公開網站，以及 Search Console 或同等搜尋資料。
- • 一頁有明確讀者問題、可驗證主張與公開來源的既有內容。
先把定義說清楚
SEO 與 AI 搜尋
SEO 先確保搜尋系統能抓取、索引並理解對讀者有用的頁面；GEO 則進一步觀察生成式搜尋是否在合適問題中找到、正確表述並引用該內容。兩者可以並行，也沒有一個所有引擎共用的「AI 排名分數」。可執行的做法，是固定市場、語言、查詢意圖、測試頁面、觀察日期與判定規則，留下回答與引用快照，再把曝光訊號與站內行為分開解讀。沒有基準、對照與重跑規則的截圖，只能當線索，不能當成效果證明。
AI 搜尋的答案會受查詢措辭、位置、登入狀態、模型版本與時間影響。同一題今天有引用，明天可能換來源；只挑成功畫面，團隊很容易把波動誤認為內容修改的結果。固定查詢集與多次觀察雖然不華麗，卻讓變化至少能被比較。
生成式答案裡出現品牌名稱，不等於使用者看過正確主張，更不等於帶來合格訪客。實驗要分開記錄「有沒有提到」「有沒有引用」「引用是否支持句子」「連結能否到達」「到站後是否完成有意義行動」。把這些事件混成單一可見度指標，會遮住錯誤引用與無效流量。
搜尋內容仍要服務真實讀者。為了猜測模型偏好而大量製造重複定義、沒有證據的比較表或與正文不一致的 schema，既可能降低信任，也可能踩到搜尋政策。先修技術阻塞與內容缺口，再用小範圍實驗檢查 AI 搜尋，是更能被團隊維護的順序。
現場情境
Atlas Secure GEO 實驗
教學用合成案例。公司、查詢結果、流量與轉換數字均為練習設定，不代表任何搜尋引擎或客戶成效。
- 負責人
- 搜尋成長負責人，要判斷是否更新一篇零信任存取指南，並向內容主管說明證據強度。
- 要做的決策
- 先修正可索引性、過期定義與缺少的來源，再以 12 個繁中查詢建立基準；其中 6 個為資訊查詢、4 個為比較查詢、2 個為品牌查詢。28 天內每週依相同紀錄規則觀察，不因單次未引用反覆改稿。
- 目前狀態
- Atlas Secure 的指南在傳統搜尋有穩定曝光，但團隊只保存過 6 張 AI 答案截圖，其中 4 張來自同一個查詢。有人提議一次改寫 20 頁，加上大量 FAQ schema；現有紀錄沒有日期、地區、答案全文、引用網址或到站事件。
- 預期成果
- 實驗結束時能交付頁面 diff、索引證據、48 次查詢觀察、引用正確性判定、站內行為與限制說明。即使沒有提升，也能指出是技術阻塞、內容不匹配、樣本不足或目前無法歸因。
限制條件
- • 測試期 28 天，只能修改 1 個主要頁面與 1 個對照頁面。
- • 繁中與英文查詢必須分開記錄，不能把不同市場結果合併。
- • 所有產品、安全與效能主張都要能回到公開文件；不得製造客戶數字。
- • 搜尋引擎條款不允許的自動查詢不能執行；必要時由指定研究者手動採樣。
實作範例
把「讓 AI 更常提到我們」改成可反駁的假設
證據類型: 具名模擬情境Atlas Secure 原假設是「加入 10 組 FAQ 與 Organization schema，AI 可見度會提升 30%」。這句話沒有定義可見度，也沒有說 30% 的分母。檢查後發現主要頁面 canonical 指向舊網址，三個關鍵定義沿用兩年前文件，而預計加入的 FAQ 在可見正文裡根本不存在。這時直接大量加 schema，無法知道後續變化來自修正技術問題、內容更新，還是搜尋結果本身波動。
團隊先把假設縮成：「修正 canonical、更新 3 個有來源的定義，並讓頁面明確回答 6 個資訊查詢後，28 天觀察窗中，正確引用該頁的觀察次數相對基準增加；錯誤引用率不得上升。」對照頁只修技術問題，不改內容。每次觀察保存查詢、語言、地區、日期、答案節錄、引用網址、是否支持答案、頁面版本與研究者。
範例結果不宣稱因果：測試頁正確引用從 48 次觀察中的 5 次變成 9 次，對照頁從 4 次變成 5 次；兩頁傳統搜尋曝光都上升。研究紀錄只寫「值得延長觀察」，沒有寫成「GEO 帶來 80% 成長」，因為樣本小、沒有隨機化，而且搜尋產品在期間內可能更新。團隊另發現兩次引用連到舊網址，優先處理轉址與 canonical。
主張限制
12 個查詢與 28 天只能示範實驗紀律，不能代表完整市場。手動觀察可能受個人化影響；答案出現與站內轉換之間也缺少穩定識別。schema 只能幫助描述頁面內容，不能保證顯示或引用。實務上要保留搜尋介面與模型版本變動、季節性、品牌活動及其他頁面修改等干擾因素，結論強度要跟設計相稱。
做法
照著做，每一步都有檢查點
現場情境
先修正可索引性、過期定義與缺少的來源，再以 12 個繁中查詢建立基準；其中 6 個為資訊查詢、4 個為比較查詢、2 個為品牌查詢。28 天內每週依相同紀錄規則觀察，不因單次未引用反覆改稿。
- 01建立分層查詢集與基準
- 02先排除技術與品質阻塞
- 03寫出單一修改假設
驗收條件
完成品要成為一包可交給別人重跑的證據，無須追求一張漂亮排名圖。讀者能分辨哪些是頁面修改、哪些是搜尋觀察、哪些是到站結果，以及目前能說到哪裡、不能說到哪裡。
- 01
建立分層查詢集與基準
從 Search Console、客服問題與銷售異議選出 10–20 個真實查詢，標記資訊、比較、品牌與決策意圖。固定語言及地區，先照同一規則觀察至少一輪；未出現引用也要記錄。
檢查點 · 每個查詢都有來源、意圖、locale 與納入理由；基準包含成功和失敗結果，不只保存有品牌的畫面。
- 02
先排除技術與品質阻塞
檢查狀態碼、robots、canonical、內部連結、主要內容渲染與索引證據。逐項核對頁面主張是否有最新來源，刪除無法支持的數字與空泛段落。
檢查點 · 測試頁能從站內導覽找到，canonical 正確，主要主張都有來源；沒有用 schema 表達正文看不到的內容。
- 03
寫出單一修改假設
把問題、修改、預期訊號、品質門檻、觀察窗與停止條件寫在同一段。一次只處理可追蹤的一組內容缺口，保存部署前後 diff。
檢查點 · 同事能指出什麼結果會支持、削弱或無法判斷假設；沒有把「排名提升」當成唯一答案。
- 04
按排程重跑並判定引用
每週依相同查詢、locale、地區與紀錄欄位觀察。保存必要節錄與來源連結，另由一人判斷引用頁是否真的支持答案；不允許的自動化就改成手動抽樣。
檢查點 · 任選一列，另一位研究者能看懂何時、在哪個介面、用什麼查詢得到什麼回答，並重做支持性判定。
- 05
分層報告結果與限制
先報技術索引，再報出現、引用與引用正確性，最後才接站內行為。對照頁、同期變更與缺失資料放進限制；依預先規則決定延長、擴大、修改或停止。
檢查點 · 摘要沒有用品牌提及替代正確引用，也沒有把相關性寫成因果；零結果同樣留下可採取的診斷。
動手實作
建立一份可重跑的 AI 搜尋實驗包
沿用 Atlas Secure 的 12 個查詢範例，替自己的頁面完成基準、修改與觀察規則。
準備項目
- • 確認 robots、canonical、狀態碼、索引與頁面渲染沒有明顯阻塞。
- • 選一個讀者問題清楚、可以在測試期內小幅更新的頁面。
- • 閱讀使用中的搜尋產品條款，決定哪些觀察能自動化、哪些必須手動。
本課產出
一份查詢集、基準快照、技術檢查、內容與 schema diff、每週觀察表、結果摘要、限制與下一步決策。
起始模板: GEO 實驗紀錄表
CSVexperiment_id,atlas-geo-001
market,zh-TW
page_url,
control_url,
window_start,
window_end,
hypothesis,
quality_guardrail,
query_id,query_text,intent,locale,region,observed_at,surface,answer_excerpt,brand_mentioned,cited_url,citation_supports_answer,page_version,observer,notes
q01,什麼是零信任網路存取,informational,zh-TW,TW,,,,false,,,baseline-v1,,
change_id,page_location,before,after,source_id,approved_by,deployed_at
c01,canonical,,,,,
result_metric,baseline,test,control,interpretation
correct_citation_rate,,,,
incorrect_citation_rate,,,,
organic_impressions,,,,
qualified_action_rate,,,,預期結果
完成品要成為一包可交給別人重跑的證據，無須追求一張漂亮排名圖。讀者能分辨哪些是頁面修改、哪些是搜尋觀察、哪些是到站結果，以及目前能說到哪裡、不能說到哪裡。
留給下一課
保留查詢 fixture、頁面版本與判定規則。第 8 堂會把它們做成重複評估集，第 9 堂則用這份證據決定是否值得進入 30 天部署。
驗收條件
- 01查詢集至少 10 題，分層記錄意圖、語言、地區、來源與固定觀察方法。
- 02測試頁與對照頁都有基準、版本、部署時間及技術索引證據。
- 03每次觀察保存答案節錄、引用網址與支持性判定，未引用結果沒有被刪除。
- 04結果同時呈現引用正確性、搜尋曝光、站內行為、限制與停止／延長決策。
常見故障
故障診間
F1報告顯示可見度暴增，但原始資料只有幾張成功截圖。
- 先檢查
- 核對查詢母體、觀察次數、未出現結果、日期、地區、介面與選樣方式。
- 可能原因
- 先看到答案再挑案例，沒有固定分母與基準。
- 修復方式
- 回到預先定義的查詢集補跑基準；無法補齊時降級為探索性觀察。
- 下次怎麼避免
- 實驗開始前鎖定查詢、觀察節奏與必要欄位，成功與失敗都寫入同一張表。
F2頁面有新的結構化資料，搜尋測試卻警告內容不一致。
- 先檢查
- 逐欄比對 JSON-LD、可見正文、頁面類型與 Schema.org 定義。
- 可能原因
- 為了增加標記而填入頁面不存在的 FAQ、評價或組織資訊。
- 修復方式
- 移除不符合頁面內容的欄位，只保留正確、可見且符合類型的資料。
- 下次怎麼避免
- schema diff 跟內容 diff 一起審核，發布前跑語法與內容一致性檢查。
F3AI 答案引用品牌頁，卻把過期價格或產品能力寫錯。
- 先檢查
- 查看引用片段、頁面版本、來源日期、轉址與快取；確認錯誤是否源自本頁。
- 可能原因
- 舊頁仍可索引、主張沒有版本與刷新責任，或答案引用不支持該句。
- 修復方式
- 修正或下架過期內容，補轉址與 canonical，提交更新後持續記錄錯誤引用。
- 下次怎麼避免
- 為高風險 claim 設定到期日、負責人、來源版本與定期查詢 fixture。
展示版之後
正式上線前的邊界
- 01遵守 robots、API 與搜尋產品條款；取樣頻率不造成濫用或未授權自動化。
- 02保存查詢、locale、地區、介面、日期、答案證據、引用網址、頁面版本與判定者。
- 03技術 SEO、內容品質、schema、AI 答案觀察與站內轉換分層監測。
- 04產品、價格、安全、法規與客戶主張都指定來源、負責人與刷新期限。
- 05修改前後保留 diff、部署紀錄與回復版本；大量頁面變更先通過小範圍測試。
- 06報告保留未出現、錯誤引用與資料缺失，不用挑選成功案例補滿故事。
- 07每次搜尋介面或量測方法改版，重新建立基準，不直接接續舊趨勢線。
證據類型
資料來源與主張限制
資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。
- [1]Google Search Essentials搜尋收錄的技術、垃圾內容與基本政策邊界
Google Search Central · 官方文件 · 2026-08-20
- [2]Creating helpful, reliable, people-first content內容品質、自評與以讀者需求為中心的發布原則
Google Search Central · 官方文件 · 2026-08-20
- [3]Schema.org結構化資料詞彙與可見內容一致性
Schema.org · 官方文件 · 2026-08-20
- [4]What is Generative Engine Optimization (GEO)?假設、基準、測試設計、分析與限制的公開實驗框架
Seer Interactive · 公開案例 · 2026-08-20
- [5]AI Search ManualAI 搜尋檢索、引用、衡量、組織與實作方法
iPullRank · 已發表研究 · 2026-08-20
延伸的 Tenten 資源