一句話先講結論：結構化資料（Structured Data，俗稱 Schema）是一套「說給機器聽」的標記，明確告訴 Google 與 AI 搜尋引擎「你是誰、賣什麼、這頁在講什麼」。做對的關鍵不是塞越多，而是三件事——集中成單一 @graph、由網站統一輸出、FAQ 從內文解析，讓機器讀到的和訪客看到的一致。
什麼是結構化資料？為什麼 AI 特別需要它
人看網頁靠版面理解意思，機器不會——搜尋引擎和生成式 AI 讀到的是一堆 HTML 標籤，需要一份標準化的「說明書」，才能確定這頁的公司、地址、服務、作者、問答分別是什麼。這份說明書就是結構化資料，通用詞彙表是 schema.org，最推薦的寫法是 JSON-LD。
在傳統 SEO 時代，結構化資料主要用來爭取「複合式搜尋結果」（rich results），例如星等、FAQ 展開、麵包屑。到了 AI 搜尋與 AI Overview 階段它更關鍵：當 AI 要判斷哪個網站是某問題的權威、要引用誰當來源時，機器可讀的實體資訊會大幅降低它猜錯的機率。把「我是台北的 SEO 代理商、提供這幾項服務」寫成機器讀得懂的格式，遠比讓 AI 從行銷文案自行推敲可靠。
要提醒的是：結構化資料能讓 AI 與 Google 更精準理解你的內容，但它不是排名保證，也無法讓空洞的內容變得有價值——它是把好內容翻譯給機器的橋樑，不是內容的替代品。
常見的結構化資料類型與各自用途
類型很多，但多數網站真正用得到的是以下這幾種。理解它們各自回答什麼問題，比背 schema.org 的完整清單更實用：
| 類型（@type） | 回答的問題 | 誰該用 |
|---|---|---|
| Organization | 「這個網站背後是哪家公司？」名稱、logo、社群與各平台連結（sameAs） | 所有品牌／公司網站 |
| WebSite | 「這是哪個網站？站內搜尋怎麼用？」有時帶站內搜尋框設定 | 所有網站 |
| LocalBusiness | 「你在哪、營業時間、服務範圍、評價幾分？」地址、地理座標、營業時段、評分 | 有實體或在地服務的店家、工程行、診所、事務所 |
| Article／BlogPosting | 「這篇文章在講什麼？誰寫的？何時更新？」標題、作者、發佈與更新日期 | 部落格、知識文、新聞頁 |
| FAQPage | 「這頁有哪些常見問答？」一問一答，容易被 AI Overview 與 PAA 摘錄 | 服務頁、長文、常見問題頁 |
| BreadcrumbList | 「這頁在網站架構的哪個位置？」麵包屑層級 | 所有有分層結構的網站 |
| Service／OfferCatalog | 「你提供哪些服務？」把服務清單結構化列出 | 服務型公司 |
實務上，在地服務型公司通常同時用 Organization、WebSite、LocalBusiness，服務頁加 FAQPage 與 BreadcrumbList，文章用 Article／BlogPosting 標明作者與更新日期——這正是我們協助客戶的預設起手式。
結構化資料怎麼做才正確：三個原則
一、全站集中成單一 @graph，而不是零散拼貼
很多網站的結構化資料東一塊、西一塊：首頁一段 Organization、外掛又吐一段 WebSite、文章頁再單獨掛 Article，這些片段彼此不認識，機器得自己拼湊關係。正確做法是把整頁實體收進單一 @graph，用 @id 讓節點互相參照——例如標明這個 Article 的發佈者是哪個 Organization。關係一旦明確，AI 就不必猜，也不會被兩段矛盾的標記混淆。
二、由網站統一輸出，不要每個外掛各自為政
結構化資料應該有「單一真相來源」。若 SEO 外掛、佈景主題、社群外掛各自注入 schema，很容易同一頁掛兩組 WebSite、兩組 FAQPage。重複標記通常不致命，卻是雜訊，會稀釋機器判讀的確定性。理想做法是由網站集中產生，其餘來源關掉，避免打架。
三、FAQ 等內容從「內文」解析，不要手打一份給機器看
這是最容易踩雷的一點。FAQPage 標記裡的問答，必須和頁面上看得到的內容一致。若標記裡塞了頁面根本沒有的問答，那叫 cloaking（對人和對機器顯示不同內容），是 Google 明文禁止的操作，抓到反受其害。正確做法是：先把 FAQ 寫進內文（每題答案放第一句，AI 最容易擷取），再由系統從內文自動解析成標記——內容改一次，兩邊同步，永不對不上。
常見錯誤：這些做法弊大於利
- 標記和內文不符（cloaking）：schema 裡的評價、問答、價格，頁面上卻找不到。這是最嚴重的一種，寧可不做也不要造假。
- 同頁重複掛同型標記：兩組 WebSite、兩組 FAQPage。我們檢視過一個業界案例，schema 地基很強，卻因不同外掛各自輸出而出現重複節點——正是「缺乏單一真相來源」的典型症狀。
- 為複合式結果亂加不相干標記：明明不是食譜、活動、產品，硬套 Recipe、Event、Product，機器讀到不相符的標記反而降低信任。
- 把標記當成寫內容者的負擔：手動硬塞 JSON-LD 到正文，日後改內文卻忘了改標記；或以為裝了 SEO 外掛就萬事俱備。外掛出基本標記是好起點，但標記應由系統統一產生，也不會替你設計實體關係。
豐遠（Richers）怎麼幫客戶做
我們把上面三個原則直接做進網站架構，而不是事後補外掛——這些都是我們自己跑過、驗證過的做法：
- 網站本身就是作品。我們重建的官方網站採用單一 @graph：Organization、WebSite、服務與文章實體全部收在同一節點裡互相參照，由網站統一輸出，避免重複衝突。FAQ 不手打給機器，而是從內文的 FAQ 區塊自動解析——編輯把問答寫進內文，標記就同步產生，杜絕 cloaking 風險。
- 在地服務站的實戰補強。協助一個在地服務型網站復原流量時，我們為它寫了一支輕量程式（mu-plugin），在首頁補上 Organization、WebSite、LocalBusiness／營建服務類標記，標明品牌、服務區域與聯絡方式，並避開與既有 SEO 外掛重疊（外掛只出 FAQ 與文章標記）。這就是「集中輸出、避免衝突」的落地。
- 我們不承諾排名。結構化資料能讓 Google 與 AI 更精準理解你的網站，但沒有人能保證被引用或排名。我們保證的是把可驗證的基礎工程做對——單一 @graph、乾淨不衝突的標記、內文與標記一致——這是內容有機會被看見的前提，不是結果的承諾。
結構化資料只是 AI 搜尋友善度的一環。想了解它在整體策略中的位置，可以延伸閱讀我們的 生成式引擎優化（GEO）完整指南；若你需要有人把這些工程一次做到位，這正是我們 SEO 服務與網站建置的一部分。
常見問題 FAQ
結構化資料一定要用 JSON-LD 嗎？
是。JSON-LD 是 Google 官方建議的格式，獨立於頁面內容之外，維護最單純。舊式的 Microdata、RDFa 雖仍可辨識，但新網站沒有理由不用 JSON-LD。
網站沒有結構化資料，Google 就找不到我嗎？
不會。沒有結構化資料，Google 一樣能索引你的網站。它的作用是讓機器更確定地理解內容、降低誤判，並爭取複合式結果與 AI 引用——是加分項，不是被收錄的門檻。
用 SEO 外掛（Yoast、RankMath、SureRank 等）出 schema 夠嗎？
作為起步足夠，能自動產生基本的 Article、FAQ 標記。但它不會替你設計實體之間的關係，也可能和其他外掛重複輸出。要做到單一 @graph、乾淨不衝突，通常需由網站層統一規劃。
FAQ 的結構化資料會不會被判定作弊？
只要標記裡的問答和頁面看得到的內容一致，就不會。會出問題的是「標記有、頁面沒有」的造假（cloaking）。最安全的做法是把 FAQ 寫進內文，再由系統解析成標記，兩邊永遠同步。
加了結構化資料，多久會被 AI 引用？
沒有人能給你保證的時間表，任何宣稱「保證被引用」的說法都不可信。結構化資料是提高被正確理解與引用「機率」的基礎工程；能不能被引用，仍取決於內容本身的品質、可信度與相關性。
想知道你的網站對 AI 是否可讀？
若你不確定網站有沒有結構化資料、有沒有重複衝突、標記與內文是否一致，我們可以幫你檢查。預約免費 SEO 健檢，我們會實際讀你網站的標記，告訴你 Google 與 AI 現在怎麼理解你——以及哪裡能做得更好。
