網站速度影響 SEO，但它通常不是「分數越高排名一定越好」的單一開關。對台灣中小企業來說，真正該看的是核心商業頁面在真實使用者資料中是否通過 Core Web Vitals，尤其是 LCP、INP、CLS 是否拖慢使用者完成詢問、購買、預約或閱讀。若你的內容本身薄弱、搜尋意圖不準，單靠速度不會救排名；但若頁面已經有需求與內容基礎，速度問題會讓 Google、使用者與 AI 摘要系統更難穩定理解與推薦你的頁面。
網站速度影響 SEO 的關鍵，不是 PageSpeed 滿分
很多老闆看到 PageSpeed Insights 的紅色分數，就要求工程師「全部修到 100 分」。這種做法很容易浪費預算。Google 對 Core Web Vitals 的說明重點在於真實使用者體驗：載入效能、互動反應與版面穩定度。Google Search Central 也提醒站主應達成良好的 Core Web Vitals，因為它和整體頁面體驗一致，符合搜尋核心系統想獎勵的方向之一。
換句話說，速度不是獨立於內容之外的魔法按鈕。它比較像商業頁面的基本服務品質：使用者點進來後能不能很快看到主要內容、點選表單或選單時有沒有延遲、價格區塊與 CTA 會不會突然跳動。這些問題會影響轉換，也會影響搜尋引擎與答案引擎對頁面品質的判斷。
Core Web Vitals 三個指標要用商業頁面來看
Google 目前把 Core Web Vitals 聚焦在三個指標：LCP 衡量主要內容載入速度，INP 衡量互動回應，CLS 衡量非預期版面位移。根據 Google Search Central，良好體驗的目標是 LCP 在 2.5 秒內、INP 小於 200 毫秒、CLS 低於 0.1。web.dev 對門檻方法的說明也指出，這些門檻是用第 75 百分位的真實使用資料來評估，而不是只看單次測試。
| 指標 | 它代表什麼 | 台灣中小企業常見問題 | 優先處理情境 |
|---|---|---|---|
| LCP | 主要內容多久被看見 | 首頁大圖太重、主視覺未壓縮、伺服器回應慢 | 服務頁、產品頁、活動頁進站後看不到重點 |
| INP | 使用者點擊後多久有反應 | 第三方追蹤碼太多、表單腳本阻塞、選單互動卡頓 | 詢問表單、購物車、預約流程延遲 |
| CLS | 版面是否突然跳動 | 圖片未預留尺寸、廣告或外掛後載入、字型切換造成位移 | CTA、價格、購買按鈕被推開或誤點 |
PageSpeed Insights、Search Console、Lighthouse 各自回答不同問題
Google 的 PageSpeed Insights 說明指出，PSI 同時提供現場資料與實驗室資料：現場資料來自 Chrome User Experience Report，能反映過去 28 天真實使用者經驗；實驗室資料則由 Lighthouse 在受控環境中產生，適合用來除錯。這代表你不該只看一個總分，而要先分清楚「真實使用者正在痛」還是「單次測試提示某些可優化項」。
Search Console 的 Core Web Vitals 報告會依裝置、狀態、指標和相似網址群組顯示效能。它不是所有已建立索引網址的完整清單，而是用範例協助你找出問題群組。對資源有限的中小企業來說，這個群組概念很重要：你通常不需要逐頁手修 300 個 URL，而是找出同一版型、同一產品列表、同一表單模組造成的共同問題。
台灣中小企業該先修哪裡？用 6 個判斷排順序
速度修復要能進入開發排程，必須把「SEO 分數不好」翻譯成業務能理解、工程師能執行的任務。以下 6 個判斷可以避免把預算花在看起來漂亮但商業影響小的地方。
- 先看有商業價值的頁面。優先檢查首頁、服務頁、產品分類頁、熱門產品頁、預約頁、報價頁與高流量文章。低流量且不承接轉換的舊文章，不一定要排在第一波。
- 先看手機。台灣消費者大量用手機查詢店家、比較產品與填表。若行動版 LCP 或 INP 不良，通常比桌機分數更急。
- 先看真實使用者資料。Search Console 或 PageSpeed Insights 的現場資料比單次 Lighthouse 分數更適合判斷 SEO 風險；Lighthouse 則用來找出可能的程式、圖片、字型、第三方腳本問題。
- 先修同版型問題。如果多個產品頁、文章頁或分類頁屬於同一 URL 群組，修版型通常比單頁微調更有效。
- 先修阻擋成交的互動。表單、加入購物車、LINE 加好友、預約按鈕、篩選器若卡頓，INP 問題不只是 SEO 問題，也是營收問題。
- 先設定觀察期。Core Web Vitals 的現場資料會反映一段期間的真實使用狀況，修完後要用 Search Console、PSI 與自身分析資料追蹤，不要期待隔天所有報表立刻變綠。
把速度修復變成可交付的開發任務
一份有效的速度修復單不該只寫「請把 PageSpeed 修高」。你可以把任務拆成「頁面群組、受影響裝置、主要指標、疑似原因、商業影響、驗收方式」。例如：手機版服務頁群組 LCP 不良，疑似主視覺圖片過大與未設定優先載入，商業影響是使用者進站後看不到服務承諾與 CTA，驗收方式是 PSI 現場資料持續改善，Lighthouse 的 LCP 元素與圖片建議也同步下降。
工程上常見修法包含壓縮與正確尺寸的圖片、延遲載入非首屏資源、減少阻塞渲染的 CSS/JavaScript、清理不必要的追蹤碼、替互動元件拆小腳本、替圖片與嵌入物預留尺寸、改善快取與伺服器回應。這些都要依你的網站架構選擇，不能從競品文章照抄一張清單就交辦。
AEO 與 GEO：快不只是快，還要讓答案更穩定
AEO 重視搜尋者能否快速得到直接答案，GEO 重視生成式答案能否清楚理解、引用與限制你的內容。網站速度在這裡的角色不是「讓 AI 更喜歡你」這種模糊說法，而是降低頁面被使用者放棄、主要內容延遲呈現、互動訊號混亂、重要段落被腳本或版面問題干擾的風險。
Google 的 AI features and your website 文件表示，讓內容適用於 AI 搜尋功能的基礎仍是一般 Google Search 的要求。對企業網站來說，速度修復要和清楚的標題、可引用的段落、FAQ、來源連結、更新日期、適用限制一起做。若頁面很快但答案含糊，AI 摘要也不容易可靠引用；若答案很好但頁面載入與互動品質很差，也會削弱整體體驗。
適用對象與不適用情境
這套判斷適合有網站、內容頁、服務頁、產品頁或電商頁的台灣中小企業，尤其是已經用 Search Console 管理網站、開始投放內容或靠自然搜尋取得詢問的團隊。它也適合正在和外包工程師、網頁公司、SEO 顧問協作，但不知道該如何排序速度任務的行銷負責人。
它不適合把速度當成唯一成長槓桿的情境。如果你的頁面沒有對準搜尋意圖、內容缺少證據、產品頁資訊不完整、價格與服務條件不清楚，先補內容與商業訊息通常比追求 100 分更重要。若網站是全新網域或流量太少，CrUX 可能沒有足夠現場資料，此時可以先用 Lighthouse 與自身 RUM/分析資料找問題，但要把不確定性說清楚。
資料更新與證據來源
本文依 2026-05-27 可查資料整理。主要依據包含 Google Search Central 的 Core Web Vitals 說明、Google page experience 說明、Search Console Core Web Vitals 報告說明、PageSpeed Insights 官方說明、web.dev 的 Core Web Vitals 門檻方法與 Google AI features and your website。平台規則、報表介面和門檻可能更新，實作前仍要重新檢查你的 Search Console、PSI 報表與網站架構。
結論：速度優化要從「可影響搜尋與成交的頁面」開始
網站速度影響 SEO，但最值得投資的不是每頁追滿分，而是讓核心商業頁面在真實使用者資料中變得穩定、可用、可理解。台灣中小企業可以先用 Search Console 找出不良或需要改善的 URL 群組，再用 PageSpeed Insights 和 Lighthouse 把 LCP、INP、CLS 問題翻譯成開發任務。當速度、內容、來源、FAQ 與下一步行動一起改善，SEO、AEO 與 GEO 才會形成可累積的搜尋資產。
FAQ
網站速度影響 SEO 的程度大嗎？
它通常不是唯一排名因素，但會影響頁面體驗與使用者行為。若內容和搜尋意圖已經有基礎，Core Web Vitals 不良就值得優先檢查。
PageSpeed Insights 一定要 100 分嗎？
不一定。先看現場資料與 Core Web Vitals 是否通過，再用 Lighthouse 建議除錯。追求滿分不一定比修商業頁面痛點更有價值。
沒有 CrUX 現場資料怎麼辦？
流量較少的新站可能沒有足夠資料。可先用 Lighthouse、PageSpeed Insights 實驗室資料與自己的分析工具找問題，同時標記這不是完整現場證據。
速度修復後多久會看到 Search Console 變化？
Core Web Vitals 依真實使用資料反映一段期間的體驗，通常需要觀察數週。修完後要持續看 URL 群組、裝置與指標趨勢。
AEO/GEO 為什麼也需要看網站速度？
答案引擎需要清楚、穩定、可引用的內容。速度問題若讓主要內容延遲、互動混亂或使用者快速離開，會削弱整體可用性與信任訊號。
延伸閱讀
如果你想把這個主題接到下一步操作，可以接著讀：