Protokół WebSub

TL;DR — WebSub to sposób powiadamiania subskrybentów o publikacji zamiast czekania, aż sami sprawdzą kanał. Działa tylko wtedy, gdy witryna ma kanał RSS lub Atom. Wskazujesz w kanale „hub”, a po publikacji witryna wysyła do niego ping, który przekazuje aktualizację subskrybowanym usługom. Niektóre platformy blogowe obsługują to automatycznie.

Czym jest WebSub

Zwykle wyszukiwarki znajdują nowe wpisy, wracając, by je sprawdzić — co jakiś czas, według własnego harmonogramu, ponownie odczytują mapę witryny lub kanał RSS. WebSub odwraca tę kolejność: w chwili publikacji witryna wysyła krótką wiadomość „hej, mam coś nowego”, a ta trafia do nasłuchujących wyszukiwarek.

Początkowo nazywał się PubSubHubbub (naprawdę). W 2017 roku przemianowano go na WebSub i ustanowiono oficjalnym standardem sieciowym. Obie nazwy oznaczają to samo, a system Google nadal działa pod obiema.

Jedna rzecz, którą trzeba wiedzieć

WebSub działa wyłącznie z kanałami RSS lub Atom. Nie służy do wysyłania dowolnej strony witryny do Google. Jeśli chcesz powiadomić wyszukiwarki o zwykłej stronie, której nie ma w kanale, użyj innego narzędzia (IndexNow dla Bing, a URL Inspection dla Google).

Tak jak w przypadku każdego odkrywania, WebSub pomaga wyszukiwarce szybciej dowiedzieć się o treści. Nie gwarantuje crawlowania, indeksowania ani pozycji — to nadal osobne etapy.

Czy trzeba go konfigurować?

Prawdopodobnie nie ręcznie. Jeśli publikujesz w WordPressie (z wtyczką), Bloggerze albo na większości hostowanych platform, WebSub jest już wbudowany lub dzieli go od działania jedna wtyczka, a kanał wskazuje publiczny hub Google. To przydatna opcja dla witryn publikujących często — nie obowiązek dla każdego.

Chcesz poznać szczegóły protokołu, dokładne stanowisko Google i porównanie WebSub z IndexNow? Przejdź do karty Advanced.

TL;DR — WebSub (dawniej PubSubHubbub; rekomendacja W3C od stycznia 2018 roku, potwierdzona aktualizacją skupioną na bezpieczeństwie w czerwcu 2026 roku) jest częścią „push” uzupełniającą „pull” RSS/Atom. Wydawca ogłasza hub w kanale (<link rel="hub">), subskrybenci rejestrują się w hubie, a po publikacji wydawca wysyła do niego ping, aby rozesłał zaktualizowany kanał wszystkim subskrybentom. Usługi wyszukiwania mogą subskrybować kanał, ale sam WebSub nie obiecuje, że którakolwiek wyszukiwarka zcrawluje lub zindeksuje URL. Protokół jest zaprojektowany wokół zasobów tematycznych, takich jak kanały, a nie jako ogólne API indeksowania. W przypadku obsługujących je wyszukiwarek IndexNow jest osobnym protokołem powiadamiania o URL — a od połowy 2025 roku Bing nie przyjmuje też nowych zgłoszeń do własnego programu przesyłania kanałów informacyjnych (więcej poniżej), co jeszcze zawęża możliwości.

WebSub to część „push” kanałów

W hubie Discovery dzielę odkrywanie na pull i push. Kanały RSS/Atom są kanałem pull: silnik odpytyuje kanał według własnego harmonogramu (na przykład Feedfetcher Google nie pobiera większości kanałów częściej niż mniej więcej raz na godzinę). WebSub zamienia pull w push — zamiast czekać na ponowne pobranie, kanał rozgłasza zmianę w chwili publikacji.

Na tym polega cała wartość: powiadomienie o aktualizacji kanału niemal w czasie rzeczywistym zamiast czekania na następne zaplanowane odpytywanie.

PubSubHubbub a WebSub — ten sam protokół, inna nazwa

To często myli podczas wyszukiwania dokumentacji. Protokół pierwotnie nazywał się PubSubHubbub (w skrócie PSH). W październiku 2017 roku zmieniono jego nazwę na WebSub, a w styczniu 2018 opublikowano go jako rekomendację W3C. Teksty sprzed 2018 roku mówią „PubSubHubbub”, a późniejsze „WebSub”. To to samo, a hub Google odpowiada pod obiema nazwami — John Mueller potwierdził to w chwili zmiany nazwy (“Yes, finally dug it up! We support both.” — Polski glos: „Tak, w końcu to znalazłem! Obsługujemy obie”).

Sama specyfikacja również nie zatrzymała się w 2018 roku. W3C opublikowało WebSub jako nową rekomendację 2 czerwca 2026 roku, dodając zabezpieczenia przed cross-site scripting (XSS) w sekcji Security Considerations. To aktualizacja wzmacniająca bezpieczeństwo, a nie zmiana mechaniki — opisani poniżej uczestnicy, relacje odkrywania oraz przepływ subskrypcji/publikacji pozostają tym samym protokołem co w wersji z 2018 roku. Jeśli wdrażasz WebSub, a nie tylko go używasz, przeczytaj bieżącą rekomendację zamiast kopii tekstu z 2018 roku.

Jak działa WebSub

Są trzy podmioty:

• Wydawca — Twoja witryna (a dokładniej jej kanał).
• Hub — serwer przekaźnikowy obsługujący subskrypcje i rozsyłanie.
• Subskrybent — wyszukiwarka (albo dowolny klient), który chce otrzymywać aktualizacje.

Specyfikacja W3C opisuje przepływ wprost: “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.” Polski glos: „Subskrybenci odkrywają hub adresu URL tematu i wysyłają POST do co najmniej jednego ogłoszonego huba, aby otrzymywać aktualizacje po zmianie tematu. Wydawcy powiadamiają adresy URL swoich hubów o zmianie tematów. Gdy hub wykryje zmianę tematu, wysyła powiadomienie o dystrybucji treści wszystkim zarejestrowanym subskrybentom”.

W praktyce, z punktu widzenia SEO:

1. Twój kanał ogłasza hub za pomocą tagu <link rel="hub" href="..."> (oraz <link rel="self" href="...">, który wskazuje własny URL kanału).
2. Subskrybenci (wyszukiwarki) rejestrują się w hubie dla Twojego kanału.
3. Po publikacji witryna powiadamia hub, że kanał się zmienił.
4. Hub pobiera zaktualizowany kanał i rozsyła go wszystkim subskrybentom przez HTTP POST na ich adres callback.

Krok 2 oznacza więcej niż sugeruje słowo „rejestracja”. Specyfikacja rozdziela subskrypcję na osobne stany: żądanie subskrypcji, etap weryfikacji, w którym hub potwierdza, że subskrybent naprawdę chce temat (aby nikt nie mógł zapisać cudzego adresu callback bez jego zgody), dzierżawę utrzymywaną przez ograniczony czas oraz odnowienie, którego subskrybent musi dokonać przed jej wygaśnięciem (nie ma subskrypcji bezterminowej) — a także jawną ścieżkę rezygnacji z subskrypcji. Nic z tego nie jest zarządzane przez Ciebie jako wydawcę; to część uzgadniania między hubem i subskrybentem. Warto jednak wiedzieć, że istnieje, bo „wysłałem ping do huba” i „wyszukiwarka ma aktywną subskrypcję mojego kanału” to dwie niezależne rzeczy, z których każda może zawieść.

Krok 3 jest również mniej ustandaryzowany, niż sugeruje większość opisów WebSub: sama specyfikacja mówi, że “the specific mechanism for the publisher to inform the hub is left unspecified,” Polski glos: „konkretny mechanizm powiadamiania huba przez wydawcę pozostaje nieokreślony”, a jedynie podaje przykład, że niektóre publiczne huby — w tym Google — przyjmują POST z hub.mode=publish i hub.url ustawionym na zmieniony kanał. Konwencja jest w praktyce na tyle powszechna, że „pingowanie huba” i „POST hub.mode=publish” są właściwie synonimami — ale to szeroko stosowana konwencja opisana jako przykład, a nie twardy wymóg rekomendacji.

Specyfikacja W3C jest technicznie szersza niż kanały — może przenosić dowolny zasób HTTP — ale dokumentacja Google ogranicza zalecenie do kanałów Atom/RSS. Specyfikacja jest szeroka, a zastosowanie SEO wąskie.

WebSub i Google

Wsparcie Google jest potwierdzone w dokumentacji Build a Sitemap: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Polski glos: „Jeśli używasz Atom lub RSS, możesz używać WebSub do rozgłaszania zmian do wyszukiwarek, w tym Google”. To jedno zdanie podrzędne — Google nie poświęca WebSub osobnej sekcji — ale stanowi potwierdzenie.

Hub Google znajduje się pod adresem pubsubhubbub.appspot.com i jest usługą prowadzoną przez Google — potwierdziłem, że nadal działa i odpowiada 2026-07-18. To ten hub ogłaszasz w kanale i pingujesz po publikacji. Istnieją też huby społecznościowe, ale historycznie były mniej trwałe niż hub Google — przed powiązaniem kanału sprawdź, czy rozważany hub zewnętrzny faktycznie odpowiada, zamiast ufać staremu wpisowi na blogu.

Crawlerem działającym w tle jest Feedfetcher (Feedfetcher-Google), za pomocą którego Google crawluje kanały RSS/Atom dla Google News i WebSub. Ważny niuans z dokumentacji Feedfetchera brzmi: “only podcast feeds get indexed in Google Search” przez tę ścieżkę. Polski glos: „tylko kanały podcastów są indeksowane w Google Search”. Zwykły kanał bloga zyskuje więc dzięki WebSub szybszą świadomość Google o aktualizacji, ale faktyczne indeksowanie każdej strony nadal odbywa się przez Googlebota podążającego za URL-ami wewnątrz kanału w normalnym procesie crawl → index. WebSub przyspiesza odkrywanie, ale nie jest skrótem do indeksowania.

WebSub i Bing

Udokumentowane wsparcie Bing w stylu WebSub działało w ramach Bing News PubHub — a więc dotyczyło wiadomości i kanałów, podobnie jak ścieżka Feedfetchera Google koncentruje się na News i podcastach. PubHub jednak wygasza działanie: Microsoft przestał przyjmować nowe zgłoszenia wydawców do PubHub w czerwcu 2025 roku, informując, że przechodzi na automatyczne rozpoznawanie i ocenianie kwalifikujących się treści informacyjnych zamiast ręcznych zgłoszeń. Wydawcy zaakceptowani wcześniej pozostają zindeksowani, a portal zgłoszeń dla nowych kandydatów jest zamknięty. To wycofanie programu ręcznego przesyłania wiadomości, a nie zmiana w IndexNow.

Do wysyłania zwykłych stron internetowych do Bing służy IndexNow, nie WebSub ani PubHub. IndexNow jest preferowanym przez Bing (oraz Yandex, Naver, Seznam i Yep) mechanizmem czasu rzeczywistego dla dowolnych URL, niezależnym od zmiany w PubHub — co ważne, Google nie uczestniczy w IndexNow (potwierdza to własna lista uczestników indexnow.org aktualna w chwili tego przeglądu). Podział jest więc prosty: WebSub do kanałów (gdzie praktyczną opcją jest hub Google), IndexNow do zwykłych stron w wyszukiwarkach, które go obsługują.

Jak wdrożyć WebSub

Krok 1 — ogłoś hub w kanale. Dodaj link do huba i link self. Najczęstsza forma jest osadzona bezpośrednio w kanale:

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

Hub Google przyjmuje również odpowiednik w postaci nagłówków odpowiedzi HTTP dla żądania kanału zamiast osadzonych tagów — przydatne, gdy nie kontrolujesz bezpośrednio XML kanału (na przykład korzystasz z generatora kanału innej firmy):

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

Obie formy mówią subskrybentowi to samo: z którym hubem ma się zarejestrować i jaki jest kanoniczny URL tego kanału. Druga informacja ma znaczenie, jeśli kiedykolwiek przeniesiesz kanał — skieruj stary URL do nowego przekierowaniem HTTP, a zgodnie ze specyfikacją subskrybent odnawiający dzierżawę podąży za przekierowaniem i automatycznie pobierze nową parę hub/self, zamiast po cichu stać się nieaktualny.

Krok 2 — pinguj hub po publikacji. Wyślij POST na URL huba z trybem publikacji i URL-em kanału — to szeroko stosowana konwencja oczekiwana przez hub Google (i większość innych), opisana powyżej:

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

W praktyce CMS obsługuje oba kroki. Wtyczka PubSubHubbub WordPressa domyślnie używa huba Google; Blogger, WordPress.com i Medium natywnie wspierają WebSub. Własna witryna wymaga podłączenia pingu publikacyjnego do procesu publikacji.

Weryfikuj, ale rozumiej, co naprawdę potwierdzasz. Odpowiedź 2xx z huba dowodzi tylko, że hub przyjął Twoje powiadomienie; nie dowodzi, że którykolwiek subskrybent je otrzymał, a jako wydawca zwykle nie możesz bezpośrednio obserwować ostatniego etapu. Z własnej strony możesz: opublikować testowy wpis, potwierdzić odpowiedź 2xx huba na ping, a następnie obserwować w logach serwera, czy wkrótce potem Feedfetcher-Google odwiedził kanał — to potwierdza ponowne pobranie przez hub i jest granicą weryfikacji po stronie wydawcy. Pełny etapowy podział (oznaczenie kanału, odpowiedź na ping, ponowne pobranie przez hub) z tym, co każdy test dowodzi i czego nie dowodzi, znajduje się w karcie Validation Tests.

Czym WebSub nie jest

Kilka mitów, które warto obalić:

• Nie indeksuje stron natychmiast. Powiadamia hub o aktualizacji kanału; Google nadal crawluje i indeksuje każdy URL zwykłymi procesami.
• Nie działa dla dowolnych stron. Tylko kanały. Dla URL spoza kanału użyj IndexNow (Bing) albo URL Inspection (Google).
• Nie zastępuje map witryn. WebSub i mapy witryn się uzupełniają — mapa obejmuje całą witrynę, a WebSub wysyła w czasie rzeczywistym zmiany kanału. Google zaleca oba rozwiązania.
• Hub Google nie jest wycofany. pubsubhubbub.appspot.com działa i jest prowadzony przez Google — potwierdzono jego dostępność 2026-07-18. PubHub Bing to inna historia: od czerwca 2025 roku nie przyjmuje nowych zgłoszeń wydawców (zobacz sekcję WebSub i Bing), więc nie traktuj tej strony jako ścieżki wdrożenia, mimo że nadal istnieje.

Kto naprawdę na tym korzysta

Najwięcej zyskują wydawcy publikujący często — serwisy informacyjne, podcasty i wszyscy, dla których ważne jest okno świeżości. W witrynie publikującej kilka razy w miesiącu marginalne przyspieszenie względem zwykłego odpytywania kanału i dobrego linkowania wewnętrznego jest niewielkie. Jeśli platforma oferuje WebSub, to rozsądny standard; samodzielna rozbudowana implementacja rzadko się opłaca.

Szerszy obraz tego, jak odkrywane są adresy URL, znajdziesz w hubie Discovery; informacje o tym, co dzieje się po odkryciu URL, są w Crawling.

Podsumowanie AI

Skrócona wersja karty Advanced:

• WebSub = część „push” RSS/Atom. Kanały są zwykle pobierane według harmonogramu silnika; WebSub rozgłasza zmianę w chwili publikacji.
• Dawniej PubSubHubbub (PSH); nazwa zmieniona w październiku 2017 roku, rekomendacja W3C od stycznia 2018 roku — w czerwcu 2026 opublikowano ją ponownie z poprawkami bezpieczeństwa XSS, przy tej samej mechanice protokołu. Google obsługuje obie nazwy (John Mueller: “We support both.” — „Obsługujemy obie”).
• Trzy podmioty: wydawca → hub → subskrybenci. Ogłaszasz hub w kanale (<link rel="hub"> + <link rel="self"> albo równoważne nagłówki HTTP Link), a po publikacji powiadamiasz hub (hub Google i większość innych używają POST hub.mode=publish — to udokumentowana konwencja, nie wymóg specyfikacji); hub rozsyła kanał subskrybentom, z których każdy ma osobną zweryfikowaną, ograniczoną czasowo i odnawialną subskrypcję.
• Google go obsługuje: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Polski glos: „Jeśli używasz Atom lub RSS, możesz używać WebSub do rozgłaszania zmian do wyszukiwarek, w tym Google”. Hub Google: pubsubhubbub.appspot.com (potwierdzono działanie 2026-07-18). Feedfetcher wykonuje crawlowanie; pamiętaj, że “only podcast feeds get indexed in Google Search” przez tę ścieżkę. Polski glos: „tylko kanały podcastów są indeksowane w Google Search”.
• Dwa twarde ograniczenia: tylko kanały (nie dowolne strony) i tylko odkrywanie (bez gwarancji crawlowania ani indeksowania). Udany ping huba nie dowodzi też dostarczenia do subskrybenta — możesz zweryfikować tylko do ponownego pobrania przez sam hub.
• Bing: wsparcie w stylu WebSub działało w ramach PubHub dla wiadomości, który w czerwcu 2025 roku przestał przyjmować nowych wydawców. Dla zwykłych stron IndexNow jest mechanizmem push Bing i zmiana PubHub go nie dotyczy (Google nie uczestniczy w IndexNow).
• Nie zastępuje map witryn i nie daje natychmiastowego indeksowania. Większość CMS-ów (wtyczka WordPressa, Blogger, Medium) obsługuje go automatycznie. Najbardziej przydaje się wydawcom publikującym często.

Oficjalna dokumentacja

Dokumentacja źródłowa i specyfikacja protokołu.

Google

• Build and submit a sitemap — jedyne miejsce, w którym Google dokumentuje WebSub: “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Polski glos: „Jeśli używasz Atom lub RSS, możesz używać WebSub do rozgłaszania zmian do wyszukiwarek, w tym Google”.
• Feedfetcher — crawler stojący za pobraniami wywołanymi przez WebSub; informuje, że tą ścieżką w Google Search indeksowane są tylko kanały podcastów.
• Hub WebSub Google — działający publiczny hub Google, który ogłaszasz i pingujesz.
• Using RSS/Atom feeds to discover new URLs (2009) — podstawowy wpis Search Central wprowadzający wsparcie Google dla PubSubHubbub.

Bing / Microsoft

• Bing News PubHub support — wytyczne Bing dotyczące kanałów i wiadomości; strona nadal istnieje, ale Microsoft przestał przyjmować nowe zgłoszenia wydawców PubHub w czerwcu 2025 roku.
• IndexNow / indexnow.org — preferowany przez Bing mechanizm push w czasie rzeczywistym dla zwykłych (niekanałowych) URL, niezależny od zmiany PubHub.

Standard

• WebSub — rekomendacja W3C — specyfikacja protokołu, rekomendacja W3C od stycznia 2018 roku, ponownie opublikowana 2 czerwca 2026 roku z poprawkami XSS w Security Considerations: huby, subskrybenci, wydawcy i dystrybucja treści.

Cytaty ze źródeł

Wypowiedzi Google i specyfikacja W3C zapisane w źródłach. Każdy link prowadzi bezpośrednio do cytowanego fragmentu.

Google — wsparcie WebSub

• “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” — Google Search Central, Build a Sitemap. Polski glos: „Jeśli używasz Atom lub RSS, możesz używać WebSub do rozgłaszania zmian do wyszukiwarek, w tym Google”. Jump to quote
• “Google accepts RSS 2.0 and Atom 1.0 feeds.” Polski glos: „Google akceptuje kanały RSS 2,0 i Atom 1,0”. Jump to quote

Google — Feedfetcher (crawler stojący za WebSub)

• “Feedfetcher is how Google crawls RSS or Atom feeds for Google News and WebSub.” — dokumentacja crawlerów i fetcherów Google. Polski glos: „Feedfetcher to sposób, w jaki Google crawluje kanały RSS lub Atom dla Google News i WebSub”. Jump to quote

W3C — jak działa protokół

• “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.” — rekomendacja W3C WebSub. Polski glos: „Subskrybenci odkrywają hub adresu URL tematu i wysyłają POST do co najmniej jednego ogłoszonego huba, aby otrzymywać aktualizacje po zmianie tematu. Wydawcy powiadamiają adresy URL swoich hubów o zmianie tematów. Gdy hub wykryje zmianę tematu, wysyła powiadomienie o dystrybucji treści wszystkim zarejestrowanym subskrybentom”. Jump to quote

John Mueller, Google (o zmianie nazwy PubSubHubbub → WebSub, wrzesień 2017)

• “Yes, finally dug it up! We support both.” — potwierdzenie, że Google obsługuje zarówno nazwę „WebSub”, jak i wcześniejszą „PubSubHubbub”. Przekazano za relacją Search Engine Roundtable z września 2017 roku; oryginalny tweet nie jest już bezpośrednio dostępny, więc traktuj to jako wypowiedź przypisaną autorowi, a nie cytat zweryfikowany w źródle.

Lista kontrolna publikowania w WebSub

• Opublikuj poprawny kanał RSS lub Atom ze stabilnym publicznym URL.
• Dodaj do oznaczenia kanału zarówno relację huba, jak i relację własnego kanału.
• Po publikacji lub aktualizacji elementu wyślij zmieniony URL kanału do ogłoszonego huba.
• Potwierdź przyjęcie żądania przez hub, a następnie w logach sprawdź, czy hub pobrał kanał.
• Kanał musi być dostępny bez uwierzytelniania i zwracać normalną odpowiedź sukcesu.
• Traktuj ping jako powiadomienie o odkryciu, a nie dowód crawlowania, indeksowania ani pozycji.

Model publikuj → powiadom → pobierz

Pomyśl o WebSub jak o przekazaniu między trzema stronami:

1. Wydawca: aktualizuje kanał i informuje ogłoszony hub, który kanał się zmienił.
2. Hub: przyjmuje powiadomienie i rozsyła je subskrybentom.
3. Subskrybent: otrzymuje powiadomienie i decyduje, czy pobrać kanał.

Każda granica wymaga osobnego dowodu. Udany ping publikacyjny dowodzi tylko, że hub przyjął powiadomienie. Żądanie w logu serwera od huba dowodzi, że kanał został pobrany. Żadne z nich nie dowodzi, że wyszukiwarka zcrawlowała URL elementu ani dodała go do indeksu. To rozdzielenie chroni przed błędnym diagnozowaniem problemów z odkrywaniem jako problemów z indeksowaniem.

WebSub — szybka ściąga

Wymagane oznaczenie kanału (oba elementy w tagach <head> kanału lub na poziomie channel)

Ping publikacyjny

Wartości hub.mode

• publish — wartość wysyłana przez wydawcę zgodnie z konwencją (używa jej hub Google i większość innych; sama specyfikacja pozostawia mechanizm powiadamiania wydawcy nieokreślony). Informuje hub: „ten temat się zmienił, pobierz go ponownie”.
• subscribe / unsubscribe — wartości ZDEFINIOWANE w specyfikacji (rekomendacja W3C, wymagany parametr hub.mode), używane przez subskrybentów do rejestrowania i wyrejestrowywania aktualizacji tematu, za każdym razem z weryfikacją huba i odnawialną dzierżawą. Wyszukiwarki obsługują to po swojej stronie; nie wysyłasz tych wartości.

Szybkie fakty

• Publiczny hub Google: pubsubhubbub.appspot.com — potwierdzono działanie 2026-07-18.
• WebSub działa wyłącznie z kanałami (RSS/Atom), nie z dowolnymi stronami.
• Dla zwykłych (niekanałowych) URL w wyszukiwarkach obsługujących push czasu rzeczywistego użyj IndexNow, nie WebSub. Osobny program zgłoszeń wiadomości PubHub Bing przestał przyjmować nowych wydawców w czerwcu 2025 roku.
• Nazwę zmieniono z PubSubHubbub na WebSub w październiku 2017 roku; rekomendacja W3C obowiązuje od stycznia 2018, a 2 czerwca 2026 opublikowano ją ponownie z poprawkami wyłącznie bezpieczeństwa. To ten sam protokół, a obie nazwy nadal działają w hubie Google.

Błędy, które po cichu psują WebSub

Ogłoszenie huba bez linku rel="self". Hub potrzebuje obu tagów — rel="hub", aby wiedzieć, gdzie wysłać subskrybentów, oraz rel="self", aby dokładnie potwierdzić, do którego URL kanału odnosi się ping. Wysłanie wyłącznie linku huba sprawia, że niektóre implementacje nie potrafią wiarygodnie dopasować pingu do kanału.

Ping z nieprawidłowym hub.url. Wartością musi być własny URL kanału (ten sam co w linku rel="self") — nie strona główna, nie URL pojedynczego wpisu i nie URL z doczepionymi parametrami śledzącymi. Niezgodny hub.url uniemożliwia hubowi weryfikację tematu, więc ping nic nie robi.

Oczekiwanie, że WebSub zastąpi mapy witryn. Mapa witryny jest kompletną mapą całej witryny; WebSub rozgłasza tylko zmiany kanału, który wcześniej ogłosiłeś. Jeśli usuniesz mapę, wyszukiwarka straci mapę wszystkiego, czego nie ma w tym kanale.

Oczekiwanie, że ping oznacza „zindeksowano”. Udana odpowiedź 2xx z huba oznacza tylko, że hub przyjął powiadomienie i ponownie pobierze kanał. Nie mówi nic o tym, czy Google (albo ktoś inny) zcrawlował, wyrenderował lub zindeksował strony wskazane w kanale — to osobne etapy procesu.

Próba użycia WebSub dla stron, których nie ma w kanale. WebSub obejmuje wyłącznie to, co znajduje się w pingowanym kanale. Dla jednorazowej aktualizacji strony spoza kanału WebSub nie ma nic do zaoferowania — użyj IndexNow (Bing i inne wyszukiwarki) albo narzędzia URL Inspection Google.

Ciche zaufanie, że każdy ping się udał. Procesy publikacji, które wysyłają ping i nigdy nie sprawdzają odpowiedzi, mogą miesiącami działać z uszkodzoną integracją (nieprawidłowy URL huba po migracji, reguła zapory blokująca wychodzące POST), zanim ktoś zauważy, że aktualizacje kanału przestały się rozchodzić. Zobacz Validation Tests, aby sprawdzić, co faktycznie należy kontrolować.

Uruchomienie własnego huba bez zabezpieczenia callbacków i dostarczania. Większość wydawców nigdy tego nie potrzebuje — hub Google lub wbudowany hub CMS-u wystarcza do zastosowania SEO. Jeśli jednak uruchamiasz własny hub (na przykład wewnętrzne narzędzie syndykacji), sekcja Security Considerations specyfikacji wskazuje realne ryzyka, które łatwo przeoczyć: hub bezkrytycznie pobierający lub wysyłający POST na dowolny URL podany przez klienta jest narażony na server-side request forgery (pobieranie adresów wewnętrznych/prywatnych), więc waliduj i ograniczaj adresy callback oraz tematu zgodnie z wytycznymi OWASP dotyczącymi SSRF. Nie obiecuj też subskrybentom dostarczenia dokładnie raz — ponowienia HTTP oznaczają, że callback może otrzymać tę samą dystrybucję treści więcej niż raz, dlatego implementacja subskrybenta powinna traktować dostarczanie jako co najmniej raz i deduplikować/przetwarzać je idempotentnie, a nie zakładać pojedynczy, czysty POST dla każdej aktualizacji.

Pinguj hub i potwierdź działanie

Bash / curl — ping z widocznym kodem statusu

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

Wydrukowane 204 lub 202 oznaczają, że hub przyjął powiadomienie. Każda inna odpowiedź (4xx/5xx albo błąd połączenia) oznacza, że ping nie dotarł — sprawdź URL huba i wartość hub.url kanału, zanim uznasz, że wszystko działa.

Python — ten sam ping do podłączenia do hooka publikacji

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}")

Wywołaj go zaraz po tym, jak CMS lub build witryny opublikuje nowy wpis — w tym samym momencie, w którym ponownie generujesz kanał. Można bezpiecznie wywoływać go przy każdej publikacji; ponowne pingowanie niezmienionego kanału niczemu nie szkodzi, tylko mówi hubowi, aby sprawdził go ponownie.

Udowodnij, że WebSub faktycznie zadziałał

Kontrole pass/fail po podłączeniu linku huba i pingu publikacyjnego. Są celowo etapowe: każda dowodzi tylko własnego kroku w łańcuchu wydawca → hub → subskrybent, a ostatni etap — faktyczne dostarczenie do subskrybenta i jego działanie — odbywa się poza Twoimi logami. Wydawca może bezpośrednio zweryfikować dwa pierwsze etapy, a trzeci wywnioskować z ponownego pobrania przez hub; nic w WebSub nie pozwala wydawcy potwierdzić, że konkretny subskrybent otrzymał lub przetworzył aktualizację.

Test: kanał ogłasza hub i siebie

• Test do wykonania: Wyświetl źródło kanału i poszukaj na poziomie channel/feed obu elementów <link rel="hub" href="..."> oraz <link rel="self" href="...">.
• Oczekiwany wynik: Oba tagi są obecne, a rel="self" odpowiada dokładnemu URL, pod który pobierasz kanał.
• Interpretacja porażki: Brak rel="hub" oznacza, że nie ma huba do pingowania; brak lub niezgodność rel="self" oznacza, że hub nie może wiarygodnie potwierdzić tematu, którego dotyczy ping.
• Okno monitorowania: Natychmiast — sprawdź od razu po każdej zmianie szablonu kanału.
• Wyzwalacz wycofania: Brakuje któregoś tagu albo rel="self" wskazuje inny URL niż ten pobierany przez wyszukiwarki.

Test: ping publikacyjny zwraca status sukcesu

• Test do wykonania: Wyślij ping (zobacz kartę Scripts) i odczytaj zwrócony kod HTTP.
• Oczekiwany wynik: 204 No Content lub 202 Accepted.
• Interpretacja porażki: 4xx zwykle oznacza źle sformatowane żądanie (błędne wartości hub.mode/hub.url) albo hub.url, którego hub nie rozpoznaje jako należącego do Ciebie; 5xx lub timeout oznacza niedostępność huba — ponów próbę, zanim uznasz problem za trwały.
• Okno monitorowania: Natychmiast — za każdym razem, gdy proces publikacji wysyła ping.
• Wyzwalacz wycofania: Powtarzające się odpowiedzi inne niż 2xx przy wielu publikacjach — to uszkodzona integracja, nie jednorazowe zakłócenie.

Test: hub faktycznie ponownie pobrał kanał

• Test do wykonania: Sprawdź w logach serwera żądanie Feedfetcher-Google (albo huba) do URL kanału wkrótce po udanym pingu.
• Oczekiwany wynik: Żądanie pobrania URL kanału w ciągu mniej więcej kilku minut od pingu.
• Interpretacja porażki: Ping 2xx bez następczego pobrania w logach sugeruje, że hub przyjął żądanie, ale nie potrafił rozwiązać lub osiągnąć kanału — sprawdź, czy URL jest publicznie dostępny i nie blokuje go robots.txt ani firewall.
• Okno monitorowania: W ciągu godziny od testowej publikacji; to najwolniejsza z tych kontroli, bo zależy od harmonogramu pobierania huba.
• Wyzwalacz wycofania: Po kilku kolejnych pingach wyglądających na udane nadal nie pojawia się pobranie — uznaj relację z hubem za niezweryfikowaną, dopóki logi jej nie potwierdzą.

Sprawdź się: WebSub

Pięć krótkich pytań o to, czym jest WebSub, jak działa i jakie ma ograniczenia. Wybierz odpowiedź na każde, a potem sprawdź wynik.

Dziennik zmian