評論類的 Schema，是整個結構化資料家族裡規範最嚴、也最多人標錯的一支。別的類型標錯了頂多沒效果，Review 和 AggregateRating 標錯，輕則星星消失，重則整站的結構化資料被 Google 手動處置，連帶其他頁面的富結果一起陪葬。我們接過不只一個案子，官網首頁掛著自己寫的「客戶五星好評」加上 Organization 的 AggregateRating，老闆還以為這是 SEO 加分項。這篇把界線一次講清楚：什麼場景可以標、欄位怎麼寫、怎麼檢測，以及最重要的——為什麼 Google 和 AI 都不准你自己給自己打分數。
Schema 是信任的機器可讀層
先劃界。Schema 全家族的入門與選型，我們在 Schema 結構化資料完整指南 已經寫過，這篇不重複。本篇只處理評論類：Review、AggregateRating，以及它們掛在 Product、LocalBusiness、Organization 底下時的規範差異。
為什麼評論類值得單獨寫一篇？因為它碰到的不是技術問題，是信任問題——口碑是 GEO 的信任層，AI 推薦品牌前會先查第三方怎麼說你。評論 Schema 做的事，就是把這層信任翻譯成機器可讀的格式：這個產品幾分、幾個人評、誰評的、什麼時候評的。搜尋引擎讀它決定要不要給你星星，AI 讀它決定要不要引用你。正因為它直接影響信任判斷，Google 對它的規範才會嚴到近乎苛刻——一套允許自己給自己打分的系統，分數就沒有意義了。
最大地雷先講：self-serving reviews 禁令
直接講結論：LocalBusiness 和 Organization 類型，不能在自家網站上標自己的 AggregateRating 或 Review。這不是我們的保守解讀，是 Google 結構化資料規範的明文規定。2019 年 9 月 Google 更新評論摘要規範時，把這類標記定義為 self-serving reviews（自利評論），從那天起就不再顯示星星。
白話翻譯：你是一間行銷公司，官網首頁放了十則客戶見證，然後用 Organization 加 AggregateRating 標「4.9 分、127 則評論」——這就是教科書等級的違規。你是一間餐廳，把 Google 評論上的 4.6 分搬回官網，用 LocalBusiness 標出來——一樣違規。評分數字是真的也沒用，問題不在數字真假，在「被評的對象」跟「放評分的網站」是同一個實體。裁判不能自己兼球員，就這麼簡單。
違規的代價分兩級。輕的：星星不顯示，標了等於白標。重的：如果 Google 認定是刻意操弄，會發「結構化資料問題」的手動處置，整個網站的富結果資格被拔掉——不只評論，你的 FAQ、麵包屑、文章標記全部一起失效，直到你清乾淨並通過重審。
那正確做法是什麼？讓評論住在它該住的地方：Google 商家檔案的評論、蝦皮或 momo 商城的買家評價、Facebook 的粉專評論。這些第三方平台會自己處理結構化資料，Google 地圖包和知識面板會直接顯示你的星等，根本不需要你在官網動手。官網上的客戶見證可以照放，放文字、放截圖都行，就是不要加評分標記。
第一步：什麼場景可以合法標
禁令講完了，講可以做的。Review 和 AggregateRating 在很多類型上是完全合法、而且 Google 鼓勵的，關鍵是被評的對象不能是你自己這個組織或店家。一張表看懂：
| 場景 | 能不能標 | 理由或條件 |
|---|---|---|
| 電商產品頁標真實買家評論（Product） | 可以 | 評的是產品不是公司；評論必須真實、可查、就顯示在該頁 |
| 書籍、課程、食譜、軟體、電影的介紹頁 | 可以 | Book、Course、Recipe、SoftwareApplication、Movie 都是 Google 支援的評論類型 |
| 你的部落格評測別家的產品或服務 | 可以 | 你是評論者不是被評者，用 Review 標、author 寫你自己，完全合法 |
| 官網首頁用 Organization 標自家整體評分 | 不行 | self-serving，明文禁止 |
| 店家官網用 LocalBusiness 標自家 Google 評論分數 | 不行 | 同上，把第三方分數搬回自家網站標，一樣算自利評論 |
| 服務頁用 Service 類型標評分 | 不建議 | Service 不在評論摘要支援清單內，標了也不會有星星 |
三個共同條件，缺一不可。第一，評論必須真實存在、來自真實用戶，不能是行銷部自己寫的。第二，標記的評論內容必須就顯示在那一頁上，用戶看得到的跟機器讀到的要一致。第三，不能挑食——只標五星、把一星藏起來不標，被抓到跟造假同罪。這三條其實就是白帽口碑的原則換了一個技術形式：不灌水、不假造、不隱瞞。
第二步：Review schema 欄位正確寫法
合法場景確認了，來寫欄位。單則評論用 Review 類型，四個核心欄位加一個常被忘記的：
| 欄位 | 正確寫法 | 最常見的錯誤 |
|---|---|---|
| itemReviewed | 被評的對象，完整的巢狀物件（如 Product 加名稱） | 指向 LocalBusiness 或 Organization 自己；或只寫一個名字字串 |
| author | Person 或 Organization 型別的物件，帶 name | 直接塞一個純文字字串，這是富結果測試最常報的錯之一 |
| reviewRating | Rating 物件，含 ratingValue；量表若非 1 到 5 要寫 bestRating 和 worstRating | 只寫數字沒寫量表，10 分制的 8 分被當 5 分制解讀就變成爆表錯誤 |
| datePublished | ISO 8601 日期格式，例如 2026-07-02 | 寫「三天前」「上個月」這種相對時間 |
| reviewBody | 評論的實際文字內容 | 省略不寫。技術上非必填，但沒有內容的評論對 AI 端毫無引用價值 |
提醒一件事：author 的錯誤率高到 Google 在 2023 年之後把它列為明確的檢查項。很多套版和外掛產出的評論標記，author 直接給字串，以前能過，現在會在測試工具裡跳警告。檢查你的電商模板，別假設外掛都是對的。
第三步：AggregateRating 寫法與可見性原則
AggregateRating 是多則評論的統計值，掛在 itemReviewed 的物件底下。必要欄位三個：ratingValue（平均分數）、ratingCount 或 reviewCount（評分數或評論數，至少擇一）、量表非 1 到 5 時的 bestRating。寫法本身不難，難的是「可見性原則」，這裡最容易踩雷。
原則只有一句話：標記裡的每一個數字，都必須跟頁面上顯示的一致。標 4.7 分，頁面就要顯示 4.7 分；標 215 則評論，頁面就要讓用戶找得到這 215 則（分頁沒關係，但入口要在）。我們看過的常見翻車法：資料庫算出來 4.68，前端四捨五入顯示 4.7，標記卻寫 4.68——不一致。或是評論功能下架了，標記忘了拆，頁面上一則評論都沒有，AggregateRating 還掛著 89 則——這種殘留標記放久了就是手動處置的候選名單。
還有一個組合題：有 AggregateRating 就不必每則 Review 都標，但反過來，只標一則 Review 卻宣稱有幾百則統計，邏輯上說不通，測試工具不會報錯，品質演算法卻看得出來。我們的建議是產品頁兩個都放：AggregateRating 給統計、再標最新或最有代表性的幾則 Review 給內容，機器讀得到分數也讀得到脈絡。
第四步：檢測與除錯——工具兩個、訊息一張表
寫完不代表對。檢測流程照這個順序走：
- 把頁面網址或原始碼丟進 Google 富結果測試（Rich Results Test），確認評論摘要被偵測到、零錯誤。這是判定「有沒有富結果資格」的官方標準。
- 需要驗證 Schema.org 語法本身（不只 Google 支援的部分），用 Schema Markup Validator 再跑一次。
- 上線後兩到四週，進 Google Search Console 的「強化項目」看評論摘要報告，這裡會列出全站規模的錯誤與警告，比單頁測試更能抓到模板性的問題。
常見的 violation 訊息長這樣，看到訊息先對表，別瞎猜：
| 測試工具或 GSC 訊息 | 白話意思 | 處理方式 |
|---|---|---|
| 檢閱的項目不得為 LocalBusiness 或 Organization 類型 | 你踩到 self-serving 禁令了 | 整段評分標記拆掉，評論改經營第三方平台 |
| author 欄位值的類型無效 | author 給了字串，不是 Person 或 Organization 物件 | 改成巢狀物件，補上 name |
| ratingValue 超出範圍 | 分數超過量表上限，通常是沒宣告 bestRating | 補 bestRating 和 worstRating，或修正分數 |
| 缺少 itemReviewed 欄位 | Review 沒說評的是什麼 | 補上完整的被評對象物件 |
| 偵測到的標記內容未顯示於網頁上 | 可見性原則違規，機器讀到的用戶看不到 | 讓評論內容與分數實際顯示在該頁，或拆掉標記 |
如果已經吃到手動處置：進 GSC 的「手動處置」報告看範圍，把違規標記全站清乾淨（是全站，不是只清被點名的那頁），然後提交重審請求，誠實寫明改了什麼。重審由真人審核，通常要等數週，而且沒有捷徑。這也是為什麼我們一直說，評論標記寧可保守，別賭。
第五步：評論資料與 E-E-A-T 的連動
最後拉回信任層的視角。E-E-A-T 的第一個 E 是 Experience——真實使用經驗。演算法沒辦法直接感受你的產品好不好，它只能讀證據，而真實評論就是最直接的 Experience 證據：具體的使用情境、日期、評論者、有好有壞的分數分布。正確標記的評論資料，等於把這些證據整理成機器一秒讀懂的格式。
AI 端更是如此。Profound 的 6.8 億筆引用研究顯示，Perplexity 和 Google AI Overviews 引用最多的網域都是 Reddit，論壇型 UGC 是 AI 的第一信任來源（細節見 Perplexity 引用機制深拆）。AI 判斷一個品牌可不可信，讀的是第三方怎麼說你，不是你官網怎麼說自己——這跟 Google 的 self-serving 禁令是同一套邏輯的兩個版本。
我們自己驗證過這件事的另一面：拿自家品牌問 Perplexity，引用來源幾乎全指向同一篇第三方舊文，部分描述早已過時（實測過程見 AI 是怎麼介紹你的品牌）。你的評論 Schema 標得再漂亮，AI 對你的認知還是可能被一篇你控制不了的舊文章綁架——口碑不只要經營，還要定期監測。
收尾給一份 checklist，發布評論標記前逐項打勾：
- 被評對象不是自己的 Organization 或 LocalBusiness——這條不過，後面全部免談。
- 每一則標記的評論都真實存在、來自真實用戶、可以回溯查證。
- 評論內容與分數就顯示在標記所在的那一頁。
- author 是 Person 或 Organization 物件，不是字串。
- ratingValue 與頁面顯示一致，量表非 1 到 5 有宣告 bestRating。
- 沒有挑食：分數分布如實呈現，不是只標好評。
- 富結果測試零錯誤，上線後追蹤 GSC 評論摘要報告。
- 自家品牌的星等，交給 Google 評論等第三方平台去長，官網不碰。
評論 Schema 的技術規則背後只有一個原則：信任必須來自第三方，機器才認。標記做的是翻譯，不是製造——想知道你的品牌在 Google 星等與 AI 引用裡現在長什麼樣、該從哪裡補強，看看我們的 GEO 服務。
延伸閱讀：Rich Results 結構化資料進階指南 | Schema 結構化資料完整指南 | Google 評論管理 SOP