如果你的 SaaS 產品頁在搜尋結果裡看起來跟一段純文字沒兩樣,而競品卻多出星等、價格與「商業應用程式」的分類標籤,差別通常不在內容,而在有沒有把 SoftwareApplication 這組結構化資料寫對。我是吳承學,做了二十年 SEO,這篇想把這組 schema 該填的欄位、容易踩的雷,以及它跟 Organization 的品牌關聯講清楚,讓你的產品頁在 Google 的複合式搜尋結果裡有機會被完整呈現。

SoftwareApplication 結構化資料的四個核心欄位:applicationCategory、operatingSystem、offers、aggregateRating,並與 Organization 建立品牌關聯
SoftwareApplication 的四個核心欄位

1. 為什麼 SaaS 產品頁沒有星等,而競品有

我在實務上看過不少電子簽章、專案管理這類 SaaS 網站,產品做得很成熟,頁面資訊也齊全,但在 Google 上就是一行藍字加一段灰色描述,毫無記憶點。前陣子我接手分析一款電子簽章 SaaS 的網站,整站掃過一遍後發現一個共通問題:完全沒有實作任何結構化資料。沒有 schema,Google 就只能靠猜的方式理解「這是一個軟體產品、有免費方案、平均評分多少」,自然也無法把這些資訊放進複合式搜尋結果。

1.1 結構化資料在做的是「翻譯」而非「加分」

很多人把 schema 當成排名的加分項,這個認知會害你做錯優先序。schema 的本質是翻譯:把人看得懂的頁面內容,轉成搜尋引擎能明確歸類的欄位。當你用 SoftwareApplication 明確告訴 Google「這是一個軟體、屬於商業應用、支援哪些系統、定價多少、評分多少」,你不是在請求加分,而是在降低機器理解的成本。理解成本低,才有資格進入 rich result 的候選池。

1.2 排名前段的競爭對手通常早就標好了

當你在同一組關鍵字上跟排名前段的競爭對手正面對決,對方的產品頁若已經帶出星等與價格,點閱率的差距會在同一個排名位置上被拉開。使用者的眼睛會先被有星等的結果吸走。這不是排名輸,是版位的視覺競爭輸了,而這一塊剛好是結構化資料能補上的。

2. SoftwareApplication 的四個核心欄位怎麼填才不會被忽略

SoftwareApplication 這個型別看起來欄位很多,但真正決定 Google 願不願意採用的,是四個核心欄位:applicationCategory、operatingSystem、offers、aggregateRating。我的做法是先把這四個填到位,再談其他錦上添花的屬性。

2.1 applicationCategory:別把分類寫成行銷詞

applicationCategory 要用 schema.org 認得的分類值,而不是你自己發明的行銷語言。像電子簽章、CRM、報價工具這類商用軟體,填 BusinessApplication 最穩;如果是設計工具就用 DesignApplication,財務類用 FinanceApplication。我在實務上看過有人把這欄填成「最好用的簽署神器」,Google 直接忽略整段標記,因為它不是有效的列舉值。分類欄位是給機器讀的,不是給人看的文案。

2.2 operatingSystem:誠實列出實際支援的平台

operatingSystem 要對齊你產品真正跑得起來的環境。一款純網頁版加行動 App 的電子簽章 SaaS,合理的寫法會是 Web, iOS, Android, Windows, macOS。這裡有個常被忽略的細節:如果你只是網頁版,卻硬寫上 iOS、Android,使用者點進來發現沒有 App,跳出率一高,長期反而傷害頁面表現。結構化資料要跟頁面事實一致,這是 Google 結構化資料政策的底線,標了與事實不符的內容,輕則被忽略,重則吃到人工處罰。

2.3 offers:免費方案也要標,而且要標對幣別

offers 是決定價格會不會出現在搜尋結果的欄位。免費方案不是「不用標」,而是 price 填 0,並補上 priceCurrency。幣別要跟你實際銷售的市場一致,做台灣市場就用 TWD,做國際就依主要收費幣別填。價格區間若複雜,可以用 AggregateOffer 標出最低與最高價,讓搜尋引擎理解你的訂閱是分級的。

2.4 aggregateRating:評分數據必須是真的,而且頁面看得到

aggregateRating 是最容易被濫用、也最容易被抓的欄位。Google 明確要求評分必須來自頁面上使用者真的看得到的評價,不能憑空捏造。ratingValue 與 ratingCount 要對齊你網站上真實顯示的評分與則數。我在實務上看過有人把評分灌到接近滿分、評論數寫成幾千則,但頁面上一則評論都找不到,這種標記被系統識破只是時間問題,一旦被判定為 spam,失去的是整站的信任分數,得不償失。

2.5 把四個欄位組起來的樣子

把上面四個欄位組起來,一段合格的 SoftwareApplication JSON-LD 會像這樣,實際數值請換成你自己的真實資料:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "你的產品名稱",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web, iOS, Android, Windows, macOS",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "TWD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "ratingCount": "48"
  }
}

3. 用 Organization 把產品跟品牌的關係說清楚

只標 SoftwareApplication 還不夠。Google 要能回答「這個軟體是誰做的、這家公司可信嗎」,才會把你的品牌當成一個實體來理解。這就是 Organization 這組 schema 的價值,它負責建立品牌識別。

3.1 Organization 要補上 sameAs 與 contactPoint

Organization 的重點欄位是 name、url、logo,再加上 sameAs 與 contactPoint。sameAs 是把你的官方社群連結列進來,讓 Google 把散落在各平台的品牌訊號串成同一個實體;contactPoint 則提供客服聯絡方式,這對建立信任很有幫助。一段基本的 Organization 標記如下:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "你的品牌名稱",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.webp",
  "sameAs": [
    "https://www.facebook.com/yourbrand/",
    "https://www.linkedin.com/company/yourbrand/"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "Customer Service",
    "email": "[email protected]"
  }
}

3.2 母公司與子產品的關聯,寫在頁面上比靠外連更穩

如果你的產品是某集團旗下的品牌,建立母子關係最可靠的做法,不是去買一堆外部連結,而是在網站上(通常是 About 頁或 footer)用文字明確寫出「本產品是某某科技旗下的電子簽署服務」。我的做法是讓這句話以純文字出現在使用者看得到的地方,Google 抓取時自然會把兩者的關聯建立起來,不需要仰賴外部連結的間接訊號。這是我在多個品牌整併案例裡驗證過最省力也最穩定的做法。

3.3 兩組 schema 要對得起來

SoftwareApplication 裡的產品名、Organization 裡的品牌名、頁面上實際顯示的文字,三者要一致。我在實務上看過名稱大小寫、有無空格三邊各寫各的,結果 Google 判定成三個不同實體,品牌訊號被稀釋掉。一致性聽起來瑣碎,卻是實體建立能不能成立的關鍵。

4. SoftwareApplication 標對與標錯的差別

下面這張表把常見的錯誤寫法跟建議寫法擺在一起,你可以拿去對照自己網站現在的狀況。

欄位 常見錯誤寫法 建議寫法 可能的後果
applicationCategory 填入行銷標語或自創分類 使用 schema.org 列舉值,如 BusinessApplication 錯誤值會讓整段標記被忽略
operatingSystem 列出實際不支援的平台 只列真正能執行的環境 與事實不符,恐遭忽略或處罰
offers 免費方案索性不標 price 填 0 並補 priceCurrency 價格資訊無法進入搜尋結果
aggregateRating 灌高評分、頁面看不到評論 對齊頁面上真實顯示的評分 被判定 spam,傷害整站信任
Organization 只填 name 與 url 補上 logo、sameAs、contactPoint 品牌實體訊號不足

4.1 標完一定要用測試工具驗證

寫完 JSON-LD 別急著上線就走人。把頁面丟進 Google 的複合式搜尋結果測試工具與 Schema Markup Validator 跑一次,確認沒有錯誤與必填欄位缺漏。我在實務上看過整段 schema 因為一個逗號或引號沒閉合就整組失效,測試工具能在幾秒內幫你抓出來。

4.2 上線後追蹤 Search Console 的增強項目報告

結構化資料的成效不是即時的。上線後我會固定看 Search Console 裡的「增強項目」與「複合式搜尋結果」報告,確認 Google 有沒有成功解析、有沒有出現警告。這個回饋迴圈跑順了,你才知道標記到底有沒有被採用,而不是自我感覺良好。

5. 常見問題

5.1 SoftwareApplication 標了之後,一定會出現星等嗎

不一定。結構化資料只是讓你有資格進入複合式搜尋結果的候選池,是否實際顯示由 Google 決定,會受內容品質、評分真實性與查詢類型影響。標對是必要條件,但不是充分條件,把它當成打底,而不是保證。

5.2 免費的 SaaS 產品需要標 offers 嗎

需要。免費不代表沒有價格資訊,把 price 填成 0 並補上幣別,反而能讓「免費」這個賣點被搜尋引擎明確理解,對點閱率是加分。空著不填等於放棄一塊能被呈現的欄位。

5.3 aggregateRating 的評分可以先填一個好看的數字嗎

不建議。Google 要求評分必須來自頁面上真實可見的使用者評價,填一個與事實不符的數字,一旦被系統或人工審查抓到,會被判定為結構化資料濫用,連帶影響整站的信任評分。真實數據雖然不漂亮,卻是安全的做法。

5.4 SoftwareApplication 跟 Organization 要放在同一頁嗎

SoftwareApplication 放在產品頁,Organization 建議放在首頁或全站共用的區塊。兩者不必擠在同一段,但名稱與品牌資訊要對得起來,讓 Google 能把產品與品牌關聯成同一個實體。

5.5 JSON-LD 跟 Microdata 哪一種比較好

我會優先選 JSON-LD。它把結構化資料集中成獨立的一段腳本,跟 HTML 版面解耦,維護與除錯都容易得多,也是 Google 官方推薦的格式。Microdata 要跟標籤穿插在一起,改版時很容易被不小心破壞。

5.6 標記多久會被 Google 採用

沒有固定天數。Google 需要重新爬取並解析頁面才會反映,通常從數天到數週不等,頁面權重高、更新頻繁的網站會快一些。與其盯著日期焦慮,不如把 Search Console 的增強項目報告當成觀測點,看到成功解析的筆數上升就代表走在對的方向。

延伸閱讀