從技術底層看 GEO：為什麼語意標籤、HTML 結構、正確的網頁設計，比那些 AI 行銷話術更值得投入！

一、為什麼這篇文章從「網頁設計公司」的角度寫

市面上談 GEO 的文章，多半出自 SEO 代理商或行銷顧問。他們的角度自然偏向「怎麼讓內容被 AI 引用」，技術層面常常是輕描淡寫帶過。但很多 GEO 工程方法的問題，其實要從技術底層才能看清楚——例如 llms.txt 的設計缺陷、schema 的真實作用範圍、JavaScript 渲染與爬蟲的相容性，這些都不是寫幾篇 Blog 就能搞懂的。

CADCH 從 2006 年起就專注在正確的網頁設計：HTML5 語意標籤、無障礙設計（WCAG）、結構化資料、效能優化、跨裝置相容。這些東西在「AI 搜尋時代」之前就是最佳實踐，到了現在也沒有改變。改變的只是行銷話術——同一件事換個包裝重講，價格往往翻倍。

我們希望這篇文章能讓讀者建立一個技術判斷的底氣：當你下次看到「實作 X 提升 AI 引用率 40%」的廣告時，你能自己判斷這個說法在技術原理上合不合理，而不是只能憑感覺被牽著走。

二、AI Overviews 的技術運作：從爬蟲到生成的完整鏈路

要判斷哪些工程方法有用，得先知道 AI Overviews 在技術上怎麼運作。Google 官方文件「AI Features and Your Website」與多次 Search Central Live 公開說明，已經把鏈路講得很清楚：

1. 爬取階段：使用標準 Googlebot，跟一般 Search 共用爬蟲與索引。Google-Extended 是另一支獨立爬蟲，僅控制 Gemini 模型的訓練資料與 grounding，與 AI Overviews 的內容來源無關。
2. 索引階段：跟 Search 用同一個索引。沒有「AI 專屬索引」這種東西。
3. 查詢處理：採用「query fan-out」機制，把使用者的查詢拆成多個子查詢平行檢索。
4. 候選來源選取：從現有 Search ranking 系統選出候選頁面，再做進一步的段落級評估。
5. 生成階段：由 Gemini 模型整合多來源內容生成回答，並附上引用連結。

這個鏈路裡有幾個關鍵事實，行銷話術通常會跳過：第一，標準 Googlebot 是入口，所以任何阻擋一般爬蟲的設定（過度依賴 client-side rendering 而沒做 SSR、robots.txt 誤封 Googlebot、無限滾動沒做 progressive enhancement）都會直接讓你出局。第二，排名系統是同一套，所以 Google 才會反覆強調「If you've been doing good SEO, you're already optimized for AI features」。第三，沒有 AI 專屬的訊號通道——你沒辦法繞過排名系統直接「告訴 AI」你的內容很好。

理解這個鏈路之後，回頭看那些「AI 專屬優化」的主張，技術上就站不住腳了。

三、語意標籤的真正角色：HTML5 sectioning element 的價值

這是 CADCH 的本業領域，也是市場上最被低估的部分。HTML5 引入的 <article>、<section>、<nav>、<header>、<footer>、<aside>、<main> 這些 sectioning element，用意是讓機器能正確理解頁面的結構與內容階層。

這跟 AI Overviews 有什麼關係？關係很大但很少有人講清楚。AI Overviews 的 query fan-out 機制會做段落級的內容抽取——它需要從你的頁面裡找出「能獨立回答某個子查詢的段落」。如果你的 HTML 結構是這樣：

<div class="content">
 <div class="block">
 <div class="text">...</div>
 </div>
</div>

機器只能看到一團 div，得靠視覺布局或 NLP 推測哪裡是段落邊界、哪裡是主題切換。但如果你的結構是：

<article>
 <section>
 <h2>主題</h2>
 <p>答案段落</p>
 </section>
</article>

機器一眼就知道這是一個獨立的內容區塊，標題明確、邊界清楚。這不是 AI 加分，這是機器可讀性的基本要求。

這裡要誠實一件事：我們無法用對照實驗證明「語意標籤直接提升 AI 引用率 N%」。Google 不會公布這種權重。但從技術原理推論，結構清楚的 HTML 對任何形式的機器抽取都是有利的——這不需要實驗證明，這是設計這些標籤的初衷。

另一個常被忽略的點：標題階層（h1–h6）的合理使用。如果你的頁面 h1、h2、h3 順序錯亂，或一個頁面塞十個 h1，機器難以建立內容的階層關係。query fan-out 抽取段落時，標題是重要的主題訊號——標題下的段落會被理解為該主題的回答。這件事對所有搜尋引擎都成立，AI Overviews 不過是把這個原則用得更徹底。

四、Schema markup：從機器可讀性的角度重新評估

Schema markup（schema.org 結構化資料）是 GEO 行業最常被誇大的項目之一。常見的廣告話術是「實作 FAQPage schema 提升 AI Overviews 引用率 67%」這類具體數字。

從技術角度，我們需要把 schema 的真實作用拆開來看：

關鍵在於分清楚兩件事：schema 的官方用途是 rich results 合格資格與機器消歧義，不是 AI Overviews 的引用排名因子。Google 官方文件白紙黑字寫著「There's also no special schema.org structured data that you need to add」——AI Overviews 不需要特殊 schema。

但這不是說 schema 沒用。從機器可讀性的角度，正規的 Article、Organization、Person、Breadcrumb schema 仍能幫助搜尋引擎正確理解頁面內容。我們在 CADCH 給客戶的建議一向是：用恰當的 schema 標記真實存在的內容類型，不要為了 schema 而 schema。一個介紹公司的頁面塞 FAQPage schema，是濫用；一個產品頁缺 Product schema，是失職。

五、llms.txt 的技術設計缺陷分析

llms.txt 是 GEO 行業近一年最被推崇的「新檔案」，宣稱是「AI 時代的 robots.txt」。從技術設計的角度，這個提案有幾個明顯的問題值得拿出來講：

第一個問題：信任模型錯誤。llms.txt 的設計邏輯是「網站擁有者宣稱哪些內容是精華、AI 應該優先參考」。但搜尋引擎從 1990 年代以來學到的最深的一課就是——站長的自我宣稱不能直接信任。當年 keywords meta tag 被廢棄，就是因為站長會塞滿不相關的關鍵字。Google 的 John Mueller 把 llms.txt 比喻成 keywords meta tag，技術上這個類比是準確的——它們犯了同一個錯誤。

第二個問題：與既有機制重疊。網站要告訴搜尋引擎「哪些內容重要」，已經有 sitemap.xml、canonical link、結構化資料、語意標籤等多重機制。llms.txt 提供的訊息，幾乎都能用既有機制表達。新增一個重複的檔案格式，沒有解決任何技術問題。

第三個問題：採用率的數據慘烈。OtterlyAI 的 90 天實驗顯示，62,100 次 AI 機器人請求中只有 84 次命中 llms.txt——命中率 0.1%。SE Ranking 對 39,000 個網域的分析結論是「llms.txt 似乎並未直接影響 AI 引用頻率」。一家管理 20,000 個網域的代管商報告指出，唯一持續抓取 llms.txt 的，只有 BuiltWith 這類技術盤點工具。

第四個問題：Google 明確不採用。Gary Illyes 在 2025 年 7 月的 Search Central Live 直接說「Google doesn't support LLMs.txt and isn't planning to」。Mueller 在多個公開場合也表達同樣立場。

從技術判斷的角度，實作 llms.txt 目前對 SEO 與生成式引擎優化等於零回報。如果未來有某個主流 AI 平台正式採用，那時再實作不遲——這是一個 5 分鐘的工作，沒必要現在搶跑。

六、JavaScript 渲染、CSR/SSR 與 AI 爬蟲的相容性

這是技術層面真正會影響 AI Overviews 表現的部分，但 GEO 行銷文宣很少提。原因很簡單——這部分需要實際的工程能力，不是寫幾段內容就能解決。

事實是這樣：AI Overviews 用標準 Googlebot 抓內容。Googlebot 確實有 JavaScript 渲染能力（基於 Chromium），但有以下限制：

• 渲染有資源預算，複雜的 SPA 可能渲染不完整
• 動態載入的內容（infinite scroll、click-to-expand）多半抓不到
• 渲染存在延遲，新內容可能要過幾天才被索引
• 客戶端依賴 cookie、localStorage 才能顯示的內容，爬蟲看不到

對於以 AI Overviews 流量為重要目標的網站，SSR（Server-Side Rendering）或 SSG（Static Site Generation）幾乎是必要的。純 CSR（Client-Side Rendering）的 SPA 在 AI 搜尋時代會吃大虧——不是因為「AI 不喜歡」，而是因為基礎的爬蟲可達性就不及格。

這也是為什麼 CADCH 在做 技術正確的網頁設計時，會優先評估渲染策略：靜態內容能 SSG 就 SSG、需要動態的內容用 SSR 加 hydration、互動元件才用 CSR。這個策略跟 AI Overviews 沒有專屬關係，但它是讓內容能被任何機器正確讀取的基礎。

另一個容易被忽略的點：HTTP 狀態碼與 redirect chain。多層 302 redirect、不必要的 JavaScript redirect、回傳 200 但實際是錯誤頁的「soft 404」，都會讓爬蟲困惑。這些都是技術細節，但累積起來就是內容能不能進入 AI Overviews 候選池的差別。

七、各項工程方法的技術可信度對照

把所有實證跟技術原理放在一起，整理成這張表。判定標準是「技術原理是否合理」加上「是否有可信實證」，跟前面行銷導向的評估角度不太一樣，更聚焦在底層技術。

八、目前無法確定的灰色地帶

CADCH 自 2006 年以來的原則是：能確定的講清楚，不能確定的也要誠實標明。這個領域有些事我們現在無法 100% 確認，列出來給讀者參考：

• 語意標籤對 AI Overviews 引用率的具體影響量級。我們相信原理上正向，但無法給出「使用 article 標籤提升 N% 引用率」這種數字——任何給你這種數字的人，都應該被質疑來源。
• Schema markup 對 AI Overviews 的「間接」影響。Google 說不需要特殊 schema，但 schema 確實影響 Knowledge Graph 與實體理解，這部分是否間接影響 AI Overviews 的選源？目前沒有公開實驗能證實或證偽。
• JavaScript 渲染失敗對 AI Overviews 的影響程度。我們知道 Googlebot 的渲染限制，但渲染失敗導致內容缺失的「閾值」在哪裡，無法精確量化。
• 外部訊號（YouTube 提及、Wikipedia 收錄）的權重變化。Ahrefs 數據顯示這些是強相關因子，但 Google 可能隨 Gemini 模型版本調整權重——2024 年的數據未必適用 2026 年。
• 新興的 AI Mode 與 AI Overviews 在引用邏輯上的差異。Ahrefs 報告指出兩者引用 URL 重疊度不高，但底層差異的技術細節 Google 並未公開。

對這些灰色地帶，我們建議的態度是：用最佳實踐打底，不為單一不確定因素過度投入。把網頁設計做對、內容寫好、品牌經營扎實，這些事情即使在演算法變動時也不會白費。把預算押在某個「神奇參數」上的策略，從 SEO 黑帽時代到現在都沒有真正成功過。

九、我們怎麼幫客戶決定該做什麼、不該做什麼

CADCH 的決策邏輯一向很簡單，列出來給讀者參考，也給其他想做正確事情的同業一個對照：

1. 技術原理站不站得住腳。如果一個方法的底層邏輯本身就有問題（例如 llms.txt 的信任模型），就算現在沒有反證，我們也不會推薦客戶投入。
2. 實證來源是否可信。Google 官方文件、同行評議論文、規模夠大的獨立第三方實驗，這三類來源優先。代理商客戶資料、單一案例、無方法揭露的「+317%」一律存疑。
3. 是否符合長期可維護性。網站是長期資產，不是一次性投資。為了短期某個演算法版本而做的特殊優化，常常在下次更新時變成技術債。我們偏好做不管演算法怎麼變都仍然正確的事——語意標籤、無障礙設計、內容品質、效能優化。
4. 成本效益是否合理。低成本、有原理依據、即使無效也不會傷害——這類事情可以做（例如 Article schema）。高成本、原理薄弱、可能造成負面影響——這類事情不要做（例如為 AI 生成 Markdown 副本，疑似 cloaking 風險）。
5. 是否誠實面對不確定性。客戶問我們「實作這個能提升幾 % AI 引用率」時，如果沒有可信數據，我們會直接說沒有。包裝成保證才能成交的代理商，最終會傷害客戶的信任。

回到 GEO 這個話題本身，我們的看法很明確：絕大多數能影響 Google AI Overviews 表現的工程方法，本質上就是把網頁設計與 SEO 做對。語意標籤、清楚的 HTML 結構、合理的 schema、可被機器抽取的段落、SSR 確保爬蟲可讀、長期累積的品牌與權威——這些事情在 2006 年就是對的，在 2026 年也還是對的。

那些聲稱「為 AI 量身打造」的特殊技術，多半是把通用最佳實踐重新包裝、或者乾脆是不存在的東西。如果你正在評估一家 GEO 服務提供商，請他們解釋每個項目的「技術原理」，而不是只給你「+N% 提升」的數字。原理講不清楚的，多半就是原理本身有問題。

網頁設計這一行，從靜態 HTML 時代到響應式設計、從 SEO 到 AI 搜尋，技術會變、最佳實踐會更新，但「正確」這件事的核心邏輯沒有變過——讓機器與人類都能正確理解你的內容。CADCH 從 2006 年開始做的就是這件事，未來也會繼續這樣做下去。