URLの擬似静的化で動的サイトをインデックスさせるには
スキルセットや共通言語が異なる
エンジニアとWeb担当者をつなぐための手引書
前回の記事では、URLの正規化ができていない実例をその対処法とともに示しました。URLの最適化シリーズ、3つ目のポイントは「URLの静的化」です。また、これまで解説してきたURL最適化のためのさまざまな取り組みにも関係してくる、Apacheの主要なモジュールである「mod_rewrite」の記述方法も併せて解説していきます。
- エンジニアさんへ
検索エンジンに対するクローラビリティが重要なのはこれまで述べてきたとおりです。クローラビリティ向上ためのURLの静的化を怠ってはいけません。今回の記事の対象者 - Web担当者さんへ
今回は技術的な説明が多く、実際に設定ファイルを操作できない場合もあるかと思います。リダイレクト関連の設定は一歩間違えると致命傷です。場合によっては、対策が必要かどうかの検討が必要になるでしょう。
動的URL、静的URLとは何か
URLには大きく分けて、動的URLと静的URLの2種類があります。
- 動的URL（ダイナミックURL）の例：
http://www.example.com/dir1/file.html?query1=param1 - 静的URL（スタティックURL）の例：
http://www.example.com/dir1/file/query1/param1/
その違いは、URL中に「?」「=」「&」などのパラメータが含まれているかどうかです。
SEOの世界では、コンテンツが動的に生成されるケース、つまり特定の条件に対するページが単一のHTMLファイルで用意されておらず、その都度データベースを参照して新たなページを生成している場合などであっても、URLにパラメータを含んでいなければ静的なURLとみなされます。もちろん、静的なURLであれば通常のインデックスに支障をきたすことはありません。
参考：動的URLとみなされるURL（Yahoo! サイトエクスプローラーヘルプ）
参考：動的URL VS 静的URL――SEO的には、やはり静的URLに軍配（SEOmoz）
検索エンジン側での動的なURLの取り扱い
上記をふまえて、検索エンジンに対する動的URL、静的URLの取り扱いを解説していくことにしましょう。SEOにおける動的URLの相性については、よく質問や議論になるポイントの1つです。最近では、検索エンジン側でも動的URLを処理するツールを公開しています。
サイトエクスプローラーの管理サイトに自分のサイトを登録すると、左側の「管理サイト詳細」に「動的URL設定」というメニューが表示されます。この設定を利用することで、検索エンジン（Yahoo!）に対して不要なクエリパラメータ（セッションID「jsessionid」など）を非表示に指定できます。また、そのクエリのパラメータを固定化することも可能です。
ただし、動的URLの設定はすべてのサイトに必要な操作ではありません。Yahoo! 検索のヘルプに詳しいので設定の際には一度ご確認ください。
一方、Googleの場合、動的URLと静的URLについて以下のようにまとめています。また、動的URLをどのように静的URLにすればよいかというサンプルも掲載されています。
- 動的URLもちゃんとクロールする（できるようになっている）
- 静的URLが多少有利なのは、エンドユーザーに対する可読性が高いから
- すでに動的URLでサイトを構成している場合は、無理に変更しなくてもよい（変更すると失敗する可能性があるから）
上記のようにYahoo! やGoogleでは動的URLに対して、「努力」してクローリングを行おうとしていることが理解できると思います。しかし、セッションIDのようなパラメータがURLに付加されてしまうと、検索エンジンがサイトをクロールするたびに異なるセッションIDを持つ同じページがたくさんクロール（クローラートラップ）されてしまいます。またURLにパラメータが多くなると、クローラー側の負荷が増大することなどを理由に、インデックスされないことがあります。
エンジニアなら積極的に疑似静的化を
では、この動的URL、静的URLの問題に対してエンジニアはどのように取り組めばいいのでしょうか。
Googleの説明にもあるように、確かにURLの擬似静的化（動的URLを静的URLへの変換すること）は技術要素が多いため、一般的なWeb担当者にとってはハードルが高いように思われます。しかし、技術者にとってみれば実にシンプルな要件ではないでしょうか。「動的URLのパラメータが1つくらいなら対策は必要ないだろう」と検索エンジン側の解析技術に依存せず、きっちり疑似静的化をしていきましょう。
Webサイトを何かのシステムで生成している場合、その多くはPHPやJava、ASPなどのプログラムで作成されているはずです。動的に生成されたURLを擬似的に静的なURLにしていくには、Apacheの場合は「mod_rewrite」、IISの場合は「ISAPI_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に効くサーバー設定のサンプル集をお届けします。
ソーシャルもやってます!