版面是給人閱讀的，Schema.org 則是給解析器辨認的。前者靠樣式完成，後者是埋在原始碼裡的語意描述。兩層都處理好，頁面才算完整。
不少設計人員略過這一步，多半是覺得那屬於工程範圍。可是談到搜尋可見度時，要宣告哪些類型、欄位如何對上版面，應在規劃時就定案。拖到切版之後再補，往往得整段重做，代價比事先納入規格更高。
Schema 是什麼？給機器看的語意標籤
Schema.org 由 Google、Microsoft、Yahoo 與 Yandex 共同維護，用來描述頁面上的實體。有了這些類型，頁面可以清楚說明：
- 這一段是文章（Article）
- 這個區塊是問答（FAQPage）
- 這張圖是組織標誌（ImageObject 搭配 Organization.logo）
- 這個數字是售價（Offer.price）
解析器分清每個區塊的角色後，才判斷能不能把它抽成搜尋摘要。
建議寫法：JSON-LD，不牽動視覺
可用的語法有 Microdata、RDFa 與 JSON-LD。Google 較傾向 JSON-LD，因為它：
- 與版面標記分開，不干擾排版
- 可放在
或任一處 - 一段腳本就是一組完整資料，較好維護
- 幾乎不增加渲染成本，本身也不改動排名機制
範例：
訪客看不到這段腳本，解析器卻能立刻辨認：這是一間 2010 年成立、專注結構化內容的組織。
設計師應熟悉的七種 Schema
1. Organization（組織資訊）
適用位置：首頁與關於頁（企業站配置可看企業官網方案說明）為什麼要標：建立品牌識別，並影響知識面板怎麼呈現
常用欄位：name、url、logo、foundingDate、address、contactPoint、sameAs（外部檔案連結）
2. Article（文章）
適用位置：部落格、新聞與洞察文為什麼要標：是生成式摘要最常引用的類型之一
常用欄位：headline、author、datePublished、dateModified、image、publisher、articleBody
3. FAQPage（常見問答）
適用位置：問答頁、商品頁底部、文章結尾為什麼要標：被摘要系統採用的機會特別高，因為問答格式本來就適合抽取
常用欄位：mainEntity（陣列，元素為 Question 與 acceptedAnswer）
每一組問答都能單獨被取用，直接回應相關查詢。版面如何排列才容易被引用，可看問答區塊的版面安排。
4. Product（商品）
適用位置：電商詳情頁（購物站架構可看購物平台規劃說明）為什麼要標：關係到購物結果與推薦場景的露出
常用欄位：name、image、description、brand、offers（含 price、priceCurrency、availability）、aggregateRating
5. BreadcrumbList（導覽路徑）
適用位置：首頁以外的各個頁面為什麼要標：幫助系統理解站點層級與當前頁位置
常用欄位：itemListElement（陣列，含 position、name、item）
6. LocalBusiness（在地商家）
適用位置：有實體據點的餐廳、診所或零售店為什麼要標：影響「附近」類查詢與地圖結果
常用欄位：name、address、telephone、openingHoursSpecification、geo、priceRange
7. Person（人物）
適用位置：作者頁與團隊介紹為什麼要標：支撐作者可信度，連動經驗與專業相關評分
常用欄位：name、jobTitle、image、sameAs、worksFor
規劃階段就要定下的三件事
一、先列出每頁要標記的類型
畫版之前，先決定各頁需要哪一組 Schema：
| 頁面類型 | 建議標記 |
|---|---|
| 首頁 | Organization + WebSite |
| 關於我們 | AboutPage + Organization |
| 文章列表 | CollectionPage |
| 文章內頁 | Article + BreadcrumbList + FAQPage（若有問答） |
| 商品列表 | CollectionPage + ItemList |
| 商品詳情 | Product + BreadcrumbList + Review |
| 問答頁 | FAQPage |
| 聯絡頁 | ContactPage + LocalBusiness |
| 作者頁 | Person + ProfilePage |
二、版面上要有對應欄位
若要輸出 Article，畫面就得有作者、發布日、更新日與主圖。若要輸出 FAQPage，就得有成對的問與答。標記寫了、版面卻沒有對應內容，可能被視為結構不符而降權。曾有專案大量宣告標記，頁面卻對不上，搜尋後台警告不斷，收拾起來比重新規劃更費工。
三、先跟工程對齊資料從哪來
欄位是寫死在模板，還是由內容系統帶出？這要在設計階段談定，否則上線後只能手動補，維護會變成長期負擔。
常見踩雷
- ❌ 標記與事實不符：宣告了 Review，頁面卻沒有評論區，可能被判定違規
- ❌ 類型混用衝突：同一區塊同時用 Article 與 BlogPosting，欄位彼此打架
- ❌ 漏掉必要欄位：Article 沒有 author 或 datePublished，摘要系統通常不會採用
- ❌ 標誌用了相對路徑：logo 必須是含協定的絕對網址
- ❌ 價格寫成帶符號的文字：
"price": "$50"不正確，應寫成"price": "50", "priceCurrency": "USD"
結語：版面與標記要一起想
生成式摘要普及之後，不能再把視覺與結構化描述拆開處理。畫面上有什麼，標記就描述什麼，兩者要在規劃時一併考慮。版面如何對應摘要切片，可再看摘要時代的版面結構。設計端理解標記，頁面才容易被正確讀取；等上線再補，返工成本往往是事前規劃的數倍。
需求階段就應產出對照表：每頁標記哪些類型、欄位從哪裡來、由誰維護。這份表同時服務設計、工程與內容，也是驗收時的檢查依據。
