新規サイトやリニューアルでURLを決めるとき、「階層は浅いほどよいのか」「日本語URLは避けるべきか」「カテゴリ名をどこまでURLに含めるか」と迷いやすいものです。結論として、SEOを意識したURL設計で優先したいのは、階層数を機械的に減らすことではありません。ページの役割が分かる分類、内容を表す命名、一貫したルール、不要なURLを増やさない設計を先に決めることが重要です。この記事では、サイト制作・リニューアル時にそのまま使える設計手順とチェック項目を整理します。
SEOに強いURL設計は「意味・一貫性・管理しやすさ」で決める
SEOを意識したURL設計では、検索順位を上げるために特定の形へ寄せるのではなく、検索エンジンとユーザーの双方がページの役割を理解しやすく、運用後も崩れにくい構造を作ることが重要です。
Googleは、URLについて「人が理解しやすい論理的な構造」「内容を表す単語」「単語を区切るハイフン」「不要なパラメータを減らすこと」などを推奨しています。一方で、サイト内のページ同士の重要度や関係はURLの見た目だけで判断されるわけではありません。Googleは内部リンクなど、ページ同士のつながりも使ってサイト構造を理解します。
そのため、URL設計では次の4点を基準にします。
- ページの種類と所属カテゴリが分かる
- 同じ種類のページで命名ルールがそろっている
- 長期運用のなかで変わりやすい一時的な情報を入れない
- 同じ内容へ到達する不要なURLを増やさない
たとえばサービスページなら「/service/」、導入事例なら「/case/」、記事なら「/media/」のように、ページ種別ごとの役割を決め、その下で個別ページを整理します。URLを見るだけでサイトの分類方針がある程度推測できる状態を目指します。
URL設計で最初に決める3つの要素
URL設計を始めるときは、個別ページのスラッグから決めるのではなく、サイト全体の分類から考えます。特に先に固定したいのは「ディレクトリ」「スラッグ」「正規URLのルール」の3つです。

URLの各部分を分けて考えると、ディレクトリとスラッグの役割を整理しやすくなります。
ディレクトリはページの種類とカテゴリを表す
ディレクトリは、URLの「/」で区切られたパス部分です。たとえば次のURLなら、「media」と「seo」が分類を表しています。
https://example.com/media/seo/url-design/
ただし、ここでいうディレクトリは、必ずしもサーバー上の物理フォルダと1対1で対応するものではありません。CMSやWebアプリでは、表示URLのパスと実際のファイル配置が異なることがあります。Web担当者が設計時に重視したいのは、ユーザーに見えるURLの分類と、サイト内でのページの役割が矛盾しないことです。
スラッグはページ内容を短く表す
スラッグは、個別ページを識別するURL末尾の文字列です。
例:
https://example.com/media/seo/url-design/
この場合、「url-design」がスラッグです。
Googleは、意味のない長いIDより、内容を理解しやすい単語を使うことを推奨しています。英単語を複数使う場合は「url-design」のようにハイフンで区切ると、単語の境界も分かりやすくなります。
正規URLのルールをサイト全体で統一する
同じ内容へ複数のURLで到達できる状態を放置すると、クロール対象が増えたり、検索エンジンがどのURLを代表として扱うか判断する必要が生じたりします。
設計段階で、少なくとも次のルールを統一しておくと運用しやすくなります。
- HTTPSを標準とする
- wwwの有無を統一する
- 末尾スラッシュの有無を統一する
- 大文字・小文字を混在させない
- パラメータ付きURLを作る条件を決める
- 重複URLが発生する場合のcanonical方針を決める
新しいサイト領域を既存サイト配下に置くか別ホストに分けるか迷う場合は、サブディレクトリとサブドメインの判断基準も確認してください。
ディレクトリ階層は「何階層か」より分類と内部リンクで判断する
URLの階層は、浅ければ浅いほどSEOで有利になるという単純なものではありません。重要なのは、必要な分類だけを残し、同じ種類のページが一貫した場所へ配置されていることです。
GoogleはECサイト向けの公式資料で、サイト構造を理解する際にURL構造そのものだけを見るのではなく、ページ同士のリンク関係も分析すると説明しています。また、重要なページにはサイト内の別ページからリンクを設けることを推奨しています。

URLの深さだけでなく、カテゴリの意味と重要ページへの内部リンクを合わせて設計します。
そのため、「3階層以内なら正解」「4階層以上ならSEOに弱い」といった固定基準ではなく、次の順番で判断します。
- ページの役割を分類する
- 役割ごとにカテゴリを作る
- 必要な場合だけサブカテゴリを作る
- 重要ページへ内部リンクで到達できるようにする
- 同じ意味の階層を重複して作らない
たとえば、SEOの記事を多数公開するメディアなら次のような構造が考えられます。
| ページ | URL例 | 役割 |
|---|---|---|
| メディアトップ | /media/ | 記事全体の入口 |
| SEOカテゴリ | /media/seo/ | SEO記事の分類 |
| URL設計記事 | /media/seo/url-design/ | 個別記事 |
一方、SEO記事が数本しかない小規模サイトで「/media/marketing/seo/technical/url/」のように細分化すると、分類のための階層が増えるだけで、読者にとっての意味が薄くなる場合があります。
ディレクトリは「分類に必要か」で追加し、将来の記事数や運用体制も踏まえて決めるのが実務的です。
URLの命名規則は5項目をそろえる
URLの命名は、担当者ごとに判断すると徐々にばらつきます。制作開始時に命名規則を文章化しておくと、ページ追加時の迷いを減らせます。
| 項目 | 推奨する考え方 | 例 |
|---|---|---|
| 内容 | ページ内容を表す単語を使う | /seo-audit/ |
| 区切り | 複数語はハイフンで区切る | /url-design/ |
| 大文字・小文字 | 原則として小文字に統一する | /service/seo/ |
| 長さ | 意味を保てる範囲で簡潔にする | /case/manufacturing/ |
| 一時情報 | 年度・担当者名・final等を安易に入れない | /pricing/ |
GoogleはURLを大文字・小文字で区別して扱えるため、サーバー側で同一内容として処理できる場合でも、小文字に統一しておくとURLの重複やリンクミスを減らしやすくなります。
また、Googleは日本語を含むURLもサポートしており、対象読者の言語に合わせた単語の使用も案内しています。そのため「日本語URLだからSEOで不利」とは言えません。
ただし、日本語URLは外部ツールや共有方法によってパーセントエンコードされ、長い文字列に見える場合があります。SEO上の可否だけでなく、メール、資料、SNS、アクセス解析、CMS運用などで扱いやすいかも含めて選ぶとよいでしょう。
カテゴリ構造とURLを設計する5ステップ
新規サイトやリニューアルでは、ページごとにURLを付ける前に、全ページの役割を一覧化します。次の5ステップで進めると、サイト全体のルールをそろえやすくなります。

URLは個別ページから決めず、ページ分類から順番に設計するとルールを揃えやすくなります。
STEP1|必要なページを種類別に洗い出す
最初に、サイトで公開するページを種類ごとに分けます。
例:
- 会社情報
- サービス
- 料金
- 導入事例
- お役立ち記事
- 採用
- お問い合わせ
この時点ではURLを決めず、「何のためのページか」を整理します。
STEP2|同じ役割のページを同じカテゴリへまとめる
サービスページが複数あるなら「service」、導入事例が複数あるなら「case」のように、共通の入口を設計します。
ページ数が少ないカテゴリまで細かく分割すると、将来的に空のカテゴリや分類の迷いが増えます。現在のページ数だけでなく、今後どの領域を増やすかも考慮します。
STEP3|ディレクトリ名を固定する
同じ役割に複数の名前を使わないようにします。
たとえば記事領域を「/blog/」「/column/」「/media/」へ分散させるのではなく、役割が同じなら原則として一つにそろえます。
名称はサイト内で長く使えるものを選びます。組織名やキャンペーン名など、短期間で変更される可能性が高い名称を上位ディレクトリへ置く場合は、将来の変更コストを確認しておきます。
STEP4|スラッグの命名ルールを適用する
個別ページには、内容を短く表すスラッグを付けます。
良い例:
- /service/seo/
- /media/seo/url-design/
- /case/manufacturing/
避けたい例:
- /page123/
- /service/new-final/
- /media/seo/url_design_01/
重要なのは、英単語を使うこと自体ではなく、担当者が変わっても同じ基準で命名できることです。
STEP5|例外と変更ルールを決める
ECサイトの絞り込み、サイト内検索、並べ替え、会員ページ、多言語ページなどは、通常ページとは異なるURLが大量に発生することがあります。
Googleは、フィルタ条件の組み合わせなどによって大量のURLが生成されると、不要なクロールが増え、新しい重要ページの発見が遅くなる可能性があると説明しています。
そのため、例外URLについても制作前に「インデックスさせたいURL」「クロールさせたくないURL」「canonicalで代表URLへまとめるURL」などの方針を整理します。
検索ユーザーに見えるURLとサイト構造を分けて考える
URLを分かりやすくする目的は、検索順位対策だけではありません。ブラウザ、リンク共有、アクセス解析、社内資料などでURLを見たときに、ページの内容や所属を判断しやすくする運用上の効果があります。
一方、Google検索結果でURL階層が常にそのまま見えるわけではありません。Googleは2025年1月以降、モバイル検索結果ではURLのパンくず表示をやめ、ドメインのみを表示する仕様へ変更しました。デスクトップではパンくずが引き続き表示されます。
このため、「検索結果でURLが詳しく表示されるからクリック率が上がる」といった一点だけを目的にURLを作るのは適切ではありません。
URLは、検索ユーザーへの分かりやすさに加えて、社内での管理、ページ追加、リニューアル、計測、リダイレクト設計まで含めた長期的な情報設計として考えることが重要です。
URLを変更するときは301リダイレクトとcanonicalを使い分ける
すでに公開済みのURLを変更する場合は、設計だけでなく移行処理が必要です。ここではURL設計に必要な範囲だけ押さえます。
Googleは、恒久的にURLを移す場合、可能であればサーバー側の301または308リダイレクトを推奨しています。旧URLへアクセスしたユーザーとGooglebotを新URLへ転送し、新URLを正規URLとして扱うためのシグナルになります。
一方、canonicalは、同じまたは非常に似た内容が複数URLに存在する場合に、優先したいURLを示すための方法です。Googleは、リダイレクトとrel="canonical"をどちらも強い正規化シグナルとして説明していますが、用途は同じではありません。

旧URLを廃止するのか、重複URLを残すのか、一時転送なのかで対応方法が変わります。
| 状況 | 主な対応 |
|---|---|
| 旧URLを廃止し、新URLへ完全移行する | 301または308リダイレクト |
| 類似・重複URLを残したまま代表URLを示す | rel="canonical" |
| サイトマップで正規URL候補を伝える | XMLサイトマップ |
| 一時的な転送 | 302または307などの一時リダイレクト |
リニューアル全体のURLマッピングや公開手順は、URL設計とは別の移行作業として管理します。新規設計の段階では、「将来変えずに済むURLか」「変えた場合に旧URLとの対応を管理できるか」を確認しておくことが重要です。
公開前に確認したいURL設計チェックリスト
URL設計が完成したら、ページ単位ではなくサイト全体で確認します。
| 確認項目 | チェック内容 |
|---|---|
| 分類 | 同じ種類のページが同じディレクトリにまとまっているか |
| 階層 | 意味のない中間階層が増えていないか |
| 命名 | 内容を表す単語になっているか |
| 区切り | 複数語をハイフンで区切っているか |
| 大文字 | 大文字・小文字が混在していないか |
| 一時情報 | 年度・連番・担当者名など変更しやすい情報を入れていないか |
| パラメータ | 不要な組み合わせでURLが大量生成されないか |
| 重複 | 同一内容へ複数URLで到達していないか |
| 内部リンク | 重要ページへサイト内リンクから到達できるか |
| 変更 | 既存URLを変える場合のリダイレクト方針があるか |
このチェックで特に重要なのは、「URLだけ整っているが、実際のナビゲーションや内部リンクが別の構造になっている」という状態を避けることです。
Googleは内部リンクを、ページの発見やサイト理解に使います。URL階層、グローバルナビゲーション、カテゴリページ、パンくず、内部リンクが、それぞれ別の分類を示していないか確認しましょう。
URL設計をクロール・インデックス・構造化データなど他の技術要件とあわせて確認する場合は、テクニカルSEOの全体像も確認してください。
まとめ
SEOを意識したURL・ディレクトリ設計では、単にURLを短くしたり階層数を減らしたりするのではなく、サイトの情報分類を先に決め、その分類を一貫したURLへ落とし込むことが重要です。
実務では、次の順番で設計すると整理しやすくなります。
- ページの種類を洗い出す
- 同じ役割のページをカテゴリ化する
- ディレクトリ名を固定する
- スラッグの命名規則を統一する
- パラメータ・重複・変更時の例外ルールを決める
- 内部リンクと実際のサイト構造が一致しているか確認する
URLは公開後に変更すると、リダイレクトや計測、リンク修正など追加対応が必要になります。新規サイトやリニューアルでは、ページ制作へ入る前にURL設計表を作り、運用後も同じルールで増やせるかを確認しておくと安全です。
サイト改善・リニューアル時の確認項目を社内で整理する場合は、URL設計を含むSEOチェック資料を使い、設計漏れがないか確認してから制作へ進めると実務に落とし込みやすくなります。
参考文献・データ元
この記事で参照した情報を確認できます。
-
Google Search Central「URL Structure Best Practices for Google Search」
発表元:Google
更新日:2025-12-10
URL:https://developers.google.com/search/docs/crawling-indexing/url-structure
使用内容:説明的なURL、対象言語、ハイフン、大文字小文字、不要なパラメータ、複雑なURLによるクロール上の注意 -
Google Search Central「SEO Starter Guide」
発表元:Google
更新日:2025-12-10
URL:https://developers.google.com/search/docs/fundamentals/seo-starter-guide
使用内容:論理的なサイト整理、説明的なURL、検索エンジンとユーザーの理解 -
Google Search Central「SEO Link Best Practices for Google」
発表元:Google
更新日:2025-12-10
URL:https://developers.google.com/search/docs/crawling-indexing/links-crawlable
使用内容:内部リンクによるページ発見、ページ同士の関係理解 -
Google Search Central「Ecommerce Website Navigation Structure」
発表元:Google
更新日:2025-12-10
URL:https://developers.google.com/search/docs/specialty/ecommerce/help-google-understand-your-ecommerce-site-structure
使用内容:GoogleがURL構造だけでなくページ間のリンク関係を使ってサイト構造や相対的重要度を理解する点 -
Google Search Central「Redirects and Google Search」
発表元:Google
更新日:2026-04-14
URL:https://developers.google.com/search/docs/crawling-indexing/301-redirects
使用内容:恒久リダイレクト、一時リダイレクト、301・308の扱い -
Google Search Central「How to Specify a Canonical with
rel="canonical"and Other Methods」
発表元:Google
更新日:2026-07-10
URL:https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
使用内容:canonical、リダイレクト、サイトマップの正規化シグナル -
Google Search Central Blog「Simplifying the visible URL element on mobile search results」
発表元:Google
公開日:2025-01-23
URL:https://developers.google.com/search/blog/2025/01/simplifying-breadcrumbs
使用内容:モバイル検索結果でパンくず表示を廃止し、ドメイン表示へ簡略化した仕様 -
RFC Editor「RFC 3986: Uniform Resource Identifier (URI): Generic Syntax」
発表元:IETF / RFC Editor
公開:2005-01
URL:https://www.rfc-editor.org/info/rfc3986/
使用内容:URIの一般構文、scheme・authority・path・query・fragmentの構成
‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
関連記事
- › INDEX削除(インデックス削除)とは?検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド|LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの確認方法|孤立ページ・深度・アンカー偏りを改善
- › ページがインデックスされない原因は?Search Consoleで未登録・除外・重複URLを確認
- › JavaScript SEOの確認方法|表示・内部リンク・登録状況
- › クロールバジェットの確認方法|無駄なクロールと改善優先度
- › 構造化データの確認方法|エラー・本文との不一致・重複を検証
- › 多言語ページの言語・地域指定を確認|相互参照・正規URLをチェック
- › 絞り込み検索のSEO確認方法|URL増加・クロール・重複を防ぐ
- › SEOリダイレクトの確認方法|多段転送・ループ・誤転送を検出
- › robots設定のSEO確認方法|クロール許可と登録制御の矛盾を確認
- › ページネーションのSEO確認方法|正規URL・内部リンク・クロール
- › サイト移行後のSEO確認方法|転送・正規URL・順位変動を確認
- › 404・soft 404のSEO確認|リンク切れ・消失URLを修正
- › SEOリリース前チェックの作り方|noindex・canonical・robots・リダイレクトの事故を防ぐ
- › 画像SEOの確認方法|alt・画像URL・遅延読み込みを確認
- › 求人ページの構造化データを確認|給与・勤務地・期限の不一致
- › サイト内検索ページのSEO確認|noindex・クロール・重複URL
- › サイトリニューアルでSEO評価を落とさない移行方法|URL・301・計測・公開手順
- › サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準
- › サブディレクトリとサブドメインの違い|SEO・運用の判断基準
- › リッチリザルトとは?種類・構造化データ・表示確認方法を解説



