Image optimization for SEO is two jobs. The first is discoverability: Google has to find, crawl and understand each image, which means real <img> tags, descriptive file names, useful alt text and nearby text that explains the picture. The second is performance: the image has to load fast without hurting Core Web Vitals, which means modern formats like WebP or AVIF, the right size for each screen, width and height attributes, and lazy-loading only below the fold.
Most guides only cover the second job. In my experience, the first job is where the quiet losses happen, because an image Google can’t see can’t rank or appear in a rich result.
Below is how I decide what each image needs. Not every picture deserves the same treatment.
What Does Image Optimization for SEO Actually Cover?
Google spells out its rules in the image SEO best practices page on Search Central. I group them like this:
| Job | What it affects | Main tasks |
|---|---|---|
| Discoverability | Google Images, image results in web search, rich results, Discover | <img> tags, file names, alt text, page context, image sitemap, structured data |
| Performance | LCP, CLS, page weight, crawl efficiency | Format, dimensions, srcset, lazy-loading, compression, caching |
| Rights and credit | Licensing details shown in Google Images | IPTC photo metadata or image license structured data |
If you’re a photographer, your angle is different: portfolio pages, genre pages and gallery text. I cover that in SEO for photographers. This guide is the general technical side that applies to any site.
Four Questions That Decide What Each Image Needs
Before touching a single file, I ask four questions about the image:
- Is it above the fold? If it’s the first big thing on screen, it’s probably your LCP element, so speed rules change.
- Should it rank on its own? Product photos, original diagrams and recipe shots can bring Google Images traffic. Stock backgrounds and icons won’t.
- Do you own it and license it? Then licensing metadata is worth the effort.
- Which platform serves it? WordPress and Shopify already handle part of this, so you only fix the gaps.
If the image is above the fold, load it eagerly and give it priority. If it should rank, put most of your effort into discoverability. If it’s purely decorative, skip the SEO work, give it empty alt text and make it small.
Part 1: Make Images Discoverable
Use a Real img Element, Not a CSS Background
Google’s documentation says it finds images in the src attribute of <img> elements and does not index CSS images. Many themes place hero banners and product shots as background-image. Those look fine to people and stay invisible to Google Images.
If an image matters for search, it belongs in the HTML. Here’s the markup I start from:
<img src="/images/blue-ceramic-coffee-mug-350ml.webp"
width="1200" height="900"
alt="Blue ceramic coffee mug with a speckled glaze on a wooden table">
Name Files the Way You’d Describe Them
Google’s guide recommends short, descriptive file names and gives my-new-black-kitten.jpg as a better example than IMG00023.JPG. File names are a light signal, but they cost nothing if you rename before upload.
My rule is simple. Lowercase, hyphens between words, describe the subject, and stop there. Renaming files after they’re live changes their URLs, so I only do it on new uploads or during a planned migration with redirects.
Write Alt Text That Describes, Not Stuffs
Alt text helps both screen reader users and Google understand the image, and Google warns against filling it with keywords. I’ve written a full guide on image alt text for SEO, including decorative images, so I’ll keep this to one line here.
Put the Image Next to the Text It Supports
Google uses the page around an image to understand it: the title, headings, captions and nearby text. A product photo inside a product description beats the same photo dropped into an unrelated gallery.
Honestly, this is the step people skip. They optimize the file and forget the page.
Add Images to Your Sitemap When Google Might Miss Them
An image sitemap helps Google find images it may not discover on its own, such as images loaded by JavaScript. Per Google’s image sitemap documentation, each page URL can list up to 1,000 images, and the images can live on a CDN domain as long as you verify both domains in Search Console:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/products/blue-ceramic-mug/</loc>
<image:image>
<image:loc>https://cdn.example.com/images/blue-ceramic-coffee-mug-350ml.webp</image:loc>
</image:image>
</url>
</urlset>
Only image:image and image:loc are supported now. Google deprecated image:caption, image:title, image:geo_location and image:license, so plugins still writing them are wasting bytes. The rest of the sitemap rules are in my XML sitemap best practices guide.
Give Structured Data and Social Tags a Proper Image
Google lets you hint at the main image with the og:image meta tag or the primaryImageOfPage property. For Article structured data, its documentation asks for images of at least 50,000 pixels (width times height) and recommends 16×9, 4×3 and 1×1 versions.
Discover is stricter. Google’s Discover guidance asks for large images at least 1,200 pixels wide, enabled with the max-image-preview:large setting, and warns against using your logo as the main image. I see logos in og:image on small business sites all the time, and it’s a five-minute fix.
Part 2: Make Images Fast
Which Image Format Is Best for SEO?
Google Images supports BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. So format doesn’t decide indexing. It decides file size, and file size decides speed. The WordPress core team describes WebP files as around 30% smaller on average than JPEG or PNG equivalents, and AVIF as up to 50% smaller than JPEG at the same quality. Those are their figures, not guarantees for your images.
| Format | Use it for | Watch out for |
|---|---|---|
| AVIF | Photos where you want the smallest file | MDN notes no progressive rendering, and it needs a fallback |
| WebP | Default choice for photos and graphics | Very old browsers only, which barely matter now |
| JPEG | Fallback for photos | Larger than WebP or AVIF at similar quality |
| PNG | Screenshots needing exact pixels | Big files for photos |
| SVG | Logos, icons, simple diagrams | Not for photos |
MDN lists AVIF in Chrome 85+, Firefox 93+ and Safari 16.1+, and recommends a fallback with the <picture> element:
<picture>
<source srcset="/images/team-at-work.avif" type="image/avif">
<source srcset="/images/team-at-work.webp" type="image/webp">
<img src="/images/team-at-work.jpg" width="1600" height="1067"
alt="Three designers reviewing a website layout on a large monitor">
</picture>
The browser uses the first format it supports. The <img> inside still carries the alt text and dimensions, and Google still finds the image through its src.
Serve the Right Size With srcset and sizes
A phone with a 400-pixel-wide screen doesn’t need a 2,400-pixel photo. srcset lists the available widths and sizes tells the browser how wide the image will display, so it can pick the smallest file that still looks sharp:
<img src="/images/garden-office-1200.webp"
srcset="/images/garden-office-600.webp 600w,
/images/garden-office-1200.webp 1200w,
/images/garden-office-1800.webp 1800w"
sizes="(min-width: 900px) 50vw, 100vw"
width="1200" height="800"
alt="Timber garden office with glass doors open onto a lawn"
loading="lazy">
That sizes value says: half the viewport on screens 900 pixels and wider, full width otherwise. Get it wrong and the browser downloads a bigger file than it needs, which is one of the most common mistakes I find in custom themes.
Always Set Width and Height
Width and height let the browser reserve space before the file arrives, so text doesn’t jump when the image loads. Pair them with max-width: 100%; height: auto; in CSS and the image stays responsive. Missing dimensions are the top cause of layout shift I see, and I explain the full fix in how to fix CLS.
Lazy-Load Below the Fold, Never the Main Image
Native loading="lazy" works in all major browsers, per web.dev’s lazy-loading guide, which lists Chrome 77+, Firefox 75+ and Safari 15.4+. Google’s lazy-loading guidance for Search adds two rules: load content when it becomes visible in the viewport, and don’t lazy-load content that’s visible right away.
Too much lazy-loading backfires. In a web.dev analysis of the performance effects of too much lazy loading, Felix Arntz and Rick Viscomi found the median page without lazy loading had a 75th percentile LCP of about 2.9 seconds, against about 3.5 seconds for the median page with it. That’s a correlation, not proof for your site, but it matches what I see.
So the hero image loads eagerly, with fetchpriority="high", and everything further down lazy-loads. If your main image is slow, my guide on how to improve LCP walks through preloading and the other fixes for it.
Compress, Cache and Use a CDN
Export at the largest size you actually display, not the camera’s original. Then compress. When I review a slow page, the first thing I check is whether a 4,000-pixel phone photo is being squeezed into a 700-pixel column. I aim for the lowest quality setting where I can’t see a difference at normal viewing size, and I check by eye, not by a fixed number.
An image CDN can resize and convert on the fly and serve files from near the visitor. Long Cache-Control headers mean repeat visitors don’t download the same image twice. For how this all shows up in your scores, see page speed vs Core Web Vitals.
Should You Add Licensing Metadata to Your Images?
Only if you own the images and want credit or licensing enquiries. Google’s image license metadata documentation offers two methods: structured data on the page, or IPTC photo metadata embedded in the file.
Google reads these IPTC fields: Web Statement of Rights, Licensor URL, Creator, Credit Line and Copyright Notice. Web Statement of Rights is the one required for the Licensable badge. If both methods are present and disagree, Google uses the structured data.
The catch? Some compression tools and image pipelines strip metadata. After optimizing, open the final file in a metadata viewer and make sure the IPTC fields survived.
How Does WordPress Handle Images?
WordPress does more than most owners realize. By default it creates thumbnail (150 px), medium (300 px), medium_large (768 px wide) and large (1,024 px) versions, plus 1536×1536 and 2048×2048 sizes, and scales down huge uploads above a 2,560-pixel threshold. Those sizes feed the automatic srcset on content images.
Format support came in steps. WordPress 5.8 added WebP uploads and 6.5 added AVIF, if your server’s image library supports it, according to the WordPress core team. Core doesn’t convert your JPEGs automatically, though. The Performance Team’s Modern Image Formats plugin does that.
Two more core behaviors matter. Since 6.3, WordPress adds fetchpriority="high" to the image it judges most likely to be the LCP. Since 6.7, it adds sizes="auto" to lazy-loaded images so the browser can pick a size from the real layout. Sliders and page builders often bypass all of this, so I check the rendered HTML on every audit.
What About Shopify?
Shopify’s image_tag Liquid filter adds width and height from the image’s dimensions and builds a srcset automatically. It does not add sizes by default, so set that yourself.
It also lazy-loads images in sections further down the page unless you pass preload: true. I covered the store-specific side, including keeping the main product image out of lazy-loading, in Shopify speed optimization.
Image SEO Decision Matrix
| If the image is | And | Then do this |
|---|---|---|
| Above the fold | It’s the largest element | Real <img>, eager load, fetchpriority="high", correct srcset |
| A product or original photo | You want Google Images traffic | Descriptive file name, alt text, near relevant text, in the sitemap |
| A CSS background | It matters for search | Move it into an <img> element |
| Loaded by JavaScript | Google may not find it | Add it to an image sitemap, test with URL Inspection |
| Your own photography | You license it | Add IPTC fields or license structured data |
| Decorative | Adds no meaning | Empty alt, small file, lazy-load if below the fold |
When Should You Get Help?
Most of this is a checklist you can work through on a small site in an afternoon. It gets harder on stores with thousands of products, themes that load everything as backgrounds, or JavaScript galleries Google can’t render.
That’s work we handle in our technical SEO service. If you’d rather know where you stand first, request a free SEO audit and I’ll show you which images Google can’t see and which ones slow your pages down.
Frequently Asked Questions
What Is the Best Image Format for SEO?
Google Images indexes JPEG, PNG, WebP, AVIF, SVG, GIF and BMP, so no format ranks better by itself. For speed, use WebP as the default and AVIF where you want smaller files, with a JPEG fallback in a <picture> element.
Do Image File Names Matter for SEO?
A little. Google’s image guide recommends short, descriptive file names because they give a light hint about the subject. Rename before upload, since changing live file names changes the image URLs.
Should I Lazy Load All Images?
No. Lazy-load images below the fold and load the main above-the-fold image eagerly. Lazy-loading the main image delays your Largest Contentful Paint.
Does Google Index CSS Background Images?
No. Google’s image SEO documentation says it doesn’t index CSS images. Any image you want in Google Images needs a real <img> element with a src attribute.
Last updated: October 2026 by Mizanur Rahman
