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

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

重點摘述：對 2026 年大多數的網站來說，RWD 是預設值，不是選項。AWD 不是過時技術，它有不可取代的場景，但那個場景很窄。這篇會用六個診斷問題、一張比較表、三個 SEO 地雷，幫你把「該選哪個」這個被過度放大的難題一次拆解乾淨。

手機已經吃掉全球網路流量的大半。根據 Statista 的長期追蹤（2026 年 4 月），行動裝置佔全球網站流量的比例長年維持在六成上下，而且這個數字還在往上爬。Google 也早在 2023 年 10 月在 Google Search Central Blog 的公告〈Mobile-First is Here〉 中正式宣佈 Mobile-First Indexing（行動優先索引）全面上線。本質上來說，你現在做的每一個網站決策，都得先過手機這一關。

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

這兩個詞在中文世界被混著用的程度，老實說比你想像的嚴重。不少設計公司的報價單會把 AWD 寫成 RWD，把 RWD 解釋成自適應，客戶聽得一頭霧水，結果仍乖乖付了錢。問題出在中文字面：「適應」和「響應」聽起來都跟「配合裝置」脫不了關係，但兩者在技術上做的是完全不同的兩件事。把它們搞清楚，是後面所有判斷的地基。

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

RWD（Responsive Web Design，響應式網頁設計）的精神很單純，伺服器送出的是同一份 HTML，所有的版面變化都交給瀏覽器端的 CSS 來決定。這套做法的技術骨幹是 Media Query（媒體查詢），它讓 CSS 能夠根據螢幕寬度、方向、解析度等條件，套用不同的樣式規則。W3C 的 Media Queries 規範一路發展到 Level 5（2025 年），現在連使用者偏好都能偵測，例如 prefers-reduced-motion（減少動態）或 prefers-color-scheme（深淺色偏好）。

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

AWD 的核心：伺服器先判斷你是誰，再決定送出什麼

AWD（Adaptive Web Design，自適應網頁設計）走的是另一條路。它在伺服器端就先讀取請求的 User-Agent（或其他裝置特徵），判斷對方是手機、平板還是桌機，然後送出為這個裝置量身打造的那一份 HTML。手機版和桌機版可以是兩套不同的範本、不同的內容、甚至不同的功能。

實務上，AWD 有三種常見的部署形態，這是很多文章沒講清楚、卻會直接決定後續 SEO 複雜度的地方：

形態	URL 結構	典型做法
獨立行動網址	m.example.com 子網域，或 example.com/mobile/ 子目錄	完全獨立的行動版網站，兩套內容各自維護
動態服務（Dynamic Serving）	同一個 URL	伺服器依 User-Agent 送出不同的 HTML 回應
RESS（Responsive + Server Side）	同一個 URL	以 RWD 為主，伺服器端針對特定元件做條件式微調

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

為什麼這個問題在 2026 年其實已經被 Google 某種程度地蓋棺了

如果你在五年前、十年前問「AWD 還是 RWD 對 SEO 比較好」，這還真是個值得認真辯論的問題。那個年代，Google 用桌機版網頁來建立索引，手機版往往是被順便處理的副產品。很多網站因此發現：為手機做一個獨立的、輕量的、內容精簡的 AWD 版本，手機載入飛快，使用者體驗好，轉換率也跟著漂亮。

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

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

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

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

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

比較維度	RWD 響應式	AWD 自適應
內容份數	一份	多份（依裝置或範本）
URL 結構	單一 URL	多 URL（m.）或單 URL（動態服務）
適配發生點	瀏覽器端，靠 CSS	伺服器端，靠裝置判斷與分派
維護成本	低	高，需顧多套範本
行動版載入速度	受桌機程式碼拖累	可做到極致輕量
內容一致性風險	低，天然一致	中到高，需人工同步
SEO 複雜度	低，可預測	高，牽涉轉址、標頭、canonical
開發門檻	中，需熟媒體查詢	高，需伺服器端邏輯

表格沒說出口的三件事

上面這張表，每一格都對，但它有三個表格塞不進去的真相，而這三點往往才是專案後來出包的地方。

第一，維護成本可能遠超過直覺上以為的兩倍。很多人以為 AWD 就是桌機版加手機版，兩套各自照顧好就行。實際上，每改一個功能，你要在桌機版改一次、手機版改一次，還要測試兩者不會互相打架。專案越大，這個同步成本越可怕，後來往往演變成「手機版永遠跟不上桌機版」的落後狀態。

第二，內容一致性是 AWD 最容易被放過的隱形地雷。桌機版改了促銷文案，手機版忘了同步；手機版調了價格，桌機版還掛著舊價錢。這種事在 AWD 網站裡天天發生，而且因為兩套是分開維護的，通常要等到客訴進來、或被消費者截圖檢舉，團隊才會驚覺。

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

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

優點：一份程式碼、一個網址，Google 最愛這種單純

RWD 之所以變成主流，是因為它在大多數情境下夠好，而且簡單。對 Google 來說，一個 URL 對應一份內容，是最容易正確索引的結構，幾乎不會出什麼差錯。對開發者來說，一份程式碼意味著改一次就全部到位，不用擔心哪個版本漏掉了。對行銷人員來說，不用再追著工程師問「這個活動頁的手機版做好了沒」。

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

代價：手機被迫載了桌機那一大包

RWD 的代價，藏在「同一份 HTML」這六個字裡。既然桌機和手機拿到的是同一份，那就表示手機會把桌機需要的 CSS、JavaScript、圖片、字型全部一起載下來，再用 CSS 把不需要的 hide 掉。問題是，hide 掉不代表沒下載，那些東西還是吃掉了使用者的頻寬和你的載入時間。

web.dev（Google）的說明（2026 年）很直接：速度會影響使用者的滿意度和後續的轉換與回訪。當你的 RWD 網站為了桌機的華麗動畫載了一堆 JS 函式庫，手機版的 Core Web Vitals 就會跟著遭殃。這也是為什麼 Core Web Vitals 在 RWD 網站上，往往是個需要持續盯著的指標，做完一次就放著，很快就會失準。

實務上有個判斷方式：如果你的網站桌機版用了大量互動特效、滾動動畫、第三方面板，而且你沒有打算為手機版做獨立的效能優化，那 RWD 的代價就會慢慢累積成肉眼可見的跳出率。這不是 RWD 本身的錯，是「沒有紀律的 RWD」的錯。想知道怎麼把這個代價壓下來，網站速度這條線的細節是一份值得照著清單走一遍的對照表。

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

我不想把 AWD 講得一無是處，那不誠實。AWD 在某些情境裡，確實有 RWD 難以企及的優勢，問題是這些情境比一般人想像的窄得多。下面是 AWD 真正能發光的地方。

AWD 真正發光的場景：極致行動體驗、媒體、大型電商

• 極致的行動效能需求：當你的手機使用者多半處在 4G 甚至更不穩定的網路環境，每砍掉 100KB 都是真金白銀，AWD 讓你送出只含手機需要的最小化 HTML 與 CSS，這是 RWD 很難做到的極限。
• 功能差異極大：桌機版是一個完整的後台儀表板，手機版只保留檢視與通知，這種本來就該長得不一樣的產品，硬塞進 RWD 反而綁手綁腳，兩邊都做不好。
• 大型電商與媒體：商品頁、文章頁的桌機版可以承載大量推薦區塊、廣告版位、評論模組；手機版則可以大幅簡化，專注在看完、結帳這條最短路徑。

這也是為什麼你會看到一些大型電商平台（可參考電商平台終極比較）與媒體網站，到現在還是維持某種形式的 AWD。他們當然懂 RWD，只是算過帳，在極端流量下，AWD 帶來的效能與轉換收益，值得付出額外的維護成本。這是一個很冷血的商業計算，跟技術品味無關。

要理解 AWD 為什麼在某些場域還活著，得先回頭看它誕生的背景。大約在 2010 到 2015 年這段期間，智慧型手機剛普及，行動網路又慢又不穩，那是一個名副其實的「m-dot 黃金年代」。幾乎所有大型網站都會多做一個 m. 開頭的手機版，用最精簡的 HTML、最少圖片、最短的路徑，讓手機使用者能在 3G 環境下勉強把頁面打開。那個年代，桌機版和手機版各自獨立，是被硬體與網路環境逼出來的合理選擇。後來手機效能追上來、4G 普及、CSS 媒體查詢成熟，這套獨立維護兩套網站的成本就顯得越來越不划算，RWD 才順勢接管了主流。AWD 並沒有死，它只是退守到那些「規模與流量大到值得為手機單獨優化」的少數戰場。

AWD 的致命傷：兩套範本，加上重複內容的風險

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

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

如果你一路看到這裡，可能會以為世界只有兩種選擇：要嘛一份 HTML 全靠 CSS，要嘛伺服器分派兩套範本。但現實裡，大多數做得好的網站根本不站在這兩個極端，它們站在中間那片被忘記的灰色地帶。這也是我為什麼說「AWD vs RWD」這個二選一的框架本身就有點過時。

這片灰色地帶的核心想法是：用 RWD 當骨幹，再疊上各種「裝置感知」的優化手法，借用 AWD 的智慧，卻不背負 AWD 維護兩套範本的代價。最具代表性的例子是響應式圖片。HTML 的 <img srcset> 與 <picture> 元素，讓伺服器準備好同一張圖的多種解析度，再由瀏覽器根據自己螢幕的條件挑出最合適那一張下載。手機不會再傻傻地把手機用不到的超高解析圖整包拉下來，這項單一優化往往就能讓行動版的 LCP（最大內容繪製）硬生生快上一截。

再往下一層，是條件式的資源載入。桌機版需要那個華麗的滾動動畫函式庫，手機版根本用不到，那就用 JavaScript 在載入前先判斷螢幕寬度與裝置能力，決定要不要把那包 JS 拉進來。字型也可以做子集化與條件載入，只把頁面真的用到的字元下載下來。這些手法本質上都是在「同一份 HTML」的框架裡，塞進 AWD 那種「為不同裝置量身送出不同東西」的精神。

本質上來說，今天一個講究的 RWD 網站，骨子裡早就混進了不少 AWD 的 DNA。這對你的意義是：與其糾結要不要為了手機另起爐灶做一套 AWD，不如先把這些藏在 RWD 裡的優化空間榨乾淨。大多數網站在這一層能擠出的效能，就足以解決八成你以為非 AWD 不可的問題，而且不用多養一套範本。圖片優化相關的工具，可以參考圖片壓縮工具實測推薦，那是另一個常被低估、卻投報率極高的戰場。

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

不要再問「AWD 好還是 RWD 好」這種大而無當的問題了。下面六個問題，誠實回答，答案會自己浮現。多數人答完會發現，自己從頭到尾都只需要 RWD。

1. 你的網站規模，是十來個頁面，還是上萬個頁面？頁面少、結構單純，RWD 綽綽有餘。頁面上萬、又有複雜的商品或文章模板，AWD 才開始有意義。規模是第一個、也是最誠實的篩網。
2. 你的手機使用者，跟桌機使用者要的是同一件事嗎？一樣的話，RWD。如果手機版只求快速查、快速買，桌機版要深入研究與比較，那就值得為手機做另一種獨立體驗。意圖不同，是 AWD 唯一合理的起點。
3. 你有沒有持續維護兩套範本的人力？沒有，就別碰 AWD。這是最現實的問題，AWD 不是做不起，是養不起。很多團隊在這一題上高估了自己。
4. 你的 SEO 團隊，能不能處理 Vary 標頭、雙向 canonical、轉址鏈？不能，就留在 RWD。AWD 的 SEO 複雜度，需要有人隨時盯著爬蟲狀態與索引回報。想系統性地搞懂這些技術細節，技術性 SEO 完全指南是比較完整的入口。
5. 你的網站有沒有桌機能做、手機做不到的核心功能？例如複雜的拖曳編輯、大數據視覺化、多視窗並排比價。有，而且這功能是產品的賣點，那 AWD 為手機設計另一種合理的互動方式，是說得通的。沒有，就別為了差異而差異。
6. 你的效能瓶頸，是出在內容太多，還是互動太複雜？內容多，RWD 加上好的快取與圖片優化就能解掉大半。互動複雜到連精簡後手機都跑不動，AWD 才有真正的發揮空間。先分清楚病因，再決定療法。

六題裡如果你有四題以上指向 RWD，那就別再猶豫了。對多數中小企業、品牌官網、內容站，甚至中型電商而言，需求通常落在這個區間。真正需要 AWD 的，往往是那種流量大到每一毫秒都在燒錢、或產品形態天生分裂的少數特例。

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

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

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

如果你用的是 Dynamic Serving，同一個 URL，伺服器依 User-Agent 送出不同的 HTML，那你必須在 HTTP 回應裡加上 Vary: User-Agent 這個標頭。這是在告訴 Google 與各種 CDN 快取層：這個網址的內容會依請求裝置而不同，請不要用同一份快取回應所有人。

漏掉這個標頭時，搜尋引擎與共用快取可能無法得知回應會依 User-Agent 改變，造成錯誤版本被快取或抓取。應用不同 User-Agent 實際請求並比對 HTML，不要等到流量變化後才猜測原因。

二、兩個版本的內容不能實質不同到被當作作弊

若網站刻意依 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 完整指南有更全面的討論。但請記得一條底線：不要為了速度分數，去維護一套你根本顧不來的第二套內容，那只是在製造下一個 AWD 式的維護災難。

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

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

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

第一，用真實裝置測，不要只信設計稿或瀏覽器的裝置模擬器。Chrome DevTools 的裝置模擬很好用，但它模擬不出真實手機的觸控行為、字體渲染差異，更模擬不出弱網環境下的載入體驗。至少找兩三支不同螢幕尺寸的實機，用 4G 訊號實際把關鍵頁面走一遍。

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

第三，針對你的方案做對應的技術檢查。如果走 RWD，確認每個頁面都有正確的 viewport meta 標籤，並在常見斷點（320、375、768、1024、1440 這幾個寬度）都沒有橫向溢出。如果走動態服務，用 curl -I 或 DevTools 的 Network 面板檢查回應標頭，確認 Vary: User-Agent 真的有送出來。如果走 m. 子網域，逐一檢查桌機版與手機版的 rel=alternate、rel=canonical 是否雙向標記齊全。

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

網站上線之後，你真正該信任的，是 Google 看到的東西。這中間有落差，而且落差常常出乎意料。

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

速度這一塊，PageSpeed Insights 會給你實驗室數據與來自真實使用者的現場數據兩種來源。實驗室數據幫你定位技術瓶頸，現場數據告訴你真實使用者的實際體驗，兩者要搭配看，只看一邊會誤判。Core Web Vitals那篇把 LCP、INP、CLS 三個指標怎麼讀、怎麼優化講得更細，值得對著你自己的數據對照著讀。

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

最常被問到的幾個迷思

RWD 是不是一定比較便宜

不一定。RWD 的初次開發通常比 AWD 便宜，因為只有一套要顧。但如果你追求的是極致的手機效能，RWD 需要投入大量優化工作，包括圖片壓縮、字型子集化、JS 拆分、條件載入，這些加起來不見得比 AWD 省錢。便宜或昂貴，取決於你對「夠好」的標準設在哪裡，技術標籤反倒是次要。

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

Core Web Vitals 是眾多小幅排名訊號之一，速度快不保證排名。一個內容被大幅精簡的手機版，可能無法滿足查詢；稍慢但更相關的頁面仍可能排在前面。效能與內容都要改善，不必把速度包裝成競爭門檻。

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

不要輕舉妄動。已經上線、已經有排名的 AWD 網站，貿然拆掉改成 RWD，中間的轉址、權重移轉、索引重建，是一個高風險工程，做不好會把原本穩定的流量連根拔起。正確做法是先盤點現況的技術負債與內容落差，再決定是漸進式整合，還是維持現狀只補上內容同步。這種要不要動的決策，永遠比新站該選哪個更難，建議交給有實戰經驗的人評估，憑一股熱血自己硬上很容易翻車。

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

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

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

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

這是個好問題，也是很多人拿來質疑 RWD 的常見反證。答案很簡單：那些產品的手機版和桌機版，往往屬於同一個「服務」的兩個不同介面，背後共用一套資料與邏輯，前端卻是各自獨立設計的 app 或網頁。這跟一般企業網站、品牌官網、內容站的情境完全不同。前者是產品，後者是網站；前者有整個工程團隊在背後支撐兩套前端的持續迭代，後者大多連一個專職工程師都養不起。把 Google、Facebook 那種等級的產品介面選擇，直接套用到自己幾十頁的官網上，是典型的見樹不見林。多數網站根本沒有那個規模與資源去支撐兩套獨立介面，硬做只會兩頭空。

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

說到底，AWD 和 RWD 的選擇，是一個被嚴重過度放大的問題。太多團隊在這個選擇上開了無數次會、寫了無數份比較表，結果網站三年都沒上線。真正決定一個網站成敗的，從來不是你選了 AWD 還是 RWD，而是你選了之後，有沒有把那份選擇執行到位。

一個把 RWD 做得乾淨、內容紮實、速度顧好的網站，會穩穩打贏一個 AWD 做得半調子、兩套內容永遠對不齊的網站。反過來也成立。技術選型是手段，從來不是答案本身。還有一個反直覺的事實：使用者根本不在乎你的網站是 RWD 還是 AWD，他們在乎的是打開快不快、找不找得到想要的東西、結帳會不會卡關。把注意力從技術標籤移開，放回這些真正會被感受到的體驗上，往往才是突破排名與轉換瓶頸的起點。

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

1. 先預設 RWD。除非你能在前面那六個診斷問題裡，明確找出三個以上非 AWD 不可的理由，否則就從 RWD 開始。預設值的力量，在於它幫你擋掉九成不必要的精神內耗。
2. 把手機版當主要版本來設計。行動優先是 Google 現在的索引方式。可從手機版開始畫 wireframe，再擴充桌機版，提早發現內容、導覽與互動問題。想從設計工具端就把響應式做好，Figma 響應式設計教學是個好起點；想知道整體網頁設計該注意哪些事，網頁設計從零到一的完整指南能給你全貌。
3. 上線後，持續用 Core Web Vitals 與實際的行動版爬蟲數據回頭檢驗。資料會告訴你當初的選擇對不對，這遠比會議室裡的推測可靠。把每一次檢驗的結論寫下來，半年後回頭看，那就是你團隊最值錢的網站營運資產。

網站這件事，做了比選了重要。與其糾結 AWD 還是 RWD，不如現在就把你的手機打開，用最挑剔的眼光，把你現在的網站從頭到尾滑一遍。那一趟滑下來的真實感受，往往比任何比較表都誠實，也比任何專家的結論都更貼近你自己的答案。決定好了，就動手，別再讓這個選擇變成拖延的另一個漂亮藉口。