行動網站設計怎麼做：拇指熱區、Mobile-First Indexing與Core Web Vitals

作者｜晨星行銷　陳俊鳴執行長（網路流量操盤手・企業行銷顧問）

台灣網路資訊中心（TWNIC）2025年的調查顯示，台灣的行動上網率已經來到87.12%。這代表多數企業網站的第一個訪客畫面，不是在27吋螢幕上打開的，而是在一支握在手掌裡、隨時可能被中斷的手機上打開的。

但「有手機版」跟「手機版設計得好」是兩件事。多數網站已經解決了第一個問題——畫面會自動依螢幕寬度縮放，文字不會爆版，圖片不會超出邊界。真正被忽略的是第二個問題：版面縮放之後，這個網站是不是真的被重新設計過，還是只是把桌機版的東西，用比較小的字重新排了一次。

這篇要講的，就是第二個問題。如果你現在正在決定「該用RWD、AWD還是獨立手機版」，那是技術選型階段的問題，不是這篇要處理的範圍。這篇假設你已經有一個能在手機上正常顯示的網站，現在要問的是：它的行動版體驗，是不是真的照著行動裝置的使用方式設計過？我們會從三個角度拆開來看：人怎麼用（UX設計方法）、Google怎麼看（Mobile-First Indexing的技術要求）、機器怎麼測（Core Web Vitals行動版指標）。

為什麼「打得開」不代表「設計對了」

想像一下，你在捷運上滑手機找一家店的電話。網站打開了，畫面也沒有跑版，但你要滑三次螢幕才找到聯絡資訊，按鈕小到點了兩次才點中，跳出來的表單還有八個欄位要填——多半直接放棄，改用Google地圖打電話算了。

這種情況業界有個講法叫「表面響應式」：網站確實會依螢幕尺寸縮放版面，但只做到「畫面能顯示」這個最低標準，實際上手機版的資訊順序、重要按鈕位置、表單欄位安排，都沒有真的重新想過，只是把桌機版的內容硬塞進小螢幕。使用者雖然打得開網站，操作起來仍然卡卡的，最終還是會影響停留時間與轉換率。

真正的行動網站設計，要處理三個層次的問題：使用者的手指怎麼移動（拇指熱區）、內容出現的順序對不對（資訊架構）、以及Google拿什麼標準在評估你的網站（Mobile-First Indexing與Core Web Vitals）。接下來一項一項拆開講。

拇指熱區：手機版按鈕該放在哪，不是憑感覺

先講一個很直覺、但很多網站沒做到的觀念：大多數人是用單手拿手機、用拇指操作的，而拇指能舒服伸到的範圍，是螢幕下半部偏中間的位置；螢幕最上方那一塊，反而是拇指最難自然伸到的死角。這也是為什麼設計得好的App（外送平台是最典型的例子），重要的操作按鈕——加入購物車、送出訂單、撥打電話——幾乎都放在畫面下方，而不是塞在頁首。

這個概念叫「拇指熱區」（thumb zone），不是憑感覺講出來的說法。國際UX研究機構Nielsen Norman Group的眼動追蹤實測顯示：使用者在拇指自然能伸到的熱區內點擊，準確率高達96%；同樣的按鈕如果放在需要伸展手指才碰得到的區域，準確率只剩61%，操作反應時間也明顯拉長。換句話說，同一個按鈕，放對位置跟放錯位置，使用者點得中、點不中的機率差了三分之一以上。

這不是美感問題，是操作問題。如果你的網站把「立即諮詢」或「加入購物車」這種關鍵按鈕放在頁面最上方或側邊角落，使用者要嘛要換手拿手機、要嘛要用另一手去點，多一個動作，就多一次放棄的機會。

除了位置，按鈕本身的大小也有明確的規格可以查，不是設計師憑感覺決定。目前業界同時存在三套常被提到的標準，很多文章會把它們混在一起講，但其實各自代表不同層級：

三個熱區標準，分別在管什麼

標準	最小點擊目標	性質
WCAG 2.2（Target Size條款）	24×24 CSS像素	國際無障礙法定門檻，歐盟《歐洲無障礙法案》（EAA）2025年6月28日起強制生效
Apple人機介面指南	44×44 pt	業界最佳實務建議，非法規
Google Material Design	48×48 dp	業界最佳實務建議，非法規

WCAG 2.2的24×24像素是「法定底線」，Apple與Google的44/48是「業界建議值」，兩者不是互相矛盾的規則，是兩個不同層級——前者是「至少不能小於這個數字」，後者是「做到這個數字，使用起來才真的舒服」。實務上直接照Apple、Google的建議做，自然就會超過WCAG的法定門檻。（表格裡的CSS像素、pt、dp是三套系統各自的度量單位，不用糾結怎麼換算，記得一個原則就好：按鈕大小落在這個等級，一般成年人的手指一次就點得到。）

熱區配置的具體做法，是把「撥打電話」「立即諮詢」「加入購物車」這類會直接影響成交的按鈕，固定或優先安排在螢幕下半部，並且跟旁邊的元素之間留出至少一定的間距，避免手指大一點的使用者誤觸旁邊的連結。至於頁首，適合放的是Logo、選單這類「查閱型」而非「操作型」的元件。

資訊架構要重新排序，不是把桌機內容硬塞進小螢幕

桌機螢幕寬，可以左右並排放很多資訊，讀者一眼掃過去就能看到重點、次要資訊、聯絡方式全部同時出現。手機螢幕窄，同樣的內容只能上下堆疊，這代表一件事：排在越前面的內容，讀者看到的機率越高；排在越後面的，很可能根本沒被滑到就離開了。

常見的情況是，網站改版時只處理了「畫面會不會跑版」，卻沒有回頭問一次：「如果讀者只滑三秒鐘就走，要先讓他看到什麼？」結果桌機版原本並排呈現的服務介紹、案例、聯絡表單，到了手機版變成一長串要一路往下滑的內容，讀者要嘛沒耐心滑到重點，要嘛滑到一半就放棄了。

真正的行動版資訊架構，需要重新排一次優先順序，而不是照搬桌機版的順序縮小字體。實務上可以分兩層問自己：

第一層，先問頁面目的：這個頁面存在是為了什麼——是要讓人聯絡你、讓人了解某項服務、還是讓人讀懂一篇文章？目的不同，該優先出現的內容就不一樣，聯絡導向的頁面要優先露出聯絡方式，知識型文章頁則要優先露出讀者搜尋時真正想要的答案。

第二層，再問內容的緊急度：把頁面上所有內容依「讀者現在需不需要看到」分成三類——現在就要看到的（能不能解決我的問題、怎麼聯絡你）、之後想看再看的（案例、更多細節）、其實可以收進次頁的（公司沿革、團隊介紹、得獎紀錄）。行動版排版順序，就照這個緊急度由上到下排。

舉例來說，一個服務型網站的手機版首頁，比起把公司沿革、團隊介紹放在最上面，通常更值得把「你能解決什麼問題」跟「怎麼聯絡你」排在讀者滑進來的前幾秒就看得到的位置——沿革與團隊介紹當然重要，但它們適合的位置是讀者已經產生興趣、往下滑做進一步了解的階段，不是第一眼。

行動優先表單設計：每多一個欄位，都是在勸退使用者

表單是行動版體驗裡最容易被忽略、卻直接影響成交的一塊。手機螢幕小，打字比桌機慢、也更容易分心——走路、搭車、排隊時填表單的情況並不少見，每多一個欄位，都是多一次讓人放棄填寫的機會。

業界的實測數據很直接：拿掉一個非必要的欄位（例如選填的電話號碼），表單完成率可以提升將近八成。這不是誇張的行銷數字，而是因為每個欄位對使用者來說都是一次額外的決定成本——要不要填、填什麼格式、會不會被拿去打推銷電話——欄位越多，猶豫的機會就越多。

行動優先的表單設計，幾個具體可以做的地方：

• 欄位只留必要的：先問自己「沒有這欄資料，真的沒辦法跟進這個名單嗎」，答案是否定的就拿掉。
• 用對輸入類型：電話欄位用數字鍵盤、Email欄位用@符號鍵盤，讓手機自動跳出對應的輸入介面，減少使用者切換鍵盤的麻煩，同時也能啟用瀏覽器的自動填入功能。
• 標籤放在欄位上方，不要只放在欄位裡面當提示文字：提示文字（placeholder）一旦使用者開始輸入就會消失，如果填到一半被打斷、回頭看不到這欄原本要填什麼，反而容易填錯或放棄。
• 單欄直式排列，不要左右並排：手機螢幕窄，並排欄位容易讓人搞不清楚填寫順序，單欄由上到下最直覺。

這些調整看起來瑣碎，但表單往往是行動版網站上「使用者願意留下聯絡方式」的最後一道關卡，這道關卡設計得好不好，直接反映在名單數量上。

Google怎麼看你的行動版：Mobile-First Indexing在檢查什麼

前面講的是「人怎麼用」，接下來要講「Google怎麼看」。Google從2024年開始，已經對全部網站採用一套叫「Mobile-First Indexing」（行動優先索引）的機制，簡單講就是：Google抓取與判讀你網站內容時，用的是手機版的內容，不是桌機版。也就是說，你的網站在搜尋結果裡排到第幾名、內容有沒有被Google正確理解，判斷依據是手機版呈現的樣子。

這件事帶來一個很容易被忽略的技術要求：行動版跟桌機版的內容必須對等。Google官方文件明確列出對等性檢查的範圍，包括文字內容、圖片、影片、內部連結、結構化資料（Schema），以及meta資訊（標題、描述、robots標籤）。Google Search Central官方部落格對結構化資料這一項講得特別明確：如果桌機版網站有結構化資料，行動版也必須要有相同的結構化資料——這不是「建議」，是Mobile-First Indexing底下的技術要求，少了會讓Google在判讀你網站內容時，完全讀不到桌機版才有的那部分資訊。

如果你的手機版為了畫面簡潔，拿掉了桌機版才有的某段文字、某些連結，或是精簡了結構化資料，Google判讀你網站主題與內容深度時，看到的就會是那個「被精簡過」的版本，這對排名不是加分。

實務上比較常出現問題的地方：

• 為了手機版畫面乾淨，把某些段落或FAQ內容做成「展開才看得到」的收合區塊——這本身沒問題，只要收合的內容在HTML裡確實存在，Google還是讀得到；真正的問題是有些做法會用JavaScript動態載入才顯示，導致抓取時內容根本不存在。
• 手機版圖片沒有alt文字，或圖片乾脆被整個拿掉來換取版面簡潔。
• 手機版的結構化資料（例如FAQ Schema、文章Schema）沒有跟桌機版同步更新。

判斷方式很直接：打開你網站的手機版，逐項比對桌機版有的內容，手機版是不是也都在——不是「看起來差不多」，是「內容真的都在」。

那份大家還在教的GSC提示，其實已經下架了

講到驗收行動版體驗，很多文章還在建議讀者「去Google Search Console查看行動裝置可用性報表，有沒有出現警示」。這個建議在幾年前是對的，但這份「行動裝置可用性報表」（Mobile Usability report），連同「行動裝置相容性測試」工具與API，已經在2023年12月正式從Search Console下架。

Google官方給的理由是：行動裝置友善程度已經能從其他報表（特別是Core Web Vitals報表）反映出來，加上業界已經有更完整的工具可以做這類檢查，例如Chrome內建的Lighthouse。換句話說，這不是Google放棄了行動版驗收，而是把驗收方式整併進了別的工具。

如果你現在打開Search Console想找那份報表，會發現它已經不在選單裡了。這時候正確的驗收方式改成：

1. 用PageSpeed Insights或Lighthouse單獨測試行動版分數，這兩個工具目前都還在，而且會直接模擬手機裝置的載入與互動情況。
2. 用Search Console裡仍然保留的Core Web Vitals報表，看真實使用者在你網站上的行動版表現數據——不是模擬測試，是實際訪客的數據。

這個小細節值得特別提出來講，是因為它反映了一個更大的原則：行動版體驗的驗收工具本身也會隨時間更新，用幾年前記下來的檢查清單，可能會指向一個已經不存在的地方。

Core Web Vitals行動版三個數字：LCP、INP、CLS各自在測什麼

前面講的是「Google怎麼看內容」，這一段講「Google怎麼測速度與體驗」。Core Web Vitals是Google用來評估網頁載入速度、互動反應與畫面穩定度的三個核心指標，而且目前Google在計算網站排名參考的分數時，是以行動版的表現為主要依據。

指標	全名	測的是什麼	「良好」門檻
LCP	Largest Contentful Paint	頁面最大可視內容（通常是首屏大圖或標題區塊）出現的速度	2.5秒以內
INP	Interaction to Next Paint	使用者點擊、輸入等互動後，畫面回應的速度	200毫秒以內
CLS	Cumulative Layout Shift	頁面載入過程中，版面有沒有無預警跳動	0.1以內

翻成生活感受：LCP 2.5秒，大概是你滑開網頁、眨兩下眼睛的時間；INP 200毫秒，是手指點下去幾乎感覺不到延遲、畫面「秒回」的等級；CLS 0.1，代表頁面載入時版面幾乎不會亂跳動，你正準備點的按鈕不會忽然被擠到別的地方去。這三個門檻不是用單次測速工具跑出來的分數，而是用「75百分位」的真實訪客資料——Google稱為CrUX資料集——去評估，意思是至少75%造訪你網站的使用者，實際體驗到的速度要落在這個門檻以內，你的網站才會被判定為「良好」。這也是為什麼同一個網站，用測速工具測一次可能是綠燈，但Search Console報表卻顯示「需要改善」——因為報表看的是真實使用者的分佈，不是單一次的模擬結果。

INP取代FID是什麼時候的事

如果你在幾年前研究過Core Web Vitals，可能會記得當時的互動指標叫FID（First Input Delay，首次輸入延遲）。Google在2024年3月正式把INP列為Core Web Vitals的正式指標，取代了FID。兩者的差別在於：FID只測「使用者第一次點擊」的反應速度，INP則是追蹤整個瀏覽過程中所有互動的反應速度，取其中表現較差的那次來評分——這代表INP反映的是使用者從頭到尾操作網站的真實感受，不只是第一印象。

行動版特別容易在INP這一項吃虧，因為手機的運算能力通常比桌機弱，如果網站載入了太多、太重的JavaScript，使用者點擊按鈕後，畫面回應延遲的情況會比桌機版明顯得多。

圖片延遲載入，行動版最容易做錯的一步

圖片延遲載入（lazy loading）本身是好東西——它讓瀏覽器先不載入使用者還沒滑到的圖片，減少一開始要下載的資料量，理論上應該對速度有幫助。但這裡有一個反直覺的細節，很多網站在行動版上做錯了：如果把首屏內就看得到的那張圖片（通常也就是決定LCP分數的那張圖）也套用了延遲載入，反而會拖慢LCP分數，因為瀏覽器要先執行判斷邏輯才決定要不要載入這張圖，等於多繞了一圈才開始下載本來應該最優先出現的內容。

正確的做法是分開處理：

• 首屏內看得到的圖片（通常是精選圖片、首屏大圖）：不套用延遲載入，讓瀏覽器盡快下載，需要的話還可以加上優先載入的屬性，讓它比其他資源更早開始下載。
• 首屏以下、要滑動才看得到的圖片：套用延遲載入，這才是延遲載入真正該發揮作用的地方。
• 每張圖片都設定好寬高比例：讓瀏覽器在圖片真正下載完成前，先預留好版面空間，避免圖片跳出來時把下面的文字一起往下推，這也是CLS分數會不好看的常見原因之一。

這幾個細節單獨看都不大，但行動版網速與運算能力天生比桌機吃緊，這些「小」的技術決定，加總起來就是使用者感受到的「快不快」。如果想針對網站速度做更完整、不只限於行動版的排查，可以參考網站速度測試的完整流程、指標與拖慢原因。

FAQ

行動網站設計要顧的東西，說到底是同一件事：讓一個用拇指、在移動中、耐心有限的人，能順利在你的網站上找到他要的東西、完成他想做的動作。拇指熱區、資訊架構、Mobile-First Indexing、Core Web Vitals，這些聽起來是技術規格，但背後對應的都是使用者實際的操作感受——這也是為什麼把它們一起顧到，往往比單獨追求某一個測速分數更重要。行動版設計如果需要更完整的診斷與調整，可以找以此為專業的人一起把細節盤點過一輪。