WordPress 文章目錄要不要加？先診斷結構再選做法

一個手作皮革禮品品牌的官網上有篇三千字送禮指南，內容齊全：皮革種類比較、刻字服務、包裝選項、送禮時機全寫了。來信卻反覆出現同一類問題：「皮革比較寫在哪一段？」「刻字要加價嗎，在頁面哪個位置？」後台數據同時顯示，多數人造訪後沒往下捲多少就離開。站長的直覺是內容不夠，要再補幾段；真正卡住的是已經寫好的段落沒有被找到。以上品牌情境為建構情境示意，用來說明判斷的起點。

補內容之前，先判斷導覽缺口在哪。文章目錄是導覽的其中一種解法，而且常被誤解：目錄外掛什麼都沒有「生成」，它只讀取已經寫好的標題層級、為段落配上識別碼，再輸出一張可點的清單。標題結構及格，目錄才有用；結構亂了，裝什麼工具都救不回來。成敗在安裝之前就定案。

接下來用一道判斷流程走完全程：先確認讀者需要嗎，再檢查標題結構及格嗎，弄懂配對原理，然後選做法、選版面、處理手機、上線驗收，收在長期維運。順帶分開兩種常被混淆的需求：文章目錄攤開段落結構；資料表處理規格、價格這類要排序篩選的內容。帶著後者的需求找前者的做法，做出來的東西不會對。

快速重點：目錄該不該加，看讀者會不會跳讀、標題分層清不清楚，而不是字數。外掛只負責讀取標題層級並配對段落 id，結構先過三關再選做法；桌機可走側欄、手機以開頭收合為預設，側欄固定優先用佈景主題或 CSS，上線後逐個錨點點測才算數。

三個訊號出現，才代表讀者真的需要目錄

先回答最常見的問題：有沒有一個「字數到多少就該放目錄」的門檻？沒有。三千字的公告照樣不需要目錄，八百字的疑難排解反而可能需要。判準只有兩個來源：讀者行為，以及內容型態。把兩者整理成三個可觀察的訊號，訊號成立再動手，目錄才會是解方，不是裝飾。

訊號一，定位型的問題重複出現。皮革品牌情境裡，「皮革比較寫在哪一段」這類問題一週出現三次，代表文章結構沒有被攤開，讀者只能用問的。來源不只客訴信：站內搜尋的關鍵字、聊天機器人的提問記錄、客服回覆時複製貼上的段落，都是同一個訊號的不同出口。同一類問題出現第三次，就該回頭檢查既有文章的導覽，別急著再寫一篇新的。

訊號二，行為數據顯示多數造訪只停在單一段落。讀者帶著單一問題進來，在第一個看起來相關的段落停下，找到或沒找到都會走。短停留不等於內容差，但「多數人只停一段就離開」配上「定位型問題」，兩個訊號互相印證時，跳讀需求才算確立。單看短停留容易誤判，短停留背後的解讀限制先弄清楚再下判斷。

訊號三，標題分層達三層以上，而且段落可以獨立閱讀。規格比較、挑選指南、疑難排解這類查詢型內容受益最大：讀者要的是其中一節，不必讀全文。判別的方法看問題本身，讀者的問題若指向特定小節（某項規格、某個錯誤訊息、某段流程），就是查詢型；問題若需要整篇脈絡才能回答（決策理由、論點評析），就偏連續閱讀。相對地，公告、活動快訊、以時間序為軸的紀錄、沒有從屬關係的線性散文，都不該放目錄；硬加只會佔掉首屏，再多一條維護負擔。

反向的極端也常見：幾十篇長文全無導覽，讀者只能整頁滑，一樣是把人推出門。兩種極端出自同一個缺項：沒有判準。把判準寫下來，三個檢核句就夠用：

• 讀者會不會想直接跳到某一節，跳過其他段落？
• 標題放到清單上，能不能光看項目就知道各段講什麼？
• 同一類定位問題，近一個月出現幾次？

訊號的採集要有節奏，不需要天天盯。新內容上線兩週後看一次數據與提問，每季把站上長文整批回看一次，就足以讓判準跟著內容一起更新。把檢核句和結論寫進內容工作的檔案裡，下一篇文章要不要目錄，當場就有答案；只靠印象決定，每篇都會重新糾結一次。

還要分清楚兩件事：外掛的顯示條件，例如最低標題數，是輸出規則，數字設多少依內容組成調整，欄位位置依版本介面確認；「幾字以上才放目錄」則是站長自己的編輯紀律，不是外掛的功能。把編輯紀律外包給外掛設定，規則會愈設愈複雜，到後來沒有人記得當初為什麼這樣設。

標題分層健檢：目錄的成敗在裝外掛之前就決定

目錄是標題結構的如實映射，輸入不修，輸出不會自己變正。外掛不會替你整理內容，它只做兩個動作：讀取，然後輸出。標題亂，目錄就跟著亂；這件事在安裝之前就定案，裝了外掛也逆轉不了。所以順序永遠是：先修結構，再談工具。安裝排在整條因果鏈的末端，把它放到最前面，後面每一步都在替錯誤的輸入善後。

結構及格與否，用三關檢核。第一關，層級連續：H2 之下接 H3，H3 之下才接 H4，不跳級；層級表達的是從屬關係，不是字的大小，為了讓某行字變小而降級，結構就說了謊。第二關，語意自足：標題要能獨立理解，「補充」「其他」「更多」這類字面放進清單等於空白，讀者看不出點了會到哪裡。第三關，字面不重複：兩個標題字面相同，段落識別碼就有撞名風險，跳轉落點可能跟著不準，清單上也容易出現難以分辨的項目；各外掛對重複標題的處理方式不一，發布後依實際輸出的 id 檢查。

三關有一個共通的自測法：把標題連同層級單獨貼到純文字文件裡，只看這份清單，請一位沒讀過文章的同事猜各段內容。猜得中，結構及格；猜不中，問題不在外掛，在標題。這個測試不需要任何工具，十分鐘內能做完一篇，卻能擋下安裝之後才發現的大半問題。

這三關屬於寫作紀律與可用性議題。把層級理順的收穫是讀者看得懂結構、目錄長得正確；至於搜尋引擎如何解讀標題層級，那是它的內部處理，站長能掌握的只有把結構寫清楚，不必把某種固定的層級順序當成排名規則來供奉。

還有一種輸入問題，外掛根本讀不到：粗體放大不是標題。外掛讀的是標籤，樣式再醒目也不會進清單。從其他平台匯入的內容特別容易出現這種狀況，標題在匯入時被降成一般段落，目錄就少了好幾項；匯入後逐篇抽查，對照原站的層級，是唯一可靠的修法。

層級深度本身也是編輯決策。縮排深度對應層級深度，清單挖到第四層、項目又多時，縮排會擠壓文字空間，可讀性會先垮掉。多數文章收在兩到三層就能把從屬講清楚；真的需要更深的結構，通常代表該拆成兩篇文章，或者把下層整理成表格。目錄的長相，回頭約束了文章的結構，這是它給寫作的回饋。

下標題的層級紀律，從發文流程就要守住，具體做法整理在發文時下標題的層級紀律；標題結構同時是頁面優化的一環，牽涉的層面比目錄更廣，可以對照頁面結構的整體優化一起看。

↔ 左右捲動檢視完整表格

輸入端的缺陷	目錄出現的症狀	修正方向
層級跳級（H2 直接接 H4）	縮排與內容從屬對不上，讀者誤判段落關係	逐層遞進，H2 之下接 H3，H3 之下才接 H4
標題空泛（「補充」「其他」）	清單失去導覽作用，看不出各段內容	標題寫成可獨立理解的短句
粗體放大充當標題	外掛讀不到該段，清單漏項	視覺強調用粗體，結構層級用標題標籤
標題字面重複	識別碼有撞名風險，跳轉落點可能不準	改寫成字面不同的標題，或改用自訂錨點

一個廚具代理商的規格比較長文，可以說明修結構的效益（建構情境示意）。這篇長文把十款爐具的比較寫成三大段，標題分別是「產品介紹」「比較」「結論」，目錄只有三個空泛項目，讀者來信問的還是「感應爐的比較在哪」。把三大段改寫成可獨立理解的問句標題、各項比較收攏成第三層之後，同一支外掛輸出九個項目，定位型的提問跟著停了。工具沒換，換的是輸入。

從標題到錨點：自動目錄的配對原理，以及它依賴設定的地方

目錄外掛依設定掃描文章裡的標題，為每個標題對應的段落產生或尋找識別碼，再把清單項目做成連向這些片段位址的錨點連結。讀者點下項目時，瀏覽器拿連結裡井號後方的字串，去比對文件內唯一的 id，配對成功才捲動定位，這是 HTML 的既有行為，不是外掛的專屬魔法。涵蓋哪些層級、id 如何命名、要不要平滑捲動，都依版本與設定而異，所以同一支外掛裝在兩個站上，行為可能不同，上線前要實際點測。

id 的唯一性是整個配對的前提。標題字面重複時，各外掛的處理方式不同：有的在後面加數字、有的略過、有的保留第一個，規則依版本與設定而異。與其記住某支外掛目前的處理方式，不如記住判準：發布後逐項點開，確認每個連結落在預期段落；想進一步查，用瀏覽器開發者工具檢視該段元素，看實際輸出的 id 值，再比對清單連結裡井號後方的字串是否一致。教學截圖會過期，判準不會。

同一支外掛在不同站上行為不同，還有兩個常見來源。其一是佈景主題：有些佈景會過濾或改寫內文輸出，標題被繞過，清單就少了項目。其二是快取：目錄在頁面輸出時產生，快取外掛可能讓修改後的清單延遲更新，改了標題卻看到舊目錄時，先清快取再判斷，別急著換工具。

兩個常見的失效模式要預先想好。跳轉後段落被固定導覽列蓋住，是其一；解法在外掛的偏移量設定或佈景主題的處理方式裡，驗收時每個項目都要看落點。平滑捲動與慣性捲動衝突，是其二；平滑捲動是選配行為，應尊重讀者的減少動態偏好，行動版實測有卡頓就先關掉再測，確認它是不是原因。

順道回應一個搜尋面上的混淆：目錄的 table 與資料表的 table 是兩回事。前者是導覽清單，後者是 HTML 表格，用來呈現規格、價格這類需要排序與篩選的內容。若要做的其實是後者，資料表做法的完整分析另有一篇可以對照，做法與目錄完全不同。

還有一個藏在細節裡的行為差異：點擊跳轉時，畫面捲動與鍵盤焦點是兩件事。多數情況下視覺上捲到了目標段落，鍵盤焦點卻還留在原處，按 Tab 繼續操作的人會從捲動前的位置往下走；有的外掛或佈景會把焦點一併移到目標標題，體驗就連貫了。驗收時除了用眼睛看落點，也按幾次 Tab 確認焦點行為，這個差異平時看不見，對鍵盤使用者卻很明顯。

多語或自動翻譯的內容要多留一眼：譯文重複率高，標題撞名的機率跟著升高，id 撞名的風險也一樣。匯入或翻譯批次完成後，抽幾篇點開目錄清單檢查，比出事再回頭找原因省事得多。

三種做法的取捨條件：用讀取、插入、輸出三個切面比較

比較目錄外掛時，真正在比的不是名稱與評分，而是三個機制切面。讀取面：掃哪些層級的標題、能不能排除特定標題。插入面：全站自動插入、短碼、或逐篇放入區塊。輸出面：文內清單、側欄小工具，或兩者都有。同一個需求會有多種組合，先想清楚站上的條件再挑做法，不要被外掛的功能清單牽著走。

↔ 左右捲動檢視完整表格

條件面向	全站自動插入	側欄小工具輸出	手動區塊插入
自動化程度	規則設一次，符合條件的長文全部套用	隨側欄版型出現，逐站設定	每篇文章手動放置
前端成本	依規則輸出，例外要逐篇排除	視佈景載入狀況而定，需確認輸出位置	載入範圍通常限於放入的頁面，實際依外掛實作確認
適合的站	長文量大的內容站	雙欄版型、查詢型內容為主的站	文章量少、重視極簡前端的站
維運負擔	改規則全站生效，須抽查例外文章	與側欄版型連動，佈景改版要複查	量一大就拖，新文章要記得放

把表格讀成三個問句，選擇會自己收斂：站上有多少篇會持續被查閱的長文？版面要不要側欄輸出？之後由誰維護、能負擔多少例行工作？三個答案都有了，對應的做法只剩一種；答不出來時，先挑十篇長文做小範圍試行，跑一個內容更新週期再全站套用，成本比一次到位低，修正也快。

Easy Table of Contents 官方頁載明這支外掛能依標題建立目錄，並可依文章類型自動插入，頁面同時列出小工具輸出。要留意邊界：側邊欄能不能黏住、黏到哪裡，官方頁的說明不能取代實測，佈景相容與固定行為要另行驗收，這點在版面一節展開。它只是這條決策線末端常見的執行工具之一，需求與結構沒有先想清楚，換哪支都一樣。

LuckyWP 的官方外掛頁把輸出形式列得很完整：小工具、Gutenberg 區塊、短碼都有。同類外掛的輸出面各不相同，有的把側欄當主要輸出，有的以區塊為主；比較時不宜假設側欄輸出是特定外掛的專屬能力，到官方頁確認輸出清單，再對照自己的版型需求，才是可靠的比法。

維護狀態三件事合看：最近一次更新日期、標示的相容版本、支援論壇的回應狀況。更新間隔拉長不等於不能用，但採用前要在測試環境跑一輪；這個原則對任何老牌外掛一體適用，不限於目錄類，也不限於免費或付費。

安裝屬通用流程，從後台搜尋名稱、安裝、啟用，與其他外掛沒有兩樣，細節照安裝外掛的通用流程走一次即可。若想連同站上其他需求一起規劃，先讀挑選外掛的整體規劃，再決定目錄這一塊交給哪種做法。

放文章開頭還是側邊欄？讓版型與閱讀動線替你決定

位置由兩個維度決定：版型是單欄還是雙欄，內容是連續閱讀還是查詢型。單欄版面與手機，目錄放文章開頭、預設收合，讀者掃過清單決定要不要深入；雙欄桌機，可以讓目錄常駐側欄，讀者捲到中段也隨時可跳，不必回到頁頂。查詢型長文受益最大，連續閱讀的散文型內容，開頭那份收合目錄就夠了。

先拆開一個常見的混淆：側欄固定與目錄生成是可以分開的兩種機制，但要先確認固定由誰提供。目錄生成讀標題、輸出清單；側欄固定常來自 CSS 定位或佈景主題機制，讓側欄在捲動時貼住視窗，行為受容器高度與上邊界約束。邊界在於：有的目錄外掛自帶側欄小工具的黏著選項，啟用之後固定就跟著該外掛走，換外掛時固定會一併消失；固定若由佈景或自寫 CSS 提供，換目錄外掛後比較有機會保留，但 CSS 選取器若指向前一支外掛輸出的標記，固定仍可能失效，換裝後要重新確認。先辨認固定的來源，兩種機制分開決策、分開驗收，出問題才找得到源頭。

黏不住的常見原因，也多半出在機制而非工具。側欄的可用高度由它的容器決定：容器比視窗矮，側欄貼到容器底部就停，這是正常行為，不是故障；側欄本身比視窗高（清單長、小工具多），貼住的效果也會打折，這時該處理的是清單長度或側欄內容，不是換一支更強的固定外掛。判斷順序對了，才不會把機制的限制誤認成相容性問題。

固定的手段有優先序。先用佈景主題內建的黏著側欄；沒有，再自寫一小段 CSS（position: sticky）；固定小工具類的外掛放第三順位。這一類外掛在官方目錄都找得到現成選項，挑選時逐支自查最近的更新日期與標示的相容版本、在測試環境跑一輪，並確認上邊界預留了固定導覽列的高度，貼住的目錄才不會被頁首蓋住一角。

同頁出現兩份目錄，是位置決策最常見的失誤：文內自動插入與側欄小工具同時開啟，讀者看到兩份相同清單，只會困惑。分工解法：寬螢幕走側欄，窄螢幕留在開頭收合，兩種配置不同時出現在同一畫面。側欄目錄太長超過視窗時，改用可收合模式或回到文內配置，不要讓清單黏成一堵牆。

開頭目錄的預設狀態也要選：預設收合，首屏留給正文，讀者有需要再展開；預設展開，讀者一眼看到全貌，但長清單會把正文推到第一個畫面之外。取捨依內容型態，查詢型長文適合預設收合，讀者的問題明確，展開是主動作；結構複雜、需要讀者先理解全貌的內容，可以考慮預設展開，但清單超過一個畫面就該回到收合。放在側欄的目錄，位置排在側欄首位，讀者捲到中段時它仍然在視線範圍內。

側欄目錄以小工具形式放置，而小工具區域的命名與數量由佈景主題決定，這層運作邏輯整理在側欄小工具區域的運作方式；固定式小工具的具體做法與邊界設定，另見固定式小工具的做法。

手機版是另一場考試：過半讀者用小螢幕讀你

規模先弄清楚：行動裝置占全球網站流量的比重已經過半，近年大致在五到六成之間波動（Statista 的長期統計可查各期數字）。數字逐季有起伏，不必記住小數點，記住量級就夠了。接著讓手機當主要驗收版本：順序倒過來，先在手機上確認能讀、能跳、能返回，再到桌機微調。手機不是縮小的桌機：側欄多半被折到內容下方，或佔掉整個首屏，桌機上調好的配置，到手機上常常是另一回事。

版面分化的做法很直接：用 CSS 媒體查詢，或佈景主題內建的響應式邏輯，在寬螢幕保留側欄目錄，在窄螢幕隱藏側欄、只顯示文章開頭的摺疊目錄。兩種配置有同一條底線：不得遮住正文。開頭目錄展開後的高度，以不超過半個畫面為原則，超過就該檢視清單長度。用佈景內建邏輯的站，要確認側欄在小螢幕確實被收掉，不是只變窄。

穩定性要盯兩件事。展開與收合會改變頁面高度，跳轉的偏移量跟著變，驗收時要來回各做一次。平滑捲動與行動瀏覽器的慣性捲動可能互相干擾，定位不準或卡頓時，先關掉平滑捲動再測，就能確認它是不是原因。

展開收合與跳轉造成的版面位移、互動延遲，都有對應的衡量方式，體驗指標的衡量方式把計算口徑整理得很清楚；先知道怎麼量，才知道要修什麼、修了有沒有效。

驗收要在實機上做。開發者工具能模擬螢幕寬度，模擬不了觸控與慣性捲動；用拇指點過每一個項目，iOS 與 Android 各跑一輪，展開、跳轉、返回都走一遍。訊號弱的環境也抽一次：低速網路下清單與平滑捲動的表現，常和辦公室網路差一截。這一步沒有捷徑，但十分鐘的實機操作，涵蓋的失效模式比任何模擬都多。

上線不等於完成：能保證什麼、不能保證什麼，附驗收清單

先把話講清楚：目錄買到的是導覽可用性與可量測的行為，不是排名保證。上線前的驗收清單如下：

1. 逐個點擊目錄項目，每個連結都落在預期段落，id 沒有撞名。
2. 跳轉後的段落不被固定導覽列蓋住，偏移量正常。
3. 桌機側欄的黏住範圍與上下邊界符合預期，沒有疊到側欄其他小工具。
4. 手機版開頭目錄的收合、展開、跳轉、返回各走一遍。
5. 短文與公告沒有冒出目錄，顯示條件發揮作用。
6. 同一畫面沒有兩份目錄同時出現。
7. 佈景改版或大批改稿之後，前面的項目重跑一輪。

驗收結果留下紀錄：哪一天測的、測了哪些頁面、發現什麼。下次佈景改版或外掛升級後，照著上次的紀錄重跑，缺漏會少很多；這份紀錄也讓「目錄壞了」有跡可查，能對出是哪次變更造成的，不必從頭猜起。

上線後看什麼？捲動深度、目錄點擊事件、各段停留都可以當觀察指標。做法上，在目錄項目的點擊綁一個事件、觀察期間拉長到一個內容更新週期，數字才有上下文；有目錄與無目錄的相近頁面互相比，或改版前後比，兩種對照都只能當參考，因為同期變數經常不只一個。效果認定以自家數據為準，相關不等於因果。搜尋結果上要不要出現頁內跳轉連結，由搜尋引擎決定，站長能做的是把結構與錨點顧好，把它當可用性設計，不要當版位策略。

效能也要驗，而且用實測的，不用印象的：在有目錄與無目錄的頁面分別量測，再決定要不要調。速度自 2018 年起列入行動搜尋排名因素之一（Google 當時的公告寫明適用範圍），但目錄通常不是瓶頸；真要調速度，先看速度調校的先後順序，原則只有一條：先量測再動手。

無障礙是最容易被略過的價值。語意化的目錄連結，對鍵盤與螢幕閱讀器使用者是直接的導覽工具：清單可以被朗讀、可以被逐一跳過，等於多了一條不依賴滑鼠的閱讀動線。鍵盤聚焦的樣式不能被 CSS 拿掉，否則按 Tab 的人不知道自己停在哪個項目上。這一項驗收只需要拔掉滑鼠試一次，成本極低，受益的卻是一整群使用者。

改標題之前：錨點穩定性的長期維運

錨點會不會因為改標題而失效，取決於錨點的來源。由標題文字自動生成的錨點，改字之後有機會跟著變動；曾經連向舊識別碼的外部引用或站內片段連結，就可能落空。事先在區塊上設定固定且唯一的自訂 HTML 錨點，之後調整標題文字，就不一定影響連結。把「哪一段的 id 被誰引用」記下來，比事後全站掃描省力。

WordPress 官方的 Page Jumps 文件也是同一個口徑：可以為區塊設定固定且唯一的 HTML 錨點，改動標題文字並不必然使自訂錨點改變。要緊的分辨在「自動生成」與「自訂」兩種來源：前者的識別碼跟著標題走，後者由自己指定；長文的重要段落，用自訂錨點多一層保險。自訂錨點的名稱取簡短、語意相關、不含空白的字串，之後無論標題怎麼改寫，識別碼都不動，引用它的人也不用跟著改。

維運節奏寫進編輯流程：大批改稿或佈景改版之後，掃一次片段連結與破連結；改標題之前，先查該段識別碼有沒有被其他頁面或外部文章引用。掃描用現成的破連結檢查工具即可，重點是三件事定下來：誰負責跑、多久跑一次、結果記在哪裡。寫成可以直接照做的清單，比仰賴某個人記得要來得可靠；維運會斷，通常是因為它只存在於某人的腦子裡。

回顧整條判斷流程，每一步都排在它該在的位置：先看結構，標題分層及格，目錄才有意義；再確認 id 配對，原理對了，設定才有依據；然後是顯示規則，哪些頁面出現、哪些排除；接著版面，開頭或側欄、手機怎麼收合；收在維護，改稿之後回頭複查。前一步是後一步的輸入，跳過任何一步，後面都要重來。目錄是導覽的基礎建設，把它當長期經營的東西，用驗收數據說話；下一步很具體，挑站上被問最多的那段長文，從目錄點進去，把自己當成第一次來的訪客走一遍。