先給結論：搜尋結果裡那排星星，能不能拿到、會不會連累整站信任，取決於一條底線：結構化資料裡的評價，必須與頁面上使用者看得到的內容完全對得上。Review 與 AggregateRating 這一組標記，是服務業最常被問、也最常踩雷的一塊。把它當成「加段程式碼就有星星」的技巧，通常是麻煩的開始；把它當成「對真有人評過的承諾」來經營，星星才會穩穩留在你這邊。這篇我們只談這一組，把怎麼正確標記、怎麼合規、怎麼蒐集經得起查證的真實評價，以及怎麼避開會被判濫用的地雷，一次講清楚。
1. 星星不是裝飾，是機器對「真有人評過」的承諾
搜尋結果裡的星等評分，佔的版面不大，影響卻很直接。它對讀者是一種背書，對搜尋引擎則是一個要負責任的承諾：這個評分背後，真的有可查證的評價存在。正因為它會直接影響點擊，被濫用的動機很強，規範也相對嚴格。我們診斷過的案例中，最常見的翻車原因不是做錯什麼大事，而是把這組標記想得太簡單。
1.1 Review 與 AggregateRating 分別在講什麼
Review 描述的是單一則評價，涵蓋是誰評的、給幾分、寫了什麼、什麼時候評的。AggregateRating 則是把多則評價彙總成一個總星等與總則數。前者是個體，後者是統計，兩者要對得上：頁面上實際列出的評價，要能支撐你彙總出來的那個數字。我們看過最尷尬的一種情況，是頁面上只擺了三則評價，AggregateRating 卻標了上百則、還打了近乎滿分，這種明顯兜不攏的組合，正是搜尋引擎在找的濫用訊號。
這兩者也不是非得綁在一起用。如果你只有一則很有代表性的客戶見證，可以只標 Review，誠實呈現那一則；如果你的評價是從一套收集系統彙總而來、頁面上也列得出明細，才適合加上 AggregateRating。我們的原則是：有多少真實評價，就標多少，寧可數字樸素，也不要為了湊出總分而虛報。機器對「個體支撐不起統計」這件事特別敏感，與其冒險，不如讓標記忠實反映你手上真正有的東西。
1.2 標記的內容必須是頁面上看得到的評價
我們反覆強調一條底線：結構化資料裡的評價，必須與頁面上使用者看得到的內容一致。若程式碼裡標了一堆好評，頁面上卻找不到，這就是典型的被判濫用情境。標記是把可見內容翻給機器聽，不是憑空生出內容。多數人會忽略，標記的角色是翻譯，不是創作，這個觀念擺正了，後面很多判斷就會自然順下來。
1.3 為什麼服務業特別容易在這裡出事
服務業的評價往往散落在多個管道，有的在通訊軟體裡、有的在口頭回饋、有的寫在結案報告。想把這些湊成一個漂亮的總分並不難，難的是每一則都站得住查證。我們在協助服務型客戶時，第一件事通常不是寫程式碼，而是先問：這些評價現在分別存在哪裡、能不能在頁面上公開列出、當事人是否同意刊登。這三個問題答不清楚，標記就先別急著上。
另一個服務業特有的難處，是評價的對象容易模糊。一家同時提供多項服務的公司，客戶的好評可能是針對其中一項，硬把它彙總成整家公司的總分，在邏輯上就站不住。我們看過一家冷氣安裝品牌，把安裝、保養、維修三條線的評價全部混在首頁算一個總分，結果星星始終出不來。後來把評價拆回各自的服務頁、各算各的總分，呈現才逐漸穩定。評價要標得準，前提是先想清楚它到底在評誰。
2. 怎麼把 Review 與 AggregateRating 標對
正確標記的關鍵，是欄位齊全、彼此對得上、且掛在正確的主體上。評價是針對某個特定對象（某項服務、某個產品）而來，就要標在那個對象身上，不能把整站的評價硬掛在首頁充場面。下面這張表整理了這組標記最容易出錯的欄位，對照著看會比較清楚。
| 欄位 | 屬於 | 常見錯誤 |
|---|---|---|
| author | Review | 留空或填組織自己 |
| reviewRating | Review | 缺最高分基準值 |
| reviewBody | Review | 頁面上找不到對應文字 |
| datePublished | Review | 沒有日期、無法查證 |
| ratingValue | AggregateRating | 與實際評價算不出來 |
| reviewCount | AggregateRating | 灌水、與頁面則數不符 |
2.1 一份對得起來的評價標記
下面是我們常用的骨架，示範網址用 example.com。重點在於 AggregateRating 的 ratingValue 與 reviewCount，要真的能由底下列出的 review 算出來，兩邊不能各報各的。若你頁面上列了八則評價、平均四點六分，那 reviewCount 就寫八、ratingValue 就寫四點六，不要為了好看把數字往上調。
{
"@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 標在對的主體上，並通過驗證
評價要標在被評的那個對象上，主體型別要用得恰當。服務就用 Service、產品就用 Product，別全部塞進 Organization 這種整站層級的型別裡。標記完成後，我們一定用結構化資料測試工具與結構化資料驗證器跑一遍，確認沒有語法錯誤、沒有重複型別衝突，再逐項核對標記內容與頁面可見文字是否一致。這一步跳過，等於把風險留給日後。
這裡有個實務上的判斷：評價標記最好直接放在被評對象的那個頁面，而不是集中到一個獨立的評價總表頁。我們診斷過的案例中，有品牌把所有評價集中到一個「客戶好評」頁，再到每個服務頁掛上彙總星等，結果服務頁上根本找不到對應的評價文字，星星自然下不來。正確做法是讓每個服務頁各自列出屬於自己的那幾則評價，標記就標在那一頁，一頁一對，關係乾淨。
2.3 bestRating 與 worstRating 別省
很多人只填 ratingValue，漏了 bestRating。機器不會自動假設你用的是五分制，標清楚最高分基準，評分才有意義。四點六分在五分制與十分制裡是完全不同的好壞，省略基準值等於讓機器自己猜，猜錯就白費了這組標記。這種小欄位最容易被忽略，卻是驗證時最常跳出的警示。
3. 評價來源決定會不會被判操縱
能不能秀星星，很大程度取決於評價從哪裡來。來源乾淨、由真實客戶產生、能追溯到真實往來，星星才站得住；來源可疑、由自己灌水或誘導產生，遲早會出問題。我們在協助客戶時，第一件事就是釐清評價的產生機制，因為這決定了後面所有標記的底氣。
3.1 只採計來自真實往來的評價
我們的標準是：評價要來自實際完成並驗收的服務或交易。有一個公正的收集與審核機制，禁止內部自行灌水，這個機制本身就是可信度的一部分。當你能說明「這些評價都來自真實完成的案件」，讀者與機器的信任基礎才穩固。我們在協助客戶規劃評價頁時，通常會建議把這套收集機制寫成一小段公開說明，放在評價區塊旁邊，讓讀者知道評價從哪裡來、怎麼被審核，這種透明度本身就是一種信任加分。
3.2 別把別的平台的評分直接搬來標
常見的地雷，是把第三方平台上的星等抓下來，標成自己頁面的評價。這在規範上有明確限制，因為那不是使用者直接在你頁面留下的評價。我們的建議是清楚區分「自家收集的第一手評價」與「外部平台的評價」，不要混為一談去標記。若真的想引用外部平台的口碑，可以在頁面上以引述、連回原始出處的方式呈現，讓讀者自行查證，而不是把它塞進結構化資料當成自家評分去彙總。這一條界線分清楚，能省掉日後很多麻煩。
3.3 誘導高分與代寫，風險遠高於好處
把小獎勵綁定「給五星」，短期看是衝高了平均分，長期卻是把整批評價的可信度一起拉低。機器對評價分布的異常很敏感，一面倒的滿分、集中在某幾天冒出來的評價，都是會被盯上的特徵。我們看過因為一次誘導活動，讓原本乾淨的評價池被污染，事後要花更長時間才把信任修回來。鼓勵留評可以，但不綁定分數、不代寫內容，是比較安全的做法。
4. 怎麼蒐集真實、可驗證的評價
好的評價不是等來的，是設計出來的。我們協助客戶時，會把蒐集流程做成可重複、可留存憑證的機制，讓每一則評價日後被問起時都答得出來源。下面這張表把蒐集評價的幾個環節拆開，每一環都有它要守住的目的。
| 環節 | 做法 | 目的 |
|---|---|---|
| 邀請時機 | 在服務完成、驗收之後 | 確保評價對應真實往來 |
| 邀請對象 | 實際完成交易的客戶 | 避免無效或虛構評價 |
| 內容真實性 | 不代寫、不誘導評分 | 降低被判操縱風險 |
| 資料留存 | 保留同意與往來紀錄 | 被查證時可回溯 |
| 當事人同意 | 刊登前取得書面同意 | 符合個資保護規範 |
4.1 讓評價可回溯，是合規的底氣
我們要求客戶替每一則對外展示的評價，留下可回溯的線索：對應到哪一次服務、當事人是否同意刊登。當評價能被回溯，你面對搜尋引擎的品質審查或使用者質疑時，就有底氣。刊登涉及個人的評價與見證前，取得書面同意是基本動作，這一步在各地的個資保護規範下都越來越被看重，別省。
4.2 不刪負評、不只放五星
清一色滿分、找不到任何一則中性或負面回饋的評價牆，反而顯得可疑。我們通常建議保留真實的不同聲音，讓評價分布看起來像真的。刻意過濾到只剩好評，短期好看，長期會侵蝕讀者對整體評價的信任。更務實的做法，是在中性或負面評價下方誠實回應處理方式，讓讀者看到你面對問題的態度，這種展現比一整排滿分更能建立信任。
4.3 評價的節奏也要看起來自然
真實服務的評價，會隨著接案節奏陸續出現，有疏有密。如果一個新上線的頁面，短短幾天內湧入大量近滿分評價，這種節奏本身就可疑。我們會建議客戶讓評價自然累積，不要為了趕在某個時間點一次倒進來。評價的時間分布、分數分布、文字長短，合起來構成一種真實感，刻意製造反而露出破綻。
4.4 讓評價內容有具體細節，而不只是形容詞
一句「服務很好、很滿意」的評價，對讀者與機器的說服力都有限，因為它可以套用在任何服務上。真正有力量的評價，會帶出具體情境：處理了什麼問題、花了多久、哪個環節讓他印象深刻。我們在設計邀請評價的引導語時，會用開放式的提問引出這些細節，例如請客戶描述當初遇到的狀況、最後怎麼被解決。這樣收到的評價更立體，頁面上讀起來也更像真的，對搜尋引擎評估內容品質同樣是加分。要注意的是引導的是「描述方式」，不是「給幾分」，這條界線不能越。
5. 上線前用一份清單避開會被判濫用的地雷
評價標記翻車，往往不是因為做了什麼壞事，而是不小心踩到規範。我們上線前會照一份清單逐項確認，把可預見的風險先排掉。
5.1 上線前的自查重點
我們核對的項目包括：標記的評價頁面上都看得到、AggregateRating 的數字算得出來、評價來自真實往來、沒有把第三方評分冒充為自家評價、每則評價都有作者與日期、也沒有把整站評價硬掛在無關頁面、bestRating 等基準值都填齊。這幾項守住，被判濫用的機率就大幅下降。這份清單不需要工具，逐行對一遍花不了多少時間。
除了這些硬性項目，我們還會從讀者的角度再看一眼：這一頁的評價區塊，排版上讀起來順不順、點進去能不能看到完整內容、有沒有明顯的刊登日期。結構化資料是給機器看的，但頁面本身要先對真人交代得過去。我們的經驗是，一個對讀者誠實、資訊完整的評價區塊，標記通常也不會出問題；反過來，如果頁面本身藏藏掖掖、只想靠標記衝星星，那多半就是風險的來源。先把給人看的那一面做好，標記只是忠實地把它翻譯出來。
5.2 出問題時，先回到「一致」兩個字
若星星消失或收到品質警訊，我們第一個檢查的永遠是一致性：標記與頁面內容對不對得上、彙總數字與實際評價符不符合。多數評價標記的問題，根源都在標記與事實脫節。修好一致性，通常就修好了大半。這類調整生效需要時間讓機器重新抓取，不會立即反映，別因為隔天沒動靜就反覆改動。
另一類常被忽略的情況，是頁面改版時評價區塊被動到了。我們遇過一個案例，客戶重做了頁面樣式，評價改用前端動態載入，結果機器抓到的頁面裡看不到評價文字，標記瞬間變成「頁面上不存在的評價」，星星也跟著不見。排查這類問題時，我們會用純文字的方式檢視機器實際讀到的頁面內容，確認評價文字真的出現在原始回應裡，而不是只在瀏覽器端才渲染出來。標記與頁面一致這件事，不只是文字對得上，連「機器抓得到」都要算進去。
5.3 別把星星當成唯一目標
我們想提醒的是，星星是結果，不是目標。把力氣全放在「怎麼讓星星出現」，容易走向灌水與誘導的歧路。把評價蒐集做扎實、把標記與頁面維持一致，星星是水到渠成的副產品。就算某段時間星星沒顯示，一套乾淨、可回溯的評價機制，對讀者信任與長期經營都是實打實的資產，不會白做。
值得補充的是，評價資產的價值不只展現在搜尋結果那排星星。當 AI 搜尋或助理在回答「這家服務好不好」時，也會去讀取頁面上的評價內容。一段段具體、可查證、帶著真實情境的評價，比一個孤立的總分更容易被引用，也更能幫你在這類場景裡被提及。換句話說，把評價當成長期資產經營，回報的面向會比單純的星星更寬，這也是我們勸客戶別只盯著星星的另一層原因。
6. 常見問題
6.1 頁面沒有真實評價，可以先標記等之後補嗎
不建議。標記必須對應頁面上真實存在、使用者看得到的評價。先標記後補內容，屬於容易被判濫用的情境，風險遠高於好處。比較穩的順序是先把真實評價收集到頁面上，再做標記。
6.2 可以把外部平台的星等標成自己的評價嗎
要非常謹慎。規範對第三方評價的使用有明確限制，把別處的評分直接標成自家頁面評價，容易被視為不當使用。建議清楚區分自家第一手評價與外部平台評價，需要引用時以連回原始出處的方式呈現，讓讀者自己去查證。
6.3 AggregateRating 的則數，可以只算好評嗎
不應該。彙總數字要能由頁面實際展示的評價算出來，刻意只算好評、灌高則數，與頁面不符時就有被判操縱的疑慮。真實的分數分布反而更可信，也更經得起查證。把中性與負面評價一起納入計算，總分或許不那麼漂亮，但這個數字是真的，日後被檢視時才站得住。
6.4 收集評價時可以提供小獎勵嗎
可以鼓勵留評，但不應誘導特定分數或代寫內容。獎勵綁定「給高分」會讓評價失真，也提高合規風險。鼓勵誠實回饋、不干預內容，是較安全的做法。
6.5 標記做對了，多久會出現星星
沒有保證的時程。是否顯示由搜尋引擎依品質與規範判斷，標記正確只是必要條件之一，還需要時間重新抓取與評估，不一定每個頁面都會呈現。與其盯著星星有沒有出現，我們更建議把力氣放在持續累積真實評價與維持標記一致，這些基本功做穩，長期的機會才會慢慢站到你這邊。
6.6 一則評價裡只有分數、沒有文字，可以標嗎
技術上可以只標 reviewRating 而省略 reviewBody，但我們不建議。沒有文字的評價對讀者幾乎沒有說服力，機器也很難從中判斷真實性，整體可信度偏低。比較好的做法是鼓勵客戶留下具體描述，讓每一則評價都帶著情境與細節，頁面與標記一起呈現，才撐得起那排星星背後的份量。