web.dev 是 Google 官方維護的網站開發與品質檢測平台，底層用開源引擎 Lighthouse 對任何網址跑自動審查，從效能、無障礙、最佳實踐到 SEO 給出 0 到 100 分；它的權威性來自一個很直白的事實：訂標準的就是它。根據 Google 官方文件，Core Web Vitals 三個指標（LCP ≤2.5 秒、CLS ≤0.1、INP ≤200 毫秒）自 2021 年起列為排名訊號，2024 年 3 月 INP 又正式取代 FID，所以這套工具在 2026 年不只幫你打分數，更是你看懂「Google 眼中現代化網站」的官方入口。
TL;DR： web.dev 用 Lighthouse 引擎幫網站體檢，2026 年檢測入口已整併到 PageSpeed Insights；分數本身不是排名保證，但 Core Web Vitals（LCP 2.5 秒、CLS 0.1、INP 200 毫秒）是官方排名訊號之一，看懂四大維度再修紅字，比追求滿分更划算。
文章目錄
web.dev 是什麼？Google 官方網站檢測平台的定義
web.dev 是 Google 官方推出的網站開發與品質檢測平台，你輸入一個網址，它就用 Lighthouse 引擎跑一輪自動審查，給你四大維度的 0 到 100 分，外加一份逐項修正建議。簡單講，它是 Google 用來告訴你「它眼中的現代化網站應該長怎樣」的那套官方標準。
它跟一般 SEO 工具最大的不同在於權威性來源。Ahrefs、SEMrush 是第三方觀察，web.dev 則是「訂標準的那一方自己開的體檢站」，分數邏輯跟 Chrome DevTools 完全一致，因為底層根本是同一個引擎。換句話說，當 web.dev 跟你說某項不及格，那不是建議，是 Google 自己的判定。這也是為什麼很多站長會把它放進 免費 SEO 工具清單的第一位，而不是排在某個付費工具後面。
幾個要先講清楚的定位。第一，web.dev 不只檢測，還整合大量教學資源，web.dev/learn 是官方學習入口，如果你想理解 Google 認可的開發標準，那是正本清源。第二，2026 年的檢測入口已經整併到 PageSpeed Insights（pagespeed.web.dev），你打 web.dev/measure 也會被導過去，這點很多 2018 年的舊文還沒更新，會讓人誤以為是兩個站。第三，它免費、免登入、貼網址就能跑，這對自己架站的WordPress 站長來說幾乎零門檻。
還有一件事要講清楚：web.dev 跑出來的分數是針對「你貼的那個網址」，不是整個網站。所以同一個站的不同頁面，分數可以差很多。首頁可能 90 分，某篇裝了一堆外掛的老文章可能只剩 40 分。這也是為什麼後面我會建議你挑多個代表性網址來測，而不是只看首頁自爽。把這個觀念建立好，你看報告時才不會把單頁分數誤當成全站體質。
這裡要小心一個觀念誤區。很多人把 web.dev 當成「打 SEO 分數的工具」，這個描述在 2018 年勉強成立，放到 2026 年就太薄了。它真正在做的是網站品質的全面向審查，SEO 只是其中一個維度，速度與互動體驗才是大頭。如果你只盯著 SEO 那格分數，等於只看體檢報告的一頁，把技術性 SEO真正會影響排名的訊號全忽略了。講白了，分數高的網站不代表就能擠進 搜尋結果頁 SERP 前段，它只是把「被 Google 讀懂」這件基本功做扎實而已。
web.dev 檢測的四大維度：效能、無障礙、最佳實踐、SEO
web.dev 用四大維度評分，分別是 Performance（效能）、Accessibility（無障礙）、Best Practices（最佳實踐）、SEO。對站長來說，Performance 與 SEO 通常最直接影響排名與流量，但四項都不能偏廢，因為它們背後各自代表一種使用者體驗問題。下面我會一格一格拆開講，把每格分數背後到底在測什麼、為什麼該在意一次說清楚。
Performance：速度與互動流暢度
Performance 測的是載入速度與互動流暢度，分數來自 Core Web Vitals 三指標加上幾個輔助指標。它直接綁排名訊號，因為 Core Web Vitals 已經是 Google 公開的頁面體驗訊號之一。實務上，Performance 也是最多人焦慮的那格分數，看到 30 分就覺得天快塌了。我的經驗是：分數低不代表網站爛，常常只是圖片太大或某個外掛拖慢主執行緒，修一兩個關鍵項就能跳一截。
Accessibility：無障礙網頁
Accessibility 測的是身心障礙者能不能用你的網站，檢查項目包括 alt 文字、色彩對比、鍵盤導覽、表單標籤等等。這格分數很多人忽略，但它跟 網站可及性與 SEO 其實是同一條線，而且台灣在 2024 年之後對公部門與部分電商的無障礙要求越來越明確，早晚要面對。講白了，補齊 alt 文字與對比，對一般讀者也是加分。
Best Practices：安全性與開發規範
Best Practices 測的是網站健康度，HTTPS、圖片格式、主控台錯誤、HTTPS 混合內容都在這裡。它不像 Performance 那麼直接綁排名，但每一項紅字背後都是真實的風險，例如 HTTPS 對 SEO 的影響早就從加分項變成基本盤，沒裝 HTTPS 等於在門口掛「不安全」的牌子。這一格也會抓到Chrome 對 HTTP 網站的不安全標示這類問題，等於幫你提前擋掉被瀏覽器勸退的風險。
SEO：搜尋引擎可讀性
SEO 這格測的是搜尋引擎能不能順利讀懂你的頁面，檢查 meta 標籤、可爬取性、行動裝置相容性、hreflang 等等。它是四項裡最容易被誤解的一格，因為滿分不代表你會排上去，只是代表 Google「能讀懂」。真正的排名還是要回到內容相關性與權威，這部分可以參考 E-E-A-T 的完整討論。
給一個務實的優先順序：先看紅色（不及格）項目，再依 Performance、SEO、Best Practices、Accessibility 排修。把紅字清掉，分數自然會上來，不必為了把分數刷到頂而砍功能。
web.dev、PageSpeed Insights、Lighthouse 差在哪？三者關係一次看懂
三個名字常被搞混，但關係其實很清楚：Lighthouse 是跑分引擎，PageSpeed Insights 是把 Lighthouse 模擬資料加上 Chrome 真實使用者實測資料的網頁工具，web.dev 則是涵蓋工具與教學的官方平台。三者底層是同一套審查邏輯，差別在「跑分環境」與「是否含真實使用者資料」。
把它們拆開看會更清楚。Lighthouse 是一個開源 Node 模組，可以在 PageSpeed Insights 整合 Lighthouse 的網頁介面跑，也能裝在 Chrome DevTools、CLI 或 CI 流程裡，是工程師做自動化測試時的主力。PageSpeed Insights 是你一般會輸入網址的那個網頁工具，它同時提供 Lab Data（Lighthouse 模擬）和 Field Data（CrUX 實測），是站長最常用的入口。web.dev 則是把工具、文件、課程全包起來的品牌傘。如果你想看歷史脈絡，網頁速度對 SEO 的影響那篇有談到 PageSpeed Insights 早期的演進，能幫你把時間軸串起來。
一個常被問到的問題是：那我要不要裝 Lighthouse CLI 自己跑？我的看法是，除非你是接案工程師、需要在每次部署前自動檢查，不然用 PageSpeed Insights 的網頁版就夠了。兩者跑出來的 Lab Data 邏輯一致，差別只在 CLI 能批次跑、能寫進 CI，對一般站長沒有明顯優勢。把心力放在看懂報告，比安裝工具更值得。
| 項目 | Lighthouse | PageSpeed Insights | web.dev |
|---|---|---|---|
| 性質 | 開源跑分引擎 | 網頁檢測工具 | 官方平台（品牌傘） |
| 資料來源 | 受控模擬（Lab Data） | Lab Data＋Field Data（CrUX） | 整合上述兩者 |
| 適用情境 | CI、DevTools、自動化 | 貼網址快速體檢 | 學習標準、查文件 |
| 是否含實測資料 | 無 | 有 | 經由 PSI 取得 |
| 需要登入 | 不用 | 不用 | 不用 |
講白了，你日常用的那個介面就是 PageSpeed Insights，web.dev 是它的官方品牌，Lighthouse 是藏在裡面的引擎。理解這層關係，就不會再被三個名字弄得霧煞煞，也不會在接案時跟客戶雞同鴨講。
Lab Data vs Field Data：為什麼同一個網頁會出現兩組不同分數
Lab Data（實驗室資料）是 Lighthouse 在受控模擬環境跑出來的單次結果，適合抓程式碼問題；Field Data（實測資料）來自 Chrome 使用者真實瀏覽回傳的 CrUX 資料集，反映真實讀者體驗。兩者數字會不同，因為真實環境的網路、裝置、廣告阻擋都會影響，而排名訊號以 Field Data 為準。
這是看懂 PageSpeed Insights 報告的關鍵，但偏偏最多人卡在這裡。我先給一個小故事：有次我幫一個客戶改完首頁，Lighthouse 分數從 40 跳到 92，他高興了三天，結果實測資料那欄還是紅的。為什麼？因為 Field Data 是 28 天滾動平均，不會因為你今天改了程式碼就立刻變綠。這也帶出一個很重要的觀念，頁面體驗訊號是長期累積的，不是一槍斃命。
兩者各有用處。Lab Data 受控、可重現、即時，適合你在開發階段抓問題；Field Data 才是真實讀者的樣貌，也是 Google 判定 Core Web Vitals 是否過門檻的依據。新網站或低流量站可能根本沒有 Field Data，因為 CrUX 只收錄流量夠大的網址，這時你只能先看 Lab Data，等流量起來再補實測。
實務建議是：用 Lab Data 找問題、用 Field Data 驗收成果。把這句話記下來，你看報告時就不會陷入「分數怎麼又變了」的焦慮迴圈。如果你想更系統地追蹤 Field Data，Search Console 的 Core Web Vitals 報表是另一個免費的長期觀測工具。
再補一個容易被忽略的點：Field Data 的代表性取決於你的讀者結構。如果你的站主要流量來自行動裝置，那 CrUX 收到的資料就會以手機體驗為主，這時桌面分數再漂亮也掩蓋不了手機端的問題。所以看報告時要交叉比對 Google Analytics 的裝置分佈，確認你修的方向真的對應到多數讀者的體驗。這也是為什麼我們常說，體檢工具要跟流量工具一起看，而不是各自獨立解讀，這個觀念在技術 SEO 的真正價值裡有更完整的論證。
Core Web Vitals 三指標：LCP、CLS、INP 合格門檻與改善方向
Core Web Vitals 是 Google 用來衡量使用者體驗的三個核心指標：LCP（最大內容繪製）測載入速度，合格門檻 2.5 秒以內；CLS（累計版面位移）測視覺穩定性，門檻 0.1 以內；INP（互動到下一次繪製）測互動流暢度，門檻 200 毫秒以內，並於 2024 年 3 月正式取代舊的 FID。
| 指標 | 測什麼 | 良好門檻 | 差 | 常見改善方向 |
|---|---|---|---|---|
| LCP | 最大內容繪製（載入速度） | ≤2.5 秒 | >4 秒 | 圖片壓縮、CDN、伺服器回應 |
| CLS | 累計版面位移（視覺穩定） | ≤0.1 | >0.25 | 為圖片與廣告版位預留尺寸 |
| INP | 互動到下一次繪製（流暢度） | ≤200 毫秒 | >500 毫秒 | 減少主執行緒阻塞、拆分長任務 |
LCP：圖片與伺服器是兩個大頭
LCP 卡關，十次有八次是圖片或伺服器。圖片太大、沒壓縮、沒用現代格式（WebP、AVIF）、沒設定寬高，都會把最大那塊內容的繪製時間拖長。伺服器端則是 TTFB（首位元組時間）過高，常見於共享主機或沒快取的動態頁面。如果你是 WordPress 站長，先檢查主機等級與行動裝置網站速度，再談程式碼層的最佳化。主機選錯，後面再怎麼調程式碼都事倍功半，這也是為什麼我們在網站速度為什麼重要裡反覆強調主機是速度的起點。
CLS：版面跳動最傷體驗
CLS 過高，讀者點按鈕的瞬間按鈕跑掉了，這是最直接的體驗殺手。改善方法很直白：給所有圖片、iframe、廣告版位預留尺寸，別讓內容載入後把版面擠開。廣告版位尤其麻煩，建議固定高度或用佔位元件撐住。順帶一提，侵入式插頁廣告不只影響 CLS，還可能踩到 Google 的行動版懲罰紅線。
實際上 CLS 常常是三個指標裡最好修的，因為它幾乎不需要動程式碼邏輯，只要補上 width 跟 height 屬性，或為動態注入的區塊先保留空間。我看過不少站長為了 INP 焦頭爛額，結果回頭一看，CLS 其實半小時就解掉了，分數也跟著回來。所以修 Core Web Vitals 時，建議從 CP 值最高的 CLS 開刀，把容易拿的分先拿穩。
INP：2024 年取代 FID 的新指標
INP 在 2024 年 3 月正式取代 FID，差別在於 FID 只量首次點擊，INP 量整頁所有互動的回應速度，標準嚴格得多。WordPress 站長最常踩的雷是某個外掛在主執行緒塞了一坨 JavaScript，導致點選單、送表單都卡頓。改善方向是拆分長任務、延後載入非必要腳本，這部分可以搭配網站程式碼最佳化的觀念一起做。
三項都過門檻，才算「良好」Core Web Vitals 狀態，這個狀態會影響排名訊號。不過要再強調一次：過門檻就好，不是追求極限數字。為了把 INP 從 180 毫秒壓到 80 毫秒而砍掉互動功能，那是本末倒置。如果你發現 INP 怎麼修都卡在門檻邊緣，多半是某一兩個特定頁面或特定互動（例如複雜的篩選器、即時搜尋）拖累整頁，這時針對那個互動做最佳化，比無差別地砍腳本更有效。
web.dev 報告怎麼看：從分數到修正建議的閱讀順序
跑完報告後面對一堆數字與紅字，正確的閱讀順序是：先看 Core Web Vitals 三指標是否過門檻，再看 Performance 分數的紅色機會項（Opportunities），接著看 SEO 與 Best Practices 有沒有紅字，到頭來才把心力放在把分數刷高。把紅色項修掉，分數自然會上去。
很多人一打開報告就盯著最上面那個總分，然後開始焦慮。其實總分是四個維度算出來的綜合指標，它會隨著你修任何一項而變動，但對排名真正有影響的是 Core Web Vitals 那三格。所以第一順位永遠是：Core Web Vitals 三指標是不是「良好」。只要這三格是綠的，你已經把排名訊號那塊顧住了。
第二順位是 Performance 區塊裡的 Opportunities（機會）與 Diagnostics（診斷）。Opportunities 會告訴你「修這項能省多少毫秒」，這是投報比最高的清單，例如啟用文字壓縮、延後載入圖片，通常改一兩行設定就能拿回大把毫秒。Diagnostics 則是診斷訊號，不直接給分但反映潛在問題。這裡也常會看到HTTP/2或程式碼層最佳化的相關建議，站長可以順手一併處理。
第三順位是 SEO 紅字。常見的有缺 meta description、robots 封鎖、沒有行動裝置相容性，這些多半是設定漏掉，補一下就解決。如果你想對照檢查，meta description 怎麼寫與alt 替代文字都有現成的指南可以套用。第四順位是 Best Practices 紅字，例如 HTTPS 混合內容、過時的圖片格式。修到這裡，你的網站體質已經贏過大半競爭者。
到頭來還有一個常見陷阱要提醒：PSI 的結果有快取。你改完程式碼馬上重跑，看到的可能是舊報告，這時可以加一組亂數參數（例如 ?cb=20260617）強制重新跑，或耐心等個幾分鐘。別被快取誤導成「改了沒效」，結果改錯方向愈改愈糟。
常見錯誤：把 web.dev 分數當成排名保證
不會。web.dev 分數提高不等於排名一定變好，Core Web Vitals 只是 Google 數百個排名訊號之一，內容相關性與權威性的權重遠高於網頁速度。更實際的做法是把分數當成「使用者體驗體檢報告」，修掉明顯問題就好，不必為了滿分犧牲內容與功能。
這個誤區非常普遍，所以我直接講白：連 Google、Facebook、Instagram 的首頁都不會在每個維度拿滿分。你可以自己拿這幾個大站去跑跑看，成績單上同樣有紅字。如果全球流量最大的網站都做不到滿分，你一個內容站追求 100 分，要嘛是搞錯重點，要嘛是在浪費工程資源。
排名訊號裡，內容相關性、外部連結、E-E-A-T（經驗、專業、權威、信任）的權重遠高於速度分數。一個 Core Web Vitals 全綠但內容空洞的頁面，排名會輸給一個分數普通但內容紮實的對手。這也是為什麼我們一直強調，實用內容才是基本面，速度是加分項。如果真要排序，最重要的幾個排名因素裡，速度大概落在中段班，不是決定性的那一票。
更危險的是過度最佳化。為了把分數拉高，有人會延後載入整個選單、把圖片壓到糊掉、砍掉影片與互動元件，結果讀者體驗反而變差，跳出率上升，這在跳出率與離開率的數字上會直接反映出來。分數是手段，讀者體驗才是目的，別把手段當目的。也有人為了衝分數把頁面上的外部連結全部延後載入，結果看起來快了，卻少了對讀者與搜尋引擎的脈絡訊號，長期反而不利。
給一個務實目標：Core Web Vitals 過門檻、紅色項清零，分數落在 80 到 90 之間就很健康。再上去的邊際效益急遽遞減，工程成本卻直線上升，CP 值很低。如果你想系統性地看排名因素的優先順序，可以參考我們整理的SEO 排名因素週期表。另一個我會提醒的觀念是：分數會波動是正常的。同一個網址不同時間跑，分數差個 5 到 10 分很常見，這跟模擬環境的隨機性、當下伺服器負載都有關。把分數當成區間看，而不是單一數字，心裡會踏實很多。
2026 AI 搜尋時代，web.dev 該怎麼重新定位
有用，但角色要調整。2026 年 AI 搜尋崛起後，web.dev 從「顧 Google 排名」的工具，變成「顧任何搜尋引擎與 AI 爬蟲都能順利讀懂你網站」的基礎體檢。因為 AI 模型抓取網頁時同樣需要快速載入、結構清楚、可爬取，所以基礎檢測反而更不能省，只是不能再把分數等同於排名。
先講一個很多人沒想到的事：AI 爬蟲（GPTBot、PerplexityBot、Google-Extended 等）抓網頁時，跟傳統搜尋引擎爬蟲面對的是同一個載入與結構問題。你網站慢、JS 渲染阻塞、結構混亂，AI 一樣抓不到、抓不完整。也就是說，基礎體檢沒做好，你不只輸 Google 排名，也輸 AI Overview 與 ChatGPT Search 的引用機會。從 Google 搜尋運作方式的爬蟲、索引、排名三階段來看，載入與可爬取性本來就是地基，AI 時代只是把這個地基的重要性再放大一層。
結構化資料、語意標題、清晰的段落結構，是傳統 SEO 與 AI 引用的共同需求。一份能被 結構化資料標記、能用 H1 到 H3 清楚分層的內容，對 Google 是好讀，對 AI 是好引用。這也是為什麼 標題標籤 SEO 在 AI 搜尋時代反而更重要，而不是被淘汰。如果你想再往前推一步，llms.txt 這類專門餵給 AI 爬蟲的設定檔，是 2026 年才冒出來的新戰場，值得順手認識。
調整心態很關鍵。在 GEO 與 AEO 時代，可被 AI 引用的內容區塊，價值常常高於純粹的分數。你想被人們在 生成式引擎裡被看見，就得確保內容有清晰可抽取的答案區塊，這部分可以參考 AEO 答案引擎最佳化的完整做法。web.dev 的 SEO 維度仍是這套地基，但分數不再是唯一指標。從策略面看，AI 搜尋時代的 SEO 佈局已經不只是排名問題，而是「能不能被機器正確引用」的問題。
說到底，分數是手段，「被搜尋引擎與 AI 都讀懂」才是目的。這個心態一轉過來，你在 2026 年用 web.dev 的方式就會完全不一樣：不再為了那格數字焦慮，而是把報告當成「我的網站對機器讀者友善嗎」的檢查表。如果想進一步了解 AI 搜尋怎麼吃掉傳統流量，AI Overviews 與 零點擊搜尋是兩個值得延伸的主題；而把內容設計成易於 AI 抽取的格式，可以對照 精選摘要的老技巧，原理其實相通。
我的實戰心得：用 web.dev 幫網站做體檢的 5 步驟
我把平時幫網站做體檢的流程整理成 5 步，照著做一遍，你大概就抓到這套工具的節奏。先聲明，這是我個人經驗整理，不是唯一正解，你可以根據自己的站調整。
步驟 1：鎖定要測的網址
不要只測首頁。首頁通常最佳化得最好，但真正承載流量與轉換的是文章頁、產品頁。挑 3 到 5 個代表性網址，例如流量最高的文章、轉換率最好的產品頁、剛改版的欄頁，這樣抓到的問題才有代表性。如果你不知道哪些頁流量最高，先去 Site Kit by Google 或 Search Console 撈一份報表，搭配自然流量分佈一起看，會更精準。
步驟 2：手機與桌面都跑一遍
手機流量佔比向來不低，只跑桌面等於只看一半真相。PageSpeed Insights 預設會同時給你 Mobile 與 Desktop 兩份報告，務必兩份都看。手機分數通常比桌面低一截，這是正常的，因為手機的 CPU、網路條件都比較受限。如果你對行動版的基本觀念還不熟，先讀過行動優先索引會比較踏實。
步驟 3：先檢查 Core Web Vitals 三指標
門檻優先於分數。LCP、CLS、INP 三格是不是綠的，比上面那個 Performance 總分更重要。有任何一格是紅或橘，那就是你的第一優先戰場。把這三格顧綠，排名訊號那塊就算打底完成。對應的改善方向前面已經講過，這裡不再重複。
步驟 4：依固定順序修紅字
我固定的順序是 Performance、SEO、Best Practices、Accessibility。Performance 的 Opportunities 投報比最高，先清；SEO 紅字多半是設定漏掉，補一下就解決；Best Practices 是健康度問題；Accessibility 最終再補，因為它對一般流量影響最小但長期價值高。修的時候記得搭配技術 SEO 盲點的檢查，避免改了 A 壞了 B。
步驟 5：用 Search Console 追蹤 Field Data 變化
改完不要只看 Lighthouse 分數，要用 Search Console 的 Core Web Vitals 報表追蹤 Field Data。觀察 7 到 28 天再做下一步，因為實測資料是滾動平均，太早下結論會誤判。如果 28 天後還是紅，那才代表你的改善方向有問題，需要再回頭檢查。對網站整體最佳化流程有興趣的，可以延伸讀網站最佳化流程。
把這五步串起來，其實就是一個完整的 PDCA 迴圈：規劃要測哪些頁、執行檢測、檢查紅字、行動修正、再用實測資料驗收。很多站長的問題不在於不會用工具，而在於跑完報告就放著，沒有後續追蹤。體檢報告的價值來自「定期複檢」這個動作，單次分數高低反而是次要的。我自己的習慣是每個月挑一天，把流量前幾名的頁面重跑一次，順便記錄分數變化趨勢，這比盯單次數字有用得多。
常見問題 FAQ
web.dev 是免費的嗎？需要登入 Google 帳號嗎？
完全免費，而且不用登入。你打開 PageSpeed Insights（pagespeed.web.dev），貼上網址就能跑，連 Google 帳號都不用。web.dev 上的學習資源與文件也全部開放。它跟其他 Google 官方 SEO 工具一樣走開放路線，門檻低到只剩「你有沒有網址」。
web.dev 跟 PageSpeed Insights 是同一個東西嗎？
本質上是同一套系統的不同入口。web.dev 是品牌傘，涵蓋工具、文件、課程；PageSpeed Insights 是你實際貼網址跑檢測的那個工具介面，底層用的是 Lighthouse 引擎。2026 年 web.dev/measure 已整併到 PageSpeed Insights，所以日常使用時你幾乎只會碰到 PSI。想理解兩者整合的來龍去脈，可以看我們之前寫的 PSI 整合 Lighthouse 完整教學。
Core Web Vitals 沒過會被降排名嗎？
不會直接降排名，但會影響頁面體驗訊號這個排名因素。Core Web Vitals 是數百個排名訊號之一，沒過不代表一定掉，但當你跟對手內容實力相近時，這格就是決勝點。實務上，過門檻是基本盤，過了之後再往上的邊際效益有限，所以把心力放在過門檻即可。相關討論可以參考頁面體驗排名因素的完整解析。
為什麼我的 web.dev 分數很高，排名卻沒變？
因為分數跟排名不是一比一的關係。分數只代表「網站對機器與使用者友善」，排名還取決於內容相關性、外部連結、E-E-A-T 等數百個訊號。分數高排名不動，代表你的技術基本面已經到位，瓶頸在內容與權威，這時該補的是內容與連結策略，而不是繼續把分數從 90 拉到 95。
web.dev 的 SEO 分數跟 Rank Math、Yoast 的 SEO 分數有什麼不同？
層級不同。web.dev 的 SEO 分數測的是「搜尋引擎能不能順利讀懂這個頁面」，屬於技術可讀性；Rank Math、Yoast 的分數則是針對單篇文章的站內 SEO檢查，例如關鍵字分布、meta 設定、內部連結。前者是地基，後者是裝潢，兩者互補不衝突，建議兩種工具都跑。
INP 是什麼？為什麼 2024 年要取代 FID？
INP（Interaction to Next Paint）量的是頁面上所有互動的回應速度，FID（First Input Delay）只量第一次點擊的延遲。FID 太寬鬆，很多網站首次點擊過關但後續互動卡頓，使用者體驗其實很差，所以 Google 在 2024 年 3 月用更嚴格的 INP 取代 FID，門檻 200 毫秒以內算良好。詳見我們站上 Core Web Vitals 的完整介紹。
行動裝置的分數比桌面低很多，正常嗎？
正常。手機的 CPU、記憶體、網路條件都比桌面差，Lighthouse 在模擬行動環境時本來就會把分數壓低。重點不是手機分數跟桌面比，而是手機分數對應的 Core Web Vitals 有沒有過門檻。只要三指標過門檻，分數 60 幾分也能是健康的。對手機版的基本觀念不熟的話，先讀行動優先索引的相關基礎。
結語：把 web.dev 當體檢報告，而不是排名保單
回到搜尋意圖：你點進這篇，多半是想搞清楚 web.dev 到底是什麼、跟另外兩個工具差在哪、報告怎麼看、改了會不會影響排名。講了這麼多，核心訊息只有一句：web.dev 是 Google 給你的免費網站體檢報告，分數本身不會直接換成排名，但看懂四大維度與 Core Web Vitals 背後的使用者體驗問題、按優先順序修正，才是它真正的價值。
在 2026 年 AI 搜尋時代，這套體檢反而更不能省。因為 AI 爬蟲跟傳統搜尋引擎面對的是同一個載入與結構問題，地基沒打好，你不只輸 Google，也輸 AI Overview 與 ChatGPT Search 的引用機會。把心態從「追求分數」轉成「被機器與人都讀懂」，你用這套工具的方式就會完全升級。回顧一下全文脈絡：從定義、四大維度、三者差異、Lab 與 Field、Core Web Vitals 門檻、報告閱讀順序、分數迷思、AI 時代定位，到 5 步驟實戰，其實就是一套從認識到上手的完整路徑。
如果你還沒跑過自己的網站，現在就打開 PageSpeed Insights，貼上首頁加上流量最高的那篇文章，照著前面那 5 步驟走一遍。觀察 7 到 28 天再做下一步，別急著一天改十項。把體質顧好，排名自然會慢慢跟上來。準備好之後，下一步可以把SEO 新手入門與排名因素完整解析一起看，把技術體檢接上整體策略，這套工具的價值才會真正發揮。
