把營業時間、價目、規格這類資訊做成一張漂亮的圖片，是我們最常看到、也最可惜的一個錯誤。結論先說：文字資訊就要用文字標籤呈現，能被讀者一眼掃到、也能被搜尋引擎完整讀取的資料，才算真的存在。表格、清單、定義列表這三種語意化標籤，正是把同一份資訊同時擺給人和機器看的最省力做法。這篇我們把「什麼時候該用哪一種」講清楚，並附上可以直接照抄的語意化範例，也把交付前的驗收動作一併寫出來，讓你不再靠一張圖片賭運氣。
1. 為什麼重要資訊做成圖片會讓流量受損
先把最核心的原則立起來：文字資訊要用文字標籤呈現，不要塞進圖片。這不是美感問題，而是可讀性問題。一旦關鍵內容被壓成一張圖，搜尋引擎讀到的就只是一個檔名，讀者也無法複製、無法縮放，在手機上還可能糊掉。我們在診斷網站時，常常第一眼就看到這種把資產藏起來的做法，而且它往往發生在最值錢的頁面上，像是價目、方案、規格這些能直接帶來詢問的區塊。
1.1 搜尋引擎讀到的只是一個檔名
用「檢視原始碼」看你的頁面，如果一段營業時間或價目只以圖片存在，原始碼裡就只有一行 img 標籤，沒有任何可讀文字。這代表搜尋引擎最先讀到的版本裡，這塊資訊是空的。替代文字能補一點描述，但它是給無法載入圖片時用的簡短說明，塞不下一整張表的內容，也不該拿來堆關鍵字。換句話說，圖片裡的文字對搜尋引擎而言幾乎等於不存在，你花心力整理的資料，在它眼中只是一個沒有內容的方框。
1.2 讀者其實是在掃而不是在讀
根據我們的服務經驗，使用者面對一大段文字時很少逐字看，而是快速掃過，找他要的那一格。價格、時間、規格、步驟這類資訊，做成表格或清單能讓人在幾秒內定位；做成一整段文字或一張圖，反而拖慢他。掃得快，跳出的機率就低。這是內容呈現方式直接影響停留時間的地方，和文案寫得好不好是兩回事。一個資訊能不能在三秒內被找到，往往決定了讀者要不要繼續往下看。
1.3 我們踩過的坑：把價目表做成一張精緻的圖
早年我們協助一個居家服務品牌，設計師把方案價目做成一張很好看的長圖，視覺滿分。問題是那頁想搶的正是「某某服務費用」這類關鍵字，而頁面原始碼裡完全沒有價格文字。我們把圖換成一張 HTML 表格、保留同樣的視覺樣式後，那頁在相關字的表現才開始有起色。好看和可被讀取，本來就可以同時成立，不必二選一。這個案例後來變成我們的固定提醒：凡是想被搜到的資訊，先問一句「它在原始碼裡是文字嗎」。
1.4 文字標籤還順手解決了複製與無障礙
除了被搜尋引擎讀到，用文字標籤呈現還有兩個常被忽略的好處。一是使用者能直接複製，想記下營業時間或把價格貼給家人時不必重打；做成圖片的資訊，他只能自己抄，體驗差上一截。二是螢幕閱讀器能正確念出表格的欄列與清單的項目，對仰賴輔助技術的使用者才友善，而無障礙本身也是搜尋引擎在意的品質訊號之一。同一個決定，同時照顧到機器、一般讀者和無障礙使用者，這是把資料做成圖片時拿不到的。
2. 三種標籤各自的適用時機
table、清單、定義列表常被混用，但它們的語意不同，選對了內容才會被正確理解。判斷方式其實很直覺：看你的資訊有沒有欄位、有沒有順序、是不是成對的解釋。下面先把三種情況拆開講，再用一張表收斂。這套判斷不需要你懂程式，只要能描述資料的長相就能套用。
2.1 table 用於有欄位、需對照的二維資料
只要資訊天生是「橫向有欄位、縱向有多筆」需要互相對照的，就用表格。價目表、規格對照、營業時間、方案比較都屬於這一類。表格的好處是欄與列的關係清楚，搜尋引擎能理解哪一格對應哪個標題，讀者也能沿著同一列看完一筆完整資訊。記得補上 thead 與 th，讓標題列有明確語意，而不是全部用一般儲存格，否則機器仍得靠猜。一個簡單的自我檢查是：如果你要口頭描述這份資料，得一直說「在哪一欄、第幾列」，那它就該是表格。
2.2 ul 或 ol 用於同一層級的並列項目
當資訊是一串平行的要點、沒有欄位對照關係時，用清單。沒有先後順序的用無序清單，有明確步驟或排名的用有序清單。像是服務特色、注意事項、導入步驟，用清單比塞成一長段更好掃。要避免的錯誤，是把本來該有欄位對照的資料硬拆成清單，讀者反而看不出彼此的關係。清單和表格的分界，就在於資料之間有沒有欄位對應；只要每一項各自獨立、不需要和其他項目對齊比較，清單就夠用了。
2.3 dl 用於名詞加解釋的成對資訊
定義列表常被忽略，但它很適合「一個詞配一段說明」的結構，例如名詞解釋、規格項目說明、常見問題的問與答。它用 dt 放名詞、dd 放解釋，語意上明確表達「這是一組定義」。這種成對關係若只用一般段落寫，機器就得靠猜；用定義列表則一目了然。這三種標籤的分工，可以用下面這張表快速對照。
| 資料長相 | 該用的標籤 | 典型例子 | 常見誤用 |
|---|---|---|---|
| 有欄位、要對照的二維資料 | table | 價目表、規格比較、營業時間 | 做成圖片或用 div 排版硬拼 |
| 同層級的並列要點 | ul（無序） | 服務特色、注意事項 | 把該對照的資料拆成單欄清單 |
| 有先後或排名的步驟 | ol（有序） | 導入流程、操作步驟 | 用無序清單掩蓋了順序 |
| 名詞配解釋的成對資訊 | dl | 名詞解釋、規格說明 | 全部塞進一段文字 |
2.4 一個不用懂程式的快速選擇流程
如果不想記三種標籤的名字，可以用一串問句替自己做決定。第一問：這份資料需不需要橫向欄位和縱向多筆互相對照？需要就是表格。第二問：如果不是，那它是一串平行的要點嗎？是的話就用清單，再看有沒有先後順序決定有序或無序。第三問：如果它是「一個詞配一段解釋」的成對結構，就用定義列表。三個問題走下來，大多數內容都能對上合適的標籤，剩下真的難分的少數，再回頭看它最像哪一種。這個流程我們也常交給客戶的編輯自己跑，不必等工程師就能先把結構定好。
3. 可掃讀又能被抓取的語意化範例
原則講完，直接看該怎麼寫。以下範例都刻意保留最基本的結構，你可以套上自己的樣式，視覺不受影響，但語意先站穩。實務上我們會建議先把結構寫對，再交給設計師調整外觀，順序別顛倒，否則很容易為了視覺又把語意蓋掉。
3.1 營業時間用 table，別用一張圖
時間表是最常被做成圖片的重災區。改用表格後，原始碼裡就有完整可讀的文字，也方便日後補上營業時間的結構化資料，讓搜尋引擎在無法完整解析畫面時，仍能理解你的營業時間。下面這段是最精簡的寫法，你只要把內容換成自己的，再用 CSS 調整外觀即可。
<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>3.2 步驟用 ol，特色用 ul
有順序的流程用有序清單，讀者知道要照著做；沒順序的特色用無序清單，讀者知道這些是並列的。這樣連螢幕閱讀器都能正確念出結構，對仰賴輔助技術的使用者也更友善。一個常見的錯用，是把導入步驟也做成無序清單，結果讀者看不出第幾步先做、第幾步後做；反過來把並列的特色編上號碼，又會讓人誤以為有優先順序。兩者的差別只在你的資料有沒有先後，寫法如下。
<ol>
<li>線上預約並填寫需求</li>
<li>到府或線上場勘評估</li>
<li>提供拆項報價與確認</li>
</ol>
<ul>
<li>報價事前透明</li>
<li>流程標準化</li>
<li>完工後驗收機制</li>
</ul>3.3 名詞解釋用 dl
名詞與解釋的成對關係，用定義列表最貼切。它的語意比一連串「粗體名詞加一段文字」更明確，也讓內容在被 AI 搜尋拆解引用時更容易對得上。當一個問題的答案本身就是「某個詞等於某段解釋」，AI 在生成回答時比較容易直接取用這組對應，而不必從一整段敘述裡重新拆。以渲染方式的解釋為例，可以這樣寫。
<dl>
<dt>伺服器端渲染</dt>
<dd>頁面在伺服器就把內容生好再送出，原始碼裡即有完整文字。</dd>
<dt>前端渲染</dt>
<dd>初始原始碼幾乎是空的，內容要等程式在瀏覽器執行後才出現。</dd>
</dl>4. 一個頁面同時要用多種標籤時怎麼安排
實際的頁面很少只用一種標籤。一個服務頁可能上面是方案比較表、中間是服務特色清單、下面是常見問題的定義列表。這時候的關鍵不是選一種用到底，而是讓每一塊資訊各自用最貼近它語意的標籤。我們診斷過的案例中，排版混亂的頁面通常不是標籤太多，而是用錯了標籤。
4.1 先拆解資訊的形狀，再決定標籤
動手前，我們習慣把一頁的內容先拆成幾個區塊，逐塊問：這是要對照的二維資料、平行的要點、還是成對的解釋。拆解這一步看似多餘，卻能避免整頁都用同一種標籤硬套。一個常見的反例，是把方案比較也做成清單，讀者就得在腦中自己對齊各方案的欄位，負擔反而更重。先認清形狀，標籤自然就定了。
4.2 巢狀使用時保持層級乾淨
清單裡還可以再包清單，表格的儲存格裡也能放短清單，但層級要保持乾淨。我們的原則是巢狀最多兩層，再深下去讀者和機器都容易迷路。如果你發現一個結構要包到三四層才講得清楚，通常代表這塊內容本身需要先拆成幾個段落，而不是靠更深的巢狀去硬撐。結構是幫忙理解的工具，不該反過來變成負擔。
4.3 別用標籤去做視覺效果
有一種常見誤用，是因為表格有格線、看起來整齊，就拿它來排本來不是表格的內容；或反過來，為了去掉格線而放棄表格。這些都是把語意拿去換視覺。正確的順序是先依資料形狀選標籤，視覺一律交給 CSS 處理。這樣不管外觀怎麼改，搜尋引擎讀到的語意都穩定，日後換版型也不會把結構一起打掉。
5. 交付前一定要做的原始碼驗收
標籤選對只是第一步，還要確認這些文字真的進到搜尋引擎讀得到的版本裡。我們每次交付前一定會做一個動作，花不到一分鐘，卻能擋掉很多白做工的情況。很多團隊在編輯器裡把表格排得漂漂亮亮，就以為大功告成，卻沒回頭確認它在伺服器送出的那一份 HTML 裡到底長什麼樣；驗收這一步，就是補上這個容易被跳過的缺口。
5.1 檢視原始碼和檢查元素看到的不一樣
我們都會請團隊用「檢視原始碼」而不是「檢查元素」去看那些關鍵資訊區塊。這兩個看到的東西不一樣：檢視原始碼是搜尋引擎最先讀到的初始 HTML，檢查元素是程式跑完後的畫面。若價目、時間、規格在檢視原始碼裡看不到文字，代表它們只活在前端，搜尋引擎讀不到。這個差別很多人分不清，卻正是許多「畫面有、排名卻起不來」問題的根源。
5.2 表格文字在畫面上卻不在原始碼怎麼辦
我們也遇過表格文字明明在畫面上看得到、原始碼裡卻是空的情況。那通常是內容被程式在瀏覽器端後補進去的，這種區塊即使做成表格也等於白做，因為搜尋引擎最初讀到的版本裡它並不存在。碰到這種狀況，要嘛讓伺服器先把內容產好，要嘛至少補上對應的結構化資料當備援，讓語意不至於完全遺失。這也是為什麼渲染方式和內容能不能被讀到，往往是同一個問題的兩面。
5.3 一個五秒鐘的驗收習慣
這個五秒鐘的檢查，能擋掉很多把資訊做成圖、或靠程式後補的問題。具體做法是：開啟頁面按檢視原始碼，用瀏覽器內建搜尋去找畫面上看得到的那段關鍵文字，找得到就代表伺服器有送出、搜尋引擎讀得到；找不到就代表那塊只活在前端，需要調整。把它變成交付前的固定動作，比上線後才發現抓不到省事得多。我們會要求每一個要被搜到的區塊都通過這一關，再簽字交付。
6. 常見問題
6.1 把資訊做成表格，會不會影響手機上的排版
不會，前提是你有做好響應式處理。表格本身是語意結構，樣式可以另外用 CSS 控制，例如在窄螢幕改變顯示方式，或讓過寬的表格可以橫向捲動。真正該避免的是為了排版好看而放棄表格、改用圖片，那才是把可讀性犧牲掉了。語意和外觀可以分開處理，不必互相讓步。
6.2 用 div 加樣式排出看起來像表格的版面，也可以嗎
視覺上可以，語意上不建議。搜尋引擎與輔助技術靠標籤理解關係，用 div 拼出來的表格沒有欄列語意，機器不知道哪一格對應哪個標題。真的是二維對照資料，就用 table，別為了彈性犧牲語意。若只是版面需要分欄，而內容本身不是對照關係，那用 div 排版沒問題，重點仍是回到資料的形狀來判斷。
6.3 清單項目很多，會不會被當成內容灌水
重點不在數量，而在每一項有沒有實質資訊。若清單只是把一句話拆成十個沒內容的短句，那確實沒價值；若每一項都是讀者真正需要的要點，長一點也無妨。我們的判斷方式是把清單念一遍，如果拿掉某一項讀者會漏掉關鍵資訊，那它就該留；如果拿掉也沒差，那它本來就是湊數。清單是幫讀者省時間的工具，不是拿來衝篇幅的。與其糾結項數，不如逐項檢查每一條是不是言之有物。
6.4 替代文字可以拿來補圖片裡的表格內容嗎
不適合。替代文字是圖片的簡短描述，用來在圖片無法顯示時說明它是什麼，塞不下也不該塞一整張表的資料。正確做法是根本不要把表格做成圖片，直接用 HTML 表格呈現，替代文字則回歸描述圖片本身。把一整張表的文字硬塞進替代文字，既不符合它的用途，也無助於讀者理解。
6.5 到了 AI 搜尋盛行的 2026 年，語意化標籤還重要嗎
可以說更重要。AI 搜尋在引用時傾向抓取結構清楚、能被段落化拆解的內容。一張表格或一組定義列表，比一段糊在一起的長文更容易被正確理解與引用。把資訊用對的標籤整理好，對傳統搜尋和 AI 搜尋通常是同一份投資，雖然最後成效也會受內容品質與需求熱度等其他因素影響。
6.6 舊文章已經用圖片呈現表格，值得回頭改嗎
如果那頁本來就想搶價格、規格、時間這類關鍵字，通常值得。我們會優先處理有排名基礎、卻因為關鍵資訊藏在圖裡而表現卡住的頁面，把圖換成 HTML 表格，往往比重寫一篇新文章見效更快。至於流量本就極低、主題也不重要的頁面，可以排在後面再處理，先把力氣花在最可能回收的地方。
6.7 表格欄位很多，手機上放不下怎麼辦
先別急著改回圖片。欄位多的表格在手機上可以讓它橫向捲動，或把次要欄位收起、只留最關鍵的幾欄，這些都屬於外觀層的處理，用 CSS 就能做到，語意結構仍然完整。我們的經驗是，真正讓手機表格難用的，多半不是欄位多，而是一開始就把整張表做成圖，使用者連放大看清楚都辦不到。先保住文字結構，再針對小螢幕調整呈現，順序別弄反。