はじめに
目的
本ドキュメントは、URL設計のベストプラクティスをわかりやすくまとめたものです。SEO（検索エンジン最適化）とAPI設計の両方の観点から、実務で役立つ指針を段階的に解説します。
対象読者
- ウェブサイトを運営する方
- APIを設計・運用するエンジニア
- URL設計に自信を持ちたいプロジェクトマネージャー
初心者から中級者までを想定しています。難しい用語は極力避け、具体例を交えて説明します。
本書の構成と使い方
全7章で構成します。各章は独立して読み進められますが、順に読むと設計の流れがつかめます。手元のプロジェクトに当てはめて、少しずつ改善していくことをおすすめします。
期待される効果
シンプルで一貫性のあるURL設計により、ユーザーや検索エンジンにとって分かりやすくなり、メンテナンスも楽になります。APIでは利用者が使いやすく、バグを減らせます。
シンプルでわかりやすいURL構造の基本原則
目的と心構え
URLはページの住所です。訪問者が直感で内容を想像できるように設計します。シンプルさと明確性を最優先にしてください。
短く、意味のある語を使う
長い文字列やランダムなIDは避けます。例：
– 良い例: /products/red-shoes
– 悪い例: /p?id=12345&ref=abc
短いと覚えやすく、共有もしやすくなります。
階層は論理的に
階層は深くしすぎないでください。例：/blog/2025/10/long-title は冗長な場合があります。代わりに /blog/long-title の方が扱いやすいです。
クエリとパラメータの扱い
検索やフィルタで必要な場合を除き、複数のパラメータは避けます。クローラがインデックスしにくくなる可能性があります。必要な情報はパスに含めると分かりやすくなります。
人に優しく、検索にも配慮
読みやすい単語を選び、特殊文字や大文字は避けます。SEO面でも有利です。
リソース中心の設計とRESTful API の考え方
リソースを中心に考える
URLは操作（動詞）を表すのではなく、扱う対象（リソース）を表現します。たとえばユーザーを扱うなら /users が基本です。操作はHTTPメソッドで表現します。
HTTPメソッドと典型例
- GET /users（一覧取得）
- GET /users/123（単一取得）
- POST /users（作成）
- PUT /users/123（更新：全体）
- PATCH /users/123（更新：一部）
- DELETE /users/123（削除）
レスポンスのステータスコードは意味を持ちます。作成時は201、削除成功は204を返すと分かりやすくなります。
ネストしたリソースの表現
親子関係がある場合は階層で表現します。たとえばユーザーの投稿一覧は GET /users/123/posts とします。コメントなどさらに深い関係は /posts/456/comments のように表現します。ネストは機能に応じて深さを抑えると扱いやすくなります。
フィルタリング・ソート・ページング
一覧の絞り込みはクエリパラメータで行います。例：
/users?status=published&page=2&limit=20&sort=created_at_desc
クエリは柔軟に拡張できますが、一貫した命名（page, limit, sort, q など）を守ると利用者に優しい設計になります。
実務での注意点
- 動詞的なパス（/getUsers や /deleteUser）を避ける
- リソース名は複数形で統一する（/users）
- ネストしすぎず、必要ならIDで参照する（/users/123 と /posts/456）
- 状態変更は安全に扱い、HTTPメソッドとステータスを正しく返す
これらを守ると、直感的で拡張しやすいAPI設計になります。
命名規則と単語の区切り方
概要
URL内の単語の区切り方は可読性とSEOに直結します。Googleはアンダースコアではなくハイフンを推奨します。ハイフンは検索エンジンに単語の境界として認識され、可読性も高まります。
基本ルール
- 小文字を使う：大文字混在は誤解やキャッシュ問題を招きます。
- ハイフンを使う：user-profiles のように単語をつなぎます。アンダースコアは避けます。
- 複数形のリソース名：blog-posts, user-profiles のように集合を表現します。
具体例
- 良い例：GET /user-profiles、GET /blog-posts
- 悪い例：GET /UserProfiles、GET /user_profiles、GET /blogPost
ローカライズと可読性
ユーザー向けページはローカライズされた語を使えます（/ja/blog-posts）。APIは英語で統一すると運用やドキュメントが楽になります。
注意点
短すぎる省略語は避け、意味が分かる単語を選びます。URLは人にも機械にも分かりやすく設計してください。
階層構造の深さと設計方法
なぜ深さを抑えるか
URLを深くしすぎると、ユーザーがページの位置を把握しにくくなります。検索エンジンも階層が浅い方が理解しやすく、クローリング効率が上がります。目安は3〜4階層程度です。
推奨される階層例
- シンプル：/category/page-name
- 程度ある分類：/category/subcategory/page-name
具体例：/books/fiction/the-great-gatsby のように、各階層で内容を伝えます。
各階層に意味を持たせる方法
各階層は名詞で表現し、ページ内容が想像できる名前にします。数字のIDだけを並べると意味が分かりにくくなります。必要ならIDは末尾に付けます（例：/products/coffee/espresso-12345）。
深くなりすぎた場合の対処
深い構造が必要な場合は、URLを平坦化してカテゴリ情報を内部的に保持したり、クエリやタグで補助したりします。また、既存のURLを変更する際は301リダイレクトで古いURLから新しいURLへ誘導してください。
運用上の注意
階層とサイト内のパンくずを一致させ、ユーザーが迷わない導線を保ちます。常に簡潔さを優先してください。
文字エンコーディングとローカライズ対応
UTF-8 を必ず使う理由
URL に日本語や特殊文字を使う場合、UTF-8 によるエンコードが標準です。UTF-8 は広く対応され、検索エンジンやブラウザが正しく解釈します。たとえば「/地域/東京」は実際には「/%E5%9C%B0%E5%9F%9F/%E6%9D%B1%E4%BA%AC」と送信されます。
パス・クエリのエンコード方法
パスとクエリはまず UTF-8 に変換し、その後パーセントエンコーディングします。例: アラビア語「/مرحبا」は「/%D9%85%D8%B1%D8%AD%D8%A8%D8%A7」となります。ブラウザ側で自動変換されることが多いですが、サーバー側でも明示的に扱ってください。
表示名とURLは分ける
多言語サイトでは、ページの表示名（ユーザー向け）と実際の URL を分離すると管理しやすくなります。表示は現地語、URL は簡潔な英語やローマ字にして安定性を保つ方法が有効です。
ローカライズのベストプラクティス
- 言語別ディレクトリ（/ja/, /en/）を使うと整理しやすいです。
- hreflang を正しく設定し、検索エンジンに言語バージョンを伝えます。
よくある落とし穴と対策
- エンコード不一致でリンク切れや重複が起きます。サーバーで UTF-8 を確実に扱い、正規化ルールを決めてください。
- ホスト名のローカライズには IDN（Punycode）が必要です。ドメイン部分は別途変換される点に注意してください。
これらを守ると、ユーザーと検索エンジンの両方にとって扱いやすい URL が作れます。
プロトコルとホストの統一
意味と重要性
サイト全体で同じプロトコル（例：https）とホスト名（例：wwwあり／なし）を使うと、同一のコンテンツが複数のURLとして扱われるのを防げます。検索エンジンの評価が分散せず、ユーザーにも分かりやすくなります。
推奨設定の決め方
- プロトコルは原則としてhttpsに統一します。通信が安全になり、ブラウザ信頼も得られます。
- ホストは運用やブランドに合わせて”wwwあり”か”なし”を選びます。どちらでも問題ありませんが、一貫性が大切です。
設定と運用のポイント
- 他のバリエーション（http、非wwwなど）からは恒久的なリダイレクト（301）で統一先に送ります。これにより評価が一つにまとまります。
- HTMLのcanonicalタグとサイトマップも統一先を指すように更新します。検索エンジンへの指示が明確になります。
- サーバーやCDN、外部サービスの設定も同じホスト・プロトコルを使うようにします。クッキーやCORSの問題を防げます。
チェック方法
定期的にクロールツールやサーチコンソールで正しくリダイレクトされているか確認します。ログを見て古いバリエーションへのアクセスが残っている場合は、内部リンクや外部リンクの修正を検討します。
