我是吳承學,做 SEO 超過二十年。這些年我發現一件很反直覺的事:大多數 SaaS 團隊願意花大把時間經營部落格,卻放著定價頁和功能頁自生自滅。這兩類頁面才是離「付費」最近的搜尋入口,也是我每次接手新網站第一個打開 Search Console 去看的地方。這篇我不談全站的結構化資料鋪設,也不談 sitemap 該怎麼配,那些是另一個層次的事,我只聚焦在:當高價值的定價頁與功能頁開始漏流量時,你該怎麼救回來。
1. 為什麼定價頁與功能頁的流量,比你以為的更容易漏掉
先講一個判斷標準。在我心裡,一個 SaaS 網站的頁面價值排序,不是首頁最高,而是「離收費決策越近的頁面越高」。定價頁和功能頁剛好都卡在這條線上,使用者看完通常就是註冊或關掉分頁,中間沒有太多緩衝。這種頁面一旦流量流失,對營收的傷害是直接的,不像部落格掉一點還有整體基數撐著。
1.1 定價頁不是轉換頁,它同時是一個搜尋入口
很多人把定價頁當成「使用者從站內點進去的最後一站」,所以只在意版面和方案排列,忽略它其實會直接吃搜尋流量。使用者在 Google 打「某某工具 價格」「某某方案 費用」的時候,想看的就是這一頁。如果你的定價頁在標題和內文裡完全沒有出現這些比價意圖的字,搜尋引擎自然不會把它排到前面,你等於把一批已經準備掏錢的人推給了排名前段的競爭對手。
我手上一款電子簽章 SaaS 的定價頁,曾經在兩個月內從月點擊四十幾掉到三十上下,那是一頁「每個點擊都可能變成訂單」的頁面。我當時第一反應不是改版面,而是比對這頁的實際查詢字詞跟內容有沒有對上,結果發現內文幾乎只在講功能好處,沒有一句回應「多少錢」「有沒有免費」這種最直白的疑問。
1.2 功能頁常被當成產品說明,而不是關鍵字著陸頁
功能頁的問題更隱蔽。多數 SaaS 的功能頁是產品團隊寫的,語氣像規格書,講的是「我們有這個能力」,而不是使用者實際會搜尋的問題。搜尋引擎看的是這頁到底在回答哪個具體需求,一個講「數位憑證」的功能頁,如果沒把使用者可能搜尋的相關問法寫進去,在搜尋引擎眼中就是一頁語意模糊、主題不明確的內容。
1.3 我在一款電子簽章 SaaS 上看到的漏水點
分享一個真實情況。我接手那個網站後做的第一件事,是把所有 features 底下的頁面拉出來對照 Search Console 的索引狀態,結果發現一個上線很久、對外一直有在推的功能頁,在索引報告裡竟然是空的,等於 Google 從來沒把它當成有效頁面收錄過。這種頁面在後台看起來一切正常,你不主動去查,永遠不會知道它對搜尋引擎其實「不存在」。這讓我養成一個習慣:高價值頁面不能只看前台顯示正常,一定要回到索引報告確認它真的被收進去。
2. 定價頁要留住流量,先把這三件事解決
定價頁的優化不需要長篇大論,反而要精準。我通常從意圖、標記、連結三個角度切入。
2.1 定價頁的關鍵字意圖:比價、方案、免費
搜尋定價相關字的人,心裡通常有三種問題:這東西多少錢、有哪些方案差在哪、有沒有免費或試用。你的定價頁至少要用文字明確回應這三種。我不是要你堆關鍵字,而是把使用者真正會問的話,用自然的句子寫進頁面。方案比較的區塊除了價格數字,旁邊搭一段說明「哪種規模的團隊適合哪個方案」,這段文字就同時服務了使用者和搜尋引擎。我另外會建議在定價頁加一小塊常見問題,回答「可以隨時取消嗎」「超過額度會怎麼算」「年繳跟月繳差多少」這類問題,這些問法本身就是搜尋流量的來源,寫在定價頁上比另外開一篇文章更符合使用者當下的意圖。
2.2 用 Offer 標記把方案結構講清楚
定價頁最適合的結構化資料是 Offer,它讓搜尋引擎理解你的方案有哪些、價格區間在哪。這跟全站層級的組織標記是兩回事,它是專門描述「這一頁在賣什麼、什麼價格」的頁面級資訊。一個基本的寫法像這樣:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "電子簽章企業方案",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}如果你有多個方案,可以用 AggregateOffer 標出價格的最低與最高區間。我要提醒的是,標記裡的價格一定要跟頁面上實際顯示的一致,不要為了好看填假數字,這種不一致 Google 抓得到,而且會被視為不可信的訊號。
2.3 內部連結:別讓定價頁變成死路
定價頁常常是「大家都連進去,但它不連出來」的死路,從權重流動的角度看有點浪費。我的做法是在定價頁下方,適度連向對應的功能頁和幾篇能解釋方案差異的文章,讓看完價格還在猶豫的人有地方深入了解,也讓搜尋引擎順著連結理解網站結構。重點是適度,挑真正有助於決策的頁面連過去,不是塞滿一堆連結。
3. 功能頁怎麼寫,才會被搜尋引擎當成一個獨立主題
功能頁的核心觀念只有一句:一個功能就是一個獨立主題,不要跟別的功能混在一起。我看過太多網站把十幾個功能塞在一頁,結果每個功能的關鍵字都排不上去,因為那一頁的主題太散,搜尋引擎不知道該把它歸到哪個查詢下。
3.1 一個功能一頁,而不是把功能塞進總覽
我建議每個有明確搜尋需求的功能都獨立成一頁。像數位憑證、行動裝置身分驗證這種本身就有人在搜尋的主題,值得各自擁有一頁,而不是被塞進「所有功能」的清單裡。獨立成頁的好處是主題乾淨,你可以把這個功能相關的所有問法、使用情境、法規背景都寫進去,讓這頁在該主題上有足夠深度。
我實際處理過一個狀況:某個功能頁缺了 H1,整頁沒有一個明確主標題告訴搜尋引擎這頁在講什麼,補上精準的 H1 之後,那頁在相關查詢的能見度就明顯改善。這種基礎到不能再基礎的東西偏偏最常被忽略,因為大家都假設模板一定處理好了。
3.2 數位憑證、身分驗證這類功能頁的關鍵字切法
技術性功能頁的關鍵字有個特性:它同時混了「這是什麼」的認知型查詢,跟「怎麼用、支不支援」的評估型查詢。以數位憑證這類主題來說,搜尋的人可能想知道定義,也可能想確認你的產品支不支援某種驗證方式,好的功能頁會兩種都照顧:前段解釋概念建立信任,後段講清楚產品在這功能上實際能做到什麼、符合哪些規範。我通常會把資安相關的信任訊號寫進這類頁面,例如符合哪些國際資安標準、採用哪種等級的加密,這些對搜尋這類主題的人來說是實際的決策依據,同時回應了使用者疑慮和搜尋引擎對頁面深度的期待。
3.3 SoftwareApplication 標記怎麼配功能頁
功能頁跟定價頁可以搭配 SoftwareApplication 這個標記,它描述你的軟體屬於哪個類別、跑在哪些平台、大概的評價與價格。這是頁面級的產品描述,跟全站的品牌識別標記不衝突,兩者是不同層級。一個基本結構像這樣:
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "電子簽章 SaaS",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web, iOS, Android",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}我要特別提醒的是,不要為了拿評分星等就亂填 aggregateRating。評價數字必須來自真實可驗證的來源,而且頁面上要看得到對應的評價內容,否則這是拿石頭砸自己腳,被判定造假的代價遠比多一顆星要大。
4. 高價值頁流量流失,照這個順序排查
當定價頁或功能頁的流量開始掉,我不會急著改內容,而是照一套固定順序往下查,先確認是不是連被收錄都沒有,再看意圖有沒有對上,最後才處理內部連結。下面兩張表是我實務上會用的對照工具。
| 面向 | 定價頁 | 功能頁 |
|---|---|---|
| 主要搜尋意圖 | 比價、方案差異、有無免費 | 這功能是什麼、產品支不支援 |
| 內容重點 | 方案說明、適用規模、費用常見問題 | 概念解釋、使用情境、規範與資安 |
| 適合的結構化資料 | Offer、AggregateOffer | SoftwareApplication |
| 內部連結方向 | 連向對應功能頁與說明文章 | 連回定價頁與相關功能頁 |
| 最常見的失分點 | 內文沒回應價格意圖 | 缺 H1、主題太散、沒被索引 |
4.1 先確認有沒有被索引
這是我永遠的第一步。用 Search Console 的網址檢查工具直接查這頁有沒有被收錄,連索引都沒有的話,內容寫得再好也沒用,因為搜尋引擎根本沒把它放進資料庫。前面提過那個上線很久卻從未被索引的功能頁,就是這步抓出來的。沒被索引的原因很多,可能是 sitemap 對應亂掉,也可能被錯誤設定擋住,先確認狀態再往下追。
4.2 檢查 H1 與標題描述是否對得上意圖
確認被索引後,第二步看這頁的 H1、標題與描述,是不是準確反映了使用者的搜尋意圖。我遇過標題寫得很漂亮很有品牌感,但完全沒有出現使用者會搜尋的字。這種情況下,把標題調整成更貼近實際查詢的寫法,通常就能看到排名回升。這裡的原則是,標題要先回答「這頁能幫我解決什麼」,品牌感放後面。
4.3 用內部連結把權重導回主力頁
如果同一個主題散落在好幾頁,搜尋引擎不知道哪頁才是代表頁,權重被分散,每頁都排不好。這時我會挑一頁當主力,把站內所有提到這主題的內部連結錨文字統一指向那頁,減少混淆。這招在處理定價頁和功能頁的主題重疊時特別有效。
| 排查步驟 | 要確認什麼 | 常見問題 | 處理方向 |
|---|---|---|---|
| 一、索引狀態 | 頁面有沒有被收錄 | 上線很久卻從未被索引 | 查 sitemap 對應、送出索引 |
| 二、標題意圖 | H1 與描述有沒有對上查詢 | 缺 H1、標題太品牌化 | 補 H1、改寫貼近實際問法 |
| 三、內容深度 | 有沒有回應使用者疑問 | 只講好處不回答問題 | 加常見問題、使用情境 |
| 四、內部連結 | 主題是否有代表頁 | 同主題散落多頁互相競爭 | 選主力頁、統一錨文字 |
| 五、結構化資料 | 有沒有頁面級標記 | 缺 Offer 或軟體標記 | 依頁型補上對應標記 |
5. 常見問題
5.1 定價頁要不要放很多關鍵字才排得上去?
不需要,而且堆關鍵字反而有害。定價頁該做的是用自然的句子回應使用者真正會問的問題,像是方案差在哪、有沒有免費、超額怎麼算。這些問法本身就帶著搜尋流量,你把答案好好寫進頁面,比重複塞同一個詞有用得多。搜尋引擎現在看的是內容有沒有真正回答問題,不是某個詞出現幾次。
5.2 一個功能頁到底該多長才夠?
沒有固定字數,關鍵是這一頁有沒有把該功能的完整需求講清楚。像數位憑證這種技術性主題,使用者想知道概念、想確認產品支不支援、可能還想了解符合哪些規範,這些都寫到位,長度自然就夠。如果只寫兩三句產品好處,那再短都算薄弱內容。判斷標準是內容深度,不是字數。
5.3 定價頁和功能頁的結構化資料會不會互相打架?
不會,因為它們描述的是不同層級的資訊。定價頁用 Offer 描述方案價格,功能頁用 SoftwareApplication 描述軟體本身,這兩個跟全站的品牌識別標記各司其職。真正要小心的是同一種資訊在標記和頁面上不一致,例如標記寫的價格跟頁面顯示的不同,那才會被判定為不可信。
5.4 為什麼我的功能頁在後台看起來正常,卻沒有流量?
最常見的原因是它根本沒被索引。前台顯示正常不代表搜尋引擎有收錄它,這兩件事是分開的。我建議直接用 Search Console 的網址檢查工具查一次,如果狀態是未索引,那就是根源。我實際遇過一個上線很久、對外一直有推的功能頁,在索引報告裡是空的,不查永遠不會發現。
5.5 高價值頁掉流量,第一步該做什麼?
第一步永遠是確認它還有沒有被索引,不是急著改內容。索引沒了,內容寫得再好也到不了使用者面前。確認被收錄之後,再依序檢查標題有沒有對上搜尋意圖、內容有沒有回答疑問、內部連結有沒有把權重集中到主力頁。照這個順序走,才不會在錯的地方浪費力氣。
5.6 免費工具排在前面,我的付費功能頁還有機會嗎?
有,但切角要不一樣。免費工具搶的是「馬上就要用一次」的即時需求,你的功能頁該爭取的是「要長期用、在意安全與規範」的使用者。把符合的資安標準、法律效力、企業級的使用情境寫清楚,這些是免費工具通常給不了的深度,也是會付費那群人真正在意的判斷依據。