多數人規劃網站選單的方式是先想「我有哪些東西」，再把這些東西塞進導覽列。結果就是首頁、關於我們、產品、最新消息、聯絡我們這串看起來很完整、卻沒有人真的照著走的選單。讀者進站不是來瀏覽你的組織架構，他帶著一個任務上門：想找某項服務的價格、想知道怎麼預約、想確認你做不做某件事。網站資訊架構規劃的核心，就是把選單與層級反過來，從讀者要完成的任務開始推。

資訊架構（Information Architecture，常簡稱 IA）講的是「資訊怎麼組織，才會好找、好懂」。它比導覽列大得多，導覽列只是冰山露出水面的那一角，下面還有分類邏輯、標籤命名、頁面層級與站內搜尋。這篇會用一條可以照做的流程，帶你從盤點讀者任務，一路反推到主選單該放幾項、要不要做下拉、層級要壓多平，最後落到 WordPress 後台實際怎麼對應。

資訊架構規劃為什麼要從讀者任務開始

先講結論：選單反映的是讀者完成任務的路徑，不是你的部門表或商品目錄。從任務反推，是因為讀者進站時腦中已經有一個明確的目的，他在掃視選單時，是在找「最像我要做的那件事」的那個字，而不是在欣賞你的網站結構。

把這件事做反的代價很具體。當選單照組織內部的分類來排，讀者常常找不到對應的入口，只好按上一頁離開，或退回首頁重來一次。資訊架構的目標一直都是兩件事：可尋性（findability，東西找得到）與可理解性（understandability，看得懂這是什麼）。任務導向的規劃就是直接服務這兩件事。

具體做法是先列出讀者最常帶著上門的任務，再把任務翻成他會點的字。舉例來說，一個提供線上課程的網站，讀者的任務可能是「看課程內容」「確認上課時間」「知道怎麼報名與付款」「找退費規則」。這些任務翻成選單就是「課程」「課表」「報名方式」這類字，而不是「教學部」「行政中心」這種對內部才有意義的命名。

讀者任務清單怎麼盤出來

最快的起點是手上現成的資料，不需要先做大型使用者研究。把站內搜尋紀錄、客服與表單最常被問的問題、以及網站分析裡進站後最常被點的頁面三者攤開，讀者真正想做的事大致就浮出來了。這三份資料的好處是它們反映真實行為，而不是你猜的。

接著把蒐集到的任務寫成短句，動詞開頭，一句一個任務。像是「比較不同方案的差異」「查目前的開放時段」「下載報價單」「找到實體門市地址」。寫成動詞句，是為了避免一開始就跳進名詞分類——名詞分類是後面的事，現在要先確定讀者「想做什麼」。

任務列完後做兩件整理。第一、把同一群人在同一情境會連續做的任務標在一起，例如「看方案、比較方案、看價格」通常是同一次造訪內的連續動作。第二、依出現頻率與商業重要性粗略排序，高頻又重要的任務，等一下要放進讀者一眼就看到的位置。這份排序就是後面決定選單順序的依據。

從任務分組到分類，卡片分類法怎麼用

任務清單本身還不是選單，中間要經過一次分組，把零散的任務收斂成幾個讀者看得懂的類別。這一步最常用的工具是卡片分類法（card sorting）：把每個任務或頁面寫成一張卡片，請幾位接近目標讀者的人，把卡片分成他們覺得合理的幾堆，再幫每一堆取名字。

卡片分類法分兩種，用途不同。開放式分類讓受測者自由分堆、自己命名，適合你還沒有既定分類、想知道讀者腦中怎麼歸類的時候。封閉式分類則是你先給定幾個類別名稱，請受測者把卡片放進去，適合你已經有一套分類、想驗證它合不合直覺的時候。新站建議先做開放式找出讀者的心智模型，改版站則可以用封閉式檢查現有分類。

實務上不需要動用昂貴的工具或大量受測者，找五到八位接近真實讀者的人，用紙卡或免費的線上分類工具就能看出明顯的分組傾向。重點不是統計顯著，而是觀察「哪些任務多數人會放在一起」「哪個分類名稱大家都看不懂」。看不懂的命名，就是讀者上線後會迷路的地方，現在改成本最低。

分組完成後，每一堆對應的就是一個候選的分類或選單項目。這裡有個常被忽略的檢查：分類之間要盡量明確、不重疊。當兩個分類的界線模糊，讀者會卡在「我要找的東西到底算哪一類」，這種猶豫和找不到一樣傷。

主選單要放幾項，層級要做多深

先給可操作的數字：主選單的頂層項目控制在五到七項，是多數情境下的安全範圍。超過這個數量，讀者就難以一眼掃完並記住裡面有什麼；研究普遍觀察到，選單項目一旦超過七到九項，使用者開始感到困擾。內容真的更多時，多出來的東西交給下拉選單、大型選單（mega menu）或站內搜尋處理，而不是硬塞進頂層。

頂層數量定了，接著決定層級深度，這是扁平與深層的取捨。扁平結構層級少（通常一到三層）、讀者點幾下就到底；深層結構層級多（四層以上），分類更細但要點很多次才到得了內容。多數網站該往扁平靠，目標是讀者兩到三次點擊就能抵達任何一個重要頁面。原因是內容埋得越深越難被發現，層級一深，讀者也越容易迷失方向。

扁平不代表永遠最好，它有兩個前提。其一、你的分類本身夠明確、彼此區隔清楚，讀者才不會被一長串並列的選項淹沒。其二、項目總量沒有多到無法在一個層級展示完。當分類太多、或某些主題需要先給讀者一個過渡的脈絡頁才看得懂，這時適度加一層中介分類反而比硬攤平更好懂。判斷原則很簡單：限制深度，而不是限制廣度——寧可多一兩個頂層項目，也別把內容藏到第三層底下。

排序也別憑感覺。序列位置效應（serial position effect）指出，人對一串項目的頭和尾記得最清楚，所以最重要的入口放在選單開頭、次重要的擺中間，而像「聯絡我們」這種收尾型入口慣例放在最右。這也呼應前面盤點任務時做的頻率排序：高頻重要的任務，位置給好給滿。

反推完的架構長怎樣，一張結構圖看懂

把任務、分組、選單與層級接起來後，會得到一張站台的層級圖。下面用一個提供方案型服務的網站當例子，呈現從首頁往下兩層的扁平結構：頂層只有幾個對應讀者主要任務的入口，每個入口底下掛少量、明確的子頁。

這張圖的價值在於它一眼就能檢查兩件事：每個頂層入口是不是都對應到一個讀者任務、有沒有任何重要頁面被壓到讀者點三次以上才到得了。把整站攤成這樣一張圖，比逐頁看更容易抓出結構問題。

WordPress 的分類、標籤、頁面與選單該怎麼對應

把架構落到 WordPress 時，第一件要分清楚的事是：分類（Category）、標籤（Tag）、頁面（Page）與選單（Menu）是四個不同的東西，混用是 WordPress 站最常見的資訊架構問題。分類用來建立文章的主題層級，是樹狀的、可以有子分類；標籤是平行的關鍵詞，沒有層級，用來橫向串聯主題；頁面用來放靜態的服務、關於、聯絡這類內容；選單則是你手動挑選上述項目組成的導覽，它不會自動等於你的分類結構。

最常見的踩雷有三個。第一、把標籤當分類用，結果產生大量只有一兩篇文章的標籤頁，這些稀薄頁面對讀者和搜尋引擎都沒幫助。第二、分類切得太深，文章被埋進子分類的子分類，讀者要點很多層才看得到，違背了前面說的扁平原則。第三、誤以為導覽列會自動反映分類——WordPress 的選單是獨立設定的，你在「外觀／選單」裡放什麼，它才顯示什麼，所以前面反推出來的那張結構圖，要由你手動建成選單，而不是期待系統自動長出來。

正確的對應方式是：把任務分組得到的幾個主類別，設成少量、明確、不超過兩層的分類；用標籤做跨分類的橫向連結，而不是拿來當第二套選單；服務、價格、聯絡這類任務型入口用頁面承載；最後在選單設定裡，按任務頻率排序，手動組出那張結構圖。如果是 WooCommerce 商店，商品分類同樣套用這套邏輯，把商品依讀者選購時的思考方式分組（例如依用途、依對象），而不是依內部倉儲或品牌代號分類；至於結帳與收款流程，讀者的任務只是「順利完成購買」，導覽上把購物車與結帳入口放在固定、好找的位置即可。

麵包屑、頁尾與站內搜尋怎麼補強主選單

主選單負責讓讀者找到大方向，但它無法獨力承擔所有導覽，需要三個配角補強。第一個是麵包屑（breadcrumb），它顯示讀者目前這頁從首頁一路下來的位置，特別適合層級較深、或讀者從搜尋引擎直接落到內頁的情況。建議麵包屑層級不要超過四到五層，過長反而失去定位的作用。

麵包屑對 SEO 也有實質幫助。在頁面加上 BreadcrumbList 結構化資料，等於告訴 Google 這頁在站內層級中的位置，Google 常會把麵包屑顯示在搜尋結果裡、取代那串網址。曾有一個大型電商網站的 SEO 分流測試發現，重新導入可見麵包屑搭配伺服器端的 BreadcrumbList 結構化資料後，自然流量出現了具統計意義的約 5% 提升。在 WordPress 上，Yoast SEO、Rank Math 這類外掛都能直接產生帶結構化資料的麵包屑，不必自己寫程式。

第二個配角是頁尾。會一路捲到頁尾的讀者，通常比平均訪客更投入，所以頁尾適合放那些重要、但擠不進主選單的次要連結——隱私權政策、使用條款、客服資訊、電子報訂閱、社群連結等。頁尾通常比主選單更細，等於替主選單分擔了長尾入口。

第三個配角是站內搜尋。當讀者已經知道自己要找什麼，搜尋是最快的路徑，內容量大的站尤其需要。搜尋框的慣例位置是桌面版右上角、手機版收成放大鏡圖示。要注意的是，搜尋只服務「已經知道要找什麼」的讀者；不知道自己要什麼的讀者，還是得靠主選單與分類來瀏覽，兩者互補，缺一不可。

規劃完的架構，上線前怎麼低成本驗證

架構規劃完不要直接上線，先用一個便宜的方法驗證它真的好用：樹狀測試（tree testing）。做法是把你的層級結構去掉視覺設計，只留純文字的選單樹，給幾位接近真實讀者的人幾個任務，例如「請找出退費規則在哪裡」，看他們能不能在不靠搜尋的情況下點到正確的頁面。

樹狀測試和前面的卡片分類法是一組互補的工具：卡片分類在規劃前期幫你決定東西該怎麼分，樹狀測試在規劃後期幫你驗證分出來的結構讀者找不找得到。兩者都不需要成品網站，紙上或簡單的線上工具就能跑，成本遠低於上線後才發現選單沒人會用、再回頭大改。

上線之後，驗證的資料來源就換成真實行為。回頭看網站分析裡的進站後動線、站內搜尋紀錄與跳出狀況：如果大量讀者進站後第一個動作是用搜尋找某個東西，通常代表那個東西在選單裡不好找，該把它往上提；如果某個選單項目幾乎沒人點，要嘛它的命名讓人看不懂，要嘛它本來就不該佔頂層的位置。資訊架構不是一次定生死的工程，它隨著內容增加與讀者行為改變而持續微調。

把讀者任務變成選單之後，下一步往哪走

回到最初那個顛倒的順序：先盤點讀者帶著上門的任務，用卡片分類把任務收斂成明確、不重疊的分類，依任務頻率決定主選單的五到七個頂層項目與順序，把層級壓到讀者兩三下就點得到，再用麵包屑、頁尾與站內搜尋補強，最後在 WordPress 後台用分類、標籤、頁面與選單把這張結構圖如實建出來。每一步都對著「讀者要完成什麼」這個問題回答，選單自然就會長成讀者看得懂、走得通的樣子。

接下來最值得動手的有兩件。先把你現有網站的層級攤成一張結構圖，逐頁問「這頁對應哪個讀者任務、要點幾下才到得了」，沒有對應任務或藏太深的頁面就是優先要處理的對象。再找五到八位接近真實讀者的人跑一次樹狀測試，用他們找不到的地方反推哪裡要改。把這兩件事做完，你的選單就不再是組織架構的鏡子，而是讀者完成任務的路線圖。