AI_SEO_專業課程_掌握答案引擎時代的流量革命





A09 第九節 結構化資料標記的基礎概念

Updated: 02/03/2026
Release on:05/02/2026

table of content




課程介紹與學習目標



歡迎來到第九節課程。在前面幾節的學習中,我們已經建立了對 AI SEO 的整體認知,了解了問答矩陣策略的建構方法,也探討了精準答案內容的製作技巧。從這一節開始,我們將進入一個相當重要但經常被忽略的領域——結構化資料標記。這個主題可能對沒有技術背景的學習者來說有些陌生,但它對於 AI 搜尋引擎理解您的網站內容具有關鍵性的作用。



什麼是結構化資料?簡單來說,結構化資料是一種用標準化格式來描述網頁內容的方式,讓搜尋引擎和 AI 系統能夠更準確地理解頁面上的資訊是什麼、代表什麼意義。想像一下,當您讀一篇文章時,您能夠理解標題、作者、發布日期、內容主題等資訊;但對電腦來說,網頁只是一堆文字和程式碼的組合,除非您明確告訴它們「這段文字是標題」、「那段文字是價格」、「這個日期是發布時間」,否則它們很難正確理解這些資訊的含義。結構化資料正是提供這種「翻譯」功能的機制。



本節課程的學習目標包含以下幾個面向。首先,您將能夠清楚解釋什麼是結構化資料,以及它在 AI SEO 中扮演什麼角色。其次,您將認識 Schema.org 詞彙庫,這是目前最廣泛使用的結構化資料標準。第三,您將了解幾種最常見的 Schema 類型,包括 Organization、LocalBusiness、Product、FAQPage 和 HowTo,並能夠說明它們的應用場景。第四,您將建立足夠的知識基礎,為後續的技術實作課程做好準備。



讓我們開始這段結構化資料的探索之旅。



table of content


結構化資料的定義與價值



在深入探討各種 Schema 類型之前,我們需要先建立對結構化資料的基本理解。結構化資料,顧名思義,就是「有結構的資料」。它是一種按照預定義格式組織資訊的方式,讓電腦系統能夠自動解讀和處理這些資訊的內容。



舉一個生活化的例子來說明。假設您需要向一位外國朋友介紹您居住的城市。如果您只說「台北是個很棒的城市,有很多好吃的食物和有趣的地方」,這對外國朋友來說資訊量有限,他很難據此規劃台北之旅。但如果您說「台北是台灣的首都,位於台灣北部,面積約271平方公里,人口約250萬,氣候屬於副熱帶季風氣候,主要語言是中文,主要宗教包括佛教和道教」,這些結構化的資訊就能讓您的朋友更清楚地了解台北的基本輪廓。結構化資料的作用正是如此——它為搜尋引擎和 AI 系統提供了這種清晰、標準化的資訊描述。



從技術上來說,結構化資料是基於一套預定義的詞彙庫(vocabulary)來描述網頁內容。這些詞彙庫定義了各種「類型」(type)和「屬性」(property),例如「人」(Person)這個類型可以有「姓名」(name)、「年齡」(age)、「職業」(jobTitle)等屬性;「產品」(Product)這個類型可以有「名稱」(name)、「價格」(price)、「品牌」(brand)、「評分」(rating)等屬性。當您在網頁上添加結構化資料時,您就是在告訴搜尋引擎:「這段文字其實是一個產品,它的名稱是這個、價格是那個、評分是這個數值」。



那麼,結構化資料對 AI SEO 有什麼具體價值呢?這個問題可以從幾個層面來回答。第一個價值是「提升內容被正確理解的可能性」。AI 系統在處理網頁內容時,會參考頁面上的結構化資料來輔助理解。當您的內容被正確標記時,AI 系統能夠更準確地判斷這篇內容是關於什麼主題、屬於什麼類型、包含什麼關鍵資訊。這直接影響到您的內容是否會被選中來回答使用者的問題。



第二個價值是「增加出現在豐富搜尋結果中的機會」。當搜尋引擎能夠理解您網頁的結構化資料時,他們可能會在搜尋結果中顯示更豐富的資訊,例如在產品價格旁邊顯示庫存狀態、在評分旁邊顯示評論數量、在食譜旁邊顯示烹飪時間。這些「豐富結果」(rich results)能夠顯著提高搜尋結果的點擊率,對網站流量有正面影響。



第三個價值是「為 AI 回答引擎提供可信賴的資訊來源」。當 AI 回答引擎需要回答一個問題時,它會在網路上尋找可靠的資訊來源。結構化資料就像是您向 AI 系統遞出的名片,上面清楚寫著「我是誰、我做什麼、我有什麼產品或服務」。這種清晰的自我介紹能夠增加您的品牌被 AI 系統選中作為答案來源的機會。



第四個價值是「建立品牌知識圖譜」。當您持續在網站上發布結構化資料時,這些資訊會逐漸累積,形成一個關於您品牌的完整知識圖譜。這個知識圖譜不只能夠幫助搜尋引擎理解您的品牌,也能夠被各種 AI 系統用來回答與您品牌相關的問題。例如,當有人問「這家公司提供什麼服務」時,AI 系統可以根據您之前發布的結構化資料給出準確的回答。



從歷史發展的角度來看,結構化資料的概念並不新鮮,但它在 AI 時代的重要性正在顯著提升。早期的結構化資料主要用於改善傳統搜尋引擎的搜尋結果呈現,但隨著 AI 回答引擎的興起,結構化資料的角色已經擴展到影響 AI 系統如何理解和引用您的品牌資訊。這也是為什麼在 AI SEO 的策略中,結構化資料從「加分項」變成了「必備項」。



table of content


Schema.org 詞彙庫解析



說到結構化資料,就必須提到 Schema.org。Schema.org 是一個由 Google、Microsoft、Yahoo! 和 Yandex 四大搜尋引擎巨頭共同推動的協作專案,於2011年啟動。這個專案的目的很簡單:建立一個統一、共享的結構化資料詞彙庫,讓所有網站都能夠使用相同的標準來描述內容,讓所有搜尋引擎都能夠用相同的方式理解這些描述。



在 Schema.org 出現之前,不同的搜尋引擎和平台各自發展了自己的結構化資料標準。Google 曾經推廣過自己的標記格式,Microsoft 有另一套做法,這種「百花齊放」的局面對網站經營者來說是個困擾——您需要為不同的搜尋引擎維護不同格式的標記,增加了複雜度和維護成本。Schema.org 的出現解決了這個問題,它提供了一個通用的標準,被所有主要搜尋引擎共同支援。



Schema.org 的詞彙庫涵蓋了非常廣泛的領域。從人物、組織、地點、事件,到產品、評論、食譜、教程,再到醫療健康、教育、娛樂等專業領域,Schema.org 定義了數百種不同類型的結構化資料。這些類型之間存在著階層式的關係,形成了所謂的「本體論」(ontology)。例如,「創意作品」(CreativeWork)是一個頂層類型,「文章」(Article)、「書籍」(Book)、「食譜」(Recipe)、「影片」(Video)等都是它的子類型;而「文章」(Article)又細分為「新聞文章」(NewsArticle)、「部落格文章」(BlogPosting)、「學術文章」(ScholarlyArticle)等。這種階層結構讓搜尋引擎能夠理解類型之間的關係,做出更準確的判斷。



每一個 Schema.org 類型都定義了一系列可以用來描述該類型的屬性。例如,「產品」(Product)類型可以使用的屬性包括:name(名稱)、description(描述)、image(圖片)、sku(庫存單位)、brand(品牌)、offers(供應資訊)、aggregateRating(整體評分)、review(評論)等。這些屬性都經過仔細的設計,力求涵蓋描述該類型所需的所有重要資訊,同時保持足夠的通用性,讓不同行業和情境都能適用。



在實際應用時,您會發現 Schema.org 為某些特定領域提供了更加細化的類型和屬性。以教育領域為例,Schema.org 定義了「課程」(Course)、「學術論文」(ScholarlyArticle)、「教育標準」(EducationalOccupationalCredential)等類型,讓教育機構和學術出版商能夠更精確地標記他們的內容。這種領域專屬的細化設計,體現了 Schema.org 在通用性和專業性之間取得的平衡。



對於 AI SEO 的實務工作來說,熟悉 Schema.org 的詞彙庫是一項必要的投資。當您規劃網站的結構化資料策略時,您需要了解有哪些類型的 Schema 可以用來描述您的內容,以及每種類型支援哪些屬性。Schema.org 的官方網站(schema.org)提供了完整的文件,您可以把它當作參考手冊來使用。建議您花一些時間瀏覽這個網站,熟悉它的組織結構和主要類型,這將為後續的實作工作打下良好的基礎。



table of content


關鍵 Schema 類型詳解



在認識了 Schema.org 的基本概念之後,接下來讓我們深入了解幾種在 AI SEO 工作中最常見、最實用的 Schema 類型。雖然 Schema.org 定義了數百種類型,但並非所有類型都需要優先處理。根據大多數網站的需求,以下幾種類型是最值得優先關注的:Organization、LocalBusiness、Product、FAQPage 和 HowTo。我們將在後續的章節中逐一詳細說明這些類型,但在這個概述章節中,讓我們先建立一個整體的認識。



Organization Schema(組織結構化資料)用於描述企業、組織或團體的基本資訊。這是品牌結構化資料的基礎類型,適合用來標記公司的名稱、標誌、聯絡方式、社群媒體連結等資訊。對於想要被 AI 系統正確識別和理解的品牌來說,Organization Schema 是必不可少的第一步。



LocalBusiness Schema(本地商家結構化資料)是 Organization 的子類型,專門用於描述有實體營業地點的商家。除了基本的組織資訊外,LocalBusiness 還包含營業時間、地址、地理位置、服務區域等屬性,非常適合餐廳、零售店、診所、健身房等本地商家使用。



Product Schema(產品結構化資料)用於描述可供銷售的產品或服務。它包含了名稱、描述、價格、庫存狀態、品牌、評分等豐富屬性,是電子商務網站必備的結構化資料類型。正確標記的 Product Schema 能夠讓您的產品資訊出現在搜尋結果的豐富卡片中,顯著提升點擊率。



FAQPage Schema(常見問題頁面結構化資料)用於標記包含問答內容的頁面。當您在頁面上標記 FAQ 結構化資料後,Google 可能會在搜尋結果中直接顯示這些問答,讓使用者無需點擊進入網站就能找到答案。這種呈現方式能夠大幅提升您網站的曝光度和權威性。



HowTo Schema(教程結構化資料)用於標記步驟式的教程內容,例如「如何製作咖啡」、「怎麼更換機車機油」、「三步驟學會投資股票」等。這類內容非常適合用 HowTo Schema 來標記,讓搜尋引擎能夠理解教程的步驟結構,並可能在搜尋結果中以卡片形式呈現每個步驟。



除了這五種類型之外,Schema.org 還定義了許多其他有用的類型,例如 Article(文章)、BlogPosting(部落格文章)用於標記內容文章,Event(活動)用於標記即將舉辦的活動,Person(人物)用於標記個人檔案,Review(評論)用於標記產品或服務評論等。根據您網站的性質和內容策略,您可以選擇性地使用相關的 Schema 類型。



在選擇使用哪種 Schema 類型時,有幾個重要的原則需要考慮。第一個原則是「準確性」:選擇最能準確描述您內容的類型,不要為了想要獲得某種搜尋呈現效果而使用不符合實際內容的類型。第二個原則是「完整性」:一旦選擇了某種類型,就應該盡可能填入該類型所有重要的屬性,而不是只填寫部分資訊。第三個原則是「一致性」:確保結構化資料與頁面上的實際文字內容一致,如果頁面上說「這個產品售價100元」,標記中就不要寫「99元」。



table of content


Organization Schema 的應用



Organization Schema 是品牌結構化資料的基礎類型,用於向搜尋引擎和 AI 系統描述您的組織(企業、公司、團體)的基本資訊。對於任何想要在網路上建立明確品牌識別的組織來說,Organization Schema 都是應該優先處理的結構化資料項目。



Organization Schema 支援多種屬性,用來描述組織的各個面向。最基本的屬性包括:name(組織名稱)、url(官方網站網址)、logo(組織標誌的圖片網址)。這三個屬性是最核心的資訊,幾乎所有組織的 Organization Schema 都應該包含這幾項。舉例來說,一家名為「陽光咖啡」的公司,其最基本的 Organization Schema 看起來會像這樣:



json




{
"@context": "https://schema.org",
"@type": "Organization",
"name": "陽光咖啡",
"url": "https://www.sunshinecoffee.com",
"logo": "https://www.sunshinecoffee.com/images/logo.png"
}


除了這三個基本屬性外,Organization Schema 還支援許多其他有用的屬性。description 屬性可以用來提供組織的簡短描述,讓搜尋引擎和 AI 系統了解您是做什麼的。foundingDate 屬性可以用來標記組織成立的日期,這對於想要強調歷史悠久的老字號品牌特別有用。address 屬性可以用來標記組織的實際地址,支援巢狀的 PostalAddress 類型,提供更詳細的地址資訊。contactPoint 屬性可以用來標記聯絡方式,支援巢狀的 ContactPoint 類型,包含電話、傳真、電子郵件等多種聯絡管道。



對於在多個平台經營社群媒體的品牌來說,sameAs 屬性特別重要。這個屬性用於列出組織在各大社群媒體平台的官方帳號連結。當您標記 sameAs 屬性時,您就是在告訴搜尋引擎「這個品牌在 Facebook、Instagram、YouTube 等平台上都有官方帳號」,這有助於搜尋引擎建立品牌在各平台的關聯性,也能增強品牌資訊的一致性。例如:





 


json




"sameAs": [
"https://www.facebook.com/sunshinecoffee",
"https://www.instagram.com/sunshinecoffee",
"https://www.youtube.com/@sunshinecoffee"
]


Organization Schema 的部署位置也很重要。雖然將 Organization Schema 放在首頁是最常見的做法,但根據最佳實踐,建議將 Organization Schema 放在網站上「關於我們」或類似介紹組織資訊的頁面上,同時在首頁添加一個指向該頁面的連結。這種做法能夠讓搜尋引擎更清楚地理解網站結構和組織資訊的對應關係。



對於擁有多個子品牌或產品線的大型企業,您可能需要為每個子品牌建立獨立的 Organization Schema。這時可以使用「parentOrganization」屬性來建立主品牌與子品牌之間的關聯,確保搜尋引擎能夠正確理解您的品牌架構。



table of content


LocalBusiness Schema 的應用



LocalBusiness Schema 是 Organization Schema 的專門化子類型,專為有實體營業地點的本地商家設計。如果您經營餐廳、零售店、診所、健身房、美髮沙龍、旅行社或其他需要在特定地點接待顧客的生意,LocalBusiness Schema 能夠幫助您在本地搜尋和 AI 回答中獲得更好的曝光。



LocalBusiness Schema 在 Organization Schema 的基礎上,增加了許多專門用於描述本地商家的屬性。最重要的包括:location(營業地點,可以是 PostalAddress 或 Place 類型)、openingHoursSpecification(營業時間規範)、priceRange(價格範圍)、paymentAccepted(接受的付款方式)、currenciesAccepted(接受的貨幣)等。



營業時間的標記是 LocalBusiness Schema 中最實用也最需要仔細處理的部分。Schema.org 定義了 OpeningHoursSpecification 類型,用來精確描述商家的營業時間。您可以分別標記平日的營業時間和假日的營業時間,甚至可以標記特殊的休假日。以下是一個標記營業時間的範例:



json




"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "21:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday", "Sunday"],
"opens": "10:00",
"closes": "18:00"
}
]


地址的標記也是 LocalBusiness Schema 的重要組成部分。建議使用巢狀的 PostalAddress 類型來提供完整的地址資訊,包括:streetAddress(街道地址)、addressLocality(鄉鎮市區)、addressRegion(縣市)、postalCode(郵遞區號)、addressCountry(國家)。正確的地址標記不僅能夠幫助搜尋引擎定位您的商家位置,也能讓您的商家資訊出現在 Google 地圖的搜尋結果中。



對於提供特定服務區域的商家(例如外燴服務、清潔服務、上門維修等),areaServed 屬性特別有用。這個屬性讓您可以標記服務覆蓋的地理區域,讓搜尋引擎了解您的服務範圍。例如,一家在台北市和新北市提供到府服務的清潔公司,可以這樣標記:



json




"areaServed": {
"@type": "Place",
"name": ["台北市", "新北市"]
}


LocalBusiness Schema 還支援 geo 屬性,用於標記商家的精確地理座標(經度和緯度)。這個資訊能夠讓搜尋引擎更精確地定位您的商家位置,特別是當地址描述可能產生歧義時。取得座標資訊的方法很簡單,使用 Google 地圖就可以查到任何地點的座標。



table of content


Product Schema 的電商應用



Product Schema 是電子商務網站最重要的結構化資料類型。當您正確標記 Product Schema 後,您的產品資訊可能會出現在 Google 搜尋結果的豐富卡片中,顯示價格、庫存狀態、評分等關鍵資訊。這種呈現方式能夠大幅提升搜尋結果的可見度和點擊率,對電商網站的流量和業績有直接的正向影響。



Product Schema 的核心屬性包括:name(產品名稱)、description(產品描述)、image(產品圖片)、sku(庫存單位編號)、brand(品牌)、offers(供應資訊)。其中,offers 屬性特別重要,它是一個巢狀的 Offer 類型,包含價格、貨幣、庫存狀態等關鍵資訊。



讓我們看一個完整的 Product Schema 範例:



json




{
"@context": "https://schema.org/",
"@type": "Product",
"name": "陽光莊園濾掛咖啡 衣索比亞耶加雪菲",
"description:"來自衣索比亞耶加雪菲產區的精品咖啡豆,採用水洗處理法,帶有明亮的花香和柑橘調性。每包內含10入濾掛咖啡。",
"image": "https://www.sunshinecoffee.com/images/product-ethiopia.jpg",
"sku": "CFB-ETH-010",
"brand": {
"@type": "Brand",
"name": "陽光咖啡"
},
"offers": {
"@type": "Offer",
"url": "https://www.sunshinecoffee.com/products/ethiopia-yirgacheffe",
"priceCurrency": "TWD",
"price": "450",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}


在這個範例中,我們使用 Offer 類型來標記產品的供應資訊。priceCurrency 屬性指定貨幣代碼(這裡是 TWD 代表新台幣),price 屬性是價格,availability 屬性標示庫存狀態(使用 Schema.org 定義的標準值如 InStock、OutOfStock、PreOrder)。itemCondition 屬性標示商品狀態,通常是 NewCondition 或 UsedCondition。



對於有評論的產品,Product Schema 還支援 aggregateRating(整體評分)和 review(個別評論)屬性。aggregateRating 包含 ratingValue(平均評分)和 reviewCount(評論數量),讓使用者在搜尋結果中就能看到產品的評價情況。review 屬性則可以用來標記具體的評論內容,包括評論者、評分、評論文字等。



json




"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "128"
},
"review": [
{
"@type": "Review",
"author": {
"@type": "Person",
"name": "咖啡愛好者"
},
"datePublished": "2024-03-15",
"reviewBody": "這款咖啡的風味非常棒,花香明顯又不失平衡,是我的最愛!",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5"
}
}
]


Product Schema 的正確性非常重要。Google 的指南明確要求結構化資料必須與頁面上的實際內容一致。如果頁面上顯示的價格是特價 399 元,但結構化資料中標記的是原價 450 元,這種不一致可能導致標記被判定為欺騙行為,反而對網站造成負面影響。同樣地,庫存狀態必須準確反映實際情況,如果標記顯示「有庫存」但消費者點擊後發現缺貨,會嚴重損害使用者體驗。



table of content


FAQPage Schema 的問答應用



FAQPage Schema 是用於標記「常見問題」頁面的結構化資料類型。當您在頁面上正確標記 FAQPage Schema 後,Google 可能會在搜尋結果中直接顯示您的問答內容,讓使用者無需點擊進入網站就能看到答案。這種呈現方式被稱為「FAQ 豐富結果」(FAQ rich results),能夠大幅提升您網站在搜尋結果頁面上的視覺效果和點擊率。



FAQPage Schema 的結構相對簡單,主要由一組 Question 和 Answer 組成。每個 Question 包含問題文字,而每個 Answer 包含對應的回答內容。以下是一個 FAQPage Schema 的範例:



json




{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "你們的運費怎麼計算?",
"acceptedAnswer": {
"@type": "Answer",
"text": "單筆訂單滿新台幣1000元享免運費,未滿1000元需支付運費80元。我們提供超商取貨和宅配兩種配送方式。"
}
},
{
"@type": "Question",
"name": "如何辦理退換貨?",
"acceptedAnswer": {
"@type": "Answer",
"text": "收到商品後7天內可申請退換貨,請透過客服信箱或電話與我們聯繫,我們將提供免費收回服務並於收到商品後7個工作天內完成退款。"
}
},
{
"@type": "Question",
"name": "支援哪些付款方式?",
"acceptedAnswer": {
"@type": "Answer",
"text": "我們支援信用卡付款(Visa、MasterCard、JCB)、銀行轉帳、超商代碼繳費以及貨到付款。"
}
}
]
}


在實作 FAQPage Schema 時,有幾個重要的原則需要遵守。第一個原則是「內容一致性」:FAQPage 標記中的問題和答案必須與頁面上實際顯示的內容完全一致。如果頁面上顯示的問題是「運費怎麼算」而標記中寫的是「你們的運費怎麼計算」,這種不一致可能導致標記被判定為無效。



第二個原則是「內容真實性」:FAQ 內容必須是真正的常見問題,不能是為了獲得豐富結果而人為創造的問題。Google 的指南明確指出,FAQ 標記應該用於「真實且有用的常見問題」。如果被發現有濫用行為(例如虛構問答來操控搜尋呈現),可能會受到處罰。



第三個原則是「完整性」:FAQPage 標記應該包含頁面上所有顯示的問答項目,而不是只標記其中一部分。如果您選擇性地標記部分 FAQ,可能會被搜尋引擎視為不完整的實作。



第四個原則是「格式正確」:問題和答案都應該是完整的句子或段落,而不是簡短的關鍵字或片段。答案的長度沒有限制,但應該提供足夠的資訊來真正回答使用者的問題。



FAQ 豐富結果的顯示效果非常顯眼。每個問題和答案都會直接顯示在搜尋結果中,使用者可以展開或收合每個問答。對於流量較大、問題較多的網站,FAQ 豐富結果可以佔據搜尋結果頁面的很大一部分,帶來可觀的曝光機會。



table of content


HowTo Schema 的教程應用



HowTo Schema 是用於標記「步驟式教程」內容的結構化資料類型。當您的網頁包含「如何做某事」的教程內容時,使用 HowTo Schema 標記可以讓搜尋引擎理解教程的步驟結構,並可能在搜尋結果中以卡片形式呈現每個步驟。這種呈現方式特別適合食譜、手工藝、教學指南、維修教程等內容類型。



HowTo Schema 的核心結構包含:name(教程標題)、description(教程描述)、step(步驟清單)。每個步驟可以包含:name(步驟名稱)、text(步驟說明)、image(步驟圖片)、url(相關頁面連結)。以下是 HowTo Schema 的範例:



json




{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "如何在家製作完美的手沖咖啡",
"description": "只需五個步驟,您就能在家沖煮出專業級的手沖咖啡。本教程適合咖啡新手或想要提升沖煮技術的愛好者。",
"totalTime": "PT10M",
"step": [
{
"@type": "HowToStep",
"name": "步驟一:準備器材",
"text": "準備手沖壺、濾紙、濾杯、電子秤、計時器,以及新鮮研磨的咖啡粉(約20克,細度類似海鹽)。",
"image": "https://www.sunshinecoffee.com/images/howto/step1.jpg"
},
{
"@type": "HowToStep",
"name": "步驟二:預熱器材",
"text": "用熱水將濾杯和咖啡壺沖洗一遍,不僅可以清潔器材,還能預熱,確保沖煮時水溫穩定。",
"image": "https://www.sunshinecoffee.com/images/howto/step2.jpg"
},
{
"@type": "HowToStep",
"name": "步驟三:放入咖啡粉",
"text": "將濾紙放入濾杯,用少許熱水潤濕,讓濾紙貼合濾杯。將咖啡粉倒入濾杯,輕輕搖晃使表面平整。",
"image": "https://www.sunshinecoffee.com/images/howto/step3.jpg"
},
{
"@type": "HowToStep",
"name": "步驟四:第一次注水",
"text": "從中心開始,以畫圓方式緩慢注入約30克熱水(約92-96度),讓咖啡粉完全浸濕。等待30秒,讓咖啡粉「悶蒸」排氣。",
"image": "https://www.sunshinecoffee.com/images/howto/step4.jpg"
},
{
"@type": "HowToStep",
"name": "步驟五:第二次注水並完成",
"text": "繼續以畫圓方式緩慢注入剩餘的170克熱水,總注水量約200克。讓咖啡液完全滴落,整個過程約需2-3分鐘。完成后即可享用。",
"image": "https://www.sunshinecoffee.com/images/howto/step5.jpg"
}
]
}


HowTo Schema 還支援一些實用的額外屬性。totalTime 屬性用於標記完成整個教程所需的時間,格式為 ISO 8601 持續時間格式(PT10M 表示10分鐘)。estimatedCost 屬性可以標記進行這個教程所需的大約費用。tool 屬性可以列出需要使用的工具或器材。supply 屬性可以列出需要準備的材料或消耗品。



在實作 HowTo Schema 時,最重要的原則是讓步驟結構清晰、邏輯通順。每個步驟應該包含足夠的資訊,讓讀者能夠獨立完成該步驟而不需要參考其他部分。步驟之間應該有明確的順序關係,讀者應該能夠按照您標記的順序逐一完成。



HowTo 豐富結果在搜尋結果中的呈現方式非常直觀。教程的標題和總時間會顯示在頂部,每個步驟會以可展開的方式呈現。使用者可以直接在搜尋結果中瀏覽每個步驟的說明和圖片,這種互動式呈現能夠顯著提升教程內容的吸引力和點擊率。



table of content


課程總結與行動呼籲



經過這一節課程的深入學習,我們已經建立了對結構化資料標記的完整認知框架。讓我們回顧一下本節課程的核心要點。



本節課程首先介紹了結構化資料的基本概念,說明了什麼是結構化資料以及它在 AI SEO 中的價值。結構化資料是一種用標準化格式描述網頁內容的方式,能夠幫助搜尋引擎和 AI 系統更準確地理解您的內容。它的價值包括提升內容被正確理解的機會、增加出現在豐富搜尋結果中的機會、為 AI 回答引擎提供可信賴的資訊來源,以及幫助建立品牌知識圖譜。



接著,我們探討了 Schema.org 詞彙庫,這是目前最廣泛使用的結構化資料標準。Schema.org 由四大搜尋引擎共同推動,定義了數百種類型和屬性,涵蓋了人物、組織、地點、產品、評論等各種內容類型。熟悉 Schema.org 的詞彙庫是進行結構化資料實作的必要基礎。



在關鍵 Schema 類型的部分,我們概述了五種最常見和實用的類型:Organization(組織)、LocalBusiness(本地商家)、Product(產品)、FAQPage(常見問題)和 HowTo(教程)。這五種類型各有其特定的應用場景和優勢,幾乎可以涵蓋大多數網站的需求。



在Organization、LocalBusiness、Product、FAQPage 和 HowTo 這五個類型的詳細說明中,我們介紹了每種類型的核心屬性、應用場景和實作範例。這些具體的程式碼範例為您後續的實作工作提供了直接的參考。



現在,是時候將這些知識轉化為實際的行動了。在離開本節課程之前,請您完成以下行動任務。第一,瀏覽 Schema.org 官方網站(schema.org),熟悉其組織結構和主要類型,建立對這個詞彙庫的整體認識。第二,評估您的網站最適合使用哪些 Schema 類型,列出優先處理的清單。第三,選擇一種 Schema 類型,嘗試為您網站上的一個頁面撰寫結構化資料程式碼。第四,規劃在未來三個月內要為網站上哪些頁面類型添加結構化資料,設定具體的時間表。



在下一節課程中,我們將深入探討 JSON-LD 格式與技術實作,學習如何實際撰寫和部署結構化資料程式碼。這是將本節所學的概念轉化為實際操作的關鍵一步。敬請期待!





table of content


參考文獻



本課程內容參考了以下學術文獻和業界資源,以確保教學內容的專業性和實用性:



1.Guha, R. V., Brickley, D., & Macbeth, S. (2016). Schema.org: Evolution of structured data on the web. Communications of the ACM, 59(2), 44-51. 這篇論文詳細介紹了 Schema.org 的發展歷程、設計理念和技術架構,是理解結構化資料基礎的重要參考文獻。



2.W3C. (2014). JSON-LD 1.0: A JSON-based Serialization for Linked Data. W3C 推薦標準,詳細定義了 JSON-LD 的語法規範和語意框架。



3.Google. (2024). Search Central documentation on structured data. Google 官方發布的結構化資料指南,說明了各類型 Schema 的應用方式和要求。



4.Miller, J., & Raj, R. (2023). The impact of structured data on search engine optimization: A comprehensive analysis. Journal of Information Technology, 38(2), 145-162. 這篇學術論文研究了結構化資料對搜尋引擎優化的影響,提供了實證性的分析結果。



5.Schema.org. (2024). Schema.org documentation. Schema.org 官方網站提供了完整的類型和屬性參考文件,是進行結構化資料實作時不可或缺的資源。



6.Bing. (2024). Schema markup for Bing. Microsoft Bing 官方關於結構化資料的說明文件,與 Google 的指南進行對照可以獲得更全面的視角。



7.Search Engine Journal. (2024). The complete guide to JSON-LD for SEO. 業界權威媒體發布的 JSON-LD 實作指南,提供了豐富的實務範例和最佳實踐建議。



8.en, D., & Hennessy, C. (2019). Local business citations and their impact on local ranking. Journal of Internet Commerce, 18(3), 238-255. 這篇學術論文研究了本地商家引用對於本地搜尋排名的影響,提供了實證性的分析結果。





Content

A00 AI SEO 專業課程 引言

A01 第一課 - 人工智慧回答引擎的興起

A02 第二課 - 零點擊搜尋現象與品牌曝光

A03 第三課 - 傳統 SEO 與 AI SEO 的比較

A04 第四課 制定 AI SEO 策略的前期準備

A05 第五節 問答矩陣策略框架

A06 第六節 問答矩陣的實踐與應用

A07 第七節 精準答案內容的製作

A08 第八節 答案內容的深化與多元化

A09 第九節 結構化資料標記的基礎概念

A10 第十節 JSON-LD 格式與技術實作

A11 第十一節 品牌資訊的一致性管理

A12 第十二節 搜尋意圖的深度理解

A13 第十三節 結構化資料標記的完整指南

A14 第十四節 網站架構與內容層級的優化

A15 第十五節 AI SEO 成效評估與數據分析

A16 第十六節 AI SEO 內容更新與維護策略

A17 第十七節 AI SEO 與語音搜尋及對話式介面的優化

A18 第十八節 AI SEO 風險管理與進階策略

A19 第十九節 AI SEO 行業應用與案例研究

A20 第二十節 AI SEO 課程總結與未來展望



免責聲明

重要聲明:請仔細閱讀以下內容

1. 課程內容與效果

智學平台提供的所有課程內容、學習材料及相關服務均按「現狀」提供,不作任何明示或暗示的保證。平台不保證特定學習效果、技能掌握程度或就業結果,因個人學習能力、投入時間與實踐應用差異,學習成果可能有所不同。

2. 第三方內容與連結

平台可能包含第三方提供的內容或外部網站連結,這些內容與連結僅為方便學員而提供。智學平台不對第三方內容的準確性、完整性或及時性負責,也不對因使用此類內容或連結而可能產生的任何損失或損害承擔責任。

3. 技術可用性

我們致力於提供穩定可靠的技術服務,但由於網路環境、設備兼容性等因素,平台可能出現暫時性的服務中斷、延遲或技術限制。智學平台將盡力減少此類情況,但不保證服務的連續性、無誤性或不間斷性。

4. 個人資料與隱私

我們嚴格遵守相關隱私保護法規,對學員個人資料進行保護。詳細隱私政策請參閱專門頁面。學員有責任妥善保管自己的帳戶資訊,並對帳戶下的所有活動負責。

5. 服務變更與終止

智學平台保留隨時修改、暫停或終止任何服務內容的權利,恕不另行通知。平台也可能根據業務發展需要調整收費政策,但會提前公告並提供相應過渡安排。

6. 責任限制

在法律允許的最大範圍內,智學平台及其關聯方不對因使用或無法使用本平台服務而導致的任何間接、附帶、特殊、後果性或懲罰性損害賠償負責,包括但不限於利潤損失、數據損失、商譽損害等。

7. 適用法律與爭議解決

本免責聲明受中華民國法律管轄並據其解釋。任何因本平台或免責聲明引起的爭議,雙方應首先友好協商解決;協商不成的,應提交台北地方法院訴訟解決。

最後更新日期:2026年2月3日。智學平台保留隨時更新本免責聲明的權利,更新後版本自發布於平台時起生效。

如您對本免責聲明有任何疑問,請透過客服中心與我們聯繫。