SEO 菜鳥成長史 · #23

AEO 是 GEO 的下一道題：5 件套升級從 65 推到 88 (2.25h partial)

文 / Coolkid發布：2026-06-24 · 最後更新：2026-07-08閱讀約 8 分鐘

閱讀

中

摘要

30 天 GEO(生成式引擎優化)衝刺之後，我跑了一輪 AEO(答案引擎優化)專屬盤點。四個軸算下來整體達成度 65 分，缺 4 個好摘的果子，Speakable 0 篇、Workflow 的 HowTo 0/9、開頭快答對「其他人也問」偏長、對照表沒掛清單結構。5 件套升級都是改一處、全站套用，2.25 小時從 65 推到 88。

1. GEO 之後還有 AEO 這道題

#22 的 30 天 GEO 衝刺收尾後，我把實體、FAQ、快答、資訊增益、麵包屑打到 8 分，自以為 GEO 已經收了。

但 AEO 是更細的一層。它針對的是語音助理、精選摘要、「其他人也問」，還有 AI 摘要的直接回答，GEO 那套通用框架不會自動覆蓋到。

跑了一輪 AEO 專屬盤點，結果是 65 分。

真正的缺口只剩 4 個好摘的果子。

Speakable schema 0 篇、workflows 的 HowTo 0/9 篇、開頭快答對「其他人也問」偏長，還有對照表沒掛清單結構。

一輪升級就能推到 88。

這篇紀錄這 5 件套怎麼做、為什麼這樣設計。

還有一個關鍵心法，AEO 升級全部是改一處、全站套用，沒有寫新內容。內容寫作量是 0，純結構工程。

這一輪完全沒動到內容。

2. AEO #1:Speakable schema 全站注入 (30 分鐘)

Speakable 是給 Google 語音助理、Alexa 這類服務回讀用的標記。

Lab 當時既有的快答區塊 48 頁都建好了，結構乾淨，完全符合 Google 的規格。

但全站 0 個 Speakable 標記，語音助理完全抓不到該唸哪一段。

我在 lib/schemas.py 新增一個小工具函式跟一份選擇器清單，然後在網站 schema 跟文章 schema 各自加一個 speakable 屬性。

一個工具函式改兩處，當時全站 48 頁以上一次升級。

SPEAKABLE_SELECTORS = ["#tldr-oneliner", "#quick-answer p", "#lab-quick-answer p"]

def _speakable() -> dict:
    return {
        "@type": "SpeakableSpecification",
        "cssSelector": SPEAKABLE_SELECTORS,
    }

3. AEO #2:Workflow HowTo schema (45 分鐘)

pitfalls 有 16 篇掛了 HowTo，是自動偵測「步驟 N」開頭的清單抓的。workflows 則是 9 篇全部 0 個。

但每篇 workflow 的規格裡，本來就有 7 到 10 條流程步驟。那就是現成的步驟來源，只是建構器沒接上。

我在 build.py 加了一個 HowTo 產生器的呼叫，直接從規格裡的解鎖清單抽出步驟。

用括號當切點取名稱，整段當內容。9 篇 workflow 補上 HowTo 結構，讓 AI 跟爬蟲把它識別成教學文。

注意，Google 已經在 2023 年停止顯示 HowTo 的搜尋結果特殊版位，所以這裡的價值是機器理解，不是版面外觀。

2026-07-08 更新，HowTo schema 已經全站拆除。

後續查核一手文件之後盤點出來，HowTo 的特殊版位 2023 年 8 月就停顯，文件 9 月下架。

FAQ 版位也在 2026 年 5 月 7 日全面停顯，連政府跟健康類的站都沒了，文件 6 月下架。

Google 2025 年 12 月的 AI 功能文件更明講，沒有任何特殊 schema 能幫內容進 AI 功能。「機器理解」這個價值沒有一手來源支持，所以我把已經失效的 HowTo 標記拆掉了。

看得見的流程跟步驟條列全數保留，那才是 AI 引擎真正讀的東西。FAQ 因為可見內容跟 schema 同源、留著零成本，就維持現狀。

當初那 45 分鐘不算白做。它讓我真正搞懂 schema 是補充訊號，可見內容才是本體。

4. AEO #3:info_gain ItemList schema (1 小時)

資訊增益的三欄「適合 / 不適合 / 最常踩」對精選摘要很友善，因為結構天生就是清單。

但當時全站 21 頁以上的資訊增益區塊都沒掛清單結構，Google 不知道「這是清單，不是散段」。

我在 lib/schemas.py 新增一個清單產生器，一次回傳三個結構，每一欄一個。

每個清單都有排序方式、項目數，還有每一項的位置跟名稱。

兩個建構器各自接上，每篇自動掛 3 個清單，全站大約 90 個以上。

5. AEO #4:PAA TL;DR 30 字 partial + 8 篇 (1.5 小時)

「其他人也問」的答案通常偏短。

我觀察大概是 40 到 60 字，Google 沒有公布規格。

Lab 當時既有的快答實測 4 篇平均 156 到 205 字。對 AI 摘要整段抓取已經最佳化，但塞進這個版位會被腰斬在不該斷的地方。

build.py 新增一個一句話直答的區塊，渲染成一段 30 到 55 字的單句答案，放在快答之前，當作最短答那一層。

規格加一個選填欄位，沒填就跳過，不破壞既有的規格。

8 篇高頻文章補上 30 到 55 字的精準直答。

claude-code-what-is、what-is-ai-agent、claude-code-vs-cursor、ai-agent-vs-chatgpt、what-is-ai-workflow、no-code-can-i-build、non-engineer-can-i-learn-ai、which-ai-tool-to-start。每篇規格多一行，渲染後這 8 篇的直接抓取率就提升了。

順手把這個新區塊加進語音選擇器清單，語音助理也吃這一層。

語音、「其他人也問」、AI 摘要，三方都吃這一層。

6. AEO #5:Table scope='col' (5 分鐘)

Lab 當時有 8 篇以上的對照表，適合被精選摘要抓走，但既有的表頭沒有加欄位標記。

欄位標記是規格定義的表頭標示，也是無障礙的正確做法。格式正確的表格對機器擷取比較友善。至於能不能進精選摘要，沒有官方的倍數保證。

改 build.py 的表格渲染，自動幫每個表頭加上欄位標記。

一處改動，全站對照表自動升級，順便讓螢幕閱讀器讀得出欄位用途。

5 分鐘做完的一項。

7. 預期效應 65 → 88

指標	起始	AEO sprint 後
Speakable schema 覆蓋 page	0	48+
Workflow HowTo schema	0/9	9/9
ItemList schema 全站	0	~90+ 個(30 文章 × 3)
PAA tldr 30 字	0	8 篇
Table scope (a11y)	0%	100%
AEO 整體 audit	65	88(audit 預測)

5 件套全部是改一處、全站套用，總共 2.25 小時工時。

語音助理抓一句話直答、「其他人也問」抓一句話直答、AI 摘要抓快答，三層覆蓋同一份內容。

三層吃的是同一份文字。

▸ 常見問題

AEO 跟 GEO 差在哪?

GEO 是對生成式 AI(ChatGPT/Perplexity)引用的通用優化,範圍廣;AEO 是對 Answer Engine(語音助理/Featured Snippet/PAA/AI Overviews)直接回答的優化,更細更 targeted。GEO 解 entity + 結構 + freshness,AEO 解 selector + 短答 + schema-specific。GEO 是地基 AEO 是裝修。

Speakable schema 真的有用嗎?

對 Google Assistant 語音搜尋有用 — 它優先選有 SpeakableSpecification 的內容回讀。但目前 Lab 流量級別語音搜尋 referral 不會立即顯著。長期看是「未來語音搜尋成熟時站台已準備好」的 forward-looking 動作,成本低(30 分鐘)所以做。

PAA tldr 30 字會跟 quick_answer 200 字衝突嗎?

不會。tldr 30 字放在 quick_answer 之前,當「最短答」層;quick_answer 是「完整 Answer-First 段」。我準備長短兩層,期望分別命中 PAA(短)跟 AI Overviews(整段) — 但 Google 實際是不是這樣分流抓取,我無法確認,這是我的假設。

為什麼不順手抽 faq_block partial?

build_pitfall_article 跟 build_workflow_article 已內建 spec.faq 機制(發現 #20 沒留意),抽 partial 重複實作。SEO Journey article 用 inline FAQ HTML(本篇也是),要等專屬 partial 已存 spec 機制的好處 vs 又一個 partial 維護成本,目前 inline 夠用。

AEO 是 GEO 的下一道題。

5 件套 2.25 小時，全部改一處、全站套用，65 分推到 88。內容寫作量是 0，純結構工程。這證明 AEO 升級的投報率極高，個人站台 GEO 跑完都該接著做。

下篇 #24 講同一天的另一個重構，首頁的摘要區改成可摺疊。視覺收乾淨跟內容完整怎麼取捨，又不踩到隱藏文字的紅線。

名詞解釋

AEO（答案引擎優化）: 把內容寫成「搜尋引擎跟 AI 能直接抽走當答案」的格式：先給答案、再給支撐、附上來源。跟 GEO 高度重疊。
GEO（生成式引擎優化）: 讓 ChatGPT、Perplexity 這類 AI 在回答問題時引用你網站內容的優化方法，是 SEO 在 AI 時代的延伸戰場。
結構化資料（Schema / JSON-LD）: 用機器看得懂的格式跟搜尋引擎說明「這頁是文章、作者是誰、何時更新」，有機會換到更豐富的搜尋結果外觀。
AI Overviews: Google 搜尋結果頂部由 AI 生成的摘要區塊，會引用來源網站。被它引用是 GEO 的主要戰場之一。
搜尋結果頁（SERP）: 在 Google 搜一個詞之後出現的那一整頁結果，包含一般結果、精選摘要、AI 摘要等版位。
無障礙（accessibility / a11y）: 讓視力不佳、不便操作的人也能順利使用網站的設計標準。WCAG AA 是國際標準的中間等級，要求文字與背景對比度 ≥ 4.5:1。

全站名詞表 · 161 條 →

看完這篇之前先確認:

適合你

GEO sprint 已收尾、想做下一階段 AEO 細部優化
在意 Google Assistant 語音搜尋 / Featured Snippet / PAA 命中率
想用 partial / helper 一處改全站套用,不想手改數十篇

不適合

還沒 GEO 通用框架(entity + schema + freshness)— 先做 GEO 再做 AEO
CMS 站架構難改 partial(WordPress 等)— 改動成本高
完全不在乎 AI / 語音引用,只看 organic SERP 排名

如果內容對你有用就太好了
隨喜斗內

NEXT CHAPTER ▸ #22 Claude Code / AI Agent keyword surface 30 天回收記:AEO sprint 的前傳