URLの末尾にスラッシュを付けるのはいつですか？
末尾のスラッシュは、いつURLで使用する必要がありますか？たとえば - 私のURLは/about-us/のように表示されるべきですか、それとも/about-usのように表示されるべきですか？
私はSEO関連の問題、つまり重複した内容と標準的な問題について十分に認識しています。私はページを正しく提供するという文脈の中でどれを使うべきかを単独で使うべきかを考えています。
たとえば、私の同僚は、末尾の末尾のスラッシュが "フォルダ" - "ディレクトリ"を意味すると考えているため、これは正しいスタイルではありません。しかし、私はそれをスラッシュなしでは終わらないと思います - それはフォルダのように見えるのでそれもかなり正しくありません、しかしそれはまた普通のファイルでもなく、拡張子のないファイル名です。
どちらを使用するかを知る適切な方法はありますか？
私の個人的な意見では、末尾のスラッシュは誤用されています。
基本的にURLフォーマットはDOSシステム上のファイルとフォルダの同じUNIXフォーマットから来て、そして最後に、ウェブに適応しました。
Unixライクなオペレーティングシステムでのこの本の典型的なURLは、file：///home/username/RomeoAndJuliet.pdfのようなファイルパスです。これは、ローカルハードディスクのファイルに保存されている電子本を識別します。
ソース： ウィキペディア：Uniform Resource Identifier
読むべきもう一つの良い情報源： Wikipedia：URI Scheme
1994年にURLを定義したRFC 1738によれば、リソースが他のリソースへの参照を含んでいるとき、それらは相対リンクを使って2番目のリソースの場所を「あたかも次の相対を除いてこの場所と同じ場所で」定義できます。パス"。そのような相対URLは、相対リンクの基礎となる階層構造を含む元のURLに依存し、ftp、http、およびファイルURLスキームは、階層と見なすことができるいくつかの例です階層の構成要素は "/".で区切られています
ソース： ウィキペディアのURL
また：
それがよく聞かれる質問です。答えへ！歴史的に、末尾にスラッシュがあるURLはディレクトリを示し、末尾にスラッシュがないものはファイルを示すのが一般的です。
http://example.com/foo/ （末尾のスラッシュ付き、通常はディレクトリ）
http://example.com/foo （末尾のスラッシュなし、通常はファイル）
ソース： Google WebMaster Central Blog - 切り捨てないまたは切り捨てない
最後に：
URLの最後にスラッシュを付けると、アドレスは「きれい」に見えます。
末尾にスラッシュがなく、拡張子がないURLは、やや「奇妙」に見えます。
あなたはあなたのCSSファイルに名前をつけることは決してないでしょう（例えば） http://www.sample.com/stylesheet/ でしょうか？
しかし、私は環境に関係なくWebのベストプラクティスの支持者です。あなたが内線なしでURLについて述べたのと同じように、それは厄介で不明瞭になることがあります。
それは好みの問題ではありません。 /baseと/base/は意味が異なります。多くの場合、違いは重要ではありません。しかし、相対URLがある場合は重要です。
/base/に対する相対的なchildは/base/childです。/baseに対する相対的なchildは（おそらく驚くべきことに）/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 am、ファイルのアップロードを間違えました
つまり、まったく間違ったことをしたので、そのファイルを/dvd/the_big_lebowski.htmに（拡張子なしで）dvdとしてアップロードしたのではなく、/をアップロードしました。
誰かがあなたの/dvd/ディレクトリリストをブックマークし（もちろん、あなたはその賢いindex.htmを作成して常に更新したくはありませんでした）、あなたのウェブサイトを訪問しています。ディレクトリコンテンツが配信されます - すべて問題ありません。
誰かがあなたのリストを聞いて、/dvdと入力しています。そして今それはねじ込まれています。 DVDディレクトリの一覧の代わりに、サーバーはその名前のファイルを見つけ、Big Lebowskiファイルを配信しています。
それで、あなたはそのファイルを削除して、その人にそのページをリロードするように言います。サーバーは/dvdファイルを探しますが、なくなりました。ほとんどのサーバーは、その名前のディレクトリがあることに気付き、探しているものが実際には別の場所にあることをクライアントに伝えます。ほとんどの場合、応答は次のようになります。
Status Code:301 Moved PermanentlyとLocation: http://[...]/dvd/
そのため、youがディレクトリやファイルについて考えるものを完全に無視しても、サーバーはそのようなものしか扱えず、別の言い方をしない限り"＃：。
最後にこのレスポンスを受け取った後、クライアントは/dvd/をロードし、すべて問題ありません。
大丈夫ですか？いいえ.
「晴れ」はあなたにとって十分ではありません
すべてが/index.phpに渡されて処理される動的ページがあります。今まではすべてうまくいっていましたが、その全体が遅く感じ始め、調査します。
すぐに、/dvd/listがまったく同じことをしていることに気づくでしょう：/dvd/list/にリダイレクトし、それが内部的にindex.php?controller=dvd&action=listに変換されます。 1つの追加要求 - しかしさらに悪いことに！ customer/loginはcustomer/login/にリダイレクトし、次にcustomer/login/のHTTPS URLにリダイレクトします。あなたはtonsの不要なHTTPリダイレクト（=追加のリクエスト）を持つことになり、ユーザーエクスペリエンスが遅くなります。
ほとんどの場合、ここにデフォルトのディレクトリインデックスがあります。actionを指定しないindex.php?controller=dvdは、単に内部的にindex.php?controller=dvd&action=listをロードします。
概要：
末尾が
/の場合、neverになることはできません。 サーバー推測なし。スラッシュまたはスラッシュなしはまったく異なる意味です。 「スラッシュまたはスラッシュなし」の間には技術的/リソース的な違いがありますので、それを認識して適切に使用する必要があります。サーバが
/dvd/index.htmをロードしている、または正しいスクリプトをロードしているという理由だけで、あなたが/dvdを言ったとき：それはそれをしますが、あなたが正しい要求をしたからではありません。これは/dvd/でした。実際にmeanとなっていてもスラッシュを省略すると、HTTP要求がさらに増加します。 /これは常に悪く（モバイルの待ち時間について考える）、「かわいいURL」よりも重要性が高い - 特にクローラはSEOが信じるほど、あるいは信じて欲しいほど愚かではないので。）
あなたのURLを（末尾のスラッシュ付きで）/about-us/にするとき、単一のファイルindex.htmlで始めて、後でそれをさらに拡張してさらにファイルを追加する（例えばour-CEO-john-doe.jpg）、あるいはその下に階層を構築する（例えば/about-us/company/、/about-us/products/など）ことは簡単です。 ）（必要に応じて）公開されているURLを変更せずに。これはあなたに大きな柔軟性を与えます。
ここでの他の答えは、末尾のスラッシュを省略することを好むようです。末尾のスラッシュが検索エンジン最適化（SEO）に役立つ場合が1つあります。それはあなたの文書が.htmlではないファイル拡張子であるように見えるものを持っているというケースです。これは、Webサイトを評価しているサイトで問題になります。彼らはこれら二つのURLから選ぶかもしれません：
http://mysite.example.com/rated.example.comhttp://mysite.example.com/rated.example.com/
そのような場合は、末尾のスラッシュ付きを選択します。これは、.com拡張子がWindows実行可能コマンドファイルの拡張子であるためです。検索エンジンやウイルスチェッカーは、そのようなメカニズムを通じて配布されたマルウェアを含む可能性があると思われるURLを嫌います。末尾のスラッシュは、懸念を軽減し、検索エンジンでランク付けされ、ウイルスチェッカーによって取得されるようにします。
あなたのURLがファイル部分に.を含まないならば、私は単純化のために末尾のスラッシュを省略することをお勧めします。
誰がファイル名が拡張子を必要としていると言いますか？いつか* nixマシンを見てください。
私はあなたの友人に同意します。末尾にスラッシュは付きません。
SEOの観点からは、URLの末尾に末尾のスラッシュを含めるかどうかを選択することは無意味です。最近では、Web上で両方の例を見るのが一般的です。サイトはどちらの方法でもペナルティを科されることはなく、またこの選択はあなたのウェブサイトの検索エンジンのランキングやその他のSEOの考慮事項にも影響しません。
好みのURL命名規則を選択し、各Webページの<head>セクションに正規のメタタグを含めるだけです。
末尾にスラッシュがあってもなくても、検索エンジンは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回だけカウントします。