Google Search Console 行動裝置可用性問題怎麼判斷與修復

GSC 行動裝置可用性問題是什麼？2026 年還看得到嗎？

2026 年已不能依賴舊的 GSC 行動裝置可用性報表；遇到舊通知或截圖時，應改用 URL Inspection、Lighthouse、Core Web Vitals 與手機實機檢查確認問題。

Google 已在 2023 年 12 月 1 日退役 Search Console 的 Mobile Usability report、Mobile-Friendly Test 與 Mobile-Friendly Test API。這不代表手機版體驗不重要，只代表舊報表不再是主要判斷工具。我的判斷是：看到「google search console 行動裝置可用性」相關問題時，第一步不是找舊報表在哪裡，而是確認那個問題今天是否仍存在。

Google 已退役行動裝置可用性報表，這代表什麼？

這代表你不能再用舊的 Mobile Usability report 追蹤「文字太小」、「可點擊元素太近」、「內容超出螢幕」這類問題的批次狀態。舊通知、舊截圖、客戶月報裡留下的錯誤名稱仍有參考價值，但 2026 年的修復流程要重新校準。

可對照 Google Search Central 的 Page Experience 更新說明，以及已標示退役的 Mobile-Friendly Test 公告。

為什麼仍然要修手機版可用性問題？

報表退役不等於手機版體驗不重要。台灣多數搜尋情境都會發生在手機上，若使用者必須放大文字、左右滑動、誤點按鈕，內容再好也會被體驗拖累。

手機版可用性不應被包裝成單一排名保證，但它確實會影響閱讀完成率、互動率、表單送出、購物車流程與使用者對網站的信任。這類問題通常不是 SEO 文案能解決，而是版型、CSS、JavaScript 或載入資源要修。

現在應改用哪些工具確認？

現行做法是用多個工具交叉確認，不再等單一 GSC 報表給答案。URL Inspection 用來看 Google 對單一 URL 的已知狀態，Lighthouse 與 DevTools 用來找前端問題，Core Web Vitals 用來觀察真實使用者體驗，最後用手機實機確認可讀、可點、可操作。

工具	主要用途	適合判斷	限制
URL Inspection	檢查單一 URL 在 Google 端的狀態	是否已被 Google 抓取、是否有已知問題、是否需要要求重新索引	不是完整的行動版體驗測試
Lighthouse	檢查行動版效能、可及性與前端問題	版面、互動、載入與前端實作線索	實驗室測試結果，需搭配實機檢查
Core Web Vitals	觀察真實使用者體驗指標	LCP、INP、CLS 等體驗問題	不能單獨代表所有手機版可用性
手機實機檢查	直接檢查使用者看到的畫面	文字是否可讀、按鈕是否好點、內容是否溢出	需測多種螢幕尺寸與瀏覽器

先判斷問題嚴重性：單頁、版型，還是全站？

先判斷影響範圍，再排修復順序；單頁問題可局部修，同版型大量 URL 出錯要改範本，全站問題通常要工程介入。

這段解決的是優先順序決策。GSC 手機版問題修復最怕一開始就逐頁改，最後修了十幾頁才發現真正壞的是共用版型。比較務實的做法，是把受影響 URL 依頁面類型、流量價值、轉換價值與錯誤型態分組。

只影響一篇文章時怎麼處理

只影響單一文章時，先檢查該頁是否有特殊內容元件，例如表格、嵌入影片、廣告區塊、程式碼區塊、外部 iframe 或過寬圖片。這類問題通常不是全站 RWD 壞掉，而是內容區某個元素沒有手機版樣式。

我的經驗是，單頁手機版錯誤常出在表格與嵌入物件。修法可以是讓表格橫向捲動、圖片加上最大寬度、iframe 設定響應式比例，或移除固定寬度。

同一版型大量 URL 出問題時怎麼處理

如果同一類文章、分類頁、產品頁或工具頁大量出現相同問題，要優先檢查共用範本。這時逐頁手改只會留下後續維護風險，因為下一次新增頁面仍會複製同樣問題。

工程端應檢查 header、導覽列、文章容器、側欄、CTA 區塊、表格樣式與廣告版位。只要錯誤跟版型共用元件有關，修一個範本通常比修多個 URL 更有效。

高流量頁與低流量頁的優先順序

先處理高曝光、高點擊、高轉換或品牌入口頁。低流量頁不是不用修，而是可以排在範本修復與重要頁面之後。

情境	嚴重性	建議處理	判斷依據
單一低流量文章出錯	低到中	記錄後排程修復	曝光、點擊、商業價值都低
高流量文章出錯	中到高	優先修該 URL 並要求重新索引	已有搜尋流量與使用者影響
同版型多頁出錯	高	修共用範本後抽樣驗證	問題會重複擴散
全站導覽或主要容器出錯	最高	工程立即介入	影響所有手機使用者

標準修復流程：從確認問題到重新驗證

標準流程是先用 URL Inspection 確認單一頁面，再用手機尺寸重現，接著用 Lighthouse 或 DevTools 定位根因，修完後重新測試與記錄。

這段解決的是工程執行順序。不要只憑 GSC 舊訊息就改 CSS，也不要只看桌機畫面判斷已修好。行動版問題必須能被重現、能被定位、能被驗證，否則很容易變成「看起來有改，但 Googlebot 下次抓到什麼沒人知道」。

步驟 1：用 URL Inspection 檢查單一頁面

先把完整 URL 貼進 Search Console 上方的 URL Inspection。Google 說明文件指出，這個工具會顯示 Google 對特定頁面的已知資訊，也能測試即時版本是否符合部分 Google 搜尋顯示需求。

檢查時要看三件事：目前索引狀態、上次抓取時間、即時測試結果。若上次抓取時間早於修復時間，Google 端看到的仍可能是舊版本。

步驟 2：用手機尺寸重現問題

接著用 Chrome DevTools 切到常見手機尺寸，並用真機開啟同一 URL。只看模擬器不夠，因為字體渲染、瀏覽器工具列高度、觸控區域與實際網路狀態，都可能讓問題在真機上更明顯。

檢查重點包括：是否需要左右滑動、按鈕是否容易誤點、導覽是否遮住內容、表格是否破版、廣告或彈窗是否壓住主要內容。

步驟 3：用 Lighthouse 或 DevTools 找版面問題

用 Lighthouse 跑行動版測試，再用 DevTools 查看元素寬度、CSS 規則、JavaScript 錯誤與載入資源。若畫面超出螢幕，通常可以從固定寬度、絕對定位、未換行文字、過寬圖片或第三方嵌入元件找到線索。

這裡不要只追分數。Lighthouse 分數可以幫你排序問題，但真正要修的是使用者在手機上遇到的具體阻礙。

步驟 4：修復後重新測試與記錄

修完後先清快取，再重跑 URL Inspection 的即時測試、Lighthouse 與實機檢查。若重要頁面已確認修復，可以使用 Request indexing 通知 Google 該頁已更新。

Google 的 URL Inspection 說明也提醒，索引資料會在 Google 重新抓取與索引後更新；即時測試資料本身不會直接成為搜尋結果使用的資料。因此紀錄修復日期與上次抓取時間很重要。

1. 確認問題 URL 與錯誤型態。
2. 用 URL Inspection 查看 Google 已知狀態。
3. 用手機尺寸與真機重現問題。
4. 用 Lighthouse、DevTools 找根因。
5. 修 CSS、版型、JavaScript 或資源載入設定。
6. 部署後重新測試。
7. 重要頁面要求重新索引。
8. 把修復日期、驗證結果與待觀察指標寫入追蹤表。

常見行動裝置可用性錯誤與修法

常見錯誤可轉成五類工程任務：文字尺寸、點擊間距、內容寬度、viewport 設定，以及 CSS、JavaScript 或圖片資源造成的渲染異常。

這段解決的是錯誤訊息到修法的轉換。舊 GSC 問題名稱往往很短，但真正根因可能在版型、元件、第三方腳本或內容編輯習慣。只改單一 CSS 屬性有時有效，有時只是把問題推到另一個尺寸。

文字太小，無法閱讀

先檢查 body、文章段落、註解、表格、導覽與按鈕的字級。手機版正文通常不應依賴使用者手動放大才能閱讀，尤其是法規、醫療、金融、教學類內容，字太小會直接削弱信任感。

常見修法是設定合理的基礎字級、行高與段落間距，避免在手機斷點把文字縮得太小，也避免把重要資訊塞進圖片。

可點擊元素太靠近

先檢查導覽列、分頁、篩選器、社群分享按鈕、表單欄位與頁尾連結。手機使用者用手指操作，若按鈕間距太小，誤點率會升高。

修法包括增加 touch target 尺寸、拉開上下左右間距、減少同一列的連結數量，或在手機版改成下拉選單與分段控制。

內容寬度超出螢幕

先找出造成水平捲動的元素。最常見根因是固定寬度容器、過寬表格、沒有 max-width 的圖片、長網址、程式碼區塊、iframe 或廣告版位。

我的判斷是，內容超出螢幕比字小更常被忽略，因為桌機預覽看不出來，手機上卻會讓整篇文章閱讀節奏崩掉。

未設定 viewport

viewport 設定錯誤會讓瀏覽器用不符合手機螢幕的方式縮放頁面。先檢查頁面是否有正確的 viewport meta tag，並確認沒有被外掛、主題或自訂模板覆蓋。

常見設定會使用 width=device-width 與 initial-scale=1。若網站用了多套模板，要抽查首頁、文章頁、分類頁與轉換頁，避免只有部分頁型正確。

CSS、JS 或圖片資源造成行動版渲染異常

如果 Googlebot 或使用者瀏覽器無法正常載入關鍵 CSS、JavaScript 或圖片，行動版畫面可能跟你在後台預覽的版本不同。先檢查資源是否被 robots.txt、權限、CDN、防火牆或錯誤路徑擋住。

JavaScript 產生的導覽、延遲載入圖片、彈窗與互動元件都要特別看。SEO 端看到的是「手機版問題」，工程端要追的是渲染流程。

舊錯誤語言	常見根因	修復層級	建議修法
文字太小，無法閱讀	手機版字級、行高或縮放設定不當	元件或全站 CSS	調整基礎字級、行高、段落間距
可點擊元素太靠近	連結密度過高、按鈕尺寸不足	導覽、表單、頁尾元件	增加觸控區域與元素間距
內容寬度超出螢幕	固定寬度、寬表格、圖片或 iframe 溢出	內容區或版型	使用 max-width、overflow 控制與響應式嵌入
未設定 viewport	模板缺少 viewport meta tag	全站模板	補上正確 viewport 設定並抽查頁型
資源載入異常	CSS、JS、圖片被封鎖或載入失敗	伺服器、CDN、前端資源	檢查 robots.txt、權限、路徑與延遲載入邏輯

修完後怎麼確認 Google 看到的是新版？

修完後要分開看三件事：即時測試是否通過、Googlebot 是否重新抓取、Search Console 資料是否更新；三者時間點不同。

這段解決的是驗證落差。很多團隊會在 Lighthouse 通過後就結案，但 Google 搜尋結果依賴的是 Google 重新抓取與處理後的資料。即時測試通過是必要檢查，卻不是最終成效保證。

即時測試通過不代表報表立刻更新

URL Inspection 的即時測試可以確認目前可抓到的版本是否已修復，但 Search Console 的索引資料來自 Google 先前抓取與索引的結果。若上次抓取時間早於部署時間，GSC 看到的仍是舊頁面。

所以驗證時要同時記錄「部署時間」、「即時測試結果」、「上次抓取時間」。少了時間軸，後續很難判斷是修復沒生效，還是 Google 還沒重新處理。

什麼時候需要要求重新索引

高價值頁面、重要轉換頁、修復幅度大的頁面，可以在即時測試通過後要求重新索引。低價值或大量同版型頁面，則可先確保內部連結與 Sitemap 正常，讓 Googlebot 依正常節奏重新抓取。

不要把 Request indexing 當成批次重送工具。它適合單一重要 URL 的更新通知，不適合拿來彌補全站技術問題。

如何建立修復追蹤表

追蹤表要讓 SEO、工程與主管看同一份狀態。欄位不需要複雜，但要能回答：哪個 URL 出問題、影響範圍多大、誰負責、何時修、何時驗證、接下來觀察什麼。

欄位	填寫方式	用途
URL	填完整網址	避免不同團隊查錯頁面
頁面類型	文章、分類、產品、轉換頁	判斷是否為版型問題
問題類型	文字、點擊、寬度、viewport、資源	分派給正確負責人
修復層級	單頁、元件、範本、全站	避免逐頁手改共用問題
驗證結果	即時測試、Lighthouse、實機檢查	確認修復是否可重現
待觀察指標	曝光、點擊、CTR、轉換、Core Web Vitals	追蹤修復後的搜尋與體驗變化

大量頁面出問題時，先修哪裡？

大量頁面出問題時，先修高價值頁與共用版型；不要把資源花在逐頁微調低影響 URL。

這段解決的是資源分配。當受影響 URL 很多，問題已經不只是技術清單，而是管理決策。先修哪裡，取決於頁面價值、錯誤嚴重性、修復效率與是否會繼續擴散。

優先修高曝光、高點擊、高轉換頁

先從 Search Console 的搜尋成效看曝光與點擊，再加上業務端的轉換價值。若某頁是品牌入口、熱門內容、產品頁、報名頁或詢價頁，手機版問題會直接影響使用者完成目標。

高曝光但低 CTR 的頁面也值得檢查，因為使用者進站後若體驗差，後續互動與品牌印象都會受影響。

優先修共用版型，而不是逐頁手改

同一範本出錯時，先改範本。文章頁、分類頁、產品頁、搜尋結果頁與結帳頁常有各自的共用元件，只要根因在共用容器或元件，修範本才會真正停止問題擴散。

逐頁手改適合內容造成的個案，例如某篇文章插入過寬表格；不適合處理導覽列、頁尾、卡片列表或表單元件的系統性問題。

何時需要請工程師介入

只要問題涉及 CSS 斷點、JavaScript 渲染、伺服器資源、CDN、模板邏輯或第三方元件，就應請工程師介入。SEO 或內容人員可以整理 URL、描述問題、提供截圖與優先順序，但不應在不理解模板邏輯的情況下硬改。

優先級	頁面條件	技術條件	處理策略
第一優先	高曝光、高點擊、高轉換	手機版明顯破版或無法操作	立即修復並重新驗證
第二優先	同版型大量頁面	共用元件造成錯誤	修範本並抽樣檢查
第三優先	中等流量內容頁	局部內容元件異常	排程修復並記錄
第四優先	低流量、低商業價值頁	不影響共用版型	納入例行維護

如何把修復結果寫進 SEO 月報？

SEO 月報應把手機版修復寫成風險、行動、狀態與待觀察指標，不要承諾修完就一定排名上升。

這段解決的是回報方式。主管通常不需要看每個 CSS 屬性，他需要知道問題影響哪些頁面、是否已修、風險是否下降、後續用哪些指標判斷結果。技術修復要被翻成可追蹤的營運語言。

主管需要看的三個重點

第一是影響範圍，包含單頁、版型或全站。第二是修復狀態，包含已修、待驗證、待工程排程。第三是後續觀察，包含曝光、點擊、CTR、轉換與 Core Web Vitals 趨勢。

我的建議是月報不要寫成「已最佳化手機版」。這句太空。應該寫清楚修了哪類問題、哪些頁型受益、還有哪些資料需要等 Google 重新抓取後再觀察。

修復後要追蹤哪些指標

修復後可看 Search Console 的曝光、點擊、CTR、平均排名，也可看轉換頁的表單送出、購物流程完成率或主要互動。Core Web Vitals 則用來觀察體驗是否改善，但不要把它當成唯一成效指標。

若修復的是版型問題，建議抽樣追蹤多個 URL，而不是只看單一頁面。版型修復的價值通常在於降低同類頁面的重複風險。

不要承諾「修完一定排名上升」

行動版體驗改善有助於降低使用者阻礙，也符合 Page Experience 的方向，但搜尋排名還會受到內容品質、查詢意圖、競爭程度、連結、品牌與技術可抓取性等因素影響。

比較穩健的寫法是：本月已完成手機版可用性問題修復，接下來觀察 Google 重新抓取後的搜尋成效與使用者互動變化。

月報欄位	建議寫法	避免寫法
問題摘要	發現部分文章頁在手機版有內容寬度溢出問題	網站手機版 SEO 有問題
處理行動	已修正文章表格與嵌入元件的響應式樣式	已做手機版最佳化
驗證狀態	已通過實機檢查與 URL Inspection 即時測試	已完全解決，排名會提升
後續觀察	等待 Googlebot 重新抓取後，追蹤曝光、點擊與互動趨勢	下月保證流量成長

本文不處理哪些 GSC 問題？

這裡只處理手機版可用性修復，不延伸成完整 GSC 教學、GA4 比較、Sitemap、結構化資料或 AMP 指南。

這段解決的是主題邊界。Google Search Console 能處理很多事情，但手機版問題修復需要保持單一任務，否則很容易從「如何修」變成一篇什麼都講一點的工具導覽。

不是完整 Google Search Console 教學

完整 GSC 教學會包含網站驗證、成效報表、索引狀態、Sitemap、手動處置、移除工具與使用者權限。這些主題重要，但不應混進手機版可用性修復流程。

若目前只是在處理舊的行動裝置可用性通知，先把受影響 URL、版型與修復狀態釐清，比重新學完整個 GSC 更有效。

不是 GA4 與 GSC 比較文

GA4 可看使用者互動、事件與轉換，GSC 可看 Google 搜尋曝光、點擊與抓取索引相關資訊。手機版可用性修復時，GSC 負責搜尋端狀態，GA4 最多用來輔助觀察修復後的互動變化。

不要把 GA4 事件設定當成手機版修復本身。若按鈕太近、內容溢出或 viewport 錯誤，核心仍是前端與版型問題。

不是 Core Web Vitals 完整技術指南

Core Web Vitals 是重要體驗指標，但手機版可用性不只等於 LCP、INP、CLS。文字是否可讀、按鈕是否好點、內容是否超出螢幕、資源是否正常渲染，都要另外檢查。

AMP 也不應被當成必要排名條件。若網站本身的 RWD、載入效能與互動設計可以做好，重點應放在現有頁面體驗與可維護的版型修復。

Google Search Console 的行動裝置可用性報表是不是已經沒有了？

是。Google 已在 2023 年 12 月 1 日退役 Search Console 的 Mobile Usability report、Mobile-Friendly Test 與 Mobile-Friendly Test API。2026 年處理舊通知時，應改用 URL Inspection、Lighthouse、Core Web Vitals 與手機實機檢查。

報表退役後，手機版問題還會影響 Google 搜尋嗎？

手機版體驗仍是 Page Experience 的一部分，但不要理解成「修好就保證排名上升」。它會影響使用者閱讀、互動與轉換，也可能在競爭內容相近時影響搜尋表現。

我收到舊的 GSC 行動裝置可用性通知，現在該看哪裡？

先把通知中的 URL 或錯誤類型整理出來，再用 URL Inspection 檢查單一頁面。接著用手機尺寸、Lighthouse、DevTools 與真機確認問題是否仍存在。

URL Inspection 可以檢查手機版可用性嗎？

URL Inspection 可以檢查 Google 對單一 URL 的已知狀態，也能跑即時測試，但它不是完整的手機版可用性報表。建議搭配 Lighthouse、DevTools 與實機檢查。

Lighthouse 和 GSC 的結果不同，要相信哪一個？

兩者用途不同。GSC 反映 Google 對 URL 的已知狀態與搜尋端資訊，Lighthouse 提供前端與體驗檢查線索。若結果不同，先確認測試時間、測試 URL、裝置模式、快取與部署版本。

修好手機版問題後，GSC 會立刻更新嗎？

不一定。即時測試通過只代表目前版本看起來已修復，GSC 的索引資料仍需等 Googlebot 重新抓取與處理後才會更新。重要頁面可在即時測試通過後要求重新索引。

內容超出螢幕通常是哪裡壞掉？

常見原因是固定寬度容器、過寬表格、圖片沒有 max-width、iframe 未做響應式處理、長網址未換行，或廣告版位超出內容容器。

可點擊元素太靠近要怎麼修？

先找出導覽、按鈕、分頁、表單或頁尾連結中太密集的區塊。修法是增加觸控區域、拉開間距、減少同列連結數量，或在手機版改用更適合手指操作的控制方式。

文字太小會不會直接影響排名？

不要把它當成單一排名因素看。文字太小會影響可讀性、停留、互動與信任感，這些都會讓頁面體驗變差。修復方向是讓手機使用者不用放大也能舒服閱讀。

AMP 還需要做嗎？

AMP 不是處理手機版可用性問題的必要條件。若現有網站能做好 RWD、載入效能、版面穩定與互動體驗，優先修正現有頁面的手機版問題即可。

手機版修好後，SEO 成效要看哪些指標？

可追蹤 Search Console 的曝光、點擊、CTR、平均排名，也可搭配 GA4 觀察互動與轉換。若修的是體驗問題，Core Web Vitals、表單完成率、購物流程完成率也值得納入。

只有少數低流量頁面出問題，需要急著修嗎？

不一定。若只是少數低流量頁面，且不影響共用版型，可先記錄並排入例行維護。若問題來自共用範本，即使目前只看到少數 URL，也應優先修範本，避免後續擴散。