Blocking a Shopify Bot Attack, Not the Buyers

The problem

• A live store with thousands of dollars of daily orders was under sustained automated traffic.
• Shopify already runs behind its own CDN and does not permit proxying the storefront through a merchant’s Cloudflare account, so the WooCommerce playbook did not apply.
• Blocking too broadly risks blocking paying customers, which costs more than the attack.
• Search engine crawlers had to keep full access or the store’s rankings would suffer.

How we found the cause

• Analysed the traffic to establish which regions the automated requests were coming from, rather than blocking on assumption.
• Worked out where control was actually possible: Shopify runs its own CDN and will not let a merchant proxy the storefront through Cloudflare, so the fix had to sit at the storefront layer.

The fix

• Used Blockify, which operates at the storefront layer where Shopify’s architecture actually allows control.
• Blocked at least four attacking regions, chosen from the traffic data rather than a generic list.
• Whitelisted SEO crawlers explicitly: blocking a region is easy, keeping Googlebot inside it while shutting out attackers is the part that takes care.

The result

• Attack traffic filtered without interrupting sales.
• Store continued trading throughout the work.
• Search engine access preserved, so no ranking impact from the mitigation itself.

What this means for you

The same problem needs a different fix on a different platform. On WooCommerce you control the server and can put Cloudflare in front of it. On Shopify you cannot, so the work has to happen inside the tools Shopify allows.

Blocking by region is a blunt instrument unless the traffic data drives it. Choosing regions from what the requests showed, and letting search crawlers through on purpose, is what kept both buyers and search visibility intact.

On a store taking orders every day, the mitigation itself must not interrupt trading. That constraint shaped every step of this job.