URL構造とは|『サイト階層を表現する設計』の本質と設計5原則

『URL構造』って、ぶっちゃけ何のことか、説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SEOの本を開いてもWeb制作の現場を見ても、URL構造、URL構造と言われていますよね。「URLは短く」「キーワードを入れろ」「日本語URLは使うな」、いろんな主張が飛び交っているんです。いやちょっと待ってください。そもそもURL構造って何ですか?

なんとなくのイメージはあると思います。「サイトのアドレスの書き方でしょう?」と。でも「じゃあなぜ、ある会社のサイトはURLが整理されて検索順位が安定していて、別の会社のサイトはURLがぐちゃぐちゃで順位が乱高下するのか?」と聞かれると、意外と詰まるんですよね。これ、自分だけだと思ってませんか?

うちの事業でWordPressサイトを6サイト運用してきて、URL設計の相談は本当に多いんです。話を深掘りしていくと、「URL=ファイルパスの書き方」という認識で止まっている方が大半なんですよね。だからURL変更で順位が落ちたり、階層が深すぎてクロール対象から外れたり、パラメータ濫用でcanonicalが壊れたり、こういうトラブルが頻発します。

うちで観察してわかったのは、URL構造は単なる「アドレスの書き方」ではなく、「サイトの意味的階層をユーザーと検索エンジンに同時提示する設計」だということ。物理ファイルの場所を示すものではなくて、コンテンツの論理的な位置関係を表現する設計図なんですよね。

今回はその今さら聞けないURL構造を、表面的な解説ではなく、設計の核心と運用判断まで一気に深掘りしていきます。読み終わる頃には、自分のサイトのURLを紙に書き出して再設計できるレベルになっているはずです。

結論:URL構造の核心は「ファイルパス」ではなく「サイト階層の意味的表現」

URL構造の本当の正体は、「サイトの意味的階層をユーザーと検索エンジンに同時提示する設計」なんです。サーバー上の物理位置を示すものではなく、コンテンツの論理的な位置関係を表現するための設計図なんですよね。

うちの事業の体感として、URL構造を意識的に設計してあるサイトは、検索エンジンからの評価が安定するんです。逆にURL設計を後回しにしたサイトは、リライトや再構築のたびにURLが変わってしまって、その都度SEO評価がリセットされるんですよね。

URL構造には3つの役割があります。1つ目は「ユーザーが現在地を把握する」役割、2つ目は「検索エンジンがサイト階層を理解する」役割、3つ目は「外部リンクで評価が集まる単位を定義する」役割。この3つが同時に成立するURLを設計するのが本質なんです。

URL構造の真の価値はSEOではなくて、「サイト全体の論理整合性を担保する設計図」になることなんですよね。URLが整理されているサイトは、サイト構造そのものが整理されているということ。逆もまた然り、URLがぐちゃぐちゃなサイトは、サイト構造もぐちゃぐちゃで、運用負荷が高いんです。

なぜ「URL」と名付けられたのか

もう少し深く掘ります。なぜ「URL」と名付けられたのか、命名の背景を整理します。

URLは「Uniform Resource Locator」の頭文字なんです。日本語に直訳すると「統一されたリソースの位置特定子」、つまり「インターネット上のリソースを一意に指し示すための統一形式」を意味します。1994年、Webの発明者Tim Berners-Lee氏が中心となって設計しました。

その後、URLはIETF(Internet Engineering Task Force)のRFC 3986という国際標準で厳密に規定されました。スキーム(https)、ホスト(example.com)、パス(/category/article)、クエリ(?id=1)、フラグメント(#section)、こういう要素で構成される設計が世界共通で運用されています。

命名の意図は「Uniform=統一」にあるんですよね。世界中のどのサーバーでも、どのブラウザでも、同じ書式でリソースを指定できる、これがWebの根幹です。URLが統一形式じゃなかったら、ハイパーリンクは成立しないんです。これ、Web全体を支える地味だけど決定的な発明なんですよね。

初期のWebでは、URLは単純に「サーバー上のファイルパス」として運用されていました。example.com/about.htmlのような形ですね。でも検索エンジンの発展とコンテンツの大量化で、URLは「ファイルパス」から「論理階層の表現」へと役割が拡張していきました。これが現在のURL構造論の起点です。

うちの事業の体感として、2010年代に入ってから「セマンティックURL」という考え方が広まりました。URLそのものが意味を持つように設計する、例えば/category/seo-basicsのように、見ただけで内容が推測できる形ですよね。これがURL構造を「設計」する文化の始まりだったんです。

近年では、URL構造はSEO以上に「サイトの情報設計(IA: Information Architecture)」の一部として扱われています。UXデザイン、コンテンツ設計、SEO、Web開発、この4領域が交差する場所がURL構造設計なんですよね。だから、URLを軽く扱うと、サイト全体の整合性が崩れるんです。

URL構造の現場で何が起きているか

URL構造の現場で、具体的に何が起きているか。5段階で整理します。

ステージ1:サイト階層設計

サイトのコンテンツをカテゴリと階層に整理する段階です。トップページ→大カテゴリ→中カテゴリ→個別記事、こういう論理階層を先に決めるんですよね。階層数は基本3階層以内が業界の標準。4階層以上になると、ユーザーも検索エンジンも迷子になります。

うちでサイト設計するときは、ホワイトボードに書き出してから階層を決めるんです。例えばマーケティング情報サイトなら、/seo/、/content-marketing/、/email-marketing/、こういう大カテゴリを3〜5個に絞ります。これ、最初から正解を出すんじゃなくて、何度も書き直して整理する地味な作業なんですよね。

ステージ2:命名規約の策定

URLに使う文字・記号・単語の規約を決める段階です。英小文字のみ、単語区切りはハイフン、複数形か単数形、年月日を入れるか入れないか、こういうルールを最初に明文化するんです。途中で変えるとサイト全体のURLが壊れるんですよね。

業界の標準は、英小文字+ハイフン区切り+短い英単語、です。例えば/seo-basics/、/content-marketing-strategy/、こういう形ですね。アンダースコア(_)はGoogleが単語区切りとして認識しないため非推奨。日本語URLはエンコード後可読性が壊滅的に下がるため、英語化が標準なんです。

ステージ3:既存URLの監査

既存サイトの全URLをリストアップして、設計方針と照合する段階です。Screaming FrogやSitebulbなどのクローラーで全URLを取得し、階層深度・URL長・パラメータ有無・重複コンテンツ、こういう観点で監査します。

監査で見つかる典型的な問題は、(1)階層が深すぎる末端ページ、(2)パラメータ濫用で同一コンテンツが複数URLに分散、(3)日本語URLで可読性ゼロ、(4)スラッシュ(/)の有無で別URL扱い、こういうパターンですよね。これらを優先度順に整理して、修正計画を立てます。

ステージ4:正規化とcanonical設定

同一コンテンツに複数URLが存在する状態を解消する段階です。www有無、httpsとhttp、末尾スラッシュ有無、index.htmlあり/なし、パラメータ違い、こういう要因で同じページが複数URLになることがあるんですよね。これを正規化(URL正規化)で1つに統一します。

具体的な手段は、(1).htaccessや301リダイレクトで物理的に統合、(2)で論理的に統合、の2つ。物理統合のほうが評価集約効果が強いけど、状況によってはcanonicalで対応する場合もあります。これ、サイトのSEO評価に直接効くんです。

ステージ5:継続監視と改善

URL構造は一度設計したら終わり、ではないんですよね。Google Search ConsoleでクロールエラーやURLパラメータの状況を毎月監視し、新規コンテンツ追加時に階層がブレないかチェックします。サイトが成長するほど、URL設計の維持にコストがかかるんです。

うちで運用していて感じるのは、URL構造の維持は「掃除」と同じなんですよね。週次・月次で定期的にURL監査を回さないと、新規ページのURLが既存ルールから外れていって、気づいたら全体がぐちゃぐちゃになるんです。これ、地味だけど決定打になる運用作業です。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

住所表記に置き換えてみます。日本の住所って、「東京都渋谷区神宮前1-2-3」みたいに書きますよね。これ、よく見ると論理階層になっているんです。都道府県→市区町村→町名→番地、と上から順に絞り込んでいく構造です。

逆に「神宮前1-2-3、渋谷区、東京都」と書かれたらどうですか?読みにくいですよね。情報の論理階層が逆順で、現在地を把握するのに余計な認知コストがかかります。住所表記の順序は、人間が場所を理解する自然な順番に合わせて設計されているんです。

URL構造もまったく同じなんですよね。example.com/seo/keyword-research/というURLは、「example.comというサイトの→SEOカテゴリの→キーワードリサーチに関するページ」と論理階層が順番に伝わります。これ、住所表記の構造とそっくりなんです。

もう1つ住所の話で面白いのは、「番地が深すぎる住所は届きにくい」という現象。例えば「東京都渋谷区神宮前1丁目2番3号△△ビル4階の5号室の倉庫A-12」みたいに10階層もあると、郵便配達員でも迷子になるんですよね。これ、URLも同じで、4階層以上深いページは検索エンジンも巡回を諦めます。

うちの事業でWordPressサイトを設計するとき、必ず「住所のアナロジー」を使って説明します。「都道府県(大カテゴリ)→市区町村(中カテゴリ)→番地(個別記事)、3階層で住所が完結する設計にしましょう」と。これ、業界用語を使わなくても伝わるんですよね。

あと、住所表記でやってはいけないのが「途中で表記ルールがブレる」こと。同じ街なのに、ある通りでは「丁目」表記、別の通りでは「街区」表記、こういうのが混在すると配達ミスが多発します。URL構造でも同じで、ある時期は/blog/article-1/、別の時期は/articles/2026/04/post-1/、こうやって命名規約がブレると、サイト全体の整合性が崩れるんです。

URL構造設計の5原則