Images and SEO: File Weight, Alt Text and Indexing

Images create three different SEO problems, and solving one does not automatically solve the others. A 3 MB hero image can slow the page, a meaningless alt attribute can exclude screen-reader users, and a perfectly optimized file can still remain invisible in Google Images if it is blocked or poorly exposed to crawlers.

Effective image SEO therefore needs three separate jobs: reduce the cost of displaying the image, describe its meaning to people who cannot see it, and make the image eligible for discovery and indexing. Treat those jobs as separate checks rather than one generic “optimize your images” task.

The three jobs of image SEO

A useful workflow is to fix the page-speed and layout issues first, then review accessibility, and finally inspect discoverability. This prevents a common mistake: spending time rewriting alt text while the page still forces users to download oversized files.

Job one: reduce file weight without damaging the image

File weight is the amount of data the browser must download, not the visual dimensions shown on screen. A 2,400-pixel image displayed at 600 pixels is paying for detail the visitor cannot use. Start with the largest rendered size required by the design, then create responsive variants rather than serving the largest original to every device.

For many content images, a practical starting target is 100–250 KB per image. A prominent hero image may need 300–500 KB when quality matters, but it should not be several megabytes without a clear reason. These are working targets, not universal laws: a detailed product photograph may need more data than a flat illustration. Compare the compressed result at its actual display size.

Use the right format for the content:

• AVIF can deliver very small files, particularly for photographs, but test encoding time, browser support requirements, and visual artifacts.
• WebP is a broadly practical choice for photographs, illustrations, and transparent images.
• JPEG remains useful for photographs when compatibility, tooling, or an existing publishing system makes it convenient.
• PNG is appropriate for some lossless graphics, screenshots, and transparency needs, but it is often wasteful for ordinary photographs.
• SVG is usually best for logos, icons, and simple vector artwork. Remove unnecessary metadata and avoid using SVG as a container for large raster photographs.

Use the picture element or responsive srcset when different formats or sizes are available. The browser can then choose an appropriate file instead of receiving a fixed 2,000-pixel asset on a 360-pixel viewport. Confirm that the image CDN or CMS is not generating a new, uncached variant for every query-string combination.

Compression is not a one-time export setting. Test at least two quality levels, inspect fine text and faces at 100% zoom, and measure the transfer size. A sensible first pass might remove 30–70% from poorly optimized image files, but the result depends on the source, dimensions, format, and compression settings. Do not chase an arbitrary percentage if the image becomes visibly damaged.

What not to do: do not make every image “high quality” because the original file looks sharper in an editor. The visitor sees the rendered image in a browser, often on a small screen. Do not strip all quality from product photography either; blurry images can reduce trust and conversions even when the page is technically fast.

Dimensions, responsive delivery, and CLS

Every meaningful image should reserve its space before it loads. The simplest method is to include accurate width and height attributes that reflect the image’s intrinsic aspect ratio:

• Use width="1200" and height="800" for a 3:2 image, even if CSS later displays it at 600 by 400 pixels.
• Do not declare dimensions that distort the ratio. Cropping should be intentional and controlled with CSS.
• For responsive or art-directed images, preserve the ratio of each source and reserve the relevant container space.

Google defines a “good” Cumulative Layout Shift score as 0.1 or less, evaluated at the 75th percentile of page loads, according to Google’s Core Web Vitals guidance. The exact score is not an image-only metric, but missing dimensions are a common image-related cause of movement. Inspect field data as well as lab tests because a page can look stable on a fast development connection and shift badly on mobile.

CSS can also reserve space with aspect-ratio, especially for CMS components where image dimensions are not known in advance. This is useful for cards, galleries, and embeds. Avoid reserving a generic box that is much taller or shorter than the actual asset; that simply replaces one layout problem with another.

Lazy loading: useful, but not universal

Lazy loading is usually appropriate for images below the initial viewport. It delays downloads until the browser expects them to be needed, reducing initial work. Native lazy loading can be implemented with loading="lazy", but it should not be applied indiscriminately.

The popular advice to “lazy-load every image” is wrong. The main hero image, logo, and other above-the-fold content can be delayed, harming the Largest Contentful Paint measurement and the user’s first impression. Load the primary visible image eagerly, and consider fetchpriority="high" only when it is genuinely the page’s primary visual resource. Overusing high priority can compete with CSS, fonts, and other critical requests.

Google defines a good Largest Contentful Paint result as 2.5 seconds or less at the 75th percentile, according to Google’s Core Web Vitals guidance. That does not mean every image must appear within 2.5 seconds, but it does mean the main visual element deserves careful treatment.

Lazy loading also has an indexing risk when implemented through JavaScript. If the initial HTML contains no usable image reference and the image appears only after a scroll event, crawlers may not process it as reliably as a normal img element. Use a real src or crawlable srcset, keep important images in rendered HTML, and test the URL with a rendering inspection tool.

Do not lazy-load an image simply because it is below the fold if users are likely to scroll to it immediately, such as the first product gallery image or the next article illustration. A small amount of eager loading can provide a better experience than making every request wait for an intersection event.

Job two: write alt text for people, not algorithms

Alt text is a text replacement for an image when it cannot be seen. It supports screen-reader users, people on unreliable connections, and visitors whose browsers fail to display the asset. It can also provide context to search systems, but its first job is accessibility.

Describe the information or function the image contributes to the page. A useful alt attribute is often one short sentence or phrase:

• Product image: “Black leather laptop bag with a front zip pocket.”
• Chart: “Organic traffic rises from 18,000 visits in January to 27,000 in June.”
• Functional image: “Download the 2026 pricing guide” when the image itself is the link.
• Decorative image: use alt="" when it adds no information and is not interactive.

Do not begin with “image of” or “picture of” unless that distinction matters. A screen reader already identifies an image. Do not copy the surrounding caption into alt text if the caption already provides the same information. Do not stuff phrases such as “best running shoes cheap running shoes running shoes online” into an image attribute. That is poor accessibility, reads unnaturally, and does not create a credible relevance signal.

Alt text should not carry every SEO target on the page. If an image shows a red hiking boot, “red hiking boot on a trail” is appropriate. If it shows a generic decorative mountain silhouette behind a heading about hiking boots, an empty alt attribute may be correct. Context determines the description.

For complex charts, do not attempt to encode every data point in a tiny alt attribute. Give the image a concise summary and provide a full accessible data table or explanatory text nearby. The text alternative should preserve the decision-making value of the graphic.

Job three: make images discoverable and indexable

Search engines need to fetch the file, understand its context, and associate it with a page. Use stable, descriptive URLs such as /images/black-leather-laptop-bag.webp rather than opaque names such as IMG_48392-final2.jpg. A filename is a supporting signal, not a place to repeat every keyword variation.

Check the technical basics:

• Return a successful HTTP response, normally 200, for the image URL.
• Do not block the image directory in robots.txt or prevent access through authentication.
• Serve the correct content type, such as image/webp or image/avif.
• Use canonical, stable URLs and avoid unnecessary redirects.
• Include important images in crawlable HTML rather than exposing them only after a user interaction.
• Keep the image relevant to the page title, headings, caption, and surrounding copy.

An image sitemap can help large sites, publishers, and ecommerce stores expose assets that are difficult to discover through ordinary links. It is not a substitute for crawlable pages or accessible markup. If a product image is loaded only inside a closed gallery script, add usable image references to the product page as well.

Structured data can reinforce the relationship between an entity and its image where the schema type supports it. Use the actual image URL, ensure the image is available to crawlers, and keep the markup accurate. Structured data does not guarantee an image result or rich result.

Indexing is also a matter of time. Newly published images may take days or longer to appear in search, especially on sites with low crawl frequency. Use Search Console to inspect representative pages, review image-related performance over a 28-day or longer period, and compare impressions rather than expecting a same-day change after compression.

A practical image SEO review process

1. Sample the templates. Review the homepage, a category page, a product or service page, an article, and any image-heavy landing page.
2. Measure the largest assets. Record rendered dimensions, transfer size, format, caching headers, and whether the image is the LCP element.
3. Fix delivery. Resize oversized files, generate responsive variants, select an appropriate format, and reserve layout space.
4. Review every meaningful alt attribute. Remove keyword stuffing, describe purpose, and mark purely decorative assets with empty alt text.
5. Test crawling. Confirm that important image URLs are accessible, present in rendered HTML, and not blocked by robots directives or access controls.
6. Recheck field data. Allow at least 28 days for a meaningful comparison on sites with sufficient traffic, while using lab tests to catch obvious regressions immediately.

A small site can often manage transformations and delivery within roughly $0–$100 per month using existing CMS, hosting, or CDN features; larger catalogs, high traffic, and real-time resizing can cost more. The commercial decision is less important than verifying the outcome: smaller transfers, stable layouts, useful text alternatives, and image URLs that search engines can actually fetch.

The strongest image SEO program does not optimize images for one imaginary ranking factor. It gives each image a defined job, applies the appropriate technical treatment, and verifies that treatment with speed data, accessibility checks, and crawl evidence.

Related reading

• Our services — scope, method and what we measure.
• Technical SEO
• AI Visibility Tools: What to Check Before You Buy One
• Instagram Search Optimisation: What Is Search, What Is the Feed