行動優先索引（mobile-first indexing）是 Google 改用智慧型手機代理程式（Googlebot Smartphone）抓取並評估你網站的手機版內容，把它當成索引與排名的主要依據。這套機制在 2020 年 9 月大規模啟用、2021 年 3 月全面落實（來源：Google Search Central）。講白了，Google 只看你的手機版長怎樣，電腦版做得多漂亮都只是輔助參考。改了手機版之後，通常要等 7 到 28 天才會逐步反映在檢索與排名訊號上，因為爬蟲有重新檢索排程、檢索預算、伺服器回應速度與 robots/noindex 指令四道關卡要過。換句話說，你的手機版內容跟電腦版有任何落差，Google 能看到的就只是那個殘缺版本。
TL;DR：行動優先索引代表 Google 用手機版幫你打分數，全球行動裝置搜尋流量早已超過六成；改完手機版要等 7 到 28 天才生效，超過一個月沒動就回頭查 robots.txt、noindex、canonical 與檢索狀態，這四個是延遲最常見的兇手。
文章目錄
行動優先是什麼：Google 為什麼戴起手機眼鏡
行動優先索引，顧名思義就是 Google 把手機版內容當成索引與排名的主要依據，對應的爬蟲是 Googlebot 智慧型手機。在這套機制啟用之前，Google 是用電腦版優先，手機版只是補充；2016 年 Google 開始試行，到 2020 年 9 月大規模啟用、2021 年 3 月正式全面落實（來源：Google Search Central 官方時間線）。從那天起，電腦版就退居輔助參考的位置。
用白話說，Google 戴上了一副「手機眼鏡」，從此用這副眼鏡看你的網站。你在 Chrome 桌面看到的精緻排版、完整內容、流暢動畫，只要手機版沒有呈現出來，Google 就當作沒看到。很多人以為問題出在工具不夠好，其實問題出在方向：你一直在雕電腦版，卻沒發現評分官早就換了視角。
為什麼 Google 要這樣改
原因很直接：使用者早就用行動裝置搜尋為主。全球行動裝置的網路使用比例早已超過六成（來源：Statcounter 全球趨勢），台灣的行動搜尋市占也長期偏高。當多數使用者都從手機進來，Google 自然要把評分標準對齊多數人的體驗，而不是少數桌面使用者的體驗。這也順便呼應了 網頁體驗排名訊號背後的邏輯。
講白了，Google 不再相信你在電腦上做得多漂亮，它只相信它在手機眼鏡裡實際看到的那個版本。這就是為什麼行動版內容優先會成為這幾年排名變動的隱形推手。
行動優先索引 vs 傳統索引的關鍵差異
| 比較項目 | 傳統索引（電腦版優先） | 行動優先索引（手機版優先） |
|---|---|---|
| 檢索器 | Googlebot 電腦版 | Googlebot 智慧型手機 |
| 主要評分依據 | 電腦版內容與結構 | 手機版內容與結構 |
| 內容落差的影響 | 不明顯 | 手機版缺的等於不存在 |
| 資源封鎖容忍度 | 較高 | 極低，CSS/JS 被擋即無法正確渲染 |
這張表想表達的重點只有一句：以前缺一塊還可以靠電腦版撐，現在缺一塊就直接從評分裡扣掉。如果你還在把On-Page 最佳化的主力放在桌面版本，等於把八成的心力花在 Google 已經不太參考的那一版。
為什麼會延遲：改了手機版卻還是沒生效的 4 個原因
slug 叫 delay，但很多人改完手機版後等不到結果，就開始懷疑自己改錯了。其實延遲多半不是你改錯，而是 Google 還沒輪到重新檢索你。行動優先索引的更新不會即時反映，延遲通常來自四個地方：Googlebot 還沒重新檢索該頁、網站整體檢索預算不足、伺服器回應慢導致檢索被降速、以及 robots.txt 或 noindex 等指令讓爬蟲拿不到新內容。多數情況下等 7 到 28 天會逐步生效，超過一個月沒動就要回頭查指令或檢索狀態。
原因一：重新檢索排程
Google 不是每次都立刻回頭抓你的頁面。熱門、權重高、更新頻繁的頁面較快被重新檢索，冷門或低權重的頁面可能要數週甚至更久才輪到。你按了發布鍵，不等於 Google 那一秒就收到。去 Google Search Console 的網址檢查工具看「上次檢取時間」，就能知道 Google 還停留在哪個版本。
原因二：檢索預算（crawl budget）
檢索預算決定 Google 一次願意花多少時間在你網站上。大站頁面太多排不完，低權重小站則是被分配到的額度很少，兩種情況都會讓新內容排隊等很久。實務上，技術 SEO 常見疏漏裡最常被忽略的就是浪費檢索預算在低價值頁面上，把預算留給真正重要的頁面，更新才會快。
原因三：伺服器回應速度
當伺服器回應過慢（TTFB 偏高），Googlebot 會主動降速，減少同時連線數來保護你的伺服器，於是檢取就更慢。我會建議把網站速度當成延遲問題的第一道排查，因為它同時影響使用者體驗與 Google 的檢取意願。網站速度的影響不是傳說，頁面速度確實會影響 SEO。
原因四：指令把新內容擋掉了
這裡要小心。我碰過客戶改完等了三週急得跳腳，結果是 robots.txt 把整個資料夾封了；也碰過 noindex 設了忘記拿掉，或 轉址把頁面導去舊版本。這類指令錯誤很常見，也是延遲查不出來時最該優先懷疑的目標。把網站重新收錄要多久這個問題拆開來看，指令阻擋通常是最容易自爆的那一環。
查指令的工具是 GSC 的網址檢查工具，看「檢索狀態」與「上次檢取時間」兩個欄位。狀態顯示「已排除」或「已檢索但未建立索引」，多半就是指令或內容價值的問題，不是延遲。
內容一致性：手機版不是精簡版，是完整版
不行，手機版內容不能比電腦版少。在行動優先索引下，手機版缺少的內容等於不存在。Google 只會根據手機版實際出現的文字、連結、結構化資料來評估你，所以把產品規格、使用者評論、FAQ 折疊或砍掉，等於自動讓 Google 看不到這些排名訊號。正確做法是內容對等性（content parity）：手機版與電腦版的核心內容、標題、結構化資料、內部連結必須一致。
常見的「精簡」錯誤
很多站長為了「手機比較好讀」，會把手機版的產品規格表、長篇說明、評論區整段拿掉，只留標題與圖片。這在桌面時代沒事，現在等於自己把排名訊號刪光。你覺得手機使用者不需要看規格？他們結帳前最需要的就是規格，內容、體驗與排名三者本來就綁在一起。
折疊式（accordion）內容仍會被索引，這點不用擔心。Google 明確說過，用 details/summary 或 tab 切換把內容收起來，爬蟲仍會展開並索引。真正會出事的是「完全移除」，例如用 CSS display:none 搭配媒體查詢把手機版的整段刪掉，這種做法在桌面看不出來，但爬蟲渲染後就是少了一段。
折疊內容與完全移除的差別
| 做法 | 是否被索引 | 建議 |
|---|---|---|
| Accordion 折疊 | 是，仍會渲染 | 可用於次要資訊 |
| CSS 隱藏 display:none | 視情況，可能被忽略 | 避免用於核心內容 |
| 整段從 HTML 移除 | 否，等於不存在 | 絕對不要這樣做 |
| 動態載入且爬蟲觸發不了 | 否，看不到 | 改用相容做法 |
正確做法是用 RWD 回應式設計，讓同一份內容在不同尺寸下重新排列，而不是把內容砍掉。內部連結的數量與錨點也要兩版一致，內部連結是 Google 理解網站結構的重要訊號，手機版少一條就少一條投票權。這也牽動你的On-Page 內容最佳化策略。
技術 Roadblock：你是不是不小心擋住了 Googlebot
網站看起來正常，不代表 Google 看起來正常。最常見的無形阻擋是 robots.txt 封鎖了 CSS、JavaScript 或圖片資源，導致 Googlebot 無法正確渲染頁面，只能看到一堆沒有排版的純文字；再來是伺服器對 Googlebot 智慧型手機回應 403 或 5xx、過度使用延遲載入把主要內容藏起來、以及行動版與電腦版用了不同網址卻沒有正確的 canonical 與 alternate 標註。這些問題你在 Chrome 裡完全看不出來，得用 Googlebot 視角才能發現。
robots.txt 封鎖 CSS 與 JS 的致命傷
這裡要小心。很多工程師為了擋爬蟲，把整個 wp-includes、/assets、/js 資料夾都封了，結果連 Google 一起擋掉。當 Googlebot 拿不到 CSS 與 JS，它就沒辦法渲染出排版後的畫面，會誤判你的頁面體驗極差，連帶把Core Web Vitals相關的分數打下去。一條錯誤的 重複內容處理或 robots 規則，賠掉的可能是一整個分類的排名。
伺服器對 Googlebot Smartphone 回 403
有些主機或 WAF 會把沒見過的 User-Agent 當成壞爬蟲擋掉，特別是 Googlebot 智慧型手機這個較新的身分。症狀是電腦版正常、手機版你自己看也正常，但 GSC 一直顯示檢取失敗。處理方式是放行 Google 的 IP 範圍與官方 User-Agent 字串，這部分可以參考 GSC 顯示已索引但無內容的排查流程。
延遲載入把首屏主要內容吃掉
lazy-load 如果實作不當，會把首屏該出現的文字或圖片藏到捲動才觸發，爬蟲滑不到就結束，等於那段內容沒被索引。這在AMP 已經不再重要、大家改回原生的年代反而更常見，因為很多人把 lazy-load 當成萬用加速方案，沒想到它同時是內容的黑洞。後面會專門講怎麼做對。
m. 子網域的 canonical 與 alternate 標註
如果你用的是獨立手機網址（例如 m.example.com），就必須在兩版之間正確標註 rel=canonical 與 rel=alternate，否則 Google 會把兩版當成重複內容，甚至索引錯版本。這部分的操作可以對照技術 SEO的標準做法，少一條標註就可能讓你的手機版被判成抄襲來源。
檢查方法只有一個：GSC 網址檢查工具的「檢視已渲染頁面」。那個畫面顯示的，才是 Googlebot 實際看到的內容，不是你瀏覽器裡的那個。兩邊對不起來，問題就找到了。
圖片與影片：手機版不是次等公民
需要特別處理，手機版圖片不該用解析度極低或尺寸過小的縮圖，否則很可能不被收進 Google 圖片搜尋，等於白白丟掉流量來源；影片要避免 Flash 這類手機不支援的格式；每一張圖都要有描述性的 alt 替代文字，這是 Google 理解圖片內容、也是 AI 搜尋引用時的關鍵訊號。手機版的視覺資源跟電腦版同等重要，不是能省就省。
圖片品質與格式
別為了手機螢幕就用低解析縮圖，Google 不會收劣質圖。壓縮可以，但要在視覺品質與檔案大小之間取平衡，這部分遵循Google 圖片最佳實踐。影片格式則禁用 Flash，並遵循Google 影片最佳實踐。
alt 替代文字的正確與錯誤範例
| 圖片情境 | 錯誤 alt（沒資訊量） | 正確 alt（描述性） |
|---|---|---|
| 產品外觀圖 | image01 | 銀色無線耳機，附收納盒 |
| 步驟截圖 | 截圖 | GSC 設定頁面的檢索器欄位 |
| 資料圖表 | 圖表 | 2020 至 2024 行動搜尋占比趨勢圖 |
有人 alt 只寫 image01，這跟沒寫一樣。alt 是給 Google 看的、也是給螢幕閱讀器與網站可及性用的，不是塞關鍵字的地方。正確寫法在什麼是 alt 替代文字有完整教學，核心原則是「描述這張圖在傳達什麼」。
聰明載入：延遲載入 Lazy-loading 做對了嗎
Lazy-loading 本身沒問題，問題出在實作方式。如果用的是跟 Googlebot 不相容的 JavaScript 延遲載入，爬蟲滑不到頁面下方就結束，會錯過大部分內容；正確做法是遵循Google 官方延遲載入指南，讓搜尋引擎能在不捲動的情況下正確觸發並索引內容。簡單的判斷法：到 GSC 網址檢查看渲染後的畫面，如果該出現的圖片沒出現，就是 lazy-load 出問題了。
原生 loading=lazy 是最安全的選擇
實話說，這部分要工程師配合，行銷人自己改不動。但你可以要求工程團隊優先採用瀏覽器原生的 loading=”lazy” 屬性，這個寫法 Googlebot 完全支援，不會有觸發不了的問題。需要更複雜的延遲策略時，再回頭參考官方指南。這對PageSpeed Insights與 WordPress 站的Site Kit監測都有正面影響。
折疊會被索引，lazy-load 失敗不會
這是兩件容易被搞混的事。折疊內容（display:none 的 tab、accordion）Google 會主動展開並索引；lazy-load 失敗的內容則是爬蟲根本沒拿到，自然不會被索引。如果你發現某頁明明有很多圖片，但 圖片搜尋或GSC裡都看不到，第一個該懷疑的就是 lazy-load。
官方認證：用 GSC 確認你的網站到底有沒有被行動優先索引
登入 Google Search Console，到「設定」>；「關於」，在「檢索」這一欄看你的網站主要是由「Googlebot 智慧型手機」還是「Googlebot 電腦版」進行檢索；對絕大多數網站來說，這裡應該顯示為智慧型手機版。如果想看單一頁面的狀態，用「網址檢查」工具輸入網址，在「檢索」區塊也能看到檢索器類型與上次檢取時間。這是判斷你有沒有被行動優先索引的最直接官方證據。
正常與異常狀態怎麼判讀
| 狀態 | GSC 顯示 | 意義與處置 |
|---|---|---|
| 正常 | Googlebot 智慧型手機 | 已進入行動優先索引 |
| 異常 | 仍顯示 Googlebot 電腦版 | 網站可能缺乏可用手機版，回頭檢查 RWD 與資源 |
| 啟用通知 | 收件匣收到啟用訊息 | Google 主動告知切換時間點 |
| 單頁查詢 | 網址檢查顯示檢索器與時間 | 判斷該頁是否已被重新檢取 |
別用感覺判斷，直接打開 GSC 看，30 秒就有答案。如果你對 GSC 還不熟，先從免費 Google SEO 工具與Google SEO 入門指南建立基本概念，再回來看檢取器欄位會更踏實。也可以搭配web.dev 工具交叉驗證渲染結果。
常見錯誤清單：8 個讓你排名無聲下滑的陷阱
行動版最常拖垮排名的八個錯誤是：插頁式廣告擋住首屏、CLS 累計版面位移過高、INP 互動延遲過長、按鈕與連結太小導致誤觸、字型在手機上太小讀不下去、結構化資料在兩版不一致、m. 子網域的重複內容沒處理、以及把電腦版專屬功能直接搬到手機造成壞掉的體驗。這些都會被 Google 的網頁體驗訊號與行動裝置可用性報告捕捉到，直接反映在排名上。
插頁式廣告與 CLS 的雙重傷害
最冤的是插頁廣告。你以為是轉換利器，其實同時在扣你的排名分。全螢幕彈窗會觸發 Google 的插頁式廣告政策（來源：Google Search Central interstitial 政策），同時推高 CLS，一次扣兩種分。改用非侵入式橫幅或延後到使用者互動後再顯示，是比較安全的做法。這也呼應Google 對彈窗廣告的懲罰。
INP 取代 FID，手機互動延遲直接扣分
2024 年起，INP（Interaction to Next Paint）正式取代 FID 成為 Core Web Vitals 的互動指標（來源：web.dev）。手機上的互動延遲超標會直接反映在網頁體驗分數上。如果你還在用舊的 FID 思維做排名因素最佳化，等於用了過期的標準。
觸控目標、字型與結構化資料一致性
| 錯誤項目 | 影響 | 修正方向 |
|---|---|---|
| 按鈕小於 48px | 誤觸、可用性報告標記 | 放大觸控目標 |
| 字型小於 16px | 閱讀體驗差、跳出率升 | 調整為可讀尺寸 |
| Schema 兩版不一致 | Rich Result 失效 | 確保結構化資料對等 |
| 電腦版功能搬到手機壞掉 | 互動報錯、體驗崩潰 | 重新設計行動互動 |
結構化資料在兩版不一致是非常隱形的坑，例如手機版缺了 FAQ Schema 或 Product Schema，結構化資料對應的Rich Result就會失效。Schema 與meta description、標題標籤一樣，都該在兩版維持一致。
2026 AI 搜尋調整：AI Overview 與語音搜尋時代的手機版新要求
2026 年 Google AI Overview 已經出現在接近半數的查詢裡（來源：2026 年第三方 SEO 觀測，數字會波動，這裡刻意不寫死），而行動裝置正是 AI 搜尋與語音搜尋的主戰場；這意味著你的手機版不只是給傳統排名用，還要能被 AI 擷取成答案。具體新要求是：開頭段落要直答問題（AI 會擷取前 100 到 150 字）、結構化資料要齊全（FAQ Schema、Article Schema）、頁面體驗訊號（Core Web Vitals 含 INP）要過，並且因為語音搜尋多半來自手機，口語化、能直接被唸出來的答案更容易被選用。
AI Overview 的擷取偏好
AI Overview 偏好開頭直答的段落，這也是為什麼這篇文章開頭就是一段 100 多字的直接回答。如果你的手機版第一段還在寒暄或寫導言，AI 根本不會選用你。這跟Google AI Overview與AI 搜尋 SEO的運作邏輯一致，也牽動生成式 AI 搜尋與Google AI Mode的引用機會。
語音搜尋與口語化答案
語音搜尋多半來自手機與智慧音箱，答案要口語、能直接被唸出來。長句、書面語、夾雜英文縮寫的答案，被選用的機率低很多。這不代表你要寫得像在跟朋友聊天，而是句子要短、結構要清楚、能用一句話回答的就用一句話。這個概念跟語音搜尋取代文字搜尋的趨勢、以及Google Assistant的設計方向是相通的。
AI 不會取代基本功
別為了追 AI 搜尋就把基本功丟了，沒有好的手機版當底，AI 根本不會來抓你。AEO 與 GEO 是建立在 SEO 之上的，不是取代。你可以把GEO、AISO 策略、用 AI 增加 SEO 流量當成加分題，但基礎的行動版、SEO 基礎、Core Web Vitals（若有對應文章）永遠是先決條件。
30 分鐘排錯流程：照著跑一遍，找出你的致命問題
有，這條流程可以照著跑。依序做這四步：第一步到 GSC 設定確認檢取器是 Googlebot 智慧型手機；第二步用網址檢查工具「檢視已渲染頁面」，比對 Googlebot 看到的畫面跟你 Chrome 看到的有沒有落差；第三步檢查 robots.txt 有沒有封鎖 CSS/JS/圖片，以及有沒有 noindex 或錯誤 canonical；第四步對照常見錯誤清單逐項確認插頁廣告、CLS、INP、結構化資料一致性。跑完這四步，八成的行動優先索引問題都能定位出來。
Step 1：確認檢取器類型
開 GSC，設定 > 關於 > 檢取，看是不是 Googlebot 智慧型手機。如果還是電腦版，代表你的網站可能被判定為沒有可用手機版，先回頭修 RWD 與資源可及性。這一步只要 5 分鐘。
Step 2：比對渲染畫面
挑 3 到 5 個重點頁面，逐頁用網址檢查工具看「檢視已渲染頁面」。重點看：圖片有沒有出現、文字段落齊不齊、排版有沒有崩。跟你自己 Chrome 開手機模擬看到的畫面比對，落差最大的那一頁就是第一優先修。這是Site Kit by Google與 PageSpeed Insights 之外最直接的渲染驗證。
Step 3：檢查指令
打開 robots.txt，確認沒有擋掉 /wp-content、/assets、.css、.js。再用網址檢查看有沒有 noindex、canonical 指向錯誤、或 alternate 缺漏。這部分可以對照http 到 https、非英文網址、站內連結等常見設定問題一起檢。
Step 4：逐項對照 8 大錯誤
把前面那張 8 大錯誤表拿出來，逐項勾選。不用一次全修，先抓會直接吃掉內容的那種，像是 robots 封鎖、noindex、lazy-load 失敗。修完觀察 7 到 28 天，再用 GSC 確認檢取狀態變化。如果你的問題比較偏向整體網站架構或要不要做 SEO的層次，那就不是 30 分鐘能解決的，要排進季度計畫。
FAQ：行動優先索引最常被問的 7 個問題
我一定要做手機版嗎？
要。行動裝置搜尋流量早已過半，不做等於放棄多數使用者。就算你的網站現在勉強能在手機上開，只要體驗差，Google 的行動裝置可用性報告一樣會標記你，這跟 Google 行動裝置友善警告是同一條線的問題。
用 RWD 就等於過關嗎？
不一定。RWD 解決版面，不解決內容與資源可及性。很多 RWD 網站還是會在內容被 JS 動態隱藏、lazy-load 吃掉、結構化資料沒同步這些地方出包。RWD 是入場券，不是免死金牌，建議先看過行動裝置演算法再回頭檢查。
改完手機版多久會生效？
通常 7 到 28 天。超過一個月沒動就回頭查 robots.txt、noindex、canonical 與檢取狀態。如果你的網站權重低、檢取預算少，可能要更久，這時可以主動用網址檢查工具請求重新檢取。
排名突然掉了是不是手機版的問題？
不一定，要先看 GSC 的行動可用性報告與檢取狀態。排名掉的成因很多，可能是核心更新復原期、可能是垃圾內容更新、也可能是對手內容變強。手機版只是其中一個變數，別直覺歸因。
沒有手機版會怎樣？
Google 仍會檢取，但體驗評分差，排名與 AI 引用都受影響。沒有手機版的網站會被當成低優先，AI Overview 與語音搜尋也幾乎不會選用你。長期來看，等於把整個行動生態的流量讓給對手。
獨立手機網址（m.）跟 RWD 哪個好？
多數情況 RWD 較省事，獨立網址風險高。獨立手機網址要處理 rel=canonical、rel=alternate、重複內容、維護成本，一個沒設好就出事。除非你有非常明確的行動版技術需求，否則 RWD 是比較安全的選擇。
AI 搜尋會不會取代行動優先索引？
不會。行動版仍是 AI 擷取的底層來源。AI Overview、語音搜尋、Google AI Search 都是從你的手機版抓內容，再重新組織成答案。基礎沒顧好，AI 引用無從發生。
結論：先修正最影響判斷的訊號，再談 AI
回到搜尋意圖。會搜「行動優先索引延遲」的人，多半是排名或流量掉了，懷疑手機版出問題，卻不知道怎麼確認。這篇文章給你的不是一句「把手機版做好」，而是一條可照做的流程：先用 GSC 確認檢取器、再用渲染畫面比對、再查指令、收尾對照 8 大錯誤清單。
優先順序只有一個原則：先修會直接吃掉內容的問題。robots.txt 封鎖、noindex、lazy-load 失敗這種會讓 Google 看不到內容的，先解；插頁廣告、CLS、INP 這種影響體驗分數的，再修；AI 搜尋調整、語音口語化這種加分題，留到最終階段再做。順序顛倒，你會花一堆時間在次要問題上，真正的致命傷還在原地。
修完之後，觀察 7 到 28 天再做下一步，別每天盯排名自己嚇自己。如果你照著跑完四步還是找不出問題，那通常代表瓶頸不在行動優先索引，而在更上層的整體 SEO 策略或最近的核心更新，那是另一篇文章的範圍了。
想更系統性地把網站的行動版與 SEO 體質一次調好，可以從SEO 入門與Google SEO 對照表開始建立檢查習慣。手機版不是配角，它是 Google 現在打分數的主場，把它顧好，傳統排名與 AI 搜尋才會一起跟上。
