Image policy and image disapprovals
The image rules that get products disapproved in Merchant Center, promotional overlays, placeholders, low resolution, crawler blocks and generic shared images, and how to fix each.
Image disapprovals are among the most common and the most fixable, but they stall merchants because the reason string rarely explains what's actually wrong. The causes fall into a short list: promotional overlays, placeholder images, images too small or too generic, and images Google's crawler simply can't fetch. This guide covers each cause and its fix.
What Google wants from a primary image
The image_link is the single most-seen attribute on a product (it's what a shopper looks at before anything else) so Google polices it hard. The primary image has to show the actual product, clearly, on its own, at reasonable resolution, with nothing added on top. Everything that gets disapproved is a departure from one of those: the product isn't clear, isn't the subject, isn't real, has something stamped on it, or can't be fetched at all.
Lifestyle and detail shots belong in additional_image_link, where the rules are looser. The primary is the one that must be clean.
The five causes
1. Promotional overlays
Anything added on top of the product image: text ("Free shipping", "50% off"), price stamps, sale flashes, badges, borders, watermarks, or a logo burned into the corner. Google's editorial check catches these because they turn a product photo into an advert. The fix is a clean product-only primary image; move any promotional treatment off the primary entirely.
2. Placeholder and missing images
"Image coming soon", a grey silhouette, a brand logo standing in for a product, or a broken link. These read as no-image and get disapproved. Every product needs a real photo of the actual item; products awaiting photography should be held back from the feed, not shipped with a placeholder.
3. Low resolution and staging problems
Below Google's minimum dimensions (non-apparel images should be at least 100×100 px, apparel at least 250×250 px, and larger is strongly preferred), heavily compressed, or the product tiny within a mostly-empty frame. Also flagged: single-colour or blank images, and images where the product is obscured. Fix with a properly-sized image where the product fills most of the frame.
4. Crawler blocks
The image exists and looks perfect in a browser, but Google's image crawler can't fetch it: so from Google's side there's no image. Causes: CDNs that block unknown user-agents, hotlink protection, cookie or referrer requirements, aggressive rate limiting, or a robots.txt that disallows the image path. This is the most misdiagnosed image disapproval because it looks fine to you. Whitelist Google's image crawler and remove fetch barriers on the image host.
5. Generic and shared images
One image reused across genuinely different products, or across colour/pattern variants that should look different. Google flags this as generic or mismatched: the image doesn't represent the specific item. Each distinct product and each visually-distinct variant needs its own representative image.
Reading the reason string
| Reason string | Cause | Fix |
|---|---|---|
| Promotional overlay on image | Text, badge, watermark, border | Clean product-only primary |
| Generic image | Placeholder or shared-across-products | Real, product-specific image |
| Image too small | Below minimum dimensions | Re-export at higher resolution |
| Image cannot be crawled / fetched | Crawler blocked at the host | Whitelist crawler, drop hotlink protection |
| Missing image | Empty or broken image_link |
Supply a working URL |
Deep dive Crawler blocks and why they're the hardest to catch
Most image disapprovals are visible: you look at the image, you see the badge, you fix it. Crawler blocks are the exception, and they cause the most wasted time because the image is perfect and the URL works when you click it. The disconnect is that Google's image crawler is not your browser: it arrives with a specific user-agent, no session cookies, no referrer from your site, and it hits every image URL in your catalogue in bursts.
That combination trips defences built for humans:
- User-agent filtering: a CDN or WAF configured to serve only known browser agents returns a 403 to the crawler while serving you a 200.
- Hotlink protection: image hosts that check the
Refererheader block requests that don't originate from your domain; the crawler has no referrer. - Rate limiting: a crawler fetching thousands of images in minutes looks like abuse to a rate limiter tuned for human traffic, and gets throttled or blocked mid-run, producing intermittent disapprovals that come and go.
- Cookie or auth walls: any image path that expects a session will fail a cookieless fetch.
- robots.txt: an image directory disallowed in
robots.txtis off-limits to the crawler entirely.
The tell is intermittency and inexplicability: images that disapprove and re-approve on their own (rate limiting), or a whole image-host migration that disapproves thousands at once with URLs that all resolve fine in a browser. The fix lives on the image host, not in the feed: but catching it needs the feed layer to validate that image URLs are actually fetchable by a crawler-shaped request before submission, not after Diagnostics reports a fetch failure. /tools validates image URLs at the feed layer and surfaces unreachable images before they cost you a disapproval; because enrichment is non-destructive, corrected or substituted image links sit in a supplemental layer over your source data. See Feed Health Score explained.
Fixing image disapprovals
- Read the reason string first to know which of the five causes you're dealing with: the fixes don't overlap. See the disapproval taxonomy and Diagnostics.
- For overlays and placeholders, replace the primary image with a clean product-only shot; keep lifestyle and promotional treatments in additional images.
- For low resolution, re-export above the minimums with the product filling the frame.
- For crawler blocks, test the URL with a crawler-shaped fetch, then fix the host: whitelist the crawler, drop hotlink protection, relax rate limits.
- For generic images, give each product and distinct variant its own image.
Image disapprovals are data issues, so they clear automatically on the next crawl once the corrected image_link is live: no re-review request needed unless the item also carries a policy flag.
Frequently asked questions
Google says my image is promotional but there's no text on it. Why?
The overlay check catches more than text, badges, borders, watermarks, call-outs like a sale flash, or a logo stamped into the corner all count as promotional. It can also flag a busy lifestyle composite where the product isn't the clear subject. Use a clean product-only image on a plain background as the primary.
My image URL works in a browser but Google says it can't fetch it. What's wrong?
Google's crawler isn't a browser. Image CDNs that block unknown user-agents, require cookies, hotlink-protect, or rate-limit will serve you fine and fail the crawler. Whitelist Google's image crawler and remove hotlink protection on the image host.
Can two variants share one image?
Colour variants can't. A red and a blue variant showing the same image reads as a generic or mismatched image and gets disapproved. Each distinct sellable variant needs an image that shows that variant.