我是吳承學，做 SEO 到現在超過二十年，這幾年多半在處理 AI 推薦搜尋跟 SaaS 產品網站的能見度。SaaS 官網跟一般內容網站不一樣，它同時要服務三種讀者：正在比價的採購者、Google 的爬蟲，以及愈來愈會直接回答問題的 AI 搜尋。這篇我想把一個 SaaS 產品網站在技術結構上該收斂的地方講清楚，順序是先讓搜尋引擎看懂你是誰，再讓它抓對頁面，最後才是內容加厚。我在實務上看過太多團隊一開始就衝內容，結果底層結構歪的，寫再多文章都撐不起排名。

1. 你的 SaaS 官網搜尋表現卡住，通常卡在這三個地方

先說清楚問題長什麼樣子，這樣後面的修正才有對照。我接手一款電子簽章 SaaS 的網站時，第一輪盤點就發現流量停滯不是內容不夠，而是結構把自己絆住了。

1.1 產品頁跟部落格在搶同一個關鍵字

SaaS 網站常有一個產品功能頁，加上好幾篇談同一主題的教學文。當「電子簽名 API」這種詞同時被功能頁跟兩三篇部落格文命中，Google 會在這幾個網址之間反覆切換，無法穩定判斷哪一頁是代表頁。我實際觀察過某個關鍵字近 28 天的代表網址切換率一度逼近一半，主網址集中度掉到七成出頭，這種時候排名一定不穩。這不是內容不好，是同一批內容彼此稀釋。

1.2 多語系版本被 Google 當成重複內容

國際型 SaaS 幾乎都有多語系，但很多網站的所有語言版本，canonical 標籤全部指回英文首頁。這種寫法等於告訴 Google：這些頁面都是英文版的複本，把權重集中到英文去。結果就是繁中、日文、德文市場的自然搜尋一起受害，非英語市場排名被壓得很低。

1.3 網站很大，但真正該被索引的頁面沒有收斂

SaaS 產品後台頁面很多，登入頁、設定頁、整合流程頁、簽署流程頁全部塞進 sitemap，這些頁面對搜尋使用者沒有意義，卻在稀釋整個網站的抓取訊號。頁面總量不到一萬頁時影響有限，但它會讓 Google 對「這個網站的重點在哪」判斷得更慢。

2. 先把兩組 Schema 補上，讓搜尋引擎看懂你是誰

結構化資料是 SaaS 網站投報率最高的技術項目之一，因為它直接影響你能不能出現在複合式搜尋結果，也影響 AI 引用你的機率。我的做法是先補兩組最核心的 Schema，其餘再視頁面類型追加。

2.1 Organization：建立品牌與母公司的關聯

Organization Schema 是品牌識別的基礎，欄位包含 name、url、logo、sameAs（社群連結）與 contactPoint。這裡有個容易被忽略的重點：如果你的產品隸屬於某個母公司集團，除了在 Schema 裡標清楚，更要在網站的關於頁或頁尾用文字明確寫出兩者的隸屬關係。這樣 Google 抓取時會自然建立品牌與母公司的關聯，不需要靠外部連結去補這層關係。我在實務上看過品牌歸屬混亂的網站，光是把這層關係寫清楚，品牌詞的呈現就穩定不少。

2.2 SoftwareApplication：把產品規格結構化

SaaS 產品該用 SoftwareApplication 標記，這是它跟一般企業網站最大的差別。關鍵欄位有 applicationCategory（例如 BusinessApplication）、operatingSystem（列出支援的平台，例如 Web、iOS、Android、Windows、macOS）、offers（價格與幣別），以及 aggregateRating（評分與評分數）。填對之後，產品在搜尋結果裡可以帶出評分星等與價格資訊，點閱率通常會比純文字結果好。評分欄位務必對齊你真實的評價資料，不要虛報。

2.3 Schema 最常見的填法錯誤

下面這張表是我審過的網站裡，最常見的兩組 Schema 錯誤與正確寫法對照。

項目	常見錯誤寫法	建議正確寫法
Organization 的 sameAs	留空，或只放首頁	放品牌實際經營的社群頁，讓 Google 交叉驗證
母公司關聯	只寫在 Schema，頁面沒有文字說明	Schema 加頁面文字雙軌，關於頁或頁尾明確敘述
SoftwareApplication 評分	寫死一個漂亮數字	對齊真實評價來源，數字可被驗證
operatingSystem	只寫 Web	列出全部支援平台，涵蓋行動與桌面

3. 多語系網站的 canonical 與 hreflang 要一起做

這是國際 SaaS 最容易做半套的地方。canonical 跟 hreflang 是配套，只修一個，效果都很有限。

3.1 canonical 指向自己，不是指向英文首頁

多語系網站的正確做法，是每個語言版本的 canonical 都指向該頁自己。繁中頁的 canonical 指向繁中頁的網址，日文頁指向日文頁，不要全部指回英文首頁。這是修正的第一步，把「這頁是複本」的錯誤訊號先拿掉。

3.2 hreflang 要放在 head，不是只靠 html lang

很多人以為在 html 標籤加上 lang 屬性就算做了多語系。這對瀏覽器有幫助，但對 Google 的多語系判斷來說，這個屬性的權重很低。真正有效的是在每個頁面的 head 裡放 hreflang，把各語言版本的對應關係一組一組列出來，包含 x-default 指向預設語言。有些網站只把 hreflang 放在 sitemap，我建議 head 裡也要做，讓每個連結都明確對應到其他語言版本。

3.3 一張表看懂正確與錯誤的組合

做法組合	Google 如何解讀	結果
canonical 指英文首頁 + 無 hreflang	所有語言版本都是英文複本	非英語市場排名被壓低
canonical 指自己 + 無 hreflang	各頁獨立，但不知道彼此關係	可能出現錯誤語系給錯誤地區
只有 html lang，沒有 head hreflang	權重低，判斷不穩	多語系效益大幅折損
canonical 指自己 + head hreflang 完整	清楚知道各語言版本對應	各市場呈現對的語系內容

4. 讓 sitemap 收斂到你真的想被搜尋到的頁面

sitemap 不是把所有網址塞進去就好，它是你對 Google 表態「這些是我要被搜尋到的頁面」。SaaS 網站尤其要收斂。

4.1 哪些頁面該從 sitemap 移除

我的做法是把幾類頁面前綴整批清出去：管理後台頁（帳號設定、權限、報表、匯出）、建立任務與簽署流程頁、整合介面的內嵌頁、使用者個人設定頁、範本編輯頁。這些頁面要嘛需要登入、要嘛會轉址、要嘛是功能操作介面，對搜尋使用者沒有著陸價值。Google 去抓這些網址時常常撞到轉址或無效頁，白白消耗抓取資源。

4.2 crawl budget 什麼時候才需要在意

要誠實講，網站頁面沒有超過一萬頁時，抓取預算被浪費的實際影響通常不大，不必過度焦慮。但我仍然建議修，原因是收斂 sitemap 會讓網站的重點更清楚，也讓你在 Search Console 裡讀索引狀態時，訊號比較乾淨、比較好判讀。這是為了長期可維護性，不是為了搶那一點抓取額度。

5. 把 AI 搜尋準備度加進你的產品頁

結構修乾淨之後，才輪到內容。現在的搜尋不只給藍色連結，AI 會直接摘要並引用來源，所以產品頁的內容要寫成「容易被引用」的樣子。

5.1 可引用統計、比較表、How-to 這三種內容最容易被引用

我在強化一款電子簽章 SaaS 的首頁時，補的就是這三塊。第一是可引用的統計數據區，用條列寫出產品的量化事實，例如累積處理的文件量級、比傳統流程快多少、符合哪些國際資安標準、支援幾種語言，數字務必對齊真實資料。第二是比較表格，把傳統做法跟數位做法在處理時間、成本、安全性、法律效力、環保上並排。第三是 How-to 步驟，把「如何用這個工具完成一件事」拆成明確的動作步驟。AI 在生成回答時，特別偏好抓取這三種結構清楚的內容。

5.2 產品導向內容跟教學文要分工，不要互搶

回到第一節講的關鍵字蠶食。產品頁跟教學文如果都想吃同一個詞，就會互相稀釋。我的分工原則是：產品頁主打「這個工具能做什麼、規格與方案」，教學文主打「怎麼做、法律效力、跟其他方式的差異」。同一個主題，用不同切角寫，並在站內把錨文字統一指向你設定的代表頁，Google 才不會在幾個網址之間猶豫。這條原則我會在專門談意圖轉移的文章裡再展開。

6. 常見問題

6.1 SaaS 網站一定要同時做 Organization 跟 SoftwareApplication 兩種 Schema 嗎

建議兩種都做。Organization 負責告訴搜尋引擎品牌是誰、隸屬哪個集團；SoftwareApplication 負責把產品規格、支援平台、方案價格與評分結構化。前者建立信任與品牌識別，後者爭取複合式搜尋結果的呈現，兩者服務的目的不同。

6.2 我只改 canonical 不做 hreflang，會有效果嗎

效果會很有限。canonical 指向自己只解決了「不被當成複本」這一半，但 Google 還是不知道各語言版本之間的對應關係，可能把日文頁推給台灣使用者。canonical 與 hreflang 是配套，要一起做才完整。

6.3 把後台頁面留在 sitemap 裡，真的會傷排名嗎

直接扣分的機率不高，尤其頁面總數不多的網站。真正的問題是它讓網站的重點訊號變雜，也讓你自己在讀索引報告時更難判讀。把它清掉是為了結構乾淨與長期好維護，屬於該做但不必恐慌的項目。

6.4 產品頁補上比較表跟統計數據，對 AI 搜尋有幫助嗎

有幫助。AI 在生成回答時傾向引用結構清楚、可直接摘錄的段落，而條列統計、比較表格與步驟教學正好符合這種形態。前提是數據要真實、可對照，虛報的數字反而會傷信任。

6.5 SoftwareApplication 的評分欄位，可以自己填一個數字嗎

不建議自訂一個好看的數字。評分應該對齊你實際的評價來源，讓它可被驗證。填了不實的評分，除了違反結構化資料的規範，也可能失去豐富摘要的資格，得不償失。

6.6 這些技術修正該照什麼順序做

我的建議順序是：先補 Schema 讓搜尋引擎看懂你是誰，接著修 canonical 與 hreflang 讓多語系判斷正確，再收斂 sitemap 讓抓取訊號乾淨，最後才做產品頁的內容加厚。底層結構先穩，內容投入才不會浪費。