同一個排名位置上，一筆帶著星等、價格、「商業應用程式」分類標籤的結果，和一筆只有藍字加灰色描述的結果，使用者的眼睛會先被哪一個吸走，幾乎不用猜。多數 SaaS 產品頁在搜尋結果裡看起來和一段純文字沒兩樣，而競品多出的那些視覺元素，差別通常不在內容，而在有沒有把 SoftwareApplication 這組結構化資料寫對。這篇我們把這組 schema 該填的欄位、容易踩的雷，以及它跟 Organization 的品牌關聯講清楚，讓你的產品頁有機會在複合式搜尋結果裡被完整呈現。

1. 為什麼你的 SaaS 產品頁沒有星等，而競品有

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

1.1 結構化資料在做的是翻譯，而不是加分

很多人把 schema 當成排名的加分項，這個認知會害你做錯優先序。schema 的本質是翻譯：把人看得懂的頁面內容，轉成搜尋引擎能明確歸類的欄位。當你用 SoftwareApplication 明確告訴搜尋引擎「這是一個軟體、屬於商業應用、支援哪些系統、定價多少、評分多少」，你不是在請求加分，而是在降低機器理解的成本。理解成本低，才有資格進入複合式搜尋結果的候選池。我們會強調這個區別，是因為把它當加分項的人，容易在內容還沒做好時就急著堆 schema，順序剛好顛倒。

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

當你在同一組關鍵字上跟排名前段的競爭對手正面對決，對方的產品頁若已經帶出星等與價格，點閱率的差距會在同一個排名位置上被拉開。使用者的視線會先被有星等的結果吸走，這一塊剛好是結構化資料能補上的。這不是說標了 schema 排名就會贏，而是在排名相近時，版位的視覺豐富度會影響使用者的選擇。我們的經驗是，產品類關鍵字的競爭，往往不只比內容，也比誰的搜尋結果版位更容易被點進去。

1.3 不是每個頁面都該標 SoftwareApplication

這組 schema 適合的是真正介紹一個軟體產品的頁面，通常是產品首頁或方案總覽頁。我們看過有人把它套到部落格文章、功能說明的子頁、甚至公司介紹頁上，結果搜尋引擎收到的訊號是混亂的：一篇談使用技巧的文章被標成軟體產品，型別與內容對不上，反而稀釋了真正該被認定為產品頁的那一頁。我們的判斷標準很簡單：這一頁是不是使用者會用來決定「要不要用這個軟體」的主力頁。是，才標 SoftwareApplication；不是，就用對應該頁實際性質的型別，或乾脆不標。型別選錯，比不標還糟，因為它把搜尋引擎往錯的方向帶。

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

SoftwareApplication 這個型別看起來欄位很多，但真正決定搜尋引擎願不願意採用的，是四個核心欄位：applicationCategory、operatingSystem、offers、aggregateRating。我們的做法是先把這四個填到位，再談其他錦上添花的屬性。把核心填對，比塞一堆少見屬性更有效。

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

applicationCategory 要用 schema.org 認得的分類值，而不是你自己發明的行銷語言。像電子簽章、CRM、報價工具這類商用軟體，填 BusinessApplication 最穩；如果是設計工具就用 DesignApplication，財務類用 FinanceApplication。我們在實務上看過有人把這欄填成「最好用的簽署神器」，搜尋引擎直接忽略整段標記，因為它不是有效的列舉值。分類欄位是給機器讀的，不是給人看的文案，這個定位搞錯，整組標記的效力就打折。如果你不確定自己的產品該歸到哪個分類，可以到 schema.org 的 SoftwareApplication 頁面查它列出的子型別與建議值，挑一個最貼近你產品性質的。寧可用一個稍微籠統但正確的列舉值，也不要用一個精準但自創的詞，因為機器只認得前者。

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

operatingSystem 要對齊你產品真正跑得起來的環境。一款純網頁版加上行動 App 的電子簽章 SaaS，合理的寫法會是 Web, iOS, Android, Windows, macOS。這裡有個常被忽略的細節：如果你只是網頁版，卻硬寫上 iOS、Android，使用者點進來發現沒有 App，跳出率一高，長期反而傷害頁面表現。結構化資料要跟頁面事實一致，這是搜尋引擎結構化資料政策的底線，標了與事實不符的內容，輕則被忽略，重則影響整站的信任評分，不值得冒這個險。多平台的寫法是用逗號分隔成一個字串，而不是各自拆成陣列，這一點在實作時很容易搞混。如果你的產品確實只在網頁上運作，大方寫 Web 就好，網頁版本身就是完整的產品型態，不必為了看起來支援更廣而硬加平台。

2.3 offers：免費方案也要標，而且要標對幣別

offers 是決定價格會不會出現在搜尋結果的欄位。免費方案不是「不用標」，而是 price 填 0，並補上 priceCurrency。幣別要跟你實際銷售的市場一致，做台灣市場就用 TWD，做國際就依主要收費幣別填。價格區間若複雜，可以用 AggregateOffer 標出最低與最高價，讓搜尋引擎理解你的訂閱是分級的。把免費這個賣點明確標出來，對點閱率通常是加分，空著不填等於放棄一塊能被呈現的欄位。

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

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

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"
  }
}

2.6 核心填好之後，值得再補的幾個屬性

四個核心欄位到位後，如果還想讓搜尋引擎更理解你的產品，有幾個屬性值得補。screenshot 放一張產品介面截圖的網址，讓機器知道這確實是個有實際畫面的軟體；softwareVersion 標出目前版本，對更新頻繁的 SaaS 有幫助；featureList 用簡短文字列出主要功能。這些屬性不是必填，我們的順序一向是先把核心四欄做對、通過測試工具，再視情況補這些。把少見屬性堆在前面、核心卻填錯，是本末倒置的做法。補屬性的原則也一樣：每一項都要對應頁面上真實存在的內容，截圖網址要能打開、版本號要是真的，不能為了欄位好看而填假的。

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

只標 SoftwareApplication 還不夠。搜尋引擎要能回答「這個軟體是誰做的、這家公司可信嗎」，才會把你的品牌當成一個實體來理解。這就是 Organization 這組 schema 的價值，它負責建立品牌識別。產品的結構化資料與品牌的結構化資料各司其職，合起來才構成完整的信任訊號。

3.1 Organization 要補上 sameAs 與 contactPoint

Organization 的重點欄位是 name、url、logo，再加上 sameAs 與 contactPoint。sameAs 是把你的官方社群連結列進來，讓搜尋引擎把散落在各平台的品牌訊號串成同一個實體；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）用文字明確寫出「本產品是某某科技旗下的電子簽署服務」。我們的做法是讓這句話以純文字出現在使用者看得到的地方，搜尋引擎抓取時自然會把兩者的關聯建立起來，不需要仰賴外部連結的間接訊號。這是我們在多個品牌整併案例裡驗證過最省力、也最穩定的做法。

3.3 兩組 schema 要對得起來

SoftwareApplication 裡的產品名、Organization 裡的品牌名、頁面上實際顯示的文字，三者要一致。我們在實務上看過名稱大小寫、有無空格三邊各寫各的，結果搜尋引擎判定成三個不同實體，品牌訊號被稀釋掉。一致性聽起來瑣碎，卻是實體建立能不能成立的關鍵。標記前先把這三處的寫法核對成完全相同的字串，能省掉很多後續的麻煩。

3.4 同一頁不要重複標記同一組資訊

我們診斷過的案例中，有網站因為換過幾次佈景主題或外掛，結果同一頁被埋了兩三組 SoftwareApplication，評分、價格還各寫各的。搜尋引擎讀到互相打架的標記時，可能整組都不採用，也可能採到舊的那一組。清理的做法是先用測試工具列出這一頁所有被偵測到的結構化資料，確認只留一組、且數值正確。尤其在用佈景主題或 SEO 外掛自動產生 schema 的網站上，很容易出現你手寫一組、外掛又自動產一組的重複，上線前務必檢查這一頁到底輸出了幾組標記。

4. SoftwareApplication 標對與標錯的差別

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

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

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

寫完 JSON-LD 別急著上線就走人。把頁面丟進搜尋引擎的複合式搜尋結果測試工具與 Schema Markup Validator 跑一次，確認沒有錯誤與必填欄位缺漏。我們在實務上看過整段 schema 因為一個逗號或引號沒閉合就整組失效，測試工具能在幾秒內幫你抓出來。這一步的成本很低，省下的卻是上線後才發現標記完全沒生效的時間。測試工具除了抓語法錯誤，也會提示哪些是必填欄位、哪些是建議欄位，讓你知道還有沒有補強空間。我們會特別留意它列出的警告而不只是錯誤，因為警告通常代表「標記能被解析，但某些欄位缺了會影響呈現機會」，這些剛好是拉開與競品差距的地方。

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

結構化資料的成效不是即時的。上線後我們會固定看 Search Console 裡的「增強項目」與「複合式搜尋結果」報告，確認搜尋引擎有沒有成功解析、有沒有出現警告。這個回饋迴圈跑順了，你才知道標記到底有沒有被採用，而不是只憑自我感覺良好。根據我們的服務經驗，看著成功解析的筆數穩定上升，比盯著單日排名更能判斷結構化資料走在對的方向。這份報告也會在標記出狀況時主動示警，例如某次改版不小心動到了評分欄位、或必填欄位被漏掉，它都會標記出來。我們會把它當成定期健檢的項目，而不是上線當天看一次就不再理會，因為網站一直在改，今天對的標記明天可能因為一次改版就壞了。

5. 常見問題

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

不一定。結構化資料只是讓你有資格進入複合式搜尋結果的候選池，是否實際顯示由搜尋引擎決定，會受內容品質、評分真實性與查詢類型影響。標對是必要條件，但不是充分條件。把它當成打底的基本功，而不是保證會出現星等的開關，心態會比較健康，也比較不會因為沒立刻看到星等就亂改。我們的經驗是，同一組標記在不同查詢下呈現方式可能不同，搜尋引擎會依當下的查詢意圖決定要不要帶出豐富元素，這不是你能直接控制的，能做的是把該標的都標對、讓自己一直留在候選池裡。

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

需要。免費不代表沒有價格資訊，把 price 填成 0 並補上幣別，反而能讓「免費」這個賣點被搜尋引擎明確理解，對點閱率是加分。空著不填等於放棄一塊能被呈現的欄位。如果你同時有免費與付費方案，也可以用 AggregateOffer 標出價格區間，讓使用者在搜尋結果就知道你是分級訂閱。

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

不建議。搜尋引擎要求評分必須來自頁面上真實可見的使用者評價，填一個與事實不符的數字，一旦被系統或人工審查抓到，會被判定為結構化資料濫用，連帶影響整站的信任評分。真實數據雖然不漂亮，卻是安全的做法。如果現階段評論數還少，誠實標出少量的真實評分，遠比捏造大量評論來得穩當。更務實的做法是先把收集真實評價的機制建好，讓使用者能在產品頁留下評分，等累積到一定數量，aggregateRating 自然就有真實數據可標。與其冒著被判濫用的風險去填假數字，不如把評分當成一個需要時間經營的資產，這也是我們在多數案例裡採取的順序。

5.4 SoftwareApplication 跟 Organization 要放在同一頁嗎

SoftwareApplication 放在產品頁，Organization 建議放在首頁或全站共用的區塊。兩者不必擠在同一段，但名稱與品牌資訊要對得起來，讓搜尋引擎能把產品與品牌關聯成同一個實體。關鍵不是放在哪裡，而是各處寫法一致、彼此能對上。如果你的 Organization 已經在首頁標過一次，產品頁就不需要再重複一整組，只要確保產品頁的 SoftwareApplication 裡品牌名稱與首頁 Organization 的名稱寫法相同，搜尋引擎就能把兩者關聯起來。重複標記同一組品牌資訊，反而可能製造前面提過的衝突。簡單的原則是：品牌層級的資訊標一次、放在全站共用的位置，產品層級的資訊放在各自的產品頁，兩層靠名稱對齊，而不是到處複製。

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

我們會優先選 JSON-LD。它把結構化資料集中成獨立的一段腳本，跟 HTML 版面解耦，維護與除錯都容易得多，也是搜尋引擎官方推薦的格式。Microdata 要跟標籤穿插在一起，改版時很容易被不小心破壞。除非你有特殊的既有架構限制，否則新做的標記我們都會走 JSON-LD。它通常放在頁面的 <head> 或 <body> 裡一段獨立的 <script type="application/ld+json">，換佈景主題或調版面時，只要這段腳本還在、內容沒被動到，標記就不受影響，這也是它好維護的原因。

5.6 標記多久會被搜尋引擎採用

沒有固定天數。搜尋引擎需要重新爬取並解析頁面才會反映，通常從數天到數週不等，頁面權重高、更新頻繁的網站會快一些。這段等待期間你能做的，是確保頁面持續被正常抓取、內容沒有重大變動，讓搜尋引擎有穩定的版本可以解析。與其盯著日期焦慮，不如把 Search Console 的增強項目報告當成觀測點，看到成功解析的筆數上升，就代表走在對的方向。如果過了數週仍未被解析，再回頭用測試工具檢查標記本身有沒有語法錯誤。

5.7 用 JavaScript 動態產生的 schema 會被讀到嗎

可能會，但有風險。搜尋引擎雖然會渲染 JavaScript，但渲染是分階段、需要額外資源的，若你的 schema 是靠前端腳本在使用者端才注入，搜尋引擎不一定每次都能及時抓到。我們的建議是盡量讓結構化資料在伺服器端就輸出在原始 HTML 裡，這樣爬蟲第一次抓頁面就能直接讀到，不必等渲染。驗證方式是用測試工具看「已轉譯的 HTML」裡有沒有你的那段 JSON-LD，如果原始碼裡看不到、只有渲染後才出現，就代表你依賴了渲染這一層，穩定性會打折。對重要的產品頁，我們傾向把這個變數拿掉，直接在原始碼就把標記寫死。