Apache「mod_rewrite」の設定方法
Apache「mod_rewrite」の設定方法
今回説明する「mod_rewrite」は、現時点でよく利用されているApacheのバージョン(1.3、2.0、2.2の3系統)のいずれでも利用可能です(ただし、同一表現でも挙動が変わるケースがあります。たとえば、バージョン2.x系で用いられる「index.html」を「/」に統一する表現を、バージョン1.3で利用すると無限ループしてしまいます)。
「mod_rewrite」では、正規表現を使ってURLをリライトするルールを記述できます。正規表現を利用できることで、かえって導入のハードルを高くしている印象も受けますが、SEOのためのURLの擬似静的化に関して言えば、正規表現を完全に把握していなくても設定可能です(もちろん技術者としては、正規表現は押さえておきたいところではありますが)。
実際に現在稼働中の大規模サイトでURLが一見静的に見えるサイトは、必ずと言っていいほど擬似静的化をしています。また、そのサイトのWebサーバーがApacheの場合には、そのほとんどが「mod_rewrite」モジュールで実装されているといっても過言ではないでしょう。他にPHPの「pathinfo」を使うこともあります。
ディレクティブ | 内容 |
---|---|
RewriteEngine | 「mod_rewrite」モジュールの動作を設定する。[ON/OFF]で指定 |
RewriteCond | Rewrite時の条件を設定(後述するRewriteRuleを条件付きで実施したい場合に利用する)
TestStringには、$N(RewriteRule一致)、%N(RewriteCond一致)、%{サーバー変数}などを指定できる。 CondPatternには、不等号(「!」で不等号が反対の意味に)、「-d」「-f」なども使える。 flagには、[NC](文字の大小を区別しない)、[OR](OR条件、指定がない場合は自動的にAND条件が適用される)などが指定できる。 サーバー変数の例
|
RewriteRule | URL書き換えの実行部分。使用する正規表現はPOSIX(Apache1.2以降)
Patternの先頭に記述する「/」は、ルールを記述する場所によって必要なケースと不要なケースがあります。うまく動かないときは「/」を削除してみましょう。 Patternでよく利用する正規表現
主に利用するflag
|
参考(Ver1.3):http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
IIS「ISAPI_Rewrite」の設定方法と注意点
IISの場合、「mod_rewrite」の代わりに、Helicon Tech社が提供している「ISAPI_Rewrite」というモジュールが利用可能です。
現在、Ver2系とVer3系があり、Ver3系は「mod_rewrite」とほぼ同じ記述での設定が可能です(「mod_rewrite」との互換リスト)。また、それぞれ有償版(1サーバー当たり99ドル)と無償版(無償版の制限)があります。
- Windows 2000 with IIS 5
- Windows XP with IIS 5.1
- Windows Server 2003 with IIS 6.0
- Windows Vista with IIS 7.0
- Windows Server 2008 with IIS 7.0
「ISAPI_Rewrite」のデフォルトの設定では、1点「mod_rewrite」と挙動が変わるものがあります。それはログファイルへの出力形式です。
「mod_rewrite」の場合、生ログにはリライト前のURLが記載されるのに対して、「ISAPI_Rewrite」の場合はリライト後のURLが記載されます。もし、「ISAPI_Rewrite」でリライト前のURLを確認したい場合には、下記の「U」オプションを付与してください。生ログでアクセス解析をしている場合などに有効なオプションです。
# U (Unmangle Log)
Log the URL as it was originally requested and not as the URL was rewritten.
参考:http://www.isapirewrite.com/docs/#RewriteRule
「mod_rewrite」や「ISAPI_Rewrite」を使用する際、このケースはリダイレクトを使用するべきかリライトを使用するべきか判断に迷うことがあるかもしれません。まずはこれらの挙動を整理してみましょう。
リダイレクトの挙動
ポイントは、クライアントがリクエストしたURLに対して、Webサーバーが「違う場所にあるよ」というステータスコードをクライアントに返している点です。この場合のクライアントには一般的なのブラウザーも含まれますが、もちろん検索エンジンのクローラーも訪れています。SEOの観点からいうと、検索エンジンはURL単位でページをインデックスしていくため、検索エンジンにページが移動したことを明示する場合にはこの方法(リダイレクト)を利用します。
参考:過去記事のステータスコードの項を参照
リライトの挙動
次にリライトの仕組みを説明します。ポイントは、クライアントがリクエストしたURLに対するコンテンツが異なる場所にあったとしても、それをクライアントに通知することなく、サーバー側で変換処理を行う点です。クライアントがリクエストしたURLがあたかも静的なURLだったとしても、実は裏側では動的なURLに変換処理するといった使い方ができます。URLの擬似静的化にはこの方法を利用しているのです。
いかがだったでしょうか。URLの擬似静的化に関しては、どうしても技術的な作業が伴うため、エンジニアに協力をしてもらう必要が出てくるでしょう。ただし、単純に仕様を変更するだけではなく、なぜ擬似静的化が必要なのか、リダイレクトとはどう違うのかなど、仕様変更によってどんな効果がもたらされるのかをWeb担当者と一緒に考えていけるといいかもしれません。
次回は、今回解説したURLの「静的化(擬似静的化)」を実現する設定ファイルの実例とSEOに効くサーバー設定のサンプル集をお届けします。
ソーシャルもやってます!