AI 友善網站：Agentic Browsing 是什麼？

想像一下這個畫面：明天早上，你網站的第一個「訪客」不是一個坐在捷運上滑手機的真人，而是一個 AI Agent。它沒有情緒，不會被彈出的促銷 Banner 吸引，也不會因為一張漂亮的 hero 圖就停下來多看兩眼。它帶著一個明確任務進來，可能是幫它的使用者比價、可能是找一份你才有的規格資料、也可能是判斷你這家店值不值得幫使用者預約。它會在幾秒內掃完你的網站，然後做出一個決定：推薦你，或跳過你。

這就是 Agentic Browsing（代理式瀏覽）：AI 代理自己進到網站、自己讀、自己點、自己完成任務的新瀏覽方式。它跟傳統的 Google 爬蟲不一樣，跟 AI Overviews 那種摘要也不一樣。差別在於一個字：它不只是「讀」，它還會「操作」。

這裡要回答的只有一個核心問題：當「瀏覽網站的不一定是人」變成常態，你的網站準備好了嗎？

Agentic 友善的本質，是讓網站同時對人和對機器都清楚。語意 HTML、可正確渲染的 JavaScript、清楚的實體與定義、可操作的表單與按鈕，本來就是 SEO、可及性與網頁設計的基本功。AI Agent 的採用速度與影響仍在演變，現階段不宜把它直接等同 Mobile-First Indexing，也不該把結構化資料說成入場券。

導覽：Agentic Browsing 是什麼 → 為什麼近年值得關注 → AI Agent 如何讀取網站 → Agentic 預算 → 結構化資料 → JavaScript 與頁面體驗 → 行動面與可及性 → 存取邊界 → 自檢表與七步行動方案。

Agentic Browsing 是什麼：一個會自己瀏覽、自己決定的 AI 訪客

要搞懂 Agentic Browsing，最快的方法是把它跟兩個你已經很熟的東西擺在一起比：搜尋引擎爬蟲，跟 AI 搜尋摘要（AI Overviews）。

Google 的爬蟲（Googlebot）做的事是索引：它把全網頁面抓回來建檔，讓使用者之後搜得到。它讀的是原始 HTML、它看的是文字與連結、它不會真的「用」你的網站。AI Overviews、Perplexity 這類摘要型 AI，做的事是閱讀與整理：它讀完一堆資料，吐出一段答案給使用者，使用者多半不會再點進你的網站。

Agentic Browsing 是第三種，它做的是瀏覽加行動。AI Agent 帶著目標進網站，它會渲染頁面（像真人一樣看到 JavaScript 跑完的結果）、會點按鈕、會填表單、會比對頁面之間的資訊、會自己判斷「這家符合條件，那家不符合」。它的產出不是一段摘要，而是一個被完成的任務：訂到位、比出最低價、找到正確的聯絡方式。

實務上會用一張表把三者分清楚，因為它們對網站的要求完全不同：

維度	搜尋引擎爬蟲	AI 摘要（AI Overviews）	Agentic Browsing
它在做什麼	索引頁面，建檔供搜尋	讀資料，整理成一段答案	瀏覽並操作，完成一個任務
它「看」到什麼	多半是原始 HTML	爬蟲抓到的文字內容	渲染後的畫面＋可互動元素
它會不會點按鈕	不會	不會	會，這是核心
你的網站要對誰清楚	機器（文字與連結）	機器（可被引用的答案）	人＋機器（要能看懂，也要能操作）
典型代表	Googlebot、Bingbot	Google AI Overviews、Perplexity 摘要	Operator、Agentic Search、各種能上網的 AI 助理

看懂這張表，你就會明白為什麼不能把「做 AI 友善」直接等同於「做 SEO」。SEO 服務的是爬蟲與摘要引擎，Agentic Browsing 服務的是會動手的代理。後者的要求嚴格得多，因為它既要像爬蟲一樣能解析，又要像真人一樣能互動。

如果你想更深入了解「代理式搜尋」這條主線，可以搭配代理式搜尋（Agentic Search）介紹，那篇談的是搜尋端；這篇要談的是網站端，當搜尋變成代理，網站本身要怎麼接招。對「AI Agent 到底是什麼」還很陌生的讀者，建議先讀AI Agent 完整入門指南打好底。

從被搜尋到被代理：為什麼這幾年是分水嶺

很多人會問，Agentic Browsing 是不是又一個被炒起來的名詞？其實不是。它背後有一個結構性的技術條件成熟了。

過去幾年，大型語言模型（LLM）變強了，但它本質上是一個「被動回答」的系統：你問，它答。要讓它從「會說話」升級成「會做事」，缺兩塊拼圖：一是讓它能可靠地看懂並操作網頁（電腦使用、瀏覽器操作能力），二是給它一個能呼叫外部工具的標準化介面（這就是 MCP 這類協議在做的事）。這兩塊在最近一兩年快速補上，於是 AI 從「給答案」走向「幫你做完」。

如果使用者開始把比價、查規格或填表等任務交給 Agent，部分瀏覽行為可能不再由真人逐頁完成。這是值得提前測試的趨勢，但目前沒有證據能斷言網站讀者有多大比例會變成 Agent。

這就是為什麼這幾年是分水嶺。它不是「多了一種流量來源」這麼簡單，而是「誰在讀你的網站」這件事的本質變了。你過去所有的優化，預設讀者是人、次要讀者是爬蟲；接下來，你得多想一個全新的、會動手的讀者。

Mobile-First Indexing 提供一個可參考的教訓：Google 主要使用行動版內容進行檢索與索引，因此行動版不該缺少桌面版的重要內容；這是索引機制，不是獨立的「行動版排名加分」（見 2023 年 10 月的 Mobile-First Indexing is here 公告）。Agentic Browsing 尚未成為同等成熟的標準，但網站仍可先用可讀、可操作與可驗證的方式降低相容風險。行動版與桌面版並存的設計基礎可看響應式網頁設計。

這聽起來很像是 SEO 又要被推翻一次。倒不必這麼悲觀。你可以把相關的術語脈絡一次看懂：GEO、AEO、LLMO 這些別稱到底差在哪。Agentic Browsing 不是來取代 SEO，而是把 SEO 的技術底子重新拿出來考試，那些你以前覺得「做了也沒人看」的結構化資料、語意標記、可及性設計，突然之間有了新的、會動手的讀者。而 GEO（生成式引擎優化）這個更大的框架，可以看GEO 完整解析與GEO 與 SEO 的差異。

AI Agent 怎麼閱讀你的網站：渲染、解析、行動三層

要讓網站對 Agent 友善，你得先知道 Agent 怎麼讀你的網站。實務上可把它拆成三層，這個拆法能很快判斷一個網站的 Agentic 友善程度。

第一層、渲染（Render）：它看到的，是 JavaScript 跑完的畫面

傳統爬蟲多半讀原始 HTML，所以一個靠 JavaScript 動態產生內容的頁面，對它來說可能是空白的。但 Agentic Agent 不一樣，它的設計目標就是「像真人一樣用瀏覽器」，所以它會真的渲染頁面，看到 JS 跑完之後的結果。這代表一件重要的事：你的網站不能只靠「HTML 裡有字」就覺得安全，你的動態內容、互動元件、懶載入的區塊，Agent 都會碰到，但它碰到的方式跟爬蟲不同，跟真人也不同。

第二層、解析（Parse）：它讀懂意思，靠的是結構不是裝潢

渲染完之後，Agent 要從頁面讀懂資訊。不同代理可能使用螢幕截圖、DOM、可及性樹或多種訊號，不是完全沒有視覺能力。標題層級、表格欄位、語意 HTML、表單標籤與正確的結構化資料都能減少歧義，但沒有任何一項是所有 Agent 唯一的理解入口（見 Google 的 AI 內容優化指南）。

第三層、行動（Act）：它會點、會填、會導航

這是最關鍵也最常被低估的一層。Agent 不只讀，它還會操作。它要找得到「加入購物車」的按鈕、要能正確填寫表單欄位、要能從產品頁一路導航到結帳。如果你的按鈕是純圖片沒有文字標籤、如果你的表單欄位沒有清楚的 label、如果你的導航邏輯藏在滑鼠 hover 才出現的下拉選單裡，Agent 很容易卡住，然後放棄你，去找下一家。

把這三層想清楚，你就會發現「Agentic 友善」其實是一個非常具體的工程問題，不是玄學。它要的是：頁面能被正確渲染、內容能被結構化解析、行動面能被順利操作。這三件事，每一件都有對應的技術清單可以檢查。

Agentic 預算：你的網站有多少 token 可以被理解

這是最值得點出的一個觀念，因為它在一般談 Agentic Browsing 的文章裡很少被點出來。

你大概聽過 Crawl Budget（檢索預算）：Googlebot 分配給每個網站的抓取時間與次數是有限的，預算用完它就走。Agentic Browsing 也有一個類似的限制，只是它的單位換成了「token 與時間」，跟單純算抓取次數是兩回事。

每一個 Agent 背後都是一個語言模型，而語言模型讀東西是要花 token 的。它把你的頁面內容讀進去、轉成 token、放進上下文視窗裡理解，這整個過程有成本上限。一個頁面如果塞滿了裝飾性廢話、重複的免責聲明、跟任務無關的長篇品牌故事、動輒幾千字的「關於我們」，Agent 在抵達「使用者真正要的答案」之前，可能就已經把它的注意力預算燒掉一大半。

老實說，這件事對內容農場式寫法的殺傷力特別大。那種為了湊字數而灌水的文章（這類問題我們在內容農場 SEO談過），對真人是折磨，對 Agent 是直接的成本黑洞。Agent 不像人會出於禮貌或耐心把廢話看完，它的預算用完就截斷，截斷之後你頁面後半段再精準的資訊也讀不到。

這個概念可稱為「Agentic 預算」，它對網站內容的啟示很直接：

• 答案要放在前面。使用者要的那個規格、那個價格、那個地址，越早出現越好。這跟 SEO 把關鍵字放前面的道理一致，但動機不同：這裡是為了在預算燒完前讓 Agent 拿到答案。
• 每一個段落都要對得起它的篇幅。如果你寫了五百字卻沒有產生新資訊，那五百字對 Agent 是純成本。這正好呼應一個基本觀念：資訊增量（Information Gain）比字數重要太多。
• 結構要能讓 Agent 跳著讀。清楚的標題層級、表格、定義清單，讓 Agent 可以快速定位「要找的那一段在哪」，而不必整頁從頭讀到尾。

本質上來說，Agentic 預算逼著你做一件早該做的事：把內容裡的水分擠掉。對真人讀者友善的精實內容，對 Agent 同樣友善。這兩件事從來沒有衝突過，只是過去沒有一個夠強的誘因逼大家認真做。

結構化資料與語意 HTML：Agent 的導航骨架

如果 Agentic 預算講的是「內容密度」，那結構化資料講的就是「內容的可解析度」。前面提過，Agent 讀懂意思靠的是結構訊號，而結構訊號最密集的地方，就是結構化資料與語意 HTML。

結構化資料（Schema.org）能用機器可讀格式描述頁面內容。對 Google 而言，正確標記可讓符合資格的頁面取得特定搜尋功能，但不保證顯示；FAQ rich result 已於 2026 年 5 月停止。對 Agent 而言，Product schema 可能提供價格、庫存與規格等額外線索，前提是標記與頁面可見內容一致。它是輔助訊號，不是所有代理共用的最快或唯一入口。

技術 SEO 審查實務上最常發現的問題不是「沒有結構化資料」，而是「結構化資料是壞的」。常見的雷包括：

常見問題	對 Agent 的後果
Schema 與頁面實際內容不符（例如標了「有庫存」但其實缺貨）	Agent 拿到錯誤事實，回報給使用者後造成信任崩壞
缺少關鍵欄位（Product 沒有 price、LocalBusiness 沒有 address）	Agent 無法完成比價或預約任務，直接跳過
巢狀結構錯誤、type 用錯（Article 用成 WebPage）	Agent 誤判頁面類型，用錯誤的解析邏輯
用 JavaScript 動態注入 Schema 卻沒有對應的靜態 fallback	若 Agent 渲染流程有偏差，整段結構化資料消失

除了 Schema，語意 HTML 是另一條骨架。用 <article>、<nav>、<main>、<section> 把頁面結構講清楚，用 <th> 定義表格欄位，用 <dl> 寫規格定義。這些標籤對真人幾乎無感，但對 Agent 是金礦，因為它們把「這段是什麼角色」標得一清二楚。一個用 <div> 全包的頁面，對 Agent 來說就像一本沒有目錄、沒有頁碼的書。

而內部連結是骨架裡的關節。Agent 在站內移動、比對資訊、建立頁面之間的關係，靠的是連結。清晰、有脈絡、錨點文字有意義的內部連結結構，讓 Agent 能像走迷宮一樣有效率地完成任務。這部分可以參考內部連結完整指南跟網站架構，原理完全通用。

JavaScript、頁面速度與頁面體驗：Agent 也會等不下去

前面提過，Agentic Agent 會渲染頁面，所以 JavaScript 對它來說不再是「能躲就躲」的問題。但這不代表你可以放心地用 JS 把所有東西都動態載入。剛好相反。

原因有兩個。第一，渲染是要花時間的。Agent 雖然會等 JS 跑完，但它一樣有時間預算。一個要等三秒才跑出內容的頁面，跟一個秒開的頁面，在 Agent 的任務完成率上會有差距。JavaScript SEO 的核心原則：關鍵內容要在第一時間就存在於 DOM 裡、不要把核心資訊埋在需要複雜互動才載入的元件後面，在 Agentic 時代只會更重要。

第二，懶載入（lazy loading）用錯地方，會讓 Agent 拿不到完整資訊。一個商品列表如果第二頁以後的資料要靠滾動才觸發載入，Agent 不一定會去滾；就算它會滾，也增加它漏掉商品的風險。基礎的權衡可以參考懶載入與網站效能的做法：對「搜尋與任務關鍵」的內容，提供靜態可達的路徑；對純裝飾的圖片，才用懶載入。

Core Web Vitals（INP、LCP、CLS）衡量真人使用者感受到的載入、互動與視覺穩定度。Google 的排名系統會使用這些訊號，但良好分數不保證排名，也沒有單一頁面體驗分數。Agent 能否順利操作還取決於 DOM、標籤、權限與工具能力，不能直接用 INP 代表 Agent 成功率。詳見從 FID 到 INP與Core Web Vitals 入門；Google 的 page experience 文件對頁面體驗訊號有正式說明。

所以結論很務實：網站速度優化與頁面速度本來就該做，現在多了一個會用滑鼠的讀者，這些基本功的投報率只會更高，不會更低。

行動面與可及性：當 Agent 開始「用」你的網站

這是整個 Agentic Browsing 討論裡，最有意思也最被低估的一塊。前面講的渲染、解析、速度，本質上都還是「讀」。但 Agent 真正的殺手鐧是「用」。它要能完成一個動作。而一個網站「好不好被操作」，跟一個網站「對身心障礙者好不好用」，幾乎是同一件事。

這不是巧合。可及性（Accessibility，WCAG／ARIA）的核心精神，是讓網頁的每一個互動元素都能被「非視覺」的方式理解與操作，靠的是文字標籤、鍵盤可達、清楚的角色定義。Agent 的運作方式，某種意義上就像一個重度依賴這些結構訊號的「非視覺使用者」。它靠 ARIA label 知道一個按鈕是做什麼的、靠鍵盤可達性判斷能不能點、靠表單 label 知道每個欄位要填什麼。

換句話說，把網站的無障礙做好，等於免費送你一份 Agentic 友善。這兩件事在技術清單上高度重疊：

• 每個按鈕與連結要有可被理解的文字（不是一張純圖片的「X」）。
• 表單欄位要有清楚的 <label>，不要只靠 placeholder 提示。
• 互動元件要鍵盤可達，不要只設計給滑鼠 hover。
• 動態內容變動要即時反饋，讓依賴結構訊號的讀者（人與 Agent）知道發生了什麼。

這對很多網站是個壞消息，因為台灣大多數網站的無障礙做得非常隨便。但換個角度，這也是機會：當你的競爭對手的網站 Agent 還點不動按鈕、填不了表單時，你只要把這些做對，Agent 就會優先把任務在你這裡完成。這是一個「把基本功做到位就能拉開差距」的賽局。

實務上，幾個最容易卡住 Agent 的設計也一併列出，方便你回頭自檢：

會卡住 Agent 的設計	為什麼卡	怎麼修
結帳／預約流程強制登入才能看價格	Agent 多半沒有帳號，會直接撞牆放棄	關鍵資訊（價格、規格、時段）在登入前就要可見
把行動按鈕做成純圖片或 icon	沒有文字標籤，Agent 無法判斷點了會發生什麼	加上 aria-label 或可見文字
表單欄位只用 placeholder 標示名稱	placeholder 不是 label，Agent 解析不到欄位意義	用正規 <label> 綁定欄位
導航選單只在滑鼠 hover 時展開	鍵盤與 Agent 都難以觸發	改成可鍵盤聚焦、可程式觸發的選單
驗證碼（CAPTCHA）擋在關鍵流程前	對 Agent 是硬性阻擋，這通常是有意的	若不想擋 Agent，改用行為式或後端風控

CAPTCHA 是風險控制工具，不等於網站全面拒絕 Agent。是否使用、放在哪個流程，要依詐騙、濫用、可及性與轉換成本評估；涉及付款或帳戶操作時，安全性通常優先。

而整個網站的「好不好用」，跟它的視覺與資訊設計脫不了關係。如果你還沒看過，常見網頁設計錯誤可以挑出來讀一遍，這些設計原則在 Agentic 時代依然成立，而且更吃重。

存取邊界：robots.txt、llms.txt 與你要不要讓 Agent 進來

講到這裡，需要平衡一下視角。Agentic 友善不是無條件地把網站對所有 Agent 敞開。你完全有權利決定：哪些 Agent 可以進、可以做到什麼程度。這是你的網站、你的內容、你的商業模式。

robots.txt 是給守規範爬蟲的檢索指令，不是存取控制或安全機制。使用真實瀏覽器的 Agent 是否遵循它，取決於產品政策與技術實作。私人、付費或敏感內容仍要使用登入驗證、授權、速率限制與伺服器端控管，不能靠 robots.txt 保護。

llms.txt 是實驗性提案，尚不是搜尋與 Agent 的通用標準。Google 明確表示搜尋系統不使用 llms.txt，加入與否不會改善或傷害 Google 的能見度；只有在目標產品明確支援時，才有測試價值。它也不能取代 Sitemap、內部連結、robots.txt 或存取控制。

建議這樣思考：把「要不要讓 Agent 進來」當成一個清楚的商業決策，別交給技術預設值去決定。幾個判斷維度：

你的商業模式	對 Agent 開放的程度	理由
內容媒體、品牌曝光導向	盡量開放	Agent 引用你等於免費的品牌觸及，被推薦就是流量與信任
電商、比價敏感	選擇性開放	希望被推薦，但不希望被無成本地全量爬取價格
會員制、付費內容	登入牆後不開放	內容本身就是商品，開放等於送掉生意
工具型 SaaS、需登入才能用	公開頁面開放、產品內不開放	讓 Agent 認識你，但互動仍由真人使用者登入後完成

這個決策沒有標準答案，重點是「有意識地決定」，主動選擇，別被動交給技術預設值。被 Agent 推薦的長期價值（這正是品牌要成為被推薦的答案在談的事），跟被 Agent 無成本搬走的風險，要放在同一個天平上一起秤。

這裡還有一個必須誠實面對的現實：今天你很難完美地「只擋壞 Agent、放行好 Agent」。一個設計來模仿真人瀏覽器的 Agent，跟一個真正的真人使用者，在技術特徵上的界線越來越模糊。你可以用頻率限制、行為分析、登入牆這類手段提高門檻，但很難做到滴水不漏。所以別把力氣全押在「擋」這件事上，把基本功顧好、把該開放的開放、把該保護的（付費內容、會員資料）用登入與授權確實守住，反而更實際。這是最務實的平衡點。

誰會先被衝擊，以及為什麼內容依然是最難被取代的差異

Agentic Browsing 不會對所有網站造成同等衝擊，它最先改寫的是那些「Agent 能直接幫使用者完成任務」的場景。可分成幾種受衝擊程度不同的類型：

• 高衝擊：電商比價、旅遊訂房、本地商家預約。這些場景的任務通常具備價格、時段與地點等結構化條件，代理可協助比較選項或進入交易流程。Google 與零售、支付業者共同制定的通用商務協定（UCP），正在標準化部分代理結帳的互通方式；但可用市場、商家資格與功能仍須依官方現況確認。
• 中衝擊：資訊型查詢、規格查詢、教學步驟。Agent 會讀取並整理，但最終判斷多半還是交還給使用者。這裡的關鍵是內容的正確性與唯一性，你是不是那個擁有權威答案的來源。
• 較低衝擊但長期轉變：品牌體驗、內容訂閱、社群互動。這些場景的核心價值在「人的情感連結」與「專屬內容」，Agent 能幫忙發現與導航，但無法取代體驗本身。

這個分類告訴我們一件重要的事：不管你屬於哪一種，內容的權威性與第一手經驗，永遠是 Agent 沒辦法稀釋的差異化來源。Agent 能搬走的是「事實」，搬不走的是「你這個人、這個品牌對這個主題的真實經驗與獨特觀點」。這就是為什麼 E-E-A-T 在 AI 時代不是變不重要，而是變更重要，當事實型資訊被 Agent 商品化，剩下的差異化全押在 Experience（經驗）與 Authority（權威）上。

而「經驗」這件事，AI 寫不出來。一篇是你親身跑過、實測過、踩過坑才寫得出來的內容，另一篇是 AI 把公開資訊重新組合的內容，Agent 在比對多個來源時，能從前者的細節密度、具體觀察、非通用的判斷裡讀出差異。這也是實務上會強調實體（Entity）與主題權威要長期累積的原因：你要成為某個主題上「Agent 繞不過去」的那個來源。

怎麼知道自己做對了：Agentic 友善的檢測方法

講到這裡，有一個很實際的問題：有沒有一個分數，像 Lighthouse 的 Performance 分數那樣，直接告訴你「你的網站 Agentic 友善度幾分」？老實說，目前沒有一個公認的單一指標。Agentic Browsing 還太新，各家 Agent 的行為也不統一，這種標準化還需要時間。

但這不代表你只能憑感覺。下面把幾個實務上常用的「代理測試」整理出來，它們每一個都是某個 Agent 行為的可量化代理指標，合在一起就能給你一個相當準的判斷：

• 關 JavaScript 測一遍。在瀏覽器停用 JS，重新打開你的核心頁面。關鍵的商品資訊、價格、聯絡方式還在不在？這是「Agent 會不會拿到空白頁」最直接的代理測試，也是爬蟲友善度的老指標。原理跟網頁原始碼檢查一樣，SEO 人都熟，可以參考F12 開發者工具的操作。
• 純鍵盤走完核心流程。把滑鼠拔掉，只用 Tab、Enter、空白鍵，看你能不能從首頁走到結帳或預約完成。卡住的地方，就是 Agent 也會卡住的地方。這是行動面（Act 層）最有效的低門檻測試。
• 用適合的工具驗證結構化資料。Google Rich Results Test 用來檢查 Google 支援的搜尋功能；一般 Schema.org 詞彙則用 Schema Markup Validator。兩者用途不同，都要再核對標記是否與頁面可見內容一致。
• 看 Lighthouse 的 Accessibility 分數。無障礙分數衡量的是 label、ARIA、對比、鍵盤可達這些項目，正好就是 Agent 操作時依賴的訊號。分數低，Agentic 友善通常也低，這兩者高度正相關。
• 做一次「事實抽取」練習。把你自己的頁面當成陌生資料，假裝你只能讀文字與結構、看不到視覺設計，試著把「這頁賣什麼、多少錢、條件是什麼」抽出來。抽不出來、或抽不準的地方，就是 Agent 會誤判的地方。

這五個測試多半可用既有工具完成，能找出渲染、標籤與互動問題。它們是實務代理指標，不是經過所有 Agent 驗證的統一評分，因此仍要以目標代理的實際任務測試為準。

這裡還有一個必須誠實說明的提醒：上面這些都還是「代理指標」，不是 Agent 真實表現的保證。真正的驗證，是讓一個 Agent 實際在你的網站上跑任務、看它成不成功。這個能力正在快速成熟，但今天你還沒辦法像看 GA 流量那樣穩定地量測「Agent 任務完成率」。在這個指標出現之前，把代理測試做扎實，是你能掌握的最務實路線。

Agentic 友善自檢表：你的網站準備好了嗎

講了這麼多，以下收斂成一張你可以立刻拿去用的自檢表。對照你的網站，看看每一項打勾了沒：

檢查項目	通過標準	背後的 Agentic 邏輯
關鍵頁面有結構化資料	Product／Article／LocalBusiness 等型態正確、欄位完整、與頁面內容一致	Agent 的最快解析路徑
語意 HTML 結構完整	用 article／nav／main／section，表格有 th，定義用 dl	讓 Agent 跳著讀，省預算
核心內容不依賴 JS 才出現	關掉 JavaScript，關鍵資訊仍在原始 HTML 裡	降低渲染風險與時間成本
行動按鈕都有文字標籤	不是純圖片，有 aria-label 或可見文字	Agent 知道點了會發生什麼
表單欄位有正規 label	用 label 綁定，不只靠 placeholder	Agent 能正確填寫
導航鍵盤可達	不靠滑鼠 hover 也能展開選單、觸發互動	Agent 用程式觸發互動的基礎
關鍵資訊不藏在登入牆後	價格、規格、時段在未登入狀態可見	Agent 多半沒帳號，撞牆就放棄
內容密度高、水分低	每段都帶新資訊，沒有為字數而寫的段落	保護 Agentic 預算
內部連結結構清晰	錨點文字有意義，站內動線可被程式追蹤	Agent 在站內移動與比對的關節
頁面體驗達標	INP／LCP／CLS 在 Core Web Vitals 及格線上	Agent 的時間預算與互動回應

這張表不是要你一次做完。它是一份地圖，讓你知道自己在哪裡、離「Agentic 友善」還有多遠。打勾的越多，你在下一輪「被 Agent 推薦」的賽局裡就越穩。

七步行動方案：從今天開始打造 Agentic 友善網站

下面是一份這週就能開始的行動清單，順序從成本較低的檢查排到需要較多工程投入的項目：

1. 盤點你的結構化資料。挑出流量最高的十個頁面，用 Google 的 Rich Results Test 跑一遍，看型態對不對、欄位缺不缺、有沒有跟頁面內容打架。壞的 Schema 比沒有 Schema 更危險。
2. 把答案往前放。重新檢查你的核心頁面，問自己一個問題：Agent 拿到任務後，能不能在頁面前三分之一就找到答案？把冗長的品牌故事、跟任務無關的鋪陳往後挪，或刪掉。
3. 修行動按鈕與表單。逐頁檢查按鈕有沒有文字標籤、表單有沒有正規 label。這是最便宜、見效最快的一步，因為它同時改善無障礙與 Agentic 友善。
4. 檢查 JavaScript 內容可見性。在瀏覽器關掉 JS，看關鍵內容還在不在。不在的，補上伺服器端渲染或靜態 fallback。
5. 確認導航鍵盤可達。只用鍵盤走一遍你的核心流程（首頁到結帳、首頁到聯絡）。卡住的地方，就是 Agent 也會卡住的地方。
6. 決定你的存取政策。想清楚哪些內容可公開檢索、哪些需要登入或授權。robots.txt 用於守規範爬蟲，敏感內容用真正的存取控制；llms.txt 只在目標產品明確支援時測試。
7. 把無障礙排進路線圖。這是最花時間、但長期回報最高的一項。把 WCAG 的核心檢查項目排進開發排程，當成持續工程來做，別當成一次性專案就收工。

七步走完，你不會「做完」Agentic 友善，因為 Agent 的能力、規範、行為模式都還在演進。但你會比九成的網站更早站在正確的位置上，而 SEO 這場仗，從來都是比誰早到位、比誰基本功扎實，不是比誰有什麼別人沒有的秘技。

有一句話始終受用：為真人寫作，為機器人優化。這句話在 Agentic 時代有了新的重量，因為「機器人」現在會自己走進來、自己操作、自己決定要不要推薦你。你不必去迎合它，你只要把對真人和對機器都該做對的事做對，它就會替你把價值傳遞出去。

回頭看這整篇，你會發現一個共同點：每一個讓網站更 Agentic 友善的動作，結構化資料、語意標記、鍵盤可達、精實內容、清楚的實體，全都是本來就該做、做了對真人讀者也好的事。Agent 只是那個把你遲早該還的技術債，提前催繳的催收員。這是好消息，因為你不需要學一套全新的技術；你只需要把已知的對的事情，更認真地做完。

不確定才是唯一的確定。當瀏覽網站的不一定是人，先把基本功這關站穩的人，才有資格談下一階段的成長。