したがって、ユーザー 1 が「http://www.facebook.com/index.php」にタイプし、ユーザー 2 が「http://facebook.com」にタイプし、ユーザー 3 が「www.facebook.com」にタイプする場合、どうすればよいですかこれらすべてが解決するものにそれらを「変換」するのが最善です: " http://www.facebook.com/ "
無効な URL を修正することで、ユーザー 3 を解決します。は URL ではありませんが、それが最初に表示されるはずだwww.facebook.com
と推測できます。http://
空のパスの部分はパスと同じな/
ので、それも最後に行く必要があると確信できます。優れた URL パーサーは、このビットを実行できるはずです。
URL に対して HTTP HEAD 要求を行うことで、ユーザー 2 を解決できます。のステータス コードが返された場合は、応答ヘッダー301
に実際の URL への永続的なリダイレクトがあります。Location
Facebook は にfacebook.com
トラフィックを送信するためにこれを行います。これwww.facebook.com
は間違いなく、サイトが行うべきことです (現実の世界では多くの場合そうではありませんが)。3xx
ファミリ内の他のリダイレクト ステータス コードに同じことを許可することを検討してください。これは実際には正しいことではありませんが、リダイレクトの302
代わりに使用するサイトもあります。301
時間とネットワーク リソース (さらに、自分や他のユーザーによる DoS による機能の悪用を防ぐためのコード) がある場合は、ターゲット Web ページを取得して解析することも検討できます (それが HTML ではないことが判明した場合)。ページに要素がある場合は、<link rel="canonical" href="..." />
その URL も適切なものとして扱う必要があります。(ソースを表示: スタック オーバーフローはこれを行います。)
しかし、残念ながら、ユーザー 1 のケースは解決できません。Facebook は のページ/
と のページを提供/index.php
しています。それらを見て同じであると言うことができますが、その関係を説明する技術的な方法はありません。理想的な世界では、Facebook は、301
リダイレクト レスポンスまたは特定のリソースにアクセスするための適切な形式の URL である(またはその逆)<link rel="canonical" />
を人々に伝えるために、いずれかを含めます。しかし、そうではありません。実際、ほとんどのデータベース駆動型の Web サイトも、まだこれを行っていません。/
/index.php
これを回避するために、一部の検索エンジン (*) は、異なる [サブ] ドメインのコンテンツを比較し、限られた範囲で同じホスト上の異なるパスも比較し、コンテンツが十分に類似している場合はそれらが同じであると推測します。もちろん、これには多くの作業が必要であり、多くのストレージと処理が必要であり、最終的には信頼性が低くなります。
user 3 の場合のように URL を修正する以外は、あまり気にしません。あなたの説明から、あなたが言及していない特定のユースケースがない限り、「同じ」ページが実際のアイデンティティを共有する必要があることはそれほど重要ではないようです.
(*: とにかく、Google です。より伝統的なものは、伝統的に同じページへの複数のリンクを喜んで提供しませんでした。