私が働いている会社では、新しいWebサイトを設計する準備ができており、クリーンなURLを作成する方法について意見の相違があります。過去1年にわたり、Poor Man's Clean URLs™が関係する大規模な再設計を見越して、既存のWebサイトを少し改善しています。
例:http://www.example.com/products/widgets/index.php
http://www.example.com/products/sprockets/index.php
新しいサイトについては、mod_rewriteの使用に関するいくつかの話があります。
http://www.example.com/products/widgets/
をリクエストしますhttp://www.example.com/index.php?page=products/widgets
に送信しますhttp://www.example.com/products/widgets.php
に送信しますこのリガマロールがどのように価値を高めているのか見逃しています。 mod_rewriteを支持する従業員は、ディレクトリの数が少ないほど保守が容易になると主張しています。
既存のページでは、クエリ文字列の変数を使用していません。すべてのコンテンツは、実際のファイル自体にあります。プレスリリースや今後の見本市などのコンテンツをデータベースに入れる予定ですが、ページの大部分は、ヘッダー、フッターなどの一般的なHTMLを含めるためにPHPのみを使用します。ナビゲーション。そのような動的コンテンツにmod_rewriteを使用することは間違いありません。
すべてにmod_rewriteを使用する必要があるという、見落としている大きな利点はありますか? Poor Man's Clean URLs™は、サイトのデータベース以外の部分に十分ですか?
上記で概説した3ステップのプロセスは、上記のように冗長で役に立たないようです。手順3でindex.phpが「実際の」ページに移動する場合、なぜmod_rewriteに煩わされるのでしょうか?これを行うと、mod_rewriteが提供する利点が無効になります。すなわち、検索エンジンに優しいURLと簡単なサイトのメンテナンス。ステップ2で停止する場合、mod_rewriteの利点は、ページを1つだけ維持することであり、実質的に無制限のページ数を提供し、ステップ1でURLのみを表示するため、ユーザーおよび検索エンジンに対して透過的です。
「/ pagename」または「/pagename.htm」は、「/ pagename.php」よりも検索エンジンに適しているという神話です。少なくともGoogleでは、これには根拠がまったくありません(他のユーザーも同様に想定しています)。同様に、「index.php?page = pagename」でさえ「/ pagename」として書き換える必要はありません。検索エンジンは問題なくこれらのURLを理解でき、Googleはユーザーが書き換えないことを好むという記録にまで達しました。不必要に( http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html )。そのため、URLパラメーターを使用して無限URLを作成しない限り、書き換えられたURLは、書き換えられていないURLよりも検索エンジンにとって使いやすいとは限りません。
ただし、ユーザーはusersい/複雑なURLよりも素敵なURLを好む場合があります。検索結果にニースURLが含まれていることが主な懸念である場合は、Googleが現在サポートしているブレッドクラムのマイクロフォーマット( http://googlewebmastercentral.blogspot.com/2010/09/rich-snippets- testing-tool-improvements.html )これらは多くの場合、検索結果のURLに関するより優れたユーザーエクスペリエンスを提供できるためです。これは、見栄えの良いURLをリンクしたいユーザーの問題を解決しませんが、URLが無限に複雑でなければ(そしてあなたの例はそうではありません)、そのためにそれらを書き直しても、おそらく測定可能な違いは生じません使用事例。測定可能な違いがない場合、そのようなセットアップの設計と保守に時間を費やすことはおそらく意味がありません。
「Poor Man's Clean URLs」と呼ぶものは、ファイルシステムを介して実装されたクリーンURLです。 mod_rewriteを使用せずに2番目のタイプのURLを使用できるように、mod_rewriteを使用してこれらのタイプのURLを使用できます。
クリーンURLとは、その名前が示すとおり、クリーンなURLまたはクリーンに見えるURLです。両方
http://yoursite/foo/bar
そして
http://yoursite/foo/bar.php
きれいなURLです。 「クリーンURL」という用語は、特定の実装を指定するものではありません。必要に応じて、サイトが更新されるたびにキャッシュされた.htmlページを生成することにより、クリーンなURLを実装できます。 mod_rewriteを使用すると、リダイレクトやフレームなしでURL構造をファイル構造から簡単に分離できます。
どうやら、あなたは現在データベース駆動型のサイトを運営していません。技術的には動的なWebサイトとして認定されるかもしれませんが、ヘッダー/フッターを含めるためだけに主にPHPを使用している場合は、おそらく静的な範囲に収まっています。更新がほとんど必要ない小規模なサイトではこれで問題ありませんが、サイトが大きくなるにつれて、実際のCMSを実装する必要があります。
Mod_rewriteが輝くのは、保守性を考慮し始めるときです。 (多くの冗長コードを含む)製品ページごとに数百のphpファイルを用意する代わりに、すべてのリクエストを処理する単一のスクリプトを用意することができます。ただし、実際の.phpファイルと表示されたWebページの1対1のマッピングがなくなった場合は、mod_rewriteなどを使用して、ファイル/ディレクトリ構造の錯覚を維持しながらページリクエストをインテリジェントにルーティングする必要があります。そこ。
したがって、心配する必要があるのは追加のサブディレクトリではありません。サイトのすべてのページに個別の.phpスクリプトを作成しているという事実です。
「クリーンURL」は、多くの場合、ファイル拡張子がないことを意味します。実装の詳細をビューアから隠すのに役立ちます。その利点は、サイトをたとえばPHPからRuby on Railsに移動することにした場合、単一のURLを変更せずに移動できることです。
現在、ASP.netでサイトを実行し、URLをそのままにしたい場合は.phpで終わるファイル名を使用することは可能ですが、問題が発生しないようにそれらを実行する方が理にかなっているようです。
http://www.example.com/news/2010/10/our-new-url-system/
基盤となるアーキテクチャを完全に変更したり、静的ファイルから動的ファイルに変更したり、またはその逆を行ったりしても、常に適切なURLになります。
既に述べたように、.php
または?page=
を持っていることは実際には重要ではありません。 does問題は、次のようなことをしている場合です。
http://www.example.com/index.php?page=13
データベース内のすべてのコンテンツは、更新が必要になるたびに大規模なファイルシステムを掘り下げて管理する方がはるかに高速で簡単であるように思えます。 John Muellerが前述したように、Nice URLはランキングに大きな違いをもたらすことはありませんが、Mod_Rewriteを使用して既存のURLとその値を保持することを検討する必要があります。 IE次の場合:
example.com/widgets/index.phpはそれを指すリンクが1,000個あり、それをexample.com/pages/widgets.phpに変更すると、その値の多くを失う危険性があります(もちろんリダイレクトできますが、同じ値を渡すかどうか)
静的コンテンツの提供を継続している場合はファイルシステムを使用し続け、動的コンテンツに変換する場合はMod_Rewriteを使用して現在のURL構造をそのまま維持することをお勧めします。または、現在の構造を維持できない場合は、Mod_Rewriteを使用して、将来の更新に対して安定する構造を作成します。