Schema Markup（結構化資料）是放在網頁中的機器可讀標記，用來說明頁面是甚麼、包含哪些實體及資料關係。Google 通常建議優先使用 JSON-LD，但正確標記不等於排名或 Rich Results 保證。一般而言，企業資料頁可評估 LocalBusiness，文章頁使用 Article 或 BlogPosting，而 FAQPage Rich Results 已於 2026 年 5 月正式棄用，不再在 Google 搜尋結果顯示展開式問答。所有 Schema 最終要用 Rich Results Test 及 Search Console 驗證。
網站有地址、電話、Blog 文章和 FAQ 版塊，但 Google 未必知道每段內容代表甚麼業務實體或頁面類型。這是結構化資料要解決的問題。
很多人以為貼上 JSON-LD 代碼後，搜尋結果就會自動出現星星評分、問答展開或 AI 推薦。這個期待本身就是問題所在：Schema 不是一個排名按鈕，Google 也明確說明正確標記不保證任何特定搜尋呈現。
本文的路線很直接：先分清 Schema Markup、Schema.org、JSON-LD 和 Rich Results 的關係，再按頁面用途選擇 LocalBusiness、Article 或 FAQPage，最後完成三步驟驗證。
Schema Markup、結構化資料、Schema.org 和 JSON-LD 有甚麼分別？
用一句話分清四個概念
這四個詞常被混用，但各自代表不同層次的東西：
- 結構化資料（Structured Data）：廣義概念，指用標準化格式描述頁面內容，讓機器可理解。
- Schema.org：由 Google、Bing、Yahoo 及 Yandex 共同維護的詞彙庫，定義如
LocalBusiness、Article、FAQPage等類型及其屬性。Schema.org 本身是詞彙，不是插件或工具。 - JSON-LD：一種表達格式，全稱 JavaScript Object Notation for Linked Data。用
<script type="application/ld+json">標籤把 Schema.org 詞彙寫成 JSON，放在頁面<head>或<body>中。 - Schema Markup：實際放在頁面上的標記，可以用 JSON-LD、Microdata 或 RDFa 格式表達。
| 概念 | 定義 | 是否為格式 | 常見誤解 |
|---|---|---|---|
| 結構化資料 | 機器可讀的頁面內容描述 | 否，是概念 | 等同 Schema Markup 或 JSON-LD |
| Schema.org | 跨搜尋引擎共用詞彙庫 | 否，是詞彙 | 以為是 Google 的插件或官方工具 |
| JSON-LD | 鏈結資料的 JSON 格式 | 是 | 以為是唯一合法格式 |
| Schema Markup | 頁面實際部署的標記 | 視格式而定 | 等同「一定會出現 Rich Results」 |
根據 Google Search Central 結構化資料入門文件，Google 通常建議使用 JSON-LD，因為較容易維護，但 Microdata 及 RDFa 同樣受支援。選擇格式時，以 CMS 和開發環境的實際能力為準，而不是單純追求「最新」。
為甚麼正確標記不等於排名或 Rich Results 保證？
Google 在 General Structured Data Guidelines 中明確說明：正確標記只代表頁面取得某些搜尋呈現的資格，不保證一定顯示，也不是直接排名因素。有資格和實際顯示之間，還有內容品質、頁面權威、技術可抓取性及 Google 的演算法判斷等多重門檻。
香港中小企網站應該先做哪一種 Schema？
用頁面用途選擇 LocalBusiness、Article 或 FAQPage
最常見的錯誤是把所有 Schema 類型都堆在同一頁，或者每頁都加上 LocalBusiness 和 FAQPage。正確做法是先確認這一頁的主要內容和主要實體，再選最貼合的 Schema 類型。
| 頁面類型 | 主要實體 | 可考慮 Schema | 需要確認的資料 | 不可承諾的結果 |
|---|---|---|---|---|
| 首頁、聯絡頁 | 業務身份、地址、聯絡方式 | LocalBusiness（有實體地點時） |
真實地址、電話、營業時間 | 地圖排名或知識面板保證 |
| Blog 文章頁 | 文章、作者、日期、圖片 | Article 或 BlogPosting |
標題、作者、圖片、發佈日期 | 進入 Top Stories 保證 |
| 真實 FAQ 內容頁 | 問題與官方答案 | FAQPage（有條件） |
問答必須在頁面真實可見 | Rich Results 展開（已棄用） |
首頁及聯絡頁
LocalBusiness 適合有真實可核實的實體地點、服務地區或商業地址的業務。如果是純線上服務、沒有公開地址，或業務性質不符合 Schema.org 的 LocalBusiness 定義，就不要強行套用。根據 Google LocalBusiness 文件，應優先選擇最具體的 subtype，例如 MedicalClinic、Restaurant 或 LegalService，而不是直接使用最廣義的 LocalBusiness。
Blog 文章頁
文章頁的主要實體是文章本身，選 Article 或 BlogPosting。兩者的主要差異在於用途：Article 涵蓋範圍較廣，BlogPosting 是 Article 的子類型，更貼近一般 Blog 內容。根據 CMS 和 Google 官方文件建議決定，標記中的所有欄位必須與頁面可見內容一致。
真實 FAQ 內容頁
FAQPage 只適用於網站提供官方問答、且問答在頁面上真實可見的情況。重要更新：根據多個可信報道，Google 已於 2026 年 5 月正式棄用 FAQPage Rich Results，FAQ 展開式問答不再在 Google 搜尋結果顯示。FAQPage 標記仍然是有效的 Schema.org 詞彙，可幫助搜尋引擎理解內容，但不應再以「顯示 FAQ 展開」作為部署目標。發佈前請重新核對 Google Search Central 的最新 FAQPage 說明。
LocalBusiness Schema：本地商戶頁面要標記甚麼？
先確認是否真的屬於 LocalBusiness
在實作之前，先問三個問題：這個業務有可公開核實的實體地點嗎？地址、電話和營業時間是否真實且目前有效？業務類型是否符合 Schema.org 的 LocalBusiness 定義？三個問題都是肯定答案，才開始部署。
不要為了本地 SEO 虛構地址或服務範圍，Google 品質規則明確禁止標記不可見或具誤導性的內容。
必須與建議欄位如何取捨
根據 Google LocalBusiness Structured Data 文件，以下是欄位分類：
| 欄位 | 必要 / 建議 | 說明 |
|---|---|---|
@context |
必要 | "https://schema.org" |
@type |
必要 | 最具體的業務 subtype |
name |
必要 | 業務正式名稱 |
address |
必要 | PostalAddress 子物件，含街道、城市 |
telephone |
建議 | 香港格式，例如 +852-XXXX-XXXX |
url |
建議 | 官方網站 URL |
openingHoursSpecification |
建議 | 真實營業時間，需定期更新 |
geo |
建議 | 緯度經度（GeoCoordinates） |
sameAs |
建議 | Google Business Profile 或社交媒體連結 |
JSON-LD 實作及常見錯誤
以下是最小結構示例，所有值需替換為已核實的真實資料：
{
"@context": "https://schema.org",
"@type": "[最具體的業務類型]",
"@id": "https://[你的網域]/",
"name": "[業務正式名稱]",
"url": "https://[你的網域]/",
"telephone": "+852-[電話號碼]",
"address": {
"@type": "PostalAddress",
"streetAddress": "[街道地址]",
"addressLocality": "[區域]",
"addressRegion": "香港",
"addressCountry": "HK"
}
}
常見錯誤包括：使用 Organization 代替 LocalBusiness（兩者不同）、填入已過期的電話或地址、把服務頁或文章頁也標記為 LocalBusiness，以及標記的內容在頁面上完全看不到。
Article Schema：Blog 文章應如何描述？
Article 與 BlogPosting 的頁面適用情況
Article 是較廣義的類型，適合新聞、報告及一般文章；BlogPosting 是其子類型，語意上更貼近 Blog 內容。根據 Google Article Structured Data 文件，兩者均可讓頁面取得 Top Stories 輪播及較豐富的搜尋呈現資格，但不保證進入。選擇時以 CMS 的 schema 輸出能力及內容定位為準，不要在同一頁混用兩種類型。
headline、image、author、datePublished 及 dateModified
| 欄位 | 必要 / 建議 | 注意事項 |
|---|---|---|
headline |
必要 | 與頁面 H1 一致，不超過 110 字元 |
image |
必要 | 必須是頁面上真實顯示的圖片 URL |
author |
必要 | 真實人物，配合 Person 及 url 指向作者頁 |
datePublished |
必要 | ISO 8601 格式，首次發佈日期 |
dateModified |
建議 | 只在內容實際更新時修改，不要為了 SEO 自動刷新 |
publisher |
建議 | Organization 子物件，含 name 及 logo |
文章內容、作者資料及日期必須一致
標記中的 headline、author、image 及日期必須與頁面上的可見內容完全一致。如果文章沒有顯示作者，就不要在 JSON-LD 填入作者。如果圖片沒有在頁面上顯示，Google 可能拒絕接受。dateModified 只應在內容有實質更新時才改動，單純為了讓「最近更新」看起來更新而刷新日期，不符合 Google 的品質規則。如需完善高轉換率網頁設計服務，包含正確的頁面結構和可見元素，是確保 Schema 與可見內容一致的技術基礎。
FAQPage Schema：有 FAQ 內容就一定應該加嗎？
FAQPage 與 QAPage 不可混用
FAQPage 和 QAPage 是兩個不同的 Schema 類型，適用情況完全不同：
- FAQPage：適用於網站提供的官方問答，答案由網站方撰寫，頁面上真實可見。
- QAPage：適用於單一問題並允許使用者自行提交答案的頁面（如論壇問答頁）。根據 Google QAPage 文件，QAPage 不是一般 Blog FAQ 的替代品。
把一般 FAQ 欄錯標為 QAPage，是常見的技術錯誤，不但不會帶來預期效果，還可能導致 Search Console 出現錯誤警告。
FAQ Rich Result 現況及不可保證的原因
Google 已於 2026 年 5 月正式棄用 FAQPage Rich Results。「FAQ 展開式問答」這個搜尋功能已不再在 Google 搜尋結果中顯示。這個決定反映 Google 持續調整哪些 Rich Results 對使用者真正有價值。FAQPage 作為 Schema.org 詞彙仍然有效，可幫助搜尋引擎理解問答結構，但不應再把「顯示 FAQ 展開」列為部署目標或向客戶承諾。
甚麼情況下應該不加 FAQPage
以下情況建議不部署 FAQPage：問答只在 CMS 後台存在、頁面上看不到；問答由使用者生成而非網站官方提供；或者頁面的主要用途不是 FAQ（例如服務頁只有一兩條問題）。只有頁面問答真實可見、由官方撰寫，才考慮部署，並在發佈前重新核對 Google Search Central FAQPage 最新說明。
如何用 Google Rich Results Test 驗證 JSON-LD？
第一步：確認標記放在正確頁面
在測試之前，先確認 JSON-LD 放在對應的正確頁面，而不是把 LocalBusiness 放在 Blog 文章，或把 Article 放在首頁。頁面的 robots.txt 沒有封鎖、沒有 noindex 標籤，且 JSON-LD 在實際渲染的 HTML 中可見，才能讓 Googlebot 正確讀取。
第二步：先用 Rich Results Test，再用 Schema Markup Validator
根據 Google 結構化資料測試工具說明，兩個工具有不同用途：
- Google Rich Results Test：測試頁面是否符合 Google 特定搜尋功能的資格，例如
Article的 Top Stories 資格。注意：FAQPage 的 Rich Results Test 支援已於 2026 年 6 月移除。 - Schema Markup Validator（schema.org/validator）：驗證 Schema.org 詞彙的語法是否正確，範圍較廣，但不反映 Google 功能資格。
兩個工具分開使用，因為「語法正確」和「符合 Google 功能資格」是兩個不同結果。通過 Schema Markup Validator 不代表 Google 一定會顯示 Rich Results。
第三步：發佈後用 Search Console 及 URL Inspection 監察
部署後，在 Google Search Console 的「搜尋結果外觀」報告查看有效和無效的 Schema 項目。使用 URL Inspection 工具確認 Googlebot 實際抓取到的版本，確保 JSON-LD 不因 JavaScript 渲染問題而缺失。建立一個簡單的監察時間表：發佈後第 14、30 及 60 日各檢查一次。
Schema Markup 對 SEO、GEO 和 AI Citation 可以做到甚麼？
能改善機器理解的地方
| 能做到的 | 不能承諾的 |
|---|---|
| 清楚說明頁面類型和主要實體 | 直接提升搜尋排名 |
| 幫助 Google 理解業務地址、聯絡方式及關係 | 保證進入 Top Stories 或知識面板 |
| 在符合條件時取得某些 Rich Results 資格 | 保證 AI Overview 或 AI citation |
| 改善問答結構讓內容更易被理解 | 保證 CTR 提升或轉換率改善 |
| 為實體建立更清晰的屬性描述 | 跨 AI 平台的推薦行為 |
不能承諾的排名、點擊及 AI 行為
根據 Google Search Central，結構化資料可協助搜尋引擎理解頁面內容，並在符合條件時取得較豐富的搜尋呈現。但 Google 本身沒有承諾任何排名影響，也沒有官方文件表明 Schema 直接影響 AI citation 行為。把 Schema 部署成 AI 推薦的捷徑，是對這個技術的誤解。LetsGetWeb 的技術 SEO、GEO 與 AIO 優化服務可協助評估 Schema 與整體搜尋策略的配合，但同樣不承諾 AI citation 或排名保證。
常見 Schema 錯誤：為甚麼標記正確仍然沒有 Rich Result？
根據 Google General Structured Data Guidelines，以下是最常見的問題：
| 錯誤 | 原因 | 修正方式 |
|---|---|---|
| 標記內容在頁面不可見 | 違反「標記與可見內容一致」原則 | 確保每個欄位值在頁面上有對應的可見文字或元素 |
| 頁面不是該 Schema 的主要用途 | 服務頁標記 Article，或文章頁標記 LocalBusiness |
按頁面主要內容選 Schema |
| 資料已過期 | 地址、電話、營業時間改變但未更新 | 建立 Schema 與頁面內容同步更新流程 |
| 使用了錯誤類型 | 把 QAPage 套在一般 FAQ |
重新確認頁面用途與 Schema 類型定義 |
| 頁面無法被 Googlebot 抓取 | robots.txt 封鎖或 noindex 標籤 | 用 URL Inspection 確認抓取狀態 |
| 語法通過但不符合 Google 品質規則 | Schema Markup Validator 通過，但內容品質不足 | 參考 Google 官方品質規則，不單靠語法驗證 |
「加更多 Schema」不是解決沒有 Rich Result 的答案。問題通常出在頁面可見內容、技術抓取性或欄位一致性，而不是 Schema 類型的數量。
LetsGetWeb 可以在哪個階段協助？
Schema Markup 的部署不是單次動作，而是需要持續維護的技術層。LetsGetWeb 提供代碼級 Schema 設定、網站技術 Audit、GEO/AIO 內容結構審核，以及從搜尋流量到查詢轉換的完整路徑評估，可作為 Schema 實作和整體技術 SEO、GEO 與 AIO 優化服務的切入點。本文由 LetsGetWeb 發布；服務範圍及正式報價以官方頁面及確認文件為準。
如有需要，可先預約網站技術健檢，確認頁面類型、Schema 實作缺口及追蹤設置，再決定是否部署。
When this is not the right fit
若你的網站只有一頁靜態內容、沒有可維護的 CMS 或開發支援、業務資料（地址、電話、作者）不完整，或主要目標是取得「排名保證」，先不要購買 Schema 執行服務。正確的順序是先完成網站內容、實體資料及追蹤需求盤點，之後 Schema 部署才有意義。
FAQ：Schema Markup、JSON-LD 和結構化資料
1. Schema Markup 是甚麼？ Schema Markup 是放在網頁中的機器可讀標記，使用 Schema.org 詞彙描述頁面實體和關係，幫助 Google 等搜尋引擎理解頁面是甚麼類型、包含哪些資料。正確標記不等於排名提升，也不等於 Rich Results 保證。
2. JSON-LD 是 Schema Markup 嗎？
JSON-LD 是表達 Schema Markup 的其中一種格式，使用 <script type="application/ld+json"> 標籤撰寫。Google 通常建議 JSON-LD，但 Microdata 及 RDFa 同樣受支援，不是唯一合法選擇。
3. Schema Markup 會直接提升 Google 排名嗎？ 不會。根據 Google 官方文件，Schema Markup 不是直接排名因素。它可協助 Google 理解頁面內容，並在符合條件時取得某些搜尋呈現資格，但不保證排名位置。
4. LocalBusiness Schema 應該放在哪些頁面？
應放在有真實、可公開核實的實體地點或業務資料的頁面，例如首頁或聯絡頁。純線上服務、沒有公開地址的業務，或服務頁、文章頁，不應強行套用 LocalBusiness。
5. Article 和 BlogPosting 有甚麼分別？
BlogPosting 是 Article 的子類型，語意上更貼近 Blog 內容。兩者均可讓頁面取得 Top Stories 資格，選擇時以內容定位和 CMS 輸出為準。所有標記欄位必須與頁面可見內容一致。
6. FAQPage 和 QAPage 有甚麼分別？
FAQPage 用於網站提供的官方問答頁，答案由網站方撰寫。QAPage 只適用於允許使用者自行提交答案的單一問題頁面，例如論壇。一般 Blog FAQ 不應標記為 QAPage。
7. FAQ Schema 是否一定會出現 Rich Result？
不會。Google 已於 2026 年 5 月正式棄用 FAQPage Rich Results，FAQ 展開式問答不再在 Google 搜尋結果中顯示。FAQPage 標記作為 Schema.org 詞彙仍然有效，但不應再以顯示 FAQ 展開作為部署目標。
8. 沒有程式員可以加入 JSON-LD 嗎？ 部分 CMS（如 WordPress 的 Yoast SEO 或 Rank Math）提供 Schema 設定介面，不需要直接寫程式碼。但複雜的自訂類型和多頁部署，建議由熟悉 HTML 的技術人員或開發者處理，避免輸出錯誤的 JSON 結構。
9. 應該用哪個工具驗證 Schema？ 先用 Google Rich Results Test 確認頁面的 Google 功能資格，再用 Schema Markup Validator（schema.org/validator）驗證詞彙語法。發佈後用 Google Search Console 的搜尋結果外觀報告及 URL Inspection 持續監察。
10. Schema Markup 是否保證 AI citation？ 不保證。沒有任何官方文件支持 Schema 可以保證 ChatGPT、Gemini 或 Perplexity 等 AI 平台的引用行為。清晰的實體描述和問答結構有助於內容被理解，但跨平台 AI 行為不在 Schema 的可控範圍內。
下一步：用頁面清單及驗證紀錄開始部署
部署前，逐一回答以下清單：
- 這一頁的主要內容及主要實體是甚麼？ 先確定，再選 Schema 類型。
- 需要的是
LocalBusiness、Article、BlogPosting、FAQPage還是不用新增類型？ 按頁面用途決定，不要堆疊。 - 每個欄位是否有真實、可見及目前有效的資料？ 沒有就不填，不要用佔位符上線。
- Rich Results Test 及 Schema Markup Validator 是否分別完成？ 兩個工具功能不同，都要做。
- 發佈後是否會用 Search Console 及 URL Inspection 監察？ 排程至少發佈後 14 及 30 日各一次。
- 是否明白標記通過不代表排名、Rich Result 或 AI citation 保證？ 這是管理預期的基本前提。
如果你不確定網站的頁面類型、實體資料或 Schema 驗證結果，可先預約網站技術健檢，再決定是否部署。技術標記配合清晰的轉換路徑，才能真正為業務帶來價值；這也是 LetsGetWeb 營收增長諮詢的核心思路。同時，可參考網站轉換率優化指南，了解 Schema 以外，網站如何把搜尋流量轉化為實際查詢。
Google 官方文件及驗證工具規則於 2026 年 10 月查閱，發佈前請重新核對現行要求。