You resized every photo perfectly. The white background is clean, the dimensions are right, the file size is small. Then you upload your feed and half your products come back with "image cannot be fetched", "image not accessible" or simply no image at all.
This is one of the most frustrating failures in e-commerce because nothing is wrong with the image itself. The problem is the URL. Feeds do not carry your pictures; they carry a web address, and a robot on the other end has to fetch that address successfully, in bulk, possibly millions of times. If anything gets in the way, your listing runs blind.
This guide covers how image hosting actually works for product feeds, the specific URL rules on Google, Meta and the marketplaces, and the hosting traps that quietly kill listings.
Uploaded images vs fetched images
There are two completely different ways your photos reach a sales channel, and they fail for different reasons.
Direct upload. You drag a JPEG into Shopify, Shopee or Seller Central. The platform stores its own copy. Once it is in, it stays in. Nothing on your side can break it.
Fetched by URL. You give the platform a link and its crawler downloads the file. Google Shopping, Meta catalogues, most CSV bulk imports, and nearly every feed tool work this way. Your image is only as reliable as the server hosting it, forever, not just on upload day.
Sellers who have only ever used direct upload get caught out the first time they run a feed, because a link that opens perfectly in their own browser can still be unfetchable to a crawler.
What a valid image URL looks like
Google's specification is the strictest published one, and meeting it will generally satisfy everyone else too. An image URL must:
- Begin with http or https and comply with RFC 3986
- Use ASCII characters only, between 1 and 2,000 characters long
- URL-encode spaces and symbols (a space becomes %20, an ampersand becomes %26)
- Return a 200 status code directly, without redirects
- Serve the actual image file, not a web page that displays an image
- Require no login, no cookies, no session
That fourth point catches people constantly. "It works, I clicked it" is not the test. The test is whether an anonymous machine with no cookies, from a foreign IP address, gets an image file back.
Platform requirements at a glance
| Requirement | Google Merchant Center | Meta catalogue | Amazon (feed) |
|---|---|---|---|
| Minimum dimensions | 500 x 500 px | 500 x 500 px | 500 px; 1,000 px+ recommended for zoom |
| Recommended | 1500 x 1500 px or larger | 1024 x 1024 px or larger | 1,000 px+ on longest side |
| Maximum file size | 16 MB | Keep under 8 MB | 10 MB |
| Maximum resolution | 64 megapixels | Not published | 10,000 px longest side |
| Safe formats | JPEG, PNG, WebP, GIF, BMP, TIFF | JPEG or PNG | JPEG preferred |
| Protocol | http or https | https | https |
| Redirects allowed | Avoid | Avoid | Avoid |
Note the direction of travel on minimums. Google's old thresholds of 100 x 100 pixels for general goods and 250 x 250 for apparel are gone; the current requirement is at least 500 x 500 pixels, with 1500 x 1500 recommended so a single master file can serve Shopping listings, free listings and ad formats without upscaling. If your archive is full of 800-pixel supplier images, that is now the floor you are scraping.
The seven hosting traps
1. Google Drive and Dropbox share links
These are the single most common cause of failed image imports, and they are never fixable with a workaround that lasts. A Drive or Dropbox share link returns an HTML preview page, not an image file, and it may require authentication or break the moment sharing permissions change. Various "direct link" tricks circulate online; they are undocumented, rate-limited and change without notice. Do not build a catalogue on them.
2. robots.txt blocking the crawler
If your robots.txt disallows the directory your images sit in, Google treats every one of those images as missing. Two user agents matter: Googlebot and Googlebot-image. Check that neither is blocked from your image path. After fixing robots.txt, you must resubmit or reprocess the data source and allow roughly 24 to 48 hours before the change takes effect.
3. Hotlink protection
Many CDNs and hosts offer hotlink protection, which rejects any request whose Referer header is not your own domain. It is designed to stop other sites from stealing your bandwidth. It also blocks every feed crawler, because crawlers do not send your domain as a referrer. If images work on your site but fail in feeds, check this setting first.
4. Signed or expiring URLs
Cloud storage buckets often generate URLs with an expiry token. That is fine for a one-off download and fatal in a feed: the crawler comes back weeks later and gets an access-denied response. Feed image URLs must be permanently public.
5. Rate limiting during bulk fetch
A crawler pulling 3,000 images in a few minutes looks exactly like an attack to a security layer designed for human shoppers. Aggressive bot protection, or a shared host with tight limits, will start returning errors partway through and you will get a scattered, seemingly random set of failures. Random-looking failures across a large catalogue almost always mean throttling, not bad files.
6. Automatic format conversion
Modern platforms serve WebP or AVIF to browsers that support them and JPEG to everything else, based on the request's Accept header. That is excellent for page speed and risky for feeds. The safe approach is never to hard-code a modern format into a feed URL. Where a platform lets you pin the output, pin it to JPEG for catalogue and feed links, and let format negotiation happen only on your storefront.
7. Geographic restrictions
If your CDN or firewall blocks traffic from regions you do not sell to, you may also be blocking the data centre the crawler runs from. Whitelist crawler access rather than relying on country rules.
The caching rule almost nobody knows
This one is worth the price of admission. When you replace a product photo, how you replace it determines how fast the change appears.
- New image at a new URL: typically recrawled within 24 to 72 hours.
- New image at the same URL: can take up to six weeks to refresh.
New product images are usually crawled within about three days of submission. But overwriting a file in place, keeping shoe-black-01.jpg as the filename, is the slowest possible path, because the crawler has no signal that anything changed. If you have just reshot a hero image and want it live for a campaign, upload it under a genuinely new filename and update the feed. If you have a stable image that is not changing, leave the URL alone; stable URLs are what you want the rest of the time. Avoid timestamps or random strings that change on every feed build, which forces needless recrawling of images that never changed.
Where to host
In rough order of reliability for feeds:
- Your e-commerce platform's own CDN. Shopify, BigCommerce and similar serve stable, public, permanent URLs. For most sellers this is the correct answer, with the format caveat above.
- A dedicated image host or object storage with public read. Predictable, cheap, no hotlink surprises. Set it to public, not signed.
- Your own web server. Fine if it can handle bulk crawling and you control robots.txt.
- Consumer file-sharing services. Not viable. See trap one.
Whatever you choose, the master file you upload should already be correctly sized and compressed. Serving a 6 MB original and relying on the channel to downscale it wastes crawl budget and risks timeouts. Preparing one properly sized master per channel before it ever hits your host is the whole point of a tool like PixelPrep: get the pixel dimensions and file size right once, then let the URL simply do its job.
How to test a URL properly
Paste the URL into a private or incognito window. If it renders the raw image on a blank background with no site chrome around it, that is a real image URL. If you see a preview page, a download button, or a login screen, it will fail. For a stricter check, open the URL on mobile data rather than your home network, which rules out anything cached or whitelisted locally.
Pre-flight checklist
- URL starts with https and returns 200 with no redirect
- Opens as a raw image in an incognito window
- No spaces or non-ASCII characters; everything URL-encoded
- Under 2,000 characters
- At least 500 x 500 px, ideally 1500 x 1500 px
- Under 16 MB, and realistically under 1 MB for sane crawl performance
- JPEG or PNG, with no automatic WebP or AVIF conversion on that link
- robots.txt allows Googlebot and Googlebot-image
- Hotlink protection disabled for the image path
- No expiry token in the URL
- URL stays stable between feed builds, and changes only when the picture genuinely changes
Work through that list once, properly, and image fetch errors largely stop being part of your life. The photography is the hard part. Do not let a redirect throw it away.