What happens to a PWA when its domain is flagged?

New visitors see a browser warning instead of your page, so installs stop. Users who already installed can usually still open the app, but if Safe Browsing flags the origin they will see warnings too, and some ad networks will pause campaigns pointing at the domain. The app is tied to its origin, so the fix is to publish it on a new domain and move traffic there.

Can I move an installed PWA to a new domain?

No. An installed PWA belongs to the origin it was installed from; there is no migration. You publish the same app on a new domain, send new traffic there, and let the old installs keep working on the old domain for as long as it stays usable. Push subscribers stay with the domain they subscribed on.

How many domains should I keep for PWA campaigns?

At least one spare verified domain per active vertical, ready with DNS and SSL, so a rotation takes minutes rather than a day. Keep PWA domains separate from your main tracking domains and from each other by vertical, so one flag does not take down unrelated campaigns.

Why does Chrome show my domain in the push notification?

Chrome adds the sending site's origin to the header of every web push notification on Android, and it cannot be removed. That makes the domain name part of your creative: a brand-style domain reads as an app, a tracking-style subdomain reads as spam.

How do I rotate a PWA domain in BATracker?

Verify the new domain, duplicate the app onto it (page versions, icons, listing, colours and push keys are copied and a new PWA lander is created), set the new app active, switch the campaign path's lander to the new app, and keep the old app active for its existing installs and subscribers. New traffic installs from the new domain immediately.

Should the tracking domain and the PWA domain be the same?

No. Use a dedicated domain for the app. The tracking domain handles campaign links and postbacks and should not inherit the reputation risk of app landers, and the app's domain shows up in push notifications and the install dialog, so it should look like a brand.

PWA Domain Rotation: Keep Your Apps Live When a Domain Gets Flagged

A PWA is bound to the domain it was installed from. If that domain gets flagged, new installs stop, existing users may see warnings, and push from that origin starts to look like spam. There is no migration; you publish the same app on a fresh domain and move traffic to it. The difference between a bad afternoon and a bad week is whether you prepared for that moment: spare verified domains, a one-action duplicate, a campaign path you can switch, and a fallback for old installs.

This article explains what a flag does to a PWA funnel, the signals that one is coming, how to structure domains to limit the damage, the rotation procedure in detail, and what happens to the users who already installed.

Quick answer

The risk: Safe Browsing, ad network domain lists, registrar and host actions. Any of them makes the domain unusable for new installs.
The structure: dedicated PWA domains, one per vertical or offer group, never your main tracking domain, with spares verified in advance.
The signals: install rate collapsing while LP views hold, ad network disapprovals naming the domain, browser warnings on your own test phone, push opt-ins dropping.
The procedure: verify spare, duplicate app to spare, activate, switch path lander, keep old app for existing installs, set fallback URLs, monitor.
The users: existing installs stay on the old domain; subscribers stay with the origin they subscribed on; new traffic goes to the new domain.

Why a PWA is bound to its domain

An installed PWA is defined by its origin: scheme plus host. The manifest, the service worker, the storage that holds the click ID, and the push subscription are all scoped to that origin. Browsers do this on purpose so one site cannot speak for another. The consequence for an affiliate is that "moving" an app is not possible in the browser's model. A PWA on app-a.example and the same page on app-b.example are two different apps to the phone.

That makes the domain the single point of failure in the funnel, more than the page, the offer or the tracker.

What can flag a domain

Google Safe Browsing and similar lists. A domain reported for deceptive content or hosting something malicious gets a full-page browser warning. Chrome, Safari and Firefox all use such lists. Users see red screens instead of your app, and installed apps on the origin can be warned as well.
Ad network domain reputation. Networks keep their own lists. A domain disapproved on one source can be rejected on others that share signals.
Registrar and hosting actions. Abuse reports can lead to a registrar hold or DNS suspension, which makes the domain unreachable outright.
Platform notification controls. On Android 13 and later users can block an app's notifications; many blocks on one origin affect how that origin's pushes are treated.

Most flags trace back to content and behaviour: misleading app names and ratings, push messages that imitate system alerts, pages that differ from the ad, or complaints from users who felt tricked. Rotation handles the symptom; honest pages and pushes reduce how often you need it. Follow the ad network's policy and the advertising rules of each market you run in.

Structure domains so one flag stays small

Dedicated PWA domains. Never serve apps from the domain that carries your campaign links and postbacks. A flag on the app domain should not touch tracking.
One domain per vertical or offer group. A casino app and a dating app on the same origin share the same fate. Separate them.
Brand-style names. The domain shows in the install dialog, the home-screen app settings and, on Android, in the header of every push notification. app.brandname.com or brandname-app.com reads as a product. t3.trk-something.net reads as tracking.
Spares verified in advance. Add and verify at least one spare domain per vertical before you need it: DNS pointed, SSL issued, status verified. In BATracker, a custom domain is a CNAME to the platform and SSL is automatic, so verification takes minutes once DNS has propagated, but you do not want to wait for propagation during an incident.
Registrar hygiene. Use a registrar with a clean abuse process, keep contact details valid, and do not bundle unrelated domains in one account if an account-level action would hurt.

Plan limits matter here: BATracker's Starter plan includes 10 custom domains, Professional 20 and Enterprise 100 as of November 2026, so size the plan to the number of verticals times at least two.

Signals that a rotation is coming

Watch these in the app's stats and the campaign reports:

Signal	What it looks like	Likely cause
Install rate collapses, LP views steady	Page loads, nobody installs	Browser warning on install, or prompt blocked
LP views collapse, visits steady	Tracker redirects, page does not load	Safe Browsing interstitial or DNS problem
Ad disapprovals naming the destination	Network rejects ads to this domain	Network reputation list
Push opt-ins drop while installs hold	Users install but refuse notifications	Origin reputation in the OS or browser
Your own test phone shows a warning	Red interstitial on the campaign URL	Safe Browsing or certificate issue

Check the domain daily with a real phone and a tool such as Google's Safe Browsing site status page. When two of these signals appear together, rotate; do not wait for installs to hit zero.

The rotation procedure

This is the BATracker procedure; the steps map to any setup that lets you publish the same app on another domain.

Confirm the spare is verified. Settings, Domains: the spare shows verified with SSL active. If not, fix DNS first.
Duplicate the app onto the spare. Open the flagged app and choose Duplicate: name, optional new slug, and the target domain. The copy includes the listing, languages, colours, icons, screenshots, every published page version with the live version selected, and fresh push keys. A new PWA lander is created for the copy.
Check the copy on a phone. Open the new app's public URL on Android and iOS: page loads clean, install works, icon opens and routes to the offer with the click ID in the URL. Confirm one install and one launch appear in the new app's stats.
Activate the copy. Set its status to active if the duplicate was created as a draft.
Switch the campaign path. In each campaign that uses the old PWA lander, replace it with the new one. Weighted paths let you move 100 percent immediately or ramp if you want to compare.
Keep the old app active. Do not delete or pause it. Users who installed from the old domain still open their icon and still launch through the tracker; their push subscriptions still work from the old origin for as long as the browser allows. Deleting the app turns every one of those launches into a dead end.
Set fallback URLs. On both apps, set the fallback CTA URL to a direct-link campaign URL for the same offer with a sub ID that marks it as a fallback, so launches from installs whose click data has expired still produce tracked, attributed clicks.
Update the ad destinations. The campaign URL on your tracking domain has not changed, so ads need no edit unless the ad network flagged the final destination and requires a new review.
Monitor for a week. Install rate and launch rate on the new app should return to the pre-flag baseline. If they do not, the flag was on something else: the creative, the offer domain or the tracking domain.

Total time with a prepared spare: under fifteen minutes.

What happens to existing users

Installs on the old domain keep working as long as the browser lets them open the origin. If the domain is on a Safe Browsing list, Android users get a warning when the app opens; some proceed, many do not. If the domain is suspended at DNS, the app opens to an error. Either way, you cannot move those installs. What you can do is keep the old app serving for the users who can still reach it, and keep its fallback URL pointing at a working offer.

Push subscribers on the old domain remain tied to that origin. You can keep sending from the old app as long as deliverability holds; watch failed counts and uninstalls after each send and stop if they spike. New subscribers accumulate on the new app from the day you switch traffic. Over a few weeks the audience naturally migrates to the new origin.

Click attribution is unaffected. Clicks, installs, launches and conversions on both apps are recorded against their own clicks and campaigns. Reports by campaign show both apps' traffic; the app stats pages show each app separately.

Preventing the next one

Honest listing. App name, developer, ratings and reviews that match the offer. No brand you do not represent.
Honest push. Messages about the app the user installed, at a frequency the audience tolerates, from a domain that looks like the app. Nothing imitating system or messaging alerts.
Consistent destination. The page the ad network reviews and the page the user sees should be the same page. Networks forbid showing reviewers something else, and it is the fastest route to a domain-level flag.
Monitor complaints. Uninstalls, permission revocations and push failures are early warnings. BATracker's Push tab shows subscriber changes and the reasons subscriptions fail per install.
Rotate proactively on big launches. Starting a new high-volume campaign on a fresh domain means a flag on that campaign does not take older, well-performing installs with it.

Checklist

Before launch:

Dedicated PWA domain per vertical, brand-style name, verified, SSL active.
At least one spare per vertical, verified.
Fallback CTA URL set on every app.
Test install and launch on Android and iOS from the campaign URL.

Daily:

Install rate and LP views per app.
Campaign URL opened on a real phone.
Ad network disapproval queue.

On a flag:

Duplicate to spare, test, activate, switch path, keep old app live, set fallbacks, monitor.
Verify a new spare the same day.

Bottom line

The domain is the fragile part of a PWA funnel, so treat it like inventory: dedicated per vertical, named like a brand, with spares verified before you need them. When a flag comes, rotation is a duplicate, a test and a path switch, and it should take minutes. Existing installs and subscribers stay where they are; new traffic moves on. The complete PWA guide covers the rest of the funnel, push notifications covers the messaging that most often causes flags, and how to track PWA installs and launches covers the metrics you will watch during and after a rotation.