多數人以為，打開首頁的一定是坐在螢幕前的真人。但 2026 年 6 月 3 日，Cloudflare Radar 測到的數字反過來了。發送到 HTML 內容的 HTTP 請求裡，57.5% 來自自動化程式，只剩 42.5% 是真人。這個交叉點，Cloudflare 執行長 Matthew Prince 原本預估要等到 2027 年底才會出現，結果提早了大約一年半。
造成這次交叉提早發生的，不是舊時代的搜尋引擎爬蟲，而是會自己逛網站、自己做決定的 AI 代理。它們讀首頁的方式跟人不同，靠的不是眼睛，是程式碼裡的結構。首頁的版面因此不能只顧視覺，還得讓這批讀結構的新讀者看得懂你在賣什麼，這正是 AI 瀏覽首頁內容結構真正要顧的地方。
這篇只拆版面與內容分區：標題怎麼分層、段落怎麼寫、動態效果會不會擋住讀取，不碰結構化資料標記這類技術工程。先從 AI 代理怎麼「看」一個網頁講起。
AI 代理眼中的首頁，長什麼樣子？
AI 代理進到一個頁面時，不會像人一樣先用眼睛掃過整個畫面再決定要看哪裡。Google 官方的開發者指南 web.dev 把目前主流的讀取方式整理成三條路：一是把頁面拍成螢幕截圖，交給視覺模型判讀；二是直接讀原始 HTML，分析節點之間的巢狀關係；三是讀無障礙樹（accessibility tree），也就是瀏覽器原生從既有 DOM（文件物件模型）算出來、專門給螢幕報讀器與代理使用的語意精簡版。web.dev 也特別強調，結合多種模態交叉判讀，才能避免單一輸入造成的語意落差。
無障礙樹是這三條路裡最容易被忽略、卻最關鍵的一層。W3C 在 WAI-ARIA 規範裡把它定義成一棵「代表使用者介面結構的可及物件樹」，Search Engine Journal 整理出的四項屬性，分別是角色（role，這是按鈕還是連結）、名稱（name，它叫什麼）、狀態（state，選中了嗎、展開了嗎）、描述（description，超出名稱以外的補充資訊）。版面設計得再漂亮，如果這三種讀法都讀不到清楚的結構，AI 代理等於在瞎子摸象。
現在比較成熟的代理不會只靠一種管道判斷，常常會交叉比對，用無障礙樹先抓出這個頁面有哪些可以互動的元素，再拿截圖確認這些元素在版面上怎麼分組、排在哪個位置，單靠其中一種，都可能誤判。這也是 AI 瀏覽首頁內容結構最基本的起點，讓網站本來就該有的語意結構，清楚地被這三條路都讀得到。
螢幕截圖：靠視覺線索猜版面
螢幕截圖這條路，靠的是視覺模型讀顏色、大小、留白與鄰近關係，去猜哪些元素分在同一組、哪個看起來像主要的行動按鈕。這種判讀方式跟人眼掃視頁面的邏輯接近，對「大概在哪裡、大概分幾區」這種空間問題很管用。
它猜不到的是「這是什麼功能、按下去會發生什麼事」。一個長得像按鈕的色塊，視覺模型看得出它可能可以點，卻不知道點下去是送出表單，還是跳到另一個頁面；這個層次的答案，螢幕截圖給不出來，得靠另外兩條路補上。
原始 HTML：讀 DOM 裡的巢狀關係
一個按鈕如果包在某個商品的容器裡，代理讀原始 HTML 時就會合理假設，這顆按鈕是屬於那個商品的操作，不是頁面上其他地方的功能。整個頁面的 id、class 命名與巢狀層級，等於是代理推論語意的線索。
問題出在很多網站的 HTML 是一堆沒有意義的 <div> 疊 <div>，只是為了排版方便而巢狀出來的容器，節點之間沒有清楚的父子語意。遇到這種結構，代理讀得到節點存在，卻讀不出節點之間的關係代表什麼，這條路就會失靈。
無障礙樹：忽略視覺噪音，只留下角色、名稱與狀態
無障礙樹值得優先顧好，是因為它不是另外要生產的東西，是瀏覽器直接從你已經在維護的那份 DOM 算出來的，不需要為它多寫一行程式碼，只要原本的 HTML 語意夠清楚，瀏覽器就會自動整理出一棵乾淨的樹，把顏色、字型、留白這些視覺雜訊全部濾掉，只留下角色、名稱、狀態這幾項真正重要的資訊。
把這一層顧好，受益的不只是 AI 代理。螢幕報讀器原本就是讀這棵樹讀給視障使用者聽，搜尋引擎的部分判讀邏輯也參考這棵樹。換句話說，顧好無障礙樹是一次投入，三種讀者一起受惠，這也是為什麼它比另外兩條路更值得優先花力氣。
首頁最上面那一屏，AI 幾秒內就決定要不要往下看
進站的每一次爬取，代理都有時間與資源的預算限制，不會把整個網站每個角落都看完再下判斷。首頁最上面那一屏，就是這份預算裡最先被掃過、也最容易決定去留的區塊，如果這裡看不出「這是什麼、賣什麼、給誰用」，代理很可能直接判斷不出重點，轉頭離開這個網站。
問題常出在首屏的文字寫得太意象化。假設一個做行銷顧問服務的網站，首屏標語寫「找到品牌的下一步」，這句話對人類訪客靠著配圖、色調還能猜出一二，但對只讀文字結構的代理而言，這句話等於什麼都沒說，它讀不出這個網站提供什麼服務、服務誰。換成具體陳述句，像「提供中小企業的社群經營與廣告投放顧問服務」，代理讀到的就是一段可以直接對應到搜尋意圖的具體資訊。差別不在寫得美不美，在講得夠不夠具體。
更根本的問題是，這段說明文字要留在原始 HTML 裡，不能整段靠一張大圖或一支影片撐場面，也不能等使用者滑動、點擊，或前端程式執行完才浮現。像 GPTBot、ClaudeBot 這類訓練型爬蟲並不會執行 JavaScript，只讀伺服器回應的初始 HTML；如果首屏文字要等前端渲染完才出現，這些爬蟲讀到的就是一片空白。
想確認自己的首頁過不過關，有個簡單的方法可以測，用代理的 User-Agent 直接發一次請求，看看伺服器回傳的原始碼裡，找不找得到那段首屏說明文字。
curl -A "GPTBot" https://你的網站網域/Code language: Bash (bash)如果這段指令回傳的原始碼裡看不到首屏那段說明文字，就代表核心內容被前端渲染擋住了，得靠伺服器端渲染或預先渲染，把文字放進伺服器回應的初始 HTML 裡。
標題階層不是排版工具，是 AI 的頁面地圖
把視角從首屏拉大到整個首頁，下一層決定 AI 讀不讀得懂版面的，是標題階層。H1 到 H4 之間的巢狀關係，對 AI 代理來說就等於一份頁面地圖，跟螢幕報讀器、搜尋引擎讀的是同一份；這跟 web.dev 說明標題該依邏輯嵌套的原則，方向是一致的。階層亂跳，或者只是為了視覺效果調整標題層級，代理就抓不到這個頁面的組織邏輯，不知道哪些內容是同一個層級、哪些是彼此的子項目。
同一時間也要顧好的，是自足段落。Search Engine Land 把自足段落歸納成四個特徵：單一完整的想法、具體的事實與數字、清楚的標題、結論或重點前置而非壓到最後才講。首頁常見的每個內容區塊，像核心服務摘要、關於我們摘要、案例摘要，都應該各自把資訊講完整，單獨抽出來看也要說得通，不能靠「承接上一段」才看得懂。這件事之所以重要，是因為 Search Engine Land 也指出，AI 系統多半不是整頁閱讀，而是從網頁各處抽取一段一段的內容，拼裝成它要的答案，抽出來的那一段常常脫離了原本的上下文。
H1 到 H4 不能跳級，也不能為了視覺效果亂用順序
跳級最常見的兩種長相：一種是整個首頁塞了五、六個 H1，每個區塊都想搶最大的標題層級，好讓文字看起來夠醒目；另一種是明明該用 H2 的段落，卻因為設計師覺得 H3 的字級比較好看，直接跳著用。這兩種做法對人類訪客來說，頂多是排版有點怪，但對 AI 代理來說影響嚴重許多，它讀到的階層邏輯不是「這裡有五個同樣重要的主標題」，就是「這裡忽然冒出一個沒有上級的小標題」，完全對不上這個頁面真正的組織方式。代理沒辦法整理出一份可靠的頁面大綱，也就沒辦法正確總結或導覽這個頁面。
每個分區段落要禁得起「單獨抽出來看」
自足段落長什麼樣子，用一個假設的例子最清楚。假設首頁上有一段案例摘要，反例是這樣寫的：「這是我們近期完成的一個專案，詳情如上方所述。」這句話完全依賴上一段才看得懂「這個」指的是哪個專案，單獨抽出來連代理都讀不出主詞。
改成自足段落，同一段案例摘要會寫成：「這個電商平台的網站改版案，把結帳流程從五步簡化成三步，上線後棄單率下降了一截。」這一句話自己就把事情講完整，是誰、做了什麼、結果如何，具體事實擺在最前面，不必回頭找上一段才能理解，單獨被抽出來當一段答案用，一樣站得住腳。
懸停選單、動態效果裡的內容，AI 看得到嗎？
首頁常見的一些互動巧思，對只讀取程式碼結構、不會用滑鼠移過去試探的代理而言，風險比想像中大。滑鼠移過去才浮現的說明文字、要點開才展開的手風琴選單、版面會因為互動大幅位移的設計，這些手法對人類訪客也許是加分的細節，對代理來說卻可能等於這段內容根本不存在。
版面配置本身也要顧穩定。同一個按鈕在使用者滑動或點擊之後跑到不同位置，人類靠肌肉記憶還能適應，代理卻可能因此抓錯它在讀的是哪個元素。另一個常被忽略的風險是「幽靈」元素，視覺上看起來透明、看不見，但節點其實還佔著位置，代理可能誤判成一個可以互動的空白區域；反過來，也有節點已經從無障礙樹裡消失，畫面卻假裝它還在的情況，兩種都會讓代理讀到跟畫面對不上的資訊。
可互動元素本身的可視面積也有門檻，web.dev 建議大約要有 8 平方像素以上，太小的圖示或連結容易在視覺分析階段被直接濾掉，等於白費工夫。而所有動態效果裡最根本的風險，還是核心內容要等前端 JavaScript 執行完才出現。首頁真正重要的資訊分區，像提供什麼服務、聯絡方式、主要賣點，不該只靠這些互動效果才「看得到」，應該確保它們本來就寫在頁面結構裡，不需要任何互動或程式執行就已經存在。
連結文字含糊不清，AI 就不知道能做什麼
每個內容分區講完自己的重點之後，通常會留一個出口，像導覽列的項目、分區底下「了解更多」的按鈕、表單旁邊的送出鍵。這些出口的錨點文字，如果只寫「點這裡」「了解更多」這種空泛用語，人類訪客靠著上下文還能猜個大概，但 AI 代理讀到的只是一個沒有具體名稱的連結節點，不知道點下去會發生什麼事。
WebAIM Million 2026 這份針對全球前 100 萬個首頁的研究報告，把這個問題攤在陽光下：
| 缺失類型 | 佔首頁比例 |
|---|---|
| 讀不出目的地的空連結 | 46.3% |
| 讀不出功能的空按鈕 | 30.6% |
| 缺少表單欄位標籤 | 51% |
| 缺少圖片替代文字 | 53.1% |
2026 年這份報告更出現六年來首次「惡化」，不符合 WCAG 無障礙規範的首頁比例從前一年的 94.8% 升到 95.9%，每個首頁平均檢測到的錯誤數也增加了 10.1%。Search Engine Journal 把這種空連結形容成一扇沒有招牌的門，人類訪客還能靠上下文猜，對 AI 代理而言，等於一條走不通的路。
要修正這件事，先從錨點文字本身下手，把「了解更多」換成講清楚目的地的說法，像「查看網站改版服務方案」「填寫免費諮詢表單」，代理讀到的就是一段可以直接對應到動作與去向的具體資訊。W3C 在 ARIA 使用指南裡的第一原則，是能用原生 HTML 元素做到的語意，就不要另外加 ARIA 屬性硬湊。原生的 <button> 與 <a> 天生就會被判讀為可互動的元素，用 <div> 或 <span> 改造出來的假按鈕，代理讀到的只是一段普通文字，不知道那其實是可以按的東西。表單欄位也一樣，web.dev 特別提到，每個輸入框都要有對應的 <label>，並且用 for 屬性明確連結到那個欄位，代理才知道這一格是要填姓名、電話，還是電子郵件。
首頁要不要為 AI 另外做一個版本？
看完前面幾節，很自然會冒出一個念頭，乾脆做一份「給 AI 看」的首頁分身，或去研究 llms.txt 這類清單檔，是不是比較省事？這篇的立場是不需要。
第一個理由，是無障礙樹本來就是瀏覽器直接從你已經在維護的那份首頁算出來的，不是另外要生產的東西。維護一份平行的機器專用內容，反而製造出「兩份內容講的不一樣」的風險。Search Engine Journal 就指出，像另外做一份 markdown 副本這種做法，只能傳達文字，沒辦法讓代理操作頁面上的按鈕或表單。一旦首頁改版忘了同步更新那份副本，代理讀到的資訊就跟真正的頁面對不上，這件事本身也是白忙一場。
第二個理由，是像 llms.txt 這類清單檔，目前並沒有主要 AI 廠商公開證實會拿來當作判斷網站內容的依據。投入心力寫這類清單檔之前，應該先把同一份首頁的語意結構做紮實，標題階層、自足段落、講清楚目的地的連結文字，這些才是前面幾節談的、對每一種讀者都有用的地基。把力氣放回這裡，才是對人、對 AI 都划算的做法，這也是為什麼這篇從頭到尾沒有談結構化資料標記這類技術性做法，先把版面與內容分區的地基顧好，才輪得到下一層的技術工程。
標題階層分得清楚、連結文字講得出目的地、核心資訊不必靠互動效果才能被看見，這些本來就是把一個網站做紮實該補的功課，不是為了討好一批新訪客才臨時加開的特例。AI 代理的出現，只是讓「這個網站的結構扎不扎實」這件事，變成現在最先被檢驗的一關。
Google 與 Microsoft 已經在推動一套讓網站直接對代理開放操作介面的新標準，叫 WebMCP，目前還在 W3C 討論階段。但不管這類標準最後走到哪一步，它要成立的地基，都還是一個結構清楚、語意明確的頁面，這也是 AI 瀏覽首頁內容結構從頭到尾真正要顧的事。