Schema Markup 是用 Schema.org 詞彙描述網頁實體與屬性的結構化資料標記。它能補充機器可讀資訊，但不保證搜尋排名、複合結果或 AI 引用。實作重點是資料正確、與可見正文一致，再分別驗證語法、平台支援與實際搜尋表現。
2026 年 9 月查核更新：Google 已停止 FAQ 複合搜尋結果；FAQPage 仍可描述問答內容，但不能再以 Google 搜尋結果中的可展開 FAQ 作為交付承諾。Google 官方更新
Schema、JSON-LD 與搜尋效果是不同的事
Schema.org 定義詞彙，例如 Organization 表示組織，name 表示名稱；JSON-LD 則是表達這些資訊的一種格式。搜尋平台是否支援某種展示功能，是另一層規則。
| 檢查層次 | 要回答的問題 | 不能據此推定 |
|---|---|---|
| 資料語法 | JSON 是否可解析、屬性使用是否合理？ | 內容一定真實 |
| 頁面一致性 | 名稱、價格、作者、問答是否與正文相符？ | 平台一定索引 |
| 功能資格 | 是否符合目標平台的類型與品質要求？ | 一定展示複合結果 |
| 實際成效 | 是否出現搜尋展示、點擊或明確引用？ | 都是 Schema 單獨造成 |
Google 建議在適合的架構下使用 JSON-LD，但也支援 Microdata 與 RDFa。選擇能持續維護的格式，避免多個外掛各自輸出矛盾資料。Google 結構化資料介紹
依頁面內容選類型，不以數量當成品質
| 頁面內容 | 可評估的 Schema.org 類型 | 應先確認的資訊 |
|---|---|---|
| 公司介紹 | Organization | 正式名稱、網址、標誌、公開聯絡方式 |
| 服務介紹 | Service | 服務提供者、內容範圍與適用區域 |
| 文章或新聞 | Article 或適用子類型 | 標題、作者、發布日、實質更新日 |
| 商品頁 | Product 及適用的 Offer | 商品身分、現行價格、幣別與供應狀態 |
| 在地商家 | LocalBusiness 或適用子類型 | 商家名稱、地址、營業時間與聯絡方式 |
先查 Schema.org 詞彙，再查目標平台的功能文件。有效的 Service 或 DefinedTerm 不等於 Google 有對應搜尋特效；也不應將一般文章包裝成商品，只為取得評分星號。
FAQPage 與 HowTo 可以表達真實存在的問答和步驟。Google 的 HowTo 複合結果已於 2023 年停止，FAQ 複合結果自 2026 年 5 月 7 日起停止顯示。保留正確語意標記與承諾搜尋特效是兩回事。HowTo 官方公告、FAQ 官方更新
可照做的 JSON-LD 實作流程
步驟 1：整理頁面上可確認的事實
先列出頁面公開資訊與維護來源：公司名稱由誰確認、服務價格在哪裡更新、作者是誰、日期代表發布還是內容修訂。沒有證據的成果、評價與專業資格，不應只塞進標記中。
步驟 2：以適用類型描述資訊
以下是虛構公司的教學範例，不是優創智能的實際公司資料；部署前必須換成正文可見且已確認的資訊：
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "範例公司",
"url": "https://example.com/",
"telephone": "+886-2-0000-0000"
}
Organization 是類型；telephone 是小寫的屬性，值是文字，不存在把電話標成 Telephone 類型的做法。本例只示範語法與關聯，不代表任何搜尋功能的完整必填清單。Schema.org telephone 定義
步驟 3：輸出到頁面並保持同一份資料來源
JSON-LD 通常放在 HTML 的 script type="application/ld+json" 元素內。CMS 或網站程式可以從文章、商品或公司資料生成標記；應讓正文與標記共用資料來源，減少價格更新後兩邊不一致的情況。
使用 WordPress 等 CMS 時，先確認目前主題與外掛已輸出什麼，再新增設定。手動程式與外掛同時輸出不一定有問題，但同一組織或商品若有不同名稱、價格或網址，必須釐清維護來源。
步驟 4：分別驗證語法、功能資格與正文
- Schema Markup Validator：檢查 Schema.org 標記與詞彙使用，不代表通過 Google 搜尋功能要求。
- Google Rich Results Test：檢查 Google 支援的複合結果類型，部分類型提供預覽；不是所有 Schema.org 類型的總驗證器。
- 實際開啟頁面：逐項核對內容。工具不能替你證明客戶成果、作者資格或商品價格真實。
「未偵測到可用的複合結果」不必然代表所有 JSON-LD 無效；可能是使用的類型沒有對應功能。反過來，工具無錯誤也不保證實際展示。Google 結構化資料品質指南
步驟 5：部署後重新讀取與追蹤
檢查正式網址實際輸出的 HTML，不只看開發環境。再以適用的 Search Console 報告與網址檢查確認 Google 所見版本；強化項目報告不是全站所有 Schema.org 類型的清單。
將技術驗收和成效驗收分開記錄。例如：「正式頁面 Article 的作者與日期正確」是技術驗收；「同一期間自然搜尋點擊增加」是觀測結果。若同時改了內容、標題、內部連結或廣告，不能將變化全部歸因於 Schema。
Schema 對 GEO 能做什麼、不能證明什麼？
Google 明確表示，AI Overviews 與 AI Mode 沿用搜尋基礎要求，不需要特殊 AI 文字檔或專用 Schema。正確的結構化資料可以補充內容描述，但「沒有 Schema 就不能被 AI 引用」或「某四種 Schema 最有效」都不是可通用的驗收規則。Google AI 搜尋功能文件
不同引擎的使用方式不能由 Google 文件推定。評估 ChatGPT 或 Perplexity 時，應保留固定問題、日期、引擎模式、原始回答與引用網址，分開記錄品牌提及、本站引用及指定頁面引用。沒有完整來源就標記未知，不能把答案中出現品牌名稱直接當成引用成功。
在內容上，優先提供能獨立理解的直接答案、適用限制與可查證來源。Schema 的資料量也應受控：避免把整站文章或重複問答塞到每頁，並實測 HTML 大小與載入情況，不宣稱成本永遠可以忽略。
委外時可以怎麼驗收？
要求交付頁面清單、使用類型、資料維護位置、正式網址與驗證結果。抽查價格、作者、日期及問答是否與正文相符；另列尚未支援、尚未索引或尚未觀測的項目。
若方案承諾「部署後一定出現星號、FAQ 展開或 AI 推薦」，先要求對應平台的現行文件及實際證據。技術標記的交付，無法替代搜尋平台自己的展示決策。
需要協助盤點現有標記與內容一致性，可預約 SEO／GEO 諮詢。
相關推薦與延伸閱讀
- ChatGPT 推薦競品怎麼辦？先查回答與來源，再修正內容：ChatGPT 推薦競品不等於品牌排名落後。用固定問題、完整來源與內容差異，判斷可改善的資訊缺口，避免從單次回答推論原因或保證推薦。本文提供三步檢查與修正流程：
- 競品被 AI 推薦，品牌 GEO 策略該如何安排？：從競品引用觀察建立品牌內容缺口清單，以需求、證據與維護成本安排 GEO 工作；分開驗收頁面修正、AI 引用與商業轉換，不承諾推薦。本文提供缺口工作表與三步做法：
- 一般商家為什麼要做 GEO？從被找到到被正確引用的落地指南：GEO 不只是大型企業的品牌工程。本文用一般商家的客戶旅程拆解 AI 搜尋能見度，提供可驗證的內容、存取、結構化資料與成效量測做法：建立商家事實表、讓每個服務都