學完這一堂課，你將能夠理解什麼是結構化資料標記以及它為什麼對 AI SEO 至關重要，掌握各種與 AI SEO 相關的 Schema 類型及其適用場景，學會如何為自己的網站添加正確的結構化標記，了解如何使用測試工具驗證標記的正確性，以及掌握常見的 Schema 實施錯誤及修正方法。透過本節的學習，你將能夠為你的網站建立完整的結構化資料體系，讓 AI 能夠更準確地理解和引用你的網站內容。
在深入探討結構化資料標記之前，讓我們先理解一個核心問題：AI 是如何理解網頁內容的？
當你在 Google 上搜尋某個問題時，Google 會派遣它的爬蟲程式拜訪你的網頁，讀取你的 HTML 程式碼，然後根據它讀到的內容來判斷你的網頁是關於什麼主題的。這個過程對於人類來說非常簡單——我們讀一段文字就能理解它的意思。但對於電腦來說，理解人類語言是一件極為困難的事情。
舉例來說，當 AI 讀到這段文字：「托斯卡尼莊園是一家位於台北信義區的義大利餐廳，由義大利主廚 Marco 創立，主打手工義大利麵和傳統托斯卡尼料理」，人類可以立刻理解這是一餐廳的基本資訊。但 AI 需要「理解」這段文字的結構——哪一個是餐廳名稱？地址是什麼？主廚是誰？提供什麼類型的料理？這些資訊對 AI 來說，並不是直接從文字中「看」出來的，而是需要經過複雜的解析和推斷才能理解。
這就是結構化資料標記存在的意義。結構化資料是一種標準化的格式，用來描述網頁內容的語義結構。當你在網頁中添加結構化資料標記時，你其實是在用 AI 能夠直接理解的方式告訴它：「這是一個餐廳的名稱，這是它的地址，這是它的營業時間，這是它的菜單」。
讓我們看一個具體的例子。假設你經營一家餐廳，沒有結構化資料的情況下，當 AI 讀取你的「聯絡我們」頁面時，它可能會看到這樣的文字：「我們的地址是台北市信義區忠孝東路五段 1 號，營業時間為週一至週五 11:00-21:00」。AI 需要經過自然語言處理解析才能理解這是餐廳的地址和營業時間。
但如果你添加了 LocalBusiness Schema，AI 會直接讀到這樣的結構化資料：「@type: Restaurant」、「name: 托斯卡尼莊園」、「address: 台北市信義區忠孝東路五段 1 號」、「openingHours: Mo-Fr 11:00-21:00」。這些資訊對 AI 來說是立即可理解的，不需要經過複雜的語義分析。
這就是為什麼結構化資料標記對 AI SEO 如此重要的原因。它讓你能夠精確地控制 AI 如何理解你的品牌資訊，確保當 AI 回答相關問題時，能夠準確地呈現你的品牌資訊。
說到結構化資料，就必須提到 Schema.org。Schema.org 是一個由 Google、Bing、Yahoo! 和 Yandex 等主要搜尋引擎共同推動的結構化資料標準。這個標準提供了一套共享的詞彙表，讓網站管理者可以用統一的方式標記他們的內容，讓所有搜尋引擎都能正確理解。
Schema.org 的運作方式很簡單。網站管理者在網頁中加入特定格式的程式碼，標記頁面中各種元素的類型和屬性。這些標記使用 Schema.org 詞彙表中的詞彙，讓搜尋引擎能夠直接理解內容的意義。
Schema.org 詞彙表涵蓋了非常廣泛的內容類型。從人物、組織、地點、產品、事件，到食譜、評論、FAQ、影片，幾乎所有常見的內容類型都有對應的 Schema 類型。每個 Schema 類型都定義了一組屬性，讓你能夠詳細描述該類型事物的各種特徵。
以餐廳為例，在 Schema.org 中有專門的「Restaurant」類型，它定義了餐廳可以擁有的各種屬性，包括名稱（name）、地址（address）、菜單（menu）、營業時間（openingHours）、價格區間（priceRange）、評級（aggregateRating）等。當你在網頁中使用 Restaurant Schema 並填入這些屬性時，搜尋引擎就能夠完整地理解你的餐廳資訊。
在 AI SEO 的脈絡下，Schema.org 結構化資料特別重要，因為它讓 AI 能夠直接「讀取」並引用你的品牌資訊。當使用者在 ChatGPT 上問「台北信義區有什麼好吃的義大利餐廳」時，如果你的餐廳使用了正確的 Schema 標記，ChatGPT 就能夠直接從你的標記中獲取餐廳名稱、地址、評價等資訊，並將其推薦給使用者。
在眾多 Schema 類型中，有幾個對 AI SEO 特別重要。讓我們逐一詳細介紹。
Organization Schema 是所有品牌都應該實作的基礎 Schema。它用來描述組織的基本資訊，包括名稱、Logo、聯絡方式、社交媒體連結等。這個 Schema 就像是你的品牌在網路上的身份證，讓 AI 能夠清楚地識別你是誰。
Organization Schema 的關鍵屬性包括：name（組織名稱）、logo（Logo 圖片網址）、url（官方網站網址）、sameAs（社群媒體和其他平台的連結陣列）、contactPoint（聯絡方式，包括電話和電子郵件）。對於有實體店面的企業，address 屬性也很重要。
實施 Organization Schema 時，有幾個要注意的重點。首先，Logo 應該是一個直接的圖片網址，而不是一個包含 Logo 的網頁。其次，sameAs 屬性應該包含所有你的品牌有官方帳號的社群媒體平台，這能幫助 AI 建立對你品牌的完整認知。第三，如果你的組織有多個營業地點，可以使用多個 Organization 實體或結合 LocalBusiness Schema 來標記。
對於有實體店面或營業地點的商家，LocalBusiness Schema 是不可或缺的。它專門用來描述本地商家或企業的基本資訊，包括名稱、地址、營業時間、地理座標等。這個 Schema 對於餐廳、零售店、診所、健身房等本地商家尤其重要。
LocalBusiness Schema 的關鍵屬性包括：name（商家名稱）、address（完整地址，包括街道、城市、區域、郵遞區號）、geo（地理座標，經度和緯度）、openingHours（營業時間，採用 ISO 8601 格式）、telephone（聯絡電話）、priceRange（價格區間）、aggregateRating（平均評分和評論數量）、review（評論內容）。
實施工商地址時，要特別注意地址格式的標準化。使用 Schema.org 定義的 address 屬性格式，包括 streetAddress、addressLocality、addressRegion、postalCode、addressCountry。營業時間的格式也需要遵循 ISO 8601 標準，例如 "Mo-Fr 11:00-21:00, Sa-Su 12:00-22:00"。
值得注意的是，LocalBusiness Schema 其實是一個更廣泛類型的集合。Schema.org 定義了很多更具體的本地商家類型，包括 Restaurant（餐廳）、Cafe（咖啡廳）、Hotel（旅館）、Store（商店）、MedicalClinic（診所）、FitnessGym（健身房）等。在可能的情況下，應該使用更具體的類型而不是籠統的 LocalBusiness。
對於電商網站和零售商，Product Schema 是提高 AI 可見度的關鍵工具。它用來描述商品的詳細資訊，包括名稱、描述、價格、庫存狀態、品牌、製造商等。當使用者在 AI 平台上詢問關於某類產品的推薦時，正確標記的 Product Schema 能夠幫助 AI 理解並引用你的商品資訊。
Product Schema 的關鍵屬性包括：name（產品名稱）、description（產品描述）、brand（品牌資訊，可以是 Organization 或 Brand 類型）、sku（庫存單位編碼）、offers（報價資訊，包括價格、貨幣、庫存狀態、URL）、aggregateRating（平均評分和評論數量）、review（評論內容）、image（產品圖片）。
在實施 Product Schema 時，有幾個常見的錯誤需要避免。第一個錯誤是讓價格資訊過期。如果你的產品價格會變動，記得定期更新 Schema 中的報價資訊。第二個錯誤是忘記標記庫存狀態。讓 AI 知道你的產品是否有庫存，能夠避免推薦缺貨的產品。第三個錯誤是使用過於簡略的產品描述。詳細的產品描述不僅有助於人類讀者，也能讓 AI 更好地理解並引用你的產品資訊。
對於發布新聞、部落格文章或其他內容的網站，Article Schema 是讓 AI 正確理解和引用內容的重要工具。它用來描述文章的元資料，包括標題、作者、發布日期、摘要、圖片等。當 AI 在回答相關問題時，它可能會引用標記了 Article Schema 的文章作為答案來源。
Article Schema 的關鍵屬性包括：headline（文章標題）、author（作者資訊，應該連結到 Person 或 Organization）、datePublished（發布日期）、dateModified（最後修改日期）、description（文章摘要）、image（主要圖片）、publisher（發布者，應該是 Organization）、articleBody（文章內容）。
實施 Article Schema 時，有幾個最佳實踐值得注意。首先，確保 author 屬性正確連結到作者頁面或組織頁面，這能幫助 AI 建立內容創作者的可信度。其次，記得標記文章的發布日期和修改日期，AI 傾向於引用較新的內容。第三，如果文章有主題標籤或分類，可以使用 keywords 屬性來標記。
FAQPage Schema 是 AI 非常喜歡引用的一種 Schema 格式。它用來標記常見問題頁面，讓 AI 能夠直接提取問答內容。當使用者在 AI 平台上問到 FAQ 中已經回答過的問題時，AI 可能會直接引用這些問答作為答案。
FAQPage Schema 的結構很特別。它是一個包含 questions 屬性的頁面，每個 question 都是一個 Question 類型的物件，包含 name（問題文字）和 acceptedAnswer（被接受的答案，包含 answerText 和 url 屬性）。
實施 FAQ Schema 時，要注意以下幾點。首先，每個問題和答案都應該是完整且自成一體的。即使脫離了原頁面的上下文，答案也應該能夠讓讀者理解。其次，答案中不應該包含過多的行銷語言，AI 傾向於引用客觀、中立的答案。第三，如果你的 FAQ 內容會更新，記得更新 Schema 中的資訊。
對於發布教程、指南或操作說明內容的網站，HowTo Schema 是讓 AI 正確理解並引用你的教學內容的有效工具。它用來描述步驟化的操作指南，包括標題、描述、每個步驟的說明和所需的工具或材料。
HowTo Schema 的關鍵屬性包括：name（指南標題）、description（簡短描述）、step（步驟陣列，每個步驟包含 text 屬性和可選的 image、url 屬性）、totalTime（完成指南所需的總時間）。如果指南需要特定工具或材料，可以使用 tool 和 supply 屬性來標記。
AI 在回答「如何做某事」的問題時，很可能會引用標記了 HowTo Schema 的內容。特別是當你的 HowTo 內容涵蓋了使用者實際會問的問題時，正確的結構化標記能夠提高被引用的機會。
了解了主要的 Schema 類型後，接下來要談的是如何實際將這些標記添加到你的網站上。目前最推薦的實作方式是使用 JSON-LD 格式。
JSON-LD 是 JavaScript Object Notation for Linked Data 的縮寫，是一種基於 JSON 的結構化資料格式。相較於早期的 Microdata 格式（將標記直接嵌入 HTML 標籤中），JSON-LD 有幾個顯著的優勢。
第一個優勢是「分離性」。JSON-LD 程式碼可以放在 HTML 的 head 區塊中，與頁面的可見內容分離。這讓程式碼更容易維護和更新，也讓非技術人員更容易理解和編輯。
第二個優勢是「靈活性」。由於 JSON-LD 是獨立存在的，你可以移動標記的位置或調整網站結構，而不需要修改結構化資料本身。
第三個優勢是「廣泛支援」。Google、Bing、Perplexity 等主要搜尋引擎和 AI 平台都完全支援 JSON-LD 格式。
讓我們看一個完整的 JSON-LD 範例，這是一個餐廳的 Organization Schema：
HTML
View
這個範例展示了 Restaurant Schema 的完整結構。注意幾個要點：第一行指定了 @context 為 "https://schema.org"，這告訴解析器我們使用的是 Schema.org 詞彙表。@type 指定了我們要標記的類型是 "Restaurant"。所有屬性都使用正確的 Schema.org 詞彙。地址使用了嵌套的 PostalAddress 類型。營業時間使用了 OpeningHoursSpecification 類型的陣列。評分使用了 AggregateRating 類型。
在實際實施時，記得將範例中的網址、電話、地址等替換成你的實際資訊。同時，確保 JSON 語法的正確性——缺少逗號或多餘的逗號都可能導致標記無法被正確解析。
現在讓我們詳細說明為你的網站實施工結構化資料的完整步驟。
在開始添加新的結構化資料之前，首先需要審計你現有的網站頁面，確定哪些頁面已經有了結構化資料，哪些還沒有。你可以使用 Google 提供的 Rich Results Test 工具來檢測任何網頁的結構化資料狀況。
審計時要注意的重點包括：首頁是否標記了 Organization 或 LocalBusiness？聯絡我們頁面是否標記了正確的商家資訊？產品頁面是否標記了 Product？部落格文章是否標記了 Article？常見問題頁面是否標記了 FAQPage？記錄下每個頁面的現狀，作為後續實作的參考。
根據你的業務類型和頁面內容，選擇最適合的 Schema 類型。參考前面的章節，了解每種 Schema 類型的適用場景和關鍵屬性。
選擇 Schema 類型時要考慮的因素包括：頁面的實際內容是否與該類型匹配？你的目標受眾會使用什麼樣的 AI 平台？該類型是否包含你希望 AI 理解和引用的所有資訊？如果不確定應該使用哪種類型，可以參考 Google 的結構化資料類型參考頁面。
根據選定的 Schema 類型，撰寫對應的 JSON-LD 程式碼。可以手動撰寫，也可以使用線上工具輔助。
撰寫時要特別注意以下幾點：確保使用正確的屬性名稱（遵循 Schema.org 詞彙表）。確保值的格式正確，例如日期應該使用 ISO 8601 格式。對於必填屬性，要確認都已填寫。對於可選屬性，根據實際情況決定是否需要。避免在內容中包含過多的行銷語言，保持資訊的客觀性。
撰寫完成後，使用 JSON 驗證工具檢查程式碼語法是否正確。JSON 對語法非常敏感，一個小錯誤就可能導致整個標記失效。
將驗證通過的 JSON-LD 程式碼嵌入對應的網頁中。最佳實踐是將程式碼放在 HTML 的 head 區塊中，這樣可以確保頁面載入時就會載入結構化資料。
對於使用 WordPress 或其他 CMS 的網站，可以透過以下方式添加結構化資料：使用專用的 SEO 外掛（如 Yoast SEO、Rank Math 等），它們提供了圖形化介面來添加基本結構化資料。使用自訂程式碼區塊，在 header.php 或其他適當的檔案中手動添加程式碼。使用專用的結構化資料外掛，如 Schema Pro 等。
結構化資料添加完成後，必須進行驗證和測試。強烈建議使用以下工具：
Google Rich Results Test 是 Google 官方提供的工具，可以測試你的頁面是否支援增強搜尋結果，以及結構化資料是否正確。輸入你的網頁網址，工具會顯示檢測到的結構化資料類型以及任何錯誤或警告。
Schema Markup Validator 是另一個由 Google 提供的工具，更專注於驗證結構化資料的語法正確性。它會詳細列出解析到的所有實體和屬性。
Bing Webmaster Tools 提供了類似的結構化資料檢測功能，確保你的標記在 Bing 搜尋中也能正確運作。
如果測試發現錯誤，根據錯誤訊息進行修正。常見的錯誤包括：缺少必要的屬性、屬性值格式不正確、JSON 語法錯誤等。修正後重新測試，直到沒有錯誤為止。
結構化資料不是一次性的工作，而是需要持續維護的。定期檢查以下事項：頁面內容更新時，相關的結構化資料也要同步更新。檢查是否有新的 Schema 類型適合你的業務。監測搜尋引擎的結構化資料指南是否有變化。追蹤 AI 平台的引用偏好是否有所改變。
建立一個結構化資料維護流程，確保這项工作不會被遺忘。
在實施工結構化資料的過程中，很多人會犯一些常見的錯誤。了解這些錯誤及其修正方法，能夠幫助你更順利地完成實施。
Schema.org 詞彙表會持續更新，增加新的類型和屬性。過時的類型可能不再被搜尋引擎和 AI 平台支援，或者無法完整表達你的業務資訊。
修正方法：定期檢查 Schema.org 的更新，使用最新的類型和屬性。如果發現你正在使用的類型已經被標記為「deprecated」，盡快遷移到新的類型。
很多人在實作 Organization 或 Product Schema 時，忘記了 image 屬性，或者只提供了相對路徑而非完整的 URL。
修正方法：確保所有 image 屬性都使用完整的絕對 URL，例如 "https://example.com/images/logo.jpg"。圖片應該是可直接存取的，尺寸足夠清晰。
營業時間的格式錯誤是非常常見的問題。AI 需要標準化的格式才能正確理解你的營業時間。
修正方法：使用 ISO 8601 格式，例如 "Mo-Fr 11:00-21:00"。如果餐廳在特定節日有不同營業時間，可以使用 separate 屬性來標記例外情況。
很多人在標記地址時只填寫了街道地址，忽略了城市、區域、郵遞區號等資訊。
修正方法：使用完整的 PostalAddress 類型，包含 streetAddress、addressLocality、addressRegion、postalCode、addressCountry 等所有屬性。確保地址格式符合你所在國家或地區的標準。
JSON 對語法非常敏感，缺少逗號、多餘的逗號、引號不匹配等問題都可能導致整個標記失效。
修正方法：使用 JSON 驗證工具檢查語法。也可以使用線上 JSON 格式化工具，讓程式碼更容易閱讀和發現錯誤。
很多人在標記時只提供最基本的屬性值，沒有充分利用 Schema 提供的豐富屬性。
修正方法：研究你使用的 Schema 類型定義的所有屬性，盡可能填寫所有相關的屬性。例如，Product Schema 有很多有用的屬性如 brand、mpn、gtin13 等，不要只填寫 name 和 description。
根據你的網站類型，結構化資料的實施重點會有所不同。
餐廳網站應該優先實作 Restaurant Schema 和 Menu Schema。Restaurant Schema 標記餐廳的基本資訊，包括名稱、地址、營業時間、評分等。Menu Schema 標記菜單資訊，包括品項、價格、描述等。記得為每道菜品添加詳細的描述和圖片。此外，確保營業時間的標記準確無誤，包括假日特別營業時間。
電商網站應該優先實作 Product Schema 和 Offer Schema。Product Schema 標記產品的基本資訊，包括名稱、描述、品牌、圖片等。Offer Schema 標記價格、庫存狀態、送貨選項等。如果你的網站有評論系統，記得標記 Review 和 AggregateRating。如果有多個變體的產品，可以使用 ProductGroup 來組織。
專業服務業網站應該優先實作 ProfessionalService 或 LocalBusiness Schema，以及 Person Schema（標記專業人士的背景）。記得標記服務項目、服務區域、價格範圍等。如果有客戶評價，使用 Review Schema 標記。確保聯絡資訊和營業時間正確標記。
B2B 軟體公司網站應該優先實作 SoftwareApplication Schema 或 Product Schema，以及 Organization Schema。記得標記軟體的功能、定價方案、系統需求等。如果有客戶案例或成功故事，使用 CaseStudy Schema 標記。確保技術支援相關資訊有正確標記。
內容網站應該優先實作 Article Schema 或 BlogPosting Schema。記得標記作者、發布日期、分類標籤等。如果內容涉及食譜，使用 Recipe Schema。FAQ 頁面使用 FAQPage Schema。如果有多種內容類型，可以為每種類型使用對應的 Schema。
本節的核心內容可以歸納為以下幾點。
結構化資料標記是一種標準化的格式，用來描述網頁內容的語義結構，讓 AI 能夠直接理解你的品牌資訊。
Schema.org 是由主要搜尋引擎共同推動的結構化資料標準，提供了一套共享的詞彙表。
與 AI SEO 相關的主要 Schema 類型包括 Organization、LocalBusiness、Product、Article、FAQPage、HowTo 等，每種類型都有其特定的適用場景。
JSON-LD 是目前最推薦的結構化資料格式，具有分離性、靈活性和廣泛支援等優勢。
實施結構化資料的步驟包括審計現有頁面、選擇適當的 Schema 類型、撰寫程式碼、嵌入網頁、驗證測試和持續維護。
常見的錯誤包括使用過時的類型、缺少圖片 URL、營業時間格式錯誤、地址資訊不完整、JSON 語法錯誤等。
不同類型的網站有不同的 Schema 實施重點，應該根據業務特性選擇最適合的類型。
回顧你的網站，評估目前的結構化資料實施狀況。
你的網站是否已經有任何類型的結構化資料？如果有，是哪種類型？
根據本節的學習，你認為最需要優先添加或改進的是哪種 Schema？
制定一個行動計劃，列出你將如何為你的網站實施工結構化資料，包括時間表和具體步驟。
把這些想法寫下來，這會成為你後續執行結構化資料工作的指引。
第十三節結束。
請繼續進修下一節，持續深化你的 AI SEO 知識與技能。
智學平台提供的所有課程內容、學習材料及相關服務均按「現狀」提供，不作任何明示或暗示的保證。平台不保證特定學習效果、技能掌握程度或就業結果，因個人學習能力、投入時間與實踐應用差異，學習成果可能有所不同。
平台可能包含第三方提供的內容或外部網站連結，這些內容與連結僅為方便學員而提供。智學平台不對第三方內容的準確性、完整性或及時性負責，也不對因使用此類內容或連結而可能產生的任何損失或損害承擔責任。
我們致力於提供穩定可靠的技術服務，但由於網路環境、設備兼容性等因素，平台可能出現暫時性的服務中斷、延遲或技術限制。智學平台將盡力減少此類情況，但不保證服務的連續性、無誤性或不間斷性。
我們嚴格遵守相關隱私保護法規，對學員個人資料進行保護。詳細隱私政策請參閱專門頁面。學員有責任妥善保管自己的帳戶資訊，並對帳戶下的所有活動負責。
智學平台保留隨時修改、暫停或終止任何服務內容的權利，恕不另行通知。平台也可能根據業務發展需要調整收費政策，但會提前公告並提供相應過渡安排。
在法律允許的最大範圍內，智學平台及其關聯方不對因使用或無法使用本平台服務而導致的任何間接、附帶、特殊、後果性或懲罰性損害賠償負責，包括但不限於利潤損失、數據損失、商譽損害等。
本免責聲明受中華民國法律管轄並據其解釋。任何因本平台或免責聲明引起的爭議，雙方應首先友好協商解決；協商不成的，應提交台北地方法院訴訟解決。
