Google 從 2016 年起就把 Smartphone Googlebot 的手機身分從模仿 iPhone 的 Safari 換成模仿 Android 的 Chrome（字串裡還留著 Nexus 5X 這個 2016 年的型號），重點不在那支虛擬手機多舊，而在它背後那個會持續更新的 Chromium 引擎能不能正常渲染你的手機版頁面。Google 自己在官方的爬蟲 User-Agent 清單裡也寫得很白：Mobile-First Indexing 之後，用來排名的就是這支手機爬蟲抓到的內容。所以你該學的不是去相容十年前手機，而是用 GSC 的 URL 檢查工具或 Chrome 開發人員工具切換 User-Agent，自己驗證手機版到底被 Google 抓成什麼樣子。
TL;DR：Googlebot 的手機身分早在 2016 年就從 iPhone 換成 Android，字串裡的 Nexus 5X 與 Android 6.0.1 是歷史殘留、真正會更新的是 Chrome 核心；你要做的是用 GSC URL 檢查工具或 Chrome DevTools 切換成 Googlebot Smartphone 自測手機版內容，這套方法在 2026 年 AI 搜尋時代依然有效。
文章目錄
結論先講：Google 用手機爬你的網站，重點不是型號而是 Chrome 核心
先把一句話講清楚，免得你越讀越慌：Google 換手機身分，換的是引擎，不是要你去相容舊機。Smartphone Googlebot 抓取你的網站時，背後跑的是 Google 自己會持續更新的 Chromium，桌機爬蟲用的也是同一套核心，所以兩邊看到的渲染結果理論上會一致。你真正該在意的，是你的手機版頁面在這套現代 Chrome 下能不能正常載入、關鍵內容與結構化資料在不在。
很多站方一看到 Googlebot 字串裡寫著 Android 6.0.1、Nexus 5X，就以為得回頭寫一層舊手機相容邏輯，方向完全錯了。那兩個數字是 2016 年定下來後刻意不動的歷史標記，Google 怕頻繁改字串會害一堆網站跟著改程式，所以一直留著。真正每幾週會被拉到接近最新穩定版的，是後面那段 Chrome/W.X.Y.Z。
我自己第一次看到那串字也愣了三秒，後來翻了 Google 官方的爬蟲 User-Agent 清單才釋懷。講白了，這篇文章要回答的八個問題，核心都繞著同一件事：你能不能自己切換成 Googlebot 身分，看到 Google 實際抓到的手機版內容。想先打穩 SEO 基礎觀念，可以回頭讀一篇 SEO 的遊戲規則。
User-Agent 是什麼？把 Googlebot 想成帶著數位身分證的訪客
用白話說，User-Agent 是瀏覽器或爬蟲在每次向伺服器請求網頁時，夾在 HTTP 標頭裡的一段自我介紹字串。它會告訴伺服器「我是誰、我用哪個瀏覽器、什麼作業系統」，伺服器再依此決定要回傳桌機版、手機版，還是動態服務那一版。Googlebot 當然也帶這張身分證，所以才會有「Google 用哪支手機爬你」這個問題。
打個比方：你走進一間店，報上「我是用手機查的客人」，店員就拿出小尺寸選單；你換句話說「我坐在桌機前」，店員就給你完整版選單。User-Agent 就是那句開場白。對 SEO 來說，它的重要性在於，它直接決定 Google 索引到的是你網站的哪一版內容，而那一版才會被拿來排名。這也是為什麼 行動優先索引這件事會跟 User-Agent 緊緊綁在一起。
- 定義層：HTTP 標頭裡的一段字串，瀏覽器與爬蟲都會帶。
- 作用層：伺服器依此決定回傳桌機版、手機版或動態服務版。
- SEO 層：它決定 Google 索引到哪一版，那一版就是排名依據。
實務上，User-Agent 的價值正在遞減，但還沒歸零。Chrome 從第 100 版之後逐步減少 User-Agent 字串裡的細節資訊，業界叫做 User-Agent Reduction，目的是降低指紋追蹤與強迫開發者改用 Client Hints。也就是說，未來伺服器能從 User-Agent 拿到的版本資訊會越來越粗。但對 Googlebot 這種官方爬蟲來說，它依然會帶完整身分字串，這也是為什麼「切換成 Googlebot 身分自測」這招在可見的幾年內都還有效。
順帶一提，很多人會把 User-Agent 跟裝置模擬混為一談。切換 User-Agent 改的是「你報上的身分」，切換裝置工具列改的是「瀏覽器視窗尺寸與觸控事件」，這兩件事要分開看，後面實作章節會再拆。想看更完整的技術 SEO 觀念地圖，可以參考這篇 技術 SEO 入門。
2016 年的關鍵轉折：為什麼 Google 把爬蟲手機從 iPhone 換成 Android
2016 年是分水嶺。那一年 Google 把 Smartphone Googlebot 的 User-Agent，從模仿 iPhone 上的 Safari，換成模仿 Android 上的 Chrome。為什麼要換？因為 Google 想用一個自己能完全控制版本的 Chromium 引擎來渲染你的頁面，不再被蘋果 Safari 的更新節奏綁架，也讓桌機爬蟲與手機爬蟲用的是同一套渲染核心，降低「桌機看得到、手機看不到」的差異。
把時間軸拉開會更清楚：
- 2016：Smartphone Googlebot 從 iPhone＋Safari 換成 Android＋Chrome。
- 2018：Google 開始大規模推動行動版內容優先索引。
- 2021：行動版內容優先索引全面完成，新網站預設就走這套。
附帶效益是手機與桌機的渲染結果趨於一致，動態服務那種「伺服器偷看你身分再給不同 HTML」的老架構，風險也跟著被放大。說實話，這段歷史對多數網站主日常營運沒有直接影響，但它會決定你怎麼解讀那串 Googlebot 字串，這是下一節的重點。想深入看演算法面的脈絡，可讀 行動優先索引的演算法觀點，或回顧 Google 對行動裝置友善網站有利的演算法。
順著時間軸想，你會發現 Google 換手機身分不是孤立事件，而是為接下來的行動優先索引鋪路。先用一支可控引擎的虛擬手機穩定抓取，累積夠多的手機版資料，才可能在 2018 年大規模切換索引來源。換句話說，2016 那次切換是手段，讓手機版內容成為排名主角才是目的。理解這層因果，就會知道 Google 為什麼寧可保留看起來過時的型號字串也不願頻繁更動，因為穩定比新潮重要。這種「為了索引一致性而刻意不動」的設計哲學，也是站長做自測時能仰賴的前提。
看懂 Googlebot Smartphone 字串：Android 6.0.1、Nexus 5X、Chrome 各代表什麼
直接看 Google 官方公佈的 Smartphone Googlebot 字串範例（完整與最新版本請以 Google 官方的爬蟲 User-Agent 清單為準）：
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Mobile Safari/537.36
逐段拆給你看：
- Android 6.0.1 / Nexus 5X：固定不變的歷史標記，別誤判成要相容舊機。
- Chrome/W.X.Y.Z：唯一會持續更新的部分，是渲染能力的真正指標。
- compatible; Googlebot/2.1：用來辨識這是 Google 官方爬蟲，驗證來訪 IP 時記得做反向 DNS。
- Mobile Safari/537.36：相容性殘留，現代網頁別再拿這個判斷功能支援。
這裡要小心一個我親眼看過的悲劇：有站方為了字串裡那個 Nexus 5X，特地寫了一層舊手機相容邏輯，還降級了動畫與字型，結果桌機體驗跟著變糟，排名也沒比較好。真正該做的是功能偵測（feature detection），而不是 User-Agent 嗅探，判斷瀏覽器支不支援某個 API，比猜對方是哪支手機穩得多。這個觀念在 被忽略的技術 SEO 盲點裡也反覆被強調。
判斷重點很簡單：與其問「這支手機夠不夠新」，不如問「這個頁面在現代 Chromium 下能不能跑得起來」。具體可以檢查三件事。第一，頁面用到的 JavaScript 語法與 API 有沒有被現代 Chrome 支援。第二，CSS 的 flex、grid、container query 有沒有寫錯導致手機版破版。第三，圖片是不是用 lazy loading 但忘記給預留空間，造成版面劇烈跳動。這三項顧好，比你研究半小時 Nexus 5X 規格有意義得多。相關的程式碼層 SEO 細節，看 網站程式碼最佳化指南。
行動版內容優先索引：為什麼你非得知道 Google 用哪支手機爬你
把兩件事串起來就懂了：User-Agent 決定 Google 抓哪一版內容，而 Mobile-First Indexing 規定被抓到的那一版就是排名的主要依據。所以「Google 用哪支手機爬你」這個問題，實際上等於「被拿來排名的內容長怎樣」。
不同網站架構的命運差很多：
- RWD 自適應：同一份 HTML、同一組內容，桌機手機都吃，影響最小。
- 獨立手機版（m. 網域）：兩套內容分開維護，風險最高，最容易漏掉內容。
- 動態服務（Dynamic Serving）：伺服器依 User-Agent 回不同 HTML，最危險，一旦判斷失誤就整頁走樣。
核心原則只有一句：桌機版有、手機版沒有的內容，等於不存在於索引與排名計算。最常被犧牲的是 tab 折疊區塊、圖片 alt 文字、結構化資料，以及那些「反正手機版面太小就先拿掉」的長尾段落。想看 Google 官方對這套機制的完整說明，讀 行動優先索引的官方公告解讀。索引生效的時間差也很現實，剛改完不會馬上反映在排名上，相關的延遲成因與檢查步驟在 行動優先索引延遲有拆解。若你的站還在用侵入式插頁廣告，手機版的體驗訊號也會被扣分，可看 彈跳廣告的 SEO 懲罰；Google 對行動裝置友善度的歷史要求，則可回顧 Mobile-Friendly 警示。
這也是為什麼我一直強調自測，你不切換身分看一眼，根本不知道 Google 抓到的手機版缺了多少東西。如果你連行動版流量為什麼重要都還半信半疑，可以先看 Google 為什麼一直改手機搜尋結果版面。再退一步看，整套行動版邏輯是 Google 對「絕大多數人用手機搜尋」這個事實的回應，這個趨勢不會逆轉，所以把心力投在手機版，是少數穩賺的 SEO 投資。
方法一：Google Search Console URL 檢查工具，最準的官方自測神器
最準、最該優先用的工具，是 Google Search Console 內建的「URL 檢查工具」。貼上網址後，它會用接近 Googlebot Smartphone 的方式抓取並渲染你的頁面，再顯示實際索引到的內容、載入狀態與阻擋訊息。對驗證手機版內容來說，這是權威度最高的免費工具。
操作路徑很直覺，但它顯示的資訊比你想的多，值得花十分鐘把每個欄位都點開看一次。很多人只用來看「有沒有被索引」，卻漏掉渲染截圖與被封鎖資源這兩塊，而這兩塊恰恰是手機版排名問題的高發區。
- 打開 GSC，在最上方的「URL 檢查」欄位貼上完整網址。
- 點「測試實際網址」，等它跑完抓取與渲染。
- 看三件事：渲染後的截圖、HTTP 回應狀態、被封鎖的資源清單。
- 進階比對：用「檢視已檢索的網頁」看實際抓到的 HTML，跟你想像的手機版對照。
我處理客戶網站時，這招最常抓到的問題是 robots.txt 把 CSS 或 JS 擋住了，導致 Googlebot 渲染不出完整版面，卻又查不到明顯錯誤。另一個常見狀況是手機版漏了結構化資料，這時可以順手用 複合式搜尋結果測試工具交叉驗證。要注意限制：URL 檢查工具需要你擁有網站所有權驗證，測不了別人的站。想了解 GSC 常見報表與用法，可以讀 Site Kit by Google 或 Google 免費 SEO 工具。
還有一個容易漏掉的進階用法：在 URL 檢查結果裡，點開「涵蓋範圍」與「使用者宣告的標準網址」這兩塊，看 Google 認定的 canonical 是不是你預期的那一頁。有些網站手機版與桌機版各自帶了不同的 canonical，結果 Google 自己選了一個，跟你腦裡想的不一樣，排名訊號就會分散。把 canonical 對齊，是技術 SEO 裡 cp 值很高的動作，相關觀念在 Canonical 標籤為什麼會被無視有深入討論。重複內容的處理則可看 重複內容對 SEO 的影響。
如果你發現 GSC 顯示的渲染結果跟你在 DevTools 看到的不一樣，先別急著判定哪邊錯。GSC 用的是 Google 的 Web Rendering Service，它的行為跟你本機 Chrome 不會完全相同，尤其在你裝了一堆擴充功能或本機有代理的時候。以 GSC 為準是相對安全的判斷，因為那才是真正參與索引的渲染器。這套工具的最大價值不在「能不能用」，而在它給你的是 Google 自己的視角，沒有第二手詮釋，這也是為什麼只要有權限就從這裡開始。
如果你曾在 GSC 看過「已建立索引但未包含內容」這種訊息，那多半也跟爬蟲抓不到完整內容有關，細節可以看 GSC 已建立索引但未包含內容的排查。
方法二：Chrome 開發人員工具，自己切換 User-Agent 看手機版長怎樣
不想裝擴充功能、又想模擬手機爬蟲檢視網站，就用 Chrome 開發人員工具。按 F12 開啟後，切到「裝置工具列」，再到「網路狀況」面板關閉「使用瀏覽器預設」，就能手動輸入 Googlebot Smartphone 的完整 User-Agent 字串重新整理，看到伺服器回傳給手機爬蟲的那一版內容。
步驟拆解：
- F12 開發人員工具 → Ctrl+Shift+M（Mac 是 Cmd+Shift+M）切換裝置工具列。
- 在工具列右上角三個點打開「更多工具」→「網路狀況」。
- 找到「使用者代理字串」，取消勾選「使用瀏覽器預設」。
- 從下拉選單選一支手機，或自訂貼上前面那段完整 Googlebot Smartphone 字串。
- 重新整理，觀察回傳的內容。
重點觀察四件事：內容有沒有被精簡掉、圖片有沒有正常載入、結構化資料還在不在、有沒有被快取騙到。最後這點最坑，你的網站如果掛了 Cloudflare 或其他 CDN，重新整理時可能吃到邊緣快取的舊版，看起來「沒問題」其實是假的。我的習慣是固定開無痕視窗、或手動 purge 一次再測。這個快取陷阱在 索引系統造成的排名烏龍那篇也提過類似概念。
一個小訣竅：在 DevTools 的 Network 面板勾選「Disable cache」，再切換成 Googlebot 身分重新整理，能大幅降低被瀏覽器端快取干擾的機率。再搭配 Throttling 把網路降到 Slow 4G，你會更接近真實手機使用者的體驗，順便觀察 LCP 在慢網路下的表現。這些細節累積起來，就是你跟「隨便切個裝置看看」的差別。想系統化跑這類檢測，PageSpeed Insights 整合 Lighthouse是必備工具；更深入的程式碼層診斷，可看 WEB.DEV 工具。
把方法一與方法二想成兩道關卡，缺一不可。方法一告訴你 Google「實際」抓到什麼，方法二讓你在本機快速實驗各種身分與情境。前者權威但慢、且需要權限，後者快但可能被本機環境誤導。實務上我會先用方法二快速掃過整站，找出可疑頁面，再用方法一逐頁確認。這個順序能省下大量等待 GSC 渲染的時間，是接案現場很實用的工作節奏。
如果你想要更快的切換體驗，User-Agent Switcher 類的擴充功能也行，Firefox 那邊則有「自適應設計模式」對應。不過擴充功能要留意：少數反爬較兇的站會偵測切換行為，自測自家網站則無妨。想補一個免登入的公開驗證，回到 複合式搜尋結果測試工具就夠用。
方法三：線上模擬器與 Rich Results Test，沒有 GSC 權限也能驗
沒有網站的 GSC 權限怎麼辦？接案驗收、或想偷看競品時很常遇到這狀況。用 Google 官方的「複合式搜尋結果測試（Rich Results Test）」貼上任意網址，它會以 Googlebot 身分抓取，顯示偵測到的結構化資料與基本渲染結果；想看完整視覺效果，再搭配 BrowserStack、LambdaTest 這類線上模擬器。
- Rich Results Test：免登入、官方、可看結構化資料與基本渲染，最推薦的替代方案。
- Mobile-Friendly Test（舊）：Google 已停用，別再引用它的截圖與建議。
- BrowserStack／LambdaTest：看視覺，但不等於爬蟲真實抓取，別把它當真相。
要誠實說一句：任何模擬器都無法 100% 還原真實爬蟲行為，它們頂多逼近。真正決定你排名狀態的，還是 GSC 裡那個「實際索引狀態」。所以能用 GSC 就別用模擬器墊檔，模擬器只適合快速 sanity check。想了解結構化資料到底怎麼寫，讀 結構化資料是什麼，或看 產品結構化資料的電商實戰。
五個最常踩的雷：切換 User-Agent 自測時的錯誤判讀
自測這套方法不難，難在判讀。我把實務上看過最常見的五個錯誤整理出來，你照著避開就能少走很多冤枉路。
- 被型號嚇到：看到 Android 6.0.1、Nexus 5X 就寫舊機相容層，前面說過了，方向反了。
- 被 CDN 快取騙：Cloudflare 或 LiteSpeed 快取讓你看到的不是爬蟲現在抓的版本，記得清快取或用無痕。
- 只看畫面不看原始碼：視覺正常不代表 HTML 裡關鍵內容與結構化資料都在，一定切到「檢視原始碼」或 GSC 的已檢索網頁看。
- 漏掉結構化資料：手機版缺 JSON-LD 或 meta description 卻渾然不覺，這會直接影響複合式搜尋結果出現機會。
- 引用已停用工具：還拿舊版 Mobile-Friendly Test 的截圖當依據，給出過時建議。
說個我自己出過的包：第一次自測時我看了 Chrome DevTools 的畫面，覺得手機版一切正常，後來用 GSC 一拉才發現伺服器回的根本是桌機版（因為它對非手機 UA 一律回桌機）。從此我固定先清快取、再同時跑 GSC 與 DevTools 交叉比對，才沒再被騙。這類機械性檢查在 SEO 排名因素週期表裡被歸類為「技術層的基本功」，別嫌煩。相關的渲染與 JavaScript 抓取議題，可以再看 Google 抓取 JavaScript 連結。
把這五個雷濃縮成一份自測清單，你每次跑完切換身分的檢測，就照著過一遍：先確認抓到的是手機版（看視窗寬度與內容佈局），再看原始 HTML 裡關鍵段落與 JSON-LD 在不在，接著比對桌機版與手機版的差異清單，最後檢查 canonical 與索引狀態有沒有對齊。把這套流程跑成習慣，比記住任何一個型號都實用。清單背後的精神，跟 SEO 新手入門強調的「可重複執行」是一致的。
手機版與桌機版內容不一致：排名會怎樣
這是大家最焦慮的問題，答案也很直白：在行動版內容優先索引下，Google 以手機版為主，桌機版有、手機版沒有的內容，就是不存在於索引與排名計算。這不是懲罰，是那些內容根本沒被收進去。最常見的犧牲品有四類：tab 與 accordion 預設收合的區塊、按需載入的內容、漢堡選單裡藏起來的連結，以及被壓縮的圖片 alt。
高風險區與對應做法：
- Tab／accordion：預設收合的內容要確認 HTML 裡真的存在，不是用 JS 事後塞。
- 結構化資料：手機版也要放完整 JSON-LD，別只在桌機版放。
- 圖片：手機版別用低解析偷渡，alt 文字一定要保留。
- 長尾段落：別因為版面小就整段拿掉，那是長尾流量的來源。
檢查清單很簡單：用前面方法一加方法二，把桌機版與手機版的已檢索 HTML 拿來逐段比對，缺什麼補什麼。觀念上，這其實就是 On-Page SEO 在手機版的延伸，差別只在於你得先用自測工具「看見」手機版的真實樣貌。結構化資料的對齊細節，可參考 QAPage 結構化資料教學；圖片 alt 的寫法則看 如何寫好的 alt 替代文字。標題標籤在手機版也要維持清晰層級，這部分的寫法可看 標題標籤 H1 與 H2 怎麼用。
如果你的網站還在用獨立手機版或動態服務，真的要認真考慮遷移到 RWD。遷移的 SEO 自守眉角不少，先看 網站改版要多久心裡有個底，再讀 RWD 網頁設計的完整觀念。
速度、體驗與結構化資料：手機爬蟲不只看內容，也看載入與資料
切換 User-Agent 自測時，別只盯著內容，載入表現與結構化資料同樣會被手機爬蟲記錄下來。Google 把頁面體驗（Page Experience）整合進排名基礎後，Core Web Vitals 的 LCP、INP、CLS 都是手機版實測資料。你自測時若發現手機版載入偏慢、元素會跳動，那就算內容完整，體驗訊號也會扣分。
這部分的優先順序建議這樣排：
- 先用 GSC 的 Core Web Vitals 報表看手機版的實測分數。
- 再用 PageSpeed Insights 跑手機模式，找出具體的拖慢項目。
- 最後回到 DevTools 切換成手機爬蟲身分，驗證修正前後的差異。
速度與行動體驗是另一條獨立戰線，本文不展開，但相關資源先放著：行動網站速度為什麼重要、Core Web Vitals 是什麼、頁面體驗排名因素，以及 網頁速度對 SEO 的影響。AMP 退場後的速度策略，則可看 AMP 還重不重要。
結構化資料放哪一版才有用？答案還是手機版。Smartphone Googlebot 抓到的 JSON-LD 才是會被拿來產生複合式搜尋結果與精選摘要的來源。桌機版放得再完整，手機版漏了，等於沒放。這也是為什麼自測時要固定多檢查一項：手機版的已檢索 HTML 裡，application/ld+json 區塊在不在、內容對不對。常見的 FAQ、Product、Article、BreadcrumbList 這幾類，是手機版最容易在精簡過程中被拿掉的。想搶精選摘要的位置，先讀 精選摘要的影響與應對與 精選摘要基礎觀念；結構化資料的整體策略，可讀 WordPress SEO 最佳化。內容佈局想更貼合搜尋意圖，可讀 On-Page SEO 主題群集策略；想理解搜尋意圖怎麼影響排名，再看 搜尋意圖是什麼。
2026 AI 搜尋的調整：User-Agent 自測還有沒有用
AI Overviews 與 AI Mode 興起後，最常被問的就是「這套老方法還要管嗎」。我的答案是：要，而且可能比以前更重要。AI 搜尋引用與摘要的內容，底層來源依然是被 Smartphone Googlebot 正確索引的手機版頁面；手機爬蟲抓不到的內容，AI 也看不到。你自測手機版能不能被正確渲染、關鍵內容與結構化資料在不在，直接影響你能不能被 AI 搜尋選為引用來源。
幾個 2026 年自測的新重點：
- 不只看能不能排名，還看段落清不清楚、能不能被 AI 整段引用（GEO 觀念）。
- 結構化資料與清晰的小標，提升被 AI 摘要引用的機會。
- 別走極端：基礎 SEO 沒做好就直衝 GEO，是本末倒置。
Google 持續在更新爬蟲的 Chrome 核心，所以這套自測 SOP 不會過時，引擎會變新，但「切換身分驗證手機版」這個動作永遠有效。想完整理解 AI 搜尋對 SEO 的衝擊，可以依序讀 AI Overviews 是什麼、Google AI Mode 是什麼、AI SEO 新戰場，以及 GEO 生成式引擎最佳化。AI 搜尋的整體生存法則，再看 AI 搜尋 SEO 完整指南與 AI SEO 是什麼。
一個觀念要講清楚：AI 搜尋有自己的發現層，有些被引用的頁面在傳統 SERP 根本沒什麼流量，所以你也不能只盯著排名看。這部分可參考 2026 AI 搜尋流量重分配與 Google I/O 2026 搜尋 Agent 化。把基礎打穩再談 AI，是 Google Web Guide 反覆強調的原則。若想理解 AI 搜尋背後的查詢擴充機制，再看 查詢擴充 Query Fan-out；AI 搜尋是否在吃掉你的流量，垃圾搜尋結果對 SEO 的衝擊給了另一個視角。
FAQ：關於 Google 切換 User-Agent 與手機版自測的常見疑問
把大家最常問的問題整理在這，涵蓋型號辨識、自測工具選擇、內容差異影響與 AI 時代定位。
Q1：Googlebot 現在到底用 iPhone 還是 Android？
用 Android。Smartphone Googlebot 從 2016 年就從模仿 iPhone 換成模仿 Android 上的 Chrome，字串裡的 Nexus 5X 只是當年留下的歷史殘留，別再以為 Google 還在用 iPhone 爬你。
Q2：字串裡的 Android 6.0.1 要不要特別相容？
不用。Android 6.0.1 與 Nexus 5X 是固定不動的標記，真正決定渲染能力的是 Chrome/W.X.Y.Z，它會定期更新到接近最新穩定版。做功能偵測、別做 UA 嗅探。
Q3：切換 User-Agent 跟切換裝置工具列有什麼差？
前者改的是 HTTP 標頭裡的身分字串，決定伺服器回哪一版 HTML；後者改的是瀏覽器視窗尺寸與觸控事件，影響的是渲染後的呈現。自測時兩者要一起用，才會接近真實爬蟲行為。
Q4：沒有 GSC 權限怎麼辦？
用 Google 官方的複合式搜尋結果測試（Rich Results Test）貼上網址，它會以 Googlebot 身分抓取並顯示結構化資料與基本渲染；接案驗收則建議直接請業主開 GSC 權限，那是唯一能看「實際索引狀態」的管道。
Q5：手機版內容少很多會被懲罰嗎？
不是懲罰，是那些內容根本不會被索引。行動版內容優先索引下，桌機版有、手機版沒有的內容等於不存在，補齊手機版內容比擔心演算法懲罰更實際。
Q6：怎麼驗證來訪的真的是 Googlebot？
做反向 DNS，確認 IP 反解到 googlebot.com 或 google.com 網域，再正向 DNS 一次確認能對回原 IP。只看 User-Agent 字串不可靠，因為字串可以偽造。
Q7：2026 年還要管這件事嗎？
要。AI Overviews 與 AI Mode 引用的內容，底層仍是手機爬蟲正確索引的手機版頁面。自測手機版能不能被正確渲染、關鍵內容在不在，直接影響你能不能被 AI 搜尋選為引用來源。
Q8：用擴充功能切 UA 會被網站偵測封鎖嗎？
少數反爬較積極的站會偵測切換行為，但自測自家網站無妨。如果只是驗收自家內容，用 Chrome 內建的開發人員工具就夠，不必冒著被誤判的風險裝一堆擴充功能。
回顧一下：與其糾結型號，不如學會自測那套 SOP
講到這裡，你應該能感覺到：Google 換手機身分這件事，本身只是歷史背景，不是你該花力氣糾結的點。你真正該帶走的，是一套可重複執行的自測流程，用 GSC URL 檢查工具或 Chrome 開發人員工具，自己切換成 Googlebot Smartphone 身分，確認手機版內容完整、結構化資料在位、沒被快取或舊機迷思帶偏。
一句話行動：今晚就挑你自家首頁或一個重點產品頁，用方法一或方法二跑一次，把桌機版與手機版的已檢索 HTML 拿來比對，看看到底差多少。修正之後，給它 7 到 28 天的觀察期，再看 GSC 的索引狀態與行動流量有沒有變化，再決定下一步。
回到搜尋意圖：你會搜到這個主題，多半是懷疑排名下滑跟 Google 換手機有關。實務上，與其猜型號，不如先修正最影響判斷的訊號，也就是手機版被 Google 實際抓到的那一版內容。想看 SEO 全局觀念怎麼安排優先順序，讀 最重要的 SEO 排名因素；要補強網站整體結構，看 網站架構最佳化指南；想知道內部連結怎麼幫手機版頁面傳遞權重，讀 內部連結最佳化策略。基礎觀念想重整，則回到 如何改善 SEO。把這套自測變成例行公事，你的手機版排名才不會在不知不覺中被精簡內容拖累。記住，自測不是一次性任務，而是每個月固定跑一次的健康檢查，越早養成習慣越吃香。
