Simo Ahava’s tracking subdomain is on a blocklist. When a visitor lands on his blog with uBlock Origin active, the request to sgtm.simoahava.com never leaves. If the world’s leading server-side voice sees his own container cut off at the source, the old line about “this only hits badly built setups” no longer holds. Here is what changed, and why a blocked sGTM subdomain is no longer a hypothetical.
For years, server-side GTM was sold (by me too, on this blog) as the way to recover the data client-side loses. The argument rested on one assumption: a first-party subdomain like sgtm.yoursite.com slips under the radar of blockers that only know googletagmanager.com. That assumption has been wrong since May 2026. Filter maintainers changed their method. They no longer only target known third-party origins, they now list tracking subdomains one by one, by name.
This is not a bypass guide. It is a diagnosis and decision article. You will check your own domain, measure the loss on your own data instead of a vendor’s range, and walk away with a grid for deciding what to do, including the things I recommend you do not do.
What changed in the filter lists
Until now, a blocklist worked on generic patterns: it knew googletagmanager.com, google-analytics.com, and cut anything coming from them. A subdomain of yours, on your own domain, stayed invisible because it was on no list at all.
The shift is that maintainers started cataloguing these first-party subdomains by hand. AdGuard’s tracking_servers_firstparty.txt is the clearest example. On September 17, 2026, I opened it and recounted: it holds 2,527 rules blocking full subdomains, of which 41 entries start with gtm. and 43 with sgtm.. Each entry is a named domain, not a pattern. You find sgtm.simoahava.com, but also sgtm.yubico.com, sgtm.ookla.com, sgtm.kaspersky.de, gtm.temu.com, and on the hosting side gw.stape.fr and stape.brascast.com. These numbers move every week, upward: always date your own count.
The second point, the one that stings, is distribution. EasyList’s easyprivacy_specific.txt does the same work, and EasyPrivacy is enabled by default in uBlock Origin. In other words, this is not an optional list that only the paranoid tick. It is the factory setting of one of the most installed blockers in the world. An entry there reaches a real share of your traffic, with the user doing nothing special.
If you want the context of what server-side is and the promise we are re-examining, it is laid out in my server-side GTM guide. This article is its honest counterpart: where the guide says “migrate”, this one says “here is where the argument stops”.
Check whether your sGTM subdomain is blocked (2 minutes)
This is the most useful part, so it comes early. You have two ways to know whether your endpoint is listed.
The fast one: isblocked.fyi. The tool, which appeared in June 2026, aggregates 22 filter lists (uBlock Origin, Brave, AdGuard, AdBlock Plus). You type your subdomain, it is free and needs no account, and it tells you which lists you are on. It also keeps history, which we will use for the sizing step right after.
The reliable one: read the source files directly on GitHub. AdGuard’s tracking_servers_firstparty.txt and EasyList’s easyprivacy_specific.txt are public. A Ctrl+F on your domain settles the question with no middleman.
Then you have to read the result correctly, because not all entries carry the same weight.
| What you see | Real weight |
|---|---|
| Entry on EasyPrivacy (uBlock Origin default) | High: hits a large share of traffic with no user action |
| Entry on an optional list | Moderate: only reaches those who ticked it |
| ”All traffic” block | Total: the request never leaves |
| ”Third-party only” block | Total in practice for embedded tracking |
| Scripts / XHR block | Kills the container load or the hit send |
The classic trap is the “third-party only” label, which reads as reassuring. For tracking, it is not. Your measurement request is, by nature, a third-party request from the blocker’s point of view, even when it heads to your own subdomain. A “third-party only” block is therefore, for you, a total block.
Measure the loss on YOUR data, not a vendor’s range
You will read everywhere that ad blockers cut “5 to 40%” of traffic depending on the audience. That range comes from Mariusz Brucki, at TAGGRS, an sGTM host. It is not an independent study, it is the figure of a player selling the countermeasure to the problem it describes. I cite it naming the source and its interest, I do not repeat it as a fact. You have something better at hand: your own data.
The in-house method is three moves. Compare the server-side event volume (sGTM export or BigQuery table) to the client-side volume over the same window. Segment by browser and by device, because a general average means nothing. Then look at the gap: that is your real loss, on your audience, not on some article’s.
The sector benchmark matters as much as the number. Verticals with high blocker rates (tech, gaming, developers) have nothing in common with mainstream retail. If you sell tools to developers, your exposure can be several times that of a fashion e-commerce site. An average number applied to your case is useless at best, misleading at worst.
Watch the dating trap, because that is where people get it most wrong. If your curve dropped all at once, do not jump to blocking as the cause. Cross the date of the drop with the date your domain was first listed, which isblocked.fyi keeps in its history. If the two line up, the attribution is clean. If not, look elsewhere: a broken tag, a consent change, seasonality. The general approach to telling apart a bug, broken tracking and a real drop is in my article on missing data in GA4, and the server source to compare volumes is set up as in my sGTM to BigQuery export guide.
One useful nuance in passing, because it travels badly: server-side stays immune for the server write to BigQuery. A blocker that killed the client request can do nothing against a server-side insertion. But that immunity falls if the initial browser request to your subdomain is itself blocked: in that case, there is never a hit to insert server-side. That is exactly the gap the lists just opened.
What does not work, or no longer does
Everyone’s first reflex: rename the sgtm. subdomain to something less obvious. data., m., t., take your pick. Let us be clear, that buys you a few months, no more. Lists update, and renaming is precisely what maintainers anticipate: they catalogue the new names as they go. You are entering an arms race where the other side has time on its hands and makes you pay for each round in technical debt.
The bypass logic is a losing bet by design, and that is the point I want to make plainly. Every renaming round costs you a reconfiguration, a risk of breakage, and a little more opacity toward a user who, by installing uBlock Origin, made a choice. This is not an abstract moral stance, it is also a matter of effectiveness: you are spending energy on a vector you do not control.
What actually moves the needle, and at what cost
There are real options, provided you look at their cost head on and not only their benefit.
| Option | Real benefit | Cost (technical, ethical, legal) |
|---|---|---|
| Randomized service paths (Google tag gateway, since May 2026) | Hides container IDs, complicates the detection pattern | Still a bypass, temporary gain, dependence on Google |
| Subfolder + CDN proxy instead of subdomain | Same origin as the site, harder to isolate | Heavy configuration, risk of flagging the whole site |
| Do not bypass, measure cleanly | Consistency, credibility, compliance | Accept a share of unmeasurable traffic |
The trade-off between the tag gateway and sGTM I covered in detail in my comparison Google tag gateway vs server-side GTM, and I have to add this article’s nuance to it: the tag gateway hides, it does not make you invisible.
On the subfolder choice, you have to quote Simo Ahava as is, because his position is counterintuitive. He advises against same-origin and defends the subdomain, for a separation-of-concerns reason: an over-zealous blocker could flag the whole site if it confuses the site with the measurement endpoint. In other words, the “more discreet” subfolder solution exposes you to a graver risk, that of your entire domain being taken for an ad network. It is not settled, but it deserves to be known before you rearchitect.
The part nobody writes: what if we stopped running?
Let us lay out two facts calmly.
The uplift figures shown to justify the tag gateway (11% with Cloudflare, 14% with Fastly) are Google figures, not independent studies. Just as the “5 to 40%” range came from a host, these uplifts come from the solution’s provider. That does not make them false, it makes them interested. Treat them as such.
Next, first-party routing changes nothing about the legal basis. The March 2025 German ruling, which says GTM cannot run before explicit consent, applies whether the script comes from Google or from your own server. Changing the technical origin does not make a GDPR obligation disappear. The Consent Mode framework and what you actually have to respect is in my article Consent Mode v2 in GA4.
And here is the line I stand by. A user who installed uBlock Origin made a choice. The consultant’s job is to cleanly measure what is measurable, not to force the door. Server-side stays justified, for real reasons: more durable first-party cookies, data control, CAPI, cost control. But it is no longer justified by “it bypasses blockers”, and that is the reason we have to stop selling.
Actionable recap
This week: check your subdomain on isblocked.fyi and in both GitHub files, then put the domain under monitoring so you are alerted if it gets added. This month, before the year-end peak: measure your real loss by comparing server and client volumes, segmented by browser, and document your exposure. The tracking audit before the peak I walk through in my Black Friday guide, and Safari 27’s IP-level blocking, the other front of the same fight, is covered here.
In a client report, the right wording is not “we recovered everything”. It is: an identified share of traffic is structurally unmeasurable browser-side, here is its order of magnitude on your audience, here is what we still capture server-side, and here is why chasing the rest would cost more than it returns. That sentence is worth more than a subdomain renamed every three months.