圖片 SEO 怎麼做？先壓縮、補文字，還是改 alt

週一下午，雲林一家做花生醬的工廠把新拍的三十張商品照放上官網。第二天經銷商打電話來，第一句不是問價錢，而是「你們網站開好久，我開兩次都以為當掉」。同一週，老闆用 ChatGPT 問「台灣無糖花生醬推薦」，回答列了三個品牌，他的品牌不在裡面。

他原本打算花錢重做網站。先打開其中一個商品頁看圖片占了多少下載量：這一頁就放了三十張圖，加起來八十幾 MB，最大的一張 5 MB；手機視窗寬 390 像素，圖片實際只顯示 358 像素寬。也就是說，客人下載了一張邊長比實際需要大十幾倍的圖。

這兩件事看起來一個是速度、一個是 AI 推薦，其實都跟圖片有關。這篇就用這家工廠從頭到尾走一次：先分辨圖片 SEO 在管什麼，再量自己的圖片，然後照順序壓縮、把圖片裡的資訊補成文字、改 alt，最後才處理檔名和圖片 Sitemap。以下是整理常見情況後的情境，數字用來對照差距，不是單一客戶的實績。

圖片 SEO 管的是兩件事：載入速度與圖片裡的資訊

圖片 SEO 是讓圖片有機會出現在 Google 圖片與一般搜尋結果，同時不讓圖片把頁面拖慢的工作。如果你還沒看過 SEO 是什麼，它管的是讓 Google 找到、讀懂、願意排出你的頁面；圖片 SEO 只是把對象換成圖片。

圖片 SEO 的工作可以分成兩塊：幫 Google 找到並索引圖片，以及把圖片所在的那一頁整理好。第一塊包含用標準的 <img> 標籤、提供圖片 Sitemap、用 srcset（同一張圖的不同寬度版本）給不同寬度；第二塊包含圖片附近的文字、替代文字（alt）、檔名，還有頁面速度。

這裡有一個很多人會漏掉的分界：Google 不會為 CSS 背景圖建立索引。它主要從 <img> 的 src、srcset 與 <source> 找圖片；如果你把商品圖設成 background-image，頁面看起來一樣，但 Google 圖片搜尋看不到那張圖。比較穩的做法是用 <picture> 包一個 <img>：srcset 與 <source> 可以提供不同格式與寬度，但保留一個 src，Google 還是看得到圖片。

另一條路是 AI 搜尋。Google 的 AI 功能文件寫得很直接：AI 摘要與 AI 模式沒有額外的技術要求，也不需要特殊的結構化資料，原本的 SEO 基本原則照做就好。裡面有一句對圖片特別重要：確保重要內容以文字形式提供，圖片與影片則拿來輔助文字。

所以圖片 SEO 處理的是同一個問題的兩面：圖片要能被找到、載得完，而且圖片裡才有的資訊不能只停在圖片裡。

先量：你的圖片占了多少頁面重量

在改任何東西之前，先量三件事：顯示寬度、檔案大小、圖片位置。

1. 顯示寬度。在手機上打開那個頁面，把視窗縮到 390 像素左右，看圖片實際占幾像素。
2. 檔案大小。用瀏覽器開發者工具的「網路」面板篩選 Img，重新整理，看每一張圖的 transferred size（實際傳輸大小）。
3. 圖片位置。分辨第一屏看得到的圖，跟要往下捲才看到的圖，因為這兩種圖的載入方式不一樣。

花生醬工廠的數字是這樣：商品頁三十張圖，合計 82 MB；其中十二張主圖每張 4–5 MB；手機上主圖顯示寬度 358 像素。這三個數字放在一起，就知道問題不在「圖片不夠漂亮」，而在「檔案大小遠超過版面需要」。

顯示寬度對應的檔案寬度

表格的數字只是起點，實際還是要看你的版面。表裡的「顯示寬度」是 CSS 像素；手機螢幕的裝置像素比常見是 2，所以 360 px 的版面需要 720 px 的檔案，3 倍密度的螢幕則要 1080 px，但檔案也會跟著變大，多數網站準備到 2 倍就夠。

真正要抓的是「不要讓手機下載桌機寬度的圖」。一張 4000 像素寬、5 MB 的手機照片，縮到 800 像素寬之後通常只剩一百多 KB，標籤上的字在手機上看還夠用；反過來說，如果你把 800 像素的圖硬放大到 2400 像素，檔案變大，畫面也不會變清楚。

先決定順序：依情況判斷先做哪一件

看到這裡，你手上應該有幾個數字：圖片總共多大、最大的幾張多大、哪些資訊只存在圖裡。接下來用這張表決定先做哪一件。表裡的 LCP（頁面主要內容出現的時間）2.5 秒是 Google 的門檻，其他數字是我自己的經驗值，你可以照自己的頁面調整。

順序不是固定的，取決於哪一件事正在擋你。如果頁面根本載不完，先改 alt 沒有意義；如果客人問的規格只存在圖裡，先把圖壓小也不會讓 AI 答得出來。

對多數只有幾十張圖的小網站，預設順序是：先壓最重的那十幾張主圖，再把三段常被問的資訊寫成文字，alt 順手改，檔名與圖片 Sitemap 等下次換圖再說。這個順序大概兩個下午就能做完。

第一步：壓縮與尺寸，先讓圖片載得完

先從效益最大的一步開始：把圖片變小。壓縮圖片有三個動作，做的順序會影響結果。

1. 縮到需要的寬度。這一步的效益最大，因為檔案的像素數量是寬乘高；把 4000 像素縮到 800 像素，長邊只剩五分之一，像素數量（面積是邊長的平方）只剩原來的 1/25，檔案通常也小一個量級。
2. 換格式。同樣的畫面，WebP 通常比 JPEG 小，AVIF 又常常比 WebP 小；Google 圖片搜尋支援 BMP、GIF、JPEG、PNG、WebP、SVG 與 AVIF，所以這幾種格式都進得去。
3. 給幾種寬度。讓手機抓小的、桌機抓大的，也就是 HTML 裡的 srcset 與 <picture>；Google 的文件建議保留一個 src 當備援，因為不是每個瀏覽器與檢索器都讀得懂 srcset。如果你用 WordPress、Shopify 或開店平台，這些尺寸通常由外掛或平台產生；你要確認的是它有沒有開啟，以及有沒有輸出比原圖小的版本。

AVIF 的檔案小，但壓縮與解碼比較慢，很舊的瀏覽器也不支援。實務上可以用 <picture> 先給 AVIF，再給 WebP，最後用 JPEG 當備援；使用者不會看到格式，瀏覽器會自己挑。

我們自己的部落格也走同一套流程。同一張正文圖，四種輸出的檔案大小差很多：

從 2.9 MB 到 165 KB，少了約 94%；那張圖在手機上只顯示 358 像素寬，720 像素的版本在 2 倍密度的手機上就夠，3 倍密度或桌機再抓 1600 像素的版本。

回到花生醬工廠，十二張主圖壓完後，每張從 4–5 MB 降到 200–300 KB，整個商品頁從 82 MB 降到 9 MB 左右。他沒有換相機，也沒有重拍，只是在上傳前把圖縮到 800 像素寬、轉成 WebP。

還有一個順序問題：首圖通常是 LCP 圖片（頁面載入時最大的那塊內容），不要加 loading="lazy"。web.dev 的延遲載入指南明確寫，頁面一載入就看得到的圖不要延遲，尤其是 LCP 圖片；要延遲的是往下捲才出現的圖。

有些圖片 SEO 教學把「開啟延遲載入」列成必做，照做在首圖上，反而會讓主要內容晚出現。圖片壓縮與 LCP 的關係，我在網站速度怎麼測裡有完整的量法。

第二步：把只存在圖片裡的資訊寫成文字

回到花生醬工廠。老闆的官網首頁寫「香濃好吃、送禮自用兩相宜」，產品頁的三十張照片裡，有五張分別是玻璃罐、標籤特寫、抹在吐司上的樣子。標籤上印著「成分：花生、鹽」「無添加糖」「淨重 250 公克」。這些字在照片裡很清楚，人看得到，但頁面的文字裡一個字都沒有。

Google 的 AI 功能文件說，重要內容要以文字形式提供，圖片與影片拿來輔助文字。這句話不是在說圖片不重要，而是在說圖片不能取代那段說明。Google 會用電腦視覺讀圖片，也會看圖片旁邊的文字；但圖片裡的字認得出來，不等於有一段話可以直接放進回答，或拿來跟其他品牌比較。

所以當有人問 AI「台灣無糖花生醬推薦」，他的頁面沒有「無糖」這個詞，也沒有一段文字說明成分。系統就算從標籤照片讀到那幾個字，也不一定會把「成分只有花生與鹽」變成一句可以引用的推薦理由；頁面沒有寫，等於把這件事交給機率。

AI 回答沒有提到一家公司，原因不會只有圖片。網頁有沒有被索引、品牌有沒有在其他地方被提到、問題怎麼問，都會影響結果；這篇只處理圖片這一塊。

圖片上的資訊，正文要補哪一句

不是把圖上的字全部打出來。只補讀者會拿來比較、詢問的欄位；包裝上的品牌故事、產地插畫不用。同一個資訊，圖片與文字各放一次，但不要互相取代；圖片讓人一眼看懂，文字讓搜尋與 AI 有東西可以抓。

這一步還有一個副作用是好的：看不到圖的人、網路很慢載不出圖的人，終於讀得到成分。alt 寫得再好，也補不回正文沒寫的那一句「成分只有花生與鹽」。

第三步：alt 描述圖片，不是塞關鍵字

alt 是圖片替代文字，畫面載不出來或使用者用螢幕閱讀器時，會讀出這段字。Google 的圖片 SEO 文件說，alt 是圖片中繼資料裡最重要的屬性，Google 會用 alt、電腦視覺演算法與網頁內容來理解圖片主題，也明確把「在 alt 塞大量關鍵字」列為濫填，可能被當成垃圾內容。

花生醬工廠原本的 alt 有三種寫法，效果差很多。

alt="花生醬"：只知道這是一罐花生醬。

alt="花生醬 無糖 推薦 台灣 伴手禮 花生醬"：關鍵字重複，Google 文件把這種寫法列為濫填。

alt="玻璃罐裝的無糖花生醬，標籤上寫著成分只有花生與鹽，淨重 250 公克"：描述畫面，也帶到讀者要的資訊。

三種圖片，三種寫法

如果旁邊的段落已經寫了成分，alt 不用再重複一次。alt 描述那張畫面，用途跟關鍵字欄位、整段文案都不一樣。圖表尤其容易寫錯：只寫「長條圖」等於沒寫，讀者不知道在比什麼。寫法的細節我在 SEO 文章怎麼寫裡有另一段例子。

第四步：檔名、圖片 Sitemap 與周邊文字

檔名有用，但它的重要性比很多人想的低。Google 的文件說，檔名可以讓 Google 透過「非常細微的線索」推斷圖片主題，建議用簡短明瞭的名稱，my-new-black-kitten.jpg 比 IMG00023.JPG 好。注意它用的詞是「非常細微的線索」，不是一個可以單獨拿來操作排名的地方。檔名值得在下次換圖時順手改，不值得為它把三百張圖重新命名。

圖片 Sitemap 也一樣。它的用途是提供 Google 找不到的圖片網址，例如放在 CDN、由 JavaScript 產生、或頁面上沒有內部連結的圖。如果你的圖片都用 <img> 放在頁面裡，Google 通常找得到，三十張圖的工廠不用先做；上百張、常換、放 CDN 的店再排進來。

回到工廠：他沒有回頭改那三十張圖的檔名，因為改完的效益比不上把成分寫清楚；下一次換圖時，再從 IMG_2043.JPG 改成 wutan-peanut-butter-250g.jpg 就好。

比檔名更值得花時間的是圖片旁邊的文字。Google 會從說明文字、標題與附近段落擷取圖片主題的資訊，所以把圖片放在相關段落旁邊，比在檔名裡塞關鍵字有效。圖片下面那行說明，讀者也看得到，一舉兩得。

結構化資料是最後一件事。圖片加上標記，可以讓圖片出現在複合式搜尋結果（搜尋結果裡加上圖片或評分等樣式的區塊），但它是加分項，不是圖片 SEO 的必要步驟；先把圖片大小、alt 與旁邊的文字處理好，再談標記。

改完怎麼確認，不要只看排名

1. PageSpeed Insights 的手機 LCP。同一個網址、同一個裝置類型，改前改後各跑一次；Google 把 2.5 秒以內算好，但你要看的是自己的前後差距，不是跟別人比。
2. Search Console 的圖片搜尋。成效報表的搜尋類型選「圖片」（Search Console 教學），看曝光與點擊有沒有開始出現；這代表圖片開始進到圖片搜尋，跟一般搜尋的排名是兩件事。
3. AI 回答。同一個問題、同一個引擎、同一天問，記錄回答有沒有出現你的品牌，以及有沒有講到「無糖」這個規格。AI 的回答每次都可能不一樣，所以看重的是有沒有出現，不是第幾名。

這三個數字更新的速度不一樣：PageSpeed 幾分鐘就能重跑，Search Console 要等幾天才累積，AI 每次問又不同。分開記，不然你會把「還沒更新」當成「沒效果」。

花生醬工廠最後沒有重做網站。他壓了十二張主圖、補了三段成分與容量說明、把 alt 重寫，花了兩個下午；一個月後，圖片搜尋的曝光開始出現，AI 回答則還不穩定：同一個問題問三次，有一次提到成分，兩次沒有。這就是 AI 搜尋的常態，做完不保證每次都被引用；他要解的問題是「客人開得完、AI 有東西可以答」，排名只是後面的結果。

如果你正在重做官網，圖片尺寸與載入順序可以在開發時一起定下來，不用上線後再補。

常見問題

參考來源

• Google 圖片搜尋引擎最佳化 (SEO) 的最佳做法
• AI 功能和您的網站
• 瀏覽器層級圖片延遲載入
• 圖片 Sitemap
• Core Web Vitals：LCP 的 2.5 秒門檻
• PageSpeed Insights
• Search Console 成效報表