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


282

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

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

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

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


末尾はスラッシュですが、私の意見では主に美学です。ルックアンドフィール。
Eric Herlitz、


4
この質問は好みの 1つとして提起されているため、主に意見に基づくものとして話題から外れているようです。ただし、私の回答が示すように、実際にはこの質問を好みの問題として扱うのは誤りです。これはXY問題であり、根本的な「実際の」質問には正確な技術的な回答があるため、主に意見に基づくものではありません。
Raedwald 2016年

Googleが好きなURLのタイプに関する質問は(タグwikiで言及されているように)プログラミング関連ではなく、Stackoverflowのトピックから外れています。
クエンティン

質問をいくつか編集しました。機会があれば再確認してください。ありがとう:)
ティムポスト

回答:


131

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

基本的に、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について述べたように、それは不安定で不明瞭な場合があります。


1
これは奇妙です。ファイルに「stylesheet /」という名前を付けることはできません。スラッシュまたはスラッシュなしは、URLがどのように見えても、サーバー上のまったく異なるリソースです
nico gawenda

10
@ nicogawenda、.htaccessはあらゆる種類の魔法を実行できます;)あなたのCSSは実際にはphpファイルかもしれません!
rmorse 2013

4
多くの場合、Webサーバーは、デフォルトでindex.html、ディレクトリにアクセスしたときにサービス(または同様の名前のファイル)を提供するように設定されているため、余分な混乱/foo/はあり/foo/index.htmlません。また、以前は、ブラウザは/ドメイン名に追加されていましたが、それら(Firefox、Chrome、Opera)は/、ホームページにアクセスするときにを省略するように変更されています。
0b10011 2014年

4
@bfrohsに同意します。ディレクトリのデフォルトのページは、この原則に反しています。「末尾のスラッシュ=ディレクトリ」を適用する場合、ディレクトリを指すすべてのURLは、ディレクトリリストまたは403 forbidden http応答を返す必要があります。
Marvin

11
「最終的に」セクションのポイント1と2がまだ正確かどうかはわかりません。これが最初に書かれてから長年にわたって、味は変わりました。私はこれについて詳しく調べていませんが、新しいWebサイトではスラッシュを省略するほうが一般的で「きれい」です。
スピードプレーン

171

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

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

5
この上でいくつかの深さになり参考記事:cdivilly.wordpress.com/2014/03/11/...
ヘーパイストス

3
はい、これはSEOとともに、この質問の最も重要なことだと思います。
user2875289 2017

.Netを使用しているときにこの問題が発生しましたUri.MakeRelativeUri。結果はあなたの言ったことを正確に反映しています。ベースに末尾のスラッシュを追加して問題を修正しましたUri
julealgon

61

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

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

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


50
「リソースの後ろではなく、ディレクトリの後ろのスラッシュ」:URLは、「リソース」と「ディレクトリ」の2つのタイプのものを参照しません。それらは、リソースという1種類のことを指します。手がかりはURLのRにあります。
Raedwald 2013年

31
また、* nixファイルシステム内のすべてがファイルですが、ディレクトリはまだ存在しています。あなたのポイントは何ですか?
Yarin

6
それが内部でファイルまたはディレクトリによって提供されているかどうかに関係なく、ユーザーに表示されるのは単なるWebページです。そして、example.com/aboutは実際にはexample.com/about/index.htmlから読んでいる可能性があります
musiphil 2014年

1
@DavidRR:その通りです。また、名前解決が内部から行われる必要があるため、ブラウザーはリダイレクトを必要としますdirectory(そうでない場合、image.pngin http://hostname/directoryはを指しますhttp://hostname/image.png)。ユーザーの観点からは、ファイルとディレクトリの違いはそれほど重要ではないかもしれないとだけ言っていました。
musiphil 2014年

2
結果に同意しますが、* nixスタイルのファイルシステムをエミュレートするようにURLシステムを設計する必要があるかどうかはわかりません。それは本来目的を果たしていたかもしれませんが、今はそれほどではありません。
スピードプレーン

27

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

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

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 PermanentlyLocation: 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が信じるほど、または信じてほしいほど馬鹿ではないためです;)


2
まとめでは、最後にスラッシュを追加してくれましたか?:)
デニス

2
私はあなたがそれを意味するときにそれを使用するためのすべてです;)たとえば、コントローラーとアクションについて言えば、それは次のようになります:コントローラーはスラッシュで終わる必要があります。ファイルまたはアクションを参照するときはスラッシュを省略します
nico gawenda '14

ちょっと待って、アクションのスラッシュを省略するのはなぜですか?あなたの例のように、それは余分なリダイレクトされたリクエストという結果になりませんか?つまり、おそらくあなたのサーバーはコントローラーのアクションを認識するのに十分スマートであり、その場合実際にはファイルやディレクトリを探すようにリダイレクトしませんが、それでもあなたの例に反しませんか?
アダムグッドウィン

7
私はあなたの例を理解していません。ディレクトリと同じ名前(dvd)の別の通常ファイルを許可するファイルシステムは何ですか?
musiphil 2016年

19

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


9
うまく聞き取れませんでした。で開始した場合、 /about-usまたは/about-us/ディレクトリを展開した場合に両方のケースで公開URLを変更する必要がある場合。新しいファイルは/about-us/new-file.htmlどちらの場合にもなります!! ここで何が欠けていますか?
会計士م2016

2
@Accountant OPが、末尾のスラッシュなしで "/ about-us"を発行すると、相対パスを使用してサブリソースを後で追加できないと考えているようです。末尾にスラッシュがない場合、ブラウザは、aboutページの "ceo.jpg"への参照がドメインのルートに存在し、example.com / ceo.jpgを要求すると信じます。スラッシュを使用すると、ブラウザーはexample.com/about-us/ceo.jpgを要求し、展開するときに、サイトのフォルダーのツリー全体を静的にルーティングできます。
2017年

1
参考までに、上記のいずれにも該当しないと思います。なぜ/about-usand がないの/about-us/companyですか?ファイルの提供に関しては、ApacheとIISの両方がこれを問題なく処理できるため、同意しません。
sean2078 2017年

1
@ sean2078はい。ただし、からに/about-usリンクしたい場合は、または/about-us/companyを使用するhref="https://stackoverflow.com/about-us/company"必要がありますhref="./company"(ただし、それについては不明です)。/about-us/ただし、オンの場合、それは簡単ですhref="company"
Adowrath 2017

11

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

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

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

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


本当の検索エンジンはそのような愚かではありません。この答えは純粋な推測です。
Navin 2017

1
私は実際にこの問題をGoogleで見ました。それは数年前だったので、今日もそうなるかどうかはわかりません。
Stephen Ostermiller 2017

ええ、それは良いデータポイントです。それが他の何かによって引き起こされたかどうかはまだわかりませんが。
Navin、2017

10

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


3

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回だけカウントすることが保証されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.