DEV Community: Eduard

Image SEO: Complete Guide to Optimizing Images for Search

Eduard — Thu, 30 Jul 2026 07:37:16 +0000

A while back I audited an e-commerce site that looked solid on paper. Fast hosting, clean code, decent content. Mobile PageSpeed score: 34. I kept digging until I checked the page weight. Homepage was pulling 14MB of images on first paint. Fourteen megabytes. For a homepage.

Every product photo had been uploaded as a 3000px-wide PNG straight from the photographer’s camera. No compression, no resizing, no modern formats. Mobile users on 4G were downloading desktop-sized files. We converted everything to WebP, added proper responsive sizes, and got the total image payload down to about 800KB. Score jumped to 87. That single change — just the images — moved their Core Web Vitals from “poor” to “good” across the whole site.

That’s when it clicked for me. Image SEO isn’t some nice-to-have checklist item. On a lot of sites it’s the biggest performance bottleneck you’ll find.

Alt Text (and the mistakes I keep seeing)

Alt text does two jobs that people constantly mix up: it helps screen-reader users understand the image, and it gives search engines context so the image can show up in Google Images. Good alt text does both at once.

What I see in almost every audit:

“image of product”
or pure keyword stuffing: “buy blue widget online best price”

Neither helps anyone. Something specific works better:

“Woman hiking on mountain trail with red backpack at sunset”

That’s useful for a screen reader and it tells Google exactly what it’s looking at.

Keep it under roughly 125 characters. Screen readers often cut off after that, so longer text just gets ignored. Decorative images (background patterns, spacers, pure design elements) should get an empty alt: alt="". That way screen readers skip them instead of announcing “image”.

Early on I made a classic mistake myself. I used the same alt text for every color variant of a product — “Blue running shoe” for the blue, red, and green versions. Google couldn’t tell them apart in image search. Each variant needs its own unique description.

File names — the five-minute fix most people skip

I still open sites and see IMG_4729.JPG and photo-1.png. File names are a ranking signal for images. Renaming them costs nothing and takes almost no time.

What I do:

hyphens between words
include the main keyword
make it descriptive

red-leather-wallet.jpg is already better than IMG_4729.JPG.

seo-audit-checklist-2026.png tells Google (and future-you) exactly what the file is.

Formats — my actual take, not the marketing version

WebP is the right default for most photos. You usually get 25–35% smaller files than JPEG at similar quality, and support is over 96%. For product shots and complex images it’s the clear winner.

But I don’t buy the “WebP for everything” advice. On screenshot-heavy tutorial pages I’ve seen WebP create ugly compression artifacts around sharp text edges. In those cases PNG looked better even though the file was larger. Sometimes the “best” format isn’t the best for your images.

AVIF is technically stronger — up to 50% smaller than WebP — but support still sits around 80%. I use it as a progressive enhancement with a WebP fallback. Most people won’t notice, the ones on modern browsers get a faster load.

SVG for logos and icons is non-negotiable. If your logo is still a PNG, fix it. Vectors scale cleanly and the files are tiny.

Quick rule of thumb I use:

photos → WebP (or AVIF + WebP fallback)
screenshots / text-heavy images → PNG
logos & icons → SVG

Responsive images — stop sending desktop files to phones

This is the second biggest performance killer after raw file size. Without srcset, every mobile visitor downloads the full desktop image.

Basic pattern:

<img 
  src="image-800.jpg"
  srcset="image-400.jpg 400w,
          image-800.jpg 800w,
          image-1200.jpg 1200w"
  sizes="(max-width: 600px) 400px,
         (max-width: 1000px) 800px,
         1200px"
  alt="Descriptive alt text">

Phone gets the 400px version, tablet 800px, desktop 1200px. On that e-commerce site, just adding responsive images cut average image payload by about 60% for mobile users. That’s the difference between a 3-second load and a 1-second load on typical 4G.

Lazy loading — easy to get wrong

Native lazy loading has been around since 2020. Just add loading="lazy":

<img src="image.jpg" alt="Description" loading="lazy">

The mistake I still see constantly: people lazy-load the hero image. Above-the-fold content should load immediately. Lazy-loading the main visual tanks LCP because the browser waits to fetch the most important image on the page.

Also check your CDN or image optimization service. Some inject their own JavaScript lazy-loading that fights with the native attribute. Open Chrome DevTools and watch the network order — make sure the hero loads first and everything else waits.

Image sitemaps — Google can’t index what it never finds

Most images get discovered through the HTML. That fails for images loaded with JavaScript, CSS background images, or stuff buried in carousels and galleries.

Putting images in your XML sitemap gives Google a direct path:

<url>
  <loc>https://example.com/page</loc>
  <image:image>
    <image:loc>https://example.com/image.jpg</image:loc>
    <image:caption>Description of the image</image:caption>
  </image:image>
</url>

I’ve seen image search traffic double on sites after we added proper image entries to the sitemap. The images weren’t new — Google just couldn’t find them before.

Mistakes that show up in almost every audit

Oversized files — 3000px wide when the layout only needs 800px. Resize before you upload.
Wrong format — PNG product photos that should be WebP. The size difference hurts.
Missing or useless alt text — still the most common issue. In my last 20 audits, 14 had serious gaps.
Generic file names — banner-final-v3.jpg tells Google nothing.
No lazy loading (or lazy-loading everything, including the hero).
Leaving EXIF data — location and camera info. Some people keep it for context, I usually strip it on client sites for privacy.

Tools I actually open

Squoosh — still my go-to for quick one-off compression. The quality slider is excellent.
TinyPNG — solid for batch PNG/WebP work.
Lighthouse (Chrome DevTools) — run it after every change so you can see the real impact.
AI SEO Copilot — useful for spotting missing alt text, wrong formats, and images that lack responsive sizing across a whole site.

Quick check

If you want a fast look at your own images:

Run a free image SEO analysis

It flags alt text coverage, format issues, and whether lazy loading is set up correctly.

Eduard Tymchenko

Building tools that help people find and fix the SEO problems that actually move the needle.

I built a free SEO audit tool with 25+ features using Next.js 16, TypeScript, and AI — here's what I learned

Eduard — Wed, 29 Jul 2026 02:31:30 +0000

I spent 2 months building AI SEO Copilot — a free SEO analyzer that checks 12 dimensions and generates AI recommendations. No signup, no paywall. Here's the technical breakdown.

What It Does

Paste any URL, get a full audit in 60 seconds. 12-dimension analysis:

Meta tags (title, description, OG tags, Twitter cards)
Heading structure (H1-H6 hierarchy)
Core Web Vitals (LCP, INP, CLS, FCP, TTFB)
Schema markup validation + suggestions
Content quality scoring
Internal & external link analysis
Image SEO (alt text, formats, lazy loading)
Redirect chain detection
Social media previews
E-E-A-T signals

Plus 25 additional tools: schema validator, meta tag analyzer, keyword clusters, rank tracker, content editor, competitor diff, broken link checker, and more.

The Stack

Layer	Tech
Framework	Next.js 16 (App Router, Turbopack)
Language	TypeScript strict
Styling	Tailwind CSS v4
Database	Supabase
AI	Gemini → Groq → Mistral (fallback chain)
State	Zustand
Components	shadcn/ui
Deploy	Vercel

The Scan Pipeline

Every URL goes through this flow:

URL Input → SSRF Check → Fetch HTML → Parse → Score 12 Dimensions → AI Insights → Response

The core scanner fetches raw HTML and extracts every SEO signal:

async scanURL(url: string): Promise<PageData> {
  const response = await fetch(url, {
    headers: { "User-Agent": "Mozilla/5.0 (compatible; AISEOCopilot/1.0)" },
    signal: AbortSignal.timeout(15000),
    redirect: "follow"
  });

  const html = await response.text();

  return {
    title: this.extractTitle(html),
    meta_description: this.extractMetaDescription(html),
    h1: this.extractH1(html),
    schema_markup: this.extractSchema(html),
    internal_links: this.countInternalLinks(html, url),
    external_links: this.countExternalLinks(html, url),
    images_without_alt: this.countImagesWithoutAlt(html),
    word_count: this.countWords(html),
    // ... 12 dimensions total
  };
}

Each dimension gets scored, then weighted into an overall score. Title, H1, meta description, and schema each carry more weight than, say, image count.

The Biggest Problems I Solved

1. SSRF Protection

The biggest security risk — users can scan ANY URL. Someone could scan http://169.254.169.254 (AWS metadata) and leak server keys.

function isSafeURL(urlString: string): { ok: boolean; error?: string } {
  const url = new URL(urlString);
  const hostname = url.hostname.toLowerCase();

  // Block private IPs, localhost, cloud metadata
  if (/^(10\.|172\.(1[6-9]|2\d|3[01])\.|192\.168\.|127\.)/.test(hostname)) {
    return { ok: false, error: "Private IP blocked" };
  }

  if (["169.254.169.254", "metadata.google.internal"].includes(hostname)) {
    return { ok: false, error: "Cloud metadata blocked" };
  }

  return { ok: true };
}

Every API endpoint that accepts a URL now runs through this before fetching.

2. AI Provider Fallback Chain

If Gemini fails, try Groq. If Groq fails, try Mistral. If all fail, generate offline insights from the scan data itself.

async function aiGenerate(prompt: string) {
  const providers = [
    { name: "gemini", fn: callGemini },
    { name: "groq", fn: callGroq },
    { name: "mistral", fn: callMistral }
  ];

  for (const provider of providers) {
    try {
      const result = await provider.fn(prompt);
      if (result.text.length > 0) return result;
    } catch {
      continue;
    }
  }

  // All failed — offline analysis
  return { text: generateOfflineInsights(prompt) };
}

Users always get results, even when APIs are down.

3. AI Output Formatting

LLMs return markdown with **asterisks** everywhere. Users saw raw formatting in the UI.

function stripMarkdown(text: string): string {
  return text
    .replace(/\*\*([^*]+)\*\*/g, "$1")
    .replace(/\*([^*]+)\*/g, "$1")
    .replace(/^[-*]\s+/gm, "")
    .trim();
}

Simple fix, huge UX improvement.

4. Header Link Explosion

The scanner counts every <a href> in the DOM. My header had both desktop mega menu AND mobile menu always rendered — just CSS-hidden. Scanner saw 90 internal links and flagged it as "Internal Link Overload."

// Before: Always in DOM (90 links)
<div className={mobileMenuOpen ? "visible" : "hidden"}>
  {tools.map(tool => <Link href={tool.href}>...</Link>)}
</div>

// After: Only mounts when open (34 links)
{mobileMenuOpen && (
  <div>{tools.map(tool => <Link href={tool.href}>...</Link>)}</div>
)}

5. Rate Limiting in Serverless

Vercel serverless = each request is a new instance. In-memory rate limiting doesn't work across instances. Currently using in-memory solution. Planning Upstash Redis for distributed state.

Honest Results

28 days live. Google Search Console:

2 clicks, 2,330 impressions
Position 76.8 (page 8)

The tool works well — tested against Ahrefs and Semrush, finds real issues. But without domain authority, Google doesn't care about features. Competing against DA 91 (Ahrefs) with DA ~5.

What's Next

WordPress plugin for easier distribution
Redis for proper rate limiting
Custom domain ($12/year — budget is tight)
More blog content (15+ articles and growing)

🟢 Try It

ai-seo-audit-seven.vercel.app — free, no signup, paste any URL.

Let's Build Together 🤝

I'm open to collaboration, strategic partnerships, or bringing in a co-owner/partner to scale this project, boost marketing, and take it to the next level.

Reach out to me on LinkedIn.

Built with Next.js 16, TypeScript, Supabase, and three AI providers. Open to feedback.