Home › Website SEO › Image SEO
WEBSITE SEO / IMAGE SEO
Learn how to optimise images for search visibility, accessibility, performance and user experience, including filenames, alt text, responsive images, modern formats, image sitemaps and WordPress implementation.
Practical guidance with working markup examples and no invented statistics.
No single signal decides image visibility, and being crawlable does not mean being indexed.
THE BASICS
Image SEO is the work of making images easier for search engines to discover, understand and potentially surface, while also improving accessibility, performance and the experience of the people actually looking at them.
It’s frequently reduced to “write alt text”. That’s one part of seven:
Search engines have to find the image at all, which usually means a real img element with a reachable URL.
The image should genuinely relate to the page it sits on and the content around it.
Alt text exists first for people who cannot see the image. That purpose and search understanding align closely.
Correct markup, dimensions, responsive attributes and loading behaviour.
Images are usually the heaviest part of a page. Size and delivery affect the whole experience.
Filenames, captions, headings and surrounding text all contribute to what an image appears to be about.
Where and whether an image surfaces is decided by the search engine, not by your markup.
Images can contribute to visibility in image results and visual discovery, to how well a page’s subject is understood, and to page experience generally. What nobody can honestly tell you is how much traffic that will produce — it depends entirely on the site, the subject and whether people search visually for what you publish. A B2B software page and a recipe site have completely different realistic expectations here, and any guide quoting a percentage for “image search traffic” is inventing it.
The reliable case for doing this work: optimised images make pages faster, make them usable for people relying on screen readers, and give search engines a clearer picture of what a page covers. Those are worth having regardless of whether image results ever send you a visit.
<!-- A standard img element: the clearest way to expose an image -->
<img src="/images/blue-office-chair.webp"
alt="Blue office chair with adjustable armrests beside a wooden desk"
width="1200" height="800">
<!-- The picture element, for format fallbacks -->
<picture>
<source srcset="/images/chair.avif" type="image/avif">
<source srcset="/images/chair.webp" type="image/webp">
<img src="/images/chair.jpg"
alt="Blue office chair with adjustable armrests"
width="1200" height="800">
</picture>
<!-- A CSS background image is styling, not content. -->
<!-- Google finds images in the src attribute of img elements; -->
<!-- background images are not indexed as images the same way. -->
.hero { background-image: url("/images/decorative-pattern.jpg"); }
<!-- So: content images belong in img elements. -->
<!-- Purely decorative visuals can stay in CSS. -->DISCOVERY
Google combines many signals to work out what an image shows and whether it’s relevant: the image URL and filename, alt text, dimensions and format, the page title and headings, captions, the surrounding text, the page’s overall topic, structured data and image sitemaps — alongside its own visual analysis.
That matters because it rules out the shortcut. No single factor determines image visibility, and treating alt text as the whole of image SEO misses most of what’s actually being read.
For discovery, the practical rule is to use a standard <img> element with a real src for any image that’s part of your content. Google’s guidance is that it finds images in the src attribute of img elements, and that CSS background images are not indexed as images in the same way. That doesn’t mean a background image is invisible to every system in every context — it means it isn’t exposed for image indexing the way a real image element is.
The consequence for page builders is direct: if an image carries meaning, it should be an image element. If it’s a decorative texture behind a section, CSS is the right place for it.
DESCRIPTION
Filenames give a small contextual clue about what an image shows. Descriptive and readable beats IMG_48392.jpg. They are not a major ranking factor, and stuffing keywords into them is transparent and unhelpful — a few natural words describing the subject is the whole technique.
Alt text deserves more care, because its primary purpose is accessibility. It’s what a screen reader announces in place of the image. Write it as you’d describe the picture to someone who can’t see it: accurate, concise, specific to this context. You usually don’t need “image of” or “picture of” — assistive technology already announces that it’s an image.
Keyword-stuffed alt text fails both audiences at once. It’s meaningless to the person relying on it and obviously manipulative to anything parsing it. Writing for accessibility first tends to produce alt text that works well for search anyway, which is the useful thing to internalise here. More in our website accessibility guide.
Captions are visible text below an image. They’re read more often than body copy and genuinely help people understand a visual — but they aren’t a ranking mechanism, and not every image needs one. The title attribute is a different thing again: it produces a tooltip on hover, isn’t reliably announced by assistive technology, and isn’t a meaningful search signal. Alt text and surrounding content matter considerably more.
blue-office-chair-adjustable.webpDescriptive, readable, natural word order.team-reviewing-wireframes.jpgDescribes what is actually shown.IMG_48392.jpgTells nobody anything.office-chair-best-office-chair-cheap-chair.jpgStuffed. Reads as manipulation, helps nothing.alt="Blue office chair with adjustable armrests beside a wooden desk"Describes the image in context, naturally.alt="Bar chart showing quarterly revenue rising from Q1 to Q4"Conveys what the chart communicates.alt="chair office chair blue chair office furniture cheap chair"Keyword stuffing. Useless to a screen reader user.alt="image"Present but meaningless.<!-- Informative: describe what it conveys -->
<img src="team-workshop.jpg"
alt="Four people reviewing wireframes on a whiteboard">
<!-- Decorative: empty alt so screen readers skip it -->
<img src="divider-pattern.svg" alt="">
<!-- Missing alt entirely is different and worse — -->
<!-- some screen readers then read the filename aloud -->
<!-- <img src="IMG_48392.jpg"> -->
<!-- Functional: describe the action, not the picture -->
<a href="/cart/">
<img src="cart-icon.svg" alt="View shopping cart">
</a>
<!-- Complex: short alt, full explanation in the page -->
<figure>
<img src="revenue-chart.png"
alt="Bar chart of quarterly revenue, described below">
<figcaption>
Revenue rose each quarter, with the largest increase in Q4.
</figcaption>
</figure>
<!-- Avoid: "image of", "picture of", "photo of" -->
<!-- Assistive technology already announces it is an image --><!-- Serve modern formats with a fallback the browser understands -->
<picture>
<source srcset="/images/product.avif" type="image/avif">
<source srcset="/images/product.webp" type="image/webp">
<img src="/images/product.jpg"
alt="Blue office chair with adjustable armrests"
width="1200" height="800">
</picture>
<!-- Responsive sizing: let the browser pick by viewport -->
<img src="/images/chair-800.webp"
srcset="/images/chair-400.webp 400w,
/images/chair-800.webp 800w,
/images/chair-1200.webp 1200w,
/images/chair-1800.webp 1800w"
sizes="(max-width: 768px) 100vw,
(max-width: 1200px) 50vw,
600px"
width="1200" height="800"
alt="Blue office chair with adjustable armrests"
loading="lazy">
<!-- srcset lists the available widths -->
<!-- sizes tells the browser how wide the image will display -->
<!-- Without sizes, the browser assumes full viewport width -->
<!-- and may download a larger file than needed -->FORMATS & SIZE
There is no single best format. The right choice depends on what the image contains, the transparency and animation you need, and how much you care about older browser support.
Broadly: JPEG for photographs where universal support matters, PNG where you need transparency or crisp edges, WebP as a well-supported modern default for both, AVIF where you want stronger compression and can accept slower encoding, and SVG for logos, icons and diagrams. Google Search supports common formats including BMP, GIF, JPEG, PNG, WebP, SVG and AVIF.
What’s worth saying plainly: WebP is not a ranking factor. Converting every image to WebP does not improve rankings. Modern formats reduce file size, which improves delivery, which improves the experience — that’s the actual mechanism, and it’s indirect.
Compression trades file size against visual quality. Lossy compression discards data permanently; lossless preserves it exactly at larger sizes. For most photographs, moderate lossy compression is invisible to viewers and dramatically smaller. Test at the size you actually display — artefacts visible at full resolution often vanish at display size.
Dimensions matter twice over. Serving a 3000px image into a 600px slot wastes bandwidth for no visible gain. And setting width and height lets the browser reserve space before the image arrives, which prevents layout shift — an accessibility and usability improvement that happens to help Core Web Vitals too.
DELIVERY
Responsive images let the browser choose an appropriately sized file. srcset lists the available widths, sizes describes how wide the image will actually display at different viewports, and the browser picks based on viewport and screen density. Omitting sizes is the common error — without it the browser assumes full viewport width and may download a larger file than it needs. See our responsive design guide.
The <picture> element handles a different job: serving different formats with fallbacks, or genuinely different crops at different breakpoints. Use srcset for sizes, picture for format or art direction.
Lazy loading with loading="lazy" defers images until they’re needed, which reduces initial load. It should not be applied to everything. Images in the initial viewport — particularly the LCP element — need to load immediately, and lazy-loading them actively delays the metric being measured.
This is the single most common self-inflicted image performance problem: a site-wide lazy-loading setting applied to the hero image. Identify your LCP element, exclude it from lazy loading, and consider fetchpriority="high". Preload it only if testing shows a genuine benefit — preloads compete for bandwidth with each other.
Beyond individual images: caching avoids re-downloading, a CDN serves files from closer infrastructure and often handles resizing and format conversion automatically. A CDN is useful, not mandatory, and won’t help if the underlying problem is a 4MB uncompressed hero image.
srcset offers the options; sizes tells the browser how wide the image will actually display. The browser chooses.
<!-- Above the fold: load immediately, high priority -->
<img src="/images/hero-1200.webp"
srcset="/images/hero-600.webp 600w, /images/hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 60vw"
width="1200" height="675"
alt="Descriptive alt text for the hero image"
fetchpriority="high"
decoding="async">
<!-- Below the fold: defer -->
<img src="/images/section-800.webp"
width="800" height="450"
alt="Supporting illustration"
loading="lazy"
decoding="async">
<!-- Do NOT do this to a hero image -->
<!-- <img src="hero.webp" loading="lazy"> -->
<!-- A site-wide lazy-load setting is how this usually happens -->
<!-- Preload only where testing shows it helps -->
<link rel="preload" as="image"
href="/images/hero-1200.webp"
imagesrcset="/images/hero-600.webp 600w, /images/hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, 60vw">[ ] Page containing the image is crawlable [ ] Image URL returns a successful response [ ] robots.txt does not block image paths or required resources [ ] Image is in a real img element in crawlable HTML [ ] No authentication barrier on the image URL [ ] Image URLs served over HTTPS [ ] Image URLs are stable and not regenerated on every request [ ] Image sitemap entries included where discovery is genuinely difficult
<?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/office-chair/</loc>
<image:image>
<image:loc>https://example.com/images/chair-front.webp</image:loc>
</image:image>
<image:image>
<image:loc>https://example.com/images/chair-side.webp</image:loc>
</image:image>
</url>
</urlset>
<!-- Image entries can extend an existing sitemap or sit in -->
<!-- their own file. Most useful where images are hard to -->
<!-- discover: JavaScript-loaded galleries, CDN-hosted files. -->
<!-- A sitemap supports discovery. It does not guarantee -->
<!-- crawling, and crawling does not guarantee indexing. -->
# robots.txt — do not block image paths you want indexed
User-agent: *
# Disallow: /wp-content/uploads/ <-- would block your images
Allow: /wp-content/uploads/CRAWLING & INDEXING
An image can only be understood if it can be reached. Crawlability means the page is crawlable, the image URL returns successfully, nothing in robots.txt blocks it, and no authentication stands in the way. See our technical SEO guide.
Blocking your uploads directory in robots.txt is a surprisingly common own goal — it blocks the images along with everything else in there.
Crawlable is not indexed. Whether an image is indexed depends on the page being indexed, the image being relevant to it, the content’s quality and search engine processing. Nobody can promise image indexing, and any tool that does is overselling.
Image sitemaps list image URLs to support discovery, either as an extension of an existing sitemap or as a separate file. They help most where images are hard to find by crawling — JavaScript-loaded galleries, CDN-hosted files on a different domain. Not every site needs one, and including one does not guarantee anything.
Image URLs should be stable. Changing them unnecessarily means losing whatever understanding had accumulated and re-crawling everything. Consistent URLs also cache better.
Some duplication is normal and correct — responsive variants and format alternatives of the same photograph are expected. What causes problems is the same image at many unrelated URLs through parameters or inconsistent CDN configuration, which fragments caching and understanding for no benefit.
METADATA
og:image specifies a preview image for social sharing. It’s what most platforms use when a link is posted. It is not a control on Google image rankings — it’s page metadata that may be one source among several when a preview image is selected.
Structured data gives images context by relating them to what a page describes. An Article’s image, a Product’s image array, an Organization’s logo. primaryImageOfPage on a WebPage indicates which image is the main one — a preference, not a guarantee that any search engine will select it. More in our schema markup guide.
Structured data describes relationships. It does not produce a specific image result, and marking up an image that isn’t on the page is the kind of mismatch that causes problems.
IPTC metadata embedded in the file itself can carry creator and licensing information, and structured data can express licensing too. This matters if you produce original imagery and want its provenance to travel with it. Don’t invent licensing details for images you didn’t create or don’t hold rights to.
A preview image for social sharing. Useful, widely used, and not a Google ranking control.
Indicates the main image of a page. A preference expressed in structured data, not a guarantee.
IPTC fields and structured data can carry creator and licence information for original imagery.
<!-- Open Graph: the social sharing preview -->
<meta property="og:image"
content="https://example.com/images/article-preview.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt"
content="Descriptive text for the preview image">
<!-- Structured data: relating images to page content -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebPage",
"@id": "https://example.com/guides/image-seo/",
"primaryImageOfPage": {
"@type": "ImageObject",
"contentUrl": "https://example.com/images/guide-cover.jpg",
"width": 1200,
"height": 800,
"caption": "A description of what the image shows"
}
}
</script>
<!-- Product images as an array, most representative first -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Product Name",
"image": [
"https://example.com/images/product-front.jpg",
"https://example.com/images/product-side.jpg"
]
}
</script>
<!-- All values are illustrative examples. -->IN PRACTICE
Multiple genuine views of the actual product, descriptive filenames, alt text describing what distinguishes each shot, consistent dimensions, sensible compression, and Product structured data with an image array. Never fabricate specifications, prices or ratings alongside them.
A featured image that genuinely represents the piece, images placed near the content they illustrate, captions where they add understanding, and alt text describing what each image contributes. Original diagrams and screenshots beat generic stock photography for both readers and understanding.
Real photographs of the actual premises, team and work. Note that geotagging an image file does not improve local rankings — that claim persists but has no basis. Genuine, current imagery on well-optimised pages is the useful version. See local SEO.
Rename files descriptively before uploading, since WordPress keeps the filename. Fill in alt text in the Media Library. WordPress generates multiple sizes and responsive markup automatically. Use one compression plugin, not three — stacked image plugins conflict and duplicate work.
The Image widget produces a real img element and lets you set alt text and choose a registered size. Section and container background images are CSS, so they aren't exposed for image indexing and carry no alt text — keep meaningful images in Image widgets and backgrounds decorative.
Featured image plus gallery, at consistent dimensions so listings don't jump. Thumbnail and zoom sizes are configurable — oversized source files scaled down in the browser are a common cause of slow product pages. Product structured data is usually generated already.
AUDIT
A practical audit order, working from the changes with the largest effect down to the details. A handful of enormous images usually matters more than alt text on fifty thumbnails.
Inventory every image and where it appears.
The biggest wins are usually a handful of very large images.
Look for IMG_ patterns, empty alt on content images and stuffing.
Compare intrinsic size against display size.
Identify where a modern format would genuinely help.
Confirm srcset and sizes are present and sensible.
Confirm it is not lazy-loaded and loads with priority.
robots.txt, URLs, HTTPS, response codes.
Structured data image properties and og:image.
Alt handling across every image type.
On a real device, not just a resized window.
Search Console and performance data over time.
TECHNICAL [ ] Image URLs served over HTTPS [ ] Image URLs crawlable and returning 200 [ ] Format appropriate to the image content [ ] Dimensions appropriate to display size [ ] width and height set on every image [ ] Responsive srcset and sizes where useful [ ] Compression applied without visible damage [ ] Caching configured [ ] CDN where the audience is spread out SEARCH [ ] Descriptive, readable filenames [ ] Useful alt text on informative images [ ] Images placed near relevant content [ ] Captions where they aid understanding [ ] Image sitemap where discovery is difficult [ ] Structured data image properties accurate [ ] og:image set for sharing ACCESSIBILITY [ ] Informative images genuinely described [ ] Decorative images have empty alt [ ] Functional images describe the action [ ] Complex visuals explained in page text [ ] No important information only inside an image PERFORMANCE [ ] LCP image identified and not lazy-loaded [ ] Below-fold images deferred [ ] No oversized files served to small viewports [ ] Mobile rendering checked on a real device
MISTAKES & MYTHS
Alt text should describe the image. Stuffing it helps nobody and is trivially detectable.
Modern formats reduce file size, which improves delivery. Format choice is not itself a ranking advantage.
Loading strategy depends on where an image sits. The LCP image must not be deferred.
Relevant, useful images help. Unnecessary ones add weight without benefit.
It supports discovery. Crawling and indexing remain separate decisions.
It covers discovery, relevance, technical implementation, accessibility, performance and context.
This persists widely and has no established basis. Genuine local imagery on good pages is the real version.
Smaller files load faster, which improves experience. The connection to search is indirect.
Camera defaults uploaded straight to production.
Useless to screen reader users, obvious to everything else.
An informative image silently skipped.
Redundant — assistive tech already says it is an image.
A linked icon with no indication of where it goes.
A 5MB camera original displayed at 600 pixels.
No responsive markup, full-size files on phones.
A site-wide setting delaying the metric being measured.
PNG photographs, or SVG attempted for photos.
Layout jumping as each image arrives.
Meaningful images not exposed for image indexing.
robots.txt disallowing the uploads directory.
The same image at many URLs through parameters.
Interchangeable photos adding nothing.
Placed far from the content they illustrate.
Treating alt text as an SEO field rather than a description.
Format conversion treated as the whole job.
No idea which images are actually slow.
SCOPE & TOOLS
The two terms overlap and aren’t the same thing. Image SEO is about discovery, understanding and relevance — can search engines find the image, and do they know what it shows? Image optimisation is about delivery — how quickly does the file arrive and how much bandwidth does it cost?
They meet in the middle. Format, compression and responsive delivery serve both. But you can optimise images perfectly and still have them undiscoverable, or write excellent alt text on files that take eight seconds to load.
Indexing and performance data for pages, plus reporting on structured data. The starting point for whether images are being found at all.
Flag oversized images, missing dimensions, images without modern formats, and whether the LCP element is an image.
The Network tab shows actual transferred sizes and which image is largest. Elements shows the rendered markup Elementor and plugins produced.
Squoosh for visual comparison at different quality settings, ImageMagick and similar for batch processing.
The Rich Results Test and Schema.org Validator for structured data carrying image properties.
Where alt text lives on WordPress. One compression plugin is enough — stacked ones conflict.
FAQ
Short answers to the questions people ask most about optimising images for search, accessibility and performance.
NEXT TOPICS
Crawlability, indexing and site architecture underpin image discovery.
Images sit within page content, and context is what gives them meaning.
Images are usually the largest influence on LCP and a common cause of CLS.
Structured data carries image properties across many types.
Genuine business imagery supports local pages and listings.
Auditing, compression and validation tools for image work.
Broader performance work beyond images alone.
Alt text is accessibility first — the fuller picture matters.
Continue exploring Technical SEO, On-Page SEO, Core Web Vitals, Schema Markup, Local SEO and SEO Tools.