我看過太多網站把最值錢的資訊做成一張漂亮的圖，然後很困惑為什麼搜尋引擎抓不到、使用者也記不住。做 SEO 快二十年，我常提醒團隊一句話：能被讀者掃、也能被爬蟲讀的資訊，才算真的存在。表格、清單、定義列表這三種語意化標籤，就是把資訊同時擺給人和機器看的最省力做法。這篇我把「什麼時候用哪一種」講清楚，並附上可以直接照抄的語意化範例，讓你不再靠一張圖片賭運氣。
一、為什麼重要資訊不能做成圖片
先講最核心的原則：文字資訊要用文字標籤呈現，不要塞進圖片。這不是美感問題，而是可讀性問題。一旦重要內容被壓成圖，搜尋引擎讀到的就只是一個檔名，讀者也無法複製、無法縮放、在手機上還可能糊掉。
1. 搜尋引擎讀不到圖裡的字
用「檢視原始碼」看你的頁面，如果一段營業時間或價目只以圖片存在，原始碼裡就只有一行 img 標籤，沒有任何可讀文字。這代表搜尋引擎最先讀到的版本裡，這塊資訊是空的。替代文字能補一點描述，但它是給無法載入圖片時用的簡短說明，塞不下一整張表的內容，也不該拿來堆關鍵字。
2. 讀者其實是在「掃」不是在「讀」
我做過不少頁面的觀察，使用者面對一大段文字時很少逐字看，而是快速掃過找他要的那一格。價格、時間、規格、步驟這類資訊，做成表格或清單能讓人在幾秒內定位，做成一整段文字或一張圖反而拖慢他。掃得快，跳出的機率就低。
3. 我踩過的坑：把價目表做成一張精緻的圖
早年我協助一個居家服務品牌，設計師把方案價目做成一張很好看的長圖，視覺滿分。問題是那頁想搶的正是「某某服務費用」這類關鍵字，而頁面原始碼裡完全沒有價格文字。我們把圖換成一張 HTML 表格、保留同樣的視覺樣式後，那頁在相關字的表現才開始有起色。好看和可被讀取，本來就可以同時成立。
二、table、ul、dl：三種標籤各自的適用時機
這三種標籤常被混用，但它們的語意不同，選對了內容才會被正確理解。判斷方式其實很直覺：看你的資訊有沒有欄位、有沒有順序、是不是成對的解釋。
1. table 用於「有欄位、需對照」的二維資料
只要資訊天生是「橫向有欄位、縱向有多筆」需要互相對照的，就用表格。價目表、規格對照、營業時間、方案比較都屬於這一類。表格的好處是欄與列的關係清楚，搜尋引擎能理解哪一格對應哪個標題，讀者也能沿著同一列看完一筆完整資訊。記得補上 thead 與 th，讓標題列有明確語意，而不是全部用一般儲存格。
2. ul 或 ol 用於「同一層級的並列項目」
當資訊是一串平行的要點、沒有欄位對照關係時，用清單。沒有先後順序的用無序清單，有明確步驟或排名的用有序清單。像是服務特色、注意事項、導入步驟，用清單比塞成一長段更好掃。要避免的錯誤，是把本來該有欄位對照的資料硬拆成清單，讀者反而看不出彼此的關係。
3. dl 用於「名詞加解釋」的成對資訊
定義列表常被忽略，但它很適合「一個詞配一段說明」的結構，例如名詞解釋、規格項目說明、常見問題的問與答。它用 dt 放名詞、dd 放解釋，語意上明確表達「這是一組定義」。這種成對關係若只用一般段落寫，機器就得靠猜；用定義列表則一目了然。
| 資料長相 | 該用的標籤 | 典型例子 | 常見誤用 |
|---|---|---|---|
| 有欄位、要對照的二維資料 | table | 價目表、規格比較、營業時間 | 做成圖片或用 div 排版硬拼 |
| 同層級的並列要點 | ul（無序） | 服務特色、注意事項 | 把該對照的資料拆成單欄清單 |
| 有先後或排名的步驟 | ol（有序） | 導入流程、操作步驟 | 用無序清單掩蓋了順序 |
| 名詞配解釋的成對資訊 | dl | 名詞解釋、規格說明 | 全部塞進一段文字 |
三、可掃讀又能被抓取的語意化範例
原則講完，直接看該怎麼寫。以下範例都刻意保留最基本的結構，你可以套上自己的樣式，視覺不受影響，但語意先站穩。
1. 營業時間用 table，別用一張圖
時間表是最常被做成圖片的重災區。改用表格後，原始碼裡就有完整可讀的文字，也方便日後補上營業時間的結構化資料，讓搜尋引擎在無法完整解析畫面時，仍能理解你的營業時間。
<table>
<thead>
<tr><th>星期</th><th>營業時間</th></tr>
</thead>
<tbody>
<tr><td>週一至週五</td><td>09:00 - 18:00</td></tr>
<tr><td>週六</td><td>10:00 - 15:00</td></tr>
<tr><td>週日</td><td>公休</td></tr>
</tbody>
</table>2. 步驟用 ol，特色用 ul
有順序的流程用有序清單，讀者知道要照著做；沒順序的特色用無序清單，讀者知道這些是並列的。這樣連螢幕閱讀器都能正確念出結構。
<ol>
<li>線上預約並填寫需求</li>
<li>到府或線上場勘評估</li>
<li>提供拆項報價與確認</li>
</ol>
<ul>
<li>報價事前透明</li>
<li>流程標準化</li>
<li>完工後驗收機制</li>
</ul>3. 名詞解釋用 dl
名詞與解釋的成對關係，用定義列表最貼切。它的語意比一連串「粗體名詞加一段文字」更明確，也讓內容在被 AI 搜尋拆解引用時更容易對得上。
<dl>
<dt>伺服器端渲染</dt>
<dd>頁面在伺服器就把內容生好再送出，原始碼裡即有完整文字。</dd>
<dt>前端渲染</dt>
<dd>初始原始碼幾乎是空的，內容要等程式在瀏覽器執行後才出現。</dd>
</dl>最後分享一個我每次交付前一定會做的動作。我都會請團隊用「檢視原始碼」而不是「檢查元素」去看那些關鍵資訊區塊。這兩個看到的東西不一樣：檢視原始碼是搜尋引擎最先讀到的初始 HTML，檢查元素是程式跑完後的畫面。若價目、時間、規格在檢視原始碼裡看不到文字，代表它們只活在前端，搜尋引擎讀不到。這個五秒鐘的檢查，能擋掉很多把資訊做成圖或靠程式後補的問題。我也遇過表格文字明明在畫面上看得到、原始碼裡卻是空的情況，那通常是內容被程式在瀏覽器端後補進去的，這種區塊即使做成表格也等於白做，因為搜尋引擎最初讀到的版本裡它並不存在。碰到這種狀況，要嘛讓伺服器先把內容產好，要嘛至少補上對應的結構化資料當備援。
四、常見問題
把資訊做成表格，會不會影響手機上的排版？
不會，前提是你有做好響應式處理。表格本身是語意結構，樣式可以另外用 CSS 控制，例如在窄螢幕改變顯示方式。真正該避免的是為了排版好看而放棄表格、改用圖片，那才是把可讀性犧牲掉了。
用 div 加樣式排出看起來像表格的版面，也可以嗎？
視覺上可以，語意上不建議。搜尋引擎與輔助技術靠標籤理解關係，用 div 拼出來的表格沒有欄列語意，機器不知道哪格對應哪個標題。真的是二維對照資料，就用 table，別為了彈性犧牲語意。
清單項目很多，會不會被當成內容灌水？
重點不在數量，而在每一項有沒有實質資訊。若清單只是把一句話拆成十個沒內容的短句，那確實沒價值；若每一項都是讀者真正需要的要點，長一點也無妨。與其糾結項數，不如檢查每項是否言之有物。我的判斷方式是把清單念一遍，如果拿掉某一項讀者會漏掉關鍵資訊，那它就該留；如果拿掉也沒差，那它本來就是湊數。清單是幫讀者省時間的工具，不是拿來衝篇幅的。
alt 替代文字可以拿來補圖片裡的表格內容嗎？
不適合。替代文字是圖片的簡短描述，用來在圖片無法顯示時說明它是什麼，塞不下也不該塞一整張表的資料。正確做法是根本不要把表格做成圖片，直接用 HTML 表格呈現，替代文字回歸描述圖片本身。
2026 年 AI 搜尋盛行，語意化標籤還重要嗎？
更重要。AI 搜尋在引用時傾向抓取結構清楚、能被段落化拆解的內容。一張表格或一組定義列表，比一段糊在一起的長文更容易被正確理解與引用。把資訊用對的標籤整理好，對傳統搜尋和 AI 搜尋都是同一份投資。