URLの末尾にスラッシュを使用する必要があるのはいつですか？

末尾のスラッシュはいつURLで使用する必要がありますか？たとえば、私のURLは次の/about-us/ようになり/about-usますか？

私はSEO関連の問題を完全に認識しています-重複するコンテンツと正規のもの; 私はページを一人で正しく提供するという文脈でどちらを使用すべきかを理解しようとしています。

たとえば、私の同僚は、末尾のスラッシュが「フォルダ」-「ディレクトリ」であることを意味していると考えているため、これは正しいスタイルではありません。しかし、最後にスラッシュがないと思います-フォルダーのように見えるので、どちらも正しくありませんが、通常のファイルではなく、拡張子のないファイル名です。

どちらを使用するかを知る適切な方法はありますか？

私の個人的な意見では、末尾のスラッシュは誤用されています。

基本的に、URL形式は、ファイルとフォルダの同じUNIX形式から、後でDOSシステムで、最後にWebに適合したものです。

Unixライクなオペレーティングシステムでのこの本の一般的なURLは、file：///home/username/RomeoAndJuliet.pdfなどのファイルパスであり、ローカルハードディスクのファイルに保存されている電子書籍を識別します。

出典：Wikipedia：Uniform Resource Identifier

もう1つの優れたソース：ウィキペディア：URIスキーム

1994年にURLを定義したRFC 1738によると、リソースに他のリソースへの参照が含まれている場合、それらは相対リンクを使用して、「次のものを除いて、このリソースと同じ場所で」と言うかのように2番目のリソースの場所を定義できます。道"。さらに、そのような相対URLは、相対リンクの基準となる階層構造を含む元のURLに依存しており、ftp、http、およびファイルURLスキームは、 「/」で区切られた階層のコンポーネント。

出典：Wikipedia Uniform Resource Locator（URL）

また：

それがよく聞かれる質問です。答えに進んでください！歴史的に、URLの末尾にスラッシュが付いている場合はディレクトリを示し、スラッシュが付いていない場合はファイルを示します。

http://example.com/foo/（末尾のスラッシュ、通常はディレクトリ）

http://example.com/foo（スラッシュなし、従来はファイル）

出典：Google WebMaster Central Blog-スラッシュするかしないか

最後に：

1. URLの最後のスラッシュは、アドレスを「きれい」に見せます。

2. 末尾にスラッシュがなく、拡張子のないURLは、「奇妙」に見えます。

3. CSSファイルに（たとえば）http://www.sample.com/stylesheet/という名前を付けることはありませんか？

しかし、私は環境に関係なく、ウェブのベストプラクティスを支持しています。extのないURLについて述べたように、それは不安定で不明瞭な場合があります。

それは好みの問題ではありません。/baseと/base/セマンティクスが異なります。多くの場合、違いは重要ではありません。ただし、相対URLがある場合は重要です。

• childに対する相対/base/です/base/child。
• child相対的/baseです（おそらく驚くべきことです）/child。

非ディレクトリURL（特にWordPressなど）で末尾のスラッシュが頻繁に使用されていることにいつも驚いています。リソースの後にスラッシュを置くことは意味的に間違っているので、これは本当にどちらかまたは議論であってはなりません。Webはアドレス可能なリソースを配信するように設計されており、それらのアドレス（URL）は* nixスタイルのファイルシステム階層をエミュレートするように設計されています。その文脈では：

• スラッシュは常にディレクトリではなく、ファイルを示します。
• ファイルの名前は（拡張子の有無にかかわらず）何でもかまいませんが、スラッシュを含めたり、スラッシュで終わることはできません。

これらのガイドラインを使用すると、ディレクトリ以外のリソースの後にスラッシュを置くのは間違っています。

それは本当に美学の問題ではありませんが、確かに技術的な違いです。それを考えるディレクトリは完全に正しく、ほとんどすべてを説明しています。それを解決しましょう：

あなたは今石器時代に戻っているか、静的なページのみを提供しています

Webサーバーには固定のディレクトリ構造があり、画像やhtmlなどの静的ファイルのみがあり、サーバー側のスクリプトなどはありません。

ブラウザが要求し/index.htm、それが存在し、クライアントに配信されます。その後、あなたはたくさんの-言いましょう-DVDムービーをレビューし、/dvd/ディレクトリにそれらのそれぞれのhtmlページを表示します。これで誰かがリクエストし/dvd/adams_apples.htm、そこにあるので配信されます。

ある日、誰かがちょうど要求します/dvd/- これはディレクトリであり、サーバーは何を配信するかを理解しようとしています。アクセス制限などの他に、2つの可能性があります。ユーザーにディレクトリのコンテンツを表示する（すでにこれをどこかで見たことがあると思います）か、デフォルトのファイルを表示します（Apacheでは次のとおりですDirectoryIndex: sets the file that Apache will serve if a directory is requested.）。

これまでのところ、これは予想されるケースです。それはすでに処理の違いを示しているので、それを見てみましょう：

午前5時34分にファイルのアップロードに失敗しました

（ちなみにこれは完全に理解できます。）それで、あなたは何か間違ったことをして、アップロード/dvd/the_big_lebowski.htmする代わりに、そのファイルをdvd（拡張子なしで）にアップロードしました/。

誰かが/dvd/ディレクトリリストをブックマークし（もちろん、作成したくないし、常にその気の利いたものを更新したくありませんでしたindex.htm）、あなたのWebサイトにアクセスしています。ディレクトリコンテンツが配信されます-すべて問題ありません。

誰かがあなたのリストを聞いて入力しています/dvd。そして今、それはねじ込まれています。サーバーは、DVDディレクトリリストの代わりに、その名前のファイルを見つけ、Big Lebowskiファイルを配信しています。

したがって、そのファイルを削除して、ページをリロードするように指示します。サーバーは/dvdファイルを探しますが、存在しません。ほとんどのサーバーは、その名前のディレクトリがあることに気づき、探していたものが実際にどこか別の場所にあることをクライアントに伝えます。おそらく応答は次のようになります。

Status Code:301 Moved Permanently と Location: http://[...]/dvd/

したがって、ディレクトリやファイルについてのあなたの考えを完全に無視して、サーバーはそのようなものだけを処理でき、別様に指示されない限り、「スラッシュかどうか」の意味について決定します。

最後にこの応答を受け取った後、クライアントがロードされ/dvd/、すべてが正常です。

元気？番号。

「大丈夫」では十分ではない

すべてが渡され/index.phpて処理される動的なページがあります。今まではすべてうまくいきましたが、全体が遅く感じ始め、調査します。

間もなく、/dvd/listまったく同じことを実行していることに気づくでしょう。リダイレクト先/dvd/list/は、内部的にに変換されindex.php?controller=dvd&action=listます。1つの追加の要求-しかし、さらに悪いことです！customer/loginにリダイレクトしcustomer/login/、次にのHTTPS URLにリダイレクトしますcustomer/login/。あなたは持っ終わるトン遅くユーザーエクスペリエンスを作る不要なHTTPリダイレクト（=追加の要求）のを。

ほとんどの場合、ここにもデフォルトのディレクトリインデックスがあります。内部的にロードするだけindex.php?controller=dvdではありません。actionindex.php?controller=dvd&action=list

概要：

• それで終わる場合は、ファイルにする/ことはできません。サーバーの推測はありません。

• スラッシュまたはスラッシュなしは完全に異なる意味です。「スラッシュまたはスラッシュなし」の間には技術/リソースの違いがあり、それを認識し、それに応じて使用する必要があります。サーバーがロードする可能性が最も高いので、/dvd/index.htmまたは正しいスクリプトをロードします/dvd。どちらだったでしょう/dvd/。

• 実際にスラッシュバージョンが意味する場合でも、スラッシュを省略すると、追加のHTTPリクエストペナルティが発生します。これは常に悪いことであり（モバイルのレイテンシを考えると）、「かなりのURL」よりも重みがあります。特に、クローラーはSEOが信じるほど、または信じてほしいほど馬鹿ではないためです;）

あなたのURLを作るときは/about-us/（末尾のスラッシュで）、それは単一のファイルで始めるのは簡単ですindex.htmlし、後でそれを拡張し、複数のファイルを（たとえば、追加しour-CEO-john-doe.jpgて（例えば下の階層の構築にも）や/about-us/company/、/about-us/products/必要に応じて、など）をすることなく、公開されたURLを変更する。これにより、柔軟性が大幅に向上します。

ここでの他の回答は、末尾のスラッシュを省略することを支持するようです。末尾のスラッシュが検索エンジン最適化（SEO）に役立つケースが1つあります。それはあなたの文書がそうではないファイル拡張子のように見えるものを持っている場合です.html。これは、Webサイトを評価しているサイトで問題になります。次の2つのURLから選択できます。

• http://mysite.example.com/rated.example.com
• http://mysite.example.com/rated.example.com/

このような場合は、末尾にスラッシュが付いているものを選択します。それは.com拡張子がWindows実行可能コマンドファイルの拡張子であるためです。検索エンジンやウイルスチェッカーは、そのようなメカニズムを通じて配布されたマルウェアを含んでいる可能性があるURLを嫌います。末尾のスラッシュは問題を緩和するようで、ページを検索エンジンでランク付けし、ウイルスチェッカーで取得できるようにします。

.ファイル部分にURLがない場合は、簡単にするために末尾のスラッシュを省略することをお勧めします。

ファイル名に拡張子が必要なのは誰ですか？* nixマシンをいつか見てみ
てください... 私はあなたの友達に同意します。末尾にスラッシュはありません。

SEOの観点からは、URLの末尾にスラッシュを含めるかどうかの選択は重要ではありません。最近では、ウェブ上で両方の例を見るのが一般的です。サイトはどちらの方法でもペナルティが課されることはなく、この選択がWebサイトの検索エンジンのランキングやその他のSEOの考慮事項に影響を与えることもありません。

好みのURL命名規則を選択し、<head>各Webページのセクションに正規のメタタグを含めてください。

検索エンジンは、末尾のスラッシュの有無にかかわらず、1つのWebページを2つの別個の重複したURLと見なすことがexample.com/about-us/ありexample.com/about-usます。

他のサイトがURLにリンクする方法を制御できないため、各ページに正規のメタタグを含めることをお勧めします。

正規タグは次のようになります<link rel="canonical" href="https://example.com/about-us" />。正規のメタタグを使用すると、他のWebサイトがサイトにリンクするときに末尾にスラッシュが含まれているかどうかに関係なく、検索エンジンが各URLを1回だけカウントすることが保証されます。