Publishers today live on traffic they do not control. A search engine ships an update and half your visits vanish overnight. A social network changes how it shows links and a page with a hundred thousand followers reaches a few hundred people. A news aggregator decides on its own what to surface and to whom. Between the newsroom and the reader there is always an algorithm, and it does not work for the newsroom.
Push notifications are one of the few exceptions. When a reader allows notifications from your site, you get a direct line: you send, the browser delivers, the notification appears on the screen. Nobody else decides whether your story deserves to be seen. It is a channel you own, like a newsletter, but instant and without needing an email address.
This guide is written for people who publish news: national titles focused on a single vertical, local news sites, trade portals with many sections (education, jobs, tax, health, public exams). It covers how to organise the newsroom's work, how to respect the reader, and how to read the numbers. It applies whatever platform you use, and where it helps, it shows a concrete example of how it is done. If you are starting from scratch, read what web push notifications are first.
Why push is different from every other channel
The real difference is not speed, although speed matters. The difference is who decides what reaches the reader. On social media and in search, your story competes with everything else, and an outside system picks what gets shown. With push, the choice is yours, and the reader explicitly authorised it by clicking "Allow".
That cuts both ways. The good part: what you send gets delivered, within the limits of what the browser and the device allow. The other part is a responsibility: if you send badly, nothing protects you from yourself. An algorithm that filters out weak content, oddly enough, also hides your mistakes. Push does not. Every pointless notification is one the reader sees, judges and remembers.
That is why the newsrooms that get the most out of push are not the ones that send the most. They are the ones with a method: who decides, what goes out, to whom, and when.
The newsroom workflow
A newsroom has no time to open yet another tool every time it publishes. Push only works if it slots into the work people already do. There are three main ways to make that happen, and plenty of publishers use all three at once.
From the WordPress editor
Most news sites run on WordPress. The most natural approach is to send the push from where the article is written: finish the piece, check the headline, fire off the notification without switching windows.
Natom has the Natom Push plugin, available on every plan. It installs the snippet and the service worker for you, adds a box in the editor to send the push with the article's featured image, and works on any public content type you pick in the settings. It also builds audiences automatically from your categories and tags: the "Public exams" category becomes a group of subscribers who only get exam news. The full walkthrough is in the guide to web push on WordPress.
This is the right flow for hand-picked stories: the scoop, the lead of the day, the piece the newsroom invested in.
The RSS feed in draft mode
Trouble starts when you publish a lot. Picture an ordinary day on an education portal: a new decree comes out, and within an hour the newsroom publishes ten articles on the same topic. The text of the decree, the union's reaction, the deadlines, the how-to-apply guide, the comments, the interview, the FAQ. All useful. But if every one of them became a push, readers would get ten notifications in an hour about the same thing. By the third they stop reading them. By the fifth they switch notifications off.
The fix is to separate publishing from notifying. The platform reads your site's RSS feed, but instead of sending automatically, every new article becomes a draft. On Natom it works like this: in draft mode each new article in the feed shows up in Campaigns, already routed to the audience for its category. The editor opens the drafts, picks which of the ten deserves a notification (say, the how-to-apply guide, which is the one readers will actually use), tweaks the title, chooses the day and time, and sends or schedules it. The other nine get deleted with a click.
No automatic spreading of sends, no algorithm choosing for you: the timing and the call stay with the newsroom. The prep work (title, image, link, audience) is already done. What remains is editorial judgement, which is exactly the part no machine should be doing for you. Setup details are in the RSS feed docs.
The RSS feed on autopilot
Not everyone publishes ten stories an hour. A local site that runs three or four pieces a day, or a trade blog that posts once a day, can let every article become a push with no human in the loop.
Two safeguards matter here. The first is a daily cap: a maximum number of pushes per day, beyond which further articles do not go out. It is there for the unusual days when, for whatever reason, you publish three times your normal volume. The second is quiet hours: an overnight window when nothing is sent, so the article scheduled for 2 a.m. does not wake anyone up. On top of that, a category filter lets you decide that only certain sections trigger automatic pushes.
Recurring pushes
The third tool is the push at a fixed time: the morning briefing at 7, the evening round-up at 7 p.m. It usually points to your latest news page or a summary page. You set it up once with the time zone, image and audience, and it goes out on its own every day.
One tip: do not reuse the same title forever. "Today's news" repeated for a month becomes invisible. Tie the title to the time of day and give people a reason to open it, as covered in the piece on push titles people click.
Categories and reader preferences
A portal with many sections has a problem a small blog does not: readers are not all alike. People following public exams do not want pension news. People reading about tax do not want local crime. Sending everything to everyone means each reader gets lots of notifications they do not care about, and they judge them all together.
Let the reader choose
There are two ways to solve this. One is profiling: watch what readers read and infer what they like. The other is to ask them. Asking is almost always better, for three reasons.
First, a stated choice is more accurate. Someone who read one pension story out of curiosity is not necessarily interested in pensions. Someone who ticked "Pensions" in a list of topics definitely is.
Second, trust. A reader who picked what to receive feels in control, and when a notification arrives, they know why.
Third, GDPR. Profiling means tracking browsing, and tracking browsing means legal bases, consent, privacy notices and risk. Asking the reader directly sidesteps all of that. Natom does not track what readers browse: it stores the subscription token, the browser and device, the country, and the topics the reader chose. No profiling.
How it works in practice
Right after allowing notifications, the reader sees a list of topics (your site's categories or tags) and picks one or more. They can change them any time from a "Manage notifications" link, which on WordPress can also be dropped in with a shortcode, for example in the footer or on the contact page. Details are in the reader preferences docs.
Two rules hold the whole thing together. The reader's choice is final: no topics quietly added behind their back. And readers who skip the choice get everything: plenty of people ignore the question, and there is no point punishing them by leaving them without news. That way, segmentation improves things for people who use it without making them worse for people who do not.
Audiences beyond categories
Categories are not the only way to split subscribers. A national site can send a regional story only to subscribers in one country, or use custom tags set through JavaScript for special cases. A push can always go to everyone or to one specific group: you choose when you send.
How many pushes a day, and when
There is no single right number for everyone. There is a right number for your readers, and it depends on how often they expect to hear from you. Someone who follows a breaking news site will accept more notifications than someone who reads a site of long-form analysis. Someone who picked one topic will accept fewer than someone who picked them all.
A few principles hold almost everywhere:
Fewer and better. A push the reader finds useless weighs more than a useful one. People do not judge a single notification, they judge how much you bother them overall.
Separate breaking news from features. Breaking news goes out when it happens, because its value expires. Features, guides and analysis are not in a hurry: send them when readers have time to read, such as early morning, lunchtime or the evening. This is where draft mode earns its keep: the article is ready, but the send waits for the right moment.
Respect the night. Unless the story is truly exceptional, no pushes while people are asleep. Quiet hours exist for exactly this.
Watch your own numbers, not someone else's. Try a rhythm for a few weeks, look at clicks and unsubscribes, then adjust. There is more on this in the piece on how many pushes to send per day.
Several titles in one group
Many publishers do not run just one site. They have a flagship title plus a few satellites, or a network of local sites, one per area. Often the same story matters to readers across several of them: a regional weather warning, a national tax deadline, an event that affects the whole group.
Cross-domain push solves this: you write one notification and send it to the subscribers of several sites in the same account, each with its own link. On Natom it is available from the Pro plan, which covers up to three sites, while Business goes up to ten. For a publishing group that means one person handles shared stories instead of repeating the same work on every site.
Reading the numbers
After each send there are four figures to look at.
Sent: how many notifications went out, meaning how many subscribers were in the audience you picked.
Impressions: how many notifications were actually displayed on a reader's screen.
Clicks: how many people clicked the notification.
CTR: clicks divided by impressions, meaning how many of the people who saw the notification opened it.
Why impressions are lower than subscribers
Everyone asks this in week one. You have a thousand subscribers and far fewer impressions. Where did the rest go?
The answer is that a push goes through many steps, and not all of them depend on you. The device may be off: in that case the notification is delivered when it comes back online, within the lifetime you set, and if it does not come back in time the notification expires. The reader may have turned off browser notifications at the system level, or switched on do not disturb. The browser may have been uninstalled or its data wiped: that subscriber no longer exists, but you only find out by trying to reach them. That is why a serious platform rechecks subscribers and removes the ones that show no sign of life. Natom does this, and the count you pay for is your active subscribers.
Even so, no service can reach one hundred percent of subscribers. Anyone who promises that is selling you a number, not delivery. One last technical note: above a certain size, many platforms estimate impressions from a sample instead of counting every one. On Natom that happens above 5,000 subscribers. It is an estimate, not an exact count, and should be read that way.
What actually matters
The CTR of a single push tells you little. What counts is the trend: how your average CTR moves over time, how different categories behave, which times of day work best for your audience. If CTR slides week after week, you are probably sending too much, or sending things only a few people care about. If one category has a much higher CTR than the rest, it may deserve more room. Also keep an eye on the opt-in rate for your prompt: it tells you how many visitors choose to subscribe, and it is the first signal of how much your audience trusts the channel.
Switching from another provider
Many publishers already use a push service and worry that switching means starting over. The good news is that notification permission belongs to your domain, not to the platform. A reader who clicked "Allow" on your site will not see the browser prompt again just because you changed provider.
Subscribers from the old service do need careful handling, though: depending on how it was set up, they have to be re-collected or migrated following a specific procedure. There is no magic button that moves them all across automatically. The migration guide walks through each step, including replacing the service worker and timing the transition.
Frequently asked questions
Do push notifications work on iPhone? Yes, with a limit set by Apple: on iPhone and iPad, web push only arrives if the reader has added the site to their Home Screen, on iOS 16.4 or later. On Android, on desktop with Chrome, Edge and Firefox, and on Safari for Mac, they work normally.
Does an urgent story arrive when the phone is locked? On Android, pushes go out with high priority and arrive even with the screen off. If the device is switched off entirely, the notification is delivered when it is turned back on, within the lifetime you set.
Should the push title differ from the article headline? Almost always. An article headline is written for an open page. A push title is written for someone busy doing something else who only sees the first few words. The plugin pre-fills the article headline as a starting point: rewriting it takes seconds and makes a real difference.
What does a push channel cost a publisher? It depends on the pricing model. On Natom, pushes are unlimited on every plan and you pay by number of subscribers, not per send: the Free plan covers up to 1,000 subscribers with no credit card, and the rest is on the plans page.
Do I need GDPR consent for push notifications? The reader grants browser permission explicitly, by clicking "Allow" themselves. The sensitive part is what you do with data afterwards: if you do not track browsing and do not profile, things are much simpler. For the specifics of your situation, your privacy adviser remains the reference.
Can I send a push only to readers of one category? Yes. With audiences built from categories and tags, a story about public exams can go only to people who chose public exams. Just remember that readers who picked no topic get everything, so they are part of that audience too.