行動優先索引：為什麼 Google 排名時，主要看你的手機版

Google 主要依手機版內容與體驗理解頁面。整理內容對等、viewport、圖片、互動區與 LCP／INP／CLS 的檢查方式。

這不是什麼新聞。Google 早在 2016 年就開始測試，2018 年逐步推行，2023 年 10 月宣布大致完成，最後一批網站在 2024 年 7 月 5 日切換完畢。到今天，幾乎百分之百的網站都吃這一套，沒有例外、也回不去了。所以你要是還抱著「桌機版才是主場、手機版順便做做」的心態，方向從根本上就反了。這篇我想把背後的機制、Google 真正在量什麼、以及該怎麼判斷，一次替你講清楚。

為什麼 Google 要「改看手機」

技術上，Google 派出的爬蟲叫 Googlebot，如今主力是「smartphone」版本，它模擬的是一支 Android 手機上的 Chrome 瀏覽器，用手機的螢幕尺寸、手機的網路條件去讀你的頁面。更關鍵的是，Google 已經明講：所有的索引與排名訊號，現在都來自這隻手機爬蟲的抓取結果。也就是說，桌機爬蟲雖然還在，但它對你的排名幾乎不再有發言權。你的排名命運，就掌握在「手機版被讀到了什麼」這一件事上。

真正的重點是「內容對等」

行動優先索引最要命、也最常被忽略的一點，叫做「內容對等（parity）」。意思很直接：只有出現在你手機版裡的內容，才算數。桌機版有、手機版沒有的東西，對 Google 而言形同不存在。

我們實際遇過一個高雄的客戶，當初為了讓手機版「看起來清爽」，把一整段重要的服務說明、還有好幾個內部連結，在手機版藏了起來——不是折疊收起，而是直接不輸出。結果呢？Google 主要讀手機版，等於這些內容跟連結對排名完全沒貢獻，等於白寫。這裡要特別分清楚兩種「藏」，因為結果天差地別：

用折疊選單、頁籤把內容收起來，但原始碼裡還在：這種沒問題。爬蟲會把整份 HTML 讀進去，內容在視覺上有沒有「展開」它並不在乎，只要在文件裡就讀得到、也算數。
手機版根本沒輸出這段內容，或要靠使用者點擊才用 JavaScript 現場載入：這種很危險。前者是內容真的不在，後者是爬蟲不一定會替你去觸發那個點擊、也就抓不到。這才是真正的「白寫」。

這也是為什麼我們做網站一律走 RWD 響應式設計，而不是另外架一個「閹割版」的手機站。RWD 的精神是「一份內容、一份原始碼，自動適應不同螢幕」。桌機、手機讀到的是同一份 HTML，只是排版隨螢幕變化，根本不會出現「兩個版本內容不一致」的裂縫。相對地，早年流行的獨立手機站（那種另外開一個 m 開頭網址的做法），維護時很容易兩邊走鐘：一邊改了、另一邊忘了改，久了內容、結構化資料、標題描述全對不上，正是行動優先索引時代的大地雷。

「核心網頁指標」到底在量什麼

光是內容對等還不夠。Google 還會用一組叫「核心網頁指標（Core Web Vitals）」的東西，來衡量訪客在你頁面上的真實體驗，而且量的主要就是「手機上的感受」。目前是三項，每一項背後都有很實在的物理意義，不是只能憑感覺判斷，值得逐一拆給你看。

LCP：最大內容繪製（載入夠不夠快）

LCP 量的是頁面上「最大那塊主要內容」（通常是主視覺大圖或標題區塊）畫出來、讓人覺得「東西終於出來了」所花的時間，Google 訂的「良好」門檻是 2.5 秒以內。這 2.5 秒裡塞著一連串物理過程：手機發出請求、伺服器回應、檔案透過行動網路一路傳回來、瀏覽器再解析並繪製。任何一環拖慢——伺服器慢、圖片太肥、擋路的腳本卡住——LCP 就爛。手機吃虧的地方在於，行動網路的延遲天生就比家裡的光纖高，所以同一個頁面，手機的 LCP 往往比桌機難看。

INP：互動到下次繪製（反應夠不夠靈敏）

INP 是 2024 年 3 月 12 日正式上路的新指標，取代了舊的 FID。它量的是：你每一次點擊、每一次按按鈕、每一次敲鍵盤，從「手指按下去」到「畫面真的有反應」之間隔了多久，良好門檻是 200 毫秒以內。跟舊的 FID 只量「第一次互動、而且只量開頭那一小段延遲」不同，INP 會盯著你整個瀏覽過程裡的所有互動，抓出最差的那些來代表整頁的靈敏度，嚴格得多。

INP 之所以在手機上特別容易破功，原因很物理：一次互動的延遲由三段組成——瀏覽器排隊處理事件的「輸入延遲」、實際跑你那些 JavaScript 的「處理延遲」、以及把結果畫上螢幕的「呈現延遲」。手機的 CPU 運算能力普遍遠不如桌機，同一段肥大的 JavaScript，在桌機上一眨眼就跑完，在中低階手機上可能卡個大半秒，主執行緒被塞住，使用者這時點什麼都沒反應。腳本塞越多，手機越慘。

CLS：累計版面位移（畫面穩不穩）

CLS 量的是「畫面亂跳」的程度，良好門檻是 0.1 以下。你一定遇過：正要按一個按鈕，結果上面突然插進一張慢半拍載入的圖或廣告，整個版面往下一擠，手指就按到別的地方去了。那種惱人的位移，就是 CLS 在抓的。成因幾乎都是「元素沒有事先預留空間」——圖片沒寫寬高、字型晚到重排、內容非同步才塞進來。手機螢幕窄，一點點位移的視覺衝擊就被放大，所以 CLS 在手機上更要顧。

這些分數，是「真人在手機上跑出來的」

搜尋平台不公開固定權重，也沒有能套用所有產業的流量或轉換增幅。以 Search Console、商家檔案與實際詢問紀錄建立基準，一次調整一個項目，再比較查詢、曝光、點擊與有效詢問，會比引用沒有原始資料的平均值可靠。

速度不是只能憑感覺判斷，是實實在在的錢

Google 主要使用行動版內容建立索引，所以手機版不能省略桌機版的重要文字、內鏈、圖片替代文字或結構化資料。驗收時直接比對兩個版面的主要內容與 canonical，而不是引用沒有查核日期的行動流量比例。

該怎麼查、怎麼判斷：一套工程準則

講完機制，給你一套可以實際照做的判斷準則，從最簡單、到比較技術，依序排下來：

先用你自己的手機，當一個陌生人走一遍：拿手機打開網站，從「找服務→看內容→按下聯絡」實際跑一次流程。哪裡卡、哪裡看不清、哪裡點不到，通常一試就現形。這是零成本、卻最有感的第一步。
字級不要小於 16px：這不只是好不好讀的問題。手機瀏覽器一碰到小於 16px 的表單欄位，會自動放大整個畫面，版面當場被撐爛，使用者還得手動縮回去，體驗很糟。16px 是安全底線。
可點的東西至少 48×48 像素、彼此留 8 像素以上間距：這個數字不是隨便訂的——48 像素大約等於 9 毫米，正好是一根手指指腹的接觸面積。按鈕太小、擠太近，就會按錯、按不到，尤其對手指較粗或手不太穩的使用者更不友善。
圖片壓成新世代格式（例如 WebP）、依螢幕給對尺寸：手機不需要載入桌機那張好幾 MB 的巨圖。針對手機出小圖，是改善 LCP 最直接的一刀。
延遲載入要用對地方：把「首屏看不到」的圖延後載入是對的；但千萬別對「首屏那張主視覺（也就是 LCP 元素）」也套延遲載入——那等於叫瀏覽器晚一點才去抓最重要的那張圖，LCP 直接被你自己搞爛。這是很常見的自殘，值得特別提醒。
幫圖片、廣告位事先寫好寬高、預留空間：這樣晚到的元素就不會把版面擠開，CLS 自然穩。
把擋路的 JavaScript 延後或拆小：別讓主執行緒被一大包腳本卡死，INP 才有救。手機 CPU 弱，這一條在手機上的收益最大。

幾個常見誤區

「我的網站是 RWD，所以一定沒問題」：RWD 只保證「內容對等、排版自適應」，並不保證「快」。響應式的網站照樣可以慢到爆、INP 照樣可以很糟。對等是及格線，速度是另一張完全不同的考卷。
「桌機版把內容做齊就好，手機版精簡一點沒差」：完全相反。手機版才是主場，該做齊的是手機版——結構化資料、標題、描述、內文，手機版一項都不能少。
「在辦公室測起來很快啊」：那是實驗室資料。Google 看的是你真實客戶、在真實手機與網路下跑出來的第 75 百分位表現。辦公室的 Wi-Fi 騙不了它。