Image SEO - Optimizing Images for Search Engines and AI
CrazyEngineers, the engineering community I started in 2005, gets about 149000 visits/year only from Image Search.
I did not write any content, did anything special or even ran any advertising campaign. It's all 100% organic traffic. The traffic came from images indexed by Google that were contributed by members of CrazyEngineers community.
It still surprises me how powerful image SEO can be. In this article, we'll discuss all the essential parts of image SEO that you can implement.
FYI - Jatra community platform does image SEO automatically for you.
Almost all the advice on image SEO starts (and stops) at compression. Just shrink the image files so that they load faster. That only works for the user experience, but does not automatically get your images indexed by Google.
Google runs a separate search for images and it has a dedicated tab for image search. AI crawlers read your HTML as well along with the text that describes the image.
Google Visual Search is also growing. Google said, about 1.5 billion people use Google Lens every month. There were over 100 billion visual searches in the first five months of 2025.
Images posted inside private groups on Slack or Discord will never reach Google or any LLM. Sometimes, it's intended. But if your community content is public, Google can send a lot of traffic to the images.
How Google and AI crawlers read an image
Google says it combines the alt text, computer vision and the content of the page to figure out what an image shows. The official image SEO documentation talks about the signals: <img> element, alt text, the filename, the text and captions around the image along with page title and structured data form the primary signals for image recognition.
AL crawlers read far less. In late 2024, Vercel analysed AI crawler traffic across its network. OpenAI and Anthropic's crawlers downloaded the JS files but never ran them. Only Googlebot (which also crawls for Gemini) and Applebot rendered the pages the way browser does. I'll highly recommend understand the difference between CSR and SSR for SEO.
Make images findable
Let's go one by one through all the tricks to enhance your image SEO.
Put images in <img> tags
Google indexes images from the src attribute of an <img> element, including an <img> inside the <picture>. It does not index CSS background images.
<!-- Google can index this -->
<img src="/images/pi-weather-station.webp"
alt="Member-submitted wiring diagram for a Raspberry Pi weather station">
<!-- Google won't index this as an image -->
<div class="hero"
style="background-image: url('/images/pi-weather-station.webp')"></div>Background images are fine to decorate the page. Anything you want found in Google search, belongs in an <img> tag.
Lazy-load with the browser, not a script
You need not fetch the images that are not on user's screen. There's native loading="lazy" attribute available and it's safe for search. Basically, it'll render the images as soon as they're about to enter the viewport.
Script-based loaders are riskier. They rely on the data-src attribute and swap it in later. If the swap waits for a scroll event, it will never fire for Googlebot - and make the image invisible to it. AI crawlers don't run the script at all. It means they can never see the image.
<!-- Safe: the real URL is in the HTML -->
<img src="/images/pi-weather-station.webp"
alt="Member-submitted wiring diagram for a Raspberry Pi weather station"
loading="lazy" width="1200" height="900">
<!-- Risky: no real URL until JavaScript runs -->
<img data-src="/images/pi-weather-station.webp" class="lazyload"
alt="Member-submitted wiring diagram for a Raspberry Pi weather station">You can test this by right clicking a page -> View Source. If you are technical, you may use CURL. Search for your image filenames. The browser inspector won't do it, because it shows the page after the script has run. If a filename is missing from the raw HTML, crawlers can't see it.
robots.txt and CDN
If you serve all your images in a folder, make sure that robots.txt does not block it from crawlers. All crawlers respect the instructions in robots.txt file. (Recommended Reading: https://community.jatra.club/discussion/how-can-i-block-ai-bots-from-scraping-our-content)
Next - your CDN can block the images. Cloudflare has began blocking the AI crawlers from visiting new sites. Make sure that Cloudflare allows crawlers to crawl your website.
Sitemaps and stable URLs
An image sitemap lists image URLs Google might miss. Unlike a regular sitemap, it can point to URLs on other domains, which covers images on a CDN. Since 2022, Google reads only the image location tag. The old caption, title, geo-location, and license tags are ignored.
xml
<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/projects/pi-weather-station</loc>
<image:image>
<image:loc>https://cdn.example.com/images/pi-weather-station.webp</image:loc>
</image:image>
</url>
</urlset>Treat image URLs as permanent. Google recrawls images less often than pages. Rename files or switch CDNs without redirects, and your image traffic drops until Google catches up. Google's August 2024 AVIF announcement made the same point: if converting images changes their filenames or extensions, set up server-side redirects.
Make images understood
Alt text comes first
If you fix one thing on your images, fix the alt text.
Alt text was made for screen readers, which read it aloud to people who can't see the image. Google uses it to understand the image. For crawlers that only read HTML, it's the most direct description they get.
The usual advice is to make alt text "as descriptive as possible." Taken literally, that produces a paragraph with keywords worked in. Screen-reader users have to sit through it, and Google warns that keyword-stuffed alt text can get a site treated as spam. Aim for specific, not long. One sentence on what the image shows and why it's on this page.
Filenames and placement
Filenames are a light signal, and they cost nothing. feature-request-thread.webp tells Google something. IMG_2043.jpg tells it nothing. Use lowercase words separated by hyphens.
Placement matters more. Google reads the text and captions around an image to work out what it shows. An image beside the paragraph it explains gets that context. The same image in a gallery at the bottom of the page gets far less. When a caption helps the reader, tie it to the image in the markup:
html
<figure>
<img src="feature-request-thread.webp"
alt="Forum thread where a product manager answers a customer's feature request and links to the public roadmap"
width="1200" height="900" loading="lazy">
<figcaption>A feature request answered in public, with a link to the roadmap.</figcaption>
</figure>Original images
A stock photo appears on thousands of sites. When Google finds the same picture everywhere, it shows one copy, and it probably won't be yours. Original images have no duplicates to compete with: screenshots of your product, diagrams you drew yourself.
Communities produce original images every day. Members post screenshots of the error they're stuck on and photos of what they built. [CE: connect to what ranks on CrazyEngineers]
Structured data
For articles, add the image property to your Article or BlogPosting markup. Google's article documentation asks for high-resolution images of at least 50,000 pixels (width times height) and suggests supplying 16:9, 4:3, and 1:1 versions.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Image SEO: Optimizing Images for Search Engines and AI",
"image": [
"https://example.com/images/image-seo-16x9.webp",
"https://example.com/images/image-seo-4x3.webp",
"https://example.com/images/image-seo-1x1.webp"
]
}
</script>If credit matters to you, Google also reads image license metadata (creator, credit line, license page). It can add a "Licensable" label to your image in Google Images.
Make images fast
Format
WebP, JPEG, and PNG work in every browser, and they're a safe default. They aren't the whole list anymore. Google Search has indexed AVIF since August 2024, and every major browser supports it.
Format doesn't move rankings on its own. When AVIF support launched, Google's John Mueller said switching gives no SEO boost. The gain is smaller files and faster pages
html
<!-- Missing: some screen readers read the filename aloud instead -->
<img src="IMG_2043.jpg">
<!-- Says nothing -->
<img src="IMG_2043.jpg" alt="community">
<!-- Stuffed -->
<img src="IMG_2043.jpg"
alt="community platform forum software best community platform B2B SaaS">
<!-- Useful -->
<img src="feature-request-thread.webp"
alt="Forum thread where a product manager answers a customer's feature request and links to the public roadmap">The same screenshot can need different alt text on different pages. On a page about handling feature requests, describe the request. On a page about public roadmaps, describe the roadmap link.
Decorative images, like dividers and background flourishes, get an empty alt="" so screen readers skip them. Leaving the attribute out is worse.
Community sites have their own version of this problem. Members upload most of the images, and members don't write alt text. The platform's defaults decide whether those images are searchable at all.
Serve the newer formats with a fallback:
<picture>
<source srcset="/images/dashboard.avif" type="image/avif">
<source srcset="/images/dashboard.webp" type="image/webp">
<img src="/images/dashboard.jpg"
alt="Community analytics dashboard showing weekly active members"
width="1200" height="900">
</picture>Or let an image CDN do it. A good one picks the format per browser from a single URL, sending AVIF or WebP where supported and JPEG elsewhere. The URL stays stable while the format changes underneath. Set long cache lifetimes while you're at it.
Dimensions and file size
1200×900 is a good default for in-article images, and Google's own requirements back it up. Discover only shows large image previews for images at least 1200 pixels wide, with the robots setting covered below. And 1200×900 is 4:3, one of the three ratios Google suggests for article images.
Large images are still fine. Ship them with srcset, so a phone downloads a small file and a large screen gets the big one:
html
<img src="/images/pi-weather-station-1200.webp"
srcset="/images/pi-weather-station-600.webp 600w,
/images/pi-weather-station-1200.webp 1200w,
/images/pi-weather-station-2400.webp 2400w"
sizes="(max-width: 720px) 100vw, 720px"
alt="Member-submitted wiring diagram for a Raspberry Pi weather station"
width="1200" height="900" loading="lazy">Treat 500 KB as the ceiling, not the target. A 1200-pixel photo saved as WebP or AVIF at quality 75 to 80 usually lands under 200 KB. Compare by eye before going lower. Flat-color screenshots get smaller still.
Set width and height on every image. The browser reserves the space before the file arrives, so text doesn't jump around as images load. Google measures that jump as Cumulative Layout Shift, one of its Core Web Vitals.
The hero image
Blanket "lazy-load everything" advice gets the first big image on the page wrong. That image is usually the page's Largest Contentful Paint, the Core Web Vital for how fast the main content appears. Lazy-loading it tells the browser to wait on the image the visitor sees first. Fetch it immediately, at high priority:
html
<!-- Hero: fetch right away -->
<img src="/images/hero.webp"
alt="Customer community homepage with pinned announcements and active threads"
width="1200" height="675" fetchpriority="high">
<!-- Below the fold: fetch when needed -->
<img src="/images/step-3.webp"
alt="Settings screen for choosing which channels are public"
width="1200" height="900" loading="lazy">Bigger previews and better link shares
Add max-image-preview:large to your robots meta tag. Without it, Google can fall back to smaller image previews, and Discover won't show your images large.
html
<meta name="robots" content="max-image-preview:large">Then tell Google which image represents the page. It looks at the image property in your structured data and at the og:image tag when choosing a thumbnail for your result.
The og:image is also what shows up when someone pastes your link into Slack, WhatsApp, or LinkedIn. If your articles get passed around in channels and group chats, it's the image people see before they decide to click. Make it a separate asset: 1200×630, in JPEG or PNG, which render reliably across link-preview tools.
html
<meta property="og:image" content="https://example.com/images/image-seo-share.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Checklist of image SEO fixes for community sites">Final Words
We covered image SEO in detail. You do not need to implement it all. The basic image SEO can be done with:
Proper image format
Fast loading / lazy loading images
ALT text and
Semantic HTML
Just ensure that your images are visible to the search bots and AI crawlers. If you have questions - please feel free to ask in the comments below.