一篇文章好不好讀、能不能排名,大半在動筆之前的大綱就決定了。我是吳承學,做 SEO 二十年,審過的稿子裡有一個共通現象:結構鬆散的文章,幾乎都是大綱階段偷懶,用「起承轉合」或「優點缺點」這種通用框架硬套,而不是從讀者真正的問題長出來。這篇專門談大綱怎麼列:如何把讀者的問題展開成 H2 與 H3、為什麼一個小節只解決一個問題、以及標題階層本身如何構成一頁的架構。這是規劃層面的功夫,不談逐句寫作。
一、大綱的原料是讀者的問題,不是你想講的重點
多數人列大綱是列「我想講什麼」,但會排名的大綱列的是「讀者想問什麼」。這兩者常常不一樣,而搜尋引擎服務的是後者。
1. 從讀者實際問出口的問題開始
我的做法是,在列任何標題之前,先把這個主題下讀者會實際問出口的問題全部倒出來。以一個居家學習類的主題為例,讀者會問的是:幾歲開始適合、每天要花多久、會不會跟原本的習慣衝突、教材怎麼挑、自己不擅長還能不能陪。這些帶著疑問語氣的句子,才是大綱的原料。用「產品特色」「使用方式」這種內部視角的分類起手,寫出來的東西往往離讀者很遠。
2. 問題從哪裡蒐集
問題不必憑空想。搜尋結果頁上的相關提問區塊、搜尋建議、以及 Google Search Console 裡這一頁實際承接到的查詢,都是現成的礦。我在實務上看過一頁的表現忽好忽壞,把 GSC 的查詢逐條攤開後才發現,讀者真正在問的角度跟原本大綱設想的差了一截:編輯以為讀者關心的是規格,實際搜進來的字卻大量集中在「適不適合、會不會出問題」。把真實查詢當原料,大綱才不會自說自話。除了工具,身邊非專業的親友也是好來源,他們對這個主題的直覺提問,往往比內部人更貼近一般讀者的認知起點。
3. 幫問題排優先序
問題倒出來之後不是照單全收,要分主次。哪些是這一頁非回答不可的核心問題,哪些是延伸、可以簡短帶過或留給 FAQ,先分清楚。核心問題撐起 H2,延伸問題往下放。這個排序其實就是在替讀者決定閱讀的先後,值得花時間想。
二、把問題群組化,長成 H2 與 H3 的層次
單一問題還不是結構。要把一堆問題按關聯性歸群,大群變成 H2,群裡的子問題變成 H3,層次自然就出來了。
1. 相近的問題歸成一個 H2
把倒出來的問題攤在眼前,你會發現有些天然是一夥的:關於「怎麼挑」的幾個問題可以歸成一個 H2,關於「怎麼開始」的幾個歸成另一個。每個 H2 代表一個唯一的子主題,群與群之間界線要清楚,不要重疊。分類模糊或互相交疊,是我看過最傷結構的問題之一,讀者會在相似的段落間繞圈,搜尋引擎也難判斷各段各自負責什麼。
2. 子問題往下拆成 H3,不跳級
一個 H2 底下,通常配兩到三個 H3,對應這個子主題裡更細的問題。層次要逐級遞進,H2 之下接 H3,不要從大標直接跳到更小的層級。這條規則看似瑣碎,但標題階層一旦跳級或層次混亂,整頁的主從關係就糊掉了。下面這張表示範怎麼把讀者的問題轉成階層。
| 讀者的問題 | 歸入的 H2(子主題) | 展開成的 H3 |
|---|---|---|
| 幾歲開始適合?自己不擅長能不能陪? | 怎麼開始 | 適合的起步年齡;家長參與程度怎麼拿捏 |
| 教材怎麼挑?居家和線上差在哪? | 怎麼挑選 | 挑選的核心準則;不同型態的適用情境 |
| 每天花多久?會不會半途而廢? | 怎麼維持 | 合理的頻率;常見的中斷原因與對策 |
3. 用讀者的閱讀動線決定 H2 的先後
H2 的排列順序不是隨意的,該照讀者的思考動線走。多數人是先想「這適不適合我、怎麼開始」,再問「那我該怎麼選」,最後才關心「選了之後怎麼維持」。大綱的順序若貼著這條動線,讀者一路讀下來很順,前一節的答案剛好帶出下一節的疑問;順序若亂跳,就算每一節內容都對,整體也會讀得卡,讀者得自己在段落間來回找脈絡。我檢查動線的方法很土:把 H2 順著念一遍,想像自己是第一次接觸這主題的人,看會不會在某個轉折覺得「怎麼突然跳到這裡」,只要有這種卡頓感,順序就還能再調。
三、一個小節只解決一個問題
大綱最容易失守的地方,是一個標題底下塞了太多問題。守住「一節一問」這條線,整頁的清晰度會差很多。
1. 標題若要用「和」連接兩件事,多半該拆
我的做法是檢查每個標題,如果它得用「和」「與」把兩個不同的問題勉強綁在一起,那通常是訊號:該拆成兩節。一節只回答一個問題,讀者才能靠標題精準跳到要的地方,搜尋引擎也更容易把這一段對應到某個查詢。一節混答多題,結果常是每個問題都答得不清不楚。
2. 每節都要有實質觀點,不要換句話說
拆節之後要小心另一個反效果:為了湊出節數,把同一件事換句話說放進不同小節。每個小節都要有它自己的實質內容,若兩節講的其實是同一件事,該合併而不是硬撐。大綱階段就把重複的節揪出來,比寫完再刪省力得多。
3. 延伸與長尾問題留給收尾段落
不是每個問題都要進正文。那些讀者會問、但放進正文會打斷主線的延伸問題,適合集中到文末的問答段落處理。這樣正文的每一節都能專注在核心問題上,動線不被瑣碎的枝節切斷。哪些進正文、哪些往後放,在大綱階段就先分好。
四、標題階層本身就是這一頁的架構
把上面的步驟做完,你其實已經得到了一份內容地圖。標題階層不只是排版,它是搜尋引擎理解這一頁主題結構的依據。
1. 只看標題就要能讀懂整頁在講什麼
檢驗大綱好不好的一個簡單方法:把所有 H1、H2、H3 單獨抽出來排成一串,只讀這串標題,能不能看懂整頁的邏輯與涵蓋範圍。如果只看標題就通,讀者掃讀時能靠標題導航,搜尋引擎也能靠這個階層抓到主從關係。若抽出來一團亂,內文寫得再好也救不回結構。
2. 標題階層也要對應可被抓取的 HTML
大綱最後要落到正確的標籤上:每頁一個 H1,H2 與 H3 逐層對應,而且這些標題要真的用語意化的標題標籤寫,而不是用加大加粗的文字假裝。搜尋引擎靠標籤判斷層級,用樣式做出來的假標題,它讀不出階層。這一步是把規劃好的架構,如實交給搜尋引擎。
五、常見問題
一個 H2 底下大概放幾個 H3 合適
沒有硬性數字,常見是兩到三個。真正的判準是這個子主題底下有幾個值得單獨成節的問題。硬湊 H3 會讓內容變薄,該合併卻硬拆也會讓讀者繞圈。我的做法是讓 H3 的數量由問題本身決定,而不是為了對稱去湊。
大綱該在動筆前完全定好,還是邊寫邊調
主結構最好在動筆前就定下來,細節可以邊寫邊微調。骨架若不先立好就開寫,很容易寫到一半發現段落重疊或動線混亂,回頭重排的成本很高。我通常先把 H2 與 H3 的階層確認到自己滿意,再進正文,途中若發現某節該拆或該併,才小幅調整。
怎麼判斷兩個小節是不是重疊了
把兩節各自要回答的問題寫成一句話,如果這兩句話幾乎是同一個意思,就是重疊。重疊的節該合併,或把其中一節收斂到更明確的子問題。我在審稿時常做這個動作,它比讀完整段內容再判斷快很多。
讀者的問題找不齊怎麼辦
可以從幾個現成來源補:搜尋結果頁的相關提問、搜尋建議、以及這一頁在 Google Search Console 實際承接到的查詢。這些都是讀者真的打出來的字,比憑空想更貼近需求。若是全新主題還沒有數據,就先從相近主題的查詢與同類讀者的常見疑慮著手。
大綱列好了,標題文字還要再改嗎
要。大綱階段的標題先求邏輯清楚、一節一問;定稿前值得再回頭潤飾標題文字,讓它更貼近讀者的語氣、更能被掃讀。但潤飾的前提是不破壞既定的階層與一節一問的原則,文字服務結構,不是反過來。