URL構造：SEOに強いURLの設計原則

URL構造とは

URL構造とは、サイト内のページアドレスを作るためのルールの集まりです。長さ、フォルダ階層、スラッグの形式、パラメーターの使い方、プロトコルを決めます。良い構造は、人が読みやすく、クローラーが理解でき、何年も変わりません。悪い構造は、重複を生み、インデックス登録を妨げ、マーケティング方針が変わるたびにリダイレクトの書き直しを迫ります。

URLは、Googleが15年以上前からランキング要因として公式に認めている数少ないシグナルのひとつです。最も強い要因ではありませんが、最も低コストな要因のひとつです。開発時に一度設定すれば、編集なしで何年も機能します。この段階の間違いは直すのが大変です。URLを変えるたびに301リダイレクトが必要になり、検索エンジンによる再評価も始まるためです。

数字で見るURL

URLの構造：7つの要素

構造を設計する前に、URLが何でできているかを分解します。RFC 3986は7つの構成要素を定めており、SEOではuser-infoとfragment以外のすべてが関係します。

https://www.example.com:443/blog/seo/url-structure/?utm=email#summary
│  │   │            │   │                          │            │
│  │   │            │   │                          │            └─ fragment (anchor)
│  │   │            │   │                          └────────────── query (GET parameters)
│  │   │            │   └─────────────────────────────────────── path
│  │   │            └─────────────────────────────────────────── port (usually hidden)
│  │   └──────────────────────────────────────────────────────── host (domain)
│  └──────────────────────────────────────────────────────────── subdomain
└─────────────────────────────────────────────────────────────── scheme (protocol)

URLがSEOに重要な理由

URLは、検索順位に直接も間接も影響します。直接の寄与は小さく、URLに含まれるキーワードの効果は「ごくわずか」だとGoogleが繰り返し認めています。間接的な影響のほうがはるかに大きく、URLはスニペットのクリック率、ユーザーの信頼、クローラーにとっての予測しやすさを左右します。

これらのシグナルは積み重なります。単体では弱くても、組み合わさるとURLは静かで持続的な強みになります。特にロングテールでは、CTRの1%を巡る競争が厳しいため、効果が大きくなります。

良いURLの9つのルール

GoogleのURLに関する推奨事項は、この15年でほとんど変わっていません。以下の9つのルールは、公式ドキュメントと、Backlinko、Ahrefs、Mozの実証的な調査をまとめたものです。WordPressからNext.jsまで、どのスタックにも当てはまります。

• ラテン文字を使う（読者が現地に限られる場合を除く）。日本語などの非ラテン文字も、技術的にはパーセントエンコーディングで動作します。ただし、メッセンジャーではコピーしにくく、印刷すると崩れ、国際的な検索結果ではCTRが下がります。/blog/url-structure/のほうが/ブログ/url構造/より適切です。
• 単語の区切りはアンダースコアではなくハイフンにする。 Googleはハイフンを明確に推奨しています。アンダースコア_は、解析のときに単語を結合します。ボットにとってurl_structureは2語ではなく、url_structureという1つのトークンです。
• 小文字だけを使う。 URLは（UNIX系サーバーでは）技術的に大文字と小文字を区別します。/Page/と/page/は別のアドレスになり、重複が生じます。サーバー側で小文字に統一してください。
• 長さは、必要と思うより短く。最適なのは50～75文字です。これより長いURLは、スラッグに余分な単語があるか、不要なカテゴリが入っていることがほとんどです。
• フォルダの深さは最大3階層。 /category/subcategory/page/が、ほとんどのサイトの上限です。深いページにはクローラーが来にくくなり、ユーザーも移動に苦労します。
• ストップワードを入れない。スラッグからand、or、the、aを除きます。/how-to-fix-error/のほうが/how-to-fix-an-error-in-the-code/より適切です。ストップワードは、順位にも読みやすさにも役立ちません。
• キーワードは1回だけ、できるだけ前に。キーワードを2回繰り返さない（/seo/seo-guide/）。ドメインにできるだけ近い位置に置きます。ルートに近いほど、重みが大きくなります。
• スラッグにIDやハッシュを入れない。 /article-12384/や/post-a3f9b2c8/は人には意味が分からず、意味情報も増えません。テーマが伝わる、説明的なスラッグにします。
• URLを変えない。公開したアドレスは約束です。変更には必ず301リダイレクトが必要で、リンク評価の一部が失われます。構造は最初によく考えてください。

階層の深さとフォルダ構成

URLのフォルダ構成は、見た目の問題ではありません。クローラーとユーザーにとっての、サイトの地図です。クリック深度（ホームページからそのページまでのクリック数）は、Googleがそのページを再クロールする頻度や、新しいコンテンツを見つける速さと相関します。

URLの深さとクリック深度は別のものです。ページが物理的に/shop/laptops/macbook-pro-14/にあっても、強力な内部リンクによって、ホームページから1クリックの距離にできます。検索エンジンは、URLのパスと、リンクグラフ上の実際の距離の両方を見ています。

www、HTTPS、末尾スラッシュ、大文字小文字

重複を最も生みやすい技術設定が4つあります。どれもサーバー側で一度設定すれば解決します。しかし設定しないと、検索エンジンには同じページの最大8つのバージョンが見えます。

http://example.com/page
http://example.com/page/
https://example.com/page
https://example.com/page/
http://www.example.com/page
http://www.example.com/page/
https://www.example.com/page
https://www.example.com/page/

HTTPS

2018年から必須です。ChromeはHTTPのサイトを「保護されていない通信」と表示し、GoogleはHTTPSを弱いランキングシグナルとして使っています。設定は、nginxやapacheでリダイレクトを1つ書くだけです。

# nginx — 301 from HTTP to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

wwwあり、またはなし

技術的には同等です。DNSのレベルではwwwはサブドメインですが、301を設定すれば、GoogleもYandexもエイリアスとして扱います。wwwなしのほうがやや短く現代的で、wwwありはCookieの扱いに便利です（サブドメインで分けられます）。重要なルールは、どちらかに決めて、すべてのアクセスをそちらへ301リダイレクトすることです。

# nginx — 301 from www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

末尾スラッシュ

末尾のスラッシュ（/page/と/page）は、サーバーにとって別々のアドレスです。慣例では、ディレクトリは/で終わり、ファイルは終わりません。現代のサイトではすべてのページがディレクトリなので、方針は常に末尾スラッシュあり（または常になし）のどちらかに統一します。Next.jsとWordPressは、デフォルトで末尾スラッシュありです。

// next.config.ts — enforced trailing slash
const nextConfig = {
  trailingSlash: true,  // /blog/page/  instead of  /blog/page
};
export default nextConfig;

大文字小文字

ほとんどのサーバー（Linux/UNIX）で、URLは大文字と小文字を区別します。/Page/と/page/は2つのURLであり、2つの重複です。リバースプロキシまたはアプリケーションの層で、パス全体を小文字に統一してください。

# nginx — redirect URLs to lowercase (Lua module)
location ~ [A-Z] {
    rewrite ^/(.*)$ /$1 last;
    set_by_lua_block $lower_uri {
        return ngx.var.uri:lower()
    }
    return 301 $lower_uri;
}

ページ種別ごとのURLテンプレート

コンテンツの種類によって、必要なURLテンプレートは異なります。以下は、ほとんどのサイトに存在する6種類のページで実績のあるパターンです。

ECサイトは別の話題です。商品ページには、2つの方式があります。/shop/category/product/（カテゴリあり）と/shop/product/（フラット）です。前者はカテゴリのSEOに向いています（URLが所属を示すため）。後者は、リダイレクトなしで商品のカテゴリを移せます。どちらを選ぶかは、商品のカテゴリがどのくらいの頻度で変わるかによります。

多言語サイトのURL

多言語サイトでは、URLが戦略の最初の部分になります。Googleは3つの方法を推奨しており、それぞれにトレードオフがあります。

サブフォルダは、80%のケースで優れています。管理が簡単で、SSLとホスティングの費用も安く、リンク評価がすべて1つのドメインに集まります。seohead.techが使っているのも、この方法です。主言語はルートに置き、2つ目の言語は/en/の下に置いています。

ローカライズしたURLのスラッグは、意見が分かれる話題です。スラッグを翻訳すると（/en/url-structure/と/struktura-url/）、言語ごとにCTRが上がり、関連性もより正確に伝わります。一方で、維持は難しくなります。翻訳が変わるたびにhreflangとリダイレクトを管理しなければなりません。ほとんどのプロジェクトでは、ブログのスラッグだけを翻訳し、技術的なページのスラッグは1つにするのが妥協点です。

よくある間違いと修正方法

SEO監査でよく見つかるURLの間違いは8つあります。どれも1スプリントで直せます。放置すると、検索順位とクロールバジェットが少しずつ失われていきます。

• GETパラメーターによる重複。 UTMタグ、並べ替え、フィルターが、1つのページの何百ものバリエーションを作ります。修正：主となるURLへのrel="[canonical](/glossary/canonical)"と、GSCのURLパラメーターの設定。
• 末尾スラッシュの混在。 /が付くページと付かないページがあり、検索エンジンには重複に見えます。修正：規則を1つに決め、一致しないバリエーションをすべて301リダイレクトします。
• グローバルなプロジェクトでの非ラテン文字URL。 /サービス/は/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9/になります。修正：ローマ字化（転写）します（/service/）。
• 階層が深すぎる。 /shop/electronics/computers/laptops/apple/macbook-pro/は6階層です。修正：フラットな構造にして、カテゴリはファセットとして扱います。
• スラッグの代わりにIDがURLに入っている。 /article?id=12384や/post/12384/です。修正：意味のあるURLに切り替え、古いIDから301リダイレクトします。
• 301なしでURLを変更する。リダイレクトなしのアドレス変更は、リンク評価とトラフィックの損失を意味します。修正：名前を変えるときは必ず301を設定します。
• URLの大文字小文字。 /Catalog/と/catalog/は2つの重複です。修正：サーバーで小文字に統一します。
• 無限のリダイレクトチェーン。 A → B → C → Dのように続きます。リンクをたどるたびに評価が漏れます。修正：常に最終URLへ直接301リダイレクトします。

# Check redirect chains via curl:
curl -sILo /dev/null -w "%{http_code} %{url_effective}\n" \
     -L https://example.com/old-page/

# Find URLs with uppercase letters in nginx logs:
grep -E 'GET /[a-z]*[A-Z]' /var/log/nginx/access.log | head

# URL audit via Screaming Frog:
# 1. Run a full site crawl
# 2. Open the URL tab → Underscores / Uppercase / Non ASCII Characters
# 3. Export the list of problematic URLs and plan redirects

FAQ

監査やリニューアルのときによく出る、URL構造についての質問に答えます。

まとめ

URL構造は、一度決めたら何年も付き合う判断です。良いURLは、短く、人が読めて、コンテンツの階層を反映し、長期にわたって変わりません。3つの基本原則（ラテン文字の小文字、アンダースコアではなくハイフン、フォルダは最大3階層）で、よくある間違いの80%はなくせます。

まず、現在のURLを監査します。Screaming Frogの「Underscores」「Uppercase」「Non ASCII Characters」レポートを使えば、1時間で問題の一覧が手に入ります。次に、old → newの対応表を作り、301リダイレクトを設定し、内部リンクを更新します。繁忙期の前に一括移行を急がないでください。Googleの再評価には4～8週間かかります。