You paid Meta for the
click. Shopify declined
to serve the page.

A merchant captured
her own storefront
refusing to load.

On 3 August 2026 a merchant opened a thread on Shopify's developer community titled "Urgent, fix your platform, merchants this affects you too". What makes it worth reading rather than summarising is that she brought request IDs, screenshots and the exchange with support, and Shopify staff replied in the thread over the following fortnight.

Her account: on 29 July she loaded her own storefront in desktop Chrome and received a blank page reading local_rate_limited. Not an error page, not a queue, a blank response. The trigger was consumer antivirus software running a VPN, in her case a McAfee Total Protection subscription of the sort sold to ordinary consumers as a security product.

Support's written position, quoted in her thread, was that this was working correctly: bot protection had assessed the session as automated traffic and applied rate limiting, that this was expected behaviour for that type of connection, and that there was no platform error.

The numbers Shopify gave her, as she reported them, were 1,688 such responses served to her storefront in five days, with 91% attributed to VPNs, hosting providers, datacentres or Meta infrastructure IP addresses. She also reported a sharp fall in her Facebook conversion rate over the same period. Those figures are her account rather than something I have independently verified, and the thread is linked below so you can read the exchange yourself.

Two weeks later, part
of it was confirmed as
a misclassification.

The thread matters more than a single merchant complaint because of how it ended. Shopify staff engaged from 10 August, and on 17 August confirmed that some traffic in Meta in-app browsers was being misclassified and that this was being investigated. One response that had been categorised as rate-limited was reclassified as genuine traffic.

That is a narrower admission than the thread was asking for, and it is a significant one. Meta in-app browsers are where a large share of paid social traffic lands. A shopper who taps an ad inside the Facebook or Instagram app does not open Chrome or Safari, they get the in-app browser, and if that browser class is being misclassified then the traffic most exposed is the traffic you are paying most for.

A second merchant confirmed it from the shopper side in the same thread on 4 August, without any VPN involved: they tapped an ad in the Facebook in-app browser, landed on a Shopify store, and got a blank page. Their assumption, reasonably, was that the merchant had broken their theme.

This does not show up
as a failure. It shows
up as absence.

The reason this went undiagnosed for so long across so many stores is structural. The block happens at the edge, before the page renders, which means before your analytics script loads. There is no pageview, no bounce, no error event. The 429 response is recorded at Shopify's edge and nowhere you can reach, so the session simply does not exist in your data.

Read down the last column. Every party draws a reasonable and wrong conclusion from accurate data. The gap between the ad platform's click count and your session count is the only place the problem is visible, and that gap is normally noisy enough that nobody investigates it.

This is why the failure gets misattributed. A conversion rate that falls without a creative change, a landing page change or a pricing change is usually diagnosed as creative fatigue, because that is the most common cause and there is no evidence pointing anywhere else. Across the brands I have looked at this in, the tell is that the drop is discontinuous rather than gradual, and fatigue is almost always gradual.

How to put a number
on something your
reporting cannot see.

Because the blocked sessions are absent rather than failed, you cannot measure the loss directly. You can bound it, which is enough to decide whether this deserves attention, and the arithmetic is simple enough to do in a spreadsheet in ten minutes.

Take your ad platform click count for the channel, subtract your analytics session count for the same channel and period, and treat the difference as the upper bound on blocked traffic. It is an upper bound rather than an estimate because that gap also contains ordinary loss: people who tap and immediately back out, tracking prevention, ad blockers, redirect drop-off. On a healthy account that combined baseline commonly runs somewhere in the teens as a percentage.

The fourth row is the one that makes this usable, and it is why the exercise is worth doing before you suspect a problem rather than after. Without your own prior baseline, a 20% gap is meaningless, because you cannot tell whether it is normal for your account. With six months of history behind it, a move from 14% to 20% is a specific, dated, defensible signal.

Multiply the unexplained excess by your channel conversion rate and average order value and you have a bounded revenue figure. It will be an overestimate, and an overestimate with a method behind it is far more useful in a support escalation or a budget conversation than a description of a decline. For the wider attribution picture this sits inside, the attribution tooling comparison covers what each system can and cannot see.

Four checks, none of
which need a developer
or a support ticket.

You can establish whether this is happening to you in about twenty minutes. None of it requires access you do not already have.

1. Load your own store through a consumer VPN. Turn on whatever VPN ships with your antivirus, or any consumer VPN, and load the storefront on desktop. You are looking for a blank page or a local_rate_limited response, not a slow one.
2. Tap your own ad inside the Facebook and Instagram apps. Not a copied link opened in Safari. The in-app browser is the thing being tested and it behaves differently.
3. Compare ad platform clicks against analytics sessions, by day. Some gap is normal. A gap that widens sharply on a specific date, with no campaign change behind it, is the signal.
4. Check whether the conversion drop is a cliff or a slope. Pull daily conversion rate for the affected channel over ninety days. Fatigue slopes. Infrastructure drops on a date.

If checks one or two reproduce the blank page, you have it, and you have it in a form you can put in a support ticket with a timestamp and a request ID, which is materially more effective than describing a conversion decline.

One thing to rule out while you are in there. A blank page can also come from a theme error, a script that fails on a slow connection, or a redirect loop, and those look similar to a shopper while having nothing to do with bot protection. The distinguishing feature is the response itself: a rate-limited session returns a specific response before any of your code runs, so if the page source is empty rather than broken, it is the platform rather than the theme. The store speed analysis covers the theme-side causes worth eliminating first.

You cannot turn this
off, so the work is
measurement and pressure.

Bot protection is a platform-level service on Shopify. There is no merchant-facing control to relax it, allow-list a browser class or exempt a campaign, which means the honest set of options is narrower than anyone would like.

1. Document and escalate with request IDs. A reproducible case with timestamps moves; a description of a conversion decline does not.
2. Track the click-to-session gap as a standing metric. If you were not measuring it before this, start, because it is the only early warning available and it costs nothing to compute.
3. Stop attributing unexplained drops to creative by default. Rule out infrastructure first when the drop is a cliff. It is a cheaper test than a creative refresh and it is more often right than the industry assumes.
4. Add the check to your peak-season pre-flight. A misclassification during Black Friday is materially worse than one in July, and the check takes twenty minutes.

It is worth being fair to the platform here. Bot protection is genuinely necessary, and card-testing and scraping attacks against storefronts are a real and expensive problem that Shopify absorbs on merchants' behalf. Classification at that scale is a hard problem with a real false-positive rate, and a false positive is invisible to the party who suffers it while a false negative is very visible to the platform. That asymmetry explains the tuning without excusing the reporting gap.

The reasonable ask is not weaker protection. It is visibility: a merchant-facing count of blocked sessions on the storefront, in the admin, alongside the traffic reports. Merchants cannot manage what they cannot see, and at the moment the only way to obtain this number is to open a support ticket and know to ask for it.

There is one more measure worth taking if paid social is a large share of your revenue, which is to reduce your dependence on a single entry path. A shopper who arrives through an in-app browser and gets a blank page is gone. A shopper who has your email, or has bought before, has another way in that does not route through the same infrastructure on the same day. That is not a fix for this bug and it is the general answer to this class of bug, which recurs in different forms every year. The owned versus rented breakdown makes the fuller case.

This is the ordinary
shape of platform risk,
not an unusual one.

Strip out the specifics and this is a familiar structure. A platform makes a defensible decision at the infrastructure layer. The cost lands on merchants. The merchant cannot see the cost, cannot control the setting, and cannot easily prove the effect. The feedback loop that would normally correct this is broken by the measurement gap rather than by anyone's bad intent.

That is the same shape as several other things that happened this year across the ecosystem, and the pattern is worth internalising because the specific incident will be fixed and the structure will not. The platform dependency analysis covers how to hold that risk deliberately rather than discovering it.

The practical version for a brand running meaningful paid spend is straightforward. Own the measurement you can own. The click-to-session gap is computable from two systems you already pay for, it is not a metric anyone will build for you, and it is the only place several categories of infrastructural failure become visible before they show up as a bad quarter.

If nothing else, run the two browser checks this week. They take twenty minutes and they either produce a reproducible bug worth escalating or rule out a cause you would otherwise have spent a quarter and a creative budget failing to find. For the broader diagnostic sequence when performance moves and the reason is not obvious, the conversion leak calculator works through where the losses usually hide.

Questions merchants ask
about rate limiting and
blocked sessions.