Skip to content
Platforms · 7 min read

Web push on Wix, Squarespace and Webflow

Hosted website builders let you add scripts but not files at your domain root. Web push needs exactly that file. Here’s why — and the workarounds that genuinely work.

Updated By the Pusharoo team
In short
  • Browsers only deliver push to a service worker served from your own domain.
  • Wix, Squarespace and Webflow let you inject scripts but not upload a file at /sw.js.
  • Workarounds: a subdomain you host yourself, or a proxy route if your domain runs through a CDN you control.
  • Some vendors collect subscribers on their own subdomain — the permission then belongs to them, not you.

Why hosted builders are tricky

A service worker must be served from the same origin it controls — https://yoursite.com/sw.js for the whole site. Browsers refuse workers from other domains. Hosted builders host your files on their infrastructure and don’t expose the root path for arbitrary uploads, so the one file push needs can’t be placed there. Script injection alone isn’t enough.

What each builder allows

BuilderInject scripts?Root file at /sw.js?
WixYes — Settings → Custom code (paid plan, connected domain)No
SquarespaceYes — Code Injection on plans that include itNo
WebflowYes — site custom code on paid site plansNo
ShopifyYes — theme.liquidNo (see Shopify guide)

Plan names and menus change; check your builder’s current help pages.

Workaround 1: a subdomain you control

Host a small page on a subdomain you run yourself — for example alerts.yoursite.com on any basic web host — with sw.js at its root and the Pusharoo snippet. Link to it from your builder site (“Get alerts”). Subscriptions belong to that subdomain, so notifications show alerts.yoursite.com as the source, and links can point anywhere on your main site. It’s honest, simple and fully yours.

Workaround 2: a proxy route at your domain

If your domain’s traffic passes through a CDN you control (such as Cloudflare in proxy mode), an edge rule or Worker can answer /sw.js with the service worker file while everything else goes to the builder. The browser then sees the worker on your domain. Some builders don’t officially support proxied domains or may break SSL validation, so test carefully and keep a rollback plan. The Cloudflare Worker steps are in our Shopify guide.

Workaround 3: a vendor’s subdomain (with caveats)

Some push services offer a “no file needed” mode where visitors subscribe on yourname.vendor.com in a pop-up window. It works, but the browser permission belongs to the vendor’s domain, notifications show their domain, and you can’t take the list with you (ownership explained). Pusharoo doesn’t do this — your subscribers belong to your domain.

Or move the content that needs push

If push is central to your strategy — a news site, a deal blog — consider hosting that part on a platform where you control the root, like WordPress or a static site, and keep the builder for the rest. Setup there is two files (docs).

Questions

Can I add push notifications to Wix?

Not with a standard root service worker, because Wix doesn’t let you upload a file at /sw.js. Use a subdomain you control or a proxy route if your domain is proxied through a CDN you manage.

Does Squarespace support web push notifications?

Squarespace allows code injection but not root files, so standard web push needs a workaround such as a subdomain you host.

Why can’t I load sw.js from pusharoo.com?

Browsers only allow a service worker from the same origin as the page it controls. That’s a security rule of the web platform.

More in Platforms: WooCommerce push notifications: setup and playbook · Magento 2 push notifications · All guides

Free for life. No limits.

Unlimited subscribers, campaigns and automations. No badges. About five minutes to install.