我是吳承學，做搜尋引擎優化二十年，被問最多的結構化資料就是評價標記。大家都想在搜尋結果裡秀出那排星星，但這也是最容易出事的一塊：標記寫錯會被判濫用，評價來源不乾淨會被判操縱，星星不但拿不到，還可能連累整站信任。這篇只談 Review 與 AggregateRating 這一組，怎麼正確標記、怎麼合規、怎麼蒐集經得起查證的真實評價，以及怎麼避開會讓你被判濫用的地雷。
1. 我先搞懂：星星不是裝飾，是機器對「真有人評過」的承諾
搜尋結果裡的星等評分，佔的版面不大，影響卻很直接。它對讀者是一種背書，對搜尋引擎則是一個要負責任的承諾：這個評分背後，真的有可查證的評價存在。正因為它會直接影響點擊，被濫用的動機很強，規範也相對嚴格。把評價標記當成「加個程式碼就有星星」的技巧，通常是麻煩的開始。
1.1 Review 與 AggregateRating 分別在講什麼
Review 描述的是單一則評價，涵蓋是誰評的、給幾分、寫了什麼、什麼時候評的。AggregateRating 則是把多則評價彙總成一個總星等與總則數。前者是個體，後者是統計，兩者要對得上：頁面上實際列出的評價，要能支撐你彙總出來的那個數字。我看過最尷尬的一種情況，是頁面上只擺了三則評價，AggregateRating 卻標了上百則、還打了近乎滿分，這種明顯兜不攏的組合，正是搜尋引擎在找的濫用訊號。
1.2 標記的內容必須是頁面上看得到的評價
我反覆強調一條底線：結構化資料裡的評價，必須與頁面上使用者看得到的內容一致。若程式碼裡標了一堆好評，頁面上卻找不到，這就是典型的被判濫用情境。標記是把可見內容翻給機器聽，不是憑空生出內容。
2. 我怎麼把 Review 與 AggregateRating 標對
正確標記的關鍵，是欄位齊全、彼此對得上、且掛在正確的主體上。評價是針對某個特定對象（某項服務、某個產品）而來，就要標在那個對象身上，不能把整站的評價硬掛在首頁充場面。
| 欄位 | 屬於 | 常見錯誤 |
|---|---|---|
| author | Review | 留空或填組織自己 |
| reviewRating | Review | 缺最高分基準值 |
| reviewBody | Review | 頁面上找不到對應文字 |
| datePublished | Review | 沒有日期、無法查證 |
| ratingValue | AggregateRating | 與實際評價算不出來 |
| reviewCount | AggregateRating | 灌水、與頁面則數不符 |
2.1 一份對得起來的評價標記
下面是我常用的骨架，示範網址用 example.com。重點在於 AggregateRating 的 ratingValue 與 reviewCount，要真的能由底下列出的 review 算出來，兩邊不能各報各的。
{
"@context": "https://schema.org",
"@type": "Service",
"name": "示範服務",
"url": "https://example.com/service/",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "38",
"bestRating": "5"
},
"review": [
{
"@type": "Review",
"author": { "@type": "Person", "name": "示範使用者" },
"datePublished": "2026-03-11",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
},
"reviewBody": "與頁面上顯示完全一致的評價內容。"
}
]
}2.2 標在對的主體上，並通過驗證
評價要標在被評的那個對象上，主體型別要用得恰當。標記完成後，我一定用結構化資料測試工具與結構化資料驗證器跑一遍，確認沒有語法錯誤、沒有重複型別衝突，再逐項核對標記內容與頁面可見文字是否一致。這一步跳過，等於把風險留給日後。
3. 我對評價來源特別挑剔，因為它決定會不會被判操縱
能不能秀星星，很大程度取決於評價從哪裡來。來源乾淨、由真實客戶產生、能追溯到真實往來，星星才站得住；來源可疑、由自己灌水或誘導產生，遲早會出問題。我在協助客戶時，第一件事就是釐清評價的產生機制。
3.1 只採計來自真實往來的評價
我的標準是：評價要來自實際完成並驗收的服務或交易。有一個公正的收集與審核機制，禁止內部自行灌水，這個機制本身就是可信度的一部分。當你能說明「這些評價都來自真實完成的案件」，讀者與機器的信任基礎才穩固。我在協助客戶規劃評價頁時，通常會建議把這套收集機制寫成一小段公開說明，放在評價區塊旁邊，讓讀者知道評價從哪裡來、怎麼被審核，這種透明度本身就是一種信任加分。
3.2 別把別的平台的評分直接搬來標
常見的地雷，是把第三方平台上的星等抓下來，標成自己頁面的評價。這在規範上有明確限制，因為那不是使用者直接在你頁面留下的評價。我的建議是清楚區分「自家收集的第一手評價」與「外部平台的評價」，不要混為一談去標記。若真的想引用外部平台的口碑，可以在頁面上以引述、連回原始出處的方式呈現，讓讀者自行查證，而不是把它塞進結構化資料當成自家評分去彙總。這一條界線分清楚，能省掉日後很多麻煩。
4. 我這樣蒐集真實、可驗證的評價
好的評價不是等來的，是設計出來的。我協助客戶時，會把蒐集流程做成可重複、可留存憑證的機制，讓每一則評價日後被問起時都答得出來源。
| 環節 | 做法 | 目的 |
|---|---|---|
| 邀請時機 | 在服務完成、驗收之後 | 確保評價對應真實往來 |
| 邀請對象 | 實際完成交易的客戶 | 避免無效或虛構評價 |
| 內容真實性 | 不代寫、不誘導評分 | 降低被判操縱風險 |
| 資料留存 | 保留同意與往來紀錄 | 被查證時可回溯 |
| 當事人同意 | 刊登前取得書面同意 | 符合個資保護規範 |
4.1 讓評價可回溯，是合規的底氣
我要求客戶替每一則對外展示的評價，留下可回溯的線索：對應到哪一次服務、當事人是否同意刊登。當評價能被回溯，你面對搜尋引擎的品質審查或使用者質疑時，就有底氣。刊登涉及個人的評價與見證前，取得書面同意是基本動作。
4.2 不刪負評、不只放五星
清一色滿分、找不到任何一則中性或負面回饋的評價牆，反而顯得可疑。我通常建議保留真實的不同聲音，讓評價分布看起來像真的。刻意過濾到只剩好評，短期好看，長期會侵蝕讀者對整體評價的信任。更務實的做法，是在中性或負面評價下方誠實回應處理方式，讓讀者看到你面對問題的態度，這種展現比一整排滿分更能建立信任。
5. 我用一份清單避開會被判濫用的地雷
評價標記翻車，往往不是因為做了什麼壞事，而是不小心踩到規範。我上線前會照一份清單逐項確認，把可預見的風險先排掉。
5.1 上線前的自查重點
我核對的項目包括：標記的評價頁面上都看得到、AggregateRating 的數字算得出來、評價來自真實往來、沒有把第三方評分冒充為自家評價、每則評價都有作者與日期、也沒有把整站評價硬掛在無關頁面。這幾項守住，被判濫用的機率就大幅下降。
5.2 出問題時，先回到「一致」兩個字
若星星消失或收到品質警訊，我第一個檢查的永遠是一致性：標記與頁面內容對不對得上、彙總數字與實際評價符不符合。多數評價標記的問題，根源都在標記與事實脫節。修好一致性，通常就修好了大半。這類調整生效需要時間讓機器重新抓取，不會立即反映。
6. 常見問題
6.1 頁面沒有真實評價，可以先標記等之後補嗎
不建議。標記必須對應頁面上真實存在、使用者看得到的評價。先標記後補內容，屬於容易被判濫用的情境，風險遠高於好處。
6.2 可以把外部平台的星等標成自己的評價嗎
要非常謹慎。規範對第三方評價的使用有明確限制，把別處的評分直接標成自家頁面評價，容易被視為不當使用。建議清楚區分自家第一手評價與外部平台評價，需要引用時以連回原始出處的方式呈現，讓讀者自己去查證。
6.3 AggregateRating 的則數，可以只算好評嗎
不應該。彙總數字要能由頁面實際展示的評價算出來，刻意只算好評、灌高則數，與頁面不符時就有被判操縱的疑慮。真實分布反而更可信。
6.4 收集評價時可以提供小獎勵嗎
可以鼓勵留評，但不應誘導特定分數或代寫內容。獎勵綁定「給高分」會讓評價失真，也提高合規風險。鼓勵誠實回饋、不干預內容，是較安全的做法。
6.5 標記做對了，多久會出現星星
沒有保證的時程。是否顯示由搜尋引擎依品質與規範判斷，標記正確只是必要條件之一，還需要時間重新抓取與評估，不一定每個頁面都會呈現。與其盯著星星有沒有出現，我更建議把力氣放在持續累積真實評價與維持標記一致，這些基本功做穩，長期的機會才會慢慢站到你這邊。