想被 AI 引擎引用、被 AI 代理正確操作，關鍵不在於你的網站多好看，而在於機器能不能一眼看懂它的骨架。用 semantic HTML 標出每一塊內容的角色、用清楚的標題階層與資訊架構把答案切成可擷取的段落、再用 schema.org 結構化資料把隱性資訊寫成明碼——這三件事做到位，AI 才有辦法「引用你這一段」而不是「大概提到你這個牌子」。反過來說，滿版的 div 與靠 CSS 撐出來的假標題，在代理眼中就是一團沒有意義的雜訊。
先講結論：AI 讀的不是版面，是骨架
過去十幾年，前端的主流思維是「畫面對了就好」。瀏覽器很寬容，使用者只看渲染結果，於是一堆網站的原始碼長得像一鍋 div 湯——標題是 div 加大字級、按鈕是 div 綁 onclick、表格是 div 排成格子。人看得懂，因為人有眼睛。
問題是現在來訪的不只有人。生成式引擎要從你的頁面裡挑出一段話當作答案來源，瀏覽器代理要在你的網站上完成「查價、選規格、加入購物車」這種多步驟任務。這兩件事都需要同一個東西：可以被機器解析的結構。
對人來說是視覺設計的問題，對機器來說是「這一塊到底是什麼」的問題。
所以我的立場很明確：與其花錢追那些每年換一輪的視覺趨勢，不如先把標記與架構修乾淨。前者是加分題，後者是及格線，而且現在及格線正在往上抬。
為什麼 semantic HTML 在代理時代突然變得要命
semantic HTML 這件事講了快十五年，早期的理由是無障礙與 SEO。這兩個理由都成立，但老實說，它們對多數老闆來說不夠痛——螢幕閱讀器的使用者比例不高，搜尋引擎又聰明到就算你亂寫也猜得出來。
代理式瀏覽改變了這個算式。AI 代理不像搜尋引擎有幾年的時間慢慢學習你的網站，它是在使用者按下「幫我訂這個」的那一秒，即時解析 DOM、判斷哪個元素可以點、哪個欄位要填什麼。這時候：
<button>和<div role="button">的差別，是代理敢不敢點下去。<label for>有沒有正確綁定，決定代理填的電話號碼會不會跑到地址欄。<nav>、<main>、<article>、<aside>讓代理知道哪些是導覽雜訊、哪些是正文，直接影響它塞進上下文視窗的內容品質。- 正確的
<h1>到<h3>階層，等於幫模型畫好了「這篇文章在講什麼、分成幾塊」的地圖。
Chrome 在 2026 年 5 月釋出的 Lighthouse 13.3 加入了一個叫 Agentic Browsing 的稽核類別，檢查的四個項目是 WebMCP 整合、代理可存取性、版面穩定度，以及 llms.txt 的處理。看到「代理可存取性」被放進官方稽核工具，就知道這已經不是理想主義者的堅持，而是一個會被量化評分的工程指標。
一個實用的自我檢查：把你的頁面用純文字瀏覽器（例如 Lynx）或關掉 CSS 打開來看。如果閱讀順序亂七八糟、看不出哪裡是主要內容，那代理看到的也差不多就是這副樣子。
div soup 的代價：一個真實的對照
去年我接手一個 B2B 零件商的網站改版。原本的產品頁全部是 div 疊出來的，規格表是四層巢狀 div 排版，型號寫在 <span> 裡靠字級區分主次。他們的困擾是：客戶用 AI 助理問「XX 型號的耐溫範圍」，得到的答案不是查無資料，就是抓到競爭對手的規格。
我們沒有改任何視覺設計，只重寫了標記。下面是改動前後的對照：
| 內容區塊 | 改寫前 | 改寫後 | 機器讀到的差別 |
|---|---|---|---|
| 產品名稱 | div 加 36px 字級 | h1 | 從「一段文字」變成「這頁的主題」 |
| 規格表 | 巢狀 div 排版 | table 搭配 th scope | 欄位與數值產生對應關係，可直接擷取成鍵值對 |
| 詢價按鈕 | div 綁 click 事件 | button type="submit" | 代理能辨識這是可執行的動作，而非裝飾 |
| 相容型號清單 | 用 br 換行的一整段文字 | ul 加 li | 從一串字串變成可列舉的項目 |
| 技術文件下載 | span 綁 JS 觸發下載 | a 加 href 與 download | 連結可被爬取、可被代理直接取得 |
三個月後，他們用同樣的問法去問幾個主流的 AI 助理，正確回答率從幾乎為零變成穩定回得出來，而且會把型號與數值一起講對。這裡面沒有任何魔法，就只是把「這是什麼」誠實地寫在標籤裡而已。
資訊架構：被引用的前提是「找得到那一段」
標記處理的是單一元素的語意，資訊架構處理的是整站的可導航性。這兩件事常被混為一談，但失敗的樣子不一樣：標記爛，機器讀不懂單頁；架構爛，機器根本走不到那一頁，或走到了也不知道它跟其他頁的關係。
一個主題一個網址
最常見的架構病是把十個主題塞進一頁長長的「服務項目」。人可以滑，模型不行——它需要一個明確的 URL 來當作引用來源。如果你希望「工業用軸承保養週期」這件事被引用，它就該有自己的頁面、自己的 h1、自己的網址。
把答案放在問題後面的第一段
生成式引擎在擷取答案時，強烈偏好「問題—答案」緊鄰的結構。所以標題用問句或明確陳述句、下一段的頭兩句就把結論講完，剩下的再展開。這不是寫作技巧的問題，是擷取效率的問題：模型的上下文視窗有限，你把答案埋在第七段，它可能根本沒讀到那裡。
內部連結要有語意
「點此了解更多」這種錨文字對機器完全沒有資訊量。改成「查看軸承保養週期建議表」，等於同時告訴爬蟲、模型與使用者連結另一端是什麼。這是零成本的改動，但幾乎所有網站都在浪費它。
層級不要超過三層
首頁 → 分類 → 內容頁，三層以內。每多一層，代理需要的點擊步驟就多一輪，失敗機率跟著上升。我看過一個電商把商品埋在第五層，代理在第三層就迷路了，因為中間有個分類頁的連結是用 JavaScript 動態產生的。
schema.org 結構化資料：把你以為理所當然的事寫成明碼
semantic HTML 能表達「這是一個標題」「這是一個表格」，但它表達不了「這個數字是價格，幣別是新台幣，庫存狀態是有貨」。這一層要靠 schema.org 結構化資料補上。
實務上我建議用 JSON-LD 寫在 <head> 裡，理由很單純：它跟版面完全解耦，改設計不會弄壞它，維護成本最低。至於該標哪些型別，別貪心，先挑跟你商業模式最相關的：
| 網站類型 | 優先型別 | 為什麼是它 |
|---|---|---|
| 電商 / 品牌官網 | Product、Offer、AggregateRating | 代理結帳流程需要價格、庫存、幣別這些欄位才能判斷能不能買 |
| 內容媒體 / 部落格 | Article、Author、Organization | 作者與發布者是模型判斷可信度的關鍵訊號 |
| 在地服務業 | LocalBusiness、OpeningHoursSpecification | 營業時間、地址、電話是被問最多的三件事 |
| SaaS / 工具 | SoftwareApplication、FAQPage | 方案價格與常見問題最容易被整段引用 |
| 教學 / 知識庫 | HowTo、BreadcrumbList | 步驟型內容標記後，模型能保留正確順序 |
兩個一定要守住的原則。第一，結構化資料必須與頁面上肉眼可見的內容一致——標了 4.8 顆星但頁面上沒有評價，這是會被懲罰的作弊行為，而且模型交叉比對時也會降低對你的信任。第二，Organization 與 Product 的實體名稱要全站一致，包含你在其他平台上的名稱。實體不一致是模型認錯人的主因。
Yext 分析六百八十萬則 AI 引用後發現，其中約 86% 來自品牌自己能控制的來源。這個數字對我來說是整件事最務實的理由：你標得清楚不清楚，直接決定 AI 在講你的時候，講的是不是你想讓它講的版本。
今天就能動手的稽核清單
不用等改版，這些多半是幾小時內能修完的：
- 每一頁只有一個
<h1>，而且它跟頁面主題一致。 - 標題階層不跳號（不要 h2 直接跳 h4）。
- 正文包在
<main>裡，導覽在<nav>，側欄在<aside>，頁尾在<footer>。 - 所有可點擊的東西是
<a>或<button>，不是 div。 - 表單每個欄位都有對應的
<label>，自動填寫用 autocomplete 屬性標好。 - 圖片的 alt 寫的是內容而不是檔名；純裝飾圖用空 alt。
- 資料型內容用真正的
<table>，並用<th scope>標出表頭方向。 - 錨文字具體，不用「這裡」「更多」。
- 核心頁面補上對應的 schema.org 結構化資料，並用官方測試工具驗過。
- 關掉 JavaScript 後，主要內容仍然讀得到。
做完這十項，你的網站在代理眼中的可用性大概就贏過八成同業了。這不是誇飾，是因為大部分網站真的沒在做這件事。
三個我一再遇到的錯誤現場
把整站包成單頁應用，卻沒做伺服器端渲染
爬蟲與部分代理拿到的是空殼 HTML，內容全靠前端 JS 塞。你以為的滿滿內容，機器看到的是一個空 div。要嘛做 SSR，要嘛做預渲染，沒有第三條路。
用圖片承載關鍵資訊
價目表做成一張圖、規格表做成 PDF 截圖、營業時間寫在 banner 上。這些內容對機器等於不存在。我理解設計上很方便，但它的代價是你在 AI 答案裡直接消失。
Cookie 同意視窗擋住所有東西
這個最近特別常見。代理一進站就撞上一個蓋滿版面、關閉按鈕又是 div 做的同意視窗，任務直接中止。至少把關閉與同意按鈕做成真正的 <button>，並確保底層內容仍在 DOM 裡。
從「被引用」到「被操作」：llms.txt 與 WebMCP 的位置
講到這裡一定會有人問：那 llms.txt 呢？那 WebMCP 呢？不是說這些才是 2026 年的重點嗎？
我的看法是：它們重要，但它們是蓋在語意標記之上的樓層，不是地基。
先說 llms.txt。它的原理很清楚，用 Markdown 取代雜訊很多的 HTML，讓代理不必用大量 token 去消化導覽列、廣告與追蹤碼；有公司回報 token 用量可以降到十分之一。但實測數據沒那麼浪漫——SE Ranking 掃描三十萬個網域，採用率約一成；而在真正會帶來引用的爬蟲流量裡，觸及 /llms.txt 的請求比例低到幾乎可以忽略。所以我的建議是：它成本低，可以做，但別當成排名槓桿，也別把它排在修標記前面。
WebMCP 則是另一回事，它讓網站主動向代理宣告「我這裡有哪些可執行的功能」。它從 Chrome 149 起進入公開的 Origin Trial，分成宣告式（寫在 HTML 裡）與命令式（JavaScript）兩種 API。這是真正會改變遊戲規則的東西，但請注意——你要宣告的那些功能，本身就得建立在乾淨的表單與按鈕上。標記爛的網站接 WebMCP，只是把混亂包裝得更正式而已。
| 順序 | 層次 | 代表做法 | 投入產出比 |
|---|---|---|---|
| 1 | 結構層 | semantic HTML、標題階層、資訊架構 | 高，且一勞永逸 |
| 2 | 語義層 | schema.org 結構化資料、實體一致性 | 高，維護成本中等 |
| 3 | 索引層 | llms.txt、Markdown 版本、爬蟲政策 | 低成本、低回報，可做 |
| 4 | 執行層 | WebMCP、MCP server、代理身分驗證 | 視業務而定，電商優先 |
看到那個順序了嗎？很多人是從第四層開始做的，因為那層最有話題性。然後在第一層漏了一地。
怎麼知道有沒有效
這是最容易被含糊帶過的部分，所以講具體一點。四個可以真的量到的指標：
- 伺服器日誌裡的 AI 爬蟲流量。直接看 GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 這些 user agent 的請求次數與抓取深度。抓得深，代表你的架構走得通。
- Lighthouse 的 Agentic Browsing 分數。改版前後各跑一次，這是目前最接近官方標準的量尺。
- 引用追蹤。定期用固定的十到二十個問題去問幾個主流 AI 助理，記錄有沒有提到你、資訊正不正確。土法煉鋼，但比任何工具都誠實。
- AI 來源流量的轉換率。Adobe 在 2026 年 3 月的數據顯示，美國零售業中來自 AI 的流量轉換率比非 AI 流量高出約 42%，2026 年第一季的年增幅接近四倍。量體還小，但這是含金量最高的一群訪客，值得單獨拉一個區隔來看。
如果你只能追一個，追第一個。伺服器日誌不會說謊，也不需要付費工具。
接下來三十天的優先順序
把事情排出先後，比全部都想做卻什麼都沒完成有用得多。我會這樣安排：
- 第一週：跑一次全站標記稽核，列出所有假按鈕、假標題、假表格。從流量前二十的頁面開始修。
- 第二週：修標題階層與內部連結錨文字。同時把關鍵資訊從圖片裡搬出來變成文字。
- 第三週：替核心頁面補上 schema.org 結構化資料，用官方工具驗證，確認與可見內容一致。
- 第四週：建立基準線——記錄 Lighthouse 分數、AI 爬蟲日誌、以及那組固定問題的回答品質。之後每月重跑一次。
這裡面沒有一件事需要新技術、新框架或新預算。它們全部都是二十年前就該做好的基本功，只是現在終於有一個誰都無法忽視的理由去把它做完：因為讀你網站的，已經不只是人了。
把骨架修直，剩下的事情才有支撐它的東西。