一年前，如果 Google 的 AI 摘要引用了一個網頁，四篇裡大概有三篇本來就排在搜尋結果的前十名。今年，Ahrefs 最新研究發現，這個比例只剩不到四成。就算你辛苦擠進排名前十，被 AI 摘要選中的機率，也比一年前掉了一大截。
背後真正在變的，是搜尋引擎評分的單位。它評的早就不是「這頁排不排得上某個字」，而是「這頁答不答得完一整叢問題」。這也是為什麼關鍵字叢集分析（Keyword Clustering）愈來愈重要，它把搜尋意圖相近的關鍵字歸成一組，用一篇內容通吃整組，不必為每個詞各開一頁互打。
先從最基本的關鍵字蠶食問題講起，再一路拆到查詢背後真正在發生什麼事、怎麼動手分群，最後落地成內容架構。
關鍵字蠶食是什麼？為什麼「一頁一詞」的舊做法會反咬自己？
多頁互搶同一批字、同一種搜尋意圖，搜尋引擎因此拿不定主意該推哪一頁，這在 SEO 圈叫關鍵字蠶食。它不是內容寫得不夠好，而是同一件事被拆成好幾頁講，權重被切碎，原本能衝上去的一篇強內容，變成互相扯後腿的好幾篇弱內容。
長久以來業界的標準做法是一個主詞配兩到四個支援詞，站小的時候好用也夠用。可是內容愈寫愈多，這套一頁對一頁的思路反而會回頭咬自己。想像一家公司陸續寫了三篇需求其實相同的文章，標題各自換了說法，讀者要解決的問題卻是同一件事，搜尋引擎看著三頁高度相似，分不出該推哪一頁，結果流量沒有變多，寫作的時間反而多花了好幾倍。
叢集思維把這件事反過來解。很多看起來不同的字，講的其實是同一個搜尋意圖；既然意圖相同，就該用同一頁服務，不必各開一頁互打。把相關的字收進同一組、一組對一頁，每頁都有清楚而獨特的目標，蠶食自然沒了發生的空間，而這正是關鍵字叢集分析要做的事。
查詢擴散傳遞是什麼？AI 搜尋怎麼把一句提問拆成十幾個子查詢？
只是這幾年蠶食變得更棘手，原因不是 Google 變嚴格了，而是它評分的方式整個換了一套邏輯。Google 的官方文件把這個機制正式命名為查詢擴散傳遞功能，說明 AI 摘要與 AI 模式在產生回覆時，會針對子主題和資料來源發出多個相關搜尋，藉此找出更多相關網頁，讓顯示的連結比傳統網頁搜尋更廣泛多元。SEO 圈則更常直接用英文說法「Query Fan-out」稱呼它。
這不是行銷話術。Google 有一份專利描述過一套系統，用訓練過的生成模型，根據原始查詢的內容主動產生多種查詢變體，包括意思相近的說法、可能的追問、更概括的問法，以及需要釐清的版本，各自拿去搜尋，再把結果綜合成一段回答。
它實際擴散到什麼規模，Seer Interactive 用 Gemini 3 的 API 實測過五百多組提問，發現每個提問平均會被拆成 10.7 條子查詢，比上一代 Gemini 2.5 的 6.01 條成長了 78%。最少的一組只拆出 3 條，最多一組拆到 28 條。
子查詢平均 10.7 條，都在查些什麼？
幾個數字能讓你更具體感受這叢問題有多細。同一份研究發現，這些子查詢裡有 95% 在關鍵字工具裡幾乎查不到搜尋量，代表它們根本不是你平常在排關鍵字優先序時會鎖定的詞；平均每條子查詢有 6.7 個字，比一般關鍵字長得多，最長的一條甚至到 17 個字；整批子查詢彼此重疊的比例只有 1%，幾乎條條不同。另外還有兩個值得記住的比例：21.3% 的子查詢會帶上年份，26.4% 會帶上品牌名稱。
這代表 AI 打分的對象，早就不是一個詞，而是一整叢細到不能再細的追問。只守住主詞、不管這些追問，等於自動放棄了一大片評分範圍。
為什麼 AI 引用的頁面，不再是搜尋結果排第一的那頁？
把這層機制接回開頭那組數字，邏輯就通了。Ahrefs 這份分析八十六萬多組關鍵字、四百萬筆引用網址的研究裡，完整的分佈是這樣：被 AI 摘要引用的網址，37.9% 同時排進搜尋結果前十名，31.2% 落在第 11 到 100 名之間，剩下 31.0% 連前一百名都排不進去。這個比例跟一年前相比明顯掉了很多，代表 AI 摘要愈來愈少直接照抄搜尋結果前十名，愈來愈依賴子查詢那條線去挑來源。
另一份針對一萬組關鍵字、三萬三千條子查詢的獨立研究，替這個因果關係補上了證據。Surfer SEO 的分析指出，一個頁面在多少條子查詢裡排得上名，跟它會不會被引用之間，相關係數達到 0.77，算是相當高的正相關；同時排進主詞與至少一條子查詢的頁面，被引用的機率比只排進主詞的頁面高出 161%。更關鍵的一個數字是，有 68% 被引用的頁面，主詞和所有子查詢加起來都沒有進到搜尋結果前十名。
這正是叢集策略的價值所在。與其把力氣全部押在「這個主詞要排第一」，不如先確保這頁把整叢子查詢在問的角度都答到，被引用的機率自然墊高。
先切搜尋意圖，才輪得到分群
不過這裡有一條底線要先講清楚，免得叢集做成大雜燴。動手分群之前，得先把整批字依搜尋意圖切成幾堆，同一意圖的字才放在一起談分群，這是最容易被跳過、也最容易出事的一步。
意圖大致分四類：資訊型是想學東西的問句、教學、定義；商業調查型是比較、評測、清單；交易型是準備下單或註冊；導航型是直接找某個品牌或目的地。如果你做的是有實體據點的生意，通常還要多切出一種本地型，鎖定「附近」「怎麼去」這類帶地點的搜尋。切好之後，分群只在同一個意圖堆裡進行，每一頁從一開始就為一種使用者狀態而生。
舉個例子，「什麼是 CRM」跟「購買 CRM 軟體」雖然都在講 CRM，前者想學知識，後者想下單，硬塞進同一頁，會做出一頁兩邊都討好不了的內容。分群的第一刀，永遠是先切意圖，再談相不相關。
三種分群方法怎麼選？語意、SERP 重疊、混合各適合什麼情況？
意圖切開之後，才輪到動手把同意圖裡的字分成一個個叢集。方法主要有三種，差別在於你看的是「字的意思像不像」還是「搜尋結果長不長得像」，或者兩者都看，沒有絕對的優劣，只有適不適合你現在的階段跟規模。
| 方法 | 怎麼分 | 強項 | 要注意的地方 |
|---|---|---|---|
| 語意分群 | 用向量計算字義相似度 | 快、可規模化，適合前期整理大量原始字 | 只看意思像不像，不保證使用者需求一致 |
| SERP 重疊分群 | 比對兩個字前十名結果重疊的網址數 | 反映搜尋引擎的真實判斷，決定合併或拆分頁面時最準 | 要即時搜尋結果資料，規模一大就慢又花成本 |
| 混合分群 | 先語意快篩，重點組再用 SERP 驗證 | 速度與精準兼顧 | 訊號衝突時仍需要人工判斷 |
一個健康的叢集長這樣：有一個清楚的頭部詞定義這組的主題，底下一批單一頁面就能順手回答的長尾變體，整組從頭到尾是同一種意圖，跟別組區隔得夠開、內容不會重疊。多數結構良好的叢集會落在五到二十個字、對應一頁；真正的檢驗標準不是數量，而是一篇內容能不能自然地把這組字全都答到、又不稀釋焦點。
語意分群，看字意像不像
語意分群靠的是向量（embedding）——把每個字轉成一串數字，數字愈接近，代表意思愈相近，這套方法能抓到「男鞋跑鞋」跟「男性運動鞋款」這種字面不同、意思卻一樣的組合。
實務上，現在多數團隊已經不是手動比對，而是靠 AI／embedding 工具在大量關鍵字裡自動抓相似度，相似度落在中高區間的字通常能分出乾淨的群，抓得太寬會把不同意圖的字混進同一組。這個方法的強項是快、可以規模化處理成千上萬個字，適合新主題起步、大量原始字要先整理出樣子的階段；缺點是它只看意思像不像，不代表搜尋引擎真的把它們當成同一件事。
SERP 重疊分群，看搜尋結果像不像
SERP 重疊分群看的是兩個關鍵字的前十名搜尋結果裡，有幾個是同樣的網址。重疊的網址愈多，代表 Google 自己就認定這兩個字在講同一件事，該收進同一組；重疊愈少，多半該各自開頁。門檻可以自己抓，只要求幾個共同網址，分出來的群就大而籠統；要求的共同網址數愈多，群就愈小愈精準。這個方法最貼近搜尋引擎真實的判斷，決定兩頁該合併還是各活、要不要調整網址結構時最準；缺點是需要即時的搜尋結果資料，規模一大就慢又花成本。
混合分群，先語意快篩再用 SERP 驗證
混合分群把前兩種方法接起來，先用語意方法快速把大批原始字分出初步群組，再挑決策成本高、規模較大的幾組，用 SERP 重疊驗證、修正邊界。這種做法適合要長期規模化產內容、又不想每次都燒搜尋結果查詢額度的情況；多數成熟團隊其實不會只選一種方法，而是探索期用語意快速鋪面，要做關鍵決策時再用 SERP 重疊收緊。
支柱頁、叢集頁與內部連結，要怎麼接住一整叢關鍵字？
字分好群之後，得替每一組指派一個家，內容架構常見的做法是三層。支柱頁扛範圍最廣、最高層的主題，本身不貪心去搶每個字，而是把權威分給周邊內容；叢集頁對應每一組分好的字，往單一子主題深挖，吃掉這組的長尾跟支援詞；支援內容更窄，處理詞彙解釋、資料頁這類細瑣查詢，再把權重往上送回叢集頁。關鍵原則是一組對一頁，每一頁都清楚知道自己屬於哪一叢、目標意圖是什麼，蠶食就被堵在源頭。
內部連結是這套架構真正活起來的地方。支柱頁跟叢集頁要雙向連，錨文字盡量用精準的字眼，別用「點這裡」這種空話浪費機會；重要的叢集頁最好從首頁三次點擊內就到得了，太深的頁面分不到什麼權重；每一頁都至少要有一條站內連結指進來，沒有連結指向的孤兒頁，等於不存在。Google 官方文件裡也把「讓使用者可透過網站上的內部連結輕鬆找到內容」列為 AI 摘要與 AI 模式時代仍然值得採用的基本原則之一，這件事並沒有因為 AI 搜尋而過時。
把內容寫成 AI 搜尋好取用的形狀
分群跟架構做對了，最後一哩要落在寫法上。直接答案放在最前面，別讓重點埋在三段鋪陳之後；每個小節盡量自成一段，能被單獨抽出來回答自己那個小問題，因為現在的搜尋會把單一段落獨立評分、獨立取用；多用清楚的定義句、編號清單、比較表格，內容讀起來像答案，就比較容易被當成答案。
Google 官方文件也把「確保重要內容以文字形式提供」列為 AI 功能時代仍然適用的基本做法，圖片和影片可以輔助，但核心資訊要有文字版本機器才讀得到。這些做法不必為了討好機器犧牲可讀性，剛好也是讓真人讀得順的做法。
分群做完之後，要怎麼驗證有沒有分對？
驗證一組叢集意圖對不對，有幾個現在就能自己動手做的方法。
最快的土方法，是拿這組的主關鍵字實際去搜一次，花兩分鐘掃前五名是什麼形態。如果清一色是清單、教學文，這組偏資訊型；如果跳出來的是產品頁、比較表，那就偏商業或交易型。再順手看一眼「其他人也問」，把它列出的鄰近問題對照自己的叢集，確認有沒有涵蓋到。
第二個方法更貼近現在的 AI 搜尋環境，做法是實際模擬一次自己主題的子查詢擴散，看看真正會被拆出來的問題，自己的叢集有沒有覆蓋到。Ahrefs 那篇研究就列出幾個現成的路子，像是 iPullRank 創辦人開發的免費工具 Qforia、把 Gemini API 接上網站爬蟲工具 Screaming Frog 跑一輪的工作流程，或是 WordLift 提供的 AI Visibility Fan Out 功能，各家做法不同，但目的都一樣，找出自己叢集還沒答到的角度。跑完一次，把漏掉的角度補進對應的叢集頁，比事後才發現排名掉了再回頭補救，成本低得多。
排名要爭的東西，早就不是「這頁排不排得上某個字」。當對手還在為單一詞彙互相消耗排名時，先把意圖切乾淨、把相關長尾收進同一頁、再讓內部連結把整叢綁成一個權威結構的人，等於在用搜尋引擎現在真正的計分方式在下棋。Ahrefs 那組數字說得很清楚，一年之內，AI 摘要引用來自搜尋結果前十名的比例，從七成六掉到不到四成，排名好本身早就不再是保證。
所以下次打開關鍵字工具，先別急著問「這頁要塞哪個字」，換個問法，問這頁服務哪一叢意圖，這叢問題有沒有答全。想清楚這件事，排名跟被引用的機率，多半會自己跟上來。