圖片 SEO 與視覺搜尋完整指南：讓網站圖片被搜到

商品照拍好了、alt 也填了，圖片卻沒有出現在 Google Images；使用者拿 Google Lens 搜尋同款商品時，結果裡也找不到你的頁面。問題通常不只在圖檔。Google 會把圖片本身、alt、檔名、圖片附近的文字、所在頁面的主題與其他網頁訊號放在一起判斷。只改一個欄位，很難補齊整條理解路徑。

圖片 SEO（image SEO）是讓網站上的圖片更容易被 Google 發現、索引、理解，並有機會出現在 Google 搜尋、Google Images 與 Google Discover 的一套做法。Google 的圖片最佳實踐適用於這些不同的搜尋呈現；至於 Google Lens，它是使用圖片發動查詢的視覺搜尋工具，結果機制不能直接等同 Google Images 排名。想先補齊一般 SEO 架構，可以對照我們的 SEO 完整指南。

核心重點：Google 會用 alt、電腦視覺演算法與頁面內容理解圖片。圖片 SEO 要處理的是發現、理解、呈現與載入體驗，不是把 alt 填滿關鍵字（依 Google 的圖片 SEO 最佳實踐）。

先把邊界畫清楚：圖片 SEO、影片 SEO、YouTube SEO 是三件事

圖片 SEO 處理網站頁面裡的圖片，以及它們在 Google 圖片相關搜尋介面的能見度。影片 SEO 處理放在自有網站上的影片與承載影片的頁面，相關做法可看 影片 SEO 指南。YouTube SEO 處理 YouTube 平台內的影片發現與觀看，操作介面與資料來源都不同，可看 YouTube SEO 指南。

三者可以一起做，但量測時要分開。自有網站上的圖片與影片，可以調整 HTML、頁面內容、結構化資料、sitemap 與效能；YouTube 頁面則受平台格式限制。圖片與影片都牽涉檢索、索引與搜尋結果呈現，結構化資料的基本觀念可對照 結構化資料指南。

Google 怎麼「看懂」一張圖：alt、檔名、周邊文字與電腦視覺

根據 Google 的圖片 SEO 文件，Google 會從圖片所在頁面的內容擷取圖片主題資訊，包含 caption 與 image title，因此建議把圖片放在相關文字附近，頁面本身也要和圖片主題一致。一張木桌照片放在材質說明旁邊，和放在不相干的公司沿革頁，能提供的脈絡完全不同。

alt 是 Google 官方文件所稱「提供更多圖片中繼資料時最重要的屬性」。Google 會把 alt、電腦視覺演算法與頁面內容合在一起理解圖片，也提醒網站不要在 alt 堆砌關鍵字，否則會傷害使用體驗，網站還可能被視為垃圾內容。官方範例中，alt="Dalmatian puppy playing fetch" 比 alt="puppy" 更完整，因為它直接描述畫面。

寫商品圖 alt 時，描述讀者看不到圖片後會缺少的資訊。以北歐風橡木書桌為例，alt="桌子" 太空泛，alt="橡木 書桌 北歐 家具 木桌" 是關鍵字清單，alt="白色牆面旁的北歐風橡木書桌，桌面放著黃銅桌燈" 才交代了主體與畫面。若同一張圖出現在不同頁面，描述也可依使用情境調整；商品頁偏向辨識款式，教學頁則描述該圖在步驟中傳達的內容；這些替代文字撰寫原則出自 W3C 的 Images Tutorial。純裝飾圖通常應使用空的 alt=""，不要硬塞關鍵字。

alt 也不是 caption 的替代品。alt 在圖片無法顯示或使用輔助科技時提供替代內容；caption 是所有讀者都看得到的圖片說明。資訊圖表若包含讀者完成任務所需的數字或流程，只寫「SEO 成效圖表」仍不夠，應在 alt 或附近正文交代圖表要傳達的結論，複雜資料則可提供完整文字版。連結圖片還要讓替代文字說明連結目的，避免只描述圖案外觀。這些做法先解決可理解性，再考慮搜尋關鍵字；alt 與 caption 的分工整理自 W3C 的 Images Tutorial。

檔名在 Google 官方說明中只算「非常輕微的線索」。短而具體的 my-new-black-kitten.jpg 比 IMG00023.JPG 好，但不要把檔名當成主要排名槓桿。Google 能從 <img> 的 src 屬性發現圖片，也支援 <picture> 裡的 <img>；CSS background-image 不會被 Google 索引。Google Search 目前支援 BMP、GIF、JPEG、PNG、WebP、SVG 與 AVIF；支援格式的清單見 Google 的圖片最佳實踐。

EXIF 不適合被包裝成圖片排名技巧。Google 在 2012 年的 Search Central 文章〈1000 Words About Images〉曾說，可能使用圖片裡找到的資訊協助使用者搜尋，也可能在當時的圖片介面顯示 EXIF；那不是排名效果承諾。現行官方圖片 SEO 文件沒有把 EXIF 列為排名要求；圖片中繼資料文件明確支援的是結構化資料、IPTC 相片中繼資料，以及符合條件的 C2PA 資訊。沒有官方依據能斷言 Google 已完全不讀 EXIF，也沒有依據能把保留 EXIF 說成排名方法。授權或來源資訊要依 Google 的圖片中繼資料文件現行支援的 IPTC、C2PA 與結構化資料規格處理。

Google Lens 與 multisearch：把圖片變成一種查詢

Google 在 2022 年 4 月推出 multisearch，讓使用者在 Google App 裡用相機拍照或選擇截圖，再加入文字縮小搜尋範圍。Google 在 2022 年 I/O 主題演講（Sundar Pichai）中表示，當時 Lens 每月搜尋量已超過 80 億次；2024 年 Google 公布的數字已接近每月 200 億次，其中約 20％和購物有關。

這些數字說明視覺查詢的使用量，不代表網站只要補完 alt 就能獲得 Lens 流量。Google 沒有發布一份給站長操作的「Lens 專屬排名因素清單」。官方在 Lens 運作方式頁面公開的機制是：Lens 會比較照片裡的物件與其他圖片，依視覺相似度及相關性排序，也會參考圖片代管網站上的文字、語言與中繼資料；若回傳 Google Search 或 Shopping 的結果，會沿用那些產品各自的排序演算法。圖片 SEO 能做的是改善 Google 發現與理解圖片的條件，不能保證 Lens 排名或曝光。AI 搜尋與一般 SEO 的關係，可延伸閱讀 AI SEO 指南。

這也解釋了為什麼「把商品拍得更像搜尋目標」不能取代頁面資料。Lens 可能找到視覺相似圖片，也可能在辨識出特定商品後回傳商品資訊；兩種結果的資料組成不同。站長能控制的是圖片是否可檢索、承載頁是否公開、商品名稱與識別碼是否正確、圖片旁的文字是否對得上，以及 Product 資料有沒有反映頁面上真的看得到的內容。至於 Lens 對某次查詢選了哪個物件、產生幾個候選結果、如何調整各訊號權重，官方沒有提供可操作設定（機制說明見 Lens 的運作方式頁面）。

Google Lens 怎麼把一張照片變成搜尋結果

Lens 的公開流程可以安全地說成兩層。輸入層接受相機畫面、照片、截圖或其他圖片，各種搜尋方式可見 Google 的 Lens 使用介紹；multisearch 還能加入文字，部分介面也能用語音提問。結果層會找視覺上相似的圖片及相關網頁，辨識到文字、條碼或明確物件時，也可能回傳對應的 Google Search 或 Shopping 結果（流程說明見 Lens 官方頁面）。

「模型先把圖轉成一組文字標籤與候選查詢，再查圖片索引、Shopping Graph 與知識圖譜」講得太滿。Google 沒有公開一套適用所有 Lens 查詢的固定三步內部架構，也沒有說每次 Lens 查詢都會經過知識圖譜。能確認的是，購物情境確實會用 Shopping Graph。Google 在 2024 年的視覺搜尋購物說明中指出，Lens 會結合 AI 模型與 Shopping Graph 裡超過 450 億項商品，提供價格、優惠、評論與購買通路等資訊。Shopping Graph 的使用範圍也不等於每一種 Lens 結果的通用資料來源。

Google 目前的 Lens 官方頁面列出文字複製與翻譯、植物與動物辨識、地點與菜單探索、商品搜尋、視覺相似圖片等用途；Lens 產品頁也保留作業協助，Google 的功能介紹則列有地標、餐點附近搜尋，以及肌膚狀況的相似圖片搜尋。肌膚搜尋只在特定市場提供，官方明確說它是比對公開網路圖片，不是醫療分析或診斷。各項功能也會受國家、語言、裝置與入口影響，不宜把整份清單說成台灣每位使用者都能使用。Google Lens 的購物結果適用地區清單目前也沒有列出台灣（地區與功能限制見 Lens 運作方式頁面）。

網站端能直接控制的仍是一般搜尋資料。商品頁可提供正確的 Product 結構化資料或 Merchant Center 資料；Google 官方說，產品資訊有機會出現在 Google Search、Google Images 與 Google Lens，但實際呈現不保證。知識型文章則要讓圖解、alt、caption 與附近文字互相對得上。不要為 Lens 另造一套沒有官方依據的標籤。

商品資料還要分清楚兩條來源。Product 結構化資料放在商品頁 HTML 裡，Google 可用它理解頁面上的價格、供應狀態、評分或運送資訊；Merchant Center 則用商品資料來源提供更完整、更新頻率更高的零售資料。Google 在 Product 結構化資料說明中建議兩者並用，因為這能提高資格並協助核對資料，但兩邊的價格與庫存若互相矛盾，反而會造成資料品質問題。這是商品搜尋的資料工程，不是 Lens 快速排名技巧。

ImageObject 結構化資料：描述圖片與授權資訊

Schema.org 的 ImageObject 是描述圖片的詞彙，不是圖片排名開關。它的繼承關係是 Thing > CreativeWork > MediaObject > ImageObject，ImageObject 直接定義 caption、embeddedTextCaption、exifData、representativeOfPage 四個屬性，也會繼承 contentUrl、encodingFormat、width、height、uploadDate、license、creator 等屬性。Schema.org 告訴你有哪些詞可用；Google 支援哪些欄位、哪些是 required 或 recommended，要以對應的 Google 功能文件為準。

若頁面有多張圖，可以用三種 官方支援的中繼資料提供首選圖片：在 WebPage 使用 primaryImageOfPage；把 image 掛在頁面主實體上，搭配 mainEntity 或 mainEntityOfPage；或設定 og:image。這些資料會影響 Google 自動選擇預覽圖，但不是強制指定。圖片應與頁面相關、有足夠解析度，並避開網站 logo、文字塞滿畫面的圖片與極端長寬比。

圖片授權功能有另一套明確規則。若用 ImageObject 結構化資料提供 Google 圖片中繼資料，必要欄位是 contentUrl，再從 creator、creditText、copyrightNotice、license 至少選一個。若目標是取得 Google Images「可授權」徽章的資格，還必須有 license；acquireLicensePage 是有資料時建議提供的欄位。

同一張圖出現在多個頁面時，結構化資料要在每個使用位置都標記。IPTC 相片中繼資料是嵌入圖片本身，一張圖嵌一次即可；兩者衝突時，Google 以結構化資料為準。欄位填對只代表圖片符合功能資格，Google 不保證一定顯示中繼資料或徽章；這些規則出自 Google 的圖片中繼資料文件。

實作時先問「要取得哪個 Google 功能資格」，不要看到 ImageObject 有幾十個繼承屬性就全部填滿。一般文章若只想提供首選預覽圖，可以在 Article 或 BlogPosting 的 image 放 URL 或 ImageObject；需要顯示作者、署名與授權資訊時，才依圖片中繼資料文件補 contentUrl、權利相關欄位與授權網址。頁面可見內容也要與標記一致，不能只在 JSON-LD 裡宣稱一個使用者看不到的作者或授權條款。

也不要把 representativeOfPage 和 primaryImageOfPage 混為一談。前者是 ImageObject 上的布林屬性，用來描述該圖片是否代表頁面；後者是 WebPage 的屬性，用 URL 或 ImageObject 指向主要圖片。Google 的現行圖片最佳實踐明確列出 primaryImageOfPage、主實體的 image 與 og:image，作為提供首選圖片的三種方式；沒有要求三種全部同時使用。

圖片 Sitemap：讓 Google 找到你的圖片

圖片 sitemap 可以告訴 Google 網站上有哪些圖片，特別適合補充 Google 原本不容易發現的圖片，例如由 JavaScript 觸及的圖片。可以建立獨立的圖片 sitemap，也可以在現有 sitemap 加入圖片標記，兩種方式都可行，詳細作法見 Google 的圖片 sitemap 文件。使用的命名空間是 http://www.google.com/schemas/sitemap-image/1.1。

現行文件只有兩個必要的圖片標記：<image:image> 包住單張圖片資訊，每個 <url> 最多可放 1,000 個；<image:loc> 填圖片網址。過去常見的 <image:caption>、<image:title>、<image:geo_location>、<image:license> 已從文件移除並列為 deprecated，不要再把它們當成建議欄位。

<image:loc> 可以使用不同網域的圖片網址，例如 CDN。Google 在 圖片 sitemap 說明中要求主站與圖片網域都在 Search Console 驗證，robots.txt 也不能擋住想索引的內容。sitemap 只能協助發現網址，不保證索引。網站檢索與 sitemap 的整體做法，可看 技術 SEO 指南。

最小結構是在每個頁面網址的 <url> 裡放圖片項目，例如：<url><loc>https://example.com/product/desk/</loc><image:image><image:loc>https://cdn.example.com/desk-oak.webp</image:loc></image:image></url>。外層 loc 是承載圖片的頁面，image:loc 才是圖片檔。若商品有多張角度照，可以在同一個 url 下放多個 image:image。不要只提交一串圖片網址而漏掉承載頁關係；結構範例見 圖片 sitemap 文件。

圖片網址要穩定。相同圖片若在不同頁面反覆出現，Google 的圖片最佳實踐建議持續引用同一個 URL，讓快取可以重複使用，不必每次重新請求。圖片更新若會改變網址，網站也要同步更新 HTML、結構化資料與 sitemap，避免三處各指向不同版本。

頁面速度與格式：LCP、WebP／AVIF、響應式，首圖不要 lazy-load

圖片常是頁面的 Largest Contentful Paint（LCP）元素，但 LCP 不只看檔案大小，也會受伺服器回應、資源發現時間、下載時間與渲染延遲影響。先從 PageSpeed Insights、Chrome DevTools 或實際使用者資料確認瓶頸，再決定是壓縮、預載、調整 HTML，還是處理伺服器。

可能成為 LCP 的首屏圖片不要使用 loading="lazy"。lazy-load 會等版面計算後才確認圖片接近可視範圍，可能造成不必要的載入延遲。對確實可能是 LCP 的 <img>，可測試 fetchpriority="high"；它是優先順序提示，不是保證，也不該套在大量圖片上；原則出自 web.dev 的 LCP 優化指南。首屏外的圖片才適合用 loading="lazy"。

「不要 lazy-load」只解決延後請求，沒有處理資源太晚被發現的問題。若 LCP 圖片由 JavaScript 動態插入、藏在外部 CSS，或把真正網址放在 data-src 等自訂屬性，瀏覽器必須先執行程式或下載樣式表，才知道圖片在哪裡。能直接寫在初始 HTML 的 <img src> 應直接寫；必須使用 CSS 背景的設計，可評估在 <head> 預載該資源。每次修改都要看網路瀑布圖與實際 LCP，而不是只檢查標記有沒有出現（作法整理自 web.dev 的 LCP 優化說明）。

WebP 與 AVIF 可能比 PNG 或 JPEG 有更好的壓縮效率，但結果取決於圖片內容、編碼器與品質設定，仍要用自己的素材比較。srcset 可提供不同寬度的圖片，sizes 告訴瀏覽器在不同版面下預計顯示多大，避免把桌面大圖直接送到小螢幕；圖片效能原則見 web.dev 的圖片效能指南。格式與工具可延伸閱讀 圖片格式指南及 圖片壓縮工具。

在 <img> 標上 width 與 height，或用 CSS aspect-ratio 預留空間，可避免圖片載入後把下方內容推開，減少版面累積位移（CLS）；作法整理自 web.dev 的 CLS 優化說明。依 Google 的頁面體驗說明，Core Web Vitals 確實由 Google 排名系統使用，但高分不保證排在前面，頁面體驗也不是單一訊號。

首屏外的響應式圖片可寫成：<img src="desk-960w.jpg" srcset="desk-480w.jpg 480w, desk-960w.jpg 960w, desk-1600w.jpg 1600w" sizes="(max-width: 600px) 100vw, 50vw" width="1600" height="1067" alt="北歐風橡木書桌" loading="lazy">。瀏覽器可依版面挑選尺寸，width 與 height 預留比例，loading 延後首屏外圖片。若這張圖是 LCP 候選，就拿掉 loading="lazy"，再量測是否需要 fetchpriority="high"。

srcset 與 sizes 常見的錯誤，是產生了三種檔案尺寸，sizes 卻仍寫成整個視窗寬，瀏覽器便可能選到比版面需要更大的檔案。先確認圖片在各斷點的實際 CSS 寬度，再寫 sizes。使用 <picture> 提供 AVIF、WebP 與 fallback 時，仍要保留帶 src 的 <img>，因為 Google 官方文件要求以它作為不支援 picture 或 srcset 時的備援。

圖片落地頁與授權：不同用途，不同重點

商品頁的產品圖要和商品名稱、型號、顏色及可見的商品資訊一致。Product 結構化資料可讓價格、供應狀態、評分等資訊有機會以更豐富的方式出現在 Google Search、Google Images 與 Google Lens，但仍須符合對應欄位與內容規範。電商頁面的整體規劃可看 電商 SEO 指南。

教學文章的圖解與截圖要靠近對應步驟，alt 描述圖中對完成任務有用的內容；有必要時再補 caption。WordPress 網站則要把檔名、alt、尺寸、格式、壓縮與 lazy-load 分工放進發布流程，而不是文章上線後才逐張補救。相關工具可看 WordPress 圖片優化。

攝影、圖庫與媒體網站可用 license、acquireLicensePage、creator、creditText、copyrightNotice 說明授權及署名。AI 生成或合成圖片也可使用 IPTC Digital Source Type；Google 目前支援的值包含 trainedAlgorithmicMedia、compositeSynthetic、algorithmicMedia 與 compositeWithTrainedAlgorithmicMedia。這些欄位用來交代來源與權利資訊，不是排名保證。

授權頁本身也要讓人看得懂。license 應指向描述圖片使用條款的頁面，acquireLicensePage 則指向取得授權資訊、選擇使用權或聯絡授權方的頁面。兩個網址可以相同，也可以分開，但用途不能用一段模糊的「版權所有」帶過。若圖片沒有對外授權，不要為了徽章捏造授權流程；照實提供創作者、署名或著作權聲明即可，欄位定義見 Google 的圖片中繼資料說明。

為什麼我的圖在 Google Images 搜不到：一張診斷清單

alt 寫得再好，Google 若找不到圖片或不能存取承載頁面，圖片仍不會正常進入搜尋流程。建議依下列順序排查。

1. 檢查 HTML。要被 Google 發現的圖片應出現在 <img src>，也可以放在 <picture> 裡，但仍要有帶 src 的 <img> 作為 fallback。CSS background-image 不會被索引；圖片發現規則見 Google 的圖片最佳實踐。
2. 檢查檢索與索引規則。確認 robots.txt 沒有封鎖 Googlebot-Image 或圖片網址。圖片檔也能透過 HTTP 回應標頭使用 X-Robots-Tag: noindex（規格見 Google 搜尋中心說明），若誤設就會阻止索引。
3. 檢查圖片承載頁。用 Search Console「網址審查」查看 Google 是否能存取及轉譯該頁。登入限制、robots.txt、noindex 或無法轉譯的 JavaScript 都可能讓 Google 缺少圖片及其脈絡。
4. 檢查圖文是否一致。圖片附近的文字、caption、image title 與整頁主題都會影響 Google 對圖片的理解。不要把同一段商品關鍵字複製到所有圖片。
5. 補圖片 sitemap。把 Google 不容易發現的圖片網址放進 sitemap，尤其是由 JavaScript 觸及或位於較深頁面的圖片。這能協助發現，不代表一定收錄。
6. 留出重新檢索時間。Google 官方文件提醒，頁面發布後可能要幾天才會被發現與檢索；更新中繼資料後也要等待重新檢索及索引。

排查時一次只改一組問題。若圖片根本被 robots.txt 擋住，先解除封鎖並確認 Google 能抓取，不必同時重寫全站 alt；若圖片已經有曝光但點擊沒有跟上，再回頭檢查縮圖辨識度、承載頁主題與查詢是否相符。結構化資料測試通過，也只代表語法與必要欄位符合工具檢查，不代表圖片已被檢索、已進入索引，或一定會顯示複合式結果。

圖片更新後也要檢查網址與快取策略。若新舊圖片共用同一 URL，CDN 或瀏覽器快取可能讓你短時間仍看到舊版本；若每次改圖都換 URL，HTML、sitemap、結構化資料與社群預覽設定要一起更新。沒有必要時，讓同一資產維持穩定網址，比在不同頁面複製多個內容相同、名稱不同的檔案更容易維護。發布紀錄最好留下舊網址、新網址、變更日期與對應頁面，後續看到曝光波動時才有資料可查。

怎麼量測圖片 SEO 成效：用 Search Console 看圖片流量

在 Google Search Console 開啟「成效」中的搜尋結果報表，點選頁面上方的「搜尋類型」，把預設的「網頁」切換成「圖片」並套用，就能查看圖片搜尋的總點擊次數、總曝光次數、平均點閱率與平均排名。表格可用「查詢」與「網頁」等分頁拆開分析；實際中文標籤可能隨介面語言調整。

「網頁」分頁顯示的是使用者點擊圖片結果後抵達的承載頁，不是圖片檔網址。Search Console 也不區分同一頁上的不同圖片；同一承載頁的圖片會以該頁網址計算。只點開縮圖不算點擊，從展開圖片點到網站才會計入。圖片搜尋的平均排名還會受畫面寬度與每列圖片數影響，因此較適合看一段時間的趨勢，不要把單次名次當成固定座標（指標定義見 Search Console 說明）。

實際分析可以從承載頁開始。先把日期拉到能涵蓋修改前後的區間，在圖片搜尋類型下找曝光增加或下降的網頁，再點進單一網頁查看對應查詢。若同一頁放了多張圖片，Search Console 無法告訴你是哪一張帶來曝光，這時要回到搜尋結果、頁面內容與圖片版本逐一核對。查詢資料也可能因隱私保護而省略，表格列加總不一定等於圖表總數（資料分組的口徑見 Search Console 說明）。

修改前最好留下可比對的日期與項目，例如更換首圖、重寫 alt、解除 Googlebot-Image 封鎖、補 Product 資料或提交圖片 sitemap。排名與曝光同時受查詢需求、競爭頁面及 Google 系統變化影響，時間相近不等於單一修改造成結果。觀察時先看曝光與點擊趨勢，再用平均排名協助解釋，不要用一兩天資料宣布成效（常見分析任務可對照 Search Console 的使用情境說明）。

從地基往上疊：五個圖片 SEO 落地動作

如果網站圖片很多，不必同時重做全部。先處理帶來營收或自然流量的頁面，再把規則放進新內容流程。

盤點時可把圖片分成四組：主要商品與服務圖片、已經有圖片曝光的文章圖、影響 LCP 的首屏圖、其餘裝飾或低流量圖片。前兩組先處理內容與搜尋資料，第三組先處理載入，第四組只要確保不妨礙可及性與效能。這樣比全站逐張重命名更容易驗證，也不會把時間花在本來就不需要被搜尋的裝飾圖。

1. 讓圖片可被發現。使用帶 src 的 <img>，補上符合用途的 alt，檔名短而具體；純裝飾圖使用空 alt。
2. 把圖放在相關文字附近。頁面、段落、caption 與圖片要談同一件事，避免每張圖套用相同關鍵字。
3. 只在需要的功能使用 ImageObject。若要提供 Google 圖片中繼資料，填 contentUrl，並至少提供 creator、creditText、copyrightNotice、license 其中一項；要爭取可授權徽章，license 才是必要欄位，acquireLicensePage 則是建議欄位。
4. 提交精簡的圖片 sitemap。使用 <image:image> 與 <image:loc>，不要再填 deprecated 標記。若圖片放在 CDN，驗證主站與圖片網域並檢查 robots.txt。
5. 分清楚首屏與首屏外圖片。LCP 候選圖不要 lazy-load；首屏外圖片才使用 loading="lazy"。測試 WebP／AVIF、srcset 與 sizes，並用 width、height 或 aspect-ratio 預留版面。

圖片 SEO 最常被誤判的六個機制

下表把常見做法和官方文件真正能支持的效果放在一起看。

常見做法	實際風險與效果
把 alt 當關鍵字容器，堆滿同義詞	alt 很重要，但關鍵字堆砌會傷害使用體驗，也可能讓網站被視為垃圾內容。應描述圖片在當下頁面傳達的資訊。
在圖片 sitemap 填 caption、title、geo_location、license	四個標記已列為 deprecated。現行必要的圖片標記只有 image:image 與 image:loc。
為了省流量，對 LCP 圖片套 lazy-load	這會延後重要資源的發現與載入。首屏外圖片才適合 lazy-load；fetchpriority 也要量測後使用。
用 CSS background-image 放首圖或重點圖	Google 不索引 CSS 圖片。要讓圖片進入 Google 圖片索引流程，應使用帶 src 的 img。
圖片不標 width 與 height，只靠載入後撐開版面	瀏覽器無法提早預留空間，可能造成 CLS。可用 width、height 或 CSS aspect-ratio 指定比例。
封鎖 Googlebot-Image，或讓圖片回傳 noindex	Google 無法檢索或索引圖片。若圖片本來就不該出現在搜尋結果才使用這些控制方式。

AI 在圖片 SEO 裡的位置

AI 可以先草擬 alt、檔名與 caption，但發布前要由人核對圖片內容與頁面脈絡。模型若把包包看成鞋子，或自行補上畫面裡沒有的材質與型號，錯誤資訊會同時誤導使用者與搜尋系統。大量產生內容本身不是唯一判斷點；依 Google 的生成式 AI 內容指引，Google 警告的是利用生成式 AI 或其他工具大量建立沒有使用者價值的頁面，這可能違反 scaled content abuse 政策。

適合交給人判斷的項目包括：圖片是否真的有資訊功能、應放在哪個段落、alt 要描述什麼、是否需要 caption、哪張圖能代表頁面，以及授權資料是否正確。這些決定依賴內容目的，不是辨識模型看得到物件就能自動完成。

大量圖片網站若要自動化，可以讓系統先產生候選文字，再設計人工抽查與錯誤回報。商品名稱、顏色、型號可從可靠的商品資料帶入，畫面描述由視覺模型草擬，但不要讓模型自行猜測材質、尺寸、用途或授權狀態。發布流程還要保留空 alt 的選項，否則系統會替每一個分隔圖示和背景裝飾生成沒有用途的描述。

結語：把圖片的搜尋條件補完整

圖片 SEO 沒有一個能單獨決定排名的欄位。可執行的工作很具體：讓 Google 找得到圖片，提供準確的 alt 與圖文脈絡，依功能需求使用結構化資料和圖片 sitemap，再把 LCP、CLS 與響應式尺寸顧好。這些做法能改善發現、理解與呈現條件，但不保證索引、排名或 Lens 曝光。各項工作的細節，可以對照讓圖片被 Google 看懂的完整做法逐一落實。

如果你不確定該先處理哪一批圖片，可先從 Search Console 已有圖片曝光的承載頁、主要商品頁與流量較高的文章開始。Whoops 也提供圖片檢查、alt 與結構化資料實作、圖片 sitemap、Product 資料及 Core Web Vitals 優化服務，協助把問題拆成可驗證的修改項目。