圖片 SEO 是什麼？四件事就講完了
圖片 SEO 是讓搜尋引擎與 AI 讀得懂你網站圖片的一組作法，核心只有四件事——alt 替代文字、檔名、格式、尺寸。
被講最多的是 alt，但真正決定頁面速度的是格式，而格式沒有單一正確答案，照片、螢幕截圖、圖表三種素材的最佳解完全不同。
這篇的第 4 節用 33 筆自己跑的壓縮實測把這件事量出來。
- alt 替代文字——寫給讀不到圖的人與機器看，描述圖裡發生什麼事，不是塞關鍵字
- 檔名——上傳前就要處理，上傳後要改會牽動所有引用它的頁面
- 格式與壓縮——真正決定頁面速度的一項，最佳解隨素材類型改變
- 尺寸與載入方式——先量出版面實際需要多寬，lazy loading 用錯會反過來拖垮分數
先講結論，趕時間的人看完這一段就可以走。
同一張圖，換一種格式可以省下六成檔案大小，而且肉眼看不出差別。
但省多少要看你的圖是什麼——照片、螢幕截圖、圖表，三者的最佳解完全不同，而這件事幾乎沒有人講。
下面這張表是我們自己跑的實測，不是引用來的數字。
三種素材各輸出 11 種格式與品質組合，量真實檔案大小，再用 SSIM 計算壓縮後與原圖的結構相似度（1.0 代表完全相同，0.99 以上人眼幾乎分辨不出來）。
| 素材類型 | 一般預設（JPEG 90） | 在畫質幾乎不掉的前提下最省的選擇 | 省下 |
|---|---|---|---|
| 照片、人像、情境照 | 334 KB | AVIF 品質 80 → 170 KB | 49% |
| 網頁截圖、大量文字 | 251 KB | WebP 品質 70 → 93 KB | 63% |
| 圖表、大面積純色 | 172 KB | WebP 品質 70 → 68 KB | 61% |
實測日期 2026 年 8 月 11 日，工具為 Python Pillow 12.2.0，SSIM 由 scikit-image 計算。
完整 33 筆數據與方法在第 5 章。
如果你只想做一件事，那就是：把官網上所有的照片從 PNG 或 JPEG 改成 WebP 或 AVIF。
其他技巧都是加分，這一項是止血。
1. 圖片 SEO 是什麼？先搞懂 Google 怎麼「看」你的圖
搜尋引擎看不懂圖片內容本身，它是靠圖片周圍的訊號來推測這張圖在講什麼。
這句話是整篇文章的地基。
1.1 抓取、索引、排名，圖片走的是同一套流程
Google 的爬蟲先找到你的頁面，順著 HTML 裡的 img 標籤發現圖片，把圖片抓回去建立索引，最後在有人搜尋時決定要不要把它排出來。
這三個階段各自有可能卡住。
| 階段 | 卡住的常見原因 | 你該檢查什麼 |
|---|---|---|
| 抓取 | 圖片用 JavaScript 動態載入、或 robots.txt 擋掉了圖片資料夾 | 用瀏覽器停用 JavaScript 看圖片還在不在；檢查 robots.txt 有沒有 Disallow 到 /wp-content/uploads/ |
| 索引 | 檔案太大逾時、格式不支援、或頁面本身沒被索引 | 圖片所在的頁面要先被索引，圖片才有機會 |
| 排名 | 缺乏語意訊號：檔名、alt、周圍文字都沒說這張圖是什麼 | 本文第 2 到第 4 章 |
1.2 AI 搜尋時代多了一件事：被引用
過去圖片 SEO 的目標是「在 Google 圖片搜尋裡排前面」。
現在多了一個目標：當 AI 摘要在回答問題時，你的圖有沒有機會被拿去當佐證。
這兩件事需要的訊號不完全一樣。
排名看的是相關性與品質；被引用看的是這張圖能不能被機器「讀懂並複述」——也就是說，一張有清楚 alt、有圖說、周圍文字有解釋的圖表，比一張漂亮但沒有任何文字說明的照片更容易被引用。
（同樣的邏輯也適用在整個頁面上，我們在反向連結怎麼做那篇談過被引用這件事。
）
2. Alt 替代文字：最多人知道，也最多人寫錯
Alt 是圖片 SEO 裡唯一每一篇教學都會寫的東西，代表它確實重要。
但正因為每個人都在寫，錯誤的寫法也被複製得最廣。
2.1 Alt、title、檔名、圖說，四個東西的分工
| 項目 | 寫在哪 | 誰會看到 | 對 SEO 的作用 |
|---|---|---|---|
| alt 替代文字 | img 標籤的 alt 屬性 | 螢幕閱讀器、圖片載入失敗時、搜尋引擎 | 最主要的語意訊號 |
| title 標題 | img 標籤的 title 屬性 | 滑鼠停留時的提示框 | 幾乎沒有作用，別花時間 |
| 檔名 | 上傳的檔案名稱 | 網址列 | 次要訊號，但上傳後很難改，所以要在上傳前處理 |
| 圖說 caption | 圖片下方的說明文字 | 所有讀者 | 對讀者最有用，也是很強的語境訊號 |
最常見的誤解是把 alt 和 title 當成同一件事。
title 只是滑鼠停留時跳出的小提示，多數使用者根本不會觸發它，螢幕閱讀器也多半略過。
把力氣放在 alt 和 caption 才有意義。
這一點在 Google 圖片 SEO 最佳做法裡寫得很清楚，官方文件通篇沒有提過 title 屬性。
2.2 好的 alt 怎麼寫：五個原則
- 描述這張圖實際上有什麼，而不是描述你希望它被搜到的關鍵字。
- 長度抓在 15 到 30 個中文字，太短沒有資訊量，太長螢幕閱讀器會念不完。
- 把情境寫進去。
同樣一張辦公室照片，在「關於我們」頁面和在「工作環境」頁面，該寫的 alt 不一樣。 - 不要用「圖片」「照片」「示意圖」開頭，螢幕閱讀器本來就會先報讀「圖片」，寫了等於念兩次。
- 圖片如果是連結，alt 要描述點下去會發生什麼，而不是描述圖片長相。
2.3 五種寫錯的 alt，附對照
| 錯誤寫法 | 為什麼錯 | 改成 |
|---|---|---|
| alt=”IMG_2847″ | 上傳後沒改，等於沒有 alt | alt=”高雄鹽埕辦公室的會議區” |
| alt=”高雄網頁設計 高雄網站設計 高雄SEO” | 關鍵字堆砌，Google 會視為操控 | alt=”設計師正在與客戶討論網站版面草稿” |
| alt=”圖片” | 沒有任何資訊 | alt=”三種網站分層的價格中位數比較” |
| alt=”點這裡”（圖片是連結） | 沒說連到哪 | alt=”查看完整報價方案” |
| 整段文章複製貼進 alt | 螢幕閱讀器會念一分鐘 | 把重點濃縮成一句話 |
我們自己也犯過。
這篇文章的舊版本寫於 2019 年，裡面有五張圖，其中兩張的 alt 是空的——一篇在教別人寫 alt 的文章，自己漏了兩張。
這次改寫一併補上了。
順帶一提，我們在高雄網頁設計費用那篇裡放了好幾張價格分布圖，那些圖的 alt 就是照這一節的原則重寫過的。
2.4 哪些圖片應該留空 alt
純裝飾用的圖片應該寫 alt=””（空字串，但屬性要留著），而不是省略 alt 屬性。
兩者對螢幕閱讀器是不同意思：空字串是「這張圖可以略過」，省略則是「不知道該不該念」，後者會導致閱讀器改念檔名。
不確定某一張圖該不該寫 alt，可以照 W3C 的 alt 決策樹走一次，三個問題就能判完。
- 分隔線、裝飾線條、背景紋理
- 純粹排版用的留白圖
- 旁邊已經有完全相同文字說明的圖示
2.5 WordPress 怎麼設定
在媒體庫點開任一張圖片，右側「替代文字」欄位就是 alt。
要注意的是：在媒體庫改 alt 只會影響之後插入的圖片，已經插入文章裡的圖片要在文章編輯器中個別修改。
這是很多人以為改了卻沒生效的原因。
3. 檔名：上傳前就要處理，上傳後很難改
檔名是次要訊號，但它有一個特性：上傳之後要改，等於換網址，已經被索引的圖片會失效。
所以這件事只有上傳前那一次機會。
| 情況 | 檔名 | 說明 |
|---|---|---|
| 相機直出 | DSC_0412.JPG | 沒有任何語意 |
| 設計軟體匯出 | 未命名-1.png、Frame 27.png | 同樣沒有語意 |
| 建議 | kaohsiung-office-meeting.jpg | 用英文或拼音、小寫、連字號分隔 |
| 中文檔名 | 高雄辦公室.jpg | 可以用，但網址會被編碼成一長串，分享時很醜 |
4. 圖片格式：我們實測了 33 筆，結果跟直覺不一樣
市面上的圖片 SEO 文章講到格式時，多半引用同一組二手數字：「WebP 比 JPEG 小 25 到 35%」。
這個數字不能說錯，但它把所有圖片當成同一種東西，而實際上不同素材的差距非常大。
4.1 實測方法
- 三種素材：照片（1600×1600 人像照）、網頁截圖（大量文字）、圖表（大面積純色），各代表官網上最常見的三類圖片。
- 11 種輸出：PNG、JPEG 90/80/70、WebP 90/80/70、WebP 無損、AVIF 90/80/70。
- 畫質怎麼量：用 SSIM 結構相似度，1.0 代表與原圖完全相同。
這是為了取代「看起來還好」這種主觀判斷。 - 基準：以 JPEG 品質 90 為 100%，因為那是多數 CMS 與影像軟體的預設輸出。
- 沒有測的：PageSpeed 分數需要對真實網址執行，本次未測。
實際載入時間還受主機、CDN 與快取影響。
4.2 完整數據
| 素材 | 格式與品質 | 檔案大小 | SSIM | 相對 JPEG 90 |
|---|---|---|---|---|
| 照片 | PNG | 2,282 KB | 1.0 | 682% |
| 照片 | JPEG 90 | 334 KB | 0.9959 | 100% |
| 照片 | JPEG 80 | 226 KB | 0.9921 | 68% |
| 照片 | WebP 90 | 190 KB | 0.9896 | 57% |
| 照片 | WebP 80 | 110 KB | 0.9819 | 33% |
| 照片 | WebP 無損 | 1,619 KB | 1.0 | 484% |
| 照片 | AVIF 90 | 239 KB | 0.9957 | 71% |
| 照片 | AVIF 80 | 170 KB | 0.9935 | 51% |
| 網頁截圖 | PNG | 545 KB | 1.0 | 217% |
| 網頁截圖 | JPEG 90 | 251 KB | 0.9975 | 100% |
| 網頁截圖 | WebP 80 | 113 KB | 0.9969 | 45% |
| 網頁截圖 | WebP 70 | 93 KB | 0.9951 | 37% |
| 網頁截圖 | AVIF 80 | 129 KB | 0.9992 | 51% |
| 網頁截圖 | AVIF 70 | 105 KB | 0.9988 | 42% |
| 圖表 | PNG | 393 KB | 1.0 | 228% |
| 圖表 | JPEG 90 | 172 KB | 0.9967 | 100% |
| 圖表 | WebP 80 | 78 KB | 0.9964 | 45% |
| 圖表 | WebP 70 | 68 KB | 0.9945 | 39% |
| 圖表 | AVIF 80 | 80 KB | 0.9991 | 46% |
| 圖表 | AVIF 70 | 68 KB | 0.9988 | 40% |
完整 33 筆（含 JPEG 70、WebP 無損在各素材的表現）與可重現的程式碼，見文末說明。
4.3 三個跟直覺不一樣的發現
第一，照片千萬不要存成 PNG。
同一張照片，PNG 是 2,282 KB，JPEG 品質 90 只要 334 KB——差 6.8 倍。
很多人以為 PNG 比較「高品質」所以什麼都用 PNG，這是官網速度最常見的殺手。
第二，AVIF 不是永遠比 WebP 好。
在圖表和截圖上，兩者的檔案大小幾乎一樣（68.1 KB 對 67.6 KB），但 AVIF 的畫質分數明顯更高（0.9988 對 0.9945）。
真正拉開差距的是照片：在相近畫質下 AVIF 品質 80 是 170 KB，比 JPEG 90 省 49%。
第三，WebP 無損是陷阱。
「無損」聽起來比較安全，但用在照片上會變成 1,619 KB，比 JPEG 大將近五倍。
無損只適合圖示、線稿、需要透明背景的圖形。
4.4 怎麼決定用哪一種
| 你的圖是 | 建議格式 | 品質設定 |
|---|---|---|
| 照片、人像、情境照 | AVIF，退而求其次 WebP | 80 |
| 網頁截圖、含大量文字 | WebP | 70 到 80 |
| 圖表、資訊圖、大面積純色 | WebP 或 AVIF | 70 到 80 |
| 需要透明背景的圖示、Logo | WebP 無損，或 SVG | — |
| 線稿、圖標、色階很少的圖形 | SVG 優先，其次 PNG | — |
實務上最穩的做法是用 picture 標籤同時提供 AVIF 與 WebP，讓瀏覽器自己挑。
WordPress 從 6.x 之後已經內建 WebP 支援，多數快取外掛也能自動轉檔，不一定要手動處理。
5. 尺寸：先量出版面實際需要多寬
壓縮之前該先做的事，是把圖片縮到版面真正需要的尺寸。
一張 4000 像素寬的原圖放進一個 800 像素寬的欄位，多出來的 3200 像素是純粹的浪費，而且壓縮也救不回來。
量法很簡單：用 Chrome 開啟你的頁面，在圖片上按右鍵選「檢查」，看該圖片容器的實際寬度。
記得同時看手機版——多數台灣中小企業官網的手機流量比桌機高，而手機版的容器往往只有 400 像素左右。
為了應付高解析度螢幕，實際輸出可以是容器寬度的兩倍。
容器 800 像素就輸出 1600 像素，再往上就沒有意義了。
6. 載入速度：lazy loading 用錯會反過來拖垮分數
延遲載入（lazy loading）讓瀏覽器先載入畫面內的圖片，捲動到才載入其他的。
這對整體速度有幫助，但有一個很多人踩的坑。
首屏的主視覺圖絕對不能 lazy load。
那張圖通常就是 Core Web Vitals 裡的 LCP 元素，如果你把它設成延遲載入，等於故意叫瀏覽器晚一點才開始下載它，LCP 分數會直接變差。
Google 在 web.dev 的 LCP 優化指南裡把「LCP 圖片被延遲載入」列為最常見的失分原因之一。
| 圖片位置 | loading 屬性 | 額外處理 |
|---|---|---|
| 首屏主視覺（LCP 元素） | eager 或不設 | 加上 fetchpriority=”high”，必要時用 preload |
| 首屏內的其他圖 | eager 或不設 | — |
| 需要捲動才看得到的圖 | lazy | — |
WordPress 從 5.5 開始會自動幫所有圖片加上 loading=”lazy”，包含首屏那一張。
較新的版本已經會嘗試略過前幾張，但如果你的版型結構特殊，還是要自己確認一次。
另外一件常被忽略的事：每一個 img 都要寫 width 和 height 屬性。
沒寫的話瀏覽器不知道要預留多少空間，圖片載入時版面會跳動，那會傷到 CLS 分數。
7. 圖片 Sitemap：不是每個網站都需要
圖片 sitemap 是告訴 Google「這個頁面上有這些圖片」的清單。
但多數網站其實不需要特別處理，因為只要圖片是用標準的 img 標籤寫在 HTML 裡，Google 順著頁面就找得到。
真正需要圖片 sitemap 的是這幾種情況：
- 圖片是用 JavaScript 動態載入的（例如某些相簿外掛或前端框架）
- 圖片放在跟網站不同的網域或 CDN 上
- 網站有大量圖片而且圖片本身就是內容主體，例如攝影作品集、商品目錄
如果你用 Rank Math 或 Yoast，圖片通常已經被包在既有的 sitemap 裡，打開 sitemap 檔案搜尋 image 就能確認。
不確定的話，去 Search Console 的「網頁索引」報表看實際被索引的狀況，比猜有用。
要自己動手寫的話，格式規範在 Google 圖片 Sitemap 說明。
8. 結構化資料的 image 欄位：規格比你想的嚴格
這一段幾乎沒有中文文章講清楚。
結構化資料裡的 image 不是「加了就好」，Google 對它有明確規格，不符合的話那個複合式搜尋結果就不會出現。
以下規格整理自 Google 的 Article 結構化資料文件。
| 項目 | Google 的要求 |
|---|---|
| 格式 | 必須是爬蟲抓得到的圖片網址，不能是 CSS 背景圖或用 JavaScript 產生的 |
| 最小尺寸 | 寬度建議至少 1200 像素 |
| 長寬比 | 建議同時提供 16:9、4:3、1:1 三種，用陣列傳 |
| 可抓取性 | 圖片網址不能被 robots.txt 擋住 |
| 必填與否 | Article、Product、Recipe 等類型，image 是必填欄位 |
最常見的錯誤是只給一張 16:9 的圖。
Google 在不同版位會裁切成不同比例，只給一種等於把選擇權交出去，裁到人臉或重點被切掉是常有的事。
9. 圖片周圍的文字，比你以為的重要
搜尋引擎判斷一張圖在講什麼，除了 alt 和檔名，很大一部分靠的是圖片前後的段落、圖說、以及所在區塊的標題。
這也是為什麼「把圖片單獨放在一個沒有文字的區塊裡」是浪費。
實務上最簡單的做法是：每一張有資訊價值的圖，下面加一行圖說。
圖說對讀者有用（多數人會先看圖再看圖說），對搜尋引擎也是很乾淨的語境訊號，一舉兩得。
反過來，不要用圖片承載重要文字。
把服務項目、價格表、聯絡資訊做成圖片放上去，搜尋引擎讀不到，螢幕閱讀器也讀不到。
要有設計感可以用 CSS，不要用圖片。
10. 圖片 SEO 檢查清單
這份清單可以直接複製下來，每次上稿前跑一次。
如果你是在盤整整個網站而不只是一篇文章，可以搭配網站改版費用那篇的檢查順序一起做。
- 圖片在上傳前已經縮到版面需要的尺寸（容器寬度的兩倍以內）
- 檔名是有意義的英文或拼音，小寫、連字號分隔
- 格式：照片用 AVIF 或 WebP，圖示與線稿用 SVG，需要透明背景才用 WebP 無損
- 每一張圖都有 alt，裝飾圖寫 alt=”” 而不是省略
- alt 描述的是圖片內容，不是關鍵字清單
- 每一個 img 都有 width 和 height 屬性
- 首屏主視覺沒有被設成 lazy loading
- 有資訊價值的圖都加了圖說
- 沒有把重要文字做成圖片
- 結構化資料的 image 欄位有給至少 1200 像素寬的圖
11. 常見問題
圖片 SEO 真的會影響網站排名嗎？
會，但方式是間接的。
圖片本身不會直接讓網頁排名上升，它的影響走兩條路：一是圖片過大拖慢載入速度，那會影響 Core Web Vitals 進而影響排名；二是 alt 與圖說提供了語意訊號，幫助搜尋引擎理解整個頁面在講什麼。
另外圖片搜尋本身也是一個獨立的流量來源。
alt 裡面應該放關鍵字嗎？
如果那個關鍵字剛好準確描述了圖片內容，就自然地放進去。
如果不是，就不要硬塞。
像 alt=”高雄網頁設計 高雄網站設計 高雄SEO” 這種堆砌寫法，Google 會視為操控排名的行為，而且對螢幕閱讀器的使用者是很糟的體驗。
WebP 和 AVIF 該選哪一個？
看素材。
我們實測的結果是：照片用 AVIF 明顯較優，在相近畫質下比 JPEG 品質 90 省 49%；但在圖表和網頁截圖上，AVIF 和 WebP 的檔案大小幾乎一樣，這時 WebP 因為瀏覽器支援度較高、轉檔工具較普及，反而比較實用。
最穩的做法是用 picture 標籤同時提供兩種，讓瀏覽器自己挑。
照片可以直接存成 PNG 嗎？
不建議。
我們實測同一張 1600×1600 的照片，PNG 是 2,282 KB，JPEG 品質 90 只要 334 KB，差 6.8 倍。
PNG 適合的是圖示、線稿、需要透明背景的圖形，不適合照片。
首屏的圖片要不要 lazy loading？
不要。
首屏的主視覺通常就是 LCP 元素，設成延遲載入等於叫瀏覽器晚一點才開始下載，分數會變差。
首屏圖應該用 eager，並加上 fetchpriority=”high”。
WordPress 會自動幫圖片加 lazy，要自己確認首屏那張有沒有被誤加。
網站需要圖片 sitemap 嗎？
多數網站不需要。
只要圖片是用標準 img 標籤寫在 HTML 裡，Google 順著頁面就找得到。
真正需要的是圖片靠 JavaScript 動態載入、圖片放在不同網域或 CDN、或者圖片本身就是內容主體（攝影作品集、商品目錄）這三種情況。
12. 這篇的實測是怎麼做的
第 4 章的數據是我們自己跑的，不是引用來的。
測試日期 2026 年 8 月 11 日，工具是 Python Pillow 12.2.0，WebP 與 AVIF 編碼器皆為 Pillow 內建，SSIM 由 scikit-image 0.26.0 計算。
三種素材分別是：scikit-image 內建的公開測試影像放大為 1600×1600（代表照片）、我們用 Chromium 實際截圖的圖表頁（代表大量文字的截圖）、以及我們用 matplotlib 產生的價格分布圖（代表大面積純色的圖表）。
每一種各輸出 11 種格式與品質組合，共 33 筆。
有一件事這份實測沒有涵蓋：PageSpeed 分數。
那需要對真實網址執行，而且實際載入時間還受主機、CDN 與快取影響，不是單純的檔案大小問題。
我們把這一塊留白，而不是拿別人的數字充數。
圖片格式的生態變化很快，AVIF 的瀏覽器支援度和編碼器效率每年都在動。
這份數據是 2026 年 8 月的狀態，之後我們會回來重跑並更新日期。
想把整站的 SEO 一次盤點過，我們另外整理過高雄 SEO 費用的實際行情與工作項目；想直接找人做，可以看我們的網站服務。
