URL末尾のスラッシュの有無って結局どうしたらええの?

RFC仕様における定義と扱い

URL（より正確にはURI）の末尾にスラッシュがある場合とない場合は、RFCの仕様上別の文字列として扱われます。主な関連規格はRFC 3986「Uniform Resource Identifier (URI): Generic Syntax」で、これがURI全般の文法を定めています ( RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax )。RFC3986では、URIのパス（path）部分は「/」で区切られるセグメントから構成されると定義されています。そのため、末尾にスラッシュがあるかないかでパスのセグメント構成が変わります。

たとえばRFC3986の文法に沿えば、/users というパスは「users」という1つのセグメントから成りますが、/users/ は「users」というセグメントに加え、空のセグメント（末尾の""）がもう1つある、計2つのセグメントからなるパスと見なされます (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。つまり https://example.com/hoge と https://example.com/hoge/ はURI文字列としては異なる識別子です。それぞれ別のリソースを指しうるため、基本的には同一とはみなされません (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。RFC上も2つのURIは文字列が異なる限り同一である保証はなく、同じリソースかどうかはサーバー側の実装次第となります。

もっとも、RFC3986自体もHTTPの慣習について言及しており、Webの実用上は末尾スラッシュの有無を同等とみなす場合が多いことを示しています。例えばクローラ（Webスパイダー）は、あるURLにアクセスした際にサーバーから末尾にスラッシュを付けた別のURLへリダイレクトされる挙動を観察すると、今後それらを同一視して扱うとRFC3986で例示されています (
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax_ 。これは「http://example.com/data」にアクセスするとサーバーから「http://example.com/data/」へのリダイレクトが返ってくるようなケースで、 サーバーが両者を同一のリソースとして扱っている明確な指標がある場合 には、クライアントもそれに従い同一視するということです (RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax)。要するに、URIの仕様上は別物でも、HTTPではディレクトリを表すURLには末尾にスラッシュを付ける慣習があり、サーバーもそのように動作するため、実質的に同じ内容が提供されるケースが多いということです。

関連する過去の規格として、RFC 1808（相対URLの規則を定めたもの）では、FTPスキームにおいてディレクトリを示す際に末尾のスラッシュが重要である旨が記載されています (RFC 1808 - Relative Uniform Resource Locators)。これは「取得したディレクトリ listing 内の相対URLを解釈するには、ベースとなるURLのパスは末尾にスラッシュを含める必要がある」という内容で、ディレクトリを基準に相対参照する場合に末尾の「/」が不可欠であることを示しています (RFC 1808 - Relative Uniform Resource Locators)。HTTPでも同様に、あるURLがディレクトリ（階層構造上さらに下位のリソースを含むコンテナ）である場合には末尾にスラッシュを付けた形式が標準的です。この仕様上の考え方が、後述するサーバーやクライアントの挙動にも影響を与えています。

技術的な挙動の違い

Webサーバーにおける処理

Webサーバー（ApacheやNginxなど）の多くは、URLに対するリクエストを処理する際に末尾のスラッシュ有無を自動で補正する機能を持っています。代表例としてApacheにはmod_dirというモジュールがあり、ディレクトリへのリクエストに自動で「/」を付加してリダイレクトする役割を担っています (mod_dir - Apache HTTP Server)。例えばApacheは、実際に存在するディレクトリdirnameに対してhttp://servername/foo/dirnameのようにスラッシュなしでリクエストが来ると、HTTPステータス301（Moved Permanently）のリダイレクト応答を返し、クライアントにhttp://servername/foo/dirname/へアクセスし直すよう指示します (mod_dir - Apache HTTP Server)。これは**「ディレクトリには必ずスラッシュを付ける」というWebの約束事に従った動作です (mod_dir - Apache HTTP Server)。同様にNginxもデフォルトの挙動で、設定されたパスがディレクトリ的なロケーションの場合、例えば/foo/というロケーションに対して/fooでアクセスが来た際には自動的に「/foo/」へリダイレクト**します ([nginx] Redirect with added trailing slash · Issue #646 · kubernetes/ingress-nginx · GitHub)。実際、Nginxをリバースプロキシとして使用している環境で、/fooにアクセスするとLocationヘッダに/foo/が含まれた301応答が返り、ブラウザがそれを受けて/foo/にアクセスし直す、という動作が報告されています (url - Nginx causes 301 redirect if there's no trailing slash - Stack Overflow) ([nginx] Redirect with added trailing slash · Issue #646 · kubernetes/ingress-nginx · GitHub)。

このようなリダイレクトを行う理由の一つは、ディレクトリを指すURLの場合にベースURLが正しく解釈されるようにするためです。例えば実際のファイル構成上/hoge/ディレクトリの中にindex.htmlがある場合、クライアントがhttps://example.com/hogeとリクエストすると、サーバーは内部的にhogeという名前のディレクトリを見つけhoge/index.htmlを返そうとします。しかしURL上は末尾スラッシュがないため、相対URLの基準が親ディレクトリになってしまい、HTML内のリンクや画像参照がずれてしまう可能性があります (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。実際の例で言えば、<img src="image.avif">という相対パスの画像リンクがページ内にあった場合、ページURLが/resource/であればブラウザは/resource/image.avifを取りに行きますが、ページURLが/resource（末尾なし）だとブラウザは/image.avifを取りに行こうとしてしまいます (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。このようにディレクトリを指すURLにスラッシュがないと、ページ内の相対パス解釈が変わりリソースが正しく読み込めなくなることがあります (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。そのためサーバーは敢えてリダイレクトを返し、クライアントのURLを正しい形（末尾スラッシュ付き）に整えることで、後続のリソース取得が正しく行われるようにしているのです (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。

ただし、サーバーの設定次第では末尾のスラッシュ有無で別コンテンツを返すことも可能です。多くのサーバーは上記のように自動補正しますが、管理者が意図的に設定を変えてどちらのURLでもコンテンツを提供する、あるいはどちらか一方のみを有効にすることもできます。例えばApacheではDirectorySlash Offの指令を使うと自動リダイレクトを無効化でき、逆に末尾スラッシュなしのURLでも同じディレクトリ内容を返す（リダイレクトしない）ことが可能です。しかしこの場合、先述の通り相対リンクが崩れるリスクがあるため、運用上は注意が必要です。また、スクリプト実行型のページでは末尾にスラッシュを付けてアクセスされると思わぬ挙動になる場合があります。例えばApache + PHP環境では、/index.php/のようにPHPファイル名の後にスラッシュを付けてアクセスすると、PHP側ではindex.phpが実行され、余分なパス要素（ここでは空のパス）をPATH_INFOとして渡す仕様があります (security - Apache trailing slash added to files problem - Server Fault)。その結果、本来index.php内で期待していないパス情報が入ることで、画像などのパスがズレたり（index.phpをディレクトリと見立ててindex.php/myimg.jpgを探そうとする等）して表示崩れや、場合によってはセキュリティ上の予期せぬ挙動につながることもあります (security - Apache trailing slash added to files problem - Server Fault)。このように、サーバーは末尾スラッシュを意識した挙動を内部で行っており、設定によっては同じパスでもスラッシュの有無で別扱いになるケースがあることに留意が必要です。

ブラウザの挙動

ブラウザ（クライアント）の側では、基本的にサーバーからの指示に従って動作します。ブラウザ自体が独自に「スラッシュの補完」を行うことはほとんどありません。たとえばユーザーがアドレスバーにhttps://example.com/hogeと入力してアクセスした場合、サーバーが301リダイレクトを返せばブラウザは自動でhttps://example.com/hoge/に遷移しますが、サーバーから特にリダイレクトが返らなければ、そのままそのURLのコンテンツを表示しようと試みます。現代の主要ブラウザ（ChromeやFirefoxなど）はURLの表示上の体裁を多少変えることはありますが、自発的なリダイレクトはしません。例えばChromeではアドレスバーにドメイン名だけを入力すると自動で末尾にスラッシュを付けて表示する（example.com→example.com/）挙動や、逆に最近のブラウザはアドレスバー上でスラッシュを省略表示するなどUI上の差異はあります (url rewriting - When should I use a trailing slash in my URL? - Stack Overflow)。しかし、これらは見た目の問題であり、実際の通信上は常に完全なURL（スラッシュ含む形）でサーバーにリクエストが送られています (Trailing Slashes and SEO: Quick Tips and Gotchas)。したがって、ブラウザ自身が勝手に追加の「/」を付けて別のURLを取りに行くことは通常なく、あくまでサーバー側のリダイレクト指示やコンテンツのリンクに従う形になります。

ただ一部特殊なケースとして、ブラウザの実装とサーバー設定の組み合わせによる自動挙動が見られることがあります。例えばDjangoフレームワークでは末尾にスラッシュのないURLへのアクセスを検知すると、フレームワーク側で自動的に「/」を付けてリダイレクトする機能（APPEND_SLASH）がデフォルトで有効になっています (Trailing URL Slashes in Django - DEV Community)。このときChromeでスラッシュ無しURLにアクセスすると、ログ上はDjangoが301リダイレクトを返しているのですが、Chromeのアドレスバーには初めからスラッシュ付きで表示されるという報告があります (Trailing URL Slashes in Django - DEV Community)。これはChromeがサーバーの301応答を即座に処理してアドレスバーを書き換えてしまうため、ユーザーから見ると「最初からスラッシュを付けてアクセスしたように見える」現象です。実際にはブラウザが内部でリダイレクトを処理した結果なので、厳密にはブラウザが能動的にURLを書き換えたわけではありません。このようにブラウザはサーバーまたはWebフレームワークからのリダイレクト応答に忠実に従うので、末尾スラッシュの有無によるリソース取得の差異は、主にサーバー側で決まると考えてよいでしょう。

REST APIにおけるスラッシュの影響

RESTfulなAPI設計においても、末尾のスラッシュ有無はしばしば議論になります。技術的には通常のWebと同じくURI文字列の違いでしかないため、特段の設定がなければ/api/resourceと/api/resource/は別々のエンドポイントとして扱われます (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。そのためRESTクライアント（APIを呼び出す側）もそれらを別のURIとしてキャッシュしたり区別したりするのが原則です (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。一方で、APIサーバー（RESTサービス）の実装側ではフレームワークによって挙動が異なります。例えばDjango REST Frameworkではデフォルトで全てのAPI URL末尾にスラッシュを要求し、無い場合は上記のようにリダイレクトまたは404を返します。設定でAPPEND_SLASH=Falseやルーティングでtrailing_slash=Falseを指定すればスラッシュ無しでも受け付けるよう変更可能で、これは開発者がどちらを標準とするかのポリシーと言えます (Trailing URL Slashes in Django - DEV Community)。他のフレームワークでも、Ruby on Railsはルーティング上末尾スラッシュなしを基本としたり、Laravel（PHP）ではどちらでも動くようにしたりと様々です。重要なのはAPI利用者にとって一貫した仕様にすることで、ドキュメント上も「末尾にスラッシュは付ける/付けない」を明示するのが望ましいです。

RESTの提唱者であるRoy Fielding氏自身は特にどちらが正しいという見解を示していませんが、URIの専門家からは「URIはあくまでオーソリティ（サーバー側）が自由に設計できる識別子であり、クライアントから見ればそれがディレクトリ的かどうかは意識せず文字列として扱うべき（オペークな識別子）」との指摘があります (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。つまり**「/」の有無に特別な意味を見出すかはサーバー側次第であり、REST APIとしてはどちらでも構わないが混乱を招かないよう統一しよう、ということです。実際の運用では、「コレクション」を表すURI（例：ユーザー一覧）はスラッシュなし単数形、個々のリソースはIDを付加するので元々スラッシュで区切られる**（例：/users/123）ため、ベースとなる/users側はスラッシュを付けない、という設計もあります (rest - RESTful URI trailing slash or no trailing slash - Stack Overflow)。逆に全てのURIの末尾にスラッシュを付ける方が一貫性があると考え、/users/を一覧、/users/123/を個別といった運用をするAPIもあります。いずれにせよREST APIではクライアント・サーバー間で統一された約束事を決め、それ以外のURLは受け付けないかリダイレクトする実装にするのが一般的です。クライアント側も公式ドキュメントに従い、要求される形式でリクエストを行うのがベストプラクティスと言えるでしょう。

ベストプラクティスと推奨事項

SEO（検索エンジン最適化）の観点

SEO上は、URLの末尾スラッシュ有無を統一し一貫した形で運用することが強く推奨されます。検索エンジン（特にGoogle）は、技術的にはスラッシュの有無で別々のURLとしてクロール・インデックスしますが、サイト管理者向けにはどちらか一方のURLに統一する（片方からもう一方へリダイレクトする）ことを推奨しています (
Official Google Webmaster Central Blog: To slash or not to slash
)。Google公式のWebmaster Centralブログでも、「歴史的に末尾スラッシュ付きはディレクトリ、なしはファイルを意味するという慣習はあるが、実際にはどちらでも内容が提供されうるし、Googleは両方を別個のURLとして扱う」と明言されています (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange) (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)。つまり検索エンジンにとって.../hogeと.../hoge/は別のドキュメントとして扱われ、どちらを主とするかはサイト側の指定次第ということです。ただし、だからといって両方に別々のコンテンツを置いて良いわけではなく、ユーザー体験を考えると同一コンテンツで2つのURLがあるのは非常に紛らわしいため避けるべきだとされています (
Official Google Webmaster Central Blog: To slash or not to slash
) (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)。実際、「example.com/webmasters」と「example.com/webmasters/」で内容が違っていたらユーザーは混乱するだろう、とGoogleも例を挙げています (
Official Google Webmaster Central Blog: To slash or not to slash
)。

以上から、SEOのベストプラクティスとしては以下が挙げられます：

• サイト全体でどちらか一方の形式に統一する（例えば全て末尾スラッシュあり、または全てなし）。
• 統一ルールから外れるリクエストが来た場合は301リダイレクトで正規化されたURLに誘導する (
  Official Google Webmaster Central Blog: To slash or not to slash
  )。こうすることで検索エンジンのクローラも片方のURLだけをインデックスし、 **重複コンテンツ（duplicate content） **として評価されるのを防ぎます (
  Official Google Webmaster Central Blog: To slash or not to slash
  )。
• もし何らかの理由で両方のURLを維持して同じコンテンツを返す場合でも、 HTML上で<link rel="canonical">タグを使用して正規URLを明示 することが望ましいです (
  Official Google Webmaster Central Blog: To slash or not to slash
  )。これにより、検索エンジンにはこちらを主と見なしてほしいというシグナルを送れます。
• Google検索ではリダイレクトが適切に設定されていれば、301でも302でも 実際にコンテンツを返した側（通常はリダイレクト先）のURLをインデックスに採用 する傾向があります (
  Official Google Webmaster Central Blog: To slash or not to slash
  )。多くの場合、末尾スラッシュ付きURLにリダイレクトするサイトが多いため、結果としてスラッシュ付きの方がインデックスに残りやすいとも言われています。
• サイトマップや内部リンク、外部への案内では正規化した方のURLを用いることで、一貫性を保ちつつクローラビリティを高めます。

加えて、SEO担当者から見た実務面では「末尾のスラッシュはURLの重要な一部であり、有るか無いかで別物になる」という点が繰り返し強調されています (Trailing Slashes and SEO: Quick Tips and Gotchas)（GoogleのJohn Mueller氏の発言）。これは裏を返せば、サイト側でしっかり管理しないと検索エンジン側で自動的に統一はしてくれないという意味でもあります。実際Googleは賢いため重複コンテンツとしてペナルティを即与えることはありませんが、クロールの無駄やインデックスの分散を招くので、「どちらでもアクセスできるが内部的には統一」といった運用（つまり片方にリダイレクト or canonical 指定）は基本だと考えてよいでしょう (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange) (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)。一貫性のあるURL構造は、ユーザーにとってもわかりやすくブックマークや共有もしやすいというメリットがありますし、サイト運営側も分析やログ管理がシンプルになります。

サイト運用・ユーザビリティの観点

サイト運用やユーザビリティの面でも、URLの末尾にスラッシュを付けるかどうかのルールを決め、統一することが推奨されます。ユーザビリティの観点からは、ユーザーがあるページURLを予想したり手入力したりする場合に、一貫性がある方が混乱がありません。例えばドメイン直下のページ以外はすべて「/」で終わるとわかっていれば、ユーザーは迷わずその形式でURLを入力できますし、仮に忘れてもサーバーがリダイレクトで補正してくれるでしょう。一方、あるページはスラッシュありでアクセスできるが別のページはなしでしかアクセスできない、という状況はエラーや二重取り込みにつながり、ユーザー体験を損ねます。

またパフォーマンス面でも、統一と適切なリダイレクト設定が重要です。もしユーザーがスラッシュ無しのURLにアクセスしてサーバーがリダイレクトでスラッシュ有りに飛ばす、といったやり取りが頻発すると、その分だけHTTPリクエストが往復し表示までの時間がわずかに遅れます。特にモバイル回線など遅延の大きい環境では、無駄なリダイレクト1回でも体感速度に影響することがあります。したがって内部リンクやナビゲーションでは予め正規化されたURLを使い、極力追加のリダイレクトが発生しないようにすることが望ましいです (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。例えばWordPressサイトでは投稿ページURLに自動的に末尾スラッシュを付ける仕様になっていますが (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)、これはユーザーがスラッシュ無しでアクセスしても裏でリダイレクトされることを意味します (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。可能であれば初めからユーザーが目にするリンクは正しい形式にしておき、リダイレクトは予備的な措置と考えるのがよいでしょう。

URLの見た目（可読性）については意見が分かれます。かつては「末尾にスラッシュが付いている方がディレクトリっぽく整った見た目で好ましい」「拡張子も無いのにスラッシュが無いURLは不自然だ」といった声もありました (url rewriting - When should I use a trailing slash in my URL? - Stack Overflow)。しかし近年ではあまり気にしないユーザーも多く、むしろ「最新のサイトでは末尾スラッシュを付けないシンプルなURLの方が増えており、そちらの方がすっきりしている」という見解もあります (url rewriting - When should I use a trailing slash in my URL? - Stack Overflow)。実際、モダンなWebアプリケーションやSPA（シングルページアプリ）ではURLの末尾を付けずに運用する例も少なくありません。最終的にはサイト運営者のデザインポリシーですが、**どちらを採用するにせよユーザーに混乱を与えない実装（片方はきちんと404やリダイレクトで処理する）**が重要です。

セキュリティへの影響

URL末尾のスラッシュ有無それ自体は、直接的なセキュリティ上の脅威になるものではありません。適切に設定されていれば、どちらでアクセスされても同じコンテンツを返すか正規の方に誘導するだけなので、特段の問題は起きないでしょう。ただし不適切な実装や想定漏れによってはセキュリティ上の抜け穴となり得るケースもあります。一般的に注意すべきポイントは以下の通りです：

• 認可やアクセス制限のルール漏れ: アクセス制限をURLパス文字列で行っている場合、末尾スラッシュの有無も別パスと判断されるため、片方だけ許可・禁止してもう片方を漏らしてしまうミスが起こり得ます。例えば/adminを管理者のみ閲覧可と設定していても、/admin/でアクセスしたらそのチェックをすり抜けて表示できてしまった、などのバグは実際に発生し得ます。従って、アクセス制御やルーティングの際には両方のURLを正しく取り扱う（必要なら正規化してから判断する）ことが重要です。
• パス同一視の曖昧さ: 一部のシステムではパスの末尾に区別を設けていないつもりでも、内部モジュールが違いを区別してしまい、結果として想定外のファイルにアクセスできてしまうケースがあります。これはCWE-49: Path Equivalenceというセキュリティ問題にも挙げられており、「製品が末尾にスラッシュ付きのパス入力を適切に検証せず受け入れると、解釈の曖昧さからファイルシステム上の意図しない場所に到達したり任意のファイルにアクセスできてしまう可能性」が指摘されています (CWE - CWE-49: Path Equivalence: 'filename/' (Trailing Slash) (4.16))。具体例として、/restrictedというパスを禁止していたが/restricted/と書くと別扱いになりアクセスできてしまう、ディレクトリトラバーサルフィルタが..の後にスラッシュが無いケースしか想定しておらず../で抜けられる、等があります。防御策としては入力されたURLパスを正規化（normalize）して扱うことが挙げられ、末尾のスラッシュ有無も正規化プロセスの一環です。
• パス情報の悪用: 前述したようにApache+PHPのような環境では、script.php/anythingというリクエストが有効になっていると、スクリプト内でPATH_INFOとして/anythingが渡されます。この仕組み自体は仕様ですが、アプリケーションによってはこのPATH_INFOを想定しておらず予期しない挙動（例えば本来読み込まないはずのファイルを参照してしまう等）を引き起こす恐れがあります (security - Apache trailing slash added to files problem - Server Fault)。これは開発者がチェックしていれば防げますが、攻撃者が意図的にスラッシュを付けてアクセスすることでアプリの盲点を突く可能性もゼロではありません。従って、フレームワークの設定でPATH_INFOを無効化する（Apacheの場合はAcceptPathInfo Off (security - Apache trailing slash added to files problem - Server Fault)）など、不要な挙動は抑制しておくことが堅牢化につながります。

以上より、セキュリティ面では「スラッシュ有無でコンテンツが両方見えてしまう（二重露出）」「片方のURL経路でセキュリティチェックを回避される」といったことがないようURL正規化と一貫したアクセス制御を行うことが大切です。幸い、主要なサーバーやフレームワークはこれらを考慮したデフォルト挙動（自動リダイレクトや404応答）になっていますので、特別な理由が無ければそのデフォルトに従うのが安全策と言えるでしょう。

特定の状況における使用例と推奨ケース

スラッシュを省略するケース（末尾なしが望ましい場合）

一般的に 「これはファイルだ」と明示したいURLや、階層の末端であるリソース については末尾のスラッシュを付けません。以下のようなケースが該当します。

• 実ファイル（静的リソース）へのURL: 画像ファイルやPDF、スクリプトなど拡張子を含むファイルへのURLでは末尾にスラッシュを付けることは誤りです。例えばhttps://example.com/docs/manual.pdf/のようにファイル名の後にスラッシュを付けるとリソースが見つからずエラーになります (Trailing Slashes and SEO: Quick Tips and Gotchas)。ファイルパスでない場合でも、「実態として単一のリソースを表しており、その下位に子リソースを持たない」と設計者が判断した場合はスラッシュ無しのURLとすることが多いです。
• APIエンドポイント: REST APIなどでは末尾スラッシュ無しを推奨するガイドラインも多くあります。例えばGitHubやTwitterのAPIはドキュメント上ほとんどのエンドポイントをスラッシュ無しで記載しています。これはエンドポイントを一種のファイルパス（動的なスクリプト呼び出し）とみなし、余計な区切りを付けない方が直感的との考えによります。また、プログラム上URLを組み立てる際にも末尾に余計な「/」が入らない方が扱いやすいという理由もあります。フレームワークによってはデフォルトでスラッシュ無し運用を前提としているものもあります。
• シンプルで短いURLを好む場合: サイト運営者の方針として「可能な限り短いURLにしたい」という場合、末尾のスラッシュを省略する傾向があります。特に近年の傾向としてブログ記事や製品ページなどもスラッシュ無しURLが増えています (url rewriting - When should I use a trailing slash in my URL? - Stack Overflow)。例えばhttps://example.com/blog/new-featureのようにカテゴリも含めずシンプルな構造にするケースです。ユーザーがURLをコピー&ペーストしたとき末尾に余計な文字が無い方が見栄えが良い、SNSでシェアするとき短い方が好まれる、といった理由もあります。

以上のケースでは、基本的に末尾にスラッシュを付けないURLを正式なものとし、もしユーザーが誤って「/」を付けてアクセスした場合には速やかに外す方向（スラッシュ無しのURLにリダイレクト）に統一するのがよいでしょう (Trailing Slashes and SEO: Quick Tips and Gotchas) (Trailing Slashes and SEO: Quick Tips and Gotchas)。実際、Web制作ツールやCMSによっては「末尾スラッシュあり/なし」を設定で選べるものが多く、その設定に応じて自動でリダイレクトルールを作ってくれるものもあります (Trailing Slashes and SEO: Quick Tips and Gotchas) (Trailing Slashes and SEO: Quick Tips and Gotchas)。

スラッシュを付けるケース（末尾ありが望ましい場合）

「このURLの下にさらに下位ページやリソースが存在する」ことを示唆したい場合、末尾にスラッシュを付けるのが伝統的かつ実用上の利点もあるスタイルです。具体的なケースとしては：

• ディレクトリ（セクション）を示すページ: 典型的なのがウェブサイトのカテゴリーやセクションのトップページです。例えばhttps://example.com/blog/はブログ記事の一覧やカテゴリーページであり、その配下に個別記事ページが存在します。同様に/products/は商品一覧、/docs/はドキュメントの目次、といった具合に、下位にコンテンツを含むディレクトリ的ページにはスラッシュ付きURLがよく使われます (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。このようにしておくと、URLを見ただけで「この先に何かありそうだ」とユーザーや開発者が理解しやすくなります。また後からそのディレクトリ内に新ページを追加することも容易です。
• 実際のファイルシステム上のディレクトリに対応するURL ** : サーバー上のフォルダ構成とURL構造を合わせている場合、フォルダに対しては「/」を付けてアクセスさせる方が自然です。先述の通り、サーバーもその前提で動作しており、スラッシュ無しでディレクトリを指定すると 自動的にスラッシュ付きに直される（リダイレクトされる）ことがほとんどです (mod_dir - Apache HTTP Server)。したがって、初めから正しいディレクトリURL（末尾/）をユーザーに提供することで、 余計なリダイレクトを防ぎつつ相対パスの問題も回避**できます (Trailing Slashes On URLs: Contentious Or Settled? | CSS-Tricks)。
• 階層構造を強調したい場合: Webサイトの情報アーキテクチャ上、階層を明確にURLに反映させたい場合にもスラッシュ付きが選ばれます。例えば企業サイトで/company/以下に会社案内ページや採用情報ページがまとまっている時、その総合案内ページを/company/（末尾/）とすることで、その下位ページ（/company/team, /company/careersなど）群の親であると示せます。ユーザーがURLを見てサイト内の位置関係を把握しやすい利点があります。
• 既定のインデックスリソースを持つ場合: あるURLにアクセスしたとき、自動的に下位のデフォルトリソース（例えばindex.htmlやindex.php）が提供される場合も、末尾スラッシュ付きでアクセスするのが本来の形です (mod_dir - Apache HTTP Server)。スラッシュ無しでも結果的に同じものが返る設定もできますが、前述のように内部的にはリダイレクト処理などが走るため、本来の使い方に合わせるのが望ましいでしょう。

以上のようなケースでは、末尾にスラッシュを付ける運用を標準とし、逆にスラッシュ無しで来たリクエストは付与したものにリダイレクトするのが一般的です ([nginx] Redirect with added trailing slash · Issue #646 · kubernetes/ingress-nginx · GitHub)。特に大量の既存コンテンツをディレクトリ構造で持つサイト（例えば技術ドキュメントサイトやカテゴリ分けされた記事サイトなど）では、スラッシュ付きのURL設計の方が後々の拡張やメンテが楽になる場合もあります。

なお、ルートドメイン（ホームページ）のURLについては特別なケースです。通常ユーザーはhttps://example.comとスラッシュ無しで認識していますが、技術的にはこれはhttps://example.com/に等価です (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)（ブラウザが自動補完し、HTTPリクエストには必ず/として送られる）。ルートに関してのみはサーバー側でもスラッシュの有無を区別せず扱うため、ホームだけは例外的に両方同じと考えて問題ありません (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)。しかしそれ以外のパスでは上記のように差異が生じるため、やはりサイト内の全URLで統一したルール（末尾スラッシュあり/なし）を設け、それに沿って運用するのがベストです。

まとめると、URL末尾のスラッシュ有無は歴史的には「ディレクトリ」か「ファイル」かを示す記号的な意味合いがありました。現在では必ずしも物理ディレクトリ・ファイル構造と対応していないものの、その概念はURL設計やサーバー挙動に影響を与えています。RFCなど仕様上は別のリソース識別子になりうるため厳密な扱いが必要ですが、実際のWeb運用ではユーザーと検索エンジンに優しい形で一貫性を持たせる ことが最も重要です。 (RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax) (In terms of SEO, what is the difference between a URL with and without a trailing slash? - Webmasters Stack Exchange)適切に設定された環境ではどちらでアクセスしても正しくコンテンツが提供されますが、開発者・管理者としてはURLの正規形（preferred form） を定め、それに沿ってサイトを構築するのが望ましいでしょう。その際、ここで述べたRFCの考え方や技術的挙動、SEO上の指針を踏まえて決定することで、より健全でわかりやすいURL設計・運用が可能になります。 (mod_dir - Apache HTTP Server) (Trailing Slashes and SEO: Quick Tips and Gotchas)