H 標籤 SEO 怎麼做?從 Google NLP 機制到 H2 精選摘要設計的工程師筆記
H 標籤不只是格式工具,是 Google NLP 引擎用來分塊解析頁面的上下文邊界信號。本文引用 John Mueller 原文,拆解 contextual chunking 機制、H2 精選摘要設計原則與 GSC 三步驗證流程,給出 H1-H6 可執行的配置策略。
H 標籤 SEO 怎麼做?從 Google NLP 機制到 H2 精選摘要設計的工程師筆記
H 標籤(H1-H6)是 Google NLP 系統用來把一個頁面切割成可索引的語意區塊的主要邊界信號,不是關鍵字排名槓桿。你在 H1 塞進「最強 SEO 關鍵字」並不會讓排名提升,但如果 H tag 結構混亂,Google 就無法正確把你的內容與相關查詢配對。這篇筆記從 Google 的解析機制出發,拆解 John Mueller 的原文立場,再給出 H2 精選摘要設計、CMS 陷阱排查、GSC 驗證的操作方法。這是 On-Page SEO 完整指南裡 H 標籤的深度展開篇。
H 標籤是什麼?HTML 語意層與 SEO 信號
H 標籤是 HTML 規範定義的六級標題元素(H1-H6),核心功能是宣告文件的語意層級,不是視覺樣式。H1 是頁面最高級的主題宣告,H2 是第一層子主題,H3 是 H2 的進一步分解,以此類推。Google 的爬蟲讀取 HTML 時,會把這個層級結構對應到內容的上下文關係圖。
H1-H6 的語意差異
六個層級的語意重量並不均等:H1 定義整個頁面的中心主題,對 Google 理解頁面「是關於什麼的」有最直接的影響。H2 定義各個主要子主題,是精選摘要最常抓取的邊界節點。H3-H6 負責在 H2 定義的上下文內做進一步細分,語意影響範圍依次縮小。
| 層級 | 語意功能 | SEO 影響 | 建議數量 |
|---|---|---|---|
| H1 | 頁面中心主題宣告 | 最高:定義頁面 topical identity | 1(實務建議) |
| H2 | 主要子主題邊界 | 高:精選摘要抓取節點、NLP chunk 邊界 | 5-12(依文章長度) |
| H3 | H2 子主題的細分 | 中:補充 H2 上下文 | 不限 |
| H4-H6 | 深層細節分類 | 低:很少有獨立 SEO 信號 | 謹慎使用,避免混淆層級 |
H tag 與 CSS 偽標題的差異
常見錯誤:用 CSS class(如 .title-large)讓 <p> 或 <div> 看起來像標題,但這在 HTML DOM 裡沒有任何語意標記。Google 爬蟲讀的是 DOM 結構,不是渲染後的視覺樣式。視覺上看起來是大標題,但 HTML 裡是 <p>,Google 就只會把它當成普通段落。反過來,如果你用 H2 做了一個視覺上很小的字,Google 仍然會把它當成二級主題邊界。用 DevTools 的 Elements 面板確認實際 tag,不要相信後台編輯器的顯示。
Google 怎麼用 H 標籤解析頁面?
Google 使用 H 標籤做「contextual chunking」:把一個頁面切割成多個有上下文邊界的文字區塊,再分別評估每個 chunk 和不同查詢的關聯性。這解釋了為什麼一篇文章可以同時在多個不同查詢上出現,每個查詢對應的是不同的 H2 chunk。
Contextual Chunking 原理
Google 的 passage-level indexing(段落索引)在 2021 年正式上線(Google Search Central Blog,2021)。其底層邏輯是:每個 H tag 定義了一個上下文窗口的起點,窗口內的文字自動繼承這個 heading 的主題信號。如果你的 H2 是「H 標籤是 SEO 排名信號嗎?」,這個 H2 下方所有段落直到下一個 H2 出現之前,都會被 Google 理解為在回答這個問題。
這個機制的實踐意義:H tag 不存在時,Google 的 chunking 邊界變得模糊,整篇文章可能只被索引成一個大 chunk,無法精準配對到具體的子查詢。反之,H tag 結構清晰,每個 H2 定義一個明確的子主題,Google 就能把頁面的不同部分分別配對到不同的長尾查詢。
NLP 關聯性計算
Google 的 NLP 系統讀取 H tag 時,不是單獨計算「這個 heading 裡有沒有關鍵字」,而是把 heading 和它下方的正文一起作為輸入,判斷這個 chunk 在語意空間裡的位置。這意味著 H2 標題的詞彙選擇,直接影響哪些語意 SEO 關鍵字能被納入 Google 的語意判斷。
- H2 裡出現的詞語,會強化這個 chunk 和相關查詢的關聯性,但效果來自整個 chunk 的語意一致性,不是 H2 本身的 keyword density
- H2 和其下方正文的主題一致時,chunk 的語意信號更強;H2 說一件事、正文說另一件事,信號互相干擾
- 相鄰 H2 之間的主題跳躍會降低整篇文章的主題一致性分數
H 標籤是 SEO 排名信號嗎?John Mueller 原文拆解
H 標籤是強語意信號,但不是關鍵字排名信號。John Mueller 說的「strong signal」指的是「讓 Google 理解頁面哪個部分在講什麼主題」,不是「H1 裡的關鍵字直接影響排名」。這個區別很重要:誤解會讓人在 H tag 裡塞關鍵字,反而讓文章失去語意清晰度。
John Mueller 原文引用
2020 年 Google Search Central 的 AMA(Ask Me Anything)上,John Mueller 這樣說:
「A heading is a really strong signal telling us this part of the page is about this topic. And whether you use an H1, H2, H5 tag for that heading doesn't matter so much. What matters more is that you have those headings and that they're structurally there.」
來源:SEJ Google: Heading Tags are a Strong Signal(Search Engine Journal,2020)
拆解這段話的三個關鍵點:
- 「strong signal telling us this part of the page is about this topic」:H tag 的信號是主題定義,不是關鍵字密度增強
- 「whether you use H1, H2, H5 doesn't matter so much」:tag level 本身不是決定性因素,Google 能讀取層級但不死扣
- 「What matters more is that you have those headings and that they're structurally there」:H tag 存在、結構清晰,比用哪個 level 更重要
信號強 ≠ 關鍵字排名信號
「Strong signal」和「ranking factor」是兩個不同的概念。H tag 是 Google 理解頁面結構和主題的強信號,但不等於「H1 裡放關鍵字就能提升排名」。
| 信號類型 | H tag 是否屬於 | 實際作用 |
|---|---|---|
| 主題理解信號 | 是 | 幫 Google 理解頁面各部分在講什麼 |
| 結構清晰度信號 | 是 | 幫 Google 做 contextual chunking |
| 關鍵字密度信號 | 否 | H tag 不提升關鍵字權重 |
| 精選摘要觸發信號 | 是(H2 下方首段) | H2 下方直接回答段落是主要抓取點 |
參考 Yoast 的說明:How to use headings on your site(Yoast,2024)也指出 H tag 的核心價值在結構清晰,而不是關鍵字置入。
每頁只能有一個 H1 嗎?Google 立場 vs 實務建議
Google 的技術系統允許多個 H1,但 SEO 實務仍建議每頁只用一個 H1。這不是矛盾,而是「系統能容忍」和「最佳結構設計」的差距。
Google 允許多 H1 的原因
John Mueller 在 2020 年明確說過:「Our systems don't have a problem when it comes to multiple H1 headings on a page. That's a fairly common pattern on the web.」
Google 能容忍多 H1 是因為它讀的是整體結構信號,而不是 counting H1 tags。對 Google 來說,兩個 H1 只是兩個「high-level heading」,系統仍然能夠解析頁面主題。這在某些框架(如 HTML5 的 sectioning element 模型)裡是合法的設計。
為什麼實務仍建議只用一個 H1
即使 Google 不在意,多個 H1 對 SEO 有間接的負面效果:
- 主題信號分散:兩個 H1 讓 Google 需要猜測哪個才是頁面的核心主題。這不是 bug,而是設計不清晰。
- 使用者體驗:螢幕閱讀器依靠 H1 理解頁面主題。多個 H1 表示這個頁面沒有明確的主題焦點。
- CMS 偵測問題:大多數 SEO 工具和 CMS 外掛把多 H1 標記為錯誤,需要額外排查。
- 排名機制的邊際效應:當頁面主題信號不清晰時,Google 在配對查詢時需要做更多猜測,增加出現在非目標查詢的機率。
結論:Google 說「沒問題」不代表「是最佳做法」。每頁一個 H1,H1 清楚宣告頁面中心主題,是結構設計的最佳實踐。
H2 和 H3 的語意任務:關鍵字配置與共現設計
H2 的語意任務是劃定 chunk 邊界並宣告子主題;H3 是在 H2 定義的上下文內補充細節。關鍵字的配置邏輯應該從這個語意任務出發,而不是從「這個 heading 要放什麼關鍵字」出發。
H2 的關鍵字選詞邏輯
H2 的措辭決定了這個 chunk 會被 Google 配對到哪些查詢。選詞原則:
- H2 用讀者的實際問題或任務(問句或動作導向),而不是「XX 的重要性」或「XX 概述」這類無意圖的標題
- H2 裡的主要詞語應該和這個 chunk 內文的主詞保持一致,不要在 H2 說「H1 的設計」但正文在講「H2 的關鍵字」
- 長尾關鍵字可以自然出現在 H2,但不要為了放關鍵字把 H2 寫得語意扭曲
H3 的細節補充角色
H3 繼承 H2 的上下文,進一步細分某個面向。H3 的關鍵字應是 H2 主題的語意延伸,不應跳出 H2 的上下文範圍。常見錯誤:把 H3 用成另一個獨立主題的宣告,這等於在 H2 的 chunk 裡插入了一個主題不一致的子 chunk,干擾 Google 的語意解析。
相關詞的分布策略
從 SERP 研究得到的相關詞和同義詞(co-occurrence terms),應分布在整篇文章的不同 H2 chunk 裡,而不是集中在某一個 chunk。Co-occurrence 的分布越廣,語意覆蓋越完整,整篇文章對相關查詢族群的排名潛力也越高。這和 搜尋意圖分析裡提到的「意圖-內容對齊」有直接關係。
如何用 H2 設計觸發精選摘要?
精選摘要(Featured Snippet)最常從 H2 下方的第一個段落抓取。設計原則:H2 是問句,H2 下方第一段是 40-80 字的直接回答,接著再用後續段落補充細節和例子。這個結構讓 Google 的 passage extraction 系統能直接識別「可抽取的直接答案」。深入了解精選摘要觸發機制,可參考 精選摘要優化完整指南。
Extractable Answer 格式
一個符合精選摘要設計的 H2 chunk 結構:
- H2 用問句格式(例:「H 標籤是 SEO 排名信號嗎?」)
- H2 下方第一段:40-80 字直接回答(不用「在這一段我們要講...」、不用引言)
- 後續段落:補充細節、例子、例外情況、延伸閱讀
不可抽取 vs 可抽取 H2 首段對比
| 版本 | H2 首段寫法 | 精選摘要可能性 | 問題 |
|---|---|---|---|
| 不可抽取 | 「在這一章,我們要深入探討 H 標籤在 SEO 裡的多個面向,包括它作為排名信號的強度、關鍵字配置的策略,以及 Google 的實際立場...」 | 極低 | 這是目錄,不是答案。Google 無法確定這個 chunk 要回答什麼問題。 |
| 可抽取 | 「H 標籤是強語意信號,不是關鍵字排名信號。John Mueller 明確說明 heading 的核心功能是讓 Google 理解頁面各部分的主題,而不是提升關鍵字密度。」 | 高 | 無。直接回答,可獨立存在,符合 40-80 字範圍。 |
常見 H 標籤錯誤與 CMS 陷阱
大多數 H tag 錯誤不是設計時犯的,是 CMS 和主題自動插入的。在發布前用 DevTools 確認實際 DOM,比相信後台設定更可靠。
WordPress 的 H tag 陷阱
WordPress 常見的非預期 H tag 問題:
| 陷阱來源 | 問題描述 | 診斷方法 | 修正方式 |
|---|---|---|---|
| 主題側欄 Widget | 側欄的 Widget 標題預設輸出為 H2 或 H3,在文章頁面和文章正文的 H2 混在一起 | DevTools 搜尋 h2 tag,看非正文的 H2 |
修改 Widget 輸出 tag 為 <p> 或 <span> |
| 主題 Related Posts | 「相關文章」標題輸出為 H3,插入正文 H3 結構 | 查 theme 的 related posts template | 修改為語意上不帶 heading 功能的 tag |
| Page Builder | Elementor / Divi 的 section title 預設 H2,每個版塊都多一個 H2 | 逐一檢查每個 section 的 heading tag 設定 | 手動改 tag type 或用 CSS class 取代 |
| 多個 H1 | 文章標題是 H1,但主題也把網站名稱包成 H1 | DevTools 搜尋全頁 H1 | 修改主題 logo 或 site title 的 tag |
Webflow 和 Astro / Next.js 陷阱
現代框架的 H tag 陷阱通常在 layout 層:
- Webflow:所見即所得編輯器裡的「Heading」元素預設 H2,建新 section 時容易誤設;全局 navbar 的 logo text 有時包成 H1
- Astro / Next.js 共用 layout:如果 Layout 組件裡有 H1(例如 site title),而每個文章頁也有自己的 H1,就會出現每頁兩個 H1 的問題。解法:Layout 的 site title 改用
<p>搭配 CSS,或在每個文章頁 layout 裡做條件判斷
如何驗證網站的 H 標籤結構?
三步驗證流程:DevTools 確認 DOM 結構 → GSC 搜尋成效觀察 query 配對 → 線上 H tag checker 批量掃描。
Step 1:Chrome DevTools 確認實際 DOM
這是最可靠的方法,因為 DevTools 看到的是瀏覽器最終渲染的 DOM,包含 JavaScript 動態插入的 H tag:
- 開啟頁面,按 F12 進入 DevTools
- Elements 面板裡用 Ctrl+F 搜尋
h1,確認只有一個,且內容是這個頁面的主標題 - 繼續搜尋
h2,確認所有 H2 都是正文子主題,沒有 widget 或 layout 插入的 H2 - 用 Console 跑這段來取得全頁 H tag 清單:
['h1','h2','h3'].forEach(t=>document.querySelectorAll(t).forEach(e=>console.log(t,e.textContent.trim())))
Step 2:GSC 搜尋成效確認 query 配對
在 Google Search Console 的搜尋成效報表裡,篩選特定頁面,觀察 Google 把它配對到哪些查詢。如果有不預期的查詢出現(例如配對到和文章無關的子主題),通常是 H tag 結構有語意錯誤。
具體做法:GSC → 搜尋成效 → 點選「頁面」分頁 → 找到目標 URL → 查看配對的查詢清單。如果某個 H2 主題對應到高搜尋量查詢,可以考慮把那個 H2 的 chunk 做成獨立文章,透過 內部連結架構連回主文。
Step 3:線上工具批量掃描
對多個頁面做 H tag audit 時,可用 Screaming Frog SEO Spider(免費版 500 個 URL)的 H1 / H2 報表,一次找出:缺少 H1、多個 H1、H1 過長、H2 缺少。Google Search Console 教學裡也提到如何結合 GSC Coverage 報表做 URL 層級的 SEO 健康檢查。
H 標籤與 AI Overview 引用的關係
Google AI Overview 使用 passage-level 引用,在 EZBlog 的站內觀測中,H tag 結構清晰的頁面出現 AI Overview 引用的比例高於結構較鬆散的頁面(觀測期間 2026-03 至 2026-05,樣本量為 EZBlog 已發布文章,方向性參考,非因果結論)。被引用的段落多數位於 H2 下方的直接回答首段。
Passage-Level 引用機制
AI Overview 的引用單位是 passage(段落層級),不是整篇文章。Google 的 AI 系統在生成 Overview 時,從索引裡找最能直接回答問題的 passage,H tag 是定義 passage 邊界的關鍵信號。
兩個條件讓 passage 更容易被引用:
- H2 是問句格式,和 AI Overview 的觸發查詢語意接近
- H2 下方首段直接回答,可獨立存在(拿出這段話,不需要前後文也能理解)
實際觀測案例
EZBlog 的 Meta Description SEO 文章裡,「Meta Description 對 SEO 排名有影響嗎?」這個 H2 的首段在站內觀測中出現於 Google AI Overview(2026-04 和 2026-05 各觀測一次,查詢:「meta description seo 排名」)。該 H2 首段格式為直接回答:「Meta description 不是 Google 的排名信號,Google 官方已多次確認...」符合可獨立引用的格式條件。樣本量小,視為方向性參考。
結構清晰的 H tag + 可獨立引用的 H2 首段,是目前可觀測到的 AI Overview 引用的兩個主要觸發條件。這和 Title Tag SEO 裡提到的 Google 改寫機制同屬「Google 從結構化文字中抽取片段」的同一個底層邏輯。
趙品翰
內容工程技術顧問
擁有 8 年以上技術 SEO 與內容工程經驗。曾協助多家企業從零建立搜尋流量體系,專精於搜尋引擎演算法分析、大規模內容架構規劃與程式化 SEO 策略。透過數據驅動的方法,將複雜的搜尋排名機制轉化為可執行的技術方案。
相關文章
SEO URL 結構設計指南:五條核心規則與改 URL 的決策模型
學習 SEO URL 結構設計的五大規則,了解台灣市場的本地化重點,並掌握改 URL 的決策模型,避免流量損失。
圖片 Alt 屬性 SEO 指南:從 Google 理解機制到三類圖片的正確寫法
拆解 Google Googlebot 用 alt 屬性理解圖片的三重訊號機制,說明資訊型、裝飾型、連結型三種圖片功能角色的正確寫法差異與常見錯誤,提供 DevTools 與 Screaming Frog 批量稽查圖片 alt 缺漏的 3 步驟流程。
語意 SEO 關鍵字是什麼?從 LSI 到 Entity 的完整應用指南(2026 版)
深入解析語意 SEO 關鍵字真相,從 LSI 迷思到 Entity NLP 機制,提供台灣在地實例與覆蓋度檢查表,讓你的內容真正符合 Google 語意理解。