Yes, push notifications work on static HTML sites. You need HTTPS, a service worker file uploaded to your site’s root folder, and a short script in the head of every page. The push service or panel stores subscribers and sends the notifications, so your static site doesn’t need its own backend, database or PHP.
People often assume push needs a dynamic site, because WordPress plugins are the most common setup. It doesn’t. A browser handles web push through the service worker and the Push API, and both run in the visitor’s browser. So push notifications on static HTML sites work the same way: a plain HTML site on GitHub Pages, Netlify, Cloudflare Pages or shared hosting can collect subscribers just like a CMS. Below I cover what you need, the setup steps, and the two static-site details that trip people up.
Can you add push notifications to a plain HTML website?
You can add push notifications to a plain HTML website as long as it’s served over HTTPS and you can upload files to it. Your push provider gives you a JavaScript snippet and a service worker file. The snippet shows the opt-in prompt, and the service worker receives notifications in the background, even when your site is closed.
Your site doesn’t store anything. When a visitor clicks Allow, the browser creates a push subscription, and the snippet sends it to your push service. From then on, you send notifications from that service’s dashboard or API.
What do you need for push notifications on static HTML sites?
You need four things, and none of them requires server-side code:
| Requirement | Why it’s needed | Static-site note |
|---|---|---|
| HTTPS | Service workers only run in secure contexts (MDN) | Most static hosts include free HTTPS |
| A service worker file | Receives and shows notifications | Upload it to the site root |
| A JavaScript snippet on every page | Shows the prompt and registers the worker | Add it to your shared header or template |
| A push service or panel | Stores subscribers and sends notifications | SaaS or self-hosted |
GitHub Pages is a good example. Its docs say github.io domains are served over HTTPS automatically, and sites with a custom domain support HTTPS enforcement (GitHub Docs).
How do you add push notifications to a static HTML site step by step?
Adding push to a static site takes about six steps:
- Sign up for a push service or set up your push panel, and add your site’s domain.
- Choose your opt-in prompt style and timing in the dashboard.
- Download the service worker file (and any other files the service provides).
- Upload the files to your site’s root folder, so they load at addresses like https://example.com/sw.js.
- Paste the JavaScript snippet into the head of every page, ideally through a shared include or template.
- Deploy, open your site in a fresh browser window, allow notifications and send a test.
If you use a static site generator such as Hugo, Jekyll or Eleventy, put the service worker in the folder that copies files to the output root unchanged. Then add the snippet to your base layout, so every page gets it.
Why does the service worker location matter?
The service worker location matters because it decides which pages the worker can control. According to MDN, a service worker’s default scope is the directory where the script sits. So a worker at example.com/js/sw.js only covers pages under /js/.
That’s why push services ask you to upload the file to the root. On a static site, check two common traps:
- Project sites in a subfolder. If your site lives at username.github.io/project/, the root you control is /project/, so the worker’s scope is that folder. Make sure your push service supports that path.
- Build tools that rename files. Some bundlers add a hash to file names (sw.3f2a.js). The service worker must keep the exact name and path your push service expects.
Also, if you put a CDN or cache in front of the site, clear it after uploading the file, so browsers get the new version.
How do you send notifications from a static site?
You send notifications from your push service’s dashboard or API, not from the site itself. A static site has no “publish” event that a plugin can hook into, so you have three options:
| Method | How it works | Best for |
|---|---|---|
| Manual send | Write the notification in the dashboard after you deploy | Sites that publish a few times a week |
| Scheduled send | Prepare campaigns in advance and schedule them | Launches and planned content |
| API call from your build | Your deploy script calls the push service’s REST API | Developers who want automation |
The API route is neat for static sites. For example, a GitHub Actions or Netlify build step can call the push API with the new page’s title and URL once the deploy succeeds. Check your provider’s API limits first.
Do static site push notifications work on iPhone?
Static site push works on iPhone and iPad only on iOS and iPadOS 16.4 or later, and only after the visitor adds your site to the Home Screen as a web app (WebKit). That usually means adding a web app manifest too. Android and desktop browsers such as Chrome, Edge and Firefox don’t need that step. I explain the iPhone setup in iPhone push notifications without an app.
What are the limits of push on a static site?
Push on a static site has the same limits as on any website, plus one practical one. The general limits are consent (visitors must click Allow), browser support and opt-in fatigue. The static-site limit is automation: without a CMS, nothing sends a notification for you unless you script it.
If your site might move to another provider later, ask how subscribers can be exported. Web push subscriptions are tied to the service worker and keys used at sign-up, which I cover in what happens to subscribers when a push provider shuts down. For the general setup on any platform, see how to add push notifications to a website.
Where does LaraPush fit for static HTML sites?
LaraPush works on any site that can serve JavaScript, including plain HTML sites. You add your domain in the panel, choose the Website integration type, paste the script into your page head, and upload the two files the panel gives you to your site’s public folder. The panel then verifies the setup. It also has a REST API with no call limits, so a build script can send notifications automatically. Pricing starts from $499 one-time (see current LaraPush pricing). The trade-offs: no free plan, and the panel runs on your own VPS, so your static site stays static but you do run one server. For other options, see the best push notification services and tools.
Frequently asked questions
No. Your push service or panel stores subscribers and sends notifications. Your static site only needs HTTPS, a service worker file in its root folder and a JavaScript snippet in each page’s head. No database, PHP or server-side code is needed on the site.
Yes, if you can upload the service worker file to the folder your site is served from. GitHub Pages serves github.io sites over HTTPS automatically. For project sites in a subfolder, the service worker scope is that subfolder, so check your push service supports it.
Put it in your site’s root folder, so it loads at an address like https://example.com/sw.js. A service worker only controls pages in its own folder and below by default, so a file in a subfolder won’t cover your whole site.
Send it manually from your push dashboard after you deploy, schedule it in advance, or have your build script call the push service’s REST API once the deploy succeeds. Static sites have no built-in publish trigger.
The snippet is usually small and can load asynchronously, so the impact is minor. The service worker runs in the background, separate from page loading. Test your pages before and after with a tool such as PageSpeed Insights.
