Blogging & Open Web

WebSub for a Personal Website - Let the Feed Announce Its Updates

Written by Adam Muiz 19 Oct 2026 Updated: 19 Oct 2026 9 min read

A feed reader can discover a new article by checking a website's feed every few minutes. That works, but it creates an awkward choice: check often and make many requests that return nothing new, or check less often and accept a longer delay. Could a personal website announce that its feed changed without replacing RSS or Atom?

WebSub is one answer. It is a W3C protocol for sending updates from publishers to subscribers through an intermediary called a hub. It was previously known as PubSubHubbub. The protocol does not replace a feed format, and it is not the same as browser push notifications. It adds a server-to-server delivery path around an HTTP resource that already exists.

That distinction matters. WebSub can make updates more prompt and reduce unnecessary polling for compatible subscribers, but it does not guarantee that every feed reader will use the path, nor does it make polling obsolete. It also introduces leases, callbacks, signatures, and another service whose policy and availability matter. The useful question is therefore not simply “Is push better than polling?” but “Which responsibilities does WebSub add, and are they justified for this site?”

Keep the feed; change how updates travel

Atom is an XML syndication format: it describes a feed and its entries. WebSub is a delivery protocol. Its topic can be an RSS or Atom feed, an HTML page, or another HTTP or HTTPS resource. For a conventional personal website, a feed is still a natural topic because it already gives subscribers a structured list of posts.

A useful analogy is a notice board and a doorbell. A feed is the notice board: it contains the current information and remains available whenever someone visits. WebSub adds a doorbell: subscribers can arrange to be notified after the board changes. The notification does not remove the board, and a visitor who cannot use the doorbell can still check it directly.

This is also why “real time” should be treated cautiously. A publisher can notify a hub promptly, but delivery still depends on the hub, the subscriber, network conditions, retries, and implementation policy. WebSub defines a route for updates; it does not promise a universal latency or exactly-once processing.

The four roles in one update

The protocol becomes easier to reason about when its four terms are kept separate:

Topic: the HTTP or HTTPS resource whose changes matter, such as https://example.com/feed.atom.
Publisher: the owner of that topic. It advertises the relevant URLs and informs its designated hub after an update.
Hub: the intermediary that verifies subscription requests and distributes updated content.
Subscriber: a network-accessible service that asks for updates and receives them at a callback URL.

The high-level sequence in the current WebSub Recommendation is:

The subscriber retrieves a topic and discovers its hub URL and canonical topic URL.
The subscriber sends a subscription request to the hub.
The hub sends a challenge to the subscriber's callback to verify that the subscription was really requested.
When the topic changes, the publisher informs the hub.
The hub sends the updated topic content to active subscribers.

The publisher does not need a list of subscribers. The hub owns that relationship. This keeps the publishing side relatively small, while moving more complexity to the hub and subscriber.

What a small publisher must expose

A conforming publisher must advertise at least a hub URL and a canonical topic URL. WebSub uses typed web links for this discovery. The hub relation registered by IANA identifies a service where update registration is available, while self identifies the topic used for the subscription.

The links can be sent in HTTP Link headers. For XML feeds and HTML pages, they can also be embedded as link elements. Subscribers check HTTP headers first and inspect the representation when those headers do not provide the links. This model builds on the typed relationships and Link header serialization defined by RFC 8288.

An Atom feed could contain the following feed-level links:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Example Notes</title>
  <link rel="self"
        type="application/atom+xml"
        href="https://example.com/feed.atom" />
  <link rel="hub"
        href="https://hub.example.net/" />
  <!-- feed metadata and entries -->
</feed>

The domains are placeholders, not a public-hub recommendation. The self URL deserves particular care: it is the canonical topic URL that subscribers send back to the hub. It should resolve to the intended representation and remain stable. If one endpoint negotiates several media types or languages, the WebSub specification explains how discovery can return a representation-specific self URL instead.

Discovery is only half of the publisher's work. After publishing a changed topic, the publisher must inform every hub it advertises. The standard deliberately leaves that publisher-to-hub mechanism unspecified. Some hubs may accept a form-encoded POST, but that convention is not a universal command that can be copied to every provider. A CMS integration must follow the selected hub's current documentation and handle failure without pretending that a successful article publish depends on an immediate hub response.

Why subscribing is the harder side

Adding two links to a feed is simple. Building a subscriber is not just adding a webhook endpoint.

A subscriber sends the hub a form-encoded request containing its callback, mode, and discovered topic URL. A hub that can handle the request returns HTTP 202 Accepted, because acceptance is followed by asynchronous verification. The hub then performs a GET request to the callback with a random hub.challenge. The subscriber echoes that challenge only when the topic and action match a pending subscription.

Subscriptions are leases rather than permanent promises. The hub determines their duration, and the subscriber must renew before expiry. When content arrives, the callback acknowledges receipt with a 2xx response promptly. According to the specification, that response should mean “the message was received,” not “every downstream task finished successfully.” This allows expensive parsing or indexing to happen after acknowledgment, but it also means the subscriber needs its own durable processing and observability if losing an update would matter.

Delivery is not exactly-once. Hubs should retry failed requests within their own limits, yet duplicates, delayed delivery, and eventual failure remain application concerns. Feed entry identifiers and update timestamps therefore still matter. Polling the topic occasionally can also remain a useful recovery path rather than an admission that push failed as an idea.

The 2026 security details are not optional decoration

The W3C publication history records an original Recommendation from 23 January 2018 and a new Recommendation from 2 June 2026. The current document adds mitigations around cross-site scripting risks in subscription verification. This is a practical reason to avoid implementing WebSub from an old tutorial alone.

The current security guidance strongly recommends HTTPS for all requests. A subscriber should use a unique, hard-to-guess callback URL and provide a cryptographically random hub.secret. When a secret was supplied, the hub signs the distribution body with HMAC in X-Hub-Signature; the subscriber should recompute the signature and discard a payload that does not match. The specification says at least SHA-256 should be used when the transport cannot itself be trusted.

The verification challenge needs separate care. The current Recommendation requires the echoed challenge to use a safe media type and requires X-Content-Type-Options: nosniff. It also advises restricting the challenge, such as limiting its length and rejecting binary data. Those rules prevent a callback on a trusted domain from becoming a reflected-content or download vector.

Signatures do not make every part of the request trustworthy. The WebSub signature covers the body, not arbitrary request headers. HTTPS still protects the transport, and the subscriber must associate deliveries with its own subscription state rather than accepting any POST that happens to reach the callback.

When WebSub is worth adding

For a personal site, the clearest case is a stable public feed, a publishing pipeline with a reliable post-publish hook, and known consumers that understand WebSub. In that setting, the publisher-facing change can be modest: advertise discovery links, notify the chosen hub, log the result, and keep the feed valid.

The case is weaker when no relevant consumer uses WebSub, when a public callback is impossible, or when another operational dependency is not worth maintaining. Polling is less elegant but easier to inspect, and conditional HTTP requests can make it reasonably efficient. A small website does not become less “open” because it chooses the simpler mechanism.

There is also a meaningful difference between using a hub and operating one. A publisher can delegate subscription storage, verification, retry behavior, and delivery to a hub. Self-hosting the hub takes those responsibilities back. That may be appropriate for control or privacy reasons, but it is a service-operation project, not a two-link feed enhancement.

A cautious adoption checklist

Confirm that the feed or topic has one stable canonical URL and a correct media type.
Select a hub only after checking its present policy, limits, security support, and operational status.
Advertise matching rel="self" and rel="hub" links in a format supported by the topic.
Notify the hub only after the updated topic is publicly retrievable.
Do not remove normal feed access or assume every reader subscribes through the hub.
If implementing a subscriber, plan for lease renewal, duplicate delivery, quick acknowledgment, signature validation, and safe challenge responses.
Test the role actually implemented. WebSub Rocks, which is linked by the W3C specification, has separate tests for publishers, subscribers, and hubs.
Monitor both publishing and delivery paths, and keep polling as a possible fallback where freshness matters.

Conclusion

WebSub does not turn a feed into a different product. It gives an existing web resource a standard way to advertise a hub and gives compatible subscribers a callback-based path for updates. For a publisher, the visible surface can be small. Across the full system, however, verification, leases, retries, signatures, and hub policy make the tradeoff more substantial.

That makes WebSub neither an automatic upgrade nor needless machinery. It is useful when prompt server-to-server delivery solves a real problem and the additional dependency can be observed and maintained. When those conditions are absent, a valid feed and careful polling remain a sound design. The open question for any personal site is not whether push sounds newer, but whether its actual readers and publishing workflow benefit from the extra path.