RWD vs 獨立手機版網站:成本、SEO、維護全面比較與選擇指南

許多企業在規劃網站時，會在「RWD 響應式網站」與「獨立手機版網站」之間猶豫。兩者都能讓手機使用者順利瀏覽，但架構、成本、SEO 設定與長期維護方式完全不同。在目前的網站架構標準下，這個決策幾乎都會傾向 RWD，但具體傾斜多少、有沒有例外情境、舊有獨立手機版該不該遷移，需要看實際技術細節與 TCO 算式。本文聚焦這個採購決策——架構差異、技術 SEO 設定差異、5 年 TCO 試算、依產業與公司規模的決策矩陣，以及從舊 m.* 子網域遷移到 RWD 的考量。

一、決策前提:兩種方案的最小定義

要做這個決策，需要先快速釐清兩種方案的最小定義(技術原理請見支柱頁，本文不重複展開)。

兩者真正的差異不在「網站長什麼樣」(因為使用者體驗都可以做到很好)，而在架構、SEO 設定、開發與維護成本——這也正是採購決策要看的東西。

二、獨立手機版的三種實作方式

很多企業把「獨立手機版」當成一種東西，實際上它有三種主要實作方式，各自的技術門檻、SEO 風險與維護成本都不同。

方式 A:不同子網域(m. 子網域)

最經典的做法，桌機版放 https://example.com，手機版放 https://m.example.com，使用者用手機進站時由伺服器或前端 JS 自動轉址。

• 技術需求:兩套網站、兩套主機(或同主機兩個 vhost)、User-Agent 偵測轉址邏輯
• SEO 風險:需要正確設定 canonical 與 alternate，否則重複內容
• 典型代表:早期維基百科(m.wikipedia.org)、舊版各大新聞網站

方式 B:不同子目錄

同一個網域但用不同路徑，桌機版 https://example.com/，手機版 https://example.com/mobile/ 或 https://example.com/m/。

• 技術需求:同一個網域、不同路徑、轉址邏輯(伺服器端或前端)
• SEO 風險:略低於子網域，但同樣需要 canonical/alternate 設定
• 典型代表:少數舊系統、客製 CMS

方式 C:Dynamic Serving(動態服務)

桌機與手機共用同一個網址，伺服器在收到請求時讀取 User-Agent，動態回傳不同的 HTML 給不同裝置。

• 技術需求:伺服器端 User-Agent 偵測 + 必須回傳 Vary: User-Agent HTTP header
• SEO 風險:若 Vary header 沒設好，CDN 會把手機版內容快取後給桌機使用者
• 典型代表:部分大型電商、部分動態應用

三種方式的快速比較

三、RWD vs 獨立手機版:核心架構差異

把 RWD 與獨立手機版(以 m.* 為例)並列，可以從六個面向看出本質差異。

架構差異對採購的實際影響:

• 網址結構會影響廣告投放(要建立幾組著陸頁?要做幾組轉換追蹤?)
• 內容管理會影響行銷團隊的內容更新流程
• SEO 管理會影響長期搜尋流量穩定性
• 跨裝置彈性會影響未來支援新裝置(摺疊機、車載螢幕、穿戴裝置)的成本

四、SEO 技術差異:canonical、alternate、Vary header

這節是這個比較的核心——也是企業最容易在採購決策後踩雷的地方。

RWD 的 SEO 設定:天然簡單

RWD 因為同一份 HTML、同一個 URL，幾乎不需要特別的 SEO 設定。Googlebot 用 Smartphone 爬蟲抓取，看到的就是直接送到使用者瀏覽器的同一份內容。Mobile-First Indexing 對 RWD 而言沒有任何額外的設定工作。

需要做的事情有限:

• 確保 <meta name="viewport" content="width=device-width， initial-scale=1.0"> 存在
• 確保結構化資料(Schema.org JSON-LD)只寫在這一份 HTML 裡
• 確保 alt 文字、meta description、Open Graph 都只有一份

獨立手機版(m.* 子網域)的 SEO 設定:需要兩個方向的明確聲明

獨立手機版使用兩個不同 URL 但本質是同一個內容時，必須讓 Google 知道兩者的對應關係，否則會被當成重複內容。具體要做的事情:

桌機版頁面要加上 alternate，告訴 Google「手機版在這裡」:

<link rel="alternate"
      media="only screen and (max-width: 640px)"
      href="https://m.example.com/page">

手機版頁面要加上 canonical，告訴 Google「我的正本是桌機版」:

<link rel="canonical" href="https://example.com/page">

兩個方向都要設定，缺一不可。常見踩雷:

• 只設了 canonical 沒設 alternate → Google 認得手機版，但不知道對應到哪個桌機版
• alternate 的 media query 寫錯(例如寫了 max-width 但沒寫 only screen)
• 桌機版與手機版的網址結構對應不一致(桌機版 /products/abc 但手機版 /m/products?id=abc)，需要逐頁設定
• sitemap 同時收錄兩個版本，但沒明確標註關係

Dynamic Serving 的 SEO 設定:Vary header 不能漏

如果採用 Dynamic Serving(伺服器依 User-Agent 動態回傳不同 HTML 給同一個 URL)，HTTP 回應必須加上:

Vary: User-Agent

這行 header 告訴 Googlebot 與 CDN:「這個 URL 的內容會依 User-Agent 變化，請不要快取後混用。」

常見踩雷:

• 後端有切換 HTML 但忘了送 Vary header → CDN 把第一個來的版本快取，後面的使用者拿到錯誤版本
• CDN 設定沒讀 Vary header → 一樣會混淆
• 第三方加速服務(Cloudflare、Akamai)對 Vary 的處理規則不同 → 要逐家確認

AI 引擎(AEO)友善度差異

近年 AI 搜尋崛起後，這個差異更明顯。ChatGPT、Perplexity、Google AI Overviews 在抓取與引用內容時，會以單一 URL 作為內容語意單位。對 AI 引擎而言:

• RWD:每篇文章一個 URL，AI 引擎抓哪個都是同一份內容，引用穩定
• 獨立手機版:同一篇文章兩個 URL，AI 引擎可能在不同時間引用不同版本，造成引用一致性問題

對重視 AEO 流量(AEO 行銷方案的核心目標)的企業而言，這是另一個傾向 RWD 的理由。

五、初期建置成本與 5 年 TCO 試算

採購決策最常被低估的是「長期維護成本」。只看初期報價往往會誤判。

初期建置成本對照(以一般中小企業官網為例)

獨立手機版的初期成本約是 RWD 的 1.5–1.6 倍。這個差距來自於:兩套設計稿、兩套前端、兩套 CMS 整合、兩倍的測試工作量、加倍的 SEO 設定。

5 年 TCO 試算

但真正影響採購總成本的是維護階段。以一個中等規模企業網站(年內容更新約 30 次、改版週期 3–5 年)為例:

這個算式的關鍵不是具體數字(每家公司不同)，而是結構:

• RWD 的維護成本「乘上時間」效應較小
• 獨立手機版的維護成本「乘上時間」效應較大(每年多支出累積)
• 改版時獨立手機版的成本翻倍效應最明顯

對 3 年以上會持續經營的網站，RWD 的 TCO 優勢通常很明顯。

六、什麼情境下還會選擇獨立手機版

雖然多數情境 RWD 都勝出，但有幾種特殊情境，獨立手機版仍可能是合理選擇。

1. 情境 1:手機與桌機是完全不同的產品 當手機版與桌機版做的事情完全不同(不是「同樣的事情但呈現不同」)，獨立手機版才有意義。例如:桌機版是後台管理系統，手機版是快速報到掃碼工具;桌機版是完整詳細的產品目錄，手機版只做「快速下單回購」;桌機版是企業資訊網站，手機版是員工打卡或業務 CRM 入口。這些情境下，兩個版本的內容、功能、流程都不同，硬做 RWD 反而不自然。
2. 情境 2:大型平台有特殊手機原生整合 當網站需要深度整合手機原生功能(GPS 即時定位、相機掃碼、感測器、生物辨識、行動支付特殊整合)，且這些功能在桌機上不存在，獨立手機版可能更容易實作。但這類網站目前通常會直接做成 App，不會用網頁解決。
3. 情境 3:舊系統無法重構，需要過渡 如果既有桌機網站建構在很舊的系統上(例如 2010 年前的 ASP、PHP 4)，改成 RWD 的成本可能比另外做一個 m.* 過渡網站還高。這時獨立手機版可以作為短期方案，等舊系統整體重做時再轉 RWD。
4. 情境 4:流量規模極大、需要極致效能優化 當網站日均 PV 達到百萬以上、效能優化每一毫秒都有商業價值時，Dynamic Serving 可以針對手機回傳精簡 HTML、針對桌機回傳完整版本，比 RWD 用 CSS 隱藏更節省頻寬。但這類網站通常是大型電商、新聞媒體、社群平台，不在中小企業官網的範圍。

七、決策矩陣:依公司規模與產業給建議

把產業特性、公司規模、預算限制疊加起來，常見的決策建議如下。

三個關鍵自問

如果還在猶豫，這三個問題能快速決定:

1. 手機使用者要做的事，是否與桌機使用者本質上不同? 否 → RWD;是 → 考慮獨立手機版。
2. 是否有專門的內容團隊能維護兩套內容? 否 → RWD;是 → 仍可考慮獨立手機版。
3. 是否需要長期經營 SEO 與 AEO 流量? 是 → RWD;否(主要靠廣告或業務開發) → 兩者皆可。

絕大多數中小企業，三題答案會是「否、否、是」——直接選 RWD。

八、從獨立手機版遷移到 RWD 的步驟與考量

許多企業現有的網站是 5–10 年前做的，當時可能採用了 m.* 子網域方案。要遷移到 RWD，需要規劃妥當以避免 SEO 排名損失。

遷移前的盤點工作

• 內容差異盤點:用爬蟲工具(如 Screaming Frog)抓出桌機版與手機版的所有 URL 對應，找出「桌機有但手機沒有」「手機有但桌機沒有」「同 URL 但內容不同」的情況
• 流量盤點:用 Google Analytics 找出 m.* 子網域的高流量頁面，確保這些頁面在新 RWD 網站上有對應 URL
• 連結盤點:用 Search Console 或 Ahrefs 找出哪些外部連結指向 m.* 子網域，這些需要透過 301 確保權重轉移
• 結構化資料盤點:兩個版本的 Schema.org 標記是否一致

遷移執行步驟

1. 在桌機版網域上建立 RWD 新版 不要先停 m.* 子網域，讓新舊版本並存，直到 RWD 版完全穩定再執行轉址。
2. 內容整合 把桌機版與手機版的內容合併成單一來源，解決「桌機有手機沒有」的內容缺口。
3. 逐頁 301 轉址 建立 m.* 子網域到桌機版網域的逐頁對應，例如 m.example.com/products/abc → example.com/products/abc，不要全部都導到首頁(這是最常見的錯誤)。
4. 更新 sitemap 移除 m.* 子網域的 URL，重新提交到 Google Search Console。
5. 保留 301 至少 12 個月 讓 Google 與外部連結來源充分認識新對應關係。
6. 監控 30–90 天 用 Search Console 看排名與索引變化、用 GA 看流量變化。

遷移後常見問題

• 某些頁面排名下降:通常是因為 m.* 上的內容比桌機版完整，遷移後資訊變少。修補方式是把遺漏的內容補回新 RWD 版
• Search Console 顯示 4xx/5xx 增加:通常是 301 規則沒覆蓋到的頁面。檢查 server log 找出哪些 URL 在 404
• AI 引擎引用混亂:因為 AI 訓練資料中可能還有 m.* 的內容，這個會自然衰退，3–6 個月後 AI 工具會更新到新 URL

遷移時機建議

如果同時要做網站改版，遷移 RWD 是順勢而為。如果現有桌機版穩定且 SEO 表現好，但只有 m.* 子網域問題，可以單獨做手機版整合而不重做桌機版——這是中等規模的遷移工程。

九、三個採購決策階段的觀念誤解

進入採購決策時，企業主常見的三個觀念誤解，與實作層面的常見錯誤(請見 RWD 網站製作常見錯誤)不同。

• 誤解 1:以為「客製」一定比「響應式」更好 採購時常聽到廠商說「我們可以做獨立手機版，完全為您的手機使用者客製」，聽起來像是更高階的服務。實際上「客製」不等於「更好」，而是「更花心力」——對多數企業而言，兩套內容的維護負擔反而會讓網站品質下降。
• 誤解 2:以為改 RWD 一定要重做整站 如果現有網站是 m.* 子網域架構但桌機版運作良好，改 RWD 不一定要重做整站——可以單獨重構手機呈現邏輯，把 m.* 上的內容整合回桌機版網域。完整的網站改版預算可以下次再排。
• 誤解 3:以為 RWD 比較便宜代表「比較陽春」 採購報價中 RWD 比獨立手機版便宜 30–60%，常被誤解為「便宜的方案功能比較少」。其實兩者在功能上幾乎沒有差別——差價來自於 RWD 不需要做兩套設計、兩套前端、兩套 CMS 整合、兩套 SEO 設定。便宜的是「重複工作」，不是「功能完整度」。

十、結論:採購決策幾乎都會傾向 RWD

RWD 與獨立手機版的差異，本質上是架構與維護方式的差異，不是「網站長什麼樣」的差異。對目前的企業網站採購決策而言:

• 預設選擇 RWD:適合 95% 以上的中小企業官網、品牌網站、服務型網站、SEO 內容網站、中小型電商
• 獨立手機版的合理採用情境:手機與桌機是完全不同的產品、舊系統過渡期、大型平台極致效能優化——絕大多數企業不在這些情境內
• TCO 才是真正的決策依據:初期報價只佔 5 年總持有成本的 1/3 左右，維護成本「乘上時間」的效應決定長期划算度
• 舊有 m.* 子網域要遷移時:盤點內容差異、做逐頁 301、保留轉址 12 個月以上、監控 30–90 天，可在不損失排名的前提下完成

十一、常見問答 FAQ