Schema 標記是一段標準化的結構化資料區塊，通常以 JSON-LD 撰寫，你將它放在頁面的 script 標籤內，讓搜尋引擎能讀取你想讓它們理解的事實。這個標記不會改變訪客看到頁面的樣子；它會新增一層機器可讀的層級，讓爬蟲解析以辨識實體，例如 WebSite、Article、Organization、產品、事件或人物，以及將這些實體串連起來的屬性。一旦解析完成，這些事實就能驅動更豐富的搜尋結果功能，包括網站連結搜尋框、文章輪播、知識面板和評論摘要，端看頁面實際包含什麼內容。簡而言之，schema 標記的運作方式是為爬蟲提供一段明確、以詞彙定義的內容描述，否則這些內容只會以未加註解的 HTML 存在。
這套結構化資料背後的詞彙是由 Schema.org 維護，這是一個由主要搜尋引擎支援的協作專案。當你在頁面上撰寫 JSON-LD 時，你基本上是在宣告某個特定內容片段是什麼類型，例如類型為「NewsArticle」或「BlogPosting」的「Article」，然後列出 Schema.org 為該類型定義的屬於——headline、author、datePublished、image 等等。Google、Bing 及其他參與的爬蟲會辨識這些詞彙，並利用它們為你的頁面建立更清晰的模型。完整規格位於 schema.org，這是所有類型與屬性存在與關聯方式的權威參考來源。
Schema 標記的三個組成區塊
在產生任何程式碼之前，先了解每個 schema 標記區塊共有的三個元素會有所幫助。
- @context：指向 schema.org 詞彙的一行內容，幾乎都設定為「https://schema.org」。少了它，這個區塊就無法成為被認可的 schema 圖譜。
- @type：該區塊所描述的特定實體，例如「WebSite」、「Article」、「Organization」、「Person」或「Product」。選擇正確的類型決定了哪些屬於是有效的。
- 屬於：從該類型的 Schema.org 定義中取出的鍵值對。值可以是純文字字串、URL、日期、巢狀物件或物件陣列。
這三個區塊會被包在一個帶有 JSON-LD MIME 類型的 <script> 標籤內。由於這個 script 並非可執行的 JavaScript，也沒有任何 DOM 勾點，瀏覽器在視覺上會忽略它，而爬蟲則會直接讀取它。正是這種分離使 JSON-LD 成為 MDN 的 script 元素參考資料以及 Google 自身結構化資料文件中推薦使用的格式。
搜尋引擎如何讀取與使用標記
當爬蟲擷取一個頁面時，會解析 HTML 並尋找 JSON-LD 區塊。然後它會根據 Schema.org 詞彙以及該搜尋引擎自身的品質規則來驗證每個區塊。符合宣告類型且與可見頁面內容一致的屬於會被接受。與人類讀者在頁面上看到的內容矛盾，或驗證失敗的屬於，會被忽略或標記出來。
被接受的標記會餵入搜尋引擎的實體索引。正是這個索引驅動了強化版的結果版面。例如，一個帶有有效 headline、image、datePublished 和 author 的 Article 區塊，就符合文章複合式結果的資格。一個帶有 logo、name 以及社群檔案 sameAs 連結的 Organization 區塊，則可以餵入知識面板。一個帶有 SearchAction 的 WebSite 區塊，則能產生網站連結搜尋框。這些都不是單靠加入標記就能保證的；頁面必須真正包含你所描述的事實。
實務上的規則很簡單：schema 標記是一個標籤，而不是發明。如果你在標記中說某個頁面是 Jane Doe 發佈於 3 月 4 日的 Article，那麼 Jane Doe 必須以作者身份出現在頁面上，日期必須可見，且標題必須符合使用者看到的內容。標記無法創造頁面本身未呈現的事實。
WebSite、Article 與 Organization：選擇正確的類型
大多數網站平時只需要三種 schema 類型。下表比較了每種類型描述的內容以及它在網站中的位置。
| 類型 | 描述內容 | 典型位置 | 關鍵屬於 |
|---|---|---|---|
| WebSite | 整個網站，包含搜尋動作 | 首頁 | name、url、potentialAction (SearchAction) |
| Article | 個別的新聞、部落格或專題文章 | 文章 URL | headline、image、datePublished、author |
| Organization | 網站背後的公司、發佈者或品牌 | 關於頁面或首頁 | name、logo、url、sameAs（社群檔案） |
如果頁面是新聞文章，請使用 Article 類型搭配適當的子類型，例如 NewsArticle 或 BlogPosting。如果頁面代表公司，請使用 Organization。如果頁面代表整個網站，請使用 WebSite。把這些弄混——例如在產品頁上放了 Article 標記——是驗證錯誤的常見來源。
從可見頁面事實產生 JSON-LD 標記
為 WebSite、Article 或 Organization 產生一個乾淨、跳脫字元正確的 JSON-LD 區塊，最快的方法是使用 Schema 標記產生器。這個工具只會提示你填入那些應該已經出現在目標頁面上的事實，正確地跳脫輸出字元，並交給你一段可直接貼入 HTML 的 script。由於每個欄位都來自頁面本身，結果會更容易驗證，也更不容易失真。
逐步說明：建立一個 JSON-LD 區塊
- 開啟 Schema 標記產生器，從類型選擇器中選擇 WebSite、Article 或 Organization，讓相關欄位顯示出來。
- 蒐集目標頁面的可見事實：標準 URL、標題或網站名稱、作者或發佈者名稱、發佈日期，以及任何已出現在頁面上的圖片 URL。
- 只把這些事實輸入表單。所有 URL 欄位請使用絕對 URL（包含通訊協定），因為相對路徑在 JSON-LD 中無效。
- 複製產生的 JSON-LD script，將其貼到頁面 <head> 末端附近，或 </body> 之前的 <script type="application/ld+json"> 區塊中。
- 發佈頁面後，將上線 URL 跑過 Google 的複合式結果測試以及 Schema 標記驗證器，確認沒有警告或錯誤。
- 如果驗證標記出缺少的必要屬性，回到產生器，以頁面上實際出現的事實填入該欄位，重新產生後再次測試。
放置位置、跳脫與常見錯誤
JSON-LD 區塊擺在 HTML 的哪個位置，並不會改變爬蟲解析它的方式，但放在 <head> 中能讓標記更容易找到與稽核。script 標籤必須將其類型宣告為「application/ld+json」，且字串值內的每個雙引號都必須進行跳脫，這正是產生器為你處理的部分。如果你手動編輯輸出結果，請留意未跳脫的引號、結尾多餘的逗號，以及 JSON 內散落的 HTML 註解，這三種情況都會中斷解析。
其他錯誤在實際稽核中經常出現：
- 自創的屬於：使用了選定 @type 定義中沒有的鍵值。爬蟲會忽略未知的屬於，使標記變得不完整。
- 事實不符：標記中宣告的作者、日期或標題與使用者在頁面上看到的內容不一致。
- 相對 URL：提供「/logo.png」而非「https://example.com/logo.png」。JSON-LD 要求使用絕對 URL。
- 內容類型錯誤：將產品頁標記為 Article，或將部落格文章標記為 Product。
- 多個衝突的區塊：在同一個頁面上輸出兩個 Organization 區塊，但名稱或 logo 不同。
驗證與維護你的標記
標記上線後，驗證並不是一次性的工作。模板會改變、內容團隊會變動，有時 CMS 外掛會移除或改寫 <script> 標籤。一個實用的維護習慣是定期把一批重要 URL 跑過結構化資料驗證器，而不是只在明顯出問題時才跑。如果想瞄準的複合式結果新增了必要屬性，使用 Schema 標記產生器重新產生區塊，重新發佈後再重新測試。
標記也能與你其他技術 SEO 工作良好搭配。canonical 標籤會告訴爬蟲哪個版本的 URL 是權威版本；如果你有維護 canonical，可以參考我們的 canonical 標籤指南，遵循 canonical 連結的習慣，並只在該 canonical URL 上套用 JSON-LD。同樣地，一個乾淨的 meta description 與 Open Graph 區塊能改善頁面在其他地方的預覽方式；我們的 meta 標籤指南涵蓋了周圍的 head 區段，讓你的標記、元資料與 canonical 訊號彼此一致。
Schema 標記無法做到的事
值得先把期望講清楚。Schema 標記無法保證一定出現複合式結果，無法凌駕品質規則，也無法讓內容薄弱、重複或離題的內容獲得排名。它也無法取代良好的頁面寫作。它能做到的是消除模糊性。當爬蟲能讀出某個頁面是由特定作者在特定日期撰寫的特定類型 Article 時，它就能把該頁面安排進入比普通藍色連結更豐富的版面。頁面本身仍然必須自己爭取點擊。
謹慎使用之下，JSON-LD 提供了一種精確、以詞彙定義的方式，向搜尋引擎描述你的頁面。從頁面上已存在的事實來產生標記、正確放置、驗證上線的 URL，你的結構化資料就會在背景中默默地發揮作用。
若想深入了解，請參考如何從網站 sitemap 中擷取所有 URL。