游標停在空白的大綱上，多數人第一個動作是列「我想講什麼」，但真正會排名的大綱，列的是「讀者想問什麼」。這兩者常常不一樣，而搜尋引擎服務的是後者。一份好的大綱不是在動筆前把你腦中的知識分門別類，而是先把讀者會實際問出口的問題倒出來，再按關聯把它們群組成 H2、往下拆成 H3，讓標題階層自己長成這一頁的架構。這篇我們談大綱怎麼列：如何把讀者的問題展開成 H2 與 H3、為什麼一個小節只解決一個問題，以及標題階層本身如何構成一頁的骨架。這是規劃層面的功夫，不談逐句寫作。讀完你會有一套可重複的流程：從蒐集問題、排優先序，到群組成階層、檢查動線與重複，最後把架構如實交給搜尋引擎，每一步都有明確的判斷依據，不必憑感覺列標題。
1. 大綱的原料是讀者的問題，不是你想講的重點
多數人列大綱是列「我想講什麼」，但會排名的大綱列的是「讀者想問什麼」。這兩者常常不一樣，而搜尋引擎服務的是後者。先把這個方向擺正，後面的群組與排序才有意義，否則你只是把自己的知識整理得很整齊，卻回答不到讀者真正想問的事。
1.1 從讀者實際問出口的問題開始
我們的做法是，在列任何標題之前，先把這個主題下讀者會實際問出口的問題全部倒出來。以一個居家學習類的主題為例，讀者會問的是：幾歲開始適合、每天要花多久、會不會跟原本的習慣衝突、教材怎麼挑、自己不擅長還能不能陪。這些帶著疑問語氣的句子，才是大綱的原料。用「產品特色」「使用方式」這種內部視角的分類起手，寫出來的東西往往離讀者很遠，因為它回答的是你想介紹的，不是讀者想知道的。我們在服務經驗裡看過太多大綱，標題都很工整，卻沒有一條對得上讀者真正在搜尋框裡打的字，結果內容寫得再用心也接不到流量。辨別方向對不對有個簡單的檢查：把每個預計要寫的標題翻成一句讀者會問的話，如果翻不出來、或翻出來的是「我想介紹某某功能」這種作者口吻，那就代表這條是從內部視角出發的，該換成讀者真正會問的角度重寫。
1.2 問題從哪裡蒐集
問題不必憑空想。搜尋結果頁上的相關提問區塊、搜尋建議，以及 Google Search Console 裡這一頁實際承接到的查詢，都是現成的礦。我們在實務上看過一頁的表現忽好忽壞，把 GSC 的查詢逐條攤開後才發現，讀者真正在問的角度跟原本大綱設想的差了一截：編輯以為讀者關心的是規格，實際搜進來的字卻大量集中在「適不適合、會不會出問題」。把真實查詢當原料，大綱才不會自說自話。除了工具，身邊非專業的親友也是好來源，他們對這個主題的直覺提問，往往比內部人更貼近一般讀者的認知起點，有時一句外行的問題就點出你漏掉的整個面向。蒐集的時候我們不急著分類，先求把問題倒乾淨，哪怕看起來重複、瑣碎的也先記下來，因為重複的問題往往透露讀者最在意的點，瑣碎的問題則可能是長尾的來源。倒得夠全，後面群組時才有足夠的素材去判斷哪些該進正文、哪些該收到常見問題。
1.3 幫問題排優先序
問題倒出來之後不是照單全收，要分主次。哪些是這一頁非回答不可的核心問題，哪些是延伸、可以簡短帶過或留給文末的常見問題，先分清楚。核心問題撐起 H2，延伸問題往下放或收到收尾段落。這個排序其實就是在替讀者決定閱讀的先後，值得花時間想。我們通常會把所有問題先貼成一欄，逐條標上「核心」或「延伸」，再把核心的那幾條抽出來當 H2 的候選，這樣整頁要回答什麼、以什麼順序回答，在動筆前就定了調，不會寫到一半才發現主線散掉。排序時有個小技巧：把核心問題依照讀者的急迫程度排，越是讀者一點進來就想知道答案的，越往前放。這樣文章一開頭就命中他最關心的疑問，留得住人，也符合搜尋引擎偏好把答案放前面的傾向。
2. 把問題群組化，長成 H2 與 H3 的層次
單一問題還不是結構。要把一堆問題按關聯性歸群，大群變成 H2，群裡的子問題變成 H3，層次自然就出來了。這一步做得好，整頁的邏輯就清楚。
2.1 相近的問題歸成一個 H2
把倒出來的問題擺在眼前，你會發現有些天然是一夥的：關於「怎麼挑」的幾個問題可以歸成一個 H2，關於「怎麼開始」的幾個歸成另一個。每個 H2 代表一個唯一的子主題，群與群之間界線要清楚，不要重疊。分類模糊或互相交疊，是我們看過最傷結構的問題之一，讀者會在相似的段落間繞圈，搜尋引擎也難判斷各段各自負責什麼。檢驗的方法很簡單：把每個 H2 要回答的問題寫成一句話，如果兩個 H2 的那句話意思太接近，就代表它們該合併，或界線沒切乾淨。群組時還要留意一種情況：有些問題橫跨兩個子主題，看起來哪邊都能放。這時候要回到讀者的動線判斷，看他是在思考哪個子主題時會冒出這個問題，就把它放在那一群，而不是硬塞進比較好看的那一組。讓歸屬貼著讀者的思路，段落之間才不會彼此打架。
2.2 子問題往下拆成 H3，不跳級
一個 H2 底下，通常配兩到三個 H3，對應這個子主題裡更細的問題。層次要逐級遞進，H2 之下接 H3，不要從大標直接跳到更小的層級。這條規則看似瑣碎，但標題階層一旦跳級或層次混亂，整頁的主從關係就糊掉了，讀者掃讀時抓不到脈絡，搜尋引擎也讀不出哪個段落從屬哪個主題。下面這張表示範怎麼把讀者的問題轉成階層，你可以看到同一個子主題下的細問題，是怎麼被收進對應的 H3。
| 讀者的問題 | 歸入的 H2（子主題） | 展開成的 H3 |
|---|---|---|
| 幾歲開始適合？自己不擅長能不能陪？ | 怎麼開始 | 適合的起步年齡；家長參與程度怎麼拿捏 |
| 教材怎麼挑？居家和線上差在哪？ | 怎麼挑選 | 挑選的核心準則；不同型態的適用情境 |
| 每天花多久？會不會半途而廢？ | 怎麼維持 | 合理的頻率；常見的中斷原因與對策 |
2.3 用讀者的閱讀動線決定 H2 的先後
H2 的排列順序不是隨意的，該照讀者的思考動線走。多數人是先想「這適不適合我、怎麼開始」，再問「那我該怎麼選」，最後才關心「選了之後怎麼維持」。大綱的順序若貼著這條動線，讀者一路讀下來很順，前一節的答案剛好帶出下一節的疑問；順序若亂跳，就算每一節內容都對，整體也會讀得卡，讀者得自己在段落間來回找脈絡。我們檢查動線的方法很土：把 H2 順著念一遍，想像自己是第一次接觸這主題的人，看會不會在某個轉折覺得「怎麼突然跳到這裡」，只要有這種卡頓感，順序就還能再調。這個土方法比任何理論都管用，因為它站在讀者的位置，而不是作者的位置。作者因為太熟內容，常會不自覺照自己建構知識的順序來排，那個順序對已經懂的人很自然，對第一次接觸的讀者卻可能是倒著走。強迫自己用讀者的視角念一遍，就是在校正這個落差。
3. 一個小節只解決一個問題
大綱最容易失守的地方，是一個標題底下塞了太多問題。守住「一節一問」這條線，整頁的清晰度會差很多。
3.1 標題若要用「和」連接兩件事，多半該拆
我們的做法是檢查每個標題，如果它得用「和」「與」把兩個不同的問題勉強綁在一起，那通常是訊號：該拆成兩節。一節只回答一個問題，讀者才能靠標題精準跳到要的地方，搜尋引擎也更容易把這一段對應到某個查詢。一節混答多題，結果常是每個問題都答得不清不楚，讀者掃到標題以為有答案，讀進去卻發現被稀釋成好幾塊。拆節的成本在大綱階段很低，等內容寫完再回頭拆，往往要連帶重排好幾段，划不來。不過也別矯枉過正，不是所有帶「和」的標題都該拆，關鍵是這兩件事對讀者而言是不是同一個決策脈絡下的東西。如果拆開反而讓讀者得在兩節間來回比對才拼得出答案，那它們本來就該在一起，這種時候保留合寫、在段落裡分層說明更合理。
3.2 每節都要有實質觀點，不要換句話說
拆節之後要小心另一個反效果：為了湊出節數，把同一件事換句話說放進不同小節。每個小節都要有它自己的實質內容，若兩節講的其實是同一件事，該合併而不是硬撐。大綱階段就把重複的節揪出來，比寫完再刪省力得多。判斷兩節是否重複，一樣把各自要回答的問題寫成一句話，如果這兩句話幾乎是同一個意思，就是重複，該合併或把其中一節收斂到更明確的子問題。我們在審稿時常做這個動作，它比讀完整段內容再判斷快很多，也更不容易被文字的表面差異騙過去。
3.3 延伸與長尾問題留給收尾段落
不是每個問題都要進正文。那些讀者會問、但放進正文會打斷主線的延伸問題，適合集中到文末的常見問題段落處理。這樣正文的每一節都能專注在核心問題上，動線不被瑣碎的枝節切斷。哪些進正文、哪些往後放，在大綱階段就先分好，才不會寫到一半被一堆次要問題帶偏。常見問題段落也不是雜物櫃，它該收的是那些獨立、簡短就能答完的長尾疑問，若某個問題其實很核心、需要展開，那它該回到正文當一個小節，而不是塞進問答裡草草帶過。區分核心與延伸有個判準：這個問題是不是讀者做決定前一定要知道的。一定要知道的，進正文；知道了更好、不知道也不影響主要決策的，收到常見問題。按這條線分，正文才會緊湊，常見問題也才不會變成什麼都往裡塞的雜物櫃。
4. 標題階層本身就是這一頁的架構
把上面的步驟做完，你其實已經得到一份內容地圖。標題階層不只是排版，它是搜尋引擎理解這一頁主題結構的依據。
4.1 只看標題就要能讀懂整頁在講什麼
檢驗大綱好不好的一個簡單方法：把所有 H1、H2、H3 單獨抽出來排成一串，只讀這串標題，能不能看懂整頁的邏輯與涵蓋範圍。如果只看標題就通，讀者掃讀時能靠標題導航，搜尋引擎也能靠這個階層抓到主從關係。若抽出來一團亂，內文寫得再好也救不回結構。我們把這個動作當成大綱的出廠檢查，一份過不了這關的大綱，不會讓它進到寫作階段。實務上你會發現，能通過這關的標題串，本身讀起來就像一份精簡的摘要，這正是搜尋引擎與趕時間的讀者都想要的。很多讀者其實不會逐字讀，而是先掃標題決定值不值得細看，一串邏輯清楚的標題就是在替你留住這種掃讀型讀者。反過來說，如果抽出來的標題串讀起來像跳針或缺了環節，代表結構本身有洞，這時候回去補的不是文字，而是大綱的完整性。
4.2 標題階層也要對應可被抓取的 HTML
大綱最後要落到正確的標籤上：每頁一個 H1，H2 與 H3 逐層對應，而且這些標題要真的用語意化的標題標籤寫，而不是用加大加粗的文字假裝。搜尋引擎靠標籤判斷層級，用樣式做出來的假標題，它讀不出階層。這一步是把規劃好的架構，如實交給搜尋引擎。在我們診斷過的案例中，有不少頁面大綱其實想得很清楚，卻敗在視覺上看起來像標題、原始碼裡卻只是一般段落，等於白白把規劃好的結構藏了起來，搜尋引擎完全接收不到。
4.3 先立骨架再寫，省下的是重排的成本
有人習慣邊寫邊想結構，但我們的經驗是，主結構先立好再動筆，長期省下的時間遠比看起來多。骨架沒先確認就開寫，很容易寫到第三節才發現它其實跟第一節重疊、或動線接不上前一節，這時候要動的不只是這一節，而是連帶好幾段的順序與銜接，改起來牽一髮動全身。大綱階段調整一個標題只是改一行字，正文階段調整一個段落卻可能要重寫前後文的過渡。我們通常把 H2 與 H3 的階層確認到只讀標題就通順，才讓它進寫作階段，途中真發現某節該拆該併，也只做小幅調整，不輕易動主結構。把糾結留在便宜的階段，是大綱這道工序最實際的價值。
5. 常見問題
5.1 一個 H2 底下大概放幾個 H3 合適
沒有硬性數字，常見是兩到三個。真正的判準是這個子主題底下有幾個值得單獨成節的問題。硬湊 H3 會讓內容變薄，該合併卻硬拆也會讓讀者繞圈。我們的做法是讓 H3 的數量由問題本身決定，而不是為了對稱去湊。如果某個子主題底下只問得出一個值得細講的問題，那一個 H3 也沒關係，甚至可以直接把內容寫在 H2 底下不另開 H3；反過來若某群自然冒出四五個獨立問題，也不必硬砍成三個。
5.2 大綱該在動筆前完全定好，還是邊寫邊調
主結構最好在動筆前就定下來，細節可以邊寫邊微調。骨架若不先立好就開寫，很容易寫到一半發現段落重疊或動線混亂，回頭重排的成本很高。我們通常先把 H2 與 H3 的階層確認到自己滿意，再進正文，途中若發現某節該拆或該併，才小幅調整。換個方式說，大綱階段改一行標題很便宜，正文階段改一段卻要連帶重寫前後的銜接，把該糾結的決定留在便宜的階段，是這道工序最實際的省力之處。
5.3 怎麼判斷兩個小節是不是重複了
把兩節各自要回答的問題寫成一句話，如果這兩句話幾乎是同一個意思，就是重複。重複的節該合併，或把其中一節收斂到更明確的子問題。我們在審稿時常做這個動作，它比讀完整段內容再判斷快很多，也更不容易被換句話說的表面差異騙過。真的重複時，合併往往比刪除好，因為兩節各自可能有一兩句對方沒有的重點，合起來保留雙方的精華，再把標題收斂到那個共同的問題上，整段反而更完整。
5.4 讀者的問題找不齊怎麼辦
可以從幾個現成來源補：搜尋結果頁的相關提問、搜尋建議，以及這一頁在 Google Search Console 實際承接到的查詢。這些都是讀者真的打出來的字，比憑空想更貼近需求。若是全新主題還沒有數據，就先從相近主題的查詢與同類讀者的常見疑慮著手，上線後再用實際數據回補。問題的品質比數量重要，與其湊一堆籠統的大問題，不如找出幾個讀者真正會卡住的具體疑問，這幾個才是大綱最有價值的原料。
5.5 大綱列好了，標題文字還要再改嗎
要。大綱階段的標題先求邏輯清楚、一節一問；定稿前值得再回頭潤飾標題文字，讓它更貼近讀者的語氣、更能被掃讀。但潤飾的前提是不破壞既定的階層與一節一問的原則，文字服務結構，不是反過來。用讀者會說的話、帶著具體場景去寫標題，比用籠統的抽象詞更容易被點進來。潤飾時也可以順手檢查標題裡有沒有保留讀者會搜尋的關鍵語意，在通順和可被搜尋之間取得平衡，而不是為了漂亮把讀者會打的字全換掉。