Persistent malicious bot traffic via Shopify domain (.myshopify.com) – ongoing for 3 months with no resolution

[Nancy88]

I’m posting here to ask whether other merchants are experiencing the same issue.

For the past three months, our store has been receiving a large volume of malicious bot / crawler traffic accessing the site directly via the Shopify-managed domain (.myshopify.com). These requests completely bypass the protection we have in place on our custom domain, where we are already using Cloudflare WAF and bot protection.

We have reported this issue multiple times through Shopify Support, but so far there has been no effective solution or improvement. The bot traffic continues to:

• Severely distort analytics data

• Create performance risks

• Increase operational uncertainty, especially with peak season approaching

What is most concerning is that merchants have no control at the Shopify domain level, and third-party security solutions cannot be applied to .myshopify.com. This leaves a significant security gap that merchants cannot mitigate on their own.

I’d like to ask:

• Are other merchants seeing similar large-scale bot traffic through the Shopify domain?

• Has anyone found any effective mitigation or workaround?

• Does this incident suggest that platforms which do not expose a platform-managed third-party domain might offer better long-term security and control?

This situation raises serious questions about risk management, merchant protection, and platform responsibility. I hope Shopify can provide clearer guidance or a roadmap for addressing bot traffic at the Shopify-managed domain level.

Looking forward to hearing from other merchants and the Shopify team.

[M4rt1n]

Hi! I haven’t experienced this with my stores, but one idea could be to stop using the .myshopify.com domain and only use your custom domain (.com or others) for all traffic.

Most bots target the Shopify-managed domain, so removing it from public access might reduce a lot of this unwanted traffic. I can’t guarantee it will block everything, but it could help mitigate the issue.

[coreylando]

(post deleted by author)

[steph_31]

I am having the exact same issue. a bot called “John Doe” and another one called “Laka Lama” is making hundreds of fake profiles every day. I spoke to Shopify and they told me to “download a bot blocker app” which is ridiculous. I downloaded ARMEX and they told me the following:

We’ve checked the abandoned checkout records in your store and found that the checkout bots are attacking your xxxx.myshopify.com domain, not your custom domain (such as xxx.com). This type of attack cannot be blocked even when using a WAF (any WAF solution, not just ours).
Instead of going through product pages, the bot goes straight to the checkout using a Shopify API request or a Shopify permalink (for example: https://xxx.myshopify.com/cart/46197058797731:1)

If a bot is attacking your custom domain, our Armex Firewall can indeed block it. However, the myshopify.com domain is fully managed and controlled by Shopify. Shopify does not allow merchants or third-party apps to modify its DNS, so even if a blocking method exists in theory, there is no way to connect that domain to a firewall or apply protection. Because of this limitation, there is no way to block bot activity on the myshopify.com subdomain.”

SHOPIFY DO SOMETHING. THIS IS HORRIBLE YOU ARE NOT BLOCKING BOTS.

[dingle-larry]

Same here, try the shopify fraud controll app, so far it’s the only thing working for me. You have to setup a custom rule to block the emails/address john doe and other bots are using. Ive been collecting them as the cc attemps happen. Once setup all abandoned carts have no cc attempts with them. Also set up a flow to delete the bot accounts (attached some images)

[SealSubs-Roan]

Hi @Nancy88

Got similar results. A practical workaround is to force canonical redirects and block checkout access unless the host is your custom domain. Use server-side app proxy rules or middleware applications to analyze host headers and rate limit suspicious queries. Also, please exclude myshopify.com on your analytics so reporting accuracy is protected during your busy season!

[Nancy88]

@M4rt1n

Hi! I haven’t experienced this with my stores, but one idea could be to stop using the .myshopify.com domain and only use your custom domain (.com or others) for all traffic.

Most bots target the Shopify-managed domain, so removing it from public access might reduce a lot of this unwanted traffic. I can’t guarantee it will block everything, but it could help mitigate the issue.

Thanks for the suggestion. In our case, this doesn’t fully address the issue.

We are already using only our custom domain publicly, and the .myshopify.com domain is not promoted or used for marketing at all. However, on Shopify, the .myshopify.com domain cannot be completely disabled, as it is required for platform functionality and always remains accessible at the infrastructure level.

What we’re seeing is that bots are directly targeting the Shopify-managed domain, bypassing our custom domain and therefore bypassing Cloudflare, even though our primary domain is fully protected.

So unfortunately, removing public references to the Shopify domain doesn’t stop bots that already know or systematically scan Shopify subdomains. This appears to be a platform-level limitation rather than a configuration issue on our side.

[Nancy88]

I’ve spent the last week dealing with a huge influx of the same traffic, and I’m seeing exactly what you described: requests coming in via Shopify-managed domains (.myshopify.com) / Shopify-domain referral paths that bypass everything a merchant can deploy on their own domain (Cloudflare WAF, bot rules, cookie/path checks, Workers—none of it sees the request if it never touches our hostname). That is a security gap by design, and it’s absurd that merchants are expected to “just install apps” to compensate for it.

@coreylando

What’s been most frustrating is Support’s posture: the “solutions” I’ve been offered are mostly Plus upgrades or storefront apps. Apps are typically reactive (cleanup/blacklist after damage is done) and are objectively less effective than a properly built edge strategy—and they still can’t protect the Shopify-managed hostname anyway.

The only truly “hard” mitigation I’ve found is enabling customer login required for checkout. Yes, it’s global (it impacts everyone), but the key detail is: customer account authentication involves a handshake back to the primary domain auth flow. That means if the traffic is entering through the Shopify domain path, it’s far more likely to hit an auth pathway that can’t be completed cleanly unless it’s behaving like real storefront traffic. In practice, this is the only lever I’ve found that actually disrupts the Shopify-domain bypass rather than just reacting after the fact.

Everything else is basically damage control:

• filtering/segmenting analytics by hostname so the Shopify-domain noise doesn’t corrupt reporting
• tagging/flagging customer/cart/checkout/order activity that originates from the Shopify domain path so it can be automatically treated as high-risk (manual review / cancel / exclude)

None of that is a real fix. Merchants should not have to choose between breaking conversions with forced login or accepting a parallel unprotected entry point we can’t secure.

And what makes this extra gross is how close I am to actually solving this properly—without relying on reactive apps—except Shopify paywalls the exact platform capability that would let me finish the job. I’ve already built an edge strategy that blocks sophisticated bots on the primary domain by validating real storefront behavior (navigation continuity, timing, cookie continuity, session integrity). But by definition, it can’t enforce policy on Shopify-managed hostnames or entry points I don’t control.

So the “real” fix is not “install more apps,” and it’s not “clean up after the fact.” The real fix is a platform-level control that lets merchants bind cart/checkout eligibility to a validation signal that Shopify enforces regardless of how the traffic enters. Concretely: I need the Function API for one specific purpose—to link a cart to a checkout eligibility token.

In other words:

• A cart should only receive a “validated” marker (attribute/metafield/token—whatever the supported mechanism is) after the session passes storefront validation.
• Checkout processing should require that marker, so a checkout created from an unvalidated cart simply cannot proceed (or is automatically forced into a safer flow).

This is essentially using Shopify’s own primitives in reverse of how my current system works. Today, my system can only do: storefront navigation → cookies/pathway checks → allow/deny on my domain. What I need is: validation outcome → inject a cart-level eligibility marker → Shopify enforces it during checkout regardless of entry hostname. That’s the only practical way to close the .myshopify.com bypass without expecting Shopify to hand merchants full network control over their managed domains (which I understand they won’t).

But the Function API—the missing piece needed to enforce this properly—is paywalled behind Plus plans (roughly $2,300/month). So the message becomes: “Yes, the tooling exists. Yes, it would address your problem. But you can’t use it unless you pay thousands per month.”

That’s infuriating from a security standpoint and backwards from a merchant-support standpoint. Why should I spend days engineering a real solution only to be forced into an expensive tier to deploy it? If the end result is “pay us anyway,” it starts to feel like I should’ve skipped the engineering effort and just lit money on fire—which is obviously not acceptable. This isn’t just frustrating; it’s making me seriously consider switching platforms, because a core security gap shouldn’t be monetized as an upsell while merchants are left to absorb the fraud, analytics pollution, and operational overhead.

Shopify needs to provide better support and a real platform-level control here: either let merchants restrict storefront access on .myshopify.com, or provide equivalent, merchant-configurable bot/WAF controls at the Shopify-managed domain level, or expose the minimal cart/checkout gating capability (Function/API equivalent) needed to enforce “validated cart → allowed checkout.” Right now the message is effectively “you’re on your own,” and that’s not acceptable. To answer your last question - yes, shopify is shooting themselves in the foot here. I cannot think of a better reason to motivate your merchants into looking for better alternatives.

I completely understand your anger. Regarding Shopify’s inaction, I have personally been suffering from this issue for over three months, and it still hasn’t been resolved.

What’s even more absurd is that Shopify support actually congratulated me, saying that my website being crawled means my content is “very interesting” and attracts attention.
I want to ask: when more than 95% of the traffic to a website comes from bots, is that really something worth celebrating?

At the beginning, I didn’t realize the bots were bypassing security through the Shopify domain. I even purchased an expensive Cloudflare Business plan, only to later discover that it is impossible to set firewall rules for Shopify’s own domain.

Cloudflare’s technical team helped me test the issue and confirmed that the malicious crawlers were indeed coming through the Shopify domain, not my custom domain.

I reported this to Shopify again, but once more I only received the same polished, official responses with no real solution.

Eventually, I made it clear to them that if this issue is not properly addressed or optimized, merchants will leave Shopify one by one.

At this point, I see no viable solution. The only option left is to move away from Shopify entirely and choose a platform without third-party domains to run my business.

I will gradually start migrating my stores, and any new businesses will no longer consider Shopify.
I operate several stores and contribute a significant amount of revenue to Shopify every year — yet they clearly do not care.

[Nancy88]

@steph_31

I am having the exact same issue. a bot called “John Doe” and another one called “Laka Lama” is making hundreds of fake profiles every day. I spoke to Shopify and they told me to “download a bot blocker app” which is ridiculous. I downloaded ARMEX and they told me the following:

We’ve checked the abandoned checkout records in your store and found that the checkout bots are attacking your xxxx.myshopify.com domain, not your custom domain (such as xxx.com). This type of attack cannot be blocked even when using a WAF (any WAF solution, not just ours).
Instead of going through product pages, the bot goes straight to the checkout using a Shopify API request or a Shopify permalink (for example: https://xxx.myshopify.com/cart/46197058797731:1)

If a bot is attacking your custom domain, our Armex Firewall can indeed block it. However, the myshopify.com domain is fully managed and controlled by Shopify. Shopify does not allow merchants or third-party apps to modify its DNS, so even if a blocking method exists in theory, there is no way to connect that domain to a firewall or apply protection. Because of this limitation, there is no way to block bot activity on the myshopify.com subdomain.”

SHOPIFY DO SOMETHING. THIS IS HORRIBLE YOU ARE NOT BLOCKING BOTS.

Similarly, a bot named “John Doe” has appeared across several of my different stores.
At first, there were manual, human-like test actions, and shortly after that, large-scale crawling began.

The bot uses different IP addresses and accesses the sites at intervals throughout the day to mimic human behavior. At this point, the number of bot requests has reached around 20,000 per day.

Shopify seems completely unconcerned about this situation.

I also can’t help but wonder whether these bots could somehow be originating from Shopify itself, potentially pushing merchants—especially those with decent order volume—toward purchasing Shopify’s expensive firewall or security services.

To be clear, this is only a suspicion and a worst-case assumption, but the lack of transparency and effective solutions from Shopify naturally leads merchants to question what is really happening.

[Nancy88]

@Nancy88

Same bots from John Doe!! For such a powerful platform like Shopify, being unable to stop a single “John Doe” would be the biggest joke of 2026.

[steph_31]

I might have found a temporary solution. Under settings > domains I found my xxx.myshopify.com domain - I clicked it and changed the domain type to “alias domain”. The Alias domain has a message underneath that say,

“Displays contents of Online Store but doesn’t redirect or update the browser address bar. Misuse can harm SEO.”

I really do not care about this since I mostly care about John Doe/ Laka Lama accessing my store, screwing up analytics, screwing up my email Klaviyo list and trying to submit small dollar amount fraudulent orders.

Ever since I made the xxx.myshopify.com domain an “alias domain” I have not seen any of the bots.

[tim_tairli]

@steph_31

my xxx.myshopify.com domain - I clicked it and changed the domain type to “alias domain”.

I wonder whether it’s a coincidence and just a pause in attacks, but if it does help – how?

Usually people hitting myshopify domain are redirected to your main domain.
in “alias” mode, visitors may continue browsing the myshopify domain.
How this can prevent bot attacks by itself?

[Nancy88]

I believe your solution is currently the best, and I have already implemented it. I have sorted out human sessions in Shopify. I have reached out to Shopify support multiple times, and not a single person suggested such an effective method. As usual, in the past when I encountered issues, most of the time their support could not provide a solution, and I had to figure it out myself. Shopify really needs to properly train their support team. I sincerely appreciate your solution, and I will carefully monitor the changes over the next few days. Thank you.

[tim_tairli]

@steph_31 @Nancy88

I guess you would also want to add code like this right below the <head> in your layouts/themes.liquid

{% if request.host contains "myshopify" %}
   <meta name="robots" content="noindex,nofollow">
{% endif %}

to prevent indexing duplicated content under wrong domain.

[Nancy88]

Thank you for your important reminder. Regarding the duplicate content issue, I checked and each page has a <link rel="canonical" href="…">. I was informed that this prevents duplication, and that the page’s ranking and indexing should be attributed to the primary domain URL. Do you think this is correct?

[Nancy88]

I also encountered this malicious test payment issue, where each failed transaction cost me $0.30, and Shopify admin didn’t show any orders or abandoned checkout records. After noticing the problem, I removed the third-party payment gateway and now only use PayPal and PayPal Credit Card. To prevent losses, I recommend you consider doing the same.

[tim_tairli]

I frankly can’t be 100% sure.
Yes, canonical seem to use your main domain now (probably was not always like this, i believe it was using the current hostname before).

And hopefully, Google et al would honour this.

But, probably it’s better to tell them “do not index this URL at all” if it’s myshopify URL? I’d prefer this.

Also, not sure whether this crawl budget will be attributed to your main domain or to myshopify domain…

[akhterkhan]

@Nancy88

I’m posting here to ask whether other merchants are experiencing the same issue.

For the past three months, our store has been receiving a large volume of malicious bot / crawler traffic accessing the site directly via the Shopify-managed domain (.myshopify.com). These requests completely bypass the protection we have in place on our custom domain, where we are already using Cloudflare WAF and bot protection.

We have reported this issue multiple times through Shopify Support, but so far there has been no effective solution or improvement. The bot traffic continues to:

• Severely distort analytics data
• Create performance risks
• Increase operational uncertainty, especially with peak season approaching

What is most concerning is that merchants have no control at the Shopify domain level, and third-party security solutions cannot be applied to .myshopify.com. This leaves a significant security gap that merchants cannot mitigate on their own.

I’d like to ask:

• Are other merchants seeing similar large-scale bot traffic through the Shopify domain?
• Has anyone found any effective mitigation or workaround?
• Does this incident suggest that platforms which do not expose a platform-managed third-party domain might offer better long-term security and control?

This situation raises serious questions about risk management, merchant protection, and platform responsibility. I hope Shopify can provide clearer guidance or a roadmap for addressing bot traffic at the Shopify-managed domain level.

Looking forward to hearing from other merchants and the Shopify team.

Yes, I faced the same issue on the .myshopify.com domain, and I agree with you that bot traffic definitely disturbs the analytics. The protection option is available on the custom domain, but on the Shopify domain, it is totally zero.

For now, I am using a temporary workaround: I monitor my website traffic using traffic monitoring tools and filter the bot sessions, so I get clean and accurate results. But for the long term, the Shopify platform needs to solve this issue.

Yes, this issue becomes high risk during the peak session. If someone knows a trusted workaround, then please share it here.

[steph_31]

I agree that it seems strange. It would be the craziest coincidence ever. But it worked for me. I am not tech savvy at all so I would not even be able to remotely assume anything.

[Bundler-Manuel]

Hey there @M4rt1n so sorry for the inconveniences you are facing currently, like the first person mentioned, using your own custom domain and excluding the Shopify domain is one way to go about it for now. Secondly, using the fraud control and bot blocker apps as mentioned by some others in the replies could also be helpful as well.