What you'll find in this article
- How Google Merchant Center's automatic detection system works , two distinct phases
- The 8 most common technical causes of rejection with the exact error code in Merchant Center
- The "hidden" causes that generate disapprovals without a clear explanation , from direct experience
- How Automatic Image Improvements works and when to trust auto-correction
- Real reprocessing times and the technique to speed them up from 6 weeks to 24–72 hours
- How to structure a systematic catalog audit to find and fix disapprovals
You open your Google Merchant Center account on a Monday morning and find dozens of rejected Google Shopping images. The error says "Promotional overlay" but the images look clean. Or "Poor image quality" on visually perfect images. Or , the most frustrating situation , no explicit error but products won't go live in Google Shopping ads.
The problem isn't that Google is arbitrary. It's that the image evaluation system has precise logic that the vast majority of advertisers don't know in detail. This guide explains all of it, with a clear distinction between what is officially documented and what emerges from direct management of real catalogs.
How the detection system works: two phases, two logics
When you upload an image in the feed via the image_link attribute , alongside the rest of the product data , your Google Merchant Center account initiates a sequential verification process
in two distinct phases. If the first fails, the second is not executed , and the type of error you see in diagnostics changes accordingly.
Phase 1 , Technical verification (automatic, fast): The system checks that the URL is reachable, that the file format is supported, that dimensions meet the required minimums for different product types, that the file
size doesn't exceed 16 MB and that the color profile is compatible. This phase occurs almost instantly after crawling. If it fails, the error is clear and technical: Invalid image or Image too small.
Phase 2 , Editorial verification (computer vision): This is where content analysis begins. The system analyzes what's in the image , it detects overlaid text, watermarks, logos, placeholders, and the presence and quality of the product. This is the phase that generates the most ambiguous errors: an image can pass all technical requirements and still be disapproved here.
Invalid image,
Image too small, Promotional overlay on image, Text on image, Poor image quality. Source: Google Merchant Center Help , Product image requirements.
Something very few people know: processing times vary enormously depending on how the image is updated in the feed. It doesn't depend on the severity of the problem , it depends exclusively on the update method. I cover this in detail in the section on reprocessing times.
The 8 technical causes of rejected Google Shopping images
The system detects any graphical element covering the product , prices burned into the image ("€29.99", "50% OFF"), marketing text ("Free shipping", "Discover now"), photographer or brand watermarks, logos overlaid in post-production. Promotional overlay on Google Shopping generates immediate disapproval. Logos that are physically part of the product , printed on the product itself , are permitted: the system distinguishes between post-production overlays and text physically present in the photographed product.
Current minimums are 100×100 px for non-apparel products and 250×250 px for apparel. Since April 2026, warnings have been active for images below the 500×500 pixel Google Shopping 2027 threshold, with enforcement from January 31, 2027. The system also detects artificially enlarged images via upscaling , an original at 80×80 px brought to 200×200 px with resize does not pass the quality check even if it reaches the technical minimum dimensions.
The CMYK Google Shopping issue is one of the most insidious rejections. Merchant Center only supports RGB. CMYK files , typical of print exports from Illustrator, InDesign or Photoshop in Print mode , produce altered colors or abnormal saturation that the system interprets as insufficient quality. The error never explicitly mentions CMYK: if you see "Poor image quality" on a visually correct high-quality image, check the color profile first. In Photoshop: Image → Mode → must be "RGB Color".
An image not crawlable Google Shopping error means the image URL is not publicly accessible or is blocked by robots.txt. Common causes: CDN requiring authentication for certain referrers, robots.txt rules blocking Googlebot, images on domains with expired SSL certificates, expired temporary URLs. The system also checks that the URL responds with the correct Content-Type , a URL returning HTML instead of an image file, or redirecting to a landing page rather than a direct image resource, is rejected even if it visually displays an image in the browser.
Any generic image , "No Image Available", icons, logos as the main image, product silhouettes, empty packaging without the product , generates immediate disapproval. The system identifies the image subject and verifies it is a specific product, not a generic graphic element. Any Google Merchant Center product submitted with this type of image is flagged immediately at the editorial review stage. Catalogs imported from legacy systems or suppliers often bring this type of Merchant Center image disapproval at scale.
If you sell red shoes but the image shows the black model, or you sell size S but the image shows the "L" label, the system can flag the discrepancy. In catalogs with many color variants this error is frequent when the main image is shared across variants instead of being specific to each one. Severity varies: in some cases it's a warning, in others a full disapproval, and in severe cases it can contribute to account suspensions.
If you use the is_bundle attribute in the feed, the main image must show all items included in the bundle, clearly visible together. Showing only the main item generates disapproval. The rule varies based on product types
and feed attributes: for multipacks (multipack), the main image must instead show a single unit , the complete pack and additional information about the contents go in additional_image_link.
Merchant Center systems are progressively becoming more capable of detecting artificially generated backgrounds , via IPTC metadata that tools like Photoshop Generative Fill automatically embed in the file, and via shadow inconsistencies between the real product and the synthetic background. It's not AI detection itself that's the problem: it's the discrepancy between the photographed product and the artificial environment. Google requires that the image faithfully represent the product as it would appear in reality , a core user experience principle that underpins the entire image policy.
Hidden causes that generate disapprovals without explanation
CDN with dynamic parameters in the URL. Some e-commerce systems serve images with URLs that include temporary tokens , like image.jpg?token=abc123&expires=1716000000. When Google crawls, the token has
already expired and the image appears inaccessible. The error appears as Invalid image or Image not crawlable without indicating the token issue. The solution is to serve images from static URLs without temporary
parameters.
The "perfect" image that generates "Poor image quality". I have seen high-resolution images, well-lit, with a neutral background, without text , everything correct , still generate this error. The most frequent cause: CMYK color profile (cause 3), or excessive JPEG compression that created artifacts visible only at pixel level but detected by the automated system. A JPEG quality below 60% can generate artifacts that the system interprets as low visual quality.
The brand logo on the price tag. A recurring pattern: apparel products photographed with the price tag visible in the image. The system detects it as a promotional overlay even though it is a physical part of the product. The official rule permits text naturally integrated into the product , but in practice the system doesn't always distinguish between a tag attached to the product and an overlay added in post-production. The simplest solution: remove the price tag before photographing.
Images shared across different variants. When multiple SKUs use the same image , typical in catalogs with many size variants , the system may flag inconsistencies between the product declared in the feed and the one shown, even if the image is technically correct for the color. Catalogs with unique images for each variant have significantly lower rates of rejected Google Shopping images compared to those with shared images.
Automatic Image Improvements: when to trust auto-correction
The feature works well for simple cases: a thin watermark in a corner, a small logo, promotional text on a relatively uniform background. The limitation emerges when the overlay is large, complex or positioned over the main subject , in these cases automatic removal often produces visual artifacts worse than the original image.
There's also a side effect to keep in mind: if Automatic Image Improvements is active and you're testing intentional overlays , for example to see how far the system tolerates promotional overlay on Google Shopping , the feature will remove them before you can observe the behavior. For this type of testing, it must be temporarily deactivated.
When not to use it as a definitive solution: when Merchant Center image disapprovals are systematic across many products. In that case, auto-correction resolves the symptom but not the cause , the same problematic images will continue to be uploaded, and the disapproval → auto-fix → new upload cycle is inefficient at scale.
Real reprocessing times , and how to speed them up
This is perhaps the most practical and least known information in the entire guide. Reprocessing times depend almost exclusively on your feed management choices , specifically, how you update the feed , not on the severity of the problem or the product category.
You update both the file and the image URL in the feed. Google treats it as a new image and reprocesses it as a priority.
You update the file but keep the same URL. Google must wait for the next scheduled re-crawl of that URL.
No changes to the feed , you wait for the natural re-crawl. The slowest method and the one that costs the most lost impressions.
The practical technique: when you fix an image, add a parameter to the URL , even just ?v=2 or ?updated=20260516. For Google it's a different URL and it reprocesses it within 72 hours. Nothing
changes for the browser or the server , it's just a signal to the crawler that the image has changed.
I applied this technique on catalogs with hundreds of rejected Google Shopping images: instead of waiting for the natural re-crawl over weeks, I updated the feed with parameterized URLs and approvals came within 3 days. The difference in terms of recovered visibility in Google Shopping ads is direct , every day of disapproval is a day without impressions on those products.
image.jpg?v=2 exactly like image.jpg and
serve the cached version , which is still the old one. In that case you need to force cache invalidation explicitly in the CDN, or change the physical filename of the image.
How to perform a systematic audit of Merchant Center image disapprovals
If you manage a small catalog (under 200 products), you can manually check the Needs Attention section in your Google Merchant Center account and fix issues case by case. On large catalogs , thousands or tens of thousands of SKUs , a systematic five-step approach is needed.
Step 1 , Extract the complete error report. In Merchant Center go to Products → Diagnostics → Download. You get a CSV with all problematic products, the error type and the attribute involved. Filter for errors related
to image_link and additional_image_link to isolate only image issues.
Step 2 , Group by error type, not by product. The most frequent error often has a common cause , a photo session with CMYK background, an integration that automatically adds watermarks, an image template with embedded text. Fixing the systemic root cause is worth more than fixing a hundred products individually.
Step 3 , Prioritize by commercial value. Not all rejected Google Shopping images carry the same economic weight. High-margin, high-turnover or most-searched products should be fixed first. Recovering visibility on 20 strategic products can be worth more than fixing 200 marginal products.
Step 4 , Update URL and file simultaneously. Prepare the corrected images, update them in the system and modify the feed with the new parameterized URLs in a single operation. As explained in the previous section, this is the fastest way to force reprocessing and recover visibility in Google Shopping ads in the shortest time possible.
Step 5 , Monitor regularly, don't wait for crises. Merchant Center image disapprovals accumulate silently , Google doesn't send emails for every disapproved product. A weekly check of Merchant Center Diagnostics is sufficient to catch product disapprovals , including image-related ones , before they accumulate silently into a larger problem.
FAQ on rejected Google Shopping images
Why does Google Shopping reject images with text or logos?
How long does it take to re-approve a Google Shopping image after correction?
?v=2 ,
which signals to Google that the image has changed and forces a re-crawl within 72 hours instead of waiting for the natural cycle.