WordPress 表格製作指南：Ninja Tables 實戰教學

如果要把五十列規格放上網站，WordPress 內建表格缺少排序、搜尋與資料管理，很快就會碰到限制。開工前先分清楚：這張表是靜態展示、結構化比較，還是動態資料表。這篇用這套分類挑工具，再把 Ninja Tables 從安裝一路帶到上線，並說明 SEO、手機體驗、速度與無障礙的注意事項。外掛整體取捨可對照 WordPress 外掛清單。

快速總覽：資料量小、不會變動的表，用 Gutenberg 內建表格區塊就夠；一旦需要排序、篩選、搜尋、大量資料或可重複使用的資料來源，就值得裝 Ninja Tables。它是一款在 WordPress.org 外掛目錄上架、活躍安裝量超過十萬的免費表格工具。真正的關鍵在於你能不能在開工前說出這張表的「類型與壽命」，挑哪款外掛反而是次要問題。

為什麼 WordPress 內建表格，做到一半就不夠用

WordPress 從 5.x 之後，Gutenberg 編輯器就內建了表格區塊。對一張五列四欄、放上去就不再動的「課程時間表」來說，它完全勝任。問題出在你開始對它有期待的那一刻。

實際專案裡最常聽到的抱怨整理如下，你會發現這些其實是表格放到真實網站上幾乎一定會遇到的事，夠不上什麼進階需求：

你想要做的事	Gutenberg 內建表格	你需要的是
點欄位標題就能排序	做不到	前端的排序功能
輸入關鍵字即時篩選	做不到	前端的搜尋框
資料超過一百列仍要好維護	要在編輯器裡手動拉列，痛苦	獨立的資料表管理介面
同一份資料在多個頁面重複使用	每頁都要重打一次	可重複插入的資料來源
從 Excel 或 CSV 匯入	沒有原生支援	匯入工具
手機上不擠成糊一團	要自己寫 CSS	內建的響應式模式

換句話說，內建表格是「排版工具」，不是「資料工具」。它處理的是格子要長怎樣，資料要怎麼流動並不在它的職責裡。當你的需求跨過「排版」這條線、進到「資料」的領域，就是表格外掛該上場的時候。這條界線很清楚，不需要記什麼外掛排行榜。

如果你連 Gutenberg 區塊本身都還不熟，我會建議先回到區塊編輯器外掛的基礎認識，把內建能做的事摸到底，再判斷缺口在哪。多數人裝了一堆外掛，最後發現內建其實做得到，只是沒人告訴他怎麼用。

先分類再選工具：三種表格，三種完全不同的需求

這裡要帶你看的，是最重要的判斷框架。你只要在開工前問自己一個問題：這張表，未來一年會被改幾次？答案直接決定你該用什麼工具，也決定你會不會在三個月後被維護地獄淹沒。

第一種：靜態展示表

放上去就幾乎不再動。典型的像「公司營業時間」、「團隊成員名單」、「某次活動的獎項列表」。這類表的壽命長、變動頻率低、資料量小。它的重點是好看的排版，強大的資料管理對它只是負擔。

工具選擇：Gutenberg 內建表格區塊就夠了。不值得為了這種表多裝一個外掛、多一個資料庫表、多一個要更新的元件。維護成本是隱形的帳單，能不開就不開。我自己的原則是：如果一張表全年只會被改兩次，它就只配用內建區塊，任何外掛的安裝與更新成本都會壓過它帶來的便利。

第二種：結構化比較表

資料會更新，而且讀者需要「找」。典型的像「產品規格比較」、「方案與價格對照」、「不同廠牌功能矩陣」。這類表的核心價值在於讀者能依照自己的需求排序、篩選，例如把價格由低到高排、或只看某個材質。它已經跨進「資料」的領域了。

工具選擇：這是 Ninja Tables 這類表格外掛適合的情境。你需要獨立資料管理、前端排序與搜尋，以及一份資料在多頁重用的能力。

第三種：動態資料表

資料來自外部系統、會持續變動、甚至需要讓前端使用者互動式查詢。例如庫存即時數字、從 ERP 同步過來的報價、會員可查詢的訂單紀錄。這類表的本質其實是一個「小型的資料應用」，層級完全不同於一篇文章裡的表格。

工具選擇：免費的表格外掛通常只能做到「把靜態資料排好看」，碰到真正的動態資料來源多半要付費方案或客製整合。我會誠實提醒你：這個領域沒有便宜又強大的銀彈，把需求講清楚再找工具，比相信任何一款外掛的官網文案更重要。很多時候，動態資料表真正的瓶頸是「你的資料要從哪裡來、多久同步一次、誰負責維護它的正確性」，這些問題的答案跟外掛無關，跟你公司的資料流程有關。

把這三種分類記下來，「該不該裝外掛」通常就比較容易回答。拿靜態需求硬上動態方案會增加維護，拿動態需求勉強靜態區塊則容易失控。

Ninja Tables 在這盤棋裡的位置

講完分類，你可以很清楚看到 Ninja Tables 適合的位置：它專門服務「結構化比較表」這個最大宗、也最尷尬的中間地帶。這一帶的需求，內建區塊做不到、重型動態方案又殺雞用牛刀。

它在 WordPress.org 外掛目錄上架、有免費版本、活躍安裝量超過十萬，是一套能在獨立的後台介面裡管理表格資料的工具（見 Ninja Tables 的 WordPress.org 外掛頁）。跟內建表格最大的差別，在於它把「資料」與「版面」拆開：你在後台維護一份資料表，再用 shortcode 或專屬區塊把它插到任何頁面。同一份規格表，可以同時出現在商品頁、分類頁、比較頁，改一次全部同步。

我會用它，通常是因為專案出現三個訊號的其中一個：

• 資料量大到在編輯器裡手key會出錯：例如二、三十個 SKU 的規格矩陣，用內建表格拉列拉到眼花，Ninja Tables 讓你在表格介面裡編輯，接近試算表的操作感。
• 讀者需要排序或搜尋：價格由低到高、只看有庫存的品項，這些是結構化比較表的基本動作，也是轉換率會誠實反映的地方。
• 同一份表要在多頁出現：一份運費對照表，同時出現在結帳頁、FAQ、商品頁，單一資料來源才不會出現三個版本互相打架。

反過來說，如果你的需求不在這三個訊號裡，Ninja Tables 對你就是多餘的。工具的好壞永遠綁定場景，跟它在官網上的星星數沒有關係。我寧可你先懷疑「我真的需要它嗎」，也不要你裝了之後才發現一年沒開過幾次。

從零開一張表：Ninja Tables 實戰流程

這裡帶你走一次最常見的流程：從安裝、建表、匯入資料、到把表嵌進頁面。如果你還沒裝過任何 WordPress 外掛，先看過外掛安裝的三種方法會比較踏實，後台的路徑會對得上。

第一步：安裝並啟用

在後台「外掛 → 安裝外掛」搜尋 Ninja Tables，安裝並啟用即可。免費版的功能對第二種「結構化比較表」的需求已經夠用，不需要一開始就碰付費方案。先把基礎流程跑通，再判斷付費功能是否真的解決你的瓶頸，這個順序很重要。很多網站是先買了單，才發現自己根本用不到那些進階欄位，錢花下去卻沒有對應的場景把它用回本。

第二步：新增表格與欄位

啟用後，後台選單會出現 Ninja Tables 的專屬項目。新增一張表格時，你要先想清楚欄位結構，資料晚點再填沒關係。欄位型態決定這個欄位能做什麼：文字欄位、數字欄位、日期欄位、圖片欄位各有不同用途。數字欄位之所以重要，是因為它決定前端能不能正確排序，這是新手最容易踩的坑，把價格設成文字欄位，結果「900」排在「1200」後面，因為字串比對是看第一個字元。

欄位型態選錯，排序就全毀

這個坑太常見，值得單獨拉出來講。表格的排序邏輯完全取決於欄位的資料型態，設錯了，前端就會出現荒謬的順序。我整理了一張對照，讓你在建表時就避開：

資料性質	應設的欄位型態	設錯會出現的症狀
價格、數量、坪數	數字欄位	設成文字時，「1200」會排在「900」前面
日期、活動時間	日期欄位	設成文字時，排序會變成按月分的字串順序
產品圖、Logo	圖片欄位	設成文字時，只會顯示網址字串，不會渲染圖片
連結、按鈕	連結欄位或 HTML 欄位	設成純文字時，讀者看到的是原始網址而非可點連結

養成一個習慣：建表的第一件事是先把欄位型態定下來，第二件事才是填資料。順序顛倒，很可能填到一半才發現整批需要重做。這聽起來像常識，卻是表格排序、篩選或格式異常時很值得先檢查的地方。

第三步：把資料倒進去

資料量小的時候，直接在後台介面一列一列新增沒問題。但只要超過十幾列，我強烈建議用匯入功能。Ninja Tables 支援從 CSV 匯入資料，你的工作流程會變成：在 Excel 或 Google Sheets 裡整理好資料、另存成 CSV、再匯入到表格。這個習慣會救你很多次。試算表才是整理資料的地方，WordPress 後台不是。

多維護一份原始的試算表，還有一個額外好處：它是你最穩的備份。哪天網站出問題、或你要把表格搬到別的工具，手上有 CSV 就不怕失去資料。表格外掛的資料雖然也會被備份外掛一起備走，但它存在資料庫裡的形式不好直接閱讀，CSV 才是跨工具通用的中立格式。

第四步：打開排序、搜尋與篩選

這是結構化比較表的靈魂。在表格設定裡，你可以指定哪些欄位允許前端排序、是否顯示搜尋框、是否啟用依欄位篩選。我的建議是：不要全部打開。只給讀者真正會用的互動功能。一張表格如果同時開了排序、搜尋、分頁、篩選、匯出，介面會變成一個小型的資料庫主控台，嚇跑的讀者會比被幫助的多。我通常只開「排序」加「單一搜尋框」，篩選與匯出留給讀者真的有需求時再加，寧可少不可亂。

第五步：嵌進頁面

表格建好之後，Ninja Tables 會給你一組 shortcode，複製貼到任何文章或頁面就能顯示。它也提供 Gutenberg 區塊，讓你在編輯器裡直接選表格、預覽。把 shortcode 想成「這份資料的插入點」，你就能理解為什麼同一份資料可以出現在多個地方、改一次全部同步，因為資料只存在一個地方，頁面插的都只是它的參照。

讓表格「有人看得下去」的五個排版細節

表格做完了，不等於表格有人看。一份排序功能很強、但排版讓人眼睛吃力的表格，轉換效果往往輸給一張靜態、但層次清楚的手做表。這五個細節，是表格上線前該檢查的清單：

1. 欄位標題要夠短、夠白話。「產品代碼」比「SKU 識別碼」好懂；「每月價格」比「週期性費用方案」好懂。標題是掃讀的入口，不是術語展示場。
2. 數字靠右、文字靠左對齊。這是表格排版的潛規則，數字靠右對齊才能讓讀者直覺地比大小。很多外掛預設沒做對，你要手動調。
3. 用斑馬紋或間隔底色引導視線。資料列超過十列，沒有間隔底色就會讓眼睛在列與列之間迷路。這是最便宜的可用性提升。
4. 關鍵欄位放最左邊。讀者掃表格的視線是從左到右、從上到下，最重要的比較欄位（通常是產品名稱或方案名稱）要釘在最左欄，它捲動時最好能固定住。
5. 單位與貨幣要一致。同一張表裡一下出現「NT$1,200」、一下出現「1200元」、一下出現「$1200」，看起來就像三個不同的人拼裝出來的。統一格式是信任感的來源。

這些都不是 Ninja Tables 獨有的功能，任何表格外掛都該做得到。差別在於你有沒有在意。排版這件事，工具只給你選項，品味決定結果。如果你的版面觀念還在成形階段，網頁版面設計的完整攻略能幫你把表格放回整體架構裡看，避免孤立地盯著一張表。

手機上的表格只有兩條活路

表格是桌面思維的產物。螢幕夠寬，欄位才能橫向排開；一到手機上，四五個欄位硬塞進去，每個欄位被擠到剩下兩個字的寬度，整張表就報廢了。這不是外掛的問題，是表格這個格式本身的限制。在手機上，表格基本上只有兩條活路可選：

做法	原理	適合場景	缺點
橫向捲動	保留表格結構，超出寬度時讓使用者左右滑	讀者需要橫向比對欄位、資料結構不能拆	要給清楚的視覺提示，不然讀者不知道可以滑
卡片化變形	每一列資料重組成一張直立卡片，欄位名與值上下排列	欄位多、讀者以逐筆查看為主	失去橫向比對能力，桌機與手機呈現差異大

這兩條路沒有誰一定對，關鍵在你的讀者拿手機看這張表時，是要「比」還是要「查」。要比，就保留橫向結構、給清楚的捲動提示；要查，就拆成卡片、讓每一筆資料自成完整的閱讀單位。Ninja Tables 在響應式上有對應的設定，但最根本的原則跟任何表格都一樣：手機優先不是把桌機版縮小，而是為手機重新思考閱讀路徑。如果你想系統性地理解這套觀念，響應式網頁設計的完整指南是比外掛文件更值得讀的基礎。

表格會吃掉你的 SEO 分數嗎？Core Web Vitals 的真實影響

很多人不敢用表格外掛，是怕「外掛會拖慢網站」。這個擔心合理，但要拆開看。真正會拖垮分數的，多半是它在前端載入了多少 JavaScript 與 CSS，外掛本身反倒不是主因。Google 把這些體驗訊號整理成 Core Web Vitals，其中跟表格最相關的是 CLS（累計版面位移，Cumulative Layout Shift），白話說，就是頁面載入時元素會不會亂跳（見 Google 對 Core Web Vitals 的說明）。

表格若非同步載入且沒有預留空間，資料回來時突然長高，可能造成 CLS。排序與篩選通常發生在使用者操作後；在互動後短時間內預期發生的位移，通常不會計入 CLS，但仍可能影響使用體驗。重點是初始渲染與非預期位移。

所以評估一款表格外掛對 SEO 的影響，我會看三件事：

• 表格是否會在初始渲染就決定高度，避免等到資料或腳本載完才突然長大。
• 它載入的 JS 與 CSS 體積多大。一個表格功能不該載入一整套 UI 框架。
• 互動時會不會造成難以追蹤的版面跳動。這不一定計入 CLS，但仍要避免讓讀者失去目前位置。

若表格造成 CLS，可為載入區預留合理空間、延後非關鍵腳本，並對大量資料分頁或虛擬化。改善幅度要以實際頁面量測，不能預設固定百分比。

這些原則不只適用於 Ninja Tables，任何會在前端渲染互動元件的外掛都一樣。如果你發現裝了表格外掛之後，Core Web Vitals 的分數明顯下滑，第一步是先排查表格的載入方式有沒有造成位移，換外掛屬於之後才要考慮的事。多數時候，問題出在「表格放在太前面的摺疊之上位置、又沒有預留高度」，調整位置或預留空間就能改善大半。搭配一篇系統性的網站速度診斷與優化指南一起看，你會比較容易定位瓶頸到底在外掛、在主題、還是在主機。

順帶一提，如果你的網站已經裝了不少會在前端載入資源的外掛，表格類外掛更要挑輕量的。把快取、備份、表單、表格這些基礎外掛的體積一起算進去，整體前端資源才不會失守。快取與備份我也整理過快取外掛與備份外掛的選擇邏輯，這裡就不重複。

商品規格何時適合搬進 Ninja Tables

商品規格多時，把尺寸、材質、劑型、保固與運送條件散落在不同段落，讀者很難比對。可把穩定且適合橫向比較的欄位整理成可排序表格，並在商品頁或比較頁測試是否真的幫助理解；庫存與價格若即時變動，還要確認資料來源與更新機制。

實際的工作流程是這樣的：先把所有 SKU 的規格彙整到一份試算表，欄位型態先定好（尺寸是數字、材質是文字、保固是數字、運送條件是文字），整理乾淨之後匯出 CSV、匯入 Ninja Tables，再依需要打開排序與搜尋。之後只要規格有異動，改的就是那一份試算表，重新匯入一次，前端全部同步。這個流程的重點是「資料只有一份」，所有頁面看到的都來自同一個源頭，不會再出現商品頁寫 A、FAQ 寫 B、結帳頁寫 C 的悲劇。

這個案例的重點不在「Ninja Tables 有多強」，而在一個判斷：當商品頁的資訊密度成為轉換瓶頸時，結構化的表格比再加幾段文字更能解決問題。讀者要的是「能不能一次看完所有選項的差異」，而不是再讀三段介紹。回過頭，我前面花那麼多篇幅講分類，保健食品的規格表就是典型的「結構化比較表」，它天生就需要排序與篩選，硬要用內建表格做，等於把比較電商做成靜態海報。

如果你的站是跑 WooCommerce，商品頁的資訊架構還牽涉到 SEO 與轉換的雙重優化，表格只是其中一環。把表格跟商品頁 SEO 優化放在一起想，才不會出現「規格表好看了、但商品頁整體反而變難搜尋」的矛盾。

什麼時候你根本不該用 Ninja Tables

講了這麼多 Ninja Tables 的好，我也要誠實地把「不要用它」的情境講清楚。一個工具的價值，有一半來自知道什麼時候不要用。這幾種情況裡，裝它只會增加你的維護負擔，不會增加價值：

情境	為什麼不該用	該用什麼
一張三列兩欄、放上去就不動的表	需求是排版，外掛是殺雞用牛刀	Gutenberg 內建表格區塊
需要從外部 API 即時同步的動態資料	免費版的資料來源整合能力有限，硬做會變成維護地獄	評估付費方案或客製整合，先把需求規格化
表格本身就是要給 Google 索引的「內容資產」	靠 JS 渲染的表格內容可能不被搜尋引擎完整讀取	靜態 HTML 表格，把關鍵資料放進可被索引的原始碼
你只是想要「看起來像有在做事」	裝外掛不是績效，能解決問題才是	先回到需求本身，再決定要不要工具

Google 能執行 JavaScript，但動態渲染仍可能延遲，或因資源錯誤而缺少內容。若表格含重要規格、型號或價格區間，應用 URL Inspection 檢查 Google 看到的已渲染 HTML，也可在停用 JavaScript後確認是否仍有關鍵摘要。不要在未核對目前版本文件前，假設特定外掛一定提供「靜態渲染」選項。

把表格接上你的 WordPress 工作流

表格很少單獨存在，它通常是一整套 WordPress 工作流裡的一環。把表格放對位置，整個網站的維護成本會下降一個量級。這幾個搭配是我常用的做法：

• 表格 + Gutenberg 區塊：表格透過專屬區塊嵌入，讓你在編輯器裡就能預覽，不需要記 shortcode。區塊編輯器的外掛生態決定了你能多無痛地整合表格與其他內容元件。
• 表格 + 表單：表單收集資料、表格呈現資料，這兩者常常是一組。例如用表單收集報名、用表格顯示已報名清單。表單外掛的選擇會直接影響你能把資料接到多深。
• 表格 + 佈景主題：主題的排版系統會覆寫表格的樣式，挑主題時要確認它跟表格外掛的 CSS 不會打架。佈景主題的整體評估或像Divi 主題的完整指南這類深度的主題介紹，能幫你避開樣式衝突的坑。
• 表格 + 搬家流程：表格資料存在資料庫，搬家時要確認外掛的資料表有被一起搬過去。搬家外掛的選擇會決定這件事是自動完成還是要你手動補救。

把這些環節串起來看，你就會理解為什麼我一直強調「先分類再選工具」。表格從來不是孤立的決定，它跟你的編輯器、主題、表單、搬家流程全部耦合。一個選錯，後面要還的債會比你想像的多。

別讓表格變成障礙：給螢幕閱讀器的基本款

有一塊很少有人談，但表格上線前一定該檢查：表格的無障礙性（accessibility）。對使用螢幕閱讀器的視障讀者來說，一張沒有結構標記的表格，會被逐格朗讀成一串失去關聯的數字，完全讀不出「這一列是哪一個產品、這個數字代表什麼」。

表格無障礙的核心，其實是回到 HTML 表格原本該有的語意：用 <thead> 標出表頭列、讓表頭儲存格用 <th> 而不是 <td>、必要的時候加上 scope 屬性告訴機器這個表頭管的是列還是欄。一張有正確表頭標記的表，螢幕閱讀器就能朗讀成「產品 A，價格 1200」，而不是「1200」然後讀者要自己猜這是什麼。

實務上，多數表格外掛產生的 HTML 都會帶有 <thead> 與 <th>，但你不能假設它一定正確。我會建議在表格上線之前，用瀏覽器的開發者工具檢查一下實際渲染出來的原始碼，確認表頭有被正確標記。還有兩個容易被輕忽的點：斑馬紋的底色對比要夠，太淺的灰對視力退化的讀者等於沒有；排序與篩選按鈕要有清楚的可聚焦樣式，鍵盤使用者要能用 Tab 走到。這些都不是外掛的進階功能，是任何一個對所有讀者負責的網站都該做的事。把無障礙當成交件前的最後一道檢查，成本很低，卻能讓你的表格服務到本來就被排除在外的讀者，這在政府、醫療、教育類的網站特別重要，因為這些領域的讀者本來就涵蓋各種使用情境。

表格與 SEO 的三個容易被略過的交界

除了 Core Web Vitals，表格跟 SEO 還有幾個交界，是技術審查時最常發現問題的地方。它們不難，但容易被忽略，因為大家都把注意力放在外掛本身的功能上。

第一個交界：表格頁面要不要被索引

有些表格頁面其實不值得被搜尋引擎索引。例如純粹給內部參考的報價表、會員專屬的價格表、或跟其他頁面內容大量重複的比較表。這些頁面如果被索引，不只浪費檢索資源，還可能引發重複內容的問題。這時候noindex 的正確使用就派上用場。並非所有頁面都要搶排名，有些頁面反而要主動退出索引競爭。

第二個交界：同一份表格出現在多個頁面時的 canonical

同一張規格表嵌在多個頁面，不會只因共用元件就自動構成重複內容，也不需要把其他頁面都 canonical 到同一頁。只有當整頁主要內容高度相近、而且確實代表同一份內容時，才評估canonical、整併或差異化頁面。

第三個交界：表格所在的網址結構

表格通常嵌在文章或分類頁裡，它的網址其實是那個頁面的網址。如果表格是頁面的核心內容（例如一份完整的方案比較），那個頁面的網址優化就會直接影響這份表格能不能被正確歸類與排序。表格本身沒有網址，但承載它的頁面有，這個層級要想清楚。

表格會參與搜尋引擎與讀者理解頁面的方式。整理清楚、資料準確、更新日期與來源透明，能幫讀者判斷可信度；這不是獨立的 E-E-A-T 分數或排名捷徑。錯字、過時資料與混亂格式，也不是外掛能補救的。

表格之外：它在你整個行銷漏斗的位置

拉高一個層級看，表格通常出現在行銷漏斗的中後段。讀者已經跨過「認識問題」的階段，進入「比較選項、準備決定」。這正是表格最能發揮價值的地方。一份好的比較表，本質上就是在幫讀者完成「評估」這個階段的功課，讓他更快走到轉換。

所以你設計表格時，心裡要想的是「讀者在評估階段會問哪些問題、這張表能不能一次回答」，欄位是從這裡倒推回來的。這個視角轉換，比任何外掛功能都重要。如果你的表格能精準回答讀者在做決定前的最後幾個疑問，它就從「排版元件」升級成「轉換工具」。把表格放回完整的行銷漏斗裡思考，你會更清楚哪些欄位該留、哪些該砍。

表格的成敗很大一部分取決於開工前的需求判斷，外掛只是執行工具。SEO 相關設定可搭配WordPress SEO 外掛評測，把表格之外的技術基礎一起顧好。

開工前的五個問題（行動清單）

開工前先用這份判斷清單。下次接到「把這份表放上網站」的需求，先回答這五個問題，答案會告訴你該用什麼工具、該在意哪些事：

1. 這張表未來一年會被改幾次？幾乎不動，用內建；會規律更新，用外掛；持續從外部同步，評估動態方案。
2. 讀者要用它來「比」還是來「查」？要比，保留橫向結構與排序；要查，考慮卡片化與搜尋。
3. 資料量大到需要匯入嗎？超過十幾列，就該在試算表整理好再匯入，不要在後台手key，同時把欄位型態先定對。
4. 表格裡有沒有關鍵的 SEO 內容？有，就要確認它以靜態 HTML 存在、能被索引；沒有，就不用糾結渲染方式。
5. 這份表只出現在一頁，還是會出現在多頁？多頁時先維持單一資料來源；只有整頁主要內容實質重複時，才需評估 canonical 或整併。

把這五題想清楚，你會發現「要不要裝 Ninja Tables」從來不是重點，重點是你對這張表的需求有沒有想透徹。工具只是把你的判斷執行出來而已，判斷對了，內建表格也能做出轉換率漂亮的比較頁；判斷錯了，裝最貴的外掛也只是把一個錯誤的結構做得更精緻。

表格這件事，說到底是一種資訊整理的修養。你能把雜亂的規格整理成一張讓讀者一眼看懂的表，這個能力跟你用哪款外掛無關，跟你想事情的方式有關。把這個修養練起來，不管 WordPress 的工具怎麼改版、不管哪一款外掛會不會被淘汰，你都不會被困住。現在，挑一張你網站上最需要被整理的表，用這五個問題走一遍，那就是你最好的起點。