同樣一篇文章，有人被 ChatGPT 點名當答案來源，有人連被掃進去的資格都沒有。差別有時候不在內容寫得多好，而在你有沒有把「這是誰寫的、什麼時候改的、回答了哪些問題」用機器讀得懂的方式講一次。這件事，就是結構化資料在做的。
結構化資料（Schema）是一段標準化的程式碼，明確告訴搜尋引擎與 AI 引擎這頁是文章、是組織、還是一組問答，讓它們不用從文字去猜。 過去做它是為了搶 Google 的複合式搜尋結果版面；現在多了一個更值錢的理由，是讓 ChatGPT、Perplexity、Google AI 概覽這些生成式引擎在回答問題時，更容易把你的內容認出來、當成可信來源引用。
問題是 Schema.org 列得出來的類型超過三十種，全部標一遍既沒必要也沒效率。如果你的目標很明確，就是想被 AI 引用，那真正該優先處理的其實只有少少幾個。接下來先把這份優先清單一個一個拆開，講清楚每個為什麼有用、難不難做，最後再用一張難度對照表幫你排出動工順序。
為什麼 AI 引用看的是 Schema，而不只是排名
先講一個容易被誤會的前提。結構化資料從來就不是排名因素，Google 講過很多次，加了不保證排得更前面。但在 AI 搜尋的脈絡裡，它的角色變了。
傳統搜尋回給你的是一串連結，使用者自己點進去看。生成式引擎不一樣，它要的是「機器可讀、可驗證的事實單位」——它得先讀懂一個頁面在講誰、講什麼、誰背書、什麼時候更新的，才有辦法決定要不要把這頁的內容寫進答案裡、甚至標上你的名字。Schema 提供的正好是這種結構化的事實。它不是讓內容變好的引擎，而是把好內容翻譯給機器聽的放大器。
這裡要誠實說一件事，免得你抱錯期待。目前沒有任何公開資料能證明「加了某個 Schema，AI 就一定引用你」。有些研究觀察到加了結構化資料的頁面被引用的機率較高，但那是相關性，不是保證。更精確的講法是這樣，你把事實標清楚，至少讓 AI 有乾淨的東西可以抓；你不標，它就得自己從一團文字裡猜，猜錯或乾脆略過你的機率都更高。Schema 是把報名門檻補齊，不是直接發獎。
那為什麼還是值得做？因為它成本低、幾乎不會壞事，而當你的對手都標了、你沒標，在機器眼裡你就是那個資訊不完整、來源不明的頁面。差距會慢慢累積。先把這個心態擺正，下面這份優先清單才看得進去。
想被 AI 引用，最該優先做的五個 Schema
如果要排一份「對 AI 引用最高相關」的優先清單，五個跑不掉：Organization、Article（含 dateModified）、FAQPage、HowTo、BreadcrumbList。它們各自服務 AI 在引用時要確認的一件事——你是誰、這篇可不可信、回答了哪些問題、怎麼一步步做、在網站裡的哪個位置。下面一個一個拆。
Organization——先讓 AI 知道「你是誰」
Organization 標的是你的組織身分，放在首頁與「關於我們」頁。它回答 AI 的第一個問題——這個內容來源到底是誰。
必要的欄位是 name（組織名）、url（官網）、logo。但真正在 AI 引用上拉開差距的是另外兩個進階欄位——sameAs 和 @id。sameAs 讓你把官網跟外部的權威頁面綁在一起，例如你的維基資料條目、產業名錄、官方社群帳號，等於明白告訴 AI「這幾個地方講的是同一個實體」。@id 則給這個組織一個穩定的識別碼，讓其他頁面（文章的 publisher、作者所屬機構）都能指回來。
這件事近一兩年變得特別重要。生成式引擎開始過濾「實體訊號薄弱」的來源——如果你的組織、作者、產品都沒有穩定識別、沒有對外連結佐證身分，就算內容寫得好，檢索系統也可能把你的權重往下調。換句話說，Organization 不只是填個公司名，它是你整個網站在 AI 眼裡「可不可信」的地基。地基鬆了，上面標再多 Schema 都會被打折。
Article 與 dateModified——可不可信，時間戳記說了算
文章頁要標 Article，部落格內容用它的子類型 BlogPosting 語意更貼切。它幫 AI 把標題、作者、發布者、發布與更新時間、封面圖片這些事實對應清楚。
重點欄位是 headline、author、publisher、datePublished，還有一個最容易被漏掉、卻在 AI 引用上特別關鍵的——dateModified。原因是生成式引擎對「新鮮度」非常敏感，傾向引用近期才發布或更新過的頁面，舊內容被選中的機率明顯偏低。這代表什麼？你三年前寫的好文章，如果系統判定它「舊了」，引用的機率會明顯下滑。
dateModified 就是你的對策。每次實質更新內容、補上新數據，就同步更新這個欄位，並在頁面上放一個看得到的「最後更新日期」。這不是作弊，是把「這篇我有在維護」這件真實的事說給機器聽。配合 author 欄位把作者身分標清楚、最好用 sameAs 連到作者的專業頁面或社群，整篇文章在 E-E-A-T（經驗、專業、權威、信任）的訊號上會比一篇匿名、沒有更新時間的文章強得多。
如果整份清單你只能先做一個，我會說先把 Article 做對。因為它一口氣串起作者、時間、發布組織，是少數能同時餵飽「可信度」與「新鮮度」兩個引用條件的類型。
FAQPage——rich results 已經沒了，為什麼還要標
FAQPage 是這份清單裡最需要把話講清楚的一個，因為它的處境最容易被誤解。
先講事實。Google 從 2023 年 8 月開始大幅收窄 FAQ 複合式搜尋結果的顯示，只剩政府、醫療等權威網站還能觸發；到後來，FAQ 複合式搜尋結果對一般網站等於正式退場。也就是說，如果你標 FAQPage 是為了讓搜尋結果上多出那排可展開的問答、多佔一兩行版面——這個誘因已經沒了。很多人聽到這裡的反應是：「那還標它幹嘛？」
關鍵就在這個轉折。FAQ 複合式搜尋結果退場，不等於問答結構失去價值，它只是換了個服務對象。過去你寫 FAQ 是為了在 Google 結果頁展開；現在你寫 FAQ，是為了把使用者的搜尋意圖拆成一組組「乾淨、自成一體、問完馬上有答案」的單元，讓 AI 引擎更容易抽取其中一段直接拿去回答。生成式引擎特別偏好這種問題對答案結構清楚的內容。
不過這裡有個更深的真相，多數人沒說清楚。部分技術觀察指出，ChatGPT、Perplexity 這類引擎在讀 JSON-LD 時，比較像把它當成純文字處理，並不是真的在「解析 FAQPage 這個格式」然後特別禮遇它。意思是，AI 之所以容易引用你的問答，靠的其實是內容本身夠乾淨、夠像一問一答，標不標 FAQPage 標記不是決定性的那一刀。
所以務實的做法是這樣。FAQ 的內容結構照寫，因為它本來就利於被抽取；FAQPage 標記順手加上，反正不會壞事，也讓 Schema 之間的關係更完整；但別把標記當成「加了就被引用」的捷徑。真正在發功的是內容，標記只是把它整理得更整齊。
HowTo——把步驟拆成 AI 抽得走的單元
HowTo 用在「怎麼做某件事」的教學內容，把一連串步驟標成機器讀得懂的有序結構——每一步做什麼、需要哪些工具或材料、預估花多少時間。
它對 AI 引用的價值跟 FAQPage 是同一個邏輯：當使用者問「怎麼做 X」，生成式引擎會去找結構清楚、可以一步步照著走的內容來組答案。一篇教學如果在頁面上就是條理分明的編號步驟，再配上 HowTo 標記，等於把「這是一份操作指南、共有幾步、每步是什麼」直接送到 AI 面前，省下它自己從段落裡拆解的工夫。
要提醒的是，HowTo 跟 FAQPage 一樣，在 Google 一般搜尋結果的複合式呈現上也已經收手，所以同樣別期待它幫你的搜尋結果加版面。它現在的主戰場是答案引擎與 AI 概覽，是給機器當操作藍圖用的。教學型內容才需要它；純觀念、純定義的文章硬套反而不對題。
BreadcrumbList——幾乎零成本的網站地圖
BreadcrumbList 標的是使用者在網站裡的位置路徑，像是「首頁 ＞ SEO 教學 ＞ 結構化資料」。它幫人也幫機器搞懂這頁在你整個網站架構的哪個位置、屬於哪個主題層級。
把它放進優先清單，理由不是它對單篇文章的引用幫助有多大，而是它幾乎不花成本。多數 WordPress 的 SEO 外掛會自動生成麵包屑標記，你常常什麼都不用做就有了。而它換來的是讓 AI 理解你的內容彼此之間的從屬與關聯——這頁是某個大主題底下的一篇，不是孤立的單點。在生成式引擎越來越看重「主題權威體系」的當下，一個清楚的網站結構是加分的背景訊號。連這種免費的東西都不收，等於白白放掉。
把這五個串成一張圖，比各標各的更有用
到這裡你可能會想，那我把五個 Schema 各標一段，不就完成了嗎？這是很多人會停下的地方，但少做了關鍵一步。
零散地標，跟把它們用 @graph 串成一張關聯圖，在機器眼裡是兩件事。前者像給 AI 五張各自獨立的便利貼；後者是給它一張說明彼此關係的地圖——這篇 Article 的發布者（publisher）是這個 Organization，作者（author）是這個 Person，這個 Person 又透過 sameAs 連到外部的專業頁面，整篇文章在 BreadcrumbList 裡又屬於某個分類。當這些實體用穩定的 @id 互相指認、嵌在同一個 @graph 裡，AI 拿到的就不只是「這是一篇文章」，而是「這是一篇有名有姓、有組織背書、來源可查的文章」。
這個差別，就是一個匿名資料點和一個可被引用的來源之間的差別。實務上你不一定要手寫，成熟的 SEO 外掛多半已經會幫你輸出帶 @graph 的整合圖；但你要知道這件事存在、並確認你用的工具有做到，而不是滿足於五段各自為政的標記。
順帶一提，格式一律選 JSON-LD。它是 Google 官方首選，跟網頁內容分離、好維護、外掛支援度高，也是 Google、Bing、Perplexity、ChatGPT 在抽取結構化訊號時共同依賴的寫法。Microdata 跟 RDFa 除非你有非用不可的舊系統，否則沒有理由再碰。
哪個先做？用難度對引用幫助排個順序
道理都懂了，剩下的問題很現實——時間有限，先標哪個。把五個 Schema 放進「實作難度」對「對 AI 引用的幫助」兩個軸來看，動工順序就清楚了。
| Schema 類型 | 實作難度 | 對 AI 引用的幫助 | 適合誰先做 |
|---|---|---|---|
| BreadcrumbList | 低（外掛多半自動） | 中（結構背景訊號） | 所有網站，幾乎免費先收 |
| Article（含 dateModified） | 低 | 高（可信度＋新鮮度雙到位） | 所有有內容的網站，優先 |
| Organization | 中（sameAs 要備齊外部連結） | 高（整站身分地基） | 所有網站，跟 Article 一起做 |
| FAQPage | 中（要整理問答內容） | 中（利於被抽取，非決定性） | 有問答型內容才做 |
| HowTo | 中（要拆解步驟） | 中（教學題的答案藍圖） | 有教學型內容才做 |
讀這張表的方式是這樣。先做難度低、幫助高的——也就是 Article 和 BreadcrumbList，這兩個幾乎所有內容站都該裝，而且裝起來不費力。 Organization 雖然要花點工夫把 sameAs 的外部連結蒐集齊全，但它是整站身分的地基，值得跟 Article 排在同一批一起完成。
FAQPage 和 HowTo 則是「看內容類型才做」的兩個。你網站上有成形的問答內容，FAQPage 才有東西可標；有手把手的教學，HowTo 才對題。沒有對應內容硬去套，標出來也是空的，對引用沒幫助。換句話說，後面這兩個的觸發條件不是「想不想做」，而是「有沒有對的內容」。
最後一個提醒，難度欄寫「低」不代表可以隨便。標記內容必須跟頁面上看得到的東西一致——你標了作者是某人、更新日期是某天，頁面上就得真的有這些資訊。標記跟實際對不上，輕則沒效果，重則被判定為操弄。Schema 的整個價值建立在「誠實地把已經存在的事實說一次」，這條底線踩破了，前面排的優先序全都白排。
標完之後，真正決定你被不被引用的還是內容
把這份清單做完，你的網站在機器眼裡會從「一團要自己猜的文字」變成「一份標好欄位、查得到來源的資料」。但別忘了最前面那句話——Schema 是放大器，不是發電機。
它能放大好內容的效益，卻沒辦法把空洞的內容變得值得引用。AI 引擎最終決定要不要把你寫進答案，看的還是你的內容夠不夠原創、夠不夠準、有沒有真的解決使用者的問題。Schema 做的，是確保當你的內容夠好時，機器讀得懂、認得出、信得過，不會因為一團模糊就把你略過。
所以這件事的正確順序是：內容先扎實，再用這五個 Schema 把它的身分、時間、結構、來源講清楚。兩件事都到位，你才真正具備了在生成式搜尋時代被點名的資格。從今天就先把 Article 跟 dateModified 補上，這是投報率最穩的第一步。