多數人對 JSON-LD 的誤解
過去十年 SEO 顧問教的是:
「補上 JSON-LD schema,能讓 Google SERP 顯示星星評分、FAQ 折疊、產品價格等 rich result。」
這個說法本身沒錯,但只說了一半。Google rich result 是「附加好處」,但 JSON-LD 真正的戰略價值在 AI 時代才浮現:LLM 訓練時會大量解析這些標記。
為什麼 LLM 在意 schema.org?
LLM 在訓練前要先把網頁文字「結構化」——區分標題、內文、作者、日期等元素。傳統 HTML 解析依賴 H1 / H2、<article>、<time> 等語意元素,但這些可信度有限(誰都能亂用 H1)。
JSON-LD 提供的是「作者親口宣告」級別的事實:
"@type": "Article"— 我宣告這頁是文章"author": {"@type": "Person", "name": "李醫師"}— 作者是這個人"datePublished": "2024-03-15"— 發布日期"about": {...}— 主題實體
LLM 訓練時會把這些宣告當作結構化事實寫進向量空間。同樣的內容有 vs 沒有 JSON-LD,AI 對它的「理解」差很多。
4 個 schema 對 GEO 影響最大
1. Organization(公司實體)
每個品牌官網首頁與「關於我們」頁都該有。包含:
name— 公司全名url— 官方網址logo— logo 圖sameAs— Wikipedia、LinkedIn、官方社群連結contactPoint— 客服資訊
為什麼重要:建立「品牌實體」的權威基礎。沒有 Organization schema,LLM 看到的只是文字字串,沒有結構化的「公司」概念。
2. Article(文章內容)
每篇部落格 / 新聞文章都該有。包含:
headline— 標題author— 作者(含 Person schema)datePublished/dateModified— 日期publisher— 發行單位image— 主圖
為什麼重要:直接影響 E-E-A-T 維度分數。沒有 Article schema 的文章在 LLM 眼裡權威性大打折扣。
3. FAQPage(問答結構)
如果你的內容是 FAQ 格式,必須加上 FAQPage schema。包含:
mainEntity— 問答陣列- 每個問題有
Question與Answer
為什麼重要:Perplexity 與 Google AI Overviews 對 FAQ 結構引用率極高。一份用 H2 標問題、純文字答案的 FAQ 跟一份包進 FAQPage schema 的 FAQ,引用機率差 5 倍以上。
4. Product / Service(產品 / 服務)
電商與 SaaS 該補。包含:
name,description,brandoffers— 價格、可購買區域aggregateRating— 評分review— 評論
為什麼重要:使用者問 AI「OOO 推薦」時,LLM 在內部會比對候選產品的結構化屬性。沒進結構化的產品資訊,AI 比都沒得比。
為什麼 JSON-LD > 其他格式?
過去也有 Microdata 與 RDFa 兩種結構化資料格式。為什麼 GEO 偏好 JSON-LD?
| 比較 | JSON-LD | Microdata | RDFa |
|---|---|---|---|
放在 <script> 區塊 |
✅ 不影響 HTML 結構 | ❌ 散在 HTML 各處 | ❌ 同 |
| 維護難度 | 低(獨立區塊) | 高(每段都要) | 高(同) |
| 主流支援 | Google / OpenAI / Anthropic | 部分支援 | 部分支援 |
| 出錯率 | 低 | 中 | 中 |
Google 在 2024 年的官方文件中正式推薦 JSON-LD 為主要格式。 OpenAI 與 Anthropic 在訓練時也優先解析 JSON-LD(其他格式有時會被忽略或誤解)。
常見錯誤
我們在客戶健檢中看過的:
- 錯誤 1:用 schema validator 沒測過就上線。Schema 有錯時 Google / LLM 直接忽略整個 block
- 錯誤 2:FAQPage schema 內容跟頁面實際 Q&A 不一致——LLM 會偵測這個不一致並懲罰整個網站
- 錯誤 3:只在首頁放 Organization 但沒在子頁也放——LLM 解析到子頁時還是看不到公司實體
健檢能告訴你什麼
GeoWeb 的「結構化資料」維度(10% 權重)會逐項列出:
- 你網站有哪些 schema、缺哪些
- schema 有沒有語法錯誤
- schema 內容跟頁面 visible content 是否一致
- 有沒有「假 schema」(內容不存在但 schema 宣告存在)
如果你看完報告需要技術人員協助補上 schema 並維護,我們提供 GEO 顧問服務:[email protected]
GEO 進階系列 #9。前一篇:「E-E-A-T 在 AI 時代為什麼比過去更重要?」
12維裡結構化資料只佔10%,是不是代表其實不用太認真做?感覺投報率不高欸
我反而想糾正一下這個直覺哈哈。10% 是它在總分裡的配重,不是它重不重要,權重低不代表你可以缺。而且結構化資料是少數補了幾乎一定加分、做錯才扣分的項目,cp值其實偏高。真正吃力的是內容權威、E-E-A-T那些慢工,schema反而是相對好補的基本盤。我會建議先把這種地基型的補滿,再去攻難的。
工程師路過補一個我自己踩過的雷:純react csr塞json-ld,之前吃過虧有些crawler真的抓不到,後來改ssr放<head>才穩定。想問這篇沒講到的是,是不是每一家AI引擎的crawler行為都一樣不吃js動態塞的,還是有的會執行js有的不會,這個有沒有整理過的清單?
補充一個本文沒提到的:schema裡的sameas真的要放對,亂連到不是自己的社群帳號反而會讓實體判斷亂掉,我們踩過這雷
12維裡結構化資料只佔10% 權重 那是不是代表其實沒那麼重要?感覺花一堆力氣cp值不高
請問Organization的sameAs到底要連哪些?文章只說Wikipedia / LinkedIn / 官方社群,但我們小公司沒Wikipedia也沒LinkedIn啊
我們也小公司 我自己的做法是有什麼連什麼、不要硬湊:FB粉專、IG、官方YouTube、Google商家檔案這些只要是你本人實際在經營的官方帳號都可以放。沒Wikipedia很正常別焦慮,重點是別亂連到不是自己的帳號(樓上有人提過這雷)。寧可少放幾條真的,也不要塞一堆攀關係的假連結。
常見錯誤那段最有用 我們之前就是faqpage schema裡寫的問答跟頁面顯示的不一樣(工程師偷懶複製舊版)難怪一直怪怪的
我們電商站去年補了Product schema的offers跟aggregateRating,老實說有沒有因為這個被AI引用很難講,反正GA也看不出來orz大家有比較科學的觀測方法嗎
半信半疑,上面剛好也有人問過這個5倍數字,我換個角度問:這是所有網站通用的量級,還是你們挑比較漂亮的案例出來講的?畢竟每個站體質差那麼多,感覺不會全部都套用同一個倍率
老實說這是我們在客戶站做before/after觀察到的量級感受,不是嚴謹對照實驗,所以我寫5倍以上其實算抓個體感區間、不該被當成paper等級的數字看待😅 變因太多(內容本身好不好、站的權威度)很難乾淨切出來。你就理解成有結構vs純文字答案,差距是肉眼可見的明顯這個方向就好,別拿去當KPI報告引用。
笑死 我以前真的以為JSON-LD只是拿來騙Google顯示星星評分跟FAQ折疊那個而已 完全沒想過LLM訓練會去讀==
有沒有人實際量過補schema之後ai引用真的有變多?ga看不出來這種東西啊 大家怎麼觀測
+1問 我們補習班網站的schema也是外包廠商說有補就沒再管過 我自己完全看不出補了之後有沒有差 GA也不會告訴你這個 是不是只能乾等有一天被AI提到才知道有效
microdata / rdfa那個表格喚醒我塵封的記憶 想當年還在那邊一段一段塞itemprop有夠痛苦 還好現在都json-ld了
那是不是代表沒辦法賭運氣,只能當作「一定有一部分crawler讀不到」來規劃,全部都要ssr出來才保險?還是有辦法先判斷自己網站主要被哪幾隻抓,針對性處理就好?
好問題,這篇沒展開是因為它本身就能寫成一整篇哈哈。簡單講:你不能假設對方一定會跑你的JS。有些crawler / retrieval會執行、有些只抓初始HTML,所以純CSR把JSON-LD留在client端塞,風險就是有人讀得到有人讀不到。最穩的還是讓結構化資料在初始HTML就存在(SSR / SSG / 預先inline)。判斷自己是不是這種風險架構很簡單:檢視原始碼看JSON-LD在不在裡面,不在就代表你在賭爬蟲會不會執行JS,建議別賭,想辦法讓它出現在初始HTML。你的架構如果比較複雜、一時改不動,可以寄信附網址給我,我幫你看實際情況比較準。
作者親口宣告這個比喻蠻好懂的H1誰都能亂塞 但author寫在JSON-LD裡確實是另一回事,這段有打到我
常見錯誤2說FAQPage schema跟頁面Q&A不一致會「懲罰整個網站」,這個懲罰是真的會擴及全站還是只影響那一頁?講得有點嚇人
用詞我承認寫得偏重了一點😅 比較準確的說法是:信任是"站台級"累積的,當一個引擎抓到你schema宣告的東西跟使用者實際看到的對不上,它對你整站宣告的可信度評價會打折,不是只當作那一頁的單點問題。所以與其說"懲罰",不如說"你自己把信用額度花掉了"。實務上就守一條:schema寫什麼,頁面上肉眼就要看得到一模一樣的東西,別放只給機器看的隱藏內容。
我們去年是把offers價格、aggregateRating都補了,但一直搞不清楚這樣算不算「進得了比較」而已,還是補了就等於比較容易被AI推薦?想確認一下這兩件事是不是我搞混了
會比較容易被納入比較名單,但別誤會成寫了就會被推薦哈哈,這兩件事差很遠。schema的作用是讓你的產品屬性變成可被結構化讀取、不會在第一關就被漏掉;要不要被推薦還是看你產品本身、評價真實度、跟其他結構化信號。aggregaterating尤其要老實,數字跟頁面實際評論對不上反而是前面講的那種扣分雷。先求進得了比較,再談比贏別人。
先收藏 等等補我自己網站的schema QQ
FAQPage引用機率差5倍以上 想問這個數字是哪來的?自家健檢統計還是有paper?沒來源的話我會打個問號🤔
中小企業主視角:這些我看得懂 但要叫我自己寫JSON-LD還要過validator不出錯 老實說我寧可花錢外包,時間成本算下去比較划算
說真的看到最後那個免費健檢 + 顧問服務的連結 就懂這篇在幹嘛了ㄏㄏ 不過內容是還算實在啦
推organization要每頁都放這點 之前以為首頁放一次就好 結果子頁llm根本不認得我們是誰