Every Shopify Store Has a .myshopify.com Back Door. Bots Are Hitting It at 500 Carts an Hour.

Shopify routes every store's default *.myshopify.com subdomain through its own Enterprise Cloudflare account, which bypasses any WAF, hCaptcha, or bot-blocking app a merchant configures on their custom domain. One DTC store reported over 500 fake cart additions per hour through this back door in late April 2026. Shopify's reply, per the merchant, was that no backend block exists.

The headline number comes from a merchant who eventually posted on the Shopify community forum after roughly three months of trying everything. Their thread documents hCaptcha, reCAPTCHA, Cloudflare Challenge Mode in front of the storefront, ASN blocking, and at least one paid bot-protection app. None of it worked. The bots kept hitting *.myshopify.com directly and dumping fake carts, mostly on out-of-stock SKUs. The case got amplified by an industry post on PPC Land a few days ago.

If you have never thought about your *.myshopify.com URL, here is why it matters. That subdomain is the canonical host for your store. It sits inside Shopify's Cloudflare Enterprise tenant, not yours. Whatever firewall, bot management, or rate limiting you wired up on yourshop.com runs on the wrong host name. Anyone who learns the underlying subdomain (it is trivially discoverable, the format is just store-handle.myshopify.com) can hit the store directly and skip the lobby entirely.

The fix you are probably picturing doesn't exist

Shopify prohibits Cloudflare's orange-cloud proxy on the custom domain, which means you cannot put your own WAF in front of the storefront. The only Cloudflare-side option, Orange-to-Orange (O2O), is restricted to Shopify Plus stores running Cloudflare Enterprise. Together that runs roughly $60K a year, and it still does not allow custom firewall rules. So the workarounds most agencies suggest (turn on Cloudflare bot management, write a rate limit) are operating at the wrong layer entirely.

That is the part that took me a minute to accept. The bots aren't getting around your defenses. They are routing past them.

This is happening because the wider AI bot floor just shifted

Retail bot traffic is no longer background noise. Botify's 2025 retail report measured AI-driven bot volume at 5.4x its Q1 baseline by the end of the year, with food and grocery up 29x and Home and DIY up 11x. The bots are after pricing and inventory state because that is the data AI shopping agents need to keep their answers fresh.

The other half of the problem is impersonation. A joint Botify and DataDome study found 7.9 million requests over a sample period using a fake ChatGPT-User agent, plus 16.4 million using a fake Meta-externalagent. Most WAFs allow-list those user agents because blocking ChatGPT means losing AI Overviews citations and ChatGPT Search visibility. Bot operators know that. They wear the costume.

If you want to see the real list of legit AI crawler signatures, so you know what you are not supposed to block, Search Engine Journal keeps an updated registry.

500 fake carts an hour is not a vanity number

If you are running paid traffic into Shopify, this matters in three places you might not have connected yet.

First, your conversion modeling. Google's Smart Bidding and Meta's Conversions API both ingest cart events. If the floor of your "added to cart" volume is, say, 12,000 fake actions a day, the algorithm starts optimizing toward whatever those bots look like, which is mostly nothing. Several PPC managers have reported their accounts drifting toward audiences that never converted because the conversion signal got polluted.

Second, your inventory display. Out-of-stock items are the bots' favorite target because they want stock-state data. Genuine shoppers see "low stock" warnings that are actually low-stock-because-of-bots warnings, and they bounce. The lift you thought you were getting from urgency cues is partially noise.

Third, your fraud screen. Shopify Flow can clean up after the fact, but if you let one of those fake checkouts hit Stripe and you are not on manual capture, you will eat the chargeback cost.

This pairs badly with the promo code abuse pattern that just cost a Shopify store €18,000 over a weekend. Both attacks exploit the same gap. Shopify's defaults assume merchants will add the security layer themselves, and the platform does not give them the hooks to actually do it.

The one thing that fully stops it (and the GMC problem it creates)

Mandatory customer account creation before checkout. That is the only defense merchants have reported as fully effective, because it forces the bot to pass an email verification step.

The catch is that Google Merchant Center policy requires guest checkout on stores that want Shopping ads or free product listings. Emmanuel Flossie, Google's Diamond Product Expert for Ads, framed it cleanly in the original write-up: the policy intent is that guest checkout has to remain accessible. So forcing accounts means losing your Shopping feed.

For most stores, that trade is not worth it. The bots are annoying. Your free organic Shopping traffic might be your largest channel.

Stopgaps you can ship this week without nuking your Shopping feed

A few things that don't require killing GMC eligibility:

Switch to manual payment capture. The fake cart still happens, and the order still appears, but no charge clears, and you can bulk-cancel before reviewing legitimate orders.

Use Shopify Flow to auto-delete accounts created with throwaway-pattern emails or unverified addresses inside a 24-hour window. It is free, no app needed, and it stops the bot accounts from accumulating into something that screws with your Klaviyo segments later.

Filter your analytics at the GA4 or Meta CAPI layer rather than the Shopify pixel. If you are sending events from Shopify directly, swap to a tag manager setup that fires only on verified human signals (scroll depth plus dwell time plus mouse movement). Your CPA numbers will probably drop in week one, which is worth knowing even if nothing else changes.

For Shopify Plus stores: get on the roadmap for O2O Cloudflare Enterprise. It does not solve the problem entirely, but it lets you write a few rules that catch the worst of it.

For everyone else: monitor the *.myshopify.com host directly using a free tool like UptimeRobot, or ship logs to a cheap log store. If you see bot traffic spike on the back-door host independently from your custom domain, you can at least prove to Shopify support that the issue exists, which seems to be the bar for getting any kind of human response.

What Shopify isn't saying out loud

The reason there is no backend block is that Shopify cannot offer one without breaking how its own platform works. Apps, themes, third-party integrations, the storefront API, Hydrogen, all of it hits *.myshopify.com under the hood. A blanket redirect to the custom domain would cascade through the whole ecosystem.

What Shopify could ship is an opt-in toggle that 301s any non-API browser traffic from *.myshopify.com to the merchant's custom domain. That keeps the developer surface intact and closes the front door. From what I have seen on the community threads, that is exactly what merchants are asking for, and it has been quiet for a while.

Until that toggle exists, the answer for most merchants is to assume your bot defenses are partial, set up payment capture and Flow rules to limit downstream damage, and watch your conversion signals like a hawk. The platform is not going to fix this for you, and the AI scraping wave is just getting started.

Notice Me Senpai Editorial