多數人以為 Google 已經親口宣布，結構化資料在生成式 AI 搜尋時代可以放著不管了。這句話流傳的版本通常是「Google 都說不用做 Schema 了」，其實 Google 原文緊接著還有一句「不過」，只是這句常常在轉述的路上被留下。
結構化資料，說白了就是一段寫給機器看的程式碼，明確標出這頁是文章、是組織、還是問答，讓搜尋引擎與生成式引擎不用自己從一堆文字裡去猜。過去做它多半是為了在 Google 搜尋結果多佔一塊版位，現在多了一個更實際的理由，是想讓 ChatGPT、Perplexity 這類引擎在回答問題時，更容易把內容認出來、當成可信的來源引用。Schema 結構化資料 AI 引用之間到底有沒有直接關係，還是只是市場一廂情願的說法，值得把 Google 的原話、真正做過的實測，一次攤開來看清楚。
先從 Google 那句被斷章取義的原文看起，再往下拆真正測過數據的研究怎麼說。
Google 真的說「結構化資料不用做」了嗎？
這句話的源頭，是 Google 在 2026 年 5 月 15 日發布的一份官方指南，主題是「針對 Google 搜尋的生成式 AI 功能進行網站最佳化」，由 Google 搜尋團隊的 John Mueller 透過官方部落格公告。指南裡有一節專門「破解生成式 AI 搜尋迷思」，列出幾件「不需要做的事」，結構化資料正好是其中一項。
Google 原文完整的意思是，結構化資料不是生成式 AI 搜尋的必要條件，也不需要新增任何特殊的 schema.org 標記，但緊接著同一段還有下一句，建議繼續使用結構化資料，作為整體 SEO 策略的一部分，因為它有助於在 Google 搜尋中取得複合式搜尋結果的顯示資格。前半句經常被單獨截出來轉述，後半句的「不過」則留在原地，沒有一起被搬過來。
這不是同一件事被講了兩次，而是兩件不一樣的事。「不是必要條件」講的是，就算沒做，頁面也還是有機會出現在 AI 摘要裡；「不用做」講的是，這件事完全沒有價值，可以整組拿掉。前者是 Google 的原話，後者是被簡化以後的版本，兩者的意思其實差了一截。轉折語之後的內容，在轉述的路上本來就最容易被留下，這是資訊傳遞常見的通病，但結果就是「不需要」被讀成「不用做」，一路傳到不少中小企業主耳裡，變成拿掉結構化資料的理由。
結構化資料「沒有必要屬性」，不代表「不用標」
Google 另外有一份專門講 Article、NewsArticle、BlogPosting 這類文章型結構化資料的技術指南，裡面有一句話常常被斷章取義：「並沒有所謂的必要屬性，請改為加入適用於內容的屬性。」這句話常被簡化成「反正沒有規定，不做也沒差」，但原意其實是給網站主彈性，不是每個欄位都得硬填，該有的內容自然會有對應的欄位，不必為了符合規格硬湊。
同一份指南接著列出建議填的欄位：作者（author）、標題（headline）、代表圖片（image）、首次發布時間（datePublished），以及最近一次修改時間（dateModified）。前三個屬於基本身分辨識，讓系統知道這篇是誰寫的、講什麼、封面長怎樣；後兩個屬於時間軸，而 dateModified 又是這五個裡面最容易被忽略、卻在後面談新鮮度時特別關鍵的一個。
先回到「必要屬性」這個說法本身，它管的是這個標記格式裡哪個欄位一定要出現，跟這整套標記值不值得做，根本是兩層問題，卻常常被壓縮成同一句話講。搞懂這個差別，才不會把「填哪個欄位有彈性」誤讀成「整件事可以不做」。
普林斯頓那份研究，測出來的是什麼？
要判斷結構化資料跟被 AI 引用之間有沒有直接關係，比起看誰講了什麼，更該看有沒有人真的拿數據測過。普林斯頓大學、喬治亞理工學院與 Allen Institute for AI 三個團隊在 2024 年發表的一份研究「GEO：Generative Engine Optimization」，做的正是這件事。研究團隊建了一套涵蓋一萬筆真實查詢的測試集，把常見的內容修改手法一一套用到網頁上，實際測量每種手法能不能讓這頁內容更常出現在生成式引擎的回答裡、佔的篇幅更多。
結果排在前面的三種手法，分別是幫內容補上具名的引用出處、加入可查證的真實引語，以及加進可查證的統計數字。這三招讓內容在其中一項能見度指標上平均提升三到四成，在另一項偏主觀的印象指標上也提升了一成五到三成；研究團隊另外把同一批方法拿到 Perplexity 做真實部署測試，效果同樣重現，其中加統計數字這招在某一項指標上的提升幅度最高，接近四成。相對地，傳統 SEO 很愛用的關鍵字堆疊，在這套測試裡幾乎沒有帶來任何提升，放到 Perplexity 的真實測試甚至比完全不優化還差了一成左右。
這篇論文從頭到尾，都沒有出現過一次「schema」或「structured data」這兩個詞。一份真的拿去做實證檢驗、經過同儕評閱的研究，測的完全是內容本身怎麼寫：出處寫沒寫清楚、有沒有可查證的引語、數字給得夠不夠具體，跟頁面上有沒有埋 JSON-LD 一點關係都沒有。
Google、Perplexity、ChatGPT，讀你網頁的方式不一樣
前面兩節分開來看，會冒出一個新的疑問，如果研究測出來的是內容手法，結構化資料是不是在生成式引擎眼裡完全沒有位置？答案沒有那麼絕對，因為問題不是有沒有位置，而是不同引擎，位置不一樣。三家生成式引擎存取網頁內容的機制，本來就不是同一套。
Google 的生成式 AI 功能，運作基礎是既有的 Google 搜尋索引，透過檢索增強生成（RAG）從索引裡找出相關又新的網頁，再搭配查詢擴展，同時發出好幾個相關子查詢去拉更多資料進來輔助回答。換句話說，AI 搜尋還是要從既有索引裡找頁面，一個頁面沒被 Google 收錄，就沒有被引用的機會，這跟結構化資料標得多完整都無關，是更前面一關的問題。
Perplexity 的官方文件把它的爬蟲拆成兩種，一種叫 PerplexityBot，負責建立索引，會遵守網站的 robots.txt 規則；另一種叫 Perplexity-User，是使用者實際發問的當下，即時造訪某個頁面去核對答案內容，因為是使用者當場觸發的單次讀取，通常不受 robots.txt 限制。也就是說，同一個網站，有時候是先建好索引再回答，有時候是使用者一問、當場才去讀，讀到的內容新不新、標記讀不讀得到，會因為這兩種路徑而不一樣。
ChatGPT 的搜尋功能又是另一套邏輯。使用者輸入問題後，ChatGPT 會把問題改寫成一個或多個更精確的查詢，送去合作的搜尋供應商取得結果，再由模型判斷相關性與可信度，決定要引用哪些內容、怎麼排序。OpenAI 官方也明講，沒有辦法保證任何網站在搜尋結果裡排到最前面。三種機制擺在一起看就清楚了，同一段結構化資料，在三個引擎眼裡能不能被讀到、讀到之後算不算數，答案本來就不會一樣，這是技術架構上的差異，不是話術。
結構化資料還該不該做？
把前面四節放在一起看，答案其實沒有那麼模糊。結構化資料不是一按下去就能觸發 AI 引用的開關，沒有任何公開研究證明標了某個 schema，AI 就一定會引用你，這句話目前找不到證據支持，也不該被寫成保證。但它同樣不是可有可無的裝飾，Google 官方自己也講得清楚，結構化資料值得繼續做，理由是它有助於取得複合式搜尋結果的顯示資格，讓機器少猜一點，內容被誤讀的機率低一點。
具體要優先做哪幾件事，講得出機制的只有兩個。第一個是 Article 的 dateModified 與 datePublished，這兩個屬性的作用是把這篇內容有沒有在維護，講給系統聽；但前提是內容真的有實質更新才同步改這個日期，只改日期、內容沒動，等於自己送出一個假的新鮮訊號，長期下來反而可能被判定為操弄。第二個是 Organization，標的是這個網站背後是誰，對應到的是可信度這條線，而不是引用保證這條線，把身分講清楚，是讓系統少一分猜測，不是換來一張引用門票。
比起糾結該標哪五種、哪十種 schema，普林斯頓那份研究已經指出更值得先做的事：把每個有份量的說法補上具名出處，把統計數字換成可查證的具體數字，能引用真實的話就直接引，而不是含糊帶過。這些都是內容本身的功夫，跟會不會寫 JSON-LD 完全無關，卻是目前唯一有實證支持、真的能提升被引用機率的做法。
結構化資料這件事，角色其實沒有變過。它一直都是把已經存在的事實，用機器讀得懂的方式再講一次，不是幫內容加分的魔法。真正變了的，是市場把它說得太滿的期待，好像標一段 JSON-LD，AI 引用就會自動找上門。把地基顧好，也把真正被證實有效的內容功夫做在動筆的當下：具名出處補齊、數字換成可查證的、能引用真實的話就直接引。這兩件事分開看、分開做，才不會把力氣錯放在標記本身，卻忘了先把內容寫紮實。