SEO に強い URL 構造の作り方

URL は「短く、内容が推測でき、単語をハイフンで区切った小文字の形」が理想です。階層は浅くし、不要なパラメータやセッション ID は入れません。ただし URL は検索順位への影響が小さい軽いシグナルで、主役はページの中身です。URL を変えるときは 301 リダイレクトで旧 URL の評価を引き継ぎます。

執筆: JIT株式会社公開: 2026年7月17日

URL は SEO にどのくらい影響しますか？

影響はしますが小さく、URL は軽いシグナルです。分かりやすい URL はクリックや共有のしやすさに寄与し、Google もクロールの手がかりにしますが、順位を決める主役はあくまでページの中身です。URL の細かな最適化に時間をかけるより、まず本文の質を上げるほうが得られる効果は大きくなります。

はじめに、期待値を正しく置きましょう。URL は検索順位を左右する数百のシグナルのうちの 1 つにすぎず、その重みは大きくありません。同じ内容のページであれば、URL を /a1b2 から /url-structure に変えただけで順位が跳ね上がる、ということはまず起きません。それでも URL を整える価値があるのは、順位そのものより周辺の効果が効くからです。

クリック率 — 検索結果やSNSに URL が表示されたとき、内容が推測できる URL は押されやすい
共有のしやすさ — 人が口頭やチャットで伝えやすく、リンクとして貼られやすい
クロールの手がかり — 検索エンジンが URL からページの主題を軽く推測する

つまり URL は「中身を良く見せるための包装」であって、中身そのものではありません。本記事の原則は守る価値がありますが、既存 URL の細部を作り替えることに過度な労力を割く必要はない、というのが正直な出発点です。

良い URL とはどんな URL ですか？

短く、見ただけで内容が推測できる URL です。意味のある単語を使い、/p?id=8213 のような記号の羅列ではなく、/guide/url-structure のように何のページか分かる形にします。人が読んで理解でき、共有されたときにも安心して押せる URL は、検索エンジンにとっても内容の手がかりになります。

良い URL の第一条件は「短く、内容が推測できる」ことです。URL を構成する単語には、そのページを表す意味のある語を選びます。記事タイトルをそのまま長々と URL にする必要はなく、主題を表す 1〜3 語で十分です。/guide/url-structure のように、パスを見ただけで「URL 構造の解説ページだ」と分かれば理想的です。

良い URL と、避けたい URL

# 良い URL: 短く・小文字・ハイフン区切り・浅い階層
https://example.com/guide/url-structure

# 避けたい URL: 大文字・アンダースコア・不要なパラメータ・深い階層
https://example.com/Blog/2026/07/18/URL_Structure_Detail?sid=8f3a&ref=twitter

逆に、/p?id=8213 や /node/4471 のような意味を持たない ID だけの URLは、人にも検索エンジンにも中身を伝えません。 CMS が自動で振る番号ベースの URL は、可能なら意味のあるスラッグ（URL 末尾の単語部分）に変更しておくと、後々まで読みやすい資産になります。

単語の区切りはハイフンとアンダースコアのどちらがいいですか？

ハイフン（-）を使います。Google はハイフンを単語の区切りとして認識しますが、アンダースコア（_）は区切りとして扱わないため、url_structure は urlstructure という 1 語と見なされることがあります。複数の単語をつなぐときは必ずハイフンで区切り、スペースや全角記号は URL に含めないのが安全です。

複数の単語を URL でつなぐときの区切り文字は、ハイフン（-）に統一します。Google は公式に、単語の区切りにはハイフンを推奨し、アンダースコア（_）は使わないよう案内しています。理由は単純で、検索エンジンがハイフンを「語の区切り」として解釈するのに対し、アンダースコアは区切りとして扱わないためです。

区切り文字による、単語の認識のされ方
書き方	認識のされ方	評価
`url-structure`	url と structure の 2 語として読まれる	推奨
`url_structure`	urlstructure という 1 語として読まれることがある	非推奨
`urlstructure`	語の境界が分からない	避ける

スペースや全角の記号を URL に含めるのも避けます。スペースは %20 にエンコードされて読みにくくなり、全角記号は環境によって化けることがあります。使う文字は半角の英小文字・数字・ハイフンに絞るのが安全です。

大文字や階層、パラメータで気をつけることは？

小文字に統一し、階層は浅く保ち、不要なパラメータは付けません。多くのサーバーは大文字小文字を区別するため、/Page と /page が別 URL として重複する恐れがあります。並べ替えや計測用のパラメータ、セッション ID を URL に含めると、重複ページや無限クロールの原因になります。

残りの原則を 3 つまとめて押さえます。いずれも「同じ内容が複数の URL から見えてしまう」重複を防ぐための工夫です。重複の弊害は canonical（正規 URL）のページで詳しく扱っていますが、URL 設計の段階で避けられるものは避けておくのが確実です。

小文字に統一 — サーバーが大文字小文字を区別すると、/Page と /page が別 URL になり重複する
階層は浅く — /a/b/c/d/e/page のような深い階層は避け、意味のある区切りだけを残す
不要なパラメータを入れない — 並べ替え・計測用のクエリやセッション ID は、重複と無限クロールの原因になる

パラメータで URL が無限に増える例

# 中身は同じなのに、パラメータの有無や並び順で URL が無数に増える例
/products/shoes?color=red&sort=price&sid=8f3a2b
/products/shoes?sort=price&color=red&sid=1c9d0e

# 見せる URL は 1 つにまとめ、正規 URL を canonical で集約する
/products/shoes

特にセッション ID を URL に埋め込む古い実装は要注意です。訪問者ごとに URL が変わるため、検索エンジンから見ると同じページが無数の別 URL として存在することになり、クロール予算を浪費します。状態は Cookie で持ち、URL には残さないのが原則です。

日本語（マルチバイト）の URL を使ってもいいですか？

使えますが、注意が必要です。日本語 URL はブラウザ上では読めますが、コピーや共有をするとパーセントエンコードされ、%E6%97%A5… のように長く読みにくい文字列に変わります。SNS やメールに貼ったときの見え方が悪く、リンク切れの温床にもなるため、英数字とハイフンで組むほうが無難です。

日本語（マルチバイト文字）を含む URL は、技術的には有効で、検索エンジンも扱えます。ブラウザのアドレスバーでは /解説/url-構造 のように読める形で表示されることもあります。しかし実際にコピーして貼り付けると、日本語部分はパーセントエンコードされ、次のように大きく膨らみます。

日本語 URL の、表示と実体の違い
場面	見え方
ブラウザの表示	`/解説`
コピー・共有したとき	`/%E8%A7%A3%E8%AA%AC`

この長い文字列が SNS・メール・チャットに貼られると読みにくく、途中で改行されてリンクが切れることもあります。日本語 URL が SEO 上で不利になるわけではありませんが、共有時の見た目とリンク切れのリスクを考えると、パス部分は英数字とハイフンで組んでおくほうが無難です。

URL を変更するときは何をすればいいですか？

旧 URL から新 URL へ 301 リダイレクト（恒久的な転送）を設定します。これにより、旧 URL が集めてきた検索評価と外部からのリンクを新 URL に引き継げます。リダイレクトを張らずに URL だけ変えると、旧 URL はリンク切れになり、それまでの評価を失います。URL の変更は本当に必要なときだけにします。

URL を後から変更するときに絶対に欠かせないのが 301 リダイレクトです。301 は「恒久的に移動した」を意味するステータスコードで、旧 URL にアクセスした利用者と検索エンジンを、自動的に新 URL へ転送します。これにより、旧 URL がそれまでに集めてきた検索評価と外部リンクを新 URL に引き継げます。

nginx での 301 リダイレクト

# nginx: 旧 URL を新 URL へ 301（恒久）で転送する
location = /old-page {
  return 301 /new-page;
}

Next.js での 301 リダイレクト

// Next.js: next.config.js の redirects で 301 を返す
// permanent: true が 301（恒久）、false は 307（一時）になる
module.exports = {
  async redirects() {
    return [
      { source: "/old-page", destination: "/new-page", permanent: true },
    ];
  },
};

転送先は、できるだけ関連する新ページへ 1 対 1 で向けます。移動先が無いからと、すべての旧 URL をトップページへまとめて転送すると、検索エンジンはそれを「ソフト 404（実質的な存在しないページ）」と見なし、評価を引き継がないことがあります。仕組みの詳細は canonical と合わせて理解しておくと、重複対策と移転対策を混同せずに済みます。

URL 構造をどう確認すればいいですか？

ブラウザのアドレスバーと Search Console で、実際の URL を目視で点検します。大文字やアンダースコア、不要なパラメータ、深すぎる階層が無いかを確認し、過去に変更した URL が 301 で正しく転送されているかも見ます。本ツールでも、canonical やリダイレクトの設定状況を診断できます。

確認は難しくありません。まずブラウザのアドレスバーで、自分のサイトの主要ページの URL を眺め、大文字・アンダースコア・不要なパラメータ・深すぎる階層が無いかを目視します。次に Search Console のインデックス状況で、意図しない URL がインデックスされていないか、過去に変更した URL が 301 で正しく転送されているかを確認します。

URL 構造は単独で完結するテーマではなく、内部リンクの貼り方やサイトマップへの掲載と一体で機能します。整った URL を作ったら、そこへ内部リンクを通し、サイトマップに載せてはじめて、検索エンジンに正しく届きます。本ツールの診断でも、canonical やリダイレクトの設定状況を実測できます。

参考にした一次情報

Google 検索セントラル — URL 構造のベストプラクティス