圖片 SEO 優化是網站圖片在搜尋引擎可理解性、可索引性與頁面載入效能三個維度上的技術設定。這篇文章用 Kevin Wu 診斷客戶站的方式整理，從語意（alt、檔名、圖說）、效能（尺寸、格式、壓縮、srcset）到工具驗證（PSI、GSC），幫你判斷圖片問題屬於哪一類，再給對應的修法，而不是從壓縮工具開始盲目操作。
之前有個電商客戶問我，為什麼首頁改版之後 PageSpeed 分數掉了快 20 分，但頁面看起來沒什麼差。我打開 PSI 一看，hero image 換成了一張 2.4MB 的 PNG，而且還加了 loading="lazy"。這張圖同時是 LCP 元素，一被延後載入，LCP 就爆了。這種問題本來可以在五分鐘內被發現，但很多人做圖片優化的方式，是從壓縮工具開始，不是從症狀回推。
圖片 SEO 到底在優化什麼？
圖片 SEO 是讓圖片同時被搜尋引擎理解、被使用者看懂，並且不拖慢頁面的技術設定，分成語意層、效能層與索引層三個方向。語意層處理 alt text、檔名、圖說與周圍文字，讓 Googlebot 知道圖片在說什麼；效能層處理尺寸、格式、壓縮與載入策略，讓圖片不拖慢 Core Web Vitals；索引層處理 image sitemap、structured data 與 URL 可取用性，讓 Google 圖片搜尋能正確收錄。
很多人做圖片 SEO 只處理 alt 和壓縮，跳過了效能層和索引層。這不會造成立即的錯誤，但長期下來圖片帶來的搜尋流量、頁面速度評分與 LCP 表現都不理想。三層要同時檢查，差別只在優先順序。
圖片 SEO 要先修哪一類問題？
先修首屏大圖與 PageSpeed 標紅的圖片問題，再處理 alt、檔名與 image sitemap，因為前者直接影響 LCP 與使用者體驗，後者則影響搜尋可見度與長期索引品質。圖片問題大致分四類：一是拖慢載入（圖太大、格式沒壓縮、首屏 lazy load 設錯）；二是搜尋引擎看不懂（缺 alt、檔名無意義、沒有圖說）；三是圖片不被 Google 索引（URL 被擋、JS 載入沒有 fallback）；四是結構化資料錯誤（product image、article image 設定錯誤）。
修復順序建議如下：
- 首屏 LCP 圖片：格式、尺寸、preload、不可 lazy load
- PageSpeed 診斷標出的圖片（properly size images、next-gen formats、efficient cache policy）
- 缺 alt 的重要圖片：產品圖、流程圖、封面圖優先
- 檔名無意義的圖片：批次更名後更新 URL
- image sitemap 與 structured data：電商、圖庫與大媒體站才優先
一般內容站從前三項開始，電商或圖片流量大的站再加後兩項。
Alt 怎麼寫才不是關鍵字堆疊？
好的 alt 要精確描述圖片的內容與實際功能，不是把主關鍵字重複填進每張圖，因為 alt 的兩個主要用途都要求精準：讓螢幕閱讀器理解圖片（無障礙），以及讓搜尋引擎知道這張圖和頁面主題的關係。
| 圖片類型 | 正確 alt 寫法 | 常見錯誤 | 說明 |
|---|---|---|---|
| 產品圖 | Samsung Galaxy S24 Ultra 鈦灰色正面照 | 手機 手機推薦 Galaxy S24 | 描述圖片實際內容，型號與顏色比泛稱有效 |
| 流程圖 | 圖片 SEO 修復優先順序流程，從首屏大圖到索引問題 | 圖片SEO教學 圖片優化重要 | 說明流程圖的主題與涵蓋範圍 |
| 裝飾圖 | （空字串 alt=""） | 填入關鍵字或頁面標題 | 純裝飾圖用空 alt，讓螢幕閱讀器跳過 |
| 截圖 | Google PageSpeed Insights 報告截圖，顯示 LCP 元素為首頁 hero image | PageSpeed截圖 PSI報告 | 截圖的 alt 要說明截圖內容，不只說工具名稱 |
裝飾圖一定要給空 alt（alt=""），不要省略 alt 屬性，省略和空字串的行為不同：省略時螢幕閱讀器可能會念出檔名，空字串才是正確的「跳過」指令。建議 alt 文字保持在 125 個字元以內，避免過長描述被截斷，並讓語意更集中。
圖片檔名、圖說與周圍文字怎麼整理？
圖片檔名負責基本辨識，圖說與周圍段落負責補足搜尋引擎判斷圖片主題的上下文，兩者配合才能讓 Googlebot 在不依賴 alt 的情況下也能判斷圖片意義。
檔名規則：用描述性英文或拼音，單字之間用連字號，不用底線，不用流水號，不用中文。範例：image-seo-priority-flowchart.png，而不是 image001.png 或 圖片一.png。檔名長度不需要太長，清楚說明主題即可。
圖說（figcaption）的作用是補充圖片本身沒辦法說清楚的資訊，例如數據來源、比較基準、時間範圍。不要把 alt 文字直接複製進 figcaption，這會造成重複，而且沒有額外語意價值。
周圍段落是搜尋引擎判斷圖片主題的重要依據。Google 官方圖片搜尋文件明確建議把圖片放在相關文字段落附近，首屏的重要圖片最好在頁面 HTML 的靠前位置出現，而不是透過 JavaScript 動態插入。
JPEG、PNG、WebP、AVIF 怎麼選？
選圖片格式不是問哪個最好，而是要根據圖片的用途（照片、截圖、透明圖）、網站的瀏覽器覆蓋範圍、以及轉檔流程的可行性來判斷，下表提供基本決策框架：
| 格式 | 適合用途 | 不適合 | 壓縮比 | 透明支援 | 瀏覽器支援 |
|---|---|---|---|---|---|
| JPEG | 照片、色彩豐富的圖 | 截圖、文字圖、透明背景 | 高 | 無 | 全平台 |
| PNG | 截圖、UI 圖、透明背景 | 照片（檔案偏大） | 低 | 有 | 全平台 |
| WebP | 多數網頁圖片 | 舊版 IE（已幾乎不需考慮） | 很高 | 有 | 現代瀏覽器全支援 |
| AVIF | 高壓縮需求、現代網站 | 需要廣泛舊瀏覽器支援的情境 | 最高 | 有 | Chrome、Firefox、Safari、Edge 現代版本均已支援 |
實務上最常走的路是：把現有 JPEG/PNG 轉成 WebP，再根據流量與技術成本判斷是否進一步採用 AVIF。2024 年 8 月 Google 宣布在搜尋結果支援 AVIF，這讓 AVIF 的 SEO 優先順序開始上升，但轉換工具與 CMS 相容性仍需確認。如果 WordPress 外掛或 CMS 系統沒有內建 AVIF 支援，建議先以 WebP 為主要轉換目標。
圖片大小要怎麼壓縮才不傷畫質？
壓縮的正確順序是先把圖片的顯示尺寸裁對，再選格式與品質係數，因為大尺寸圖片本身帶著無用像素被送到所有裝置，單純降低品質係數效果有限，但先把圖片裁到實際顯示大小往往可以省去 50% 以上的檔案體積。
操作順序：
- 確認圖片在頁面上的顯示寬度（用 DevTools 查 computed size，不是圖片本身尺寸）
- 把圖片尺寸縮到顯示寬度的最大值（視網膜螢幕乘以 2，例如最大顯示 800px，準備 1600px 版本）
- 選格式：照片用 WebP 或 JPEG，截圖/UI 用 WebP 或 PNG
- 調整品質係數：WebP 80-85、JPEG 75-85 通常在視覺與檔案大小間取得平衡
- 用 PageSpeed Insights 重測確認「Properly size images」警告是否消失
這裡是關鍵：首屏的 LCP 圖片不能只考慮壓縮，還要確認它不被 lazy load、有足夠快的 TTFB，以及在 HTML 中有正確的 fetchpriority="high" 屬性。壓縮做好了但首屏圖片還是被延後載入，LCP 一樣不會好。
RWD 圖片為什麼不能只靠 CSS 縮小？
CSS 只會改變圖片的顯示大小，不會讓手機瀏覽器下載較小的圖片版本，真正要解決的是 responsive image source 設定，否則手機使用者仍然下載了整張桌機尺寸的原圖，白白消耗流量與載入時間。
解法是用 srcset 和 sizes 屬性告訴瀏覽器在不同視口寬度下應該下載哪個版本：
<img
src="hero-800w.webp"
srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1600w.webp 1600w"
sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
alt="圖片 SEO 診斷工作流程示意"
loading="eager"
fetchpriority="high"
>WordPress 在上傳圖片後會自動生成不同尺寸，但需確認模板是否有正確輸出 srcset。其他平台（Shopify、Webflow）通常有對應設定，但要確認主題有啟用。
lazy loading 什麼時候會害到 LCP？
非首屏的圖片適合使用 lazy load 延後載入，但首屏主圖（hero image、文章封面、首屏產品圖）如果也被加上 loading="lazy"，瀏覽器就會把它推遲，直接拖慢 LCP，這是改版後 Core Web Vitals 分數突然下滑的最常見原因之一。
判斷規則很簡單：
- 首屏看得到的圖片：不加
loading="lazy"，可加fetchpriority="high" - 非首屏的圖片：加
loading="lazy"減少初始載入資源 - 不確定是不是首屏：用 DevTools 在 375px 寬度檢查圖片是否在初始視窗內
和 LCP 優化文章一樣，lazy loading 問題的診斷起點是 PSI 的 LCP element 標示，找到是哪張圖，再確認它有沒有被錯誤地延後。
用 PageSpeed Insights 找圖片問題怎麼做？
開啟 PSI 後應先定位 LCP 元素，再展開圖片相關的診斷項目，不要只看頁面總分，因為總分是加權平均值，圖片問題可能被其他項目掩蓋，直接看診斷才能找到實際拖慢頁面的圖片。
操作步驟：
- 前往 PageSpeed Insights，輸入目標 URL，等待分析完成
- 在「Core Web Vitals 評估」區找 LCP 數值，點開「查看診斷資訊」確認 LCP element 是哪個圖片
- 展開「Opportunities」（改善建議）部分，找這幾項圖片相關診斷：
- 「Properly size images」：圖片尺寸超過顯示需求
- 「Serve images in next-gen formats」：還在用 JPEG/PNG 可以換 WebP/AVIF
- 「Efficiently encode images」：圖片沒有充分壓縮
- 「Serve static assets with an efficient cache policy」：圖片快取策略有問題
- 針對每個診斷，PSI 會列出具體的問題圖片 URL 和預估節省量，從節省量最大的開始修
- 修完後重新輸入 URL 測試，確認問題圖片不再出現在診斷清單
這裡是關鍵：PSI 有時分析的是行動版（預設）和桌面版不同結果，確認你測的版本和實際使用者主要使用的裝置一致。電商站通常行動版流量較高，行動版 PSI 分數更重要。
用 GSC 檢查圖片搜尋與索引問題怎麼做？
GSC 不能直接告訴你每張圖片的排名，但可以幫你確認圖片所在頁面的索引狀態、結構化資料錯誤，以及 Google 是否能正常取用圖片 URL，這是圖片 SEO 中很多人忽略的搜尋引擎側驗證步驟。
GSC 圖片相關檢查路徑：
- 「涵蓋範圍報告」：確認圖片所在頁面是否被索引，如果頁面被排除，圖片一定沒有出現在圖片搜尋中
- 「增強功能 > 圖片」：如果有使用 image structured data（例如 Article 或 Product schema 中的 image 欄位），這裡會顯示錯誤與警告
- 「URL 檢查工具」：輸入含圖片的頁面 URL，確認 Googlebot 能取用圖片資源（渲染快照中圖片要能正常顯示）
常見問題：CDN 或圖片伺服器設了 Googlebot 封鎖規則，導致圖片被索引但實際無法渲染。用 URL 檢查工具的「測試線上網址」功能，看 Googlebot 看到的頁面截圖，確認圖片有正常載入。延伸閱讀：GSC 索引涵蓋範圍問題診斷。
什麼情況需要 image sitemap、CDN 與快取？
一般小型內容站不一定需要 image sitemap，但電商、圖庫、大型媒體站以及圖片透過 JavaScript 動態載入的網站，都應該把 image sitemap 列入檢查，CDN 和快取設定則對幾乎所有站點都有正面效益，只是優先順序不同。
| 項目 | 需要的情境 | 不一定需要的情境 |
|---|---|---|
| Image Sitemap | 圖庫、電商、大型媒體站；圖片透過 JS 動態載入；頁面有嵌入但不在 HTML 正文中的圖片 | 圖片直接在 HTML 中以 <img> 標籤呈現、頁面數量少的一般內容站 |
| CDN（圖片分流） | 有海外流量；圖片較多且伺服器本身 TTFB 偏高；PageSpeed「reduce server response time」有標出問題 | 純本地流量且圖片數量少的小站 |
| 快取設定（Cache-Control） | 幾乎所有網站都應設定；PSI 出現「Serve static assets with an efficient cache policy」警告時必修 | 圖片 URL 已帶版本號或 content hash 且伺服器已正確設定 immutable |
快取的最低設定原則：靜態圖片（不常更動的）設 Cache-Control: max-age=31536000, immutable，會更新的圖片 URL 要帶版本參數或 content hash，讓快取失效機制可以正確運作。nginx 設定快取的語法可以參考 MDN HTTP Caching 文件。
整個圖片 SEO 的診斷流程可以整合進 技術 SEO 稽核的媒體資源檢查項，特別是電商站在改版或大量上傳圖片後，應當把 PSI 圖片診斷、GSC 增強功能與快取設定列為發布前的必查清單。