Schema.org 結構化資料（JSON-LD）實作指南：讓 AI 與 Google 看懂你的網站
AI 引擎和 Google 不是「讀」你的網頁，而是「解析」它。一段格式正確的 JSON-LD 結構化資料，等於用機器看得懂的語言直接告訴它們：這是一家什麼公司、這篇文章誰寫的、這個商品多少錢、這頁有哪些常見問答。少了它，AI 只能用猜的；有了它，你被正確辨識與引用的機率大幅提高。這篇帶你從零把常用類型實作出來、放對位置、驗證無誤。
結構化資料是什麼？為什麼用 JSON-LD
結構化資料是一段依照 Schema.org 共同詞彙寫成的標記，用機器可讀的鍵值告訴搜尋引擎與 AI 引擎「這頁的內容代表什麼」。同一段「王小明，0912-345-678」，人看得懂是聯絡人與電話，但機器需要你明確標出 name 與 telephone 才不會誤判。
實作格式有三種（JSON-LD、Microdata、RDFa），但 Google 與目前主流做法都建議用 JSON-LD。原因是它把所有標記集中成一個獨立的 <script> 區塊，不需要纏進 HTML 標籤裡，最好維護、最不容易和版型互相破壞，也最容易被 AI 爬蟲穩定解析。
JSON-LD 放在頁面哪裡？
把標記包在 <script type="application/ld+json"> 區塊裡，放進頁面的 <head> 或 <body> 都可以被辨識，慣例上放 <head>。一頁可以有多個 JSON-LD 區塊，也可以用一個 @graph 陣列把多個實體包在一起，兩種都合法。
關鍵原則是：結構化資料必須伺服器端就輸出，存在於原始 HTML 裡。多數 AI 檢索爬蟲不執行 JavaScript，如果你的 JSON-LD 是前端載入後才用 JS 動態插入，AI 爬蟲很可能讀到的是沒有標記的空殼。用「檢視原始碼」(View Source) 而非開發者工具的 Elements 面板確認它真的在原始回應裡。
Organization 與 LocalBusiness：定義你是誰
這是整站最該優先做的一塊，通常放在首頁。它定義你的品牌實體，是 AI 回答「這家公司是誰、可不可信」時的核心依據。有實體店面或服務區域的，用更精確的 LocalBusiness（或其子類型如 Restaurant、Store）取代 Organization，並補上地址與營業時間。
- Organization 必備欄位：name（品牌名）、url（官網）、logo（標誌圖片網址）。
- sameAs：放上你的 Facebook、Instagram、LinkedIn、維基百科等官方連結陣列。這是把分散的品牌身分「綁成同一個實體」的關鍵，能大幅降低 AI 認錯對象的機率。
- LocalBusiness 額外加：address（用 PostalAddress 結構，拆成街道／城市／郵遞區號）、telephone、openingHours、geo（經緯度）、priceRange。
- contactPoint：標出客服電話、email 與服務語言，AI 回答聯絡類問題時就找得到你。
Article、Product、BreadcrumbList：依頁面類型選對 schema
不同頁面用不同類型，原則是「這頁主要在講什麼，就標什麼」。部落格與新聞用 Article（或 BlogPosting／NewsArticle）；商品頁用 Product；任何有層級的頁面都該補 BreadcrumbList。
- Article／BlogPosting：headline、author（用 Person 或 Organization，別只放純文字）、datePublished、dateModified、image、publisher。作者與日期是 AI 判斷內容新鮮度與權威度的重要訊號。
- Product：name、image、description、brand、offers（內含 price、priceCurrency、availability）。若有評價再加 aggregateRating 與 review，但分數必須對應頁面上真實顯示的評論。
- BreadcrumbList：用 itemListElement 依序列出麵包屑路徑（首頁 › 分類 › 本頁），幫引擎理解網站結構與這頁在站內的定位。
- 選型小訣竅：一頁可同時有多個類型（例如一篇商品評測同時有 Article 與 Product），用 @graph 包起來即可。
FAQPage：對 GEO 最直接有用的一招
如果只想先做一個能立刻影響 AI 引用的類型，選 FAQPage。它把「問題—答案」配對成機器可讀的格式，剛好對應 AI 引擎「找一段能直接當答案的內容」的擷取邏輯，是投入產出比很高的一步。
做法是用 mainEntity 列出多組 Question，每組底下放一個 acceptedAnswer（Answer 類型，text 欄位填答案）。鐵律：標記裡的問答必須是頁面上使用者真的看得到的內容，不能只存在於 JSON-LD 裡。Google 政策明確要求 FAQ 內容要在頁面可見，否則屬於違規隱藏內容。
怎麼驗證？三個必跑的檢查
寫完一定要驗證，因為一個拼錯的欄位名或少一個逗號，整段標記就可能被忽略。驗證分兩個層次：語法對不對、以及有沒有資格觸發 Rich Results。
- Schema Markup Validator（validator.schema.org）：檢查 Schema.org 語法本身正不正確，適用所有類型，不限於 Google 支援的。
- Google Rich Results Test（search.google.com/test/rich-results）：貼上網址或程式碼，看 Google 是否認可、能否拿到複合式搜尋結果，並列出錯誤與警告。
- Search Console 的「複合式搜尋結果」報告：上線後持續監測實際被 Google 抓到的狀態與錯誤，比一次性測試更能反映真實情況。
- 別忘了用「檢視原始碼」確認標記真的出現在伺服器回傳的 HTML，而不是只靠 JS 注入。
最常見的五個錯誤（尤其第一個會被當 spam）
結構化資料做錯比沒做更糟，輕則被忽略、重則被判定操弄。以下五個是最常踩的雷。
- 標記與內文不一致：JSON-LD 寫了五星評價、頁面上根本沒有，或 FAQ 答案頁面看不到——這會被 Google 視為 spam，可能導致整站結構化資料失去資格。標記必須忠實反映頁面實際內容。
- 用錯類型或欄位：把產品標成 Article、把 author 填成純字串而非 Person/Organization、價格沒附 priceCurrency 等，都會讓引擎無法正確解析。
- 靠 JavaScript 動態注入：AI 爬蟲與部分情境下讀不到，等於白做。務必伺服器端輸出。
- 實體不一致：首頁叫「KKpower」、其他頁叫「KK Power」、社群連結又對不上，AI 難以把它們綁成同一個品牌。固定一致的 name、url 與 sameAs。
- 過度標記與堆砌：把整頁所有東西都硬塞成 schema、或重複宣告同一實體，反而增加出錯與被判操弄的風險。標重要的、標真實的就好。
常見問題
Q. 結構化資料一定要用 JSON-LD 嗎？Microdata 可以嗎？
Microdata 與 RDFa 在語法上仍合法，但 Google 與目前主流實務都建議用 JSON-LD。它把標記集中成獨立的 <script> 區塊，不必纏進 HTML 標籤，最好維護、最不容易與版型互相破壞，也最容易被 AI 爬蟲穩定解析。新做的網站直接選 JSON-LD 就對了。
Q. 加了結構化資料，Google 就一定會給我 Rich Results（星星、FAQ 展開）嗎？
不保證。正確的標記只是「取得資格」，是否實際顯示複合式搜尋結果由 Google 演算法決定，會看內容品質、是否符合政策、查詢情境等。但即使沒觸發視覺化的 Rich Results，正確的結構化資料仍幫助搜尋引擎與 AI 引擎理解與引用你的內容，價值不會白費。
Q. FAQPage 標記裡的問答，頁面上一定要看得到嗎？
是，這是硬性規定。Google 政策要求 FAQ 的問與答必須是使用者在頁面上真實可見的內容；只寫在 JSON-LD、頁面卻看不到，屬於違規的隱藏內容，可能讓你的結構化資料失去資格甚至影響整站。標記必須忠實對應頁面實際呈現。
Q. 結構化資料寫錯了會不會害到我的網站？
會。最嚴重的是「標記與內文不一致」（例如假評價、頁面看不到的 FAQ），這會被視為操弄，可能導致網站的結構化資料被取消資格。其他常見問題如用錯類型、欄位拼錯、靠 JS 動態注入導致爬蟲讀不到，多半是「無效但無害」，引擎直接忽略。原則是：寧可標得少而正確，不要標得多而造假。
Q. 我該優先做哪一個 schema 類型？
先做兩個。一是首頁的 Organization（有店面或服務區域就用 LocalBusiness），定義你的品牌實體與聯絡資訊；二是內容頁的 FAQPage，因為它的問答格式最貼近 AI 引擎擷取答案的方式，對被引用最直接有效。之後再依頁面類型補上 Article、Product 與 BreadcrumbList。
Q. 怎麼確認我的結構化資料真的被讀到？
三步驟：先用 Schema Markup Validator（validator.schema.org）確認語法正確；再用 Google Rich Results Test 確認 Google 認可並檢查能否觸發複合式結果；上線後用 Search Console 的複合式搜尋結果報告持續監測。最後務必用瀏覽器「檢視原始碼」確認 JSON-LD 出現在伺服器回傳的原始 HTML，而非僅由前端 JavaScript 注入。