Image SEO: Alt Text, File Names, Compression and Everything Else That Actually Matters

One image tag, annotated: file name, alt text, dimensions, responsive set and lazy loading are all things Google reads from the markup.

Most sites treat images as decoration. Google treats them as content it has to discover, understand and rank, and browsers treat them as the biggest download on the page.

This is the image chapter of our SEO guide, and the dedicated deep-dive: our on-page SEO guide and our technical SEO guide each mention images briefly inside a wider checklist, so we do not repeat those here. Everything below is grounded in Google's image best-practices documentation, with the gaps filled by what we do on client sites.

Why do images matter for SEO?

Three reasons, in order of how often they bite.

• Page speed. On most pages the Largest Contentful Paint element is an image, usually the hero or first product photo. An oversized PNG there is the most common reason we see a page fail LCP. The metric is explained in our Core Web Vitals guide; this page covers the image half of the fix.
• Google Images traffic. Product photos, infographics and how-to diagrams get searched for directly. Switch the search type to Image in the Performance report (our Google Search Console guide shows where) to see how much traffic arrives this way.
• Accessibility. Alt text is what a screen reader reads aloud. A baseline first, a ranking signal second.

Google's own framing: it "extracts information about the subject matter of the image from the content of the page, including captions and image titles." Images do not rank in isolation.

Write alt text that describes, not stuffs

Alt text is a short, plain description of what is in the image, written for someone who cannot see it. If it contains your keyword because the keyword is what the picture shows, good. If you had to force it in, it is wrong.

Google's documentation gives a four-step ladder for a picture of a puppy: no alt is bad, a stuffed alt ("puppy dog baby dog pup pups puppies…") is bad, "puppy" is better, and "Dalmatian puppy playing fetch" is best. The same doc warns that stuffing "results in a negative user experience and may cause your site to be seen as spam."

Here is that ladder applied to pages we see every week in India.

Three rules cover almost every case:

• Describe what is visible. Colour, product, angle, setting. Not what you wish the user was searching for.
• Skip "image of". The screen reader already announces it as an image.
• Decorative images get an empty alt. alt="" tells screen readers to skip a divider. Missing alt and empty alt are not the same thing.

Text inside an image (a banner that says "Flat 40% off") should be repeated in the alt, because neither Google nor a screen reader can reliably read it off the pixels.

Name the file before you upload it

Google says file names "can give Google very light clues about the subject matter of the image," and its own example is my-new-black-kitten.jpg versus IMG00023.JPG. Light clue, low effort, no reason to skip it.

• Lowercase, hyphen-separated: navy-cotton-block-print-kurta-front.webp.
• Rename before upload. WordPress builds the URL from the file name, and renaming later creates a new URL Google has to rediscover.
• For ecommerce, a fixed pattern (brand-product-colour-view) lets you generate names from the catalogue.

Google also asks you to "consistently reference the image with the same URL, so that Google can cache and reuse the image." One image, one URL, everywhere it appears.

Pick the format and compress it properly

Google Search indexes images in "BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF" when they are referenced in the src of an img. Format support is not the question. File size is.

Our defaults:

• Photos and product shots: WebP, or AVIF where your stack can produce it. AVIF is usually smaller still, and WordPress has accepted AVIF uploads since 6.5 (Make WordPress Core) if the server's image library supports it. Site Health → Info → Media Handling tells you.
• Logos, icons, simple diagrams: SVG. Any screen size, a few kilobytes.
• Screenshots with text: PNG or lossless WebP, so the text stays crisp. JPEG is now the fallback, not the primary.

Google does not publish a target file size, so treat this as our rule of thumb, not a standard: an in-content image under roughly 100 KB, a full-width hero under roughly 200 KB, a product thumbnail in the tens of kilobytes. We start at a quality setting of 75 to 85 for WebP and 70 to 80 for JPEG, then check the result on a phone at arm's length. If you cannot see the difference, ship the smaller one.

The other half of compression is dimensions. A 4,000-pixel camera file in a 600-pixel column is wasted bytes however well it is compressed. Resize to the largest size the layout will display, then compress.

Set dimensions and serve responsive images

Three attributes solve most layout and mobile problems.

• width and height on every img. The browser reserves the space before the image arrives, so the page does not jump. That jump is what Cumulative Layout Shift measures, and this is the cheapest CLS fix there is.
• srcset with sizes. You list several widths of the same image and the browser picks the one that fits, so a phone on 4G in Nagpur does not download the desktop version. Google is explicit: "We recommend that you always specify a fallback URL using the src attribute."
• <picture> for format switching. Offer AVIF, then WebP, then a JPEG img fallback. Google describes it as "a container that is used to group different <source> versions of the same image" and, again, wants the img fallback present.

WordPress generates the size variants and writes srcset for you if you upload one large original. Uploading a pre-shrunk 600-pixel file leaves it nothing to work with.

Lazy-load below the fold, never the hero

Lazy loading defers an image until the user scrolls near it. It is safe for Google if you follow Google's lazy-loading guidance: the native loading="lazy" attribute or an IntersectionObserver, never a script that waits for a scroll or click, because "Google Search does not interact with your page."

The caveat that gets missed is in the same document: "Don't add lazy-loading to content that is likely to be immediately visible when a user opens a page." web.dev's guide to optimising LCP is blunter: "Never lazy-load your LCP image."

The pattern:

• Hero or first product image: no loading="lazy", plus fetchpriority="high" so the browser fetches it first.
• Every image below the fold: loading="lazy".
• Check it: URL Inspection in Search Console shows the rendered HTML. If the image is not in it, Google cannot index it.

WordPress has added loading="lazy" automatically since 5.5 (Make WordPress Core), but only to images that already have width and height, and many themes lazy-load the hero through their own markup. Check your homepage's source before assuming.

Captions, surrounding text and placement

Because Google reads captions and page text to understand an image, the text around it is a ranking input, not an afterthought.

• Put the image next to the paragraph it illustrates, not in a gallery block at the bottom.
• Use a caption when it adds information (model number, location, date). Skip it when it would repeat the alt.
• Google says to place images "on pages that are relevant to the image subject matter," which rules out the "all our work" gallery page as an SEO asset.

If images are how you sell, product photo strategy gets its own treatment in our ecommerce SEO guide.

Image sitemaps, structured data and CDNs

Image sitemaps. Google describes them as "a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code)." Two things from the image sitemap documentation matter: only image:image and image:loc are still supported (caption, title, geo_location and license were dropped), and images on a CDN or another domain are fine "as long as you verify both domains in Search Console." Images in normal img tags on crawlable pages may not need one; images hidden in a slider do. How Googlebot spends its time across those files is covered in our crawl budget guide.

Structured data. Product, Recipe and Article markup carry an image property, and Google says the image is required for the badge on the thumbnail in Google Images. Publishers can also earn the "Licensable" badge with ImageObject license metadata: contentUrl plus at least one of license, creator, creditText or copyrightNotice. Background is in our schema markup guide; our free schema markup generator builds the JSON-LD.

CDNs. An image CDN resizes, converts and compresses at request time, which removes the manual work from everything above. Per Cloudinary's own explanation, f_auto "chooses a different format to use based on the formats supported by the browser" and q_auto "chooses an encoder quality setting to use that will reduce the file size with minimal impact on visual quality." Add a width parameter and the same source file serves a 400-pixel AVIF to a phone and a 1,600-pixel WebP to a desktop. We use Cloudinary on digitalhangover.in for exactly this reason; Cloudflare Images, imgix and Bunny Optimizer do the same job.

When we run SEO for a client site, image delivery is one of the first things we fix, because it moves LCP faster than almost anything else on the technical list.

WordPress image SEO checklist

WordPress does a lot of this out of the box, then themes and plugins undo it.

1. Resize and rename before upload. Export at the largest displayed width (roughly 1,600 to 2,000 pixels for a full-width hero, 1,200 for content), as WebP, with a descriptive hyphenated file name.
2. Fill in alt text in the Media Library at upload. WordPress writes it everywhere the image is used. Leave it blank only for decorative images.
3. Check Site Health → Media Handling for WebP and AVIF. WordPress has accepted WebP uploads since 5.8 (Make WordPress Core) and AVIF since 6.5, if the server can process them.
4. Keep width, height and srcset intact. Some page builders strip them. View source on a live page and confirm.
5. Exempt the hero from lazy loading in the theme or builder template, and add fetchpriority="high" to it.
6. Add an image CDN or an optimisation plugin that converts on upload and serves WebP/AVIF automatically.
7. Test in PageSpeed Insights and Search Console. One flags oversized and improperly sized images; the other's Image search type shows whether any of it is producing clicks.

Image SEO mistakes that undo everything else

• Lazy-loading the hero. The most common single LCP failure we see on WordPress sites, usually caused by the theme.
• Keyword-stuffed alt text on every product image. Google calls it spam, and it makes the site unusable with a screen reader.
• Uploading straight from the camera or Canva at full resolution. Four-megabyte PNGs for a 300-pixel card.
• Text baked into images. Prices and offers inside a JPEG are invisible to search.
• Blocking the image folder or the CDN in robots.txt. Google cannot index what it cannot fetch.
• Changing image URLs on a redesign without redirects. Google Images rankings sit on the image URL.

What to do next

Run PageSpeed Insights on your three most important pages and look only at the image warnings. Fix the hero on each (format, size, no lazy load, high fetch priority) and re-test. Then work through the alt text on your highest-traffic pages, where Google Images clicks are most likely to convert. Leave sitemaps and structured data until the basics are clean.