PubSubHubbubでGoogleインデックス数が急増した

運営しているリリースチェッカーについて、RSSフィードの生成時にGoogle PubSubHubbub Hubにpublishするようにしたところ、Googleのインデックス数が急増した。

search console

リリースチェッカーは、指定したキーワードに関するAmazonの新着商品フィードを配信するサービスだ。生成されたフィードはフィードリーダーでの購読に使われるのみで、配信元ページがGoogleにインデックスされる契機はこれまでなかった。

SEOについて考えていたとき、PubSubHubbubの存在をふと思い出し、試しに実装してみたらうまくいった。もちろん、検索結果への表示回数もインデックス数に比例して増えている。

フィード動的生成サービスの運営者は少ないだろうが、publishしない手はないと思う。実装も簡単だ。下記の通りPOSTするだけ。

  • Whenever new content is added to a feed, notify the hub. This is accomplished by sending a POST request to https://pubsubhubbub.appspot.com/ with Content-Type: application/x-www-form-urlencoded and two parameters encoded in the body:
    • hub.mode equal to publish
    • hub.url equal to the feed URL of the feed that has been updated. This field may be repeated to indicate multiple feeds that have been updated

スマホとマイナンバーカードで医療費控除の還付申告をした

PCでの試行錯誤を含め、2時間ほどかかってしまった。スマホのブラウザで国税庁 確定申告書等作成コーナーを開いて進めたら、わりとすんなり。次回はサクサク進められそう。去年はたまたま家族の医療費が多かっただけなので、次回がいつかになるか分からないけれど。

フロントエンドはサーバサイドと同じ轍を踏むか

下記の記事で考えていた「移植性の高いWebアプリのアーキテクチャパターン」や「Fat Controllerをコードで防ぐ方法」は、サーバサイドを主に扱ってきた経験に基づくものだ。

ただ、あらためて考えてみれば、サーバサイドでHTMLを組み立てるアーキテクチャパターンそのものが、Webアプリの移植性を低めている元凶なのだろう。気を抜けばビューロジックがコントローラに漏れ出すし、多くの場合テンプレートエンジン依存のビューテンプレートファイルが大量に作られるし、いざ移植したくなったときには、相当な労力が必要になりがちだ。

となれば、サーバサイドをAPIに特化させるのが一案だろう。APIに特化させれば、少なくともサーバサイドにおいては、ビューテンプレートファイルを作らなくてよくなる。

なんだか、汚いものをフロントエンドに押し付けているようで気が引けなくもないが、ちょうどよいことに、昨今ではサーバサイドをAPIに特化させるのが当たり前になってきている。これは、ブラウザ・Android・iOSなど、さまざまなプラットフォームでアプリを提供するのに適しているからだ。

そうなると、今度はフロントエンド側の移植性が気になってくる。たとえば、Nuxt.jsからNext.jsに乗り換えたい、みたいなニーズがあるのかどうか、あるとしたら労力はどのくらいなのか、といったことだ。

そのあたりの感覚はフロントエンドの経験を積まなければわからない。サーバサイドが生んできたいわゆる技術的負債をフロントエンドも生んでいくことになるのか、もうすでに生みまくっているのか、はたまた、優秀なエンジニアたちが日々返済してくれているのか。ぼくが気にすることではないのかもしれないが、でも気になる。


少し探したら下記の記事が見つかった。「強く依存しているライブラリやツールを減らす」といった表現が出てくる。やはりサーバサイドと同じ轍を踏んでいるようだ。とはいえ、あきらめずに返済を進めているのがすばらしい。

プロフィール
Web開発者。現在の関心事はシステム品質の改善(特に性能効率性と保守性)。JAPAN MENSA会員。
カテゴリ別アーカイブ
記事検索