是 Ray 不是 Array

整理這些技術筆記真的很花時間,如果你願意 關閉 Adblock 支持我,我會把這份感謝轉換成更多「踩坑轉避坑」的內容給你!ヽ(・∀・)ノ

Advertisement
AI

SEO 已經不夠了嗎?認識 AEO 答案引擎優化,讓 AI 搜尋找到你

SEO 已經不夠了嗎?認識 AEO 答案引擎優化,讓 AI 搜尋找到你
SEO 已經不夠了嗎?認識 AEO 答案引擎優化,讓 AI 搜尋找到你

前言

這一篇稍微來聊一下 AEO(Answer Engine Optimization,答案引擎優化)這個概念,隨著越來越多人開始用 ChatGPT、Perplexity 取代 Google 搜尋,傳統 SEO 的玩法可能也要跟著調整了,所以這篇就來聊聊 AEO 是什麼、跟 SEO 差在哪裡、以及實際上該怎麼做。

稍微回顧一下 SEO

在聊 AEO 之前,先稍微回顧一下 SEO 是什麼東西。

SEO 全名是 Search Engine Optimization,中文叫做搜尋引擎優化,簡單來講就是透過各種方式讓你的網站在 Google、Bing 這些搜尋引擎上面的排名更高,這樣使用者在搜尋的時候就更容易找到你。

通常來講常見的 SEO 做法包含:

  • 關鍵字優化: 讓你的內容包含使用者會搜尋的關鍵字
  • meta 標籤: 設定好 title、description 等,讓搜尋引擎知道你的頁面在講什麼
  • 反向連結: 讓其他網站連結到你的內容,提升網站的權威性
  • 網站速度與體驗: 頁面載入速度、行動裝置友善度等等,這些也會影響排名
  • Sitemap 與 robots.txt: 告訴搜尋引擎你的網站結構跟哪些頁面可以被收錄

以我自己來講,之前也有寫過幾篇跟 SEO 相關的文章,像是 攸關 SEO 的三大核心指標 LCP、FID、CLS快速掌握 robots.txt 用途,有興趣的可以去看看。

所以基本上 SEO 的核心目標就是讓你的網站在搜尋結果頁面排名越高越好,排名越高使用者越容易點進來,流量自然就越多。這個邏輯在過去十幾年來都是成立的,可是現在開始出現了一些變化,也就是接下來要聊的 AEO。

那什麼是 AEO?

你可以先試著想像一下這個場景:

以前你想知道「什麼是 CSR」,你會打開 Google,輸入關鍵字,然後從搜尋結果中挑一篇看起來不錯的文章點進去。可是現在呢?很多人會直接打開 ChatGPT or Perplexity,直接問它「什麼是 CSR」,然後 AI 就把答案整理好丟給你了,根本不需要點進任何網站。

這時候就出現一個問題:如果使用者不再點進你的網站,那你的 SEO 做得再好又有什麼用?

AEO 全名是 Answer Engine Optimization,中文翻成答案引擎優化。所謂的答案引擎就是那些可以直接回答你問題的 AI 工具,像是 ChatGPT、Perplexity、Google AI Overviews、Bing Copilot 等等。

所以 AEO 做的事情就是…

『讓你的內容成為 AI 在回答問題時引用的來源。』

如果用比較生活面來舉例的話,傳統 SEO 就像是讓你的書出現在書店最顯眼的書架上,大家逛書店的時候可能會看到你的書,可是 AEO 則是讓你的書變成老師上課時直接引用的教材,學生不管有沒有去書店都一定會看到。

Note
你在查資料的時候可能還會看到 GEO(Generative Engine Optimization)、LLMO、AIO 之類的詞,這些跟 AEO 基本上都在講同一件事情,目前業界也沒有非常嚴格的區分,所以這篇就統一用 AEO 來稱呼。

為什麼要在意 AEO?

你可能會想說:我 SEO 做得好好的,幹嘛要管 AEO?

那我們先來聊一個現象,就是所謂的零點擊搜尋(Zero-Click Search)。什麼意思呢?就是使用者在搜尋結果頁面上就已經得到答案了,根本不需要點進任何網站。

這個比例有多誇張?目前大約有將近七成的 Google 搜尋屬於零點擊搜尋,而且這個比例還在持續上升中。

而且這還只是傳統 Google 搜尋的狀況而已,如果加上 AI 搜尋的部分就更驚人了,像是 ChatGPT 目前每週活躍使用者已經好幾億人,Perplexity 的流量在過去一年內也暴增了好幾倍。

所以使用者取得資訊的方式正在改變,以前寫了一篇文章做好 SEO,Google 把你排在前幾名,使用者就會點進來看。可是現在使用者直接問 AI 一個問題,AI 把答案整理好丟給他,你的文章連被看到的機會都沒有 QQ

不過好消息是,如果你的內容有被 AI 引用的話,效益其實滿高的,像是被 AI Overviews 引用的頁面,有機搜尋的點擊量通常會明顯增加,而且從 AI 推薦過來的訪客轉換率也比一般有機搜尋高出不少。

所以 AEO 不只是一個趨勢而已,它是直接影響到你的流量跟轉換的東西。

SEO 跟 AEO 的差異

這邊整理一張表讓你可以更快理解兩者的差異:

面向 傳統 SEO AEO
目標 在搜尋結果頁排名越高越好 被 AI 引用為回答的來源
使用者行為 瀏覽結果、點擊連結 直接閱讀 AI 的回答
優化單位 頁面層級(標題、meta、反向連結) 事實層級(可被擷取的觀點跟資料)
內容寫法 長篇、關鍵字密度高 結構化、每段先給答案
技術重點 meta 標籤、sitemap、頁面速度 Schema Markup、結構化資料
衡量指標 排名、流量、點擊率 AI 引用次數、品牌提及率
成功指標 Google 排名第一 成為 AI 信任並引用的來源

這邊有一個滿重要的觀察:AI Overviews 引用的來源中,只有不到四成是來自 Google 排名前十的頁面,也就是說你在 Google 排名第一不代表 AI 就一定會引用你,因為 AI 在乎的東西跟傳統搜尋引擎不完全一樣。

AI 搜尋引擎是怎麼決定引用誰的?

在了解怎麼做 AEO 之前,我們需要先理解 AI 是怎麼決定要引用誰的內容。

基本上大多數的 AI 搜尋引擎都是基於一個叫做 RAG(Retrieval-Augmented Generation,檢索增強生成) 的架構在運作的,如果你不熟悉 RAG 的話可以先去看我之前寫的 你聽過 LLM、RAG、Prompt 嗎?一文帶你看懂生成式 AI 常見技術詞彙,裡面有比較完整的介紹。

簡單來講 RAG 的流程大概是這樣的:

  1. 使用者問了一個問題
  2. AI 系統先去搜尋有哪些文件跟這個問題相關
  3. 找到相關文件後再透過權威性、內容品質等條件做篩選,通常只留下前幾筆
  4. 語言模型根據這些篩選過的文件內容來產生回答,並標註引用來源

那不同平台在做法上也有些差異,像 ChatGPT 預設是用模型本身的知識來回答,開啟搜尋功能時才會即時抓取網頁;Perplexity 則是每次回答都會即時搜尋網頁,而且預設就會顯示引用來源;Google AI Overviews 則是連接 Google 自己的搜尋索引跟知識圖譜。

那 AI 在篩選來源的時候主要會看什麼呢?通常來講就是以下幾個面向:

  • 可信度: 你的網站是不是有公信力的來源
  • 內容品質: 結構是不是清楚、有沒有資料佐證、有沒有直接回答問題
  • 新鮮度: 內容有沒有定期更新
  • 結構化程度: 有沒有使用清楚的標題、列表、表格等等讓 AI 容易擷取

了解了原理之後,接下來就來看看實際上該怎麼做。

該怎麼做 AEO?

先給答案,再補脈絡

這是 AEO 最核心的寫作原則。

AI 在擷取你的內容時,通常只會看每個段落的前一兩句話,如果你的開頭是一大段鋪陳 or 背景介紹,AI 可能直接就跳過了去找下一個更直接回答問題的來源。

所以每個段落的開頭最好就直接回答該段的核心問題,後面再補充解釋和脈絡。

舉例來講,假使今天要介紹 Schema Markup 的話:

比較不好的寫法:

在我們討論 Schema Markup 之前,先來聊聊結構化資料的歷史。早在 2011 年 Google、Bing 和 Yahoo 就聯合推出了 schema.org…(後面才開始講 Schema Markup 是什麼)

比較好的寫法:

Schema Markup 是一種加在網頁 HTML 裡的結構化資料標記,用來幫助搜尋引擎和 AI 理解你的內容。常見的格式是 JSON-LD,你可以用它來標記文章的作者、發布日期、FAQ 等資訊。

有發現嗎?後者一開頭就直接告訴你 Schema Markup 是什麼,AI 可以直接擷取這段來回答使用者的問題。

讓每個段落都能獨立存在

AI 解析內容的時候是以段落為單位的,不是以整篇文章為單位,所以每個段落要能獨立回答一個問題,就算被單獨擷取出來也要看得懂。

通常來講建議的做法是每個 H2/H3 標題都要有明確的語意,最好就是一個問題 or 一個概念,然後每個段落控制在一定的長度內,善用列表跟表格來組織資訊,這樣 AI 在解析的時候會更容易抓到重點。

加入結構化資料(Schema Markup)

Schema Markup 是讓 AI 更容易理解你內容的重要手段,基本上有完整 Schema Markup 的頁面被 AI 引用的機率會比沒有的頁面高出不少。

對於部落格文章來說,比較推薦加入以下幾種 Schema:

  • Article / BlogPosting: 標記你的文章標題、作者、發布日期等資訊
  • FAQPage: 如果你的文章有 Q&A 格式的段落,這個 Schema 可以讓 AI 直接擷取問答對。這邊要特別提一下,雖然 Google 在 2023 年限制了 FAQ 的複合式搜尋結果顯示,可是 FAQPage Schema 對於 AI 搜尋引擎來說仍然是非常重要的訊號
  • BreadcrumbList: 標記你的網站層級結構
  • Person + Organization: 標記作者和所屬組織的資訊

基本上 Schema Markup 是用 JSON-LD 格式寫的,放在頁面的 <head> 裡面,如果你是用 Hexo or WordPress 的話通常可以透過外掛來自動產生,不需要自己手動寫。

適當地用資料佐證你的內容

AI 比起主觀的描述,更傾向引用有資料佐證的內容,所以建議在文章中適當地穿插一些具體的資料 or 引用,而且最好附上原始來源的連結。

比起寫「AI 搜尋正在快速成長,越來越多人在用」這種模糊的描述,如果你能寫出「根據統計 Perplexity 的流量在過去一年內成長了超過兩倍」這種有具體來源的內容,AI 在生成回答時更容易把你的話直接擷取出來作為佐證。

建立主題權威性

AI 在選擇引用來源的時候,會偏好在某個主題上有深度覆蓋的網站。什麼意思呢?假使你只寫了一篇關於 SEO 的文章,跟另一個網站寫了 SEO、AEO、Core Web Vitals、Schema Markup、robots.txt 等一整個系列,AI 會更傾向信任後者,因為後者在這個主題上展現了更完整的知識覆蓋。

所以建議針對核心主題建立文章群組(Topic Cluster),用一篇主文搭配多篇延伸文章彼此互相連結。以我自己來講,之前就有寫過 攸關 SEO 的三大核心指標 LCP、FID、CLS快速掌握 robots.txt 用途,還有試著學 Hexo 系列裡面也有好幾篇 SEO 相關的章節,這些文章彼此之間都可以互相連結,讓 AI 更容易判斷你在這個主題上有一定的深度。

定期更新你的內容

AI 搜尋引擎在處理時效性查詢時會明顯偏好比較新的內容,通常來講 AI 引用的內容都會比傳統搜尋結果還要新鮮不少。所以建議至少每季回頭檢查一下你的重要文章,更新日期跟補充最新的資料。

llms.txt:給 AI 看的網站導覽

前面提到的做法大多是「內容怎麼寫」的問題,但其實還有一個比較偏技術面的做法,就是在你的網站上放一個 llms.txt 檔案。

llms.txt 是什麼?

如果你有看過我之前寫的 快速掌握 robots.txt 用途,你應該知道 robots.txt 是用來告訴搜尋引擎爬蟲哪些頁面可以爬、哪些不能爬的,而 llms.txt 做的事情剛好反過來。

robots.txt 是在跟爬蟲說「你不准進來」,可是 llms.txt 是在跟 AI 說「嘿,這邊有好東西,快來看」。

llms.txt 是由 Answer.AI 的共同創辦人 Jeremy Howard 在 2024 年提出的一個標準提案,它的核心概念就是…

『主動告訴 AI 你的網站上有什麼重要的內容。』

為什麼需要這個東西呢?因為 AI 在讀取你的網頁時會遇到一些問題,像是網頁上通常有一堆導航列、廣告、JavaScript 等等雜訊,AI 很難從中擷取出真正有價值的內容。而且 AI 的 Context Window 是有限的,不可能把你整個網站的內容都塞進去,更不用說 AI 可能從某一篇文章進入你的網站,完全不知道你還有哪些其他有價值的內容。

所以 llms.txt 做的事情就是提供一份用 Markdown 格式寫的網站導覽,主動告訴 AI 你的網站架構跟重點內容在哪裡。

這邊也整理一下 robots.txtllms.txt 的差異:

面向 robots.txt llms.txt
目的 告訴爬蟲哪些頁面不能爬 告訴 AI 哪些內容最重要
思維 排除導向(Disallow) 發現導向(這裡有好東西)
格式 純文字指令 Markdown
對象 傳統搜尋引擎爬蟲 LLM 語言模型

llms.txt 的格式長什麼樣?

llms.txt 的格式其實滿簡單的,就是一個 Markdown 檔案:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 網站名稱

> 網站的簡短描述(用 blockquote 語法)

這邊可以放一些額外的說明文字。

## Docs

- [文章標題](https://example.com/page.md): 簡短描述這個頁面的內容
- [另一篇文章](https://example.com/other.md): 這個頁面在講什麼

## Blog

- [部落格文章](https://example.com/blog/post.md): 文章的簡短描述

## Optional

- [補充資料](https://example.com/extra.md): 如果 AI 需要更多資訊才會讀的內容

幾個重點:

  • H1 標題(必要): 你的網站或專案名稱
  • Blockquote 描述(建議): 用一兩句話描述你的網站是做什麼的
  • H2 分類區塊(選填): 把你的內容依照主題分類,每個分類下放連結跟簡短描述
  • Optional 區塊(選填): 放在這裡的連結代表不是必要的,可是如果 AI 需要更多資訊可以參考

另外連結建議指向 .md 格式的檔案,因為 Markdown 對 AI 來說比 HTML 更容易解析。

llms.txt 跟 llms-full.txt 的差異

除了 llms.txt 之外,你可能還會看到 llms-full.txt 這個檔案,簡單來講 llms.txt 就像是一本書的目錄,而 llms-full.txt 則是整本書的內容。前者讓 AI 快速了解你的網站有什麼東西,後者則是把所有文件的完整內容都塞進去,讓 AI 可以直接讀完你所有的內容。

基本上建議兩個都做,llms.txt 當作索引讓 AI 快速定位,llms-full.txt 則是提供完整內容讓 AI 在需要深入了解時使用。

以我的部落格為例

以我的部落格來講,llms.txt 大概會長這樣:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 是 Ray 不是 Array

> 由軟體工程師 Ray 撰寫的技術部落格,涵蓋前端開發、AI 工具使用、SEO 優化等技術筆記與實戰心得。

這是一個以中文為主的技術部落格,主要涵蓋 JavaScript、CSS、Vue.js、Nuxt.js、AI 開發工具等主題。

## AI

- [想用 Claude Code 開發?這篇帶你從入門到進階](https://israynotarray.com/ai/20260128/374686091/): Claude Code 的完整使用教學,包含安裝、設定、Hook、MCP 等功能介紹
- [你聽過 LLM、RAG、Prompt 嗎?](https://israynotarray.com/ai/20250425/3215958971/): NLP、LLM、RAG、Prompt、Fine-tuning、MCP、AI Agent 等名詞解釋
- [淺談 AI Vibe Coding 當今主流的 BDD 與 SDD](https://israynotarray.com/ai/20251202/797714546/): BDD 與 SDD 在 AI 開發中的應用實戰

## SEO

- [攸關 SEO 的三大核心指標 LCP、FID、CLS](https://israynotarray.com/other/20210530/1324443947/): Core Web Vitals 的介紹與測試方式
- [快速掌握 robots.txt 用途](https://israynotarray.com/other/20210627/3588736352/): robots.txt 的寫法與 SEO 的關係

## JavaScript

- ...(依此類推)

每個連結都有簡短的描述告訴 AI 這個頁面在講什麼,這樣 AI 就可以更快找到跟使用者問題相關的內容。

在 Hexo 上怎麼實作?

如果你跟我一樣是用 Hexo 的話,目前沒有專門的 Hexo 外掛可以自動產生 llms.txt,可是實作的方式其實滿簡單的。

最直接的做法就是在 source/ 目錄下建立一個 llms.txt 檔案,Hexo 在建置的時候會直接把這個檔案複製到 public/ 目錄下,這樣就可以透過 https://你的網域/llms.txt 來存取了。

不過要注意 Hexo 預設會把 Markdown 檔案渲染成 HTML,所以你需要在 _config.ymlskip_render 設定中把它加進去:

1
2
3
skip_render:
- llms.txt
- llms-full.txt

這樣 Hexo 就不會去處理這個檔案,會直接原封不動的複製到輸出目錄。

如果你不想手動維護的話,也可以考慮寫一個簡單的 Node.js 腳本在 hexo generate 之後自動掃描文章來產生 llms.txt,概念上就像 hexo-generator-sitemap 在做的事情一樣。

AI 真的會讀 llms.txt 嗎?

這邊要老實說一下,目前 llms.txt 還是一個滿早期的提案,並不是一個正式的標準。

如果你想知道 AI 有沒有來讀你的 llms.txt,可以透過伺服器的 log 或一些分析工具來觀察,像是有些站長就發現 OpenAI 的爬蟲(OAI-SearchBot、ChatGPT-User)確實有在抓 llms.txt,可是有抓不代表 AI 在回答問題的時候真的會拿來用。

而 Google 的態度則比較保留,Google 的 John Mueller 甚至把 llms.txt 跟早期被淘汰的 meta keywords 標籤做比較,認為目前沒有 AI 系統真的在使用它。

不過有趣的是,目前已經有好幾百個網站實作了 llms.txt,包含 Anthropic、Stripe、Cloudflare、Vercel、Supabase 等等知名公司,所以就算效果未知,至少業界是有在認真看待這個東西。

以我自己的看法來講,建立一個 llms.txt 花不了多少時間,成本幾乎是零,就算現在 AI 還沒有正式支援,未來也有很高的機率會支援,不如先做起來放著讓你的網站提前做好準備。

AEO 常見名詞

如果你是第一次接觸 AEO 這個領域,可能會被一堆名詞搞得暈頭轉向,這邊就整理幾個比較常見的。

E-E-A-T

全名是 Experience, Expertise, Authoritativeness, Trustworthiness(經驗、專業性、權威性、可信度),這是 Google 用來評估內容品質的框架,AI 搜尋引擎在選擇引用來源時也會參考類似的訊號。

簡單來講 AI 會去看你這個人 or 網站在這個領域是不是有足夠的經驗和專業度,別人是不是也認可你的內容,以及你的內容是不是值得信任。所以如果你的網站有明確的作者資訊、相關經歷、以及其他權威網站的反向連結,在 E-E-A-T 的評分上就會比較高。

Schema Markup

前面已經有聊過了,簡單來講就是一種加在網頁 HTML 中的結構化資料,通常用 JSON-LD 格式,用機器可讀的方式告訴搜尋引擎跟 AI 你的內容是什麼、作者是誰、發布日期是什麼時候等等。

就是 Google 搜尋結果頁面上方那個大框框,會直接顯示一段回答。有精選摘要的頁面通常會比其他排名的頁面獲得更多的流量,而 AEO 的策略同時也能提升你拿到精選摘要的機率,所以做好 AEO 對傳統 SEO 也是有幫助的。

AI Overviews

這是 Google 在搜尋結果最上方顯示的 AI 生成摘要,目前出現的比例一直在增加。AI Overviews 會從多個來源整合資訊後呈現給使用者,而且當它出現的時候傳統搜尋結果的點擊率會大幅下降。

Zero-Click Search(零點擊搜尋)

使用者在搜尋結果頁面 or AI 回答中就得到了想要的答案,不需要點進任何網站。目前大約有將近七成的 Google 搜尋屬於零點擊搜尋。

Topical Authority(主題權威性)

指一個網站在某個特定主題上展現出的深度和廣度,透過建立完整的文章群組、持續產出相關內容來累積。AI 會更傾向引用在特定領域有深度覆蓋的網站。

有工具可以追蹤 AEO 成效嗎?

既然做了 AEO 當然也要追蹤成效,目前市面上已經有一些工具可以幫助你:

  • Semrush AI Toolkit: 可以追蹤你在 AI 搜尋中的能見度跟競品比較
  • Ahrefs Brand Radar: 追蹤品牌在 AI 平台上的被提及情況
  • HubSpot AEO Grader: 免費工具,可以評估你的內容對 AEO 的準備程度
  • Google Search Console: 雖然不是專門針對 AEO 的,可是可以觀察 AI Overviews 帶來的曝光資料

當然最直接的方式就是自己去 ChatGPT、Perplexity、Gemini 等平台輸入你目標的關鍵字,直接看 AI 的回答有沒有引用到你的內容,這個方式雖然土法煉鋼可是也是最直覺的。

AEO 跟 SEO 是互補的

最後要提一件事:AEO 不是要取代 SEO,而是在 SEO 的基礎上做延伸。

它們的核心策略其實高度重疊,清楚的內容結構、回答使用者問題、結構化資料、良好的頁面體驗,做好一邊通常也會帶動另一邊的表現。而且 AI 搜尋引擎在選擇引用來源的時候,本身就很仰賴傳統搜尋引擎重視的那些訊號,像是域名權威性、內容品質、反向連結等等,所以你的 SEO 底子越好 AEO 的效果通常也會越好。

現階段的建議是 SEO 持續做,同時開始把 AEO 的思維融入到你的內容策略裡面,畢竟根據 Gartner 的預測傳統搜尋引擎的搜尋量在未來幾年會大幅下降,而使用生成式 AI 搜尋的人口也會持續增加。

早一點開始布局,你就越有可能在 AI 搜尋的世界裡占有一席之地哩~

你的支持會直接轉換成更多技術筆記

如果我的筆記讓你少踩一個坑、節省 Debug 的時間,
也許你可以請我喝杯咖啡,讓我繼續當個不是 Array 的 Ray ☕

buymeacoffee | line | portaly
Terminal

整理這些技術筆記真的很花時間,如果你願意 關閉 Adblock 支持我,我會把這份感謝轉換成更多「踩坑轉避坑」的內容給你!ヽ(・∀・)ノ

Advertisement

分享這篇文章

留言

© 2026 Ray. All rights reserved.

Powered by Ray Theme