A new post goes live. Your best readers are already on their phones, but they will not open the site again until dinner. Email is slow for that moment. SMS is expensive and awkward for a blog. A third-party push SaaS wants another account, another bill, and another privacy review. Progressify’s push notifications let you send WordPress PWA push messages from your own wp-admin dashboard: manual campaigns, automatic sends when new content publishes, optional image and action buttons, an app badge, and a subscriber list with country, device, and browser. No third-party push service. No per-message fees.
Progressify is the DaftPlug PWA plugin. This post stays on push notifications only. Not install prompts, not QR install codes, not offline page cache, not the bottom tab bar, not dark mode, not screen wake lock, not pull to refresh, not haptics, not shake to refresh, not autosave forms, not background sync, not the native share button, not Android or iOS store builds, not page transitions, not idle detection, not skeleton loaders, not toast messages. Those are siblings on the same installable stack. A separate enablement may already cover install timing (for example scroll-depth and visit-count install prompts). This article is push-only.
What Progressify actually ships here
Stay inside the real feature set:
- Push notifications from wp-admin so campaigns live next to the rest of your WordPress workflow
- Manual send when you want a one-off message for a launch, flash sale, or breaking update
- Automatic push on new content so a publish event can alert subscribers without a second tool
- Rich notification options including image, action buttons, and app badge where the browser and OS allow them
- Subscriber list with country, device, and browser so you can see who opted in without exporting to a separate ESP just to understand the audience
- No third-party push service and no per-message fees as the product-facing cost model for this path
This post does not invent undocumented A/B testing suites, geo-fencing dashboards, or SMS fallbacks Progressify does not publish. It does not promise that every browser and OS shows every rich field the same way. The product promise is push from your dashboard, manual or automatic, with subscriber context, without renting a push SaaS per send. Stay there. Install prompts, QR, offline cache, tab bar, dark mode, wake lock, pull, haptics, shake, autosave, background sync, share, store builds, transitions, idle, skeletons, and toasts are parallel tools, not this article’s job.
Why WordPress PWA push notifications matter
Attention has moved off the open tab. Installed PWAs and notification permission give you a polite channel back to people who already said yes. That is different from blasting cold traffic.
Email and social are not the same job. Email is durable and searchable. Social is rented attention. Push is the “something just happened” channel for people who already trust the site enough to allow notifications.
Third-party push stacks add cost and complexity. Another vendor means another privacy policy, another webhook, another invoice when volume grows. Shipping push from Progressify inside WordPress keeps the control plane where your content already lives.
Automatic on new content matches publishing rhythm. Many WordPress teams publish on a cadence. Wiring push to that event reduces the “we forgot to announce” failure mode without requiring a marketer to open a second app every time.
Subscriber context prevents flying blind. Country, device, and browser on the list help you see whether iOS Safari, Android Chrome, or desktop dominates. That shapes copy length, image use, and which templates you smoke-test after a theme change.
Sibling PWA features solve different friction. Install prompts grow the installable audience. Offline cache keeps pages readable without a network. Push speaks after the visit. Shipping all three in one untested hour makes regression hunting painful. Enable push, verify send and subscribe paths, then add install or offline work on their own day.
How to enable and use push in wp-admin
Assume Progressify is installed, the site runs over HTTPS in production, and you understand that browsers require a user gesture and permission for notifications. You will verify on a real device that can show system notifications, not only in a desktop customizer preview.
1. Decide what “new content” means for your site
Walk the real publish paths: blog posts, product updates, event notices, status pages. Note which content types deserve an automatic push and which should stay manual-only (draft experiments, minor typo fixes republished, internal notes). That list becomes your first policy. Do not enable every experimental PWA toggle in the same hour.
2. Open Progressify and find push notifications
In wp-admin, open Progressify. Locate push notifications among the feature list Progressify exposes alongside install prompts, offline cache, tab bar, dark mode, and the other app-like tools. Turn push on for a first pass. Leave install prompts, QR, offline cache strategy, tab bar, dark mode, wake lock, pull, haptics, shake, autosave forms, background sync, share, transitions, idle, skeletons, and toasts alone until subscribe and send are verified.
3. Confirm permission and subscribe on a real device
- Open a public HTTPS front-end URL (or the installed PWA window if that is how readers use you).
- Complete the browser notification permission flow Progressify presents for push.
- Confirm the device appears on the subscriber list with country, device, and browser populated as the product shows them.
- Repeat once on a second browser or OS if your audience is mixed.
If the device never appears, confirm push is enabled, confirm HTTPS, confirm the browser supports web push on that OS version, and confirm you actually granted permission (not blocked at the OS level). Do not invent undocumented Progressify “force subscribe every admin” toggles that are not on the product page.
4. Send a manual test notification
From the Progressify push UI in wp-admin, compose a short manual message. Keep the first test boring and identifiable (“Progressify push test [date]”). If you use image, action buttons, or app badge on this pass, note which fields your test browser actually renders. Send to yourself (or a known test subscriber), then confirm the system notification appears, opens the expected destination, and that badge behavior matches what you configured where supported.
5. Wire automatic push on new content carefully
Enable automatic push for the content types you listed in step 1. Publish a draft or scheduled post that is safe to announce. Confirm subscribers receive the automatic message after publish, and confirm a trivial edit-and-update does not spam people if your workflow republishes often. If automatic fire feels too noisy, narrow which content types trigger it and keep launches on manual send.
6. Read the subscriber list like an ops tool
Open the subscriber list. Spot-check country, device, and browser columns. Export or note patterns for your runbook (for example “most push readers are Android Chrome”). That context matters when someone asks why an iOS-only screenshot looks different, or why an image-heavy notification feels cramped on small screens.
7. Document the enablement for the next teammate
Write one line in your internal runbook: “Progressify push enabled on [date]. Manual send verified. Automatic on [content types]. Test subscribers: [devices]. Install prompts and offline cache are separate.” Push gets blamed when a redesign changes the permission entry point and someone assumes subscribe still works.
Who this is for
Publishers and news-style WordPress sites that need a fast “we just published” channel for people who already opted in.
WooCommerce and product-led stores that announce drops, restocks, or limited windows without paying per SMS or per push SaaS message.
Membership, course, and community sites where enrolled readers expect timely updates but do not live in email all day.
Local businesses and event sites that push schedule changes, door times, or status updates to a known subscriber base.
Agencies shipping PWAs for clients who asked for “app-like” re-engagement without adding a second vendor stack.
This is less urgent for brochure sites that publish once a quarter and never ask for notification permission, or for purely desktop intranet tools where email already covers every alert. Even then, push is cheap insurance when a later content cadence needs a real-time channel.
What good looks like
- A subscriber who granted permission receives a manual test notification on a real device within a normal delay for that browser.
- Automatic push fires when the content types you chose publish, without surprise sends on every tiny revision.
- Optional image, action buttons, and app badge behave as expected on the browsers you care about, and you documented where OS limits apply.
- The subscriber list shows country, device, and browser for real opt-ins, not an empty table after a false “enabled” checkbox.
- You send from wp-admin without a third-party push SaaS account or per-message invoice for this path.
- Install prompts, offline cache, tab bar, dark mode, and wake lock remain optional siblings, not confused with push.
- Support stops guessing whether “notifications are broken” means permission denied, OS block, or a send that never left the dashboard.
If nothing arrives, confirm permission, confirm the subscriber row exists, confirm the send UI reported success as Progressify presents it, and re-test in a clean browser profile in case an extension or OS focus mode is swallowing notifications.
Pitfalls (the ones that bite)
Confusing push with install prompts. Install grows the home-screen audience. Push speaks after permission. Debugging one while expecting the other wastes a day.
Enabling every PWA toggle with push. If push, tab bar, dark mode, and offline cache all land together, you cannot tell which change moved engagement or caused a layout fight. Enable push, verify, then add the next piece.
Automatic push on every content type. Draft experiments, SEO tweaks, and republished fixes can spam loyal subscribers. Start narrow. Keep noisy launches on manual send until the policy is clear.
Testing only on desktop Chrome. Mobile OS permission sheets, badge rules, and image rendering differ. Verify on the phones your audience actually uses.
Promising identical rich notifications everywhere. Image, action buttons, and badge support vary by browser and OS. Document what you verified instead of marketing universal parity Progressify does not claim in this post.
Ignoring OS-level notification blocks. Users (and MDM profiles) can silence a site after they said yes in the browser. Treat “permission granted once” as necessary, not sufficient, when support tickets arrive.
Forgetting to re-test after a theme or service worker change. PWA layers share infrastructure. A redesign that rewrites scripts can break subscribe or click-through. Behavior that worked last month can silently stop.
Practical checklist before you call it done
- Confirm Progressify is installed and production URLs are HTTPS.
- List which content types deserve automatic push versus manual-only.
- In Progressify, enable push notifications only for this pass.
- Leave install prompts, QR, offline page cache, tab bar, dark mode, wake lock, pull, haptics, shake, autosave, background sync, share, store builds, transitions, idle, skeletons, and toasts alone if they are not already stable.
- Subscribe on a real device and confirm the subscriber list shows country, device, and browser.
- Send a manual test with a clear subject; confirm delivery and open behavior.
- If using image, action buttons, or app badge, note what each test browser actually rendered.
- Enable automatic push only for the content types you chose; publish one safe test; confirm the send.
- Spot-check a second device or OS when you can.
- Write the enablement date, content-type policy, and verified devices in the team runbook.
- Re-test after the next theme or Progressive Web App redesign.
- Only then consider enabling other Progressify features that change front-end UX.
Takeaway
Readers who already trust you should not depend on luck to see the next publish. Progressify’s push notifications send WordPress PWA messages from your own dashboard: manual campaigns, automatic alerts on new content, optional image and action buttons with app badge, and a subscriber list with country, device, and browser. No third-party push service. No per-message fees. It is not an install prompt, not offline cache, and not a tab bar. It is the re-engagement channel for people who opted in.
Progressify handles push alongside the rest of the PWA stack, without asking you to rent a separate push SaaS that knows nothing about your WordPress publish flow. Enable it once. Test with a real device and a boring manual send. Keep sibling PWA features as separate enablement work. For growing the installable audience after push is stable, use the related install prompt by scroll depth and visit count guide when you are ready.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when push should leave wp-admin instead of another vendor invoice.
Turn push on. Subscribe on your phone. Send the test. When the system notification lands with the copy you wrote, the PWA finally has a channel that matches how people actually come back.