Webの俊敏性
ドキュメント

Webの俊敏性

概要

Triumphの「Web Agility」プラグインは、 ウェブサイトのSEO機能を向上させるための重要な機能を追加します。何より、Rockの 機能を活かして管理作業を簡素化できる点が最大の魅力です。これらのツールには、次のようなものがあります：

  • リダイレクトの設定– これにより、トラフィックを新しい場所へリダイレクトするためのルールを設定できます。これにより、リンクが切れないようにすることで、SEOの向上に役立ちます。また、かなり便利な機能も利用できるようになります。
  • XMLサイトマップ– 外部ウェブサイト用にサイトマップを用意することは、SEOにおけるもう一つのベストプラクティスです。動的なウェブサイトの場合、これは想像以上に難しい作業となります。このモジュールを使用すると、ウェブサイトをクロールして、サイトマップファイルを自動生成することができます。
  • レスポンスヘッダー– 「レスポンスヘッダー」モジュールを使用すると、ウェブサイトからのリクエストにレスポンスヘッダーを追加できます。これにより、キャッシュ戦略をきめ細かく制御できるほか、その他多くのユースケースにも対応できます。
  • リクエストヘッダー– 最後に、リクエストヘッダーモジュールを使用すると、ウェブサイトへの着信リクエストにリクエストヘッダーを追加することができます。

これらのツールについては、以下でそれぞれ詳しく説明します。

リダイレクター

Redirector モジュールを使用すると、 クライアントからのリクエストを完全に制御でき、リクエストの リダイレクトや変換を簡単に行うことができます。なぜこれが必要なのか、と疑問に思う方もいるかもしれません。この プラグインは多くのユースケースで非常に便利なツールですが、 特に注目すべき主な理由は、検索エンジン最適化（SEO）のためです。

ウェブサイトを移転したり変更したりする際は、 以前のリンクをすべて無効にしないことが重要です。これらのリンクは、 検索エンジン内だけでなく、さらに重要なことに、他のウェブサイトからのリンクとしても 引き続き存在し続けることを忘れないでください。「Redirector」プラグインを使えば、 古いリンクへのリクエストを検知し、 新しいURLへリダイレクトすることができます。

たとえば、以前のサイトにあるブログ記事へのリンクは、 次のようなものだったかもしれません：

http://www.mysite.com/blogs/youth/{post-title}

それを次の新しい場所へ簡単にリダイレクトすることはできません：

https://www.mysite/youth/blog/{post-title}

あるいは、たとえば、あなたのウェブサイトが「https://www.mysite.com」と「https://mysite.com」の両方に応答するが、 そのうちのどちらか一方だけをプライマリ（専門家の間では「カノニカル」とも呼ばれる）にしたい場合を考えてみましょう。 リダイレクタープラグインを使えば、すべての「www.」で始まるトラフィックをもう一方のアドレスにリダイレクトできます（ 必要に応じて、その逆も可能です）。

とはいえ、これは可能性のほんの一部に過ぎません。 この強力なプラグインのすべての機能を知るには、ぜひ読み進めてください。

設定

インストールが完了すると、このモジュールは「管理ツール > インストール済みプラグイン > Web Agility > リダイレクトルール」の下に表示されます。この リンクをクリックすると、設定済みのリダイレクトルールのリストが表示されます。

一般的に、ルールはできるだけ少なくしたほうがよいでしょう。 というのも、サーバーに届くリクエストごとに、それぞれのルールを処理する必要があるからです。とはいえ、 このプラグインのパフォーマンス（速度）を最大限に高めるよう、私たちは尽力してきました。

処理速度を向上させるために、無視するファイル拡張子を指定することができます。 たとえば、画像、CSS、JavaScript ファイルについては、通常、リダイレクトを追加する必要はありません。

技術的な詳細

ご興味のある方のために、内部で どのような処理が行われているかについて、さらに詳しくご紹介します：

  • Redirectorプラグインは、IIS内のHTTPモジュールとして動作します。つまり、Rockがその存在を認識するよりも前に、このプラグインがHTTPリクエストを受け取ることになります。これにより、URLがRockに届く前に、実際のURLを変更することが可能になります。
  • RedirectorはRockの外で動作するため、データベースから直接設定を読み取ることはできません。その代わり、設定は「App_Data」ディレクトリ内のJSONファイル（~/App_Data/RedirectorRules.json）に保存されています。
  • ルールはファイルに保存されていますが、処理速度向上のためメモリにもキャッシュされます。ルールや設定値を更新すると、このキャッシュはクリアされます。

リダイレクトルール

さっそく本題、つまりルールについて見ていきましょう。ルールは 以下の2つの部分に分かれています：

  1. 一致条件 – 特定のルールを有効にするために、Webリクエストのどの要素を確認すべきか。
  2. アクション – 一致が見つかった場合に実行するアクション。

これらの手順を一つずつ詳しく見ていき、 それぞれで利用可能な設定オプションについて確認していきましょう。

一致条件

リダイレクト処理の最初のステップは、 受信したリクエストが特定のルールに一致するかどうかを判断することです。一致する場合は、 そのアクションが実行されます。この一致判定ロジックは、非常に柔軟にカスタマイズ可能です。それでは、 どのようなことが可能か見ていきましょう。

ソースURLのパターン

主なマッチングロジックは、「受信URLの中で 何を探しているか」というものです。その文字列をここで指定します。なお、 URL全体（例：https://www.mysite.com/GroupViewer.aspx?Group=12）に対してマッチングを行う点に注意してください。

ソース比較タイプ

次に、パターンをURLにどのように照合するかを決定します。 選択肢は以下の通りです：

  • 「Starts With」 – URLは、指定した文字列で始まっていなければなりません。
  • 末尾 –URLは、指定した文字列で終わっている必要があります。
  • 「Contains」 – URLには、指定した文字列が含まれている必要があります。
  • 正規表現 – 一致の判定には正規表現が使用されます。このオプションを使用すると、アクション内で使用するURLの一部を抽出することも可能です。このオプションは非常に強力であるため、マニュアルの以下のセクションで詳しく解説しています。

マッチの構成要素

URLで何を探すべきかはわかりました。それでは、 さらに詳細な条件を設定しましょう。選択肢は以下の通りです：

  • URLのみ– これがデフォルトの設定です。この場合、照合ではURLのみが考慮されます。
  • URLとログイン状態– この場合、URLとユーザーのログイン状態（「ログイン中」または「未ログイン」）を照合します。ユーザーが誰であるかを把握しているかどうかに基づいて、異なるページへリダイレクトできるため、これは非常に強力な機能です。
  • URL および Referred– これにより、「Referrer」（意図的にスペルを間違えた「https://en.wikipedia.org/wiki/HTTP_referer」）HTTP ヘッダーの値に基づいて、さらにフィルタリングを行うことができます。この値は、そのドキュメントにリンクを張ったページのアドレスです。この設定を使用すると、リンク元となったページに基づいてリダイレクトを行うことができます。指定した値がリファラーに含まれている場合、その値と一致すると判定されます。
  • URL とユーザーエージェント– この設定により、ユーザーが使用しているブラウザに基づいてさらにフィルタリングを行うことができます。これは、ユーザーがサイトがサポートしていない非常に古いブラウザを使用している場合に対処するのに役立ちます。このような場合、そのユーザーを、サイトが当該の古いブラウザをサポートしていないことを通知するページにリダイレクトすることができます。

大文字と小文字を区別する比較

このオプションを使用すると、一致の判定において 大文字と小文字を区別するかどうかを設定できます。場合によっては、まさにこれが必要になることもありますが、 他の場合（実際にはほとんどの場合）は不要でしょう。いずれにせよ、 どちらのケースにも対応しています。

詳細設定

「詳細設定」の表示・非表示を切り替えるトグルに、お気づきの方もおられるかもしれません。 これらの設定を利用することで、ルールをさらに高度なものにすることができます。

IPアドレスフィルター

ルールを特定のIPアドレスを持つクライアントに限定することができます。たとえば、 キャンパス内やその他の既知のネットワークに所属する個人に対して、 特別なルールを設定したい場合などがあるでしょう。各ルールに対して、複数のIPフィルターを設定できます。これらのフィルターは、 いくつかの異なる形式に対応しています。最も一般的な形式を見てみましょう：

  • 単一のIPアドレス – 192.168.100.12
  • IPアドレスの範囲 – 192.168.100.1 – 192.168.100-255
  • ショートカット範囲 – 192.168.100.23～45
  • サブネットマスク – 192.168.100.1/255.255.255.0
  • CIDR表記 – 192.168.100.1/24
  • IPv6 - fe80::/10

クッキー

場合によっては、クッキーの有無に基づいてルールをフィルタリングしたいこともあるでしょう。 これにより、コード（Lava または C#）を使用して、ユーザーをルールの対象に含めるか除外するかを 設定できるようになります。

アクション

一致条件がわかったところで、 ルールが処理された際にどのような処理が可能かを見てみましょう。まず最初に 決定すべきことは、リダイレクトを行うか、リクエストをそのまま通過させるか、それともエラーを返すかです。 それぞれについて考えてみましょう。

リダイレクト

これが最も一般的な選択肢となります。指定された URL に基づいて、新しい URL へリダイレクトします。リダイレクトには、 いくつかの種類があります。

  • 301 永久リダイレクト– これがデフォルトの設定です。ブラウザ（またはGoogleの検索クローラー）に対して、ページが移動したことを通知し、新しいURLを指定します。これはSEOに優しい選択肢です。
  • Found 302– 302リダイレクトは、このリダイレクトが一時的なものであることをリクエスト元に伝えます。GETメソッドでのみ使用すべきです（リクエストのほとんどはGETです）。
  • 一時的なリダイレクト 307– 302と非常によく似ているため、少し紛らわしいかもしれません。これは、このリダイレクトがPOSTリクエストにのみ使用されるべきものであるためです。
  • 308 恒久リダイレクト – 301 と似ていますが、HTTP メソッドの変更が許可されます。

警告

リダイレクトを扱う際、Chromeは301リダイレクトをキャッシュするという点に注意する必要があります。このため、ルールのテストがやや難しくなり、予期せぬ結果につながる可能性があります。Chromeのリダイレクトキャッシュをクリアする方法については、こちらのブログ記事をご覧ください（https://salferrarello.com/chrome-clear-redirect-cache/）。

パススルー

このオプションでは、リダイレクトは一切行われません。その代わりに、 受信したURLを変更し、リクエストの処理を続行します。Rockにとっては、 元のリクエストのURLは最初から存在しなかったものとなります。Rockには、 変更された新しいURLのみが表示されます。

エラー

このオプションを使用すると、ルールに 一致した場合に HTTP エラーを返すことができます。このエラーは Rock に到達する前に処理されるため、 通常の Rock の 404 処理は実行されない点に注意してください。

対象URLパターン

アクションが「リダイレクト」または「パススルー」の場合は、 ターゲットURLパターンを指定する必要があります。これは、 ユーザーを遷移させたい新しいURLになります。なお、上記で正規表現によるマッチングを使用した場合、 元のURLの一部を利用してこのアドレスを動的に生成することができます。これについては、 以下の「ルールにおける正規表現」のセクションで説明します。

ルールにおける正規表現

リダイレクトルールに正規表現を組み合わせると、その威力は格段に高まります。 でも心配はいりません。それほど複雑にする必要はありません。ここでは、 最小限の労力で最大限の威力を引き出せるよう、十分な例を挙げていきます。

正規表現の構文

正規表現の構文については数多くの本が出版されており、 そのせいで頭を抱えて髪が薄くなってしまった人も大勢います。でも心配はいりません。 ここでは、最も一般的な使用例をまとめたチートシートをご紹介します。

まずは基本的なことをいくつか：

  1. . 「任意の文字」を意味する
  2. * 前の文字が任意の回数繰り返されることを意味する
  3. というわけで、 .* 任意の文字が任意の回数現れることを意味する
  4. URLでよく使われる「/」という文字は、必ず「\」でエスケープする必要がある点に注意してください。

ユースケース：groups または smallgroups で終わる URL を照合する

たとえば、以下のURLのいずれかと一致させたい場合を考えてみましょう：

  • http://www.mysite.com/smallgroups
  • http://www.mysite.com/groups

この式を使えばうまくいくはずです：

.*\/(groups|smallgroups)$

その論理は次のとおりです：

  • 何からでも始めてみましょう (.*)
  • 「Then」には以下の内容が含まれています。 / \/()
  • 「groups」または「smallgroups」が含まれている ( (グループ|小グループ) )
  • そして、その $ 「これは最後に置かなければならない」と言っている

ユースケース：末尾のスラッシュ（省略可能）との照合

たとえば、次のいずれかのURLに一致させたい場合を考えてみましょう：

  1. http://www.mysite.com/blog
  2. http://www.mysite.com/blog/

以下の式は、次のいずれかに一致します：

.*\/blog[\/]?$

その論理は次のとおりです：

  1. 何からでも始めてみましょう (.*)
  2. では、 /ブログ
  3. また、末尾にスラッシュを付けることも可能です ([\/])
  4. そして、その $ 「これは最後に置かなければならない」と言っている

ユースケース：SSL非対応のすべてのブログ記事の照合

暗号化されていないトラフィックをすべて、以前のブログから 自分のウェブサイトの新しいページに転送したい場合を想定します。その場合は、 次の式を使用できます：

http:\/\/.*\/blog\/.*

その論理は次のとおりです：

  1. http:// から始まる (http:\/\/)
  2. その場合、文字数は任意です (.*)
  3. それなら /blog/ があります (\/blog\/)
  4. その後、末尾まで任意の数の文字が続く (.*)

ソース情報の抽出

正規表現は一致条件の設定に役立ちますが、 ほとんどの場合、「先頭が～」「末尾が～」「～を含む」といった条件で、必要な結果が得られます。 しかし、正規表現が真価を発揮するのは、 ソースURLの一部を抽出して新しいターゲットURLに使用したい場合です。例えば、ブログサイトを 次のURLから移動させる場合：

https://www.mysite.com/blogs/youth/parenting-tips-for-grade-school → https://www.mysite.com/youth/blog/parenting-tips-for-grade-school

新しいURLで使用する投稿名を取得したいでしょう。 そのためには、キャプチャグループを作成します。これらのグループは、 正規表現の記述内で括弧を使って定義します。例えば、 ブログ投稿名を取得するには、次のような記述を使用します。

.*\/blogs\/youth\/(.*)

これにより、上記の最初のURLに一致し、ブログ 記事のタイトルが「取得」され、リダイレクト時に変数 $1 として使用されます。その結果、ターゲットとなるパターン URLは次のようになります：

https://www.mysite.com/youth/blog/1ドル

これにより、ソースURLのブログ記事のタイトルを、 リダイレクト先のURLに追加することができます。

キャプチャグループは1つだけに限定されるわけではなく、 実際には好きなだけ作成できます。例えば、何らかの理由でルールを httpまたはhttpsのどちらでも機能させ、リダイレクト後もプロトコルを 維持したい場合（現在の「httpsのみ」が主流の環境ではベストプラクティスとは言えませんが、仮にそうしたいとしましょう）。その場合は、 次のようなパターンを使用できます：

ソースURLのパターン (http|https).*\/blogs\/youth\/(.*)

ターゲットパターン $1://www.mysite.com/youth/blog/$2

URLから「www.」を削除する

たとえば、サイトのすべてのURLから「www.」を削除したい場合を想定しましょう。 ウェブサイトは1つのURL（https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs）にのみ応答するように設定するのがベストプラクティスです。

ソースURLのパターン (http|https):\/\/www\.mysite\.com(.*)

ターゲットパターン https://mysite.com$2

このパターンでは、常に https を使用したいので、基本的に最初の キャプチャグループを無視している点に注目してください。

サイトマップ XML

サイトマップは、検索エンジンが あなたのウェブサイトをより適切にインデックスできるようにするための不可欠なツールです。基本的には、サイト上のすべてのページの一覧であり （検索エンジン向けの「 cheat sheet（参考資料）」のようなものと考えてください）。これは一見、 作成が簡単なファイルのように思えるかもしれませんが……しかし……動的なウェブサイトが主流となった現代では、実際には かなり難しい作業なのです。 というのも、Rockでは1つのページが、訪問者にとっては数百、あるいは数千もの ページとして表示されることがあるからです。例えば、「メッセージシリーズ」のページはRock上では1つのページですが、 これまでに実施したすべてのシリーズの名称やアートワークを動的に読み込んでいます。

Web Agilityプラグインには、 選択したRockサイトのサイトをクロールしてsitemap.xmlファイルを生成するジョブが用意されています。以下に そのジョブ設定のスクリーンショットを示します。

設定

以下に、この仕事の各設定について一覧を示します。

  • サイト – サイトマップを作成したいウェブサイト。
  • ファイルを圧縮– ジョブでサイトマップをgzip形式で圧縮するかどうかを指定します。サイトマップのサイズが大きい場合は、この設定を行うことを推奨します。
  • ログインIDとパスワード– これらの設定では、クローラーがサイト内のページを検索する際に使用するユーザー名とパスワードを指定できます。通常、検索エンジンは見つけたページにアクセスできないため、これらの設定を使用することはありませんが、必要に応じて利用可能です。

結果

ジョブが実行されると、サイトマップは 「~/Content/Sitemaps/site-3-sitemap.xml」に保存されます。なお、「3」は、 ジョブで選択したサイトのサイトIDです。ファイルを圧縮するように設定した場合は、 「.xml」の後に「.gz」が追加されます。

このファイルのURLを、お好みの検索 エンジンに送信できるようになりました。詳細については、以下の記事をご覧ください： https://yoast.com/help/submit-sitemap-search-engines/

設定のヒント

ここでは、サイトでのインデックス登録を設定するためのヒントをいくつかご紹介します。 

  1. サイト - インデックスに追加したい各サイトを、以下の場所で有効にしてください 管理ツール > CMSの設定 > サイト. サイトの「詳細設定」を編集して、インデックス登録を許可してください。
  2. 各ページ - また、以下の設定で個々のページのクロールを設定することもできます。 管理ツール > CMS設定 > ページ > ページ設定 > 詳細設定
  3. コンテンツチャンネル - ページに動的コンテンツが含まれている場合は、関連するコンテンツチャネルをインデックス登録用に有効にする必要があります。これを確認するには、以下のページにアクセスしてください。 管理ツール > CMS設定 > コンテンツチャンネル 内部サイト内で、チャンネルの詳細を確認します。

サイトマップとrobots.txtファイル

サイトマップファイルを共有するもう1つの方法は、Webサーバーのルートフォルダにある robots.txt ファイルにそれを組み込むことです。問題は、Web サーバーにはこれらのファイルを1つしか置けず、1つのファイルが表せるのは1つの ウェブサイトのみであるという点です（Rockでは、サーバーサイトやマイクロサイトをホストできることをお忘れなく）。ご安心ください。 私たちは、両方のメリットを享受できる方法、つまり動的な robots.txt ファイルを用意しました！

動的ロボットファイルは、必要に応じて作成されます。その仕組みは 次のとおりです：

1. Redirector プラグインで「動的ロボットファイル」を有効にします。

2. これにより、 /robot.txt へのすべてのリクエストが、 バックグラウンドで動作するカスタム REST API にリダイレクトされます。

3. この REST APIは、URLを解析してRock内のサイトと照合します。その後、 「~/Contents/」フォルダ内にある 「site-3-sitemap.xml(.gz)」ファイルを探し出し、そのサイト用のrobot.txtファイルを作成します。

鋭い洞察力を持つウェブマスターの中には、 「robot.txt ファイルにはサイトマップ以外にもさまざまな要素があるはずだ。 ファイルに追加したい他のルールはどうすればいいのだろうか？」 と考えている方もいるかもしれません。 ええ、私たちも その点は考慮しました……プラグインのインストール時に、Rock上のサイトに「Robot Rule」 属性も追加しました。この属性に追加した内容はすべて、 動的なrobot.txtにも反映されます。

ヒント

以下の「レスポンスヘッダー」のセクションには、サイトマップに関するその他のコツがいくつか紹介されています…

レスポンスヘッダーモジュール

「Response Header」モジュールを使用すると、訪問者のWebブラウザに 返されるHTTPレスポンスオブジェクトにヘッダーを追加することができます。これは あまり面白く聞こえないかもしれませんが、実際には便利な用途があります。 レスポンスヘッダーは、Web上のキャッシュを機能させる上で重要な役割を果たします。Rockでは 多くの場所でこれらのヘッダーを調整できますが、Rockでは ヘッダーを提供できない領域もいくつかあります。このモジュールを使用すると、強力なルールを作成して これらのキャッシュヘッダーを追加することができます。これは、Webサイトにコンテンツ配信 ネットワーク（CDN）を導入する際に非常に役立ちます。

設定

インストールが完了すると、このモジュールは「管理ツール > インストール済みプラグイン > Web Agility > レスポンスヘッダー規則」の下に表示されます。このリンクをクリックすると、 設定済みの規則の一覧が表示されます。

ルールをクリックすると、そのルールの 詳細ページが表示されます。

ヘッダールールの設定について分析してみましょう。

  1. 名前 – ルールの表示名。
  2. 「アクティブ」 – これがどういう意味かは、一目瞭然ですよね？
  3. 一致条件
    1. ソースURLパターン– これは、ヘッダーを追加すべきかどうかを判断するためにURLを評価する際の一致パターンです。
    2. ソース比較タイプ – これは、一致の評価方法を決定します。ここでのオプションには、以下のものがあります：
      1. 「～から始まる」
      2. 「で終わる」
      3. 内容物
      4. 正規表現
    3. 大文字と小文字を区別する比較– URLの比較において、大文字と小文字を区別するかどうかを指定します。
  4. ヘッダーの設定
    1. ヘッダー名– ヘッダーの名前。
    2. ヘッダー値– ヘッダーの値。
    3. 既存の値を上書きする– 多くの場合、ヘッダーがモジュールに到達する時点で、そのヘッダーはすでに存在していることがあります。この設定により、ヘッダーが存在する場合にその値を上書きするかどうかを指定できます。

例

よくあるユースケースの例としては、Webサーバー上の静的画像へのリクエストに キャッシュヘッダーを追加することが挙げられます。そのための正規表現パターンは 次のようになります：

(https?:\/\/.*\.(?:png|jpg|gif|svg))

その場合は、「Cache-Control」というヘッダーを追加し、 その値を「public max-age=3600」のような形式に設定します。

サイトマップの見出し

サイトマップをさらに強力にするためのボーナスヒント… サイトマップ では、ページに関する追加情報を記載することができます。これには、 ページの更新頻度や、そのページがサイトにとってどれほど重要かといったヒントが含まれます。 ページにヘッダーを追加することで、サイトマップにこれらのプロパティを 記載できるようになりました。以下に、Rock固有のヘッダーに関する詳細を記載します：

  • x-更新頻度 – このヘッダーの有効な値には、以下のものがあります：
    • いつも
    • 時間単位
    • 毎日
    • 週刊
    • 月次
    • 年次
    • 決して
  • x-priority– 0.0 から 1.0 までの小数で指定できます。1 は「非常に重要」を意味します（デフォルトは 0.5）。

リクエストヘッダーモジュール

「リクエストヘッダーモジュール」を使用すると、 受信するHTTPリクエストにヘッダーを追加することができます。このモジュールは、 前のセクションで説明した「レスポンスヘッダーモジュール」と ほぼ同じように動作し、ルールや設定オプションも同様であるため、 ここでは簡単に説明するにとどめます。

設定

インストールが完了すると、このモジュールは「管理ツール > インストール済みプラグイン > Web Agility > リクエストヘッダー規則」の下に表示されます。この リンクをクリックすると、設定済みの規則の一覧が表示されます。ここでの 規則の設定方法は、前の セクションで説明した規則と全く同じです。唯一の違いは、 これらのヘッダーが、送信される HTTPレスポンスではなく、受信するHTTPリクエストに追加されるという点です。