Mobilegeddon 是 Google 在 2015 年 4 月 21 日推出的行動裝置友善演算法更新，核心邏輯是當使用者用手機搜尋時，Google 會優先呈現「在手機上看得清楚、操作順手」的頁面。這項更新有三個經典特徵：只影響行動搜尋排名、影響全球所有語言、以單一頁面為評估單位。雖然 Mobilegeddon 已是多年前的更新，它仍是 Google 邁向「手機優先（Mobile-First）」時代的分水嶺，後續的 Mobile-First Indexing、Page Experience 與 Core Web Vitals 都可視為這條路線的延伸。在 AI 搜尋時代，使用者透過 ChatGPT、Perplexity、Google AI Overviews 與 Bing Copilot 找答案，而這些 AI 搜尋系統的底層資料來源，大多仍是 Google 以手機版內容建立的索引。理解 Mobilegeddon 的演進脈絡，等於掌握了現代行動 SEO 與 AEO 的基礎。本篇文章適合網站經營者、SEO 從業者、行銷人員與企業主閱讀。
- Mobilegeddon 是什麼？Google 行動友善更新的核心
- Google 為什麼要推出 Mobilegeddon？
- Mobilegeddon 如何判斷網站是否行動友善？
- Mobilegeddon 對 SEO 的四大實際影響
- Mobilegeddon 與 Mobile-First Indexing 有什麼差別？
- 從 Mobilegeddon 到 Core Web Vitals：行動 SEO 的演進
- 現在該怎麼檢查網站是否行動友善？
- 行動 SEO 優化：七個實務做法
- 常見的行動 SEO 錯誤
- Mobilegeddon 與 AEO：AI 搜尋時代的行動體驗
- 結論：行動體驗已是搜尋的基礎題
- 常見問答 FAQ
Mobilegeddon 是什麼？Google 行動友善更新的核心
Mobilegeddon 是業界對 Google「行動裝置友善更新（Mobile-Friendly Update）」的暱稱，指的是 Google 在 2015 年 4 月 21 日正式上線的搜尋排名調整。它的核心邏輯很明確：當使用者用手機搜尋時，Google 會更偏好顯示在行動裝置上具有良好可讀性與可操作性的頁面。
換句話說，手機體驗良好的頁面更容易在行動搜尋中取得優勢，只為桌機設計、手機體驗差的頁面則會逐漸失去競爭力。
Mobilegeddon 是 Google 搜尋從「桌機優先」邁向「手機優先」的歷史分水嶺。
Mobilegeddon 的三大特徵
這項更新有三個經典特徵，理解這些特徵有助於分辨它與後續更新的差異：
Google 當時在官方部落格表示，這次更新會對全球行動搜尋結果產生顯著影響。當時許多依賴搜尋流量的中小企業在更新後流量大幅變動，「Mobilegeddon」這個帶有「Armageddon（末日）」意味的暱稱也因此誕生。
它象徵的不只是一次演算法調整，而是 Google 對網站期待的全面轉變。從此之後，手機體驗不再是加分題，而是進入搜尋競爭的門檻。
Google 為什麼要推出 Mobilegeddon？
Google 推出 Mobilegeddon 的根本原因，是手機搜尋已超越桌機，成為主要的搜尋來源。當時全球行動搜尋量首次超過桌機搜尋，但大量網站仍停留在「桌機優先」的設計思維：字太小、版面跑版、按鈕難按、左右滑來滑去。這種體驗落差讓 Google 不得不採取行動。
三個推動 Mobilegeddon 的關鍵背景
-
行動裝置已成為主要上網工具
智慧型手機普及帶動行動搜尋量爆發，但網站體驗未跟上，導致使用者搜尋滿意度下降。Google 必須回應這個結構性轉變，否則競爭對手會逐步搶走行動搜尋市場。
2015 年初，Google 官方公告全球已有超過 10 個國家的行動搜尋量超越桌機，台灣也在其中。但同時段只有約 60% 的網站具備手機版設計。
-
使用者體驗成為搜尋品質的核心
Google 搜尋的價值是「幫使用者找到能用、能讀、能解決問題的內容」。若搜尋結果導向的頁面在手機上無法正常使用，即使內容再相關，使用者體驗仍然是失敗的。
當時常見情況是使用者搜尋「附近的咖啡店」，點進結果頁卻看到桌機版地圖被擠到一邊、電話號碼太小無法點擊，只好回上一頁重新搜尋。這就是 Google 想解決的痛點。
-
推動網站設計標準的轉變
Google 是搜尋的事實標準，當它把行動友善納入排名訊號，等於用市場力量推動整個網站產業朝「響應式設計」轉型。這也是 Mobilegeddon 之所以成為分水嶺的原因：它不只影響排名，還重塑了網站設計產業的方向。
此後 WordPress、Shopify、Wix 等主流建站平台全面預設響應式模板；台灣的網站設計公司也紛紛把「手機版」從報價單上的選配，改為標準配備。
Mobilegeddon 如何判斷網站是否行動友善？
Mobilegeddon 判斷的核心不是「網站有沒有手機版網址」，而是「頁面在手機上是否真的好用」。Google 官方說法是會優先考量在手機上 legible and usable（看得清楚、操作順手）的頁面。具體可拆解為四個判斷面向：
-
文字是否容易閱讀
使用者進到頁面後，不應該需要主動放大兩次才看得懂內容。行動版頁面應讓使用者在預設縮放比例下，就能清楚閱讀標題、內文與按鈕文字。這涉及字級、行高、段落留白與版面寬度的整體配置。
手機版內文字級建議 15 至 16px、行高 1.6 至 1.8、段落間距至少 1em。低於 14px 的小字在手機上閱讀壓力會明顯偏高。
-
內容是否能適應手機螢幕
若頁面超出螢幕寬度，迫使使用者左右滑動才能讀完一行，Google 不會認為這是理想的行動體驗。採用「響應式設計（Responsive Web Design）」能讓相同內容在手機、平板、桌機上維持合理的閱讀體驗。
使用 CSS Media Query 與 viewport meta 標籤，讓版面隨螢幕寬度自動調整。常見斷點：768px（平板）、480px（手機）、375px（小型手機）。
-
按鈕與連結是否容易點擊
手機操作不是用滑鼠，而是手指。Mobilegeddon 重視
tap targets是否足夠大、是否有適當間距。CTA 太小、連結太密、表單欄位太擠，使用者很容易誤觸。Google 建議的最小可點擊區域為 48×48 像素，且連結之間應有至少 8px 的間距。低於這個標準會被視為 tap targets 過小。 -
是否使用不適合手機的技術
早期 Flash 是經典案例，因為 iOS 完全不支援。雖然 Flash 已退場，但相同原則仍然適用：若網站使用阻礙渲染、互動不佳或無法在手機正常顯示的技術，都可能損害行動體驗評分。
現代常見問題包括：過度依賴 hover 效果（手機沒有 hover）、大型未壓縮影片自動播放、過多 JavaScript 阻塞渲染、字型載入過慢導致 FOUT 或 FOIT。
Mobilegeddon 對 SEO 的四大實際影響
Mobilegeddon 對 SEO 的影響可歸納為四個層面：行動排名變動、思維轉變、內容策略調整，以及網站設計產業重塑。這四點至今仍持續發酵，並深刻影響今日的 SEO 實務。
| 影響層面 | 當年的衝擊 | 在 AI 搜尋時代的延續 |
|---|---|---|
| 行動排名 | 未優化手機版的頁面在行動搜尋大幅下滑 | 演進為 Mobile-First Indexing，影響整體可見度 |
| SEO 思維 | 從「桌機優先」轉向「手機優先」 | 進一步發展為「使用者體驗優先」的整體觀 |
| 內容策略 | 內容需考慮手機閱讀的字級與長度 | 內容需同時對應 AI 摘要與行動使用者 |
| 網站設計 | 響應式設計成為產業標準 | Core Web Vitals 成為設計時的必要考量 |
Mobilegeddon 與 Mobile-First Indexing 有什麼差別？
Mobilegeddon 與 Mobile-First Indexing 經常被混為一談，但其實是兩件不同的事。前者是「排名訊號」，後者是「索引方式」。理解差異，才能準確判斷現在該做什麼。
| 比較項目 | Mobilegeddon | Mobile-First Indexing |
|---|---|---|
| 推出時間 | 2015 年 4 月上線 | 2018 年起分批推進，2023 年 10 月全面完成 |
| 性質 | 排名訊號 | 索引機制 |
| 核心邏輯 | 手機體驗納入排名考量 | 主要以手機版內容建立索引 |
| 影響範圍 | 只影響行動搜尋排名 | 影響所有搜尋（含桌機）的排名依據 |
| 內容一致性要求 | 不強制要求 | 手機版與桌機版內容必須一致 |
| 當前狀態 | 已整合進整體頁面體驗訊號 | 已成為所有網站的預設索引方式 |
為什麼 Mobile-First Indexing 更關鍵？
Google Search Central 明確指出，目前 Google 使用 smartphone Googlebot 抓取的手機版內容作為索引與排名依據，這項轉換在 2023 年 10 月已全面完成。這代表什麼？
代表如果您的手機版內容比桌機版精簡，例如折掉重要段落、隱藏 FAQ、縮減內部連結、移除圖片 alt 文字，Google 看到的世界就比您想像的小很多。這也是現代 SEO 中極常見、卻最容易被忽略的盲點。
從 Mobilegeddon 到 Core Web Vitals：行動 SEO 的演進
從 Mobilegeddon 到 Core Web Vitals，Google 對行動體驗的要求一路加深。理解這條演進線，才能掌握當前 SEO 的真正方向。
四個階段層層遞進：Mobilegeddon 解決「手機能不能用」，Mobile-First Indexing 解決「Google 看誰的版本」，Page Experience 解決「整體體驗訊號」，Core Web Vitals 則用具體指標量化體驗品質。每個階段都不是取代，而是疊加。
四個階段的對應重點
| 階段 | 推出時間 | 核心要求 |
|---|---|---|
| Mobilegeddon | 2015 年 | 頁面在手機上能正常閱讀與操作 |
| Mobile-First Indexing | 2018 至 2023 年 | 手機版內容與桌機版完整一致 |
| Page Experience | 2021 年 | 整合 HTTPS、無干擾廣告、無侵入式插頁 |
| Core Web Vitals | 2020 年起持續演進 | 具體量化 LCP、INP、CLS 三大體驗指標 |
Core Web Vitals 三大指標
-
LCP（Largest Contentful Paint，最大內容繪製）
衡量主要內容的載入速度，目標應在 2.5 秒內。LCP 通常被首屏主視覺圖、大型標題或主要段落拖累。
優化方向：首屏圖片使用 WebP 或 AVIF 格式、加上 fetchpriority 高優先權屬性、避免對首屏圖片使用懶載入。
-
INP（Interaction to Next Paint，互動到下次繪製）
已正式取代舊有的 FID 指標，衡量互動反應速度，目標應在 200 毫秒內。INP 反映使用者點擊、輸入、捲動時的整體流暢度。
優化方向：減少主執行緒阻塞、拆分長任務、延後非關鍵 JavaScript、善用 requestIdleCallback 安排低優先權工作。
-
CLS（Cumulative Layout Shift，累積版面位移）
衡量版面穩定度，目標應在 0.1 以下。CLS 通常被未指定尺寸的圖片、字型載入跳動、廣告插入時的版面跳動所拖累。
優化方向：所有圖片標籤指定寬高、字型使用 font-display 的 swap 策略並預先載入、廣告區塊預留固定高度。
現在該怎麼檢查網站是否行動友善？
檢查行動友善的工具已大幅變動：Google 已在 2023 年 12 月 1 日退休 Mobile-Friendly Test、Mobile-Friendly Test API，以及 Search Console 的 Mobile Usability 報表。這不代表行動體驗不重要，而是 Google 認為應該從「整體頁面體驗」角度檢視，而非依賴單一工具評分。
目前推薦的三個檢查工具
-
PageSpeed Insights
從手機維度查看載入效能與 Core Web Vitals 表現。適合快速辨識 LCP、INP、CLS 等問題，並提供具體優化建議。資料同時包含「實驗室資料」（Lighthouse 模擬）與「真實使用者資料」（CrUX）兩種來源。
使用網址 pagespeed.web.dev，輸入頁面網址後切換到「行動裝置」分頁查看詳細數據。
-
Lighthouse
Chrome 內建的頁面體檢工具，可從效能、可存取性、最佳化建議、基礎 SEO 四個面向給予評分。雖然不是排名工具，但對發現手機版問題極有幫助。
使用方式：開啟 Chrome DevTools 後切到 Lighthouse 分頁，選擇 Mobile 再生成報告。建議定期對核心流量頁執行，並追蹤分數變化。
-
Search Console
雖然 Mobile Usability 報表已退休，Search Console 仍是不可取代的工具。Core Web Vitals 報表、網址檢查、索引涵蓋範圍、搜尋成效報表都能協助掌握 Google 如何理解您的頁面。
重點查看：Core Web Vitals 報表（行動裝置）、網址檢查工具（看手機版渲染結果）、索引涵蓋範圍（確認手機版被正確索引）。
行動 SEO 優化：七個實務做法
現在的行動 SEO 優化，核心是「內容一致、速度優先、體驗順暢」。以下七個實務做法，適合台灣中小企業官網、電商網站與品牌部落格採用：
- 優先採用響應式網頁設計（RWD）：同一份 HTML 自動適應不同螢幕，避免手機版與桌機版內容斷裂。Google 長期建議站長以 RWD 作為首選方案。
- 確保手機版內容完整，不要瘦身：許多網站把手機版重要段落折掉、FAQ 隱藏、內部連結縮減，這對 Mobile-First Indexing 極不友善。Google 看到什麼就排什麼。
- 圖片優化是 LCP 的第一關：使用 WebP 或 AVIF 格式、依顯示尺寸提供 srcset、首屏圖提高載入優先權。圖片往往是手機速度的最大瓶頸。
- 字級至少 15 至 16px，行高 1.6 至 1.8：手機版內文不可沿用桌機比例，需獨立調整。小於 14px 在手機上會明顯造成閱讀壓力。
- CTA 按鈕至少 48×48 像素，間距至少 8px：這是 Google 建議的最小可點擊區域。重要 CTA 應該獨立放置，周圍留有足夠空白。
- 避免侵入式插頁廣告（Intrusive Interstitials）：一打開頁面就跳全螢幕表單、訂閱框或蓋版廣告，這些都會被 Google 標記為負面訊號。
- 結構化資料（Schema）同步部署於手機版：FAQ、麵包屑、商品、文章 Schema 在手機版必須完整保留，這影響搜尋摘要呈現與 AI 引擎引用機率。
常見的行動 SEO 錯誤
許多網站經營者誤解行動 SEO 的本質，導致優化方向偏差。以下是六個最常見的錯誤，並搭配具體改善方向：
- 把手機版當成桌機版的精簡版 為了畫面清爽，把 FAQ、規格表、相關文章等折掉或刪除，結果手機版內容比桌機版少三成到五成。改善方式：內容一致是 Mobile-First Indexing 的基本要求，排版可以調整，但內容不能砍。
- 使用 m. 子網域且兩版不同步 手機版與桌機版採用不同的內容管理系統，導致兩版更新不同步、缺少 canonical 或 alternate 對應。改善方式：建議直接遷移至響應式設計；若必須維持獨立手機版架構，須確保兩版內容、Schema、連結完全一致。
- 忽略 Core Web Vitals，只看 PageSpeed 分數 PageSpeed 分數只是參考，真實使用者體驗資料（CrUX）才是 Google 排名的依據。改善方式：到 Search Console 查看「行動裝置」的 Core Web Vitals 報表，優先處理狀態為「不良」的頁面。
- 手機版字級太小、行距太擠 沿用桌機版的 14px 字級到手機，加上 1.4 的行高，造成閱讀壓力極高。改善方式：手機版內文 15 至 16px、行高 1.6 至 1.8 是合理區間，文章型網站可考慮 17 至 18px。
- 過度使用蓋版彈窗 進站立刻跳訂閱、登入或優惠彈窗，使用者還沒看到內容就被打斷。改善方式：Google 頁面體驗指引明確要求避免侵入式插頁。彈窗可以使用，但應在使用者閱讀一段時間後出現，且必須容易關閉。
- 圖片未指定尺寸，造成 CLS 飆高 圖片標籤沒有寬高屬性，瀏覽器載入時版面跳動，使用者容易誤觸按鈕。改善方式：所有圖片都明確指定尺寸，或使用 aspect-ratio 屬性；字型載入採用 swap 策略並預先載入。
Mobilegeddon 與 AEO：AI 搜尋時代的行動體驗
現在的 SEO 已演進為 SEO 與 AEO（Answer Engine Optimization，答案引擎優化）雙軌策略，而行動體驗在 AEO 中扮演了意想不到的關鍵角色。許多人以為 AI 搜尋引擎只看內容文字，其實它們在抓取與引用判斷上，也會受到行動體驗的間接影響。
AI 引擎引用的內容，大多來自 Google 以手機版建立的索引。手機版做不好，連被 AI 引用的入場券都拿不到。
行動體驗如何影響 AEO 表現？
| 行動 SEO 要素 | 對 SEO 的影響 | 對 AEO 的影響 |
|---|---|---|
| 內容一致性 | 確保 Google 抓到完整內容 | AI 引擎引用的是同一份手機版索引 |
| 頁面載入速度 | 影響排名與使用者跳出率 | 過慢頁面可能被 AI 爬蟲跳過 |
| 結構化資料 | 協助搜尋摘要呈現 | AI 引擎偏好引用有 Schema 的內容 |
| FAQ 區塊 | 對應長尾查詢與精選摘要 | 問答結構是 AI 引擎最容易引用的形式 |
| 清楚的標題層級 | 讓 Google 理解內容結構 | AI 摘要時容易抓對重點段落 |
結論：行動體驗已是搜尋的基礎題
Mobilegeddon 是 Google 搜尋演算法走向「手機優先」的重要起點，它改變的不只是排名規則，更重塑了網站設計與 SEO 的基本邏輯。網站不能只在桌機上看起來正常，而必須在手機上同樣清楚、順手、快速、完整。
Google 後續完成 Mobile-First Indexing，並持續以 Page Experience 與 Core Web Vitals 深化這條路線，說明行動體驗早已不是附加題，而是基礎題。
如果想檢視網站的行動 SEO 健康度，可以從以下五個問題自我檢查：
- 您的網站在手機上是否讀得順、點得準、載得快、版面穩？
- 您的手機版內容是否與桌機版完整一致，沒有刪減 FAQ、內部連結或結構化資料？
- 您的 Core Web Vitals（LCP、INP、CLS）在 Search Console 是否顯示為「良好」？
- 您的網站是否避免使用侵入式插頁廣告與蓋版彈窗？
- 您的網站是否在所有重要頁面（首頁、產品頁、文章頁）都做了行動優化，而不只有首頁？
