WebSubとSEO

TL;DR — WebSub は、購読者がフィードを確認しに来るのを待つ代わりに、公開時に購読者へ通知する方法です。サイトに RSS または Atom フィードがある場合にのみ機能します。フィードを「ハブ」に指定すると、公開時にサイトがハブに ping を送り、ハブが更新を購読中のサービスに配信します。一部のブログプラットフォームはこれを自動的にサポートしています。

WebSub とは

通常、検索エンジンは戻って確認することで新しい投稿を見つけます。つまり、独自のスケジュールで定期的にサイトマップや RSS フィードを再読み込みします。WebSub はこれを逆転させます。公開ボタンを押した瞬間に、サイトは「新しいものがあります」という小さなメッセージを送信し、それが待機中の検索エンジンに中継されます。

以前は PubSubHubbub（本当にそう呼ばれていました）と呼ばれていました。2017 年に WebSub に改名され、公式のウェブ標準になりました。どちらの名前も同じ意味で、Google のシステムはどちらでも動作します。

知っておくべきこと

WebSub は RSS または Atom フィードでのみ機能します。サイトの任意のページを Google にプッシュする方法ではありません。フィードに含まれない通常のページについて検索エンジンに ping を送りたい場合は、別のツール（Bing の場合は IndexNow、Google の場合は URL Inspection ツール）を使用します。

また、ディスカバリのすべてと同様に、WebSub は検索エンジンがコンテンツについて知るのを早めるだけです。ページがクロール、インデックス、ランク付けされることを保証するものではありません。これらは依然として別のステップです。

設定する必要がありますか？

おそらく手動で設定する必要はありません。WordPress（プラグインを使用）、Blogger、またはほとんどのホスト型プラットフォームで公開している場合、WebSub は組み込まれているか、プラグインを追加するだけで、Google の公開ハブにすでに接続されています。頻繁に公開するサイトにとっては便利な機能であり、すべての人にとって必須というわけではありません。

プロトコルの詳細、Google の正確な見解、WebSub と IndexNow の比較を知りたいですか？ Advanced タブに切り替えてください。

TL;DR — WebSub（旧 PubSubHubbub。2018 年 1 月に W3C 勧告となり、2026 年 6 月にセキュリティに焦点を当てた更新で再確認）は、RSS/Atom の プル に対する プッシュ の補完です。パブリッシャーはフィード内でハブを宣伝し（<link rel="hub">）、購読者はそのハブに登録し、公開時にパブリッシャーがハブに ping を送信して、更新されたフィードをすべての購読者に配信します。検索サービスは購読できますが、WebSub 自体は、検索エンジンが URL をクロールまたはインデックスすることを保証しません。これはフィードなどのトピックリソース向けに設計されており、一般的なインデックス API ではありません。参加している検索エンジンにとって、IndexNow は別の URL 通知プロトコルです。また、2025 年半ばの時点で、Bing は独自のニュースフィード提出プログラムの新規登録も停止しており（詳細は後述）、選択肢はさらに狭まっています。

WebSub はフィードのプッシュ側

Discovery ハブでは、ディスカバリを プル と プッシュ に分けています。RSS/Atom フィードはプルチャネルです。エンジンは独自の周期でフィードをポーリングします（たとえば、Google の Feedfetcher は、ほとんどのフィードを約 1 時間に 1 回以上は取得しません）。WebSub は、そのプルをプッシュに変えるものです。再取得を待つ代わりに、公開した瞬間にフィードが変更をブロードキャストします。

それが価値提案のすべてです。次のスケジュールされたポーリングを待つのではなく、フィード更新のほぼリアルタイムの通知です。

PubSubHubbub と WebSub — 同じプロトコル、異なる名前

これはドキュメント検索で人々を混乱させます。このプロトコルは元々 PubSubHubbub（略称 PSH）と呼ばれていました。2017 年 10 月に WebSub に改名され、2018 年 1 月に W3C 勧告として公開されました。2018 年より前の記事は「PubSubHubbub」、2018 年以降の記事は「WebSub」と表記されています。これらは同じものであり、Google のハブは今でも両方に対応しています。これは改名時に John Mueller が確認したことです（“Yes, finally dug it up! We support both.”）(翻訳) 「はい、ようやく見つけました！ 両方サポートしています。」

仕様自体も2018年以降、静止しているわけではありません。W3Cは2026年6月2日にWebSubを新しい勧告として再発行し、セキュリティ考慮事項のセクションにクロスサイトスクリプティング（XSS）対策を追加しました。これはセキュリティ強化の更新であり、メカニズムの変更ではありません。以下で説明するアクター、ディスカバリー関係、購読/公開フローは2018年版と同じプロトコルです。WebSubを実装（単に利用するだけでなく）する場合は、2018年のテキストのコピーではなく、現在の勧告を読んでください。

WebSubの実際の仕組み

アクターは3つあります：

• パブリッシャー — あなたのサイト（具体的にはフィード）。
• ハブ — 購読とファンアウトを処理するリレーサーバー。
• 購読者 — 更新を必要とする検索エンジン（または任意のクライアント）。

W3C仕様はフローを明確に説明しています：“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.” (翻訳) 「購読者はトピックURLのハブを発見し、トピックが変更されたときに更新を受け取るために、宣伝された1つ以上のハブにPOSTを行います。パブリッシャーはトピックが変更されたときにハブのURLに通知します。ハブがトピックの変更を検出すると、登録済みのすべての購読者にコンテンツ配信通知を送信します。」

実際には、SEOの観点では：

1. フィードは <link rel="hub" href="..."> タグ（およびフィード自身のURLを指す <link rel="self" href="...">）でハブを宣伝します。
2. 購読者（検索エンジン）は、そのハブにフィードを登録します。
3. 公開すると、サイトはフィードが変更されたことをハブに通知します。
4. ハブは更新されたフィードを取得し、各購読者のコールバックURLへのHTTP POSTを介して全員にファンアウトします。

ステップ2は「登録」という言葉が示す以上に多くの作業を行っています。仕様は購読を別々の状態に分割しています：購読リクエスト、ハブが購読者が実際にトピックを望んでいることを確認する検証ステップ（誰も他人のコールバックURLを許可なく購読できないように）、購読が保持する期限付きのリース、およびそのリースが期限切れになる前に購読者が行わなければならない更新（永続的な購読というものはありません）— さらに明示的な購読解除パスもあります。これらはどれも、パブリッシャーとしてあなたが管理するものではありません。ハブと購読者の間のハンドシェイク側です。しかし、それが存在することを知っておく価値はあります。なぜなら、「ハブにpingを送った」と「検索エンジンが私のフィードにアクティブな購読を持っている」は、別々に失敗し得る2つの異なることだからです。

ステップ3も、ほとんどのWebSubの解説が示すほど標準化されていません。仕様自体は*“the specific mechanism for the publisher to inform the hub is left unspecified,”* と述べており、例として、Googleを含む一部の公開ハブが hub.mode=publish と hub.url を変更されたフィードに設定した POST を受け入れることだけを注記しています。この慣習は実際には十分に普遍的で、「ハブにpingを送る」と「hub.mode=publish をPOSTする」は事実上同義語です—しかし、これは例として文書化された広く採用された慣習であり、勧告の厳格な要件ではありません。

W3C仕様は技術的にはフィードよりも広く、任意の HTTPリソースを運ぶことができます—しかし、Googleのドキュメントはその推奨をAtom/RSSフィードに限定しています。仕様は広く、SEOのユースケースは狭いです。

WebSubとGoogle

Googleのサポートは公式に記録されており、Build a Sitemap ドキュメントにあります：“If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” これは単一の従属節です—GoogleはWebSubに独自のセクションを与えていません—しかし確認されています。

Googleのハブは pubsubhubbub.appspot.com にあり、Googleがサービスとして運営しています—2026年7月18日時点でまだ稼働して応答していることを確認しました。それがフィードで宣伝し、公開時にpingを送るハブです。コミュニティハブも存在しますが、歴史的にGoogleのものよりも耐久性が低い傾向があります—フィードをコミットする前に、検討しているサードパーティのハブが実際にまだ応答しているかどうかを確認し、動作すると言う古いブログ投稿を信頼しないでください。

舞台裏のクローラーは Feedfetcher（Feedfetcher-Google）で、Google が Google ニュースや WebSub 向けに RSS/Atom フィードをクロールする方法です。Feedfetcher 自身のドキュメントにある重要なニュアンスの一つは、“only podcast feeds get indexed in Google Search” という点です。つまり、通常のブログフィードでは、WebSub は Google がフィードの更新を 認識 するのを加速しますが、各ページの実際のインデックスは、Googlebot がフィード 内 の URL を通常のクロール → インデックスのパイプラインを通じて追跡することによって行われます。WebSub は発見を加速するものであり、インデックスの近道ではありません。

WebSub と Bing

Bing の文書化された WebSub スタイルのサポートは、Bing News PubHub の下にありました。つまり、ニュース/フィードに限定されており、Google の Feedfetcher パスがニュースとポッドキャストに向いているのと並行しています。しかし、PubHub 自体は縮小傾向にあります。Microsoft は 2025 年 6 月 に PubHub への 新規 パブリッシャー申請の受け付けを停止し、Bing News を手動申請ではなく、適格なニュースコンテンツを自動的に識別してランク付けする方向に移行すると述べています。それ以前に承認されたパブリッシャーはインデックスに残りますが、新規申請者向けの申請ポータルは閉鎖されています。これは、手動ニュース申請のプログラムレベルの廃止であり、IndexNow の変更ではありません。

一般的なウェブページ を Bing にプッシュするには、適切なツールは WebSub や PubHub ではなく IndexNow です。IndexNow は、Bing（および Yandex、Naver、Seznam、Yep）が任意の URL に対して好むリアルタイムプッシュであり、PubHub の変更の影響を受けません。特に、Google は IndexNow に参加していません（このレビューの時点で indexnow.org 自身の参加者リストで確認済み）。したがって、明確な分割は次のとおりです。フィードには WebSub（Google のハブが実用的な選択肢）、それをサポートするエンジンには一般的なページに IndexNow を使用します。

WebSub の実装方法

ステップ 1 — フィードでハブを宣伝する。 ハブリンクとセルフリンクを追加します。最も一般的な形式は、フィード自体に埋め込むことです。

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

Google のハブは、埋め込みタグの代わりに、フィードリクエストの HTTP レスポンスヘッダーとして同等のものも受け入れます。これは、フィードの XML を直接制御できない場合（たとえば、サードパーティのフィードジェネレーター）に役立ちます。

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

どちらの形式も、サブスクライバーに同じことを伝えます。どのハブに登録するか、そしてこのフィード自身の正規 URL が何かということです。2 番目の部分は、フィードを移動する場合に重要です。古い URL を HTTP リダイレクトで新しい URL にポイントし、仕様に従って、リースを更新するサブスクライバーはリダイレクトをたどって新しいハブ/セルフのペアを自動的に取得し、静かに古くなることはありません。

ステップ 2 — 公開時にハブに ping を送信する。 公開モードとフィード URL を指定してハブ URL に POST します。これは、Google のハブ（および他のほとんどのハブ）が期待する広く使用されている規約であり、上記で説明したとおりです。

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

実際には、CMS が両方のステップを処理します。 WordPress の PubSubHubbub プラグインはデフォルトで Google のハブを使用します。Blogger、WordPress.com、Medium は WebSub をネイティブにサポートしています。カスタムサイトの場合は、公開 ping を公開フローに組み込みます。

検証 — ただし、実際に確認している内容を理解してください。 ハブからの 2xx は、ハブが 通知を受け入れた ことだけを証明します。サブスクライバーがそれを受け取ったことを証明するものではなく、パブリッシャーとしてその最後のホップを直接観測することは通常できません。自分の側で確認できること：テスト投稿を公開し、ハブが ping に対して 2xx を返すことを確認し、その後すぐにサーバーログで Feedfetcher-Google がフィードにアクセスするのを確認します。これにより、ハブが再フェッチしたことが確認され、パブリッシャー側の検証はここまでです。完全な段階的な内訳（フィードマークアップ、ping レスポンス、ハブの再フェッチ）と、それぞれが何を証明し、何を証明しないかについては、検証テスト レンズを参照してください。

WebSub が ない もの

いくつかの誤解を解消しておきましょう：

• ページを即座にインデックスするわけではありません。 フィードの更新をハブに通知するだけです。 Googleは通常のプロセスを通じて各URLをクロールし、インデックスします。
• 任意のページには対応していません。 フィードのみです。フィード以外のURLには、 IndexNow（Bing）またはURL Inspection（Google）を使用します。
• サイトマップの代わりにはなりません。 WebSubとサイトマップは補完関係にあります。サイトマップは サイト全体をカバーし、WebSubはリアルタイムのフィード変更をプッシュします。Googleは両方を推奨しています。
• Googleのハブは非推奨ではありません。 pubsubhubbub.appspot.com はアクティブで、Googleが運営しています。 2026年7月18日時点で稼働を確認済みです。BingのPubHubは別の話です： 2025年6月に新しいパブリッシャー申請の受け付けを停止しました（上記のWebSubとBingを参照）。 そのため、そのページがまだ存在していても、オンボーディングの経路として扱わないでください。

実際に恩恵を受けるのは誰か

高頻度で公開するパブリッシャー（ニュースサイト、ポッドキャスト、鮮度が重要なサイト）は、 WebSubから最も恩恵を受けます。月に数回しか公開しないサイトでは、通常のフィードポーリングと適切な内部リンクに比べて、 速度向上はわずかです。プラットフォームが対応しているなら、デフォルトで有効にするのが賢明です。 単独で大掛かりなカスタムエンジニアリングをする価値はほとんどありません。

URLがどのように発見されるかの全体像については、Discoveryハブを参照してください。 URLが発見された後の処理については、Crawlingを参照してください。

AIまとめ

Advancedバージョンの簡潔な見解:

• WebSub = RSS/Atomのプッシュ側。 フィードは通常、エンジンのスケジュールでプルされます。 WebSubは公開した瞬間に変更をブロードキャストします。
• 旧称はPubSubHubbub（PSH）。2017年10月に改名、2018年1月にW3C勧告。 2026年6月にXSSセキュリティ対策を追加して再公開されましたが、プロトコルの仕組みは同じです。 Googleは両方の名前をサポートしています（John Mueller: “We support both.”）。
• 3つのアクター： パブリッシャー → ハブ → サブスクライバー。フィード内でハブを宣伝し （<link rel="hub"> + <link rel="self">、または同等のHTTP Linkヘッダー）、 公開時にハブに通知します（Googleのハブと他のほとんどのハブは hub.mode=publish POSTを使用します。これは文書化された慣例であり、仕様要件ではありません）。 ハブはフィードをサブスクライバーに配信します。各サブスクライバーは個別に検証され、 期限付きで更新可能なサブスクリプションを保持していました。
• Googleはサポートしています： “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” Googleのハブ： pubsubhubbub.appspot.com（2026年7月18日に稼働確認済み）。Feedfetcherがクロールを実行します。 その経路では*“only podcast feeds get indexed in Google Search”* であることに注意してください。
• 2つの厳しい制限： フィードのみ（任意のページは不可）、および発見のみ（ クロールやインデックスの保証はありません）。ハブへのpingが成功しても、サブスクライバーへの配信の証明にはなりません。 ハブ自身の再取得までしか確認できません。
• Bing： WebSubスタイルのサポートはニュース限定のPubHubにありましたが、 2025年6月に新しいパブリッシャーの登録受付を停止しました。一般的なページには、IndexNowが Bingのプッシュ手段であり、これは影響を受けません（GoogleはIndexNowに参加していません）。
• サイトマップの代わりにはならず、即時インデックスでもありません。 ほとんどのCMS（WordPressプラグイン、 Blogger、Medium）は自動的に処理します。高頻度のパブリッシャーに最適です。

公式ドキュメント

一次情報のドキュメントとプロトコル仕様。

Google

• サイトマップの作成と送信 — GoogleがWebSubを文書化している唯一の場所: 「AtomまたはRSSを使用している場合、WebSubを使用して変更を検索エンジン（Googleを含む）にブロードキャストできます。」
• Feedfetcher — WebSubトリガーのフェッチの背後にあるクローラー。この経路ではポッドキャストフィードのみがGoogle検索にインデックスされることに注意。
• GoogleのWebSubハブ — 広告とpingを送信する、Googleが運営するライブの公開ハブ。
• RSS/Atomフィードを使用した新しいURLの発見（2009年） — GoogleのPubSubHubbubサポートを紹介した画期的なSearch Centralの投稿。

Bing / Microsoft

• Bing News PubHubサポート — Bingのフィード/ニュースに特化したガイダンス。ページはまだ存在しますが、Microsoftは2025年6月に新しいPubHubパブリッシャー申請の受け付けを停止しました。
• IndexNow / indexnow.org — 一般的な（フィード以外の）URLに対するBingの推奨リアルタイムプッシュ。PubHubの変更の影響を受けません。

標準

• WebSub — W3C勧告 — プロトコル仕様。2018年1月からW3C勧告であり、2026年6月2日にセキュリティ考慮事項のXSS緩和策（ハブ、サブスクライバー、パブリッシャー、コンテンツ配信）を含めて再公開されました。

ソースからの引用

GoogleとW3C仕様からの公式声明。各リンクは、ソースページの引用箇所にジャンプするディープリンクです。

Google — WebSubサポート

• “If you use Atom or RSS, you can use WebSub to broadcast your changes to search engines, including Google.” (翻訳) 「AtomまたはRSSを使用している場合、WebSubを使用して変更を検索エンジン（Googleを含む）にブロードキャストできます。」 — Google Search Central、サイトマップの作成。 引用にジャンプ
• “Google accepts RSS 2.0 and Atom 1.0 feeds.” (翻訳) 「GoogleはRSS 2.0およびAtom 1.0フィードを受け入れます。」 引用にジャンプ

Google — Feedfetcher（WebSubの背後にあるクローラー）

• “Feedfetcher is how Google crawls RSS or Atom feeds for Google News and WebSub.” (翻訳) 「Feedfetcherは、GoogleがGoogleニュースとWebSubのためにRSSまたはAtomフィードをクロールする方法です。」 — Googleクローラーとフェッチャーのドキュメント。 引用にジャンプ

W3C — プロトコルの仕組み

• “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.” (翻訳) 「サブスクライバーはトピックURLのハブを発見し、トピックが変更されたときに更新を受け取るために、宣伝されている1つ以上のハブにPOSTを送信します。パブリッシャーはトピックが変更されたときにハブのURLに通知します。ハブがトピックの変更を検出すると、登録されているすべてのサブスクライバーにコンテンツ配信通知を送信します。」 — W3C WebSub勧告。 引用にジャンプ

John Mueller、Google (PubSubHubbubからWebSubへの名称変更について、2017年9月)

• “Yes, finally dug it up! We support both.” — Googleが「WebSub」と以前の「PubSubHubbub」の両方の名称をサポートしていることを確認。 (翻訳) 「はい、ようやく見つけました！両方サポートしています。」 Search Engine Roundtableの2017年9月の報道を通じて伝えられたもの。元のツイートは直接アクセスできなくなっているため、これは逐語的なソースではなく、帰属として扱ってください。

WebSub公開チェックリスト

• 公開された安定した公開URLを持つ有効なRSSまたはAtomフィードを公開する。
• フィードのマークアップに、hubリレーションとフィードのselfリレーションの両方を追加する。
• アイテムの公開または更新後、変更されたフィードURLをアドバタイズされたhubに送信する。
• hubがリクエストを受け入れたことを確認し、次にログからhubがフィードを取得したことを確認する。
• フィードを認証なしで到達可能に保ち、通常の成功レスポンスを返す。
• ピングをクロール、インデックス、ランキングの証明ではなく、ディスカバリー通知として扱う。

公開 → 通知 → 取得のフレームワーク

WebSubを三者間のハンドオフと考えてください：

1. パブリッシャー： フィードを更新し、アドバタイズされたhubにどのフィードが変更されたかを通知する。
2. ハブ： 通知を受け入れ、購読者に配信する。
3. 購読者： 通知を受け取り、フィードを取得するかどうかを決定する。

各境界には個別の証拠が必要です。公開ピングの成功は、hubが通知を受け入れたことのみを証明します。hubからのサーバーログリクエストは、フィードが取得されたことを証明します。どちらも、検索エンジンがアイテムURLをクロールしたり、インデックスに追加したりしたことを証明するものではありません。この分離により、ディスカバリーの失敗がインデックスの失敗として誤診されるのを防ぎます。

WebSub — クイックリファレンス

必須のフィードマークアップ（フィードの<head>/チャンネルレベルのタグ内の両方の要素）

公開ピング

hub.mode の値

• publish — パブリッシャーが送信する値（慣例による。Googleのhubや他のほとんどのhubが使用する。仕様自体はパブリッシャー通知メカニズムを未指定のままにしている）。hubに「このトピックが変更されたので、再取得してください」と伝える。
• subscribe / unsubscribe — これらは仕様で定義されており（W3C勧告、hub.mode必須パラメータ）、トピックの更新を登録または登録解除する購読者によって使用され、それぞれhubの検証と更新可能なリースが必要です。検索エンジンはこれを自社側で処理します。あなたが送信する必要はありません。

豆知識

• Googleの公開hub：pubsubhubbub.appspot.com — 2026年7月18日に稼働確認済み。
• WebSubはフィードのみ（RSS/Atom）で機能します — 任意のページでは機能しません。
• リアルタイムプッシュをサポートするエンジンの一般的な（非フィード）URLについては、それはWebSubではなくIndexNowです。Bingの別のPubHubニュース提出プログラムは、2025年6月に新規登録の受付を停止しました。
• 2017年10月にPubSubHubbubからWebSubに改名。2018年1月からW3C勧告であり、2026年6月2日にセキュリティのみの緩和策を加えて再公開されました。同じプロトコルで、両方の名前がGoogleのhubに対して引き続き機能します。

WebSubを静かに壊す間違い

hubをアドバタイズしてもrel="self"リンクをアドバタイズしない。 hubは両方のタグを必要とします — rel="hub"は購読者を送信する場所を知るため、rel="self"はピングがどのフィードURLを参照しているかを正確に確認するためです。hubリンクのみを配信すると、一部のhub実装ではピングをフィードに確実に一致させることができません。

間違ったhub.urlでピングする。 値はフィード自身のURL（rel="self"リンクと同じもの）でなければなりません — サイトのホームページでも、個々の投稿URLでも、トラッキングパラメータが追加されたURLでもありません。hub.urlが一致しない場合、hubはトピックを検証できず、ピングは何も行いません。

WebSubがサイトマップを置き換えると期待する。 サイトマップはサイト全体の包括的なマップです。WebSubは、あなたがすでにアドバタイズしたフィードへの変更のみを常にブロードキャストします。サイトマップを削除すると、そのフィードに含まれないすべてのものに対するエンジンのマップを失います。

「インデックスされた」という意味でpingを期待すること。 ハブからの2xx成功レスポンスは、ハブが通知を受け入れ、フィードを再取得することを意味するだけです。Google（または他の誰か）がフィードがリンクするページをクロール、レンダリング、またはインデックスしたかどうかについては何も示していません — これらは別々のパイプラインステージです。

フィードに含まれていないページにWebSubを使おうとすること。 WebSubは、pingを送信したフィード内にあるものだけを対象としています。フィード外の一回限りのページ更新には、WebSubは何も提供できません — それはIndexNow（Bingなど）またはGoogleのURL Inspectionツールの役割です。

すべてのpingが成功したと暗黙に信頼すること。 pingを送信してレスポンスを確認しない公開パイプラインは、統合が壊れた状態（移行後のハブURLの誤り、送信POSTをブロックするファイアウォールルール）で数ヶ月間、フィードの更新が伝播しなくなっていることに誰も気づかないままになる可能性があります。実際に確認すべき内容については検証テストを参照してください。

コールバックと配信の堅牢化なしに独自のハブを運用すること。 ほとんどのパブリッシャーはこれを必要としません — GoogleのハブやCMSに組み込まれたハブでSEOのユースケースはカバーされます。しかし、独自のハブ（例えば内部シンジケーションツール）を立ち上げる場合は、仕様のセキュリティ考慮事項が、素朴な実装が見逃す実際のリスクを指摘しています：クライアントが渡す任意のURLを盲目的にフェッチまたはPOSTするハブは、サーバーサイドリクエストフォージェリ（内部/プライベートアドレスのフェッチ）にさらされるため、OWASPのSSRFガイダンスが説明するようにコールバックとトピックURLを検証して制限してください。また、サブスクライバーに厳密に一度だけの配信を約束しないでください — HTTPリトライはコールバックが同じコンテンツ配信を複数回受け取る可能性があるため、サブスクライバー側の実装は配信をat-least-onceとして扱い、更新ごとに単一のクリーンなPOSTを想定するのではなく、冪等に重複排除/処理する必要があります。

ハブにpingを送信して動作を確認する

Bash / curl — ステータスコードを表示してpingを送信

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

204または202が返ってきたら、ハブが通知を受け入れたことを意味します。それ以外（4xx/5xx、または接続失敗）はpingが届かなかったことを意味します — 動作したと想定する前に、ハブのURLとフィードのhub.url値を確認してください。

Python — 公開フックに組み込むための同じping

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

CMSまたは静的サイトビルドが新しい投稿を公開した直後にこれを呼び出してください — フィード自体を再生成するのと同じタイミングです。毎回の公開で呼び出しても安全です。変更されていないフィードに再pingしても害はなく、ハブに再チェックを指示するだけです。

WebSubが実際に発火したことを証明する

ハブリンクと公開pingを配線した後の合格/不合格チェック。これらは意図的に段階的に構成されています：各チェックはパブリッシャー → ハブ → サブスクライバーのチェーンにおける自身のステップのみを証明し、最後のホップ — ハブが実際にサブスクライバーに配信し、そのサブスクライバーがそれに基づいて行動すること — はあなたのログの外で完全に発生します。パブリッシャーは最初の2つのステージを直接検証し、ハブ自身の再取得から3番目を推測できます。ここ（またはWebSubのどこでも）でパブリッシャーが特定のサブスクライバーが更新を受信または処理したことを確認できるものはありません。

テスト：フィードがハブと自身をアドバタイズする

• 実行するテスト： フィードURLのソースを表示し、チャンネル/フィードレベルで<link rel="hub" href="...">と<link rel="self" href="...">の両方を探します。
• 期待される結果： 両方のタグが存在し、rel="self"がフィードを取得する正確なURLと一致すること。
• 失敗の解釈： rel="hub"がない場合は、そもそもpingを送信するハブがないことを意味します。rel="self"がないか不一致の場合は、ハブがpingがどのトピックを参照しているかを確実に確認できないことを意味します。
• 監視ウィンドウ： 即時 — フィードテンプレートを変更した直後に確認してください。
• ロールバックトリガー： どちらかのタグがない、またはrel="self"が検索エンジンが実際に取得するURLと異なるURLを指している場合。

テスト: 公開ピングが成功ステータスを返す

• 実行するテスト: ピングを送信し（スクリプトレンズを参照）、HTTP ステータスコードを読み取ります。
• 期待される結果: 204 No Content または 202 Accepted。
• 失敗の解釈: 4xx は通常、不正なリクエスト（不正な hub.mode/hub.url 値）またはハブがあなたのものとして認識しない hub.url を意味します。5xx またはタイムアウトは、ハブ自体に到達できないことを意味します。永続的な障害と判断する前に再試行してください。
• 監視期間: 即時 — 公開フローがピングを発火するたびに。
• ロールバックのトリガー: 複数の公開にわたって 2xx 以外の応答が繰り返される場合 — それは一時的な問題ではなく、統合の破損です。

テスト: ハブが実際にフィードを再取得する

• 実行するテスト: 成功したピングの直後に、サーバーログで Feedfetcher-Google（またはハブの）リクエストがフィード URL に対して行われたか確認します。
• 期待される結果: ピングからおおよそ数分以内にフィード URL へのフェッチリクエストが行われること。
• 失敗の解釈: ログにフォローアップフェッチがない 2xx ピングは、ハブがリクエストを受け入れたものの、フィードを解決または到達できなかったことを示唆します。フィード URL が公開的に到達可能であり、robots.txt やファイアウォールでブロックされていないことを確認する価値があります。
• 監視期間: テスト公開から 1 時間以内。これはハブ自身のフェッチスケジュールに依存するため、これらのチェックの中で最も遅いものです。
• ロールバックのトリガー: 成功したように見えるピングが連続して何度か続いた後もフェッチが表示されない場合 — ログが確認するまでハブの関係は未検証として扱います。

自分で試す: WebSub

WebSub とは何か、どのように機能するか、そしてその限界がどこにあるかについての 5 つの簡単な質問です。それぞれ答えを選んでから、確認してください。

変更履歴