How to Optimize Images for Your Website: Complete SEO Guide

Images are usually the heaviest thing on a web page and the least examined. Most sites ship them at the wrong size, in the wrong format, at a quality setting nobody chose deliberately. That is good news: it means image SEO is one of the few areas where a couple of hours of work still produces a visible change in how a page performs.

This guide covers the whole job in the order you should actually do it. Not a checklist of thirty tips, but the sequence that matters, with the numbers to aim for and the mistakes that quietly undo the rest of your work.

What image SEO actually affects

"Image SEO" gets used as if it were one thing. It is three, and they have almost nothing to do with each other.

• Your page rankings, through speed. Google measures Largest Contentful Paint, and on most content pages the largest contentful element is an image. A slow hero image is a slow page, and page experience is part of how you rank.
• Traffic from Google Images. A separate search surface with its own results. Filenames, alt text, captions and surrounding copy are how Google works out what a picture shows.
• Accessibility, which is not an SEO tactic. Alt text exists so that people using screen readers can use your site. It happens to help search engines. Write it for the person.

Work in that order. Speed is where the ranking impact lives, so it comes first.

Start by finding out what is actually broken

Do not optimise blindly. Spend ten minutes measuring, and you will usually find that two images out of forty are causing the whole problem.

1. Run the page through PageSpeed Insights. Read the "Largest Contentful Paint element" line. That names the single image that matters most on the page.
2. Open DevTools, go to the Network tab, filter to Img, and sort by size. Anything over 200 KB deserves an explanation.
3. In the same panel, compare each image's intrinsic size against its displayed size. Hover an image in the Elements tab and the browser tells you both. A 3000 px file in a 800 px slot is wasted bytes.

Resize before you do anything else

Compression gets the attention, but resizing is the bigger win and it is not close. Compressing a 4000 px image still leaves you with a 4000 px image. Resizing it to the width it actually displays at removes most of the file before a compressor touches it.

The rule: find the largest width the image will ever be displayed at, then export at up to twice that for high-density screens. Beyond 2x, nobody can see the difference.

You can do this in the browser with our image resizer, which never uploads the file anywhere.

Choose the format on purpose

Format choice is worth another 25 to 50 percent on top of resizing, and it takes one decision.

If you only change one thing: stop using PNG for photographs. It is the single most common format mistake and it can multiply a file size by five for no visible benefit. Our image converter handles the conversion locally.

Compress to a target size, not to a quality number

"Quality 80" means different things in different encoders and for different images. A flat graphic at quality 80 may be needlessly large; a detailed landscape at quality 80 may still show artefacts. Aim at a file size instead, and check the result with your eyes.

Compress with our image compressor, then look at the result at 100 percent zoom before you ship it. Pay particular attention to skin tones, gradients and areas of flat sky, which are where compression shows up first.

Serve a different size to every device

A phone should not download the desktop hero. This is what srcset is for, and it is the part most guides describe incorrectly.

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w,
          hero-800.jpg 800w,
          hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="1600" height="900"
  alt="Description of the image">

The w values describe how wide each file actually is in pixels. The sizes attribute tells the browser how wide the image will be displayed at a given viewport width, so it can pick a file before it has downloaded any CSS. Get sizes wrong and the browser will confidently choose the wrong file, which is worse than not using srcset at all.

Protect the image that decides your LCP

Your hero image is measured. Three rules apply to it, and to nothing else on the page.

• Never lazy-load it. Adding loading="lazy" to the hero is the most common self-inflicted performance wound on the modern web. It delays the exact image Google is timing.
• Give it fetchpriority="high" so the browser fetches it ahead of other images.
• Preload it if it is referenced from CSS rather than an <img> tag, so discovery is not delayed.

<link rel="preload" as="image" href="hero-1600.jpg">
<img src="hero-1600.jpg" fetchpriority="high" alt="...">

Everything below the fold should get loading="lazy". The distinction is the whole trick: lazy-load the many, prioritise the one.

Reserve space so the page does not jump

Always set width and height on every image. Browsers use the ratio between them to reserve the right amount of space before the file arrives, which prevents the content from shifting as images load. Layout shift is measured as Cumulative Layout Shift and it is one of the Core Web Vitals.

The attributes do not fix the displayed size. Keep the usual CSS alongside them:

img { max-width: 100%; height: auto; }

File names and alt text

Rename the file before uploading. IMG_4829.jpg tells Google nothing; blue-running-shoes-nike.jpg describes the subject before a single pixel is analysed. Use hyphens between words, keep it short, and describe what is in the frame rather than where you want to rank.

For alt text, describe the image to someone who cannot see it. Concrete rules:

• Under 125 characters, because some screen readers cut off around there.
• No "image of" or "photo of". The screen reader already announces that it is an image.
• Include a keyword only where it is genuinely descriptive.
• If the image is purely decorative, use alt="". An empty alt is correct and tells assistive technology to skip it. Omitting the attribute entirely is not the same thing and is worse.
• If the image contains text that matters, put that text in the alt.

Structured data, where it earns its keep

Adding ImageObject markup to every image is busywork. It matters in specific places: product images, recipe images, article images, and anywhere you want licensing information to appear in Google Images.

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/photo.jpg",
  "license": "https://example.com/license",
  "acquireLicensePage": "https://example.com/how-to-license",
  "creditText": "Jane Doe",
  "creator": { "@type": "Person", "name": "Jane Doe" }
}

If you sell something, the image belongs inside your Product markup rather than as a standalone block.

Image sitemaps

Most sites do not need one. You need one when your images are loaded by JavaScript, served from a different domain, or otherwise not discoverable in the page HTML at crawl time.

<url>
  <loc>https://example.com/product-page</loc>
  <image:image>
    <image:loc>https://cdn.example.com/photo.jpg</image:loc>
  </image:image>
</url>

The image: namespace goes in your existing sitemap. You do not need a separate file.

When to stop doing this by hand

Everything above is manual work, and manual work is the right answer for a long time. If you publish a handful of images a week, the browser tools on this site will do the whole job and you will never need anything else.

The calculation changes when volume does. Roughly speaking, once you are handling more than about fifty images a month, or you have a back catalogue of thousands that were uploaded before anyone thought about any of this, hand-optimising stops being realistic. At that point you want the work to happen automatically at upload time.

• On WordPress, that means an optimisation plugin that compresses and converts on upload and can bulk-process what is already in the media library. ShortPixel and Imagify are the two we would look at first. Our WordPress image optimization guide covers the setup properly.
• On any platform, an image CDN can resize, convert and cache at the edge, so the same original is delivered as AVIF to a modern phone and JPEG to an old browser without you generating either.
• In a build pipeline, tools like sharp or squoosh-cli do this at deploy time with no runtime dependency at all.

None of these replace resizing sensibly and choosing formats deliberately. They automate the compression step, which is the repetitive part, not the thinking part.

The mistakes that undo everything else

• Lazy-loading the hero image. Fix this before anything else on this list.
• Missing width and height, causing layout shift on every load.
• Uploading straight from a phone or camera, where files are routinely 3 to 8 MB.
• PNG for photographs.
• Serving the same file to a 360 px phone and a 1440 px desktop.
• Keyword-stuffed alt text, which helps nobody and reads as spam.
• Optimising once and never checking again. Re-run PageSpeed after a redesign or a theme change.

Do it now, in your browser

Every step above that involves changing a file can be done here without uploading anything, because these tools run entirely on your own device:

• Image resizer for step one, which is the big one.
• Image compressor to hit a target file size.
• Image converter for WebP and AVIF.
• Metadata viewer to check what your camera left in the file.

Start with the single image PageSpeed names as your LCP element. That one change is usually worth more than the rest of the list put together.