支柱頁（pillar）與叢集頁（cluster）不是把權重灌給首頁的內部連結技巧。當檢索你內容的是 AI 引擎，這套結構要做的事很具體：把一個主題拆成一組乾淨、能獨立被抽取、彼此互指的頁面，讓模型判斷你的網站對這一題有前後一致的完整答案，而不是散在各處、互相打架的片段。
為什麼 LLM 檢索吃這套結構
AI 引擎回答問題時，不會把整個網站讀進去，而是先把頁面切成小段（chunk），轉成向量，再挑出和使用者問題最相近的幾段來組答案。這帶來兩個後果。第一，內容如果散在十幾篇彼此重複、定義又不一致的短文裡，每一段的訊號都被稀釋，模型抓到的可能是三年前那篇早該下架的版本。第二，模型傾向引用「看起來是這個主題權威來源」的頁面，也就是把定義、範圍、子題結構講清楚的那一頁。
支柱頁的工作，是成為那個權威節點：定義主題、界定範圍、列出所有子題，並把每個子題的深入內容連到對應的叢集頁。叢集頁則各自回答一個具體、長尾的問題，短到能被單獨抽出來當引用。分工清楚，訊號才不會互相稀釋。
支柱頁該寫什麼，不該寫什麼
常見的錯誤，是把支柱頁寫成一篇什麼都塞的五千字長文，想一次講完所有細節。這麼做會讓每個子題的訊號互相干擾，也讓叢集頁失去存在意義。支柱頁應該給主題的完整地圖：每個子題只留兩三段摘要，加一個明確的「看完整說明」連結，深入內容留給叢集頁去承接。
- 第一屏放一段可被直接引用的主題定義，40 到 80 字內講清楚「這是什麼、為誰而設」。
- 界定主題的範圍與邊界：涵蓋哪些子題、又刻意不談哪些。
- 每個子題一個小節，摘要加上連往叢集頁的描述性連結。
- 一張能總覽全貌的圖表或清單，讓讀者與引擎一眼看懂結構。
- 標示更新日期與負責人，讓引擎判斷內容的新鮮度。
叢集頁怎麼切題：繁中的實務差異
叢集頁的黃金標準是「一頁回答一個問題，抽出來也讀得懂」。判斷方法很簡單：把頁面標題貼進 ChatGPT 或 Perplexity，如果它想問的問題和你頁面回答的不是同一個，題就切錯了。繁體中文這裡有個容易被忽略的落差。台灣使用者搜尋「線上刻章」「發票載具」「勞健保級距」，用的語彙和中國大陸不同，斷詞方式也不同；如果內容策略直接沿用簡中關鍵字表，叢集頁會對到錯的問題。實務上，先用台灣在地的搜尋建議、社群提問與客服工單湊出子題清單，再回頭決定支柱頁的架構，而不是反過來。
內部連結：雙向，而且錨點要有語意
支柱與叢集之間要雙向連結：支柱指向每一個叢集，每個叢集也指回支柱，同群組的叢集之間再依語意相關性互指。錨文字（anchor text）用完整、有語意的短語，例如「繁體中文的斷詞與關鍵字選擇」，不要用「點這裡」或「了解更多」。對 LLM 來說，錨文字是理解兩頁關係的重要線索，含糊的錨點等於白白丟掉這個訊號。
讓爬蟲和 LLM 都抓得到
結構再漂亮，引擎抓不到就等於零。把可爬取性當成上線前的基本檢查表：
- 正文寫在 HTML 裡，不要靠使用者互動才觸發的 JavaScript 才渲染出內容。
- sitemap.xml 列出所有支柱與叢集頁，llms.txt 標出你希望被引用的核心頁面。
- 用語意化的 heading 階層（一個 h1、子題用 h2），讓引擎切 chunk 時邊界乾淨。
- 每頁自足：不預設讀者看過別頁，關鍵定義在該頁就講清楚。
- 對定義型與問答型內容補上對應的結構化資料（Article、FAQPage）。
一套可直接執行的建置順序
從零開始的話，順序會決定成敗。先有子題再有支柱，別倒過來：
- 盤點真實問題：從客服工單、業務常見問答與台灣在地搜尋建議，列出 20 到 40 個使用者真的會問的具體問題。
- 分群：把問題歸進 3 到 6 個主題群，每一群就是一個未來的支柱頁。
- 先寫兩三篇叢集頁試水溫，把正文貼進 AI 引擎測試可抽取性，確認切題正確再量產。
- 回頭寫支柱頁：用子題摘要串起已完成的叢集，補上描述性的雙向連結。
- 送出更新後的 sitemap 與 llms.txt，隔 2 到 4 週用能見度追蹤工具看哪些頁真的被 AI 引用。
- 依被引用資料回補：補齊沒被抽到的子題、改寫抽取率低的頁，讓內容中心持續長大。
支柱與叢集不是一次做完就結束的專案，而是會隨引擎引用資料持續調整的系統。多數團隊卡在最前面：不知道自己的內容中心到底缺哪些子題，也不知道哪些頁根本沒被 AI 讀到。想快速看清自己的結構缺口，可以預約 30 分鐘 GEO 診斷，我們會拿你的實際網站跑一次可抽取性與被引用狀況，指出該優先補的支柱與叢集。Tenten 的 GEO 內容引擎，也是照這套順序在替 B2B SaaS 客戶建立繁體中文內容中心。
