AWD 自適應 vs RWD 響應式：優缺點與適用情境比較

行動裝置已占全球網站流量的重要比例，Google 也以手機版內容作為索引基礎。在這個前提下，「該用 RWD 還是 AWD」的答案比過去收斂。Mobile-First Indexing 談的是索引來源，不是手機版另有排名加分；真正要避免的是兩種裝置的內容與結構不一致。這篇要幫你判斷：多數情況採 RWD，還是少數情境值得考慮 AWD。

可先評估 RWD，再按具體功能、效能與維護需求比較其他配置。下面的問題與表格協助釐清取捨，沒有固定九成比例、頁數或答題分數能直接決定。

Google 主要使用行動內容建立索引，因此需核對手機版主要資訊與可抓取性。各站手機流量佔比由自己的資料確認，不用未界定時段與母體的全球數字作決策。

「自適應」和「響應式」為什麼常常被搞混

RWD、AWD 在業界有不同使用方式，不能只看中文譯名或報價標籤。先問清楚版型、HTML、網址與資源如何提供；本文將版面策略和 Google 的行動網站配置分開說明。

RWD 的核心：同一份內容，交給瀏覽器重新排列

RWD 通常用彈性版面、圖片與 CSS 查詢適應可用空間；在 Google 的配置分類中，響應式網站以相同網址與 HTML 配合 CSS 調整。Media Queries Level 5 仍屬工作草案，個別功能有不同支援狀態，不能因文件層級較新就推定全部可用。

講白一點：桌機、平板、手機連到同一個網址，拿到的 HTML 幾乎一模一樣，只是 CSS 把元素的位置、大小、顯示與否重新排列過。想深入這套機制，可以看我寫的響應式網頁設計 RWD，那篇把流體網格、彈性圖片、斷點都講過一遍；如果你對 CSS 本身還不熟，CSS 入門全攻略會是比較好的起點。

AWD 需先釐清：預設版型與伺服器選版

AWD 常被用來描述為不同條件準備多套配置，也有資料以它指伺服器依裝置提供不同 HTML。這些不是同一個必然機制；本文後續涉及 User-Agent、快取與多 URL 的風險，特指相應部署方式，不能套到所有被稱為 AWD 的版面。

Google 的文件分別說明響應式、動態提供及獨立網址。RESS 是混合實作的稱呼，並不是官方另外新增的第四類，也不能把下面三列全部當 AWD 的唯一形式。

這三種形態要處理的技術問題不同。獨立行動網址需要桌機頁以 rel="alternate" 指向對應行動頁，行動頁再以 rel="canonical" 指回桌機頁；動態服務要處理 Vary: User-Agent 與快取，RESS 則介於兩者之間。真正關鍵是部署形態與技術細節，不是 AWD 這個標籤。

行動優先索引改變的是內容檢查重點

歷史上網站可能以獨立行動頁或不同範本處理裝置需求。是否較快、較好維護或提高轉換，都需看實作與當時條件，不由年代或名稱直接判斷。

Google 在 2023 年 10 月宣布行動優先索引全面到位，現在以手機版內容作為索引基礎。這是內容蒐集與索引方式的改變，不代表 RWD 天生取得排名優勢；它只是讓手機版缺內容的 AWD 網站更容易暴露問題。

若 AWD 手機版為了速度刪掉詳細產品描述、評論或重要連結，Google 建立索引時也可能看不到這些資訊。問題是內容不對等，不是 AWD 技術本身；搜尋表現是否改變仍取決於被刪內容與查詢的關係。

行動優先索引真正改變的是前提：不管選 AWD 或 RWD，手機版都要提供與桌機版等值的主要內容、結構化資料、圖片替代文字與可探索連結。RWD 通常較容易維持一致；AWD 則需要額外的同步與測試機制。

再把這件事講得更白一點。在桌機版作為主要索引來源的年代，有些 AWD 網站會大幅精簡手機版；Google 並非完全看不到手機頁，只是桌機版曾是主要索引基礎。改為行動優先索引後，手機版若缺少產品描述、評論、結構化資料或重要連結，這些內容就可能無法完整進入索引。還在使用 AWD 的舊網站，應先確認手機版是否保留等值核心內容，再決定是否更換技術。

一張表把差異講清楚，但表格從來不是最終的答案

表格沒說出口的三件事

比較表是待確認的實作差異，不是每個專案都成立的固定優劣。尤其要核對共用內容、快取與維護方式。

多套範本可能增加修改與測試，但也可共用資料和元件。成本不由裝置數直接相乘，應列出實際工作再估算。

不同版本若缺少同步機制，可能出現價格、文案或功能不一致。RWD 也可能因條件顯示或程式邏輯而缺內容；兩種實作都應測試，不能假設某類網站天天發生客訴。

第三，RWD 的技術 SEO 變因通常較少。獨立行動網址要維護 alternate 與 canonical 對應，動態服務要正確送出 Vary 標頭；設定錯誤可能造成抓取、快取或正規化問題，但不能把任何排名變化都歸因於 AWD。

RWD 真正的優點，以及它沒有告訴你的代價

優點：可共用內容與網址

Google 建議響應式設計，原因包括較容易實作與維護。這不是排名偏好，也不保證不會出錯；同一程式修改後仍需檢查各個視窗、狀態與裝置。

如果你想看 RWD 在實際專案裡怎麼落地，網頁版面設計完全攻略把斷點規劃與流體排版的觀念講得很完整；電商場景則可以參考RWD 購物網站設計的 Elementor 實戰流程，那是一條可以直接照著走的工作路徑。服務型作品集的場景，可以接著看Blocksy 作品集的斷點與動線規劃，從手機動線一路做到聯絡轉換。

效能代價取決於資源如何提供

相同 HTML 不代表手機必須下載全部桌機資源。srcset、picture、條件載入與適當拆分可控制資源；另一方面，單純用 CSS 隱藏元素不保證已阻止相關下載，需看實際網路請求。

大量不必要資源可能影響效能，但結果需要量測。Core Web Vitals 的現場資料與實驗室診斷適用所有配置，不只 RWD。

若桌機特效在手機仍載入卻無用途，可先定位並精簡。不要直接由動畫數量推算跳出率，也不一定需要為手機另設整站。 延伸可參考網站速度這條線的細節。

AWD 不是舊技術，它只是常常被用錯地方

裝置選版可以評估，但先問它要解決什麼問題，以及現有響應式和資源優化能否處理。這不是只限少數產業的技術資格。

值得比較不同配置的情境

• 不同裝置的任務或互動差異大，需比較共用與獨立介面的成本。
• 經量測確認資源傳輸或渲染是瓶頸，再比較響應式資源、條件載入或伺服器調整。
• 既有多版本網站需要評估保留、重整或遷移，並維持行動主要內容。

大型平台可能因歷史架構、流程或團隊安排使用混合配置；小型產品也可能有合理需求。未取得其測試資料前，不能推定它們都已證明 AWD 有更高轉換收益。 延伸可參考電商平台終極比較。

獨立行動網址曾是處理行動需求的做法之一，至今仍受 Google 支援。不能將 AWD 的所有定義都等同 m. 網址，也不宜臆測某年代幾乎所有大型網站的配置。

獨立網址：維護內容與 URL 對應

若 AWD 採用 m. 子網域（子網域與子目錄可看子網域 vs 子目錄全解析），桌機與手機會是不同 URL。Google 對相似內容通常會做重複內容整併，不是自動處罰；但若 alternate、canonical 與轉址對應錯誤，可能選錯代表網址或浪費抓取資源。每個桌機頁與行動頁都要一對一對應。

純 RWD 和純 AWD 之間，其實還有一大片灰色地帶

實作可以結合彈性佈局、預設版型、共用內容與條件資源。先描述實際行為，會比只問 RWD 或 AWD 名稱更容易比較。

響應式圖片讓瀏覽器依 srcset、sizes 或 picture 的來源條件選擇資源。需正確提供尺寸與候選並量測網路請求；它本來就是 RWD 可使用的方式，不必解讀為借用 AWD，也不保證固定 LCP 改善。

可按實際能力或條件安排 JavaScript 及其他資源，避免只從視窗寬度推定裝置效能。字型分段或子集也需保留缺字回退，不一定精確只載入當頁每個字。

先量測瓶頸，再比較低成本調整和架構變更。沒有可證實的八成問題都能由某組優化解決，也不能由圖片壓縮一項保證最高投報率。 延伸可參考圖片壓縮工具實測推薦。

六個問題，幫你診斷自己到底該走 RWD 還是 AWD

用下面問題整理需求與限制，再比較候選實作；它們不是有固定分數門檻的診斷測驗。

1. 有哪些代表性版型、任務與互動，哪些需要在不同視窗調整？
2. 手機與桌機需要的主要資訊是否等值，操作方式有哪些差異？
3. 資料、元件與範本可以共用多少，維護和測試由誰負責？
4. 相同 URL 是否依請求提供不同內容，快取與 Vary 如何處理？
5. 若有獨立行動 URL，alternate、canonical 與轉址是否一對一正確？
6. 量測到的瓶頸在哪裡，能否先用響應式資源與程式調整解決？ 延伸可參考技術性 SEO 完全指南。

將候選方案按需求、效能、維護和遷移成本比較即可。沒有四題或三個理由的門檻，也不要求內容破萬才可以評估裝置選版。

如果你還是決定走 AWD，這三個 SEO 地雷一定要閃過

若決定採用 AWD，下面三項要在上線前驗證。它們可能影響抓取、索引、快取與使用體驗，但不宜宣稱每一項都會立刻造成排名變化。

一、動態服務一定要送出正確的 Vary HTTP 標頭

同一 URL 若依 User-Agent 回傳不同 HTML，Google 的動態提供指引要求使用 Vary:User-Agent，表明哪些請求特徵影響回應。但標頭不保證每家 CDN 都自動建立相應快取變體，仍需檢查供應商的支援範圍與快取鍵設定。

缺少 Vary 或快取鍵設定不符，都可能讓裝置收到錯誤版本。Cloudflare 文件說明，預設不會按任意 Vary 值區分快取，特定設定與功能另有例外。應分別用桌機與手機 User-Agent 發出 GET 請求，比對首次及命中快取後的 HTML 與回應標頭。

二、保留主要內容並避免誤判 cloaking

若網站刻意依 User-Agent 向搜尋引擎與使用者提供不同內容以操控排名，可能構成 Cloaking，違反 Google 垃圾內容政策。Google 可能採取演算法或人工處置，但不是每個差異都會自動導致整站移除；無障礙、裝置適配與正常動態服務要看目的與呈現是否一致。

安全原則是桌機版和手機版提供等值核心資訊，差異可放在版面與互動方式。獨立行動 URL 應由桌機頁用 alternate 指向行動頁、行動頁用 canonical 指回桌機頁，不是雙向 canonical。可參考Canonical URL 完全指南；需要轉址時，再對照301 與 302 轉址完整教學。

三、別讓 AMP 變成你的偽 AWD

有些網站在 RWD 主站之外維護 AMP 版本，等於多一組 URL 與內容同步成本。AMP 從來不是一般排名加分保證，Google 也已取消行動版「焦點新聞」必須使用 AMP 的資格限制。今天不必把 AMP 當成行動 SEO 必修，是否保留要看既有流量、功能與維護成本。

AMP 是否保留應按現況評估，並記錄內容和網址對應。多版本增加哪些成本要具體盤點，不直接稱為必然維護災難。 延伸可參考AMP 完整指南。

上線之前與之後，怎麼驗證你真的做對了

選了 RWD 或 AWD，不等於它就真的運作正常。實務上太多網站自以為是響應式，結果手機一打開就出現橫向捲軸；也有自以為是動態服務的網站，Vary 標頭根本沒設上去。這一節給你一份不管選哪種方案都用得上的驗證清單，分上線前與上線後兩段。

上線前：在你能完全掌控的環境裡把地雷先踩掉

用代表性實機補足模擬測試，檢查觸控、字型、效能和完整任務。DevTools 能模擬部分觸控與限制網路，但不是實際手機的完整等效環境；裝置數量及網路條件按受眾和風險安排。

第二，刻意把網路限速再測一次。DevTools 的 Network 面板可以模擬慢速 3G 與 4G，這一步會讓你親眼看到使用者最痛苦的瞬間，哪些元素在空白等待、哪些圖片阻塞了首屏，往往在這一步才會現形。

RWD 要檢查 viewport、連續寬度、縮放及重要內容，320、375、768 等可作測試尺寸而非固定必設斷點。動態提供需檢查實際 GET 回應、Vary 與快取變體；curl -I 的 HEAD 標頭不能單獨證明 HTML 正確。獨立網址則核對桌機 alternate 與行動 canonical 的方向和對應。

上線後：用 Google 自己的工具持續監看

上線後結合索引資料、使用者任務、現場效能與伺服器回應檢查，不只相信單一工具或單次觀察。

Google 已在 2023 年 12 月停止 Search Console 的「行動裝置可用性」報告與 Mobile-Friendly Test。上線後可用 Search Console 的網址審查確認索引狀態與 Google 抓取的版本，再搭配 Lighthouse、真實手機、瀏覽器無障礙檢查與不同 User-Agent 的回應比對。對動態服務網站，伺服器日誌也能補足 URL Inspection 的單頁抽查。

PageSpeed Insights 可能提供現場與實驗室資料，現場資料不足時不一定顯示。兩者環境、時間範圍與量測內容不同，應分開解讀，再用診斷找原因。 延伸可參考Core Web Vitals。

把上面這些檢查排進每個月的例行工作，光在上市當下做一次，遠遠不夠。網站是活的，你每加一個功能、每多一支外掛、每換一張首圖，都可能把之前顧好的行動體驗悄悄打回原形。持續監看，才是真正讓你當初的技術選型發揮價值的前提。

最常被問到的幾個迷思

RWD 是不是一定比較便宜

費用取決於版型、共用程度、功能、效能目標、內容與測試，不由 RWD 或 AWD 名稱保證高低。先列相同需求，再比較整體成本。

AWD 手機版比較快，是不是排名就一定比較好

Google 的排名系統使用 Core Web Vitals，但未公佈通用固定權重。較快不保證排名較好，仍需處理查詢相關性、內容與其他條件。

我已經有 m. 子網域了，現在要不要拆掉改 RWD

先盤點既有網址、內容對應、流量、標記、轉址及維護成本，再決定是否改 RWD。遷移需建立測試和回復安排，可能有波動，但不能預設一定流量崩跌。

用 CSS 把元素 display:none 藏起來，Google 還會索引嗎

Google 可以索引以 CSS 隱藏、摺疊或分頁呈現的內容，沒有官方規則說使用 display:none 就會自動「權重打折」。真正要確認的是內容是否已存在於行動版 DOM、是否需要互動後才載入，以及使用者能否合理存取。若內容根本未載入，Google 當然無法索引。

這帶出一條實用的設計紀律：重要內容可用摺疊、分頁或響應式版面整理，但要保留在行動版 DOM 中，並讓使用者能合理開啟。Google 沒有規定 display:none 會自動降低權重；真正的風險是內容根本未載入、手機版缺漏，或介面讓讀者難以存取。純裝飾背景與動畫則可依裝置移除，以減少不必要的資源。

那為什麼有些大公司的產品，桌機版和手機版還是長得完全不一樣

不同裝置的介面可能因任務、平台或歷史架構而不同，也可能共用資料和邏輯。不能由外觀直接推定團隊規模或網站類型，先把自己的需求和維護能力列清楚。

結論：別讓選哪個變成拖延動工的藉口

選型前先寫清楚手機與桌機的主要內容、互動差異、資源需求及維護責任。RWD 是可先評估的配置；若其他方式更符合需求，則把內容同步、快取與網址對應列入驗收。

以實際內容、速度與操作驗收方案，比只看技術標籤有用。做好其中一種不保證一定勝過另一個網站，排名和轉換仍受多項條件影響。

如果你正在規劃一個新網站，我給你一個三步行動方案，照著走可以少繞很多遠路。

1. 先評估 Google 建議的 RWD，並按需求比較其他配置，不設固定答題門檻。
2. 確保行動內容完整；mobile-first 設計流程可以採用，但和行動優先索引是不同概念，桌機也需驗證。
3. 上線後結合索引、現場效能、實機任務與回應資料重測，記錄限制和變更。 延伸可參考Figma 響應式設計教學、網頁設計從零到一的完整指南。

可從一個代表性頁面開始：完成手機與桌機的核心操作，記錄缺漏內容、溢出、載入瓶頸與錯誤回應。用這份結果比較方案，並保留修改前後的測試紀錄。