You hit publish at 6:00am. Your most loyal listeners open their app at 6:15 and do not see the new episode. Some apps show it at 6:20, others at 9:00, a few the next day. For a daily news show, a sports reaction show or a time-sensitive interview, those hours matter.
The delay is not a bug in any one app. It comes from how podcasting has worked since the beginning: apps and directories have to keep checking millions of feeds to see whether anything changed. Podping is an open system that flips that around, so your host tells the world the moment your feed changes. This guide explains what Podping is, how it works, how to check whether your show uses it, and what difference it makes, including how podsearch.org uses it to make new episodes searchable within seconds to minutes.
The problem: polling millions of feeds
Every open podcast is an RSS feed hosted by your podcast host. Apps and directories do not get told when you publish; they find out by downloading your feed again and comparing it with the last copy. This is called polling.
With a handful of feeds, polling every few minutes is easy. With millions, it is a huge amount of traffic, most of it wasted, because most feeds have not changed since the last check. So every directory has to make a trade-off:
- Poll frequently and spend a fortune on bandwidth and servers, hammering hosts with requests.
- Poll rarely and show new episodes late.
In practice, directories poll active shows more often and inactive shows less often. That works reasonably well, but there is always a gap between publishing and a directory noticing, and the gap is longest for smaller and less frequently published shows.
Earlier solutions
Notification systems for feeds are not new. WebSub (formerly PubSubHubbub) and rssCloud both let a feed announce changes to subscribers through a hub. They work, but adoption in podcasting was uneven: each directory had to subscribe to each feed through the right hub, and many hosts and directories never supported them.
What Podping is
Podping is a global notification system for podcast feed updates, developed by the Podcast Index community as an alternative to WebSub and rssCloud. Its design is simple:
- When your feed changes, your host sends a ping. It makes a web request to the Podping service with your feed's URL.
- The service writes the URL to a public ledger. Specifically, it publishes a small message to the Hive blockchain, a public, fast, low-cost blockchain. The message says, in effect, "this feed has updated".
- Anyone can watch the ledger. Directories, apps and search engines stream the blockchain and see every ping as it is written. The project describes watchers seeing updates within about 20 seconds.
- Watchers re-check the feed. When a watcher sees a ping for a feed it knows, it downloads that feed immediately rather than waiting for its next scheduled poll.
Because the notifications are public, your host only has to send one ping, and every service that watches Podping learns about your update at the same time. No subscriptions, no per-directory integrations.
According to the project, pings can also carry "reason" and "medium" codes, so watchers can treat different kinds of updates and different kinds of feeds appropriately.
Why a blockchain?
The blockchain is used as a shared, public, append-only message board, not for currency or speculation. Its useful properties here are that anyone can read it, nobody can quietly delete or reorder messages, and it is designed for fast writes. You do not need a crypto wallet, tokens or any blockchain knowledge to benefit from Podping; your host handles it.
How podsearch.org uses Podping
podsearch.org runs a Podping watcher that streams these notifications continuously. When a ping arrives for a feed in its catalog (built from the Podcast Index, about 4.7 million feeds):
- The feed jumps to the front of the polling queue.
- A worker re-fetches the feed, typically within seconds to minutes of the ping.
- New episodes are parsed and written to the database, and indexed into search at the same time.
The result is that a new episode from a Podping-enabled host can be searchable on podsearch.org shortly after publish.
Feeds that do not send pings are still covered, by adaptive polling: podsearch.org checks shows that published recently far more often than shows that have been quiet for months, and uses conditional requests so unchanged feeds cost little to check. Podping simply removes the wait.
The watcher also keeps track of its position on the blockchain, so if it restarts, it catches up on pings it missed rather than losing them.
How to tell if your show uses Podping
There are three ways to check.
1. Ask your host or check its documentation. Search your host's help center for "Podping". If your host does not support it, ask. Hosts prioritize features that customers request.
2. Look in your feed for the Podping tag. Open your RSS feed in a browser and search for podcast:podping. A feed that declares Podping support contains:
<podcast:podping usesPodping="true"/>The tag is a declaration that your feed sends pings. Its absence does not prove your host does not ping, but its presence is a good sign.
3. Watch for your own ping. If you or a friend are comfortable with developer tools, you can stream Hive operations whose ids begin with pp_ (the identifiers Podping uses) and filter for your feed URL after you publish.
If your host does not support Podping
You still get indexed through polling. To make polling work well for you:
- Publish on a regular schedule. Adaptive pollers check frequently-publishing shows more often.
- Keep your feed fast and reliable, with correct caching headers, so polls succeed.
- Avoid unnecessary feed churn. Editing old episodes constantly does not help discovery and can confuse "what is new" logic.
- Consider your host. If timeliness matters to your format (news, sports, daily shows, live events), Podping support is a reasonable factor when choosing a host.
Self-hosters can send pings themselves. The Podping project describes a simple web request to its service with the feed URL; see the project's documentation for current details and authorization requirements.
What Podping does and does not do
It does:
- Tell watching services that your feed changed, within seconds.
- Reduce the delay before new episodes appear in services that watch it.
- Reduce wasted polling traffic for hosts and directories.
It does not:
- Submit your show to directories that do not already know your feed. You still need to be listed.
- Change your ranking. It affects how quickly an episode appears, not where it ranks.
- Guarantee that every app shows your episode instantly. Each app decides whether to watch Podping and how quickly to act.
- Replace good feed hygiene. If your feed is invalid or your GUIDs change, pings just make problems appear faster.
Who benefits most
Daily and news shows benefit most, because their content loses value by the hour. Sports shows reacting to games, live-event coverage and shows with scheduled releases that promote a publish time on social media also benefit: when listeners click your announcement, the episode should already be there.
Small shows benefit too. Pollers tend to check small, infrequent shows least often, so the gap between publishing and appearing can be longest for them. A ping closes that gap regardless of show size.
A publishing-day checklist
- Publish the episode at your host.
- Confirm it appears in your RSS feed with a unique GUID, correct date and working audio link.
- If your host supports Podping, the ping is sent automatically.
- Search the episode title on podsearch.org or in an app that watches Podping; it should appear quickly.
- Share links once you have confirmed the episode is live.
A brief history of feed notifications
Notifications for feeds have been tried several times, and the history explains Podping's design choices.
rssCloud, dating from the early days of RSS, let a feed name a "cloud" server that would notify registered subscribers when the feed changed. It never became widespread in podcasting.
WebSub (originally PubSubHubbub) introduced hubs: a publisher notifies a hub, and the hub pushes updates to subscribers who registered for that feed. It works well where it is supported, but every directory has to subscribe to every feed through the right hub, and subscriptions expire and must be renewed. For millions of feeds and many directories, that is a lot of moving parts.
Podping removes subscriptions altogether. A ping is published once, publicly, and any number of watchers can read it. A new directory can start watching today and immediately receive every ping from every participating host, with no registration and no per-feed setup. That simplicity is the main reason it suits the open podcast ecosystem.
Podping and live podcasting
Because a ping simply says that a feed changed, it is just as useful for live content. The Podcast Namespace includes a <podcast:liveItem> tag for announcing live streams in a feed, and when a live item is added or changes state, a ping tells watching apps to re-check the feed right away instead of discovering the stream after it has ended. If you stream live shows, Podping support at your host matters even more than for regular episodes, because the value of a live notification is measured in minutes.
What your host is doing behind the scenes
When you click publish at a host that supports Podping, the sequence usually looks like this: the host regenerates your RSS feed with the new item, waits until the updated feed is being served, then sends the ping with your feed URL. Sending the ping before the feed is updated would make watchers fetch the old version, so well-implemented hosts order these steps carefully. Watchers such as podsearch.org then fetch your feed, compare it with the version they had, and index whatever is new. If a host pings many times for small edits, watchers simply re-fetch and find little has changed; there is no penalty, but there is also no benefit to editing an episode repeatedly after publishing.
Measuring the difference
If you want to see Podping's effect for your own show, note your publish time and then check when the episode appears in a few apps and on podsearch.org. Repeat for a few episodes. Shows on hosts that send pings typically see the episode in Podping-watching services within minutes; shows without pings see more variation, depending on each service's polling schedule. The comparison is also a useful data point if you are deciding whether to change hosts.
Frequently asked questions
Do I need a crypto wallet or tokens to use Podping?
No. Your host sends pings on your behalf. Podping uses the Hive blockchain as a public notification board; podcasters do not interact with it directly.
How fast is Podping?
The Podping project describes watchers seeing updates within about 20 seconds of a ping. How quickly an app then shows your episode depends on the app; podsearch.org typically re-polls within seconds to minutes.
Does Podping help my ranking in search?
Not directly. It affects how quickly new episodes are indexed, not how they rank. Being searchable sooner can still mean more early listens for time-sensitive episodes.
Is Podping the same as WebSub?
They solve the same problem differently. WebSub uses hubs and per-feed subscriptions; Podping publishes one public notification that any service can watch.
How do I know whether my feed sends pings?
Check your host's documentation, look for <podcast:podping usesPodping="true"/> in your feed, or ask a developer to watch the Hive blockchain for your feed URL after you publish.
What if my host does not support Podping?
You are still indexed by regular polling. Publish consistently, keep your feed healthy, and ask your host to add support.
Summary
Podping replaces the slow, wasteful habit of polling millions of feeds with a single public notification your host sends when you publish. Services that watch it, including podsearch.org, re-check your feed within seconds to minutes, so new episodes become findable almost immediately. Check whether your host supports it, look for the tag in your feed, and keep your feed clean so that faster indexing shows your best work.