Your portfolio probably looks something like this: a flagship sportsbook on the .com, a licensed regional brand on the .ca, a casino white-label you launched last spring, and a rebrand penciled in for Q4. One retention team owns all of it. And if you run web push across multiple domains the default way, you also own four disconnected subscriber lists, each growing on its own, none of them talking to the others.
That fragmentation is not a configuration mistake you made. It is how the web’s push architecture works. The browser pins every subscription to a single domain, and no dashboard setting changes that.
There is, however, a supported way around it. This article covers the mechanics: why a web push subscription binds to one origin, what actually survives a domain change (more than you think), what breaks (less than you fear, but the part that compounds), and the stable-origin architecture that grows one subscriber list across every brand you run today and every brand you launch next.
Why a web push subscription binds to one domain
When a visitor clicks Allow, the browser does not subscribe them to your brand. It subscribes them to an origin: the exact protocol and hostname in the address bar. The Push API creates the subscription against a service worker registered on that origin, using your platform’s application server key. The record the browser returns has three parts: an endpoint URL on the browser vendor’s push service, plus two encryption values (p256dh and auth) that lock payloads to that one browser.
Notification permission follows the same rule. It is granted per origin, not per company. sportsbook.com and sportsbook.ca are strangers at the protocol level, even when they share a logo, a wallet, and a player database. Each one prompts separately, subscribes separately, and builds a separate list.
Origin, push notification service worker, and VAPID keys: the three-part lock
Three things pin a web push subscription in place. The origin that created it. The push notification service worker that receives messages for it. And the VAPID keys your sending platform holds. The subscription is created under the public key, and the push service accepts a send only when it is authenticated with the matching private key. Your platform proves it holds the key pair on every send; the subscription record itself carries only the public half.
The browser also enforces one subscription per origin. Calling subscribe again with a different application server key fails until the existing subscription is removed. That constraint matters later, when we get to consolidation: on the same origin, a new service worker can take over an existing subscriber silently. Across origins, it never can.
What a domain migration breaks in web push (and what it doesn’t)
Here is the part most teams get wrong about a domain migration: they assume the old list dies. It does not. Subscribers who opted in on the old domain keep receiving your notifications.
Delivery never touches your website. When you send, your platform makes a request authenticated with your VAPID keys to the push service holding each subscription (Google’s for Chrome, Mozilla’s for Firefox, Apple’s for Safari), and that service delivers the encrypted payload to the service worker already installed in the subscriber’s browser. The old domain can be redirected, parked, or gone entirely. The notification still lands.
The click destination is yours too. Click URLs are set per campaign, so a subscriber who opted in on a domain you retired two years ago can click today’s notification and land on today’s live site.
| After a domain change | Still works? |
|---|---|
| Delivery to existing subscribers | Yes — pushes route through the browser vendors’ push services, not through your site |
| Click-through destination | Yes — the click URL is set per campaign; point it at the current domain |
| Old-origin subscribers automatically joining the new domain’s list | No — permission is per origin, so joining the new list is a new opt-in |
| New signups on the old origin | No — and this is the loss that compounds |
So a domain migration does not cost you the subscribers you have. It costs you the machine that was producing them. The day traffic moves, signup capture on the new domain restarts at zero while the old list slowly decays. Run that across a portfolio of brands and every property is paying that reset tax independently.
The real cost: every new domain starts its list from zero
Fragmented capture would be an annoyance in a low-churn channel. Betting is not a low-churn channel. Across betting and gaming sites on PushEngage, in one 90-day window, unsubscribes erased roughly 91% of new subscriber acquisition across the segment. A list in this vertical is a bathtub with the drain open; the only thing that keeps the level up is the tap running continuously.
Fragmentation turns off the tap, one property at a time. Each brand’s list only grows while that specific domain earns opt-ins. A migration resets its tap to zero. A new white-label starts at zero. Meanwhile the browsers keep draining: Chrome’s automatic permission revocation, announced in October 2025, quietly removes notification permission from sites with very low engagement and high notification volume. A list that is not capturing is not flat. It is shrinking.
The CAC framing makes the stakes plain. You paid to acquire every one of those visitors, and the opt-in is the only durable retargeting asset the visit leaves behind. The case for push in this vertical rests on that asset compounding. Fragmentation writes part of it off every time a domain changes.
The stable-origin architecture: one subscription domain for every brand
The fix is to stop creating subscriptions on brand domains altogether. Anchor every subscription to a single stable HTTPS origin your group controls, one that will outlive any individual brand domain, and let every property feed it.
PushEngage ships this as the custom subdomain flow, built for exactly this case: multiple domains that need unified subscriber administration under one controlled domain. The setup:
- Pick a stable, brand-neutral origin you own, such as
notify.yourbrandgroup.com. Choose a name you are happy for subscribers to see, because browsers display the subscribing origin on notifications. - Upload the PushEngage service worker file to that domain’s root and enable the feature under Site Settings » Advanced Settings. The stable origin gets its own install snippet with
isSubscriptionOnSubDomain: true. - Add the PushEngage snippet to each brand domain. When a visitor opts in on any of them, the flow routes through the stable origin, where the actual subscription is created.
Two requirements are non-negotiable in this mode. First, opt-in is double-step only: the browser’s permission prompt has to fire on the origin that owns the subscription, so a single-step native prompt on the brand domain is not possible. Second, Quick Install stays enabled.
Be honest about the trade-off. Double-step adds a click before the permission prompt, and it converts lower at the moment of capture. It is worth reading alongside the broader levers for raising your opt-in rate. But a single-step subscriber captured on a domain you later migrate away from is a depreciating asset. A double-step subscriber on the stable origin survives every rebrand, every regional launch, every migration you will ever run. Over any horizon that includes a domain change, the consolidated list wins on total reach.
Push notifications for multiple websites, one subscriber list
Once the stable origin is in place, push notifications for multiple websites stop meaning multiple lists. Every brand domain feeds the same subscriber base. Launching a new regional domain or white-label next quarter means adding the snippet; its opt-ins land in the consolidated list from day one. Retiring a domain means nothing happens to the list at all: capture continues on the surviving properties, delivery continues through the push services, and click URLs point wherever you are live.
Consolidating the subscriber lists you already fragmented
Most operators arrive at this architecture with history: live lists scattered across old domains, some dormant, some on another vendor. Consolidation runs on three tracks in parallel.
| Track | What you do | What it gets you |
|---|---|---|
| 1. Keep old lists working | Keep sending to every old-origin list; point click URLs at the current live domain | Paid-for reach keeps producing sessions instead of being written off |
| 2. Capture new on the stable origin | Switch every live property’s opt-in to the stable-origin flow | Fragmentation stops the day it ships; all new acquisition lands in one list |
| 3. Let old lists funnel themselves in | Every send to an old list drives a revisit to a current domain, where the stable-origin prompt waits | Active subscribers consolidate themselves, no forced re-permission |
Track 3 is the quiet workhorse. Browser permission is per origin, so old-origin subscribers technically need a new opt-in to join the consolidated list, but you never have to demand it. Given how quickly betting audiences cycle, the consolidated list becomes the majority of your active reach within months, simply because active players keep visiting.
If some fragments live with another push vendor on a domain you own, they can come along too. PushEngage’s standard path is a silent re-subscribe: on a subscriber’s next visit, the SDK’s push notification service worker takes over and re-subscribes them with no second permission prompt, because origin-level permission persists. For OneSignal, PushEngage can fetch the list directly through OneSignal’s API. Migration is white-glove and free on paid plans.
Per-brand campaigns inside one consolidated list
One list does not mean one message. It means one asset with better targeting than four fragments could ever manage.
Capture the originating brand as a subscriber attribute at opt-in, and per-brand cohorts exist from day one. From there, segmentation does what separate lists never could: brand crossed with geography, deposit behavior, session recency, or league preference. That is the model post #1 lays out in the push notifications for betting sites playbook. The flagship’s odds-boost campaign goes to the flagship’s bettors; the casino white-label’s cashback reminder goes to its players; a portfolio-wide fixture alert goes to everyone who follows the league, whatever brand they signed up under.
The upside is not cosmetic. Across betting sites on PushEngage, the median betting-site sender sees ~2.1% CTR on viewed notifications; the top decile does 6.9% — roughly triple. That spread is a targeting gap, not a channel gap, and you cannot build behavioral cohorts across four disconnected fragments. Consolidation is what makes segmentation as a deliverability practice workable at portfolio scale. That matters more now that Chrome scores every sending origin daily and throttles disruptive senders (live since January 2026). One stable origin concentrates your sender reputation; segmented, relevant sends are what keep it healthy.
One list also makes responsible gambling operationally simpler, and that is a feature, not a footnote. A self-excluded player suppressed on a portfolio-wide segment is suppressed everywhere at once, not brand by brand where a fragment can slip through. Quiet hours and frequency caps apply at the subscriber level across every brand’s campaigns. And the campaigns themselves should hold the line: no win-back framed around chasing losses, no countdown pressure on deposit prompts.
Run web push across multiple domains without splitting your list
The whole setup is smaller than it sounds: a DNS record for the stable origin, the service worker file at its root, the toggle in Advanced Settings, the isSubscriptionOnSubDomain snippet, and the standard snippet on each brand domain with double-step opt-in configured and Quick Install left on. Teams typically ship it same-day, with no re-platforming. That is the entire lift to run push notifications for multiple websites from one origin.
What you get back is the thing fragmentation quietly taxes: a subscriber list that compounds. Every brand feeds it, every domain change bounces off it, and every campaign can target the whole portfolio or one brand at a time. If you want to see the mechanics against your own domain map, start with the web push notifications feature overview and the pricing plans. Paid plans carry a 14-day money-back guarantee, so the architecture can prove itself on your traffic before the decision is final.
