Image Compression Kills Ranking More Than You Think
So, this started because I was shaving 20 milliseconds off a Shopify store’s load time, and tanked a whole category’s organic traffic for four weeks. I compressed a bunch of product images using TinyPNG, uploaded them via the theme assets folder — and watched impressions die like flies. Turns out, text in images got flattened a bit weird. At 100% zoom, they looked fine; but Google’s image processing choked on them. Rank drop followed within the week. Classic “optimize too hard” move.
If you’re using aggressive lossy compression on product images — especially those with embedded labels, text, logos, or patterns — Google might misread them or not index them at all. WebP helps, but quality settings matter way more than you’d think. You can get away with around 75 quality most of the time, but anything below 60? Yeah, expect weirdness in Search Console.
Also, some CDNs auto-recompress to a default setting you can’t easily override per-file. Cloudflare Pro does this if you’ve turned their Polish feature on. Took me too long to realize the actual culprit wasn’t the images I’d exported — it was the second layer of “optimization” on edge delivery.
Don’t Use CDN Caching to Mask Bad Alt Text
I had this dumb moment where I thought renaming image files and setting well-crafted alt tags would instantly improve our placement in Google Images. Reality? Our CDN (StackPath at the time) was caching old image metadata headers, and those alt updates weren’t reflected until I invalidated the cache manually. Painful, but it taught me: browser caching longevity is not your friend when debugging SEO image problems.
Debug it by using incognito AND curl. Seriously, use:
Check for any weird headers like X-Image-Optimized or edge hints that might show stale metadata. Especially if you just changed an image caption or switched from poorly-worded alt attributes to more descriptive ones. If you’re seeing a rank improvement delay of multiple days — but Google’s last crawl date shows as recent — blame your server cache with extreme prejudice.
Stop Relying on CMS-Level Filename Generation
Most e-commerce platforms (Shopify, BigCommerce, Wix, even Squarespace) autogenerate image filenames on upload. They’ll grab something like IMG_4732 or sanitize the user-given name into red-shoes-2023_large.webp. It’s clean, sure, but SEO-dead. Google uses filenames as a low-signal-but-still-relevant hint, especially when combined with structured data and alt text. And that hint disappears when images are lazy-cloned across multiple product templates.
One workaround I’ve used: export images with a filename that includes the product’s main longtail keyword — even if you rename them later in the CMS. This way, during initial upload (when Google first discovers them), they’ll carry the semantic weight you’re after. Shopify obfuscates filenames less now than they used to, but double-check the end URL with full CDN path after upload to make sure your name made it through.
Quick test? Open the product page in Chrome, right-click the image, and copy image address. If it’s delivering something like /files/UGG-boots-womens-classic.webp, you’re golden. If you’re getting random hashes or pipeline IDs, don’t count on it ranking in image search anytime soon.
Undocumented Quirk: Responsive Srcset Can Break Alt Detection
This one’s subtle. I discovered it after converting a fashion store’s theme to use <img srcset="..."> properly. After deployment, our alt-based rankings started nose-diving. The images were still there, still loading fine, and looked great across devices.
Eventually found an old Stack Overflow thread buried in GitHub issues that referenced a weird case where Googlebot sometimes doesn’t correctly attribute the alt tag when the srcset attribute loads a different image dimension than the base src. No official confirmation from Google, but the moment we hardcoded one fallback image per page (without srcset), those images reappeared in Search Console’s “Image indexed” reports.
Feels like a rendering timing issue inside Google’s mobile crawler. Edge adaptive rendering timing maybe? Don’t know. But it exists, and it’s real. Sometimes your clever sizes setup turns invisible fast.
Structured Data and Images: You’re Probably Doing Half of It Wrong
Most people focus on the image attribute inside Product or Offer schemas, and call it a day. But that property alone isn’t enough if you’re trying to win a spot in product carousels or image-rich results. What helped a ton in one of my builds was referencing each product image twice: once in schema directly, and once within embedded HTML with descriptive context right above or below it. Think caption or review block.
Putting context around the image, both visually and structurally, is what seems to push crawlers over that relevance edge. Also weirdly useful: embedding a unique image for each similar variant, and specifying additionalProperty with matching metadata fields (size, color). Tedious? Yep. But I saw an increase in click-through for a category with nearly identical silhouettes (plain t-shirts — not a visually loud product type).
“We index images based on multiple signals—not just the image file, but the surrounding context and page structure.” — Not even from Google, just some guy in a webmaster chatroom in 2018. Still true.
The Longtail of Lazy Loading
Lazy loading is the new default on almost every template out there. And for performance? Sure. It helps. For image indexing? The effect is messier. Googlebot can’t always trigger JavaScript-based image loading, so unless your images are using loading="lazy" natively (and defined high in the DOM), they may never get seen.
Don’t append product images below the fold with JS-only infinite scroll unless you’ve tested it with the Mobile Friendly Test tool.
Use intersection observers if you must use custom JS lazy loading, but add a <noscript> fallback with basic <img> tags pointing to actual product image URLs.
Verify indexing visually by doing a site: search on your product page, then looking at the cached image links. Set your cache-control headers short-term to retrigger crawl events for lazy content.
If you’re in Shopify, there’s an arcane Liquid filter bug where {{ image | img_url: 'large' }} doesn’t work right with AVIF generation in some themes — feeding ghosts to Google instead of real URLs.
The crawl budget on small shops is already tight. Don’t waste it tossing out DOM-lazy silhouettes wrapped in three layers of Vue spaghetti.
Bonus: EXIF Meta Still Matters Indirectly
Yeah, I know everyone strips EXIF nowadays. Privacy, filesize, speed. But on high-ticket listings — cameras, paintings, cars — leaving some geo-attribution data in EXIF can actually help Google understand context. Not for ranking directly, but for clustering images with similar regional context. I left coordinate data in for a batch of hand-painted map posters and got a bump on local-intent image searches.
It’s subtle. Nothing you’d call a silver bullet. But if you’re selling stuff with place-based appeal or provenance — rugs from Turkey, boots from Alberta — and you geotag your original images prior to upload? Just maybe, it helps build that fuzzy background signal that Google’s stitching together behind the scenes.
