Why Shopify's image fetcher fails on WooCommerce images

Shopify never takes an image file from you. It takes a URL and goes off to fetch it itself. That is true of a CSV import and it is equally true of any app built on the Admin API, including ours.

So the thing that decides whether your images survive a migration is not which import method you picked. It is whose server that URL points at, and how hard Shopify hits it. An app that passes your WooCommerce URLs straight through to Shopify runs into exactly the same wall a CSV does.

If the URL points at your WooCommerce server, your WooCommerce server has to survive Shopify’s fetcher. Plenty don’t.

Shopify’s fetcher has no speed limit. Point it at a catalogue of 7,000 products and it starts pulling images in parallel, as fast as your server will answer, with no pause between requests and no browser attached.

Your host reads that correctly. Hundreds of rapid requests from an IP that has never visited before, walking through /wp-content/uploads/ in order. That is what a scraper looks like, and shared hosting is tuned to stop scrapers.

So it stops them. Here is what Shopify tells you when that happens:

Media upload failed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed
Image: Media failed to process because the image could not be processed

Seven of those on one product, in our case. No filename, no URL, no reason. You cannot tell which images failed or why, and the message is identical whether your server refused the request, the format was wrong or the file was 30 MB.

This is the most common thing that goes wrong

Many of our early support conversations related to images came down to a host, a CDN, a security plugin or a country block refusing to hand over data. It is the single largest category of problem we deal with.

Ranked by how often we see them: Cloudflare, Wordfence, Hostinger, Cloudways, SiteGround, then ModSecurity. Kinsta, IONOS, o2switch, Rocket.net, InMotion, Raidboxes, MalCare and Defender Pro each show up too.

Not one of those is a badly run host. They are doing the job you pay them for. The trouble is that a migration and an attack look identical from the server’s side.

Why your product data imported but your images didn’t

This catches people out constantly, because it looks like a bug in the import rather than a block.

Product data comes across in a handful of API calls. A few hundred requests, spread over minutes, from one IP. Most firewalls let that through without complaint.

Images are thousands of requests in a burst. Same server, same store, completely different traffic pattern. So the products land, the catalogue looks right in the Shopify admin, and every product page is a grey placeholder.

One store we migrated got all 6,929 products across with no images at all. Cloudflare was the only thing in the way. Once their developer allowed our server through, a re-run with “overwrite products” filled every image in.

Sometimes the host is clearer than Shopify about what happened. A Danish store running Defender Pro returned this on every image request:

403 Forbidden – Request forbidden by administrative rules

A Hostinger store was blunter:

Your country is not allowed to access this resource

That was a country block in Hostinger’s WAF. Our servers are in the Netherlands and Germany, and the store had blocked most of Europe. In another case a merchant had blocked the entire EU in Wordfence because they don’t sell there, not realising they had also blocked every European service they use. Her words, not ours: “it was a country block since we can’t sell to the EU.”

Formats are the other half of it

Shopify accepts a specific set of image formats and nothing outside it. WooCommerce sites, especially ones running an image optimiser plugin, often serve something Shopify will not take.

Shopify has broadened what it accepts recently, so this bites less than it used to. It still bites. The file loads perfectly in your browser, Shopify refuses it, and you get the same “could not be processed” line you get for a firewall block.

What about the images inside your descriptions?

Nobody checks these before cancelling their WordPress hosting.

Size charts, lifestyle shots, care instructions and comparison tables usually sit inside the product description as plain HTML pointing at yourstore.com/wp-content/uploads/. Most imports copy that HTML across untouched. The images keep loading, the descriptions look perfect, everyone signs off.

They break the day the old server goes away. Every description image in the catalogue fails at once, months later, with nobody watching.

What we do about it

WooCommerce Importer does not point Shopify at your server and hope.

We collect your images ourselves, at a pace your server reads as ordinary traffic rather than an attack, and we make sure what reaches Shopify is in a format Shopify will accept. Images referenced inside your descriptions are handled as well, so your product pages stop depending on your WooCommerce server still being online next year.

That is the short version on purpose. The details are ours.

Where this still goes wrong

Sometimes we get blocked anyway, and pretending otherwise would waste your time.

Allowing one layer through is usually not enough. Most stores have two or three protections stacked, and an allow-list rule only covers the one you edited. A customer on Cloudways behind Cloudflare allowed our server IP on both and was still getting 403s. Only turning off Cloudways bot protection got the import moving, and it blocked us again partway through a 1.3 million variant download.

Some hosts won’t allow-list at all. The hosting company o2switch told a customer, in writing:

Hello, We do not whitelist IPs in a shared hosting environment.

Another hosting company, simply.com, has no allow-list feature at all and blocked us even when we slowed to a crawl. We got 935 of that store’s 14,059 products through before it cut us off, and finished the rest by waiting out the automatic block.

And occasionally we lose. Not too long ago, a store had Cloudflare lowered enough for products to import, then ModSecurity blocked every single image. The server was run by an outside agency who wouldn’t turn it off. That store migrated without images. If you can’t get someone with server access on your side, no migration tool is going to fix that for you.

There is one more move before you give up on it. If your host will not budge and nobody with access will override it, we can take the migration over and run it ourselves as a $299 expert migration. Your host stops being the thing that has to cooperate. It needs full server and database access rather than an API key, so it starts with an email instead of an app install.

It will not rescue product data that was already broken in WooCommerce. What it does is get you past a server that has decided you are an attacker.

Before you start, ask your host one question. Is there a firewall, a WAF, a country restriction or a security plugin in front of this site, and who can change it.