opus.life · read-only check · last updated 9:23pm Pacific, Wednesday 14 October 2026

Is Shopify's bot blocking turning away real shoppers?

You asked me tonight to look into the "Cloudflare 429" lead from the order-drop check: is it blocking real shoppers, since when, how many orders did it cost, and what setting would fix it. I changed no settings and sent nothing to the store. Here's what I found.

Short answer

No. I found no sign it has stopped a single real shopper or cost us an order.

Every 429 on record came from our own automated testing on this Mac. And there's no setting to change: the Cloudflare in front of opus.life belongs to Shopify, not to us. Two small things are worth doing anyway (below).

What's the "429" this is about?

On 7 October a helper was testing our old buy links, one after another. After about a dozen quick checkouts, opus.life started answering with error 429, "Too many requests," and for a few minutes it answered every page that way. The worry was that real shoppers might hit the same wall, which could help explain the drop in orders at the start of October.

HTTP 429 · server: cloudflare · cf-mitigated: challenge · "Verifying your connection..."

That's the gist of what the store sent back to our test. The "Verifying your connection" page is Cloudflare checking whether a visitor is a person or a bot.

Is it blocking real shoppers?

Not that I can find. Our logs show a 429 or a bot check at 11 different times between 2 and 12 October, about 42 hours in all, counted generously. Every one of them was during our own testing from this Mac.

I lined each one up against what real visitors were doing in the same hours. Where real visitors came in, their pages loaded and they could shop. Two of them even paid during the longest stretch.

When (Pacific)	What we were doing	Real visitors in those hours
Fri 2 Oct 3:25 to 4:00pm	A cart test on the old www.broq.life: about 80 page loads in 20 minutes	None came
Fri 2 Oct 8:10pm to Sat 3 Oct 9:28am	Overnight cart tests on a preview; refused on and off	14 visits, 5 carts, 4 checkouts, 2 paid orders (7:37am and 8:21am)
Sat 3 Oct 11:40pm to 3:50am	Overnight buy checks	2 visits
Sun 4 Oct 8:17 to 9:31pm	Landing page buy tests, one at a time	11 visits (the carts in these hours were most likely our tests)
Mon 5 Oct 12:21 to 9:14am	About 12 cart test runs on a preview, before the launch	7 visits; one reached checkout at 8am
Mon 5 Oct 2:33 to 8:20pm	Landing page tests that empty the cart first	11 visits; one reached checkout at 5pm
Mon 5 Oct 10:54pm to 4:49am	Page snapshots for the compare pages	13 visits
Tue 6 Oct 12:27 to 12:35pm	A home page speed check	4 visits
Wed 7 Oct 4:47 to 5:26pm	The old buy links check (the one that found this)	1 visit
Fri 9 Oct 4:20 to 4:58am	Several test carts at the same time	3 visits; 4 ad clicks, and 3 of them loaded the page
Mon 12 Oct 5:47 to 6:41pm	An iPhone checkout test on a preview	28 visits (17 of them most likely Meta checking our new ads); 11 ad clicks, and 8 of them loaded the page

That's the pattern of a limit on one internet connection at a time. It shut out this Mac, and nothing shows it shutting out anyone else. The refusals also came and went within each stretch, a few minutes at a time.

Two more checks point the same way:

88%of Facebook and Instagram ad clicks loaded our page, 667 of 761 from 8 to 14 October. A 10% to 20% gap is normal (people tap back before the page appears). The two ad days with one of our 429s, 9 and 12 October, came in at 94% and 84%, the same range as the days without.

55%of real shoppers who reached checkout since 8 October paid, against 44% to 51% in August and September.

Since when?

The first 429 in our records is Friday 2 October at 3:25pm, during our own cart test on www.broq.life, three days before the move to opus.life. Our tests set it off again on and off through 6 October, then once each on 7, 9 and 12 October. There's no start date for real shoppers, because nothing shows any of them blocked.

For context, Shopify's developer forum shows merchants reporting blocked shoppers several times this year (January to April, May to June, and August), with Shopify adjusting its bot protection each time. It's always on, for every Shopify store.

How many orders did it cost?

Best estimate: none. Real shoppers placed 2 orders during those 11 stretches, and the stretches mostly fell in quiet hours.

Even if every shopper had been shut out for every minute of all of them, which is far worse than what happened, we'd expect to have lost about 2 orders in total, or about 7 at our best recent order rate.

The early October drop lines up with other things: the email blasts stopped on 25 September and no ads ran until 8 October.

Since the ads started, web orders are back to 5.7 a day, above the 5.1 a day of late September. Today, 14 October, had 10, the best day since 24 September.

One thing I can't fully explain

Since 2 October, visitors who come from Google add to cart less often: about 11% of visits, down from 18% to 20% in late September.

Fewer returning customers fits this better than blocking. The emails stopped, the domain moved on 5 October, and the Google visitors who do add to cart still pay at the same rate as before.

Even if all of it were blocking, it would come to about 3 to 14 orders over 13 days. I'd look at it again in a week.

What setting would fix it?

There isn't one. opus.life points straight at Shopify, and the Cloudflare in front of it is Shopify's own. Shopify's help page says it's "always active on your store and requires no action from you." Merchants get no switch, no allow list and no way to raise the limit.

The Shopify settings that sound related don't help shoppers:

hCaptcha (Online Store preferences) covers contact forms and logins only, not the cart or checkout.
Checkout bot protection is for Shopify Plus stores only, and we're not on Plus. It also adds checks rather than removing them.
Crawler access (Online Store preferences) can sign our own test tools so they stop tripping the limit. It does nothing for shoppers or checkout.

Is there any risk left?

A small one. On 17 August, Shopify staff admitted that some traffic from the Facebook and Instagram in-app browsers was wrongly being treated as bots. On 26 August they said they'd improved it, but they haven't said it's fully fixed.

People on VPNs get checked more often too. Our numbers show no sign of this on opus.life, but it's where a real shopper could get caught.

Here's what that shopper would see on our pages today. After they tap Add to cart, the page quietly tries twice more, then says "We couldn't add that. Please try again."

Trying again won't get them past Cloudflare's check, because a browser can only pass it on a full page load, not in the background.

There's also a gap in what I can see. A visit that gets blocked never shows up in Shopify's numbers. If about a tenth of ad clicks were quietly blocked every day, that would hide inside the normal gap between clicks and loaded pages, and cost about 2 orders a week. Nothing points to it, but only Shopify can rule it out, which is one more reason to ask them (recommendation 3).

What I recommend

Change no settings. None of them would help, and the 429s don't explain the order drop.
A small theme fix, with your and Nick's OK. When Shopify refuses an Add to cart, take the shopper to the cart on a full page load, where most browsers pass the check in a few seconds, instead of retrying in the background and showing an error. I'd build it on a preview, test it by faking a refused add (no real cart touched), and show you before it goes live.
Ask Shopify Support for our numbers. Only Shopify can count how many visits to opus.life it turned away since 1 September, and why. In August they pulled these counts for another merchant. The message is below, ready for you or Nick to send.
Keep our own testing slow, one cart at a time. That's been the rule since 9 October. Our tests are what trip the limit, and while it's tripped it can lock anyone on the same internet connection as this Mac, you included, out of opus.life for a few minutes.
Later, not urgent: the old go.opus.life pages still send buyers through 4 redirects on the way to checkout. Pointing them straight at opus.life would cut that to 1 or 2. They work today, and nothing shows them costing orders. (The helper who researched this would repoint them now; I'd wait.)

Decisions for you

1. The Add to cart fix (recommendation 2)?

Build it on a preview and show me recommended
Leave it as it is

2. Ask Shopify Support for the blocked-visit counts (recommendation 3)?

Yes, you or Nick send the message below recommended
Skip it

3. The old go.opus.life buy links (recommendation 5)?

Leave them for now and revisit when those pages are retired recommended
Repoint them straight at opus.life this week

The message to Shopify Support

For the Shopify Help Center chat or an email to Support. It names the store, the dates and what we want back.

Hi there,

Could you pull the number of requests to opus.life and www.broq.life (store superhuman-health-broq.myshopify.com) that got a 429 or a "Your connection needs to be verified" page since September 1, by day and by reason (VPN, bot signals, Facebook or Instagram in-app browser and so on)?

We run Facebook and Instagram ads to opus.life, and we want to be sure real shoppers aren't being turned away. Our own testing set it off a number of times between October 2 and October 12, so feel free to leave those out or show them separately.

Thanks so much for your help!

-Mike

How I checked, and where the detail is

Everything was read only. Nothing was sent to opus.life, www.broq.life or go.opus.life, and no setting was touched anywhere.

Who runs the Cloudflare: opus.life's DNS is at GoDaddy and points at Shopify's address. The store's replies carry Shopify's and Cloudflare's markers. Shopify's help page "Protecting your store from bots" says every request to a Shopify store passes through Cloudflare.
Real shoppers: Shopify Analytics, day by day from 15 August and hour by hour on the 429 days, counting only visits that arrived with a referrer (almost all our own tests arrive with none). Orders came from the Shopify Admin, and ad clicks and pages loaded from Meta Ads.
Our 429s: the order-drop timeline and our own build logs from 2 to 12 October.
What a shopper would see: the live theme's own code (the cart script retries a refused add twice, then shows the error).
Shopify's side: Shopify's help pages, Cloudflare's documentation and Shopify's developer forum, where staff answered merchants with blocked shoppers in February, June and August 2026.

The full working notes, with every number, quote and source link, are saved in the website session's order-drop folder: one for the numbers, one for how the blocking works and the theme code.