WebSub

TL;DR — WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. is a way to notify subscribers when you publish something, instead of waiting for them to come check your feed. It only works if your site has an RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap. or Atom feed. You point your feed at a “hub,” and when you publish, your site pings the hub, which passes the update to subscribed services. Some blogging platforms support this automatically.

What WebSub is

Normally, search engines find your new posts by coming back to look — they re-read your sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. or your RSS feed every so often on their own schedule. WebSub flips that around: the moment you hit publish, your site sends a little “hey, I’ve got something new” message, and that gets relayed to the search engines that are listening.

It used to be called PubSubHubbub (yes, really). In 2017 it was renamed WebSub and became an official web standard. Both names mean the same thing, and Google’s system still works under either one.

The one thing to know

WebSub only works with RSS or Atom feeds. It is not a way to push any random page on your site to Google. If you want to ping search engines about a normal page that isn’t in a feed, that’s a different tool (IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. for Bing; the URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. tool for Google).

And like everything in discovery, WebSub only helps a search engine find out about your content faster. It doesn’t guarantee the page gets crawled, indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., or ranked — those are still separate steps.

Do you need to set it up?

Probably not by hand. If you publish on WordPress (with a plugin), Blogger, or most hosted platforms, WebSub is either built in or one plugin away, already pointed at Google’s public hub. It’s a nice-to-have for sites that publish often — not a must-do for everyone.

Want the protocol details, Google’s exact stance, and how WebSub compares to IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it.? Switch to the Advanced tab.

TL;DR — WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. (formerly PubSubHubbub; a W3C Recommendation since January 2018, reaffirmed with a security-focused update in June 2026) is the push complement to RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap./Atom’s pull. A publisher advertises a hub in its feed (<link rel="hub">), subscribers register with that hub, and on publish the publisher pings the hub so it fans the updated feed out to every subscriber. Search services can subscribe, but WebSub itself makes no promise that any search engine will crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. a URL. It is designed around topic resources such as feeds, not as a general indexing APIThe Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content.. For participating search engines, IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. is a separate URL-notification protocol — and as of mid-2025, Bing has also stopped taking new sign-ups for its own news-feed submission program (more below), which narrows the field further.

WebSub is the push half of feeds

In the DiscoveryURL discovery is how search engines find URLs to crawl — by pull (following links and reading sitemaps) and by push (you notify them via IndexNow, the Indexing API, or WebSub). It's the find step that comes before a page is ever fetched. hub I split discovery into pull and push. RSS/Atom feeds are a pull channel: the engine polls your feed on its own cadence (Google’s Feedfetcher, for instance, won’t pull most feeds more than about once an hour). WebSub is what turns that pull into a push — instead of waiting to be re-fetched, your feed broadcasts the change the moment you publish.

That’s the whole value proposition: near-real-time notification of feed updates, rather than waiting for the next scheduled poll.

PubSubHubbub vs WebSub — same protocol, different name

This trips people up in documentation searches. The protocol was originally called PubSubHubbub (abbreviated PSH). It was renamed WebSub in October 2017 and published as a W3C Recommendation in January 2018. Pre-2018 articles say “PubSubHubbub”; post-2018 articles say “WebSub.” They’re the same thing, and Google’s hub still answers to both — which John Mueller confirmed at the time of the rename (“Yes, finally dug it up! We support both.”).

The spec itself hasn’t stood still since 2018, either: the W3C republished WebSub as a new Recommendation on 2 June 2026, adding cross-site-scripting (XSS) mitigations to the Security Considerations section. That’s a security-hardening update, not a mechanics change — the actors, discovery relations, and subscribe/ publish flow described below are the same protocol as the 2018 version. If you’re implementing (not just consuming) WebSub, read the current Recommendation rather than a copy of the 2018 text.

How WebSub actually works

There are three actors:

• Publisher — your site (specifically, your feed).
• Hub — a relay server that handles subscriptions and fan-outQuery fan-out is the technique where an AI search system breaks a single user question into multiple related sub-queries, runs those searches concurrently, and synthesizes the retrieved results into one answer. Google confirms AI Overviews and AI Mode 'may use a query fan-out technique' issuing multiple related searches across subtopics..
• Subscriber — a search engine (or any client) that wants updates.

The W3C spec frames the flow plainly: “Subscribers discover the hub of a topic URL, and makes a POST to one or more of the advertised hubs in order to receive updates when the topic changes. Publishers notify their hub(s) URLs when their topic(s) change. When the hub identifies a change in the topic, it sends a content distribution notification to all registered subscribers.”

In practice, for SEO:

1. Your feed advertises a hub with a <link rel="hub" href="..."> tag (plus a <link rel="self" href="..."> pointing at the feed’s own URL).
2. Subscribers (search engines) register with that hub for your feed.
3. When you publish, your site notifies the hub that your feed changed.
4. The hub fetches your updated feed and fans it out to every subscriber via an HTTP POST to their callback URL.

Step 2 is doing more work than “register” implies. The spec breaks subscription into separate states: a subscription request, a verification step where the hub confirms the subscriber actually wants the topic (so nobody can subscribe a stranger’s callback URL without their say-so), a lease the subscription holds for a bounded time, and a renewal the subscriber has to make before that lease expires (there’s no such thing as a permanent subscription) — plus an explicit unsubscribe path. None of that is something you, as the publisher, manage; it’s the hub-and-subscriber side of the handshake. But it’s worth knowing it exists, because it’s why “I pinged the hub” and “a search engine has an active subscription to my feed” are two different, independently-failable things.

Step 3 is also less standardized than most WebSub write-ups let on: the spec itself says “the specific mechanism for the publisher to inform the hub is left unspecified,” and only notes, as an example, that some public hubs — including Google’s — accept a POST with hub.mode=publish and hub.url set to the changed feed. That convention is universal enough in practice that “ping the hub” and “POST hub.mode=publish” are effectively synonyms — but it’s a widely-adopted convention documented as an example, not a hard requirement of the Recommendation.

The W3C spec is technically broader than feeds — it can carry any HTTP resource — but Google’s documentation scopes its recommendation to Atom/RSS feedsAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap.. The spec is wide; the SEO use case is narrow.

WebSub and Google

Google’s support is on the record, in the Build a SitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. docs: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” It’s a single subordinate sentence — Google doesn’t give WebSub its own section — but it’s confirmed.

Google’s hub is at pubsubhubbub.appspot.com, run by Google as a service — I confirmed it’s still live and answering as of 2026-07-18. That’s the hub you advertise in your feed and ping on publish. Community hubs exist too, but they’ve historically been less durable than Google’s — check that any third-party hub you’re considering is actually still responding before you commit your feed to it, rather than trusting an old blog post that says it works.

The crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. behind the curtain is Feedfetcher (Feedfetcher-Google), which is how Google crawls RSS/Atom feeds for Google News and WebSub. One important nuance from Feedfetcher’s own docs: “only podcast feeds get indexed in Google Search” through that path. So for a normal blog feed, WebSub accelerates Google’s awareness of the feed update, but the actual indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. of each page still comes from GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. following the URLs inside the feed through the normal crawl → index pipeline. WebSub is a discovery accelerant, not an indexing shortcut.

WebSub and Bing

Bing’s documented WebSub-style support has lived under Bing News PubHub — i.e., it’s news/feed-scoped, parallel to how Google’s Feedfetcher path is oriented toward News and podcasts. But PubHub itself is winding down: Microsoft stopped accepting new publisher applications to PubHub in June 2025, saying it’s moving Bing News toward automatically identifying and ranking eligible news content instead of manual submissions. Publishers already approved before then stay indexed; the submission portal for new applicants is closed. That’s a program-level retirement of manual news submission, not a change to IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it..

For pushing general web pages to Bing, the right tool is IndexNow, not WebSub or PubHub. IndexNow is Bing’s (and Yandex’s, Naver’s, Seznam’s, Yep’s) preferred real-time push for arbitrary URLs, unaffected by the PubHub change — and notably, Google does not participate in IndexNow (confirmed on indexnow.org’s own participant list as of this review). So the clean split is: WebSub for feeds (where Google’s hub is the practical option), IndexNow for general pages on the engines that support it.

How to implement WebSub

Step 1 — advertise the hub in your feed. Add a hub link and a self link. The most common form is embedded in the feed itself:

<link rel="hub" href="https://pubsubhubbub.appspot.com/" />
<link rel="self" href="https://example.com/feed.xml" />

Google’s hub also accepts the equivalent as HTTP response headers on the feed request instead of embedded tags — useful if you don’t control the feed’s XML directly (a third-party feed generator, for instance):

Link: <https://pubsubhubbub.appspot.com/>; rel="hub"
Link: <https://example.com/feed.xml>; rel="self"

Either form tells a subscriber the same thing: which hub to register with, and what this feed’s own canonical URL is. That second part matters if you ever move the feed — point the old URL at the new one with an HTTP redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. and, per the spec, a subscriber renewing its lease will follow the redirect and pick up the new hub/self pair automatically, rather than silently going stale.

Step 2 — ping the hub when you publish. POST to the hub URL with the publish mode and your feed URL — this is the widely-used convention Google’s hub (and most others) expect, described above:

curl -i -d "hub.mode=publish&hub.url=https://example.com/feed.xml" \
  https://pubsubhubbub.appspot.com/

In practice, your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. handles both steps. WordPress’s PubSubHubbub plugin uses Google’s hub by default; Blogger, WordPress.com, and Medium support WebSub natively. For a custom site, you wire the publish-ping into your publishing flow.

Verify — but know what you’re actually confirming. A 2xx from the hub only proves the hub accepted your notification; it doesn’t prove any subscriber received it, and as the publisher you generally can’t observe that last hop directly. What you can check from your own side: publish a test post, confirm the hub returns a 2xx to your ping, then watch for Feedfetcher-Google hitting your feed in your server logs shortly after — that confirms the hub re-fetched, which is as far as publisher-side verification goes. See the Validation Tests lens for the full staged breakdown (feed markup, ping response, hub re-fetch) with what each one does and doesn’t prove.

What WebSub is not

A few myths worth killing:

• It does not index pages instantly. It notifies the hub of a feed update; Google still crawls and indexes each URL through normal processes.
• It does not work for arbitrary pages. Feeds only. For non-feed URLs, that’s IndexNow (Bing) or URL Inspection (Google).
• It does not replace sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.. WebSub and sitemaps are complementary — sitemaps cover the whole site; WebSub pushes real-time feed changes. Google recommends both.
• Google’s hub is not deprecated. pubsubhubbub.appspot.com is active and run by Google — confirmed live as of 2026-07-18. Bing’s PubHub is a different story: it stopped taking new publisher applications in June 2025 (see WebSub and Bing above), so don’t treat that page as an onboarding path anymore even though it still exists.

Who actually benefits

High-frequency publishers — news sites, podcasts, and anyone whose freshness window matters — get the most out of WebSub. For a site that publishes a few times a month, the marginal speed-up over normal feed polling and good internal linkingLinks between pages on the same site. is small. It’s a sensible default if your platform offers it; it’s rarely worth heavy custom engineering on its own.

For the broader picture of how URLs get found, see the DiscoveryURL discovery is how search engines find URLs to crawl — by pull (following links and reading sitemaps) and by push (you notify them via IndexNow, the Indexing API, or WebSub). It's the find step that comes before a page is ever fetched. hub; for what happens after a URL is discovered, see CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor..

AI summary

A condensed take on the Advanced version:

• WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. = the push half of RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap./Atom. Feeds are normally pulled on the engine’s schedule; WebSub broadcasts the change the moment you publish.
• Formerly PubSubHubbub (PSH); renamed October 2017, W3C Recommendation January 2018 — republished June 2026 with XSS security mitigations added, same protocol mechanics. Google supports both names (John Mueller: “We support both.”).
• Three actors: publisher → hub → subscribers. You advertise a hub in your feed (<link rel="hub"> + <link rel="self">, or the equivalent HTTP Link headers), then notify the hub on publish (Google’s hub and most others use a hub.mode=publish POST — a documented convention, not a spec requirement); the hub fans the feed out to subscribers, each of which held a separately-verified, time-limited, renewable subscription.
• Google supports it: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Google’s hub: pubsubhubbub.appspot.com (confirmed live 2026-07-18). Feedfetcher does the crawl; note “only podcast feeds get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. in Google Search” via that path.
• Two hard limits: feeds only (not arbitrary pages), and discovery only (no guaranteed crawl or index). A successful hub ping also isn’t proof of subscriber delivery — you can only verify as far as the hub’s own re-fetch.
• Bing: WebSub-style support lived under news-scoped PubHub, which stopped taking new publisher sign-ups in June 2025. For general pages, IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. is Bing’s push, unaffected by that (Google doesn’t participate in IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it.).
• Doesn’t replace sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.; isn’t instant indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Most CMSes (WordPress plugin, Blogger, Medium) handle it automatically. Best for high-frequency publishers.

Official documentation

Primary-source documentation and the protocol spec.

Google

• Build and submit a sitemap — the one place Google documents WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled.: “If you use AtomAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap. or RSS, you can use WebSub to broadcast your changes to search engines, including Google.”
• Feedfetcher — the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. behind WebSub-triggered fetches; notes that only podcast feeds get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. in Google Search via this path.
• Google’s WebSub hub — the live, Google-run public hub you advertise and ping.
• Using RSS/Atom feeds to discover new URLs (2009) — the seminal Search Central post introducing Google’s PubSubHubbub support.

Bing / Microsoft

• Bing News PubHub support — Bing’s feed/news-scoped guidance; the page still exists, but Microsoft stopped accepting new PubHub publisher applications in June 2025.
• IndexNow / indexnow.org — Bing’s preferred real-time push for general (non-feed) URLs, unaffected by the PubHub change.

Standard

• WebSub — W3C Recommendation — the protocol spec, a W3C Recommendation since January 2018 and republished 2 June 2026 with Security Considerations XSS mitigations: hubs, subscribers, publishers, and content distribution.

Quotes from the source

On-the-record statements from Google and the W3C spec. Each link is a deep link that jumps to the quoted passage on the source page.

Google — WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. support

• “If you use AtomAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap. or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” — Google Search Central, Build a SitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.. Jump to quote
• “Google accepts RSS 2.0 and Atom 1.0 feeds.” Jump to quote

Google — Feedfetcher (the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. behind WebSub)

• “Feedfetcher is how Google crawls RSS or Atom feeds for Google News and WebSub.” — Google crawlersGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. and fetchers docs. Jump to quote

W3C — how the protocol works

• “Subscribers discover the hub of a topic URL, and makes a POST to one or more of the advertised hubs in order to receive updates when the topic changes. Publishers notify their hub(s) URLs when their topic(s) change. When the hub identifies a change in the topic, it sends a content distribution notification to all registered subscribers.” — W3C WebSub Recommendation. Jump to quote

John Mueller, Google (on the PubSubHubbub → WebSub rename, September 2017)

• “Yes, finally dug it up! We support both.” — confirming Google supports both the “WebSub” and the earlier “PubSubHubbub” names. Relayed via Search Engine Roundtable’s September 2017 coverage; the original tweet is no longer directly accessible, so treat this as attributed rather than verbatim-from-source.

WebSub publishing checklist

• Publish a valid RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap. or Atom feed with a stable public URL.
• Add both the hub relation and the feed’s self relation to the feed markup.
• Send the changed feed URL to the advertised hub after publishing or updating an item.
• Confirm the hub accepted the request, then confirm it fetched the feed from your logs.
• Keep the feed reachable without authentication and return a normal success response.
• Treat the ping as a discovery notification, not proof of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., or ranking.

The publish → notify → fetch framework

Think of WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. as a three-party handoff:

1. Publisher: updates the feed and tells its advertised hub which feed changed.
2. Hub: accepts the notification and fans it out to subscribers.
3. Subscriber: receives the notification and decides whether to fetch the feed.

Each boundary needs separate evidence. A successful publish ping proves only that the hub accepted the notification. A server-log request from the hub proves the feed was fetched. Neither proves that a search engine crawled an item URL or added it to an indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. That separation keeps discovery failures from being misdiagnosed as indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. failures.

WebSub — quick reference

Required feed markup (both elements, in the feed’s <head>/channel-level tags)

The publish ping

hub.mode values

• publish — the value a publisher sends, by convention (Google’s hub and most others use it; the spec itself leaves the publisher-notification mechanism unspecified). Tells the hub “this topic changed, go re-fetch it.”
• subscribe / unsubscribe — these ARE spec-defined (W3C Recommendation, hub.mode required parameter), used by subscribers registering or deregistering for a topic’s updates, each requiring hub verification and a renewable lease. Search engines handle this on their own end; you don’t send it.

Fast facts

• Google’s public hub: pubsubhubbub.appspot.com — confirmed live 2026-07-18.
• WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. works on feeds only (RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap./Atom) — not arbitrary pages.
• For general (non-feed) URLs on engines that support real-time push, that’s IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it., not WebSub. Bing’s separate PubHub news-submission program stopped taking new sign-ups in June 2025.
• Renamed from PubSubHubbub to WebSub in October 2017; W3C Recommendation since January 2018, republished 2 June 2026 with security-only mitigations. Same protocol, both names still work against Google’s hub.

Mistakes that quietly break WebSub

Advertising the hub but not the rel="self" link. The hub needs both tags — rel="hub" to know where to send subscribers, rel="self" to confirm exactly which feed URL your ping refers to. Ship only the hub link and some hub implementations can’t reliably match your ping to your feed.

Pinging with the wrong hub.url. The value has to be the feed’s own URL (the same one in your rel="self" link) — not the site’s homepage, not an individual post URL, not a URL with tracking parameters appended. A mismatched hub.url means the hub can’t verify the topic and the ping does nothing.

Expecting WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. to replace sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing.. A sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. is your comprehensive map of the whole site; WebSub only ever broadcasts changes to a feed you already advertised. Drop the sitemap and you lose the engine’s map of everything that isn’t in that feed.

Expecting a ping to mean “indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..” A successful 2xx from the hub only means the hub accepted your notification and will re-fetch the feed. It says nothing about whether Google (or anyone else) crawled, rendered, or indexed the pages the feed links to — those are separate pipeline stages.

Trying to use WebSub for pages that aren’t in a feed. WebSub only covers whatever’s inside the feed you pinged about. For a one-off page update outside any feed, WebSub has nothing to offer — that’s IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. (Bing and others) or Google’s URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version..

Silently trusting that every ping succeeded. Publish pipelines that fire the ping and never check the response can go months with a broken integration (wrong hub URL after a migration, a firewall rule blocking outbound POSTs) before anyone notices feed updates stopped propagating. See Validation Tests for what to actually check.

Running your own hub without callback and delivery hardening. Most publishers never need this — Google’s hub or your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms.’s built-in one covers the SEO use case. But if you do stand up your own hub (an internal syndication tool, for example), the spec’s Security Considerations flag real risks a naive implementation misses: a hub that blindly fetches or POSTs to whatever URL a client hands it is exposed to server-side request forgery (fetching internal/private addresses), so validate and restrict callback and topic URLs the way OWASP’s SSRF guidance describes. And don’t promise subscribers exactly-once delivery — HTTP retries mean a callback can receive the same content distribution more than once, so a subscriber-side implementation needs to treat delivery as at-least-once and dedupe/process idempotently, not assume a single clean POST per update.

Ping the hub and confirm it worked

Bash / curl — ping with visible status code

curl -s -o /dev/null -w "%{http_code}\n" \
  -d "hub.mode=publish&hub.url=https://example.com/feed.xml" \
  https://pubsubhubbub.appspot.com/

A 204 or 202 printed back means the hub accepted the notification. Anything else (a 4xx/5xx, or a connection failure) means the ping didn’t land — check the hub URL and your feed’s hub.url value before assuming it worked.

Python — same ping, for wiring into a publish hook

import requests

HUB_URL = "https://pubsubhubbub.appspot.com/"
FEED_URL = "https://example.com/feed.xml"

response = requests.post(
    HUB_URL,
    data={"hub.mode": "publish", "hub.url": FEED_URL},
    timeout=10,
)

if response.status_code in (202, 204):
    print(f"WebSub ping accepted ({response.status_code})")
else:
    print(f"WebSub ping failed: {response.status_code} {response.text}")

Call this right after your CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. or static-site build publishes a new post — the same moment you’d regenerate the feed itself. It’s safe to call on every publish; re-pinging an unchanged feed doesn’t hurt anything, it just tells the hub to re-check.

Prove WebSub actually fired

Pass/fail checks for after you wire up the hub link and the publish ping. These are staged deliberately: each one only proves its own step in the publisher → hub → subscriber chain, and the last hop — the hub actually delivering to a subscriber, and that subscriber acting on it — happens outside your logs entirely. A publisher can verify the first two stages directly and infer the third from the hub’s own re-fetch; nothing here (or anywhere in WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled.) lets a publisher confirm a specific subscriber received or processed an update.

Test: feed advertises the hub and itself

• Test to run: View source on your feed URL and look for both <link rel="hub" href="..."> and <link rel="self" href="..."> at the channel/feed level.
• Expected result: Both tags present, with rel="self" matching the exact URL you fetch the feed at.
• Failure interpretation: Missing rel="hub" means there’s no hub to ping in the first place; missing or mismatched rel="self" means the hub can’t reliably confirm which topic a ping refers to.
• Monitoring window: Immediate — check right after any feed template change.
• Rollback trigger: Either tag missing or rel="self" pointing at a different URL than the one search engines actually fetch.

Test: the publish ping returns a success status

• Test to run: Send a ping (see the Scripts lens) and read the HTTP status code back.
• Expected result: 204 No Content or 202 Accepted.
• Failure interpretation: A 4xx usually means a malformed request (bad hub.mode/hub.url values) or a hub.url the hub doesn’t recognize as yours; a 5xx or timeout means the hub itself is unreachable — retry before assuming a permanent failure.
• Monitoring window: Immediate — every time your publish flow fires a ping.
• Rollback trigger: Repeated non-2xx responses across multiple publishes — that’s a broken integration, not a one-off blip.

Test: the hub actually re-fetched the feed

• Test to run: Check your server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. for a Feedfetcher-Google (or your hub’s) request against the feed URL shortly after a successful ping.
• Expected result: A fetch request against the feed URL within roughly a few minutes of the ping.
• Failure interpretation: A 2xx ping with no follow-up fetch in the logs suggests the hub accepted the request but couldn’t resolve or reach your feed — worth confirming the feed URL is publicly reachable and not blocked by robots.txt or a firewall.
• Monitoring window: Within an hour of a test publish; this is the slowest-moving of these checks since it depends on the hub’s own fetch schedule.
• Rollback trigger: No fetch appears after several successful-looking pings in a row — treat the hub relationship as unverified until logs confirm it.

Test yourself: WebSub

Five quick questions on what WebSubWebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled. is, how it works, and where its limits are. Pick an answer for each, then check.

WebSub

WebSub (formerly PubSubHubbub) is a push notification protocol for RSS/Atom feeds that lets a site instantly broadcast new or updated content to subscribing search engines instead of waiting to be re-crawled.

Related: URL discovery, RSS Feeds

WebSub

WebSub — renamed from PubSubHubbub in October 2017 and made a W3C Recommendation in January 2018 — is an HTTP-based publish/subscribe protocol. It turns an RSSAn RSS or Atom feed is an XML file listing a site's most recently published or updated URLs. Search engines accept it as a sitemap-style discovery signal for fresh content — not a replacement for a full XML sitemap. or Atom feed from a pull channel (where a search engine polls it on its own schedule) into a push channel (where your site notifies the engine the moment something changes). Three actors are involved: the publisher (your site), a hub (a relay server), and subscribers (search engines and other clients).

The flow is simple. Your feed advertises a hub with a <link rel="hub"> tag; subscribers register with that hub; and when you publish, your site POSTs a “ping” to the hub, which immediately forwards the updated feed to every subscriber. Google runs a public hub at pubsubhubbub.appspot.com, and Google confirms support: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.”

The important limit: WebSub only works for RSS/Atom feeds, not arbitrary web pages, and it only speeds up discovery — it never guarantees a crawl or indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. For pushing general (non-feed) URLs, the right tool is IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. for Bing and other participating engines, or URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. for Google.

Related: URL discovery, RSS Feeds

Changelog