Domain 18 / 225
URL 構造は単純で人間に意味が分かる設計が SEO の基本
URL 構造 の要点
URL 構造はシンプルで人間に意味が分かる形が Google 推奨。単語区切りはハイフン、アンダースコアは避ける。URL は case-sensitive で `/Apple` と `/apple` は別 URL。フラグメント（#）はインデックス対象外で内容変更には使えない
なぜこれを学ぶか
URL 構造の 誤設計はクロール効率を一気に悪化させ、大規模サイトでインデックス漏れを引き起こす。 特に EC のファセットナビゲーション、カレンダー、無限スクロールでは、URL 設計次第で Googlebot が膨大な無駄ページを巡回し、本来クロールしてほしいページにリソースが回らなくなる。
メディア・EC・SaaS のリプレイス、URL 設計の初期決定で必須の知識。
学ばないと起きること
| よくある事故 | 被害 |
|---|---|
URL にアンダースコア（_）を使う | 単語区切りとして認識されにくく、人間にも検索エンジンにも分かりづらい |
URL のフラグメント（#section）でコンテンツを切り替える | フラグメント部分はインデックス対象外、SPA ルーティングで使うとインデックスされない |
大文字小文字混在 URL（/Apple と /apple）が両方存在 | 別 URL 扱いされて重複コンテンツ、評価分散 |
| ファセットナビゲーション（フィルタ追加で URL が増殖）を放置 | Googlebot が数百万 URL を巡回、クロール予算を使い果たす |
| 動的カレンダーで未来日 URL が無限生成 | クローラーが無限ループ、本来のページがインデックスされない |
| URL パラメータの順序が一定でない | 同じ内容で複数 URL ができ、重複コンテンツ判定 |
| セッション ID が URL に入る | 同じページが無数の URL として扱われ、評価分散 |
学ぶメリット
- リプレイス時に SEO 観点で URL を設計できる
- ファセットナビ / カレンダー / 検索結果ページのクロール制御を組める
- Search Console「クロール統計」で無駄クロールを発見・対処できる
- 商談で「URL 設計の良し悪しの判断基準」を即答できる
仕組み
クロール可能な URL の必須要件
公式に明記された要件:
| 要件 | 内容 |
|---|---|
| IETF STD 66 準拠 | URL の標準仕様に従う、予約文字はパーセントエンコード |
フラグメント（#）でコンテンツ切替不可 | Google は基本的に URL フラグメントをサポートしない |
| URL パラメータは標準形式 | ?key=value&key=value 形式（= で区切り、& で連結） |
これに従わないと Google はサイトを非効率にクロールするか、クロールしない可能性がある。
URL 構造のベストプラクティス
説明的な URL を使う
| OK | NG |
|---|---|
https://example.com/wiki/Aviation | https://example.com/index.php?topic=42&area=3a5ebc944f41daa6f849f730f1 |
長い ID 番号より読みやすい単語が推奨。
対象オーディエンスの言語を使う
ドイツ語向け: https://example.com/lebensmittel/pfefferminz
日本語向け: https://example.com/食料品/ペパーミント
非 ASCII 文字はパーセントエンコード（%E9%A3%9F など）でも OK だが、人間可読のためにそのまま記述するのも推奨。
ハイフン（-）で単語を区切る
| OK | NG |
|---|---|
/summer-clothing/filter | /summer_clothing/filter（アンダースコア） |
/blog/seo-basics | /blog/seobasics（連結） |
歴史的にアンダースコアはプログラミング言語の関数名（format_date）で「連結する単語」を表すため、Google は単語区切りとしてはハイフンを推奨する。
URL パラメータは少なく
OK: /products/dress?color=red
NG: /products/dress?color=red&utm_source=email&utm_medium=cpc&utm_campaign=spring&session_id=abc123&ref=xyz
不要なパラメータは削除する。utm_* は分析用に必要だが、canonical で正規 URL を指定する。
大文字小文字を一貫させる
URL は case-sensitive。/Apple と /apple は別 URL。
サーバー側で同一視するなら、すべて小文字に統一して 301 リダイレクトで揃える。
多地域サイトの URL 設計
| 構造 | 例 |
|---|---|
| ccTLD（国別ドメイン） | https://example.de |
| サブディレクトリ + gTLD | https://example.com/de/ |
| サブドメイン | https://de.example.com |
ccTLD が地域シグナルとして最も強い。サブディレクトリは管理が簡単で多くのケースで実用的。
キー概念
避けるべき URL 構造の問題
ファセットナビゲーション（追加フィルタで URL 増殖）
hotels.example.com/search?category=value
hotels.example.com/search?category=value&beach=1
hotels.example.com/search?category=value&beach=1&fitness=1
hotels.example.com/search?category=value&beach=1&fitness=1&pool=1
...
各組み合わせで別 URL が生成され、組み合わせ爆発で URL 数が無限に。
対処: robots.txt で Disallow: /search?* してクロール除外、または crawling-managing-faceted-navigation ガイドに従う。
無関係なパラメータ
referral: /search?click=6EE2BF1AF6A3D705D5561B7C3564D9C2
session: /search?sessionid=6EE2BF1AF6A3D705D5561B7C3564D9C2
sorting: /results?search_sort=relevance&search_category=25
これらは URL を無限に増やすが、コンテンツは同じ。 対処: クッキーに移行、または robots.txt で除外。
カレンダーの無限 URL
/calendar?d=13&m=8&y=2011
/calendar?d=14&m=8&y=2011
/calendar?d=15&m=8&y=2011
...
未来日も無限に生成される。
対処: 未来日へのリンクに rel="nofollow" を付けるか、robots.txt で Disallow: /calendar?*。
壊れた相対リンク
<!-- /category/community/070413/html/FAQ.htm に -->
<a href="../../category/stuff">link</a>
サーバーが存在しないページに 404 を返さないと、無限の URL が生成される（category/community/category/stuff のような）
対処: ルート相対 URL（/category/stuff）を使う。
よくある誤解
| よくある誤解 | 実際のところ | 出典 |
|---|---|---|
| URL のアンダースコアは Google が単語区切りとして認識 | 違う。歴史的に変数名で使われるため、ハイフンが推奨 | URL 構造のベスト プラクティス |
URL フラグメント（#section）でコンテンツを変えられる | Google はフラグメントをサポートしない、変えるなら History API | 同上 |
| URL の大文字小文字は Google が同一視する | しない。/Apple と /apple は別 URL | 同上 |
| 日本語 URL は SEO 上不利 | パーセントエンコード（%E9%A3%9F）または直接日本語のどちらでも OK | 同上 |
| 短い URL のほうが上位に出やすい | URL 長は直接の順位要因ではない、シンプルさは間接的に有利 | 同上 |
| ファセットナビは Google が自動で重複として処理 | 自動処理されるが、URL 数が多すぎるとクロール予算を消費 | 同上 |
| セッション ID を URL に入れて問題ない | 同じページが無数の URL になり評価分散、クッキーに移行 | 同上 |
| utm パラメータは canonical 不要 | canonical でパラメータなし URL を正規指定するのが安全 | 同上 |
実務での適用
新規サイトの URL 設計
- すべて小文字に統一（サーバーで強制）
- 単語区切りはハイフン
- ID 番号より説明的な単語
- 階層は 3-4 段以内（深すぎは避ける）
- パラメータは最小限、必要なら canonical で正規化
EC サイトのファセットナビ対策
# robots.txt 例
User-agent: *
Disallow: /search?*
Disallow: /products?*sort=*
Disallow: /products?*color=*&size=*
主要カテゴリは canonical 対象として残し、ファセット組み合わせはクロール除外。
URL 移行時のチェックリスト
- すべての旧 URL → 新 URL を 301 リダイレクト
- 新 URL が小文字統一・ハイフン区切りになっているか
- canonical で新 URL を指定
- サイトマップを新 URL で更新
- 内部リンクをすべて新 URL に張り替え
トラブル別の対処
| 症状 | 確認すべきこと |
|---|---|
| Search Console「クロール統計」で大量の URL がクロールされている | ファセットナビ / カレンダー / セッション ID の確認、robots.txt 整備 |
| 同じ商品が複数 URL でインデックスされている | 大文字小文字混在、URL パラメータの canonical 未指定 |
| SPA でインデックスされない | フラグメント（#）でルーティングしていないか、History API を使う |
| 多言語サイトの言語切替が認識されない | hreflang 設定 + ccTLD / サブディレクトリの一貫性 |
公式ソース
自己テスト
Q1. URL の単語区切りに推奨される文字は？
ハイフン（-）。アンダースコア（_）は歴史的に変数名で使われるため、単語区切りとしては推奨されない
Q2. URL の大文字小文字を Google は同一視するか？
しない。case-sensitive で /Apple と /apple は別 URL として扱われる。
サーバー側で小文字統一するか 301 リダイレクトで揃える
Q3. URL フラグメント（`#section`）でコンテンツを変えられるか？
Google は基本的に URL フラグメントをサポートしない。 JavaScript でコンテンツを変える場合は History API を使う
Q4. 日本語 URL（`/食料品/ペパーミント`）は SEO 上不利か？
不利ではない。パーセントエンコード（%E9%A3%9F）または直接日本語のどちらでも Google が処理する
Q5. ファセットナビゲーション（複数フィルタ組み合わせで URL が増殖）の問題は？
組み合わせ爆発で URL 数が無限に増え、Googlebot がクロール予算を使い果たす。 robots.txt で除外するか、専用ガイドに従って制御
Q6. URL に session ID を入れるのは推奨されるか？
推奨されない。同じページが無数の URL として扱われ評価分散する。 セッション管理はクッキーに移行する
Q7. utm パラメータが付いた URL の canonical はどう設定する？
パラメータなしの正規 URL を canonical に指定する。 これで utm 付き URL の評価が正規 URL に集約される
Q8. 多地域サイトの URL 構造で地域シグナルが最も強いのは？
ccTLD（国別ドメイン: example.de）。
ただし管理コストが高いため、サブディレクトリ + gTLD（example.com/de/）も実用的
これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。