サイト構造の設計で押さえる項目一覧｜クロール改善をAIで

「この前公開したあの記事、どのカテゴリに入れたっけ」「似たテーマの記事がお知らせとコラムに分かれて置いてある」「URLの付け方が担当者ごとにバラバラ」——記事数が増えてきたオウンドメディアの定例会議で、こんな会話に心当たりはないでしょうか。記事は3年で200本を超えたのに、サイトのどこに何があるか、運営者自身が説明できない。実はこの状態、困っているのは人間だけではありません。検索エンジンのクローラーも同じように迷子になっており、構造の乱れがクロールの効率と検索評価を静かに下げている可能性があります。本記事では、サイト構造の設計で押さえるべき項目を、階層設計・URL設計・ナビゲーション・サイトマップ・運用ルールの順に一覧で整理し、AIを使った構造監査の手順まで解説します。

サイト構造がSEOに効く3つの理由

サイト構造とは、トップページ・カテゴリページ・個別記事といったページ同士の階層関係と、それを表現するURL・ナビゲーションの設計のことです。これが検索評価に効く理由は3つあります。1つ目がクローラビリティ。検索エンジンのクローラーはリンクをたどってページを発見するため、整理された構造のサイトは新しいページの発見も更新の再クロールも速くなります。逆に、どこからもリンクされていないページはインデックスすらされないことがあります。

2つ目が評価の伝わり方です。ページの評価はリンクを通じてサイト内を流れます。トップページから各カテゴリへ、カテゴリから記事へと整った経路があれば、サイトが得た評価が体系的に行き渡ります。またテーマごとに記事がまとまっていると、「このサイトはこの領域に詳しい」というテーマ性の把握もされやすくなります。同じ30本の記事でも、1つのテーマに束ねられているのと散らばっているのとでは、伝わり方が違うのです。

3つ目が回遊性、つまり読者側の使い勝手です。関心のあるテーマのカテゴリを開けば関連記事が並んでいる。今読んでいる記事の次に読むべき記事が自然に見つかる。この状態は滞在時間や再訪問を伸ばすだけでなく、BtoBでは資料請求や問い合わせへの導線設計の土台にもなります。構造は検索エンジンと読者の両方に対する情報整理だと捉えると、以降の設計項目の意味が理解しやすくなります。

基本形は「トップ→カテゴリ→記事」の3層

サイト構造の基本形は、トップページを頂点に、カテゴリページが中間にあり、その下に個別記事がぶら下がるピラミッド型です。オウンドメディアであればトップ→カテゴリ→記事の3層が出発点で、記事数が多い場合はカテゴリの下にサブカテゴリを挟んだ4層までが現実的な範囲です。この形が優れているのは、どのページもトップから少ないクリックで到達でき、テーマのまとまりがそのまま構造に現れるからです。

設計の手順は、記事から考えるのではなく読者の関心テーマから考えるのがコツです。まず自社の読者が調べるテーマを大きく分類し、それをカテゴリとして立てる。次に既存記事と今後の企画をそのカテゴリに割り振ってみる。どのカテゴリにも入らない記事が大量に出るなら分類の切り口が実態に合っていませんし、1つのカテゴリに全体の半分が集中するなら、そのカテゴリは分割の候補です。

カテゴリの数は、立ち上げ期のメディアなら5〜8個程度から始めるのが扱いやすい規模感です。少なすぎると分類の意味がなく、多すぎると1カテゴリあたりの記事が数本ずつになって、まとまりとしての厚みが出ません。大切なのは、カテゴリ一覧を見ただけでサイトの守備範囲が伝わることです。カテゴリはサイトの目次であり、検索エンジンへの自己紹介でもあります。

「浅い階層」の本当の意味：深さよりクリック数

サイト構造の解説でよく登場する「階層は浅く」という原則は、誤解されがちです。ここでいう階層とは、URLのディレクトリの深さそのものではなく、トップページから何回クリックすれば目的のページに着くかというリンク上の距離を指します。実務の目安としてよく使われるのが、重要なページへはトップから3クリック以内で到達できるようにする、という基準です。

なぜクリック距離が問題になるのか。クローラーはリンクをたどって巡回するため、トップから遠いページほど発見が遅れ、クロールの頻度も下がる傾向があるからです。また、リンクの経路が長いほど評価の流れも細くなります。ここで重要なのは、URLのディレクトリが深くても、トップやカテゴリから直接リンクされていればクリック距離は短くなるという点です。つまりURLの深さとリンクの距離は別物で、SEOでより効くのは後者です。

実際に問題になりやすいのは、古い記事が一覧ページの10ページ目より奥に沈んでいて、たどり着くリンク経路が実質存在しないケースです。カテゴリの細分化や人気記事・関連記事からのリンクで、価値のある古い記事への経路を保つ。「浅くする」とは、ディレクトリを無理に平らにすることではなく、すべての重要ページへ短い経路を確保することだと覚えてください。

カテゴリ設計の実務：読者の探し方に合わせて割る

カテゴリ設計で最初に決めるべきは、分類の軸です。よくある失敗が、社内の組織や商材のラインナップでカテゴリを割ってしまうこと。読者は自社の組織図を知りませんし、興味もありません。カテゴリの軸は読者が情報を探すときの頭の中に合わせます。課題別（集客・育成・分析など）、業務別（経理・人事・情シスなど）、目的別（比較検討・導入手順・トラブル解決など）が代表的な切り口です。

次に、1記事1カテゴリの原則を決めておきます。多くのCMSでは記事を複数カテゴリに登録できますが、乱用すると同じ記事が複数の場所に現れて構造が曖昧になり、カテゴリページ同士の内容も重複していきます。分類を補助したい場合は、主分類はカテゴリ、横断的なラベルはタグと役割を分けるのが定石です。タグは「AI活用」「テンプレート付き」のような、カテゴリをまたぐ属性に使います。

そしてカテゴリページ自体を育てる意識を持ちましょう。カテゴリページは記事の置き場ではなく、そのテーマの入り口ページです。カテゴリの冒頭に短い説明文を置き、代表的な記事への導線を整えるだけでも、テーマの入り口としての体裁が整います。検索結果で「◯◯ 記事一覧」的な中間的なキーワードを拾うのは、多くの場合このカテゴリページです。

URL設計の基本：短く・意味が通る・ASCIIで

URL設計には、Googleが公式に推奨するベストプラクティスがあります。要点は3つです。第一に、意味の通る単語を使うこと。Googleのドキュメントは、内容と無関係な長いID番号の羅列よりも、ページ内容を表す単語で構成されたURLを推奨しています。第二に、単語の区切りにはアンダースコアではなくハイフンを使うこと。これも公式に明記されている推奨事項です。第三に、短く保つこと。深すぎる階層や余計なパラメータは、管理もクロールも複雑にします。

日本語サイトで悩むのが、URLに日本語を使うかどうかです。技術的には使えますが、日本語などASCII以外の文字はURL上でパーセントエンコードという変換を受けるため、コピーして共有すると「%E3%82%B5」のような長い符号列になります。リンクとして共有されにくく、管理画面や解析ツールでも読みにくいため、実務では記事のスラッグは意味の通るローマ字か英単語のASCII文字列にするのが無難です。この記事のURLもその方針で付けられています。

項目	推奨	避けたい例
文字種	半角英数字とハイフン（ASCII）	日本語・全角文字（共有時に長い符号列になる）
単語の区切り	ハイフンで区切る（seo-guide）	アンダースコア（seo_guide）や単語の連結（seoguide）
長さ・構成	内容が伝わる単語を2〜4語程度	自動発行の長いID、日付や連番だけのURL
階層	サイト構造と対応した浅いディレクトリ	意味を持たない深い入れ子、不要なパラメータ付きURL

URLは「後から変えない」が鉄則

URL設計でもっとも重要な原則は、意外にも「良いURLを付ける」ことではなく「一度公開したURLを変えない」ことです。URLを変更すると、そのページに集まっていた被リンクや検索評価は旧URLに紐づいたままになります。301リダイレクトで新URLへ引き継ぐ手当てはできますが、設定の手間がかかるうえ、サイト内の内部リンクの張り替え、サイトマップの更新まで含めると、変更のコストは想像以上に大きくなります。

だからこそ、最初の設計で「変えなくて済むURL」を決め切ることに価値があります。具体的には、URLに変わりやすい要素を入れないことです。年号（2026など）を入れると翌年に変えたくなります。組織名やサービス名の変更が見込まれるなら、それもディレクトリ名に使わない。カテゴリ名をURLに含める設計は構造が伝わりやすい反面、カテゴリ再編のたびにURLが変わるリスクを抱えるため、記事のURLはカテゴリに依存しない浅い設計にする判断もあります。

それでも変更が避けられない場合（サイト移転・大規模リニューアル）は、旧URLから新URLへの対応表を作り、1対1の301リダイレクトを漏れなく設定します。このときリダイレクトの対応表はリニューアル計画の最初に作るのが鉄則です。リニューアル後に流入が急減する事故の多くは、この対応表を後回しにして旧URLを大量に404にしてしまうことから起きています。

パンくずリストとナビゲーションの整え方

階層とURLを設計したら、それをページ上で表現するのがナビゲーションです。まずパンくずリスト。「トップ > カテゴリ名 > 記事名」という現在地表示は、読者が迷わないためだけのものではありません。クローラーにとってもページの階層関係を伝えるリンク経路であり、構造化データでマークアップすれば検索結果にサイト内の位置が表示されることもあります。全記事に、実際の階層と一致したパンくずを設置するのが基本です。

グローバルナビゲーション（全ページ共通のメニュー）には、主要カテゴリを並べます。ここで大事なのは網羅ではなく取捨選択です。20項目が並ぶメニューは、読者にもクローラーにも「どれが重要か」を伝えられません。ナビゲーションは重要度の宣言だと考えて、本当に入り口にしたいページを厳選します。フッターには、カテゴリ一覧・運営者情報・問い合わせなど、全ページから到達できるべきページをまとめます。

あわせて点検したいのが、リンク切れと孤立ページです。カテゴリ再編や記事の削除を重ねると、どこからもリンクされていない記事や、存在しないページへのリンクが残ります。こうしたほころびはクロールの無駄と読者の離脱を生むため、後述する定期監査の点検項目に含めておきます。

XMLサイトマップ：クローラーへの送り状

XMLサイトマップは、サイト内のURL一覧を検索エンジンに直接伝えるファイルです。リンクをたどる通常のクロールを補完するもので、新しいページの発見を早める効果が期待できます。特に、公開直後でリンクの少ない新規サイト、ページ数の多い大規模サイト、更新頻度の高いメディアでは整備の価値が高くなります。多くのCMSやSEOプラグインには自動生成機能があるため、まず自社サイトのサイトマップが生成されているかを確認しましょう。

整備のポイントは2つです。第一に、Search Consoleからサイトマップを送信し、読み込みエラーが出ていないかを確認すること。第二に、サイトマップの中身を正規URLだけにすることです。リダイレクト元の旧URL、noindexを付けたページ、パラメータ付きURLなどが混ざっていると、検索エンジンに矛盾したシグナルを送ることになります。サイトマップは「インデックスしてほしいURLの公式リスト」だと考えて、実態と一致させておきます。

• XMLサイトマップに載せたからといってインデックスが保証されるわけではない。登録の判断は検索エンジン側にある
• 記事の更新日（lastmod）を正しく出力しておくと、更新の再クロールを促す手がかりになる
• 読者向けのHTMLサイトマップ（サイト内の一覧ページ）とXMLサイトマップは別物。役割が違うため混同しない

構造を崩す典型パターンを知っておく

設計項目を押さえたところで、運用の中で構造が崩れていく典型パターンを見ておきます。崩れは一晩では起きません。小さな例外の積み重ねが、数年後の「ぐちゃぐちゃなサイト」を作ります。

• 記事のたびにカテゴリを増やす：分類の軸が崩れ、記事1本だけのカテゴリが乱立する。新カテゴリは判断ルールを通してから作る
• 置き場に迷った記事を「お知らせ」や「その他」に入れる：雑多入れが肥大化し、テーマのまとまりが失われていく
• URLの命名規則が担当者ごとに違う：日本語スラッグ・日付入り・連番が混在し、後から統一するにはリダイレクトの山になる
• リニューアルのたびに構造を白紙から作り直す：URLが総入れ替えになり、蓄積した評価を引き継ぐリダイレクト作業が膨大になる

共通するのは、判断がその場しのぎで行われていることです。構造に関わる変更——カテゴリの追加・記事の分類・URLの命名——には、個人の裁量ではなく文書化されたルールを通す。これだけで崩れの速度は大きく変わります。ルールの中身は、この後の運用セクションで具体化します。

現状を棚卸しする：構造監査の4ステップ

既存サイトの構造を立て直すには、まず現状の見える化からです。次の4ステップで棚卸しを行います。

棚卸しで意外なほど多く見つかるのが、運営者自身が忘れていたページです。昔のキャンペーンページ、テスト公開のまま残ったページ、旧サイトから引き継いだ記事。これらは放置せず、残す・統合する・閉じるのいずれかに仕分けます。構造の設計図は、現状を全部知ってからでないと引けません。

AIでサイト構造を監査する

この棚卸しと監査は、AIに手伝わせると工数を大きく圧縮できます。URL一覧とカテゴリ情報を渡せば、分類の偏りや命名規則の不統一といったパターンの検出はAIの得意分野だからです。数百行の一覧を人が目視でチェックする代わりに、AIに一次スクリーニングをさせて、人は指摘された箇所の妥当性を判断する分担にします。プロンプトの例を挙げます。

以下は自社サイトの全ページ一覧です（URL／タイトル／カテゴリ／公開日）。
（ここに一覧を貼り付け）
サイト構造の観点で次の点を監査してください。
(1)カテゴリごとの記事数の偏り（多すぎ・少なすぎの指摘）
(2)URLの命名規則の不統一（日本語・日付・連番・長すぎるものの列挙）
(3)タイトルから見てカテゴリと内容が合っていない可能性のある記事
(4)テーマが近く、同じカテゴリに集約すべきに見える記事群
指摘には必ず該当URLを添え、判断に迷うものは「要確認」としてください。

AIの指摘はあくまで候補です。カテゴリの再編やURLの統一は、実施すればリダイレクトや内部リンクの張り替えを伴う変更なので、実行の判断は流入データと工数を見て人が下すのが原則です。それでも、これまで「時間ができたらやろう」と先送りされてきた構造監査が、半日で一次レポートまで進むようになる効果は大きいはずです。四半期に一度の定期監査として組み込むことをおすすめします。

さらに一歩進めるなら、Search Consoleのデータとの突き合わせです。URL一覧にページごとの表示回数・クリック数を列として加えてからAIに渡すと、「流入がほぼゼロの記事が特定のカテゴリに集中している」「トップから遠いページほど表示が少ない」といった、構造と成果の関係までの一次分析をさせられます。構造の問題は感覚では優先順位を付けにくいものですが、数字と重ねれば「どこから直すと効果が大きいか」を根拠を持って議論できるようになります。データのエクスポートの手間を含めても半日仕事です。監査の頻度を保つためにも、一覧の作り方とプロンプトはドキュメント化して、担当者が替わっても同じ品質で回せるようにしておきましょう。

増築のルール：新カテゴリを作る判断基準

構造を長持ちさせる鍵は、増築の統制です。サイトは生き物で、事業の変化とともに扱うテーマは必ず増えます。そのとき無秩序に増やさないために、新カテゴリを作る条件をあらかじめ文書にしておきます。たとえば「そのテーマで既に記事が5本以上ある、または半年以内に5本の企画が確定している」「既存カテゴリのどれにも7割以上重ならない」「担当者2名以上の合意がある」のような条件です。

この条件の意味は、カテゴリを記事の実績に後追いで与えることにあります。先にカテゴリという箱を作ってから記事を集めようとすると、記事1本だけの空き箱が乱立します。逆に、記事が自然に溜まってきたテーマを昇格させる方式なら、カテゴリは常に中身の詰まった状態を保てます。サブカテゴリへの分割も同じ考え方で、親カテゴリの記事数が一定数を超え、その中に明確なサブテーマのまとまりが見えたときに行います。

なお、カテゴリの改廃はURLやナビゲーションに波及するため、実施は年に1〜2回のタイミングに集約するのが安全です。思いついたときに随時変更するのではなく、「構造の変更は四半期レビューでまとめて審議する」と決めておくと、変更の影響確認も一度で済みます。審議の記録を残しておけば、担当者が交代しても「なぜこのカテゴリ構成なのか」の経緯が引き継がれ、場当たり的な再編を防ぐ抑止力にもなります。

崩れさせない運用：公開前チェックと定期点検

最後の仕上げが、日々の運用への組み込みです。構造は設計した瞬間から崩れ始めます。それを防ぐ第一の仕組みが、記事公開前のチェックリストです。分類は適切か、URLは命名規則に沿っているか、パンくずは正しい階層を示しているか。公開フローにこの確認を1ステップ挟むだけで、崩れの大半は入り口で止まります。

• カテゴリは既存の分類ルールに沿って1つ選んだか（迷った場合の相談先も決めておく）
• URLスラッグは命名規則どおりか（ASCII・ハイフン区切り・内容が伝わる2〜4語・年号なし）
• タイトル・パンくず・カテゴリの表示が矛盾していないか
• 関連する既存記事からのリンクを1本以上設置したか（孤立ページを作らない）
• XMLサイトマップに新URLが反映されているか

第二の仕組みが定期点検です。四半期に一度、AI監査で挙がった指摘とSearch Consoleのインデックス状況を突き合わせ、カテゴリの偏り・孤立ページ・リンク切れを是正します。ここまで見てきたように、設計は一度、点検は永続がサイト構造との正しい付き合い方です。構造が安定しているサイトは、記事を追加するたびに正しい場所に評価が積み上がっていきます。

よくある質問

階層は何階層までにすべきですか？

オウンドメディアであれば、トップ→カテゴリ→記事の3層を基本に、記事数が多い場合のサブカテゴリを含めて4層までが扱いやすい範囲です。ただし本文で述べたとおり、本質はディレクトリの深さではなくリンク上の到達距離です。重要なページへトップから3クリック程度で届く経路が保たれているなら、URL上の階層が4層あっても問題はありません。逆に2層のフラットな構造でも、一覧の奥に沈んで実質たどり着けないページがあれば、そちらのほうが問題です。

URLに日本語を使ってもいいですか？

技術的には使えますし、日本語URLだから順位が下がるという単純な話でもありません。ただし、日本語部分は共有時にパーセントエンコードされて長い符号列になり、リンクの見た目が悪く、解析ツールやログでも読みにくくなります。運用上の扱いにくさが積み重なるため、新規に設計するなら、スラッグは内容が伝わるローマ字か英単語のASCII文字列にしておくのが無難です。すでに日本語URLで運用中のページを変更する場合は、リダイレクトの手間とリスクを天秤にかけて判断してください。

カテゴリとタグはどう使い分けますか？

カテゴリは記事の主たる置き場所で、1記事1カテゴリが原則です。サイトの構造そのものを形作るため、数を絞って安定させます。タグはカテゴリを横断する属性ラベルで、「AI活用」「事例あり」のように複数付与しても構いません。注意したいのはタグの乱発です。1記事にしか付いていないタグが増えると、中身のないタグページが量産されてクロールの無駄になります。タグページを検索結果に出す必要がない場合は、noindexにする判断も含めて設計します。

既存サイトのURL構造を今から変えるべきですか？

原則は「明確な問題がないなら変えない」です。URLの変更は301リダイレクトを正しく設定しても一定の手間とリスクを伴うため、見た目の美しさだけを理由に行うものではありません。変更を検討してよいのは、パラメータの増殖でクロールに実害が出ている、サイト移転やリニューアルでどのみち構造が変わる、命名の不統一が運用に支障を来しているなど、コストに見合う課題がある場合です。その際は必ず旧新URLの対応表を先に作り、段階的に実施してください。

まとめ

サイト構造の設計で押さえる項目を一覧にすると、こうなります。階層はトップ→カテゴリ→記事を基本に、重要ページへの到達を3クリック程度に保つ。カテゴリは読者の探し方で割り、1記事1カテゴリを原則にする。URLは短く・意味が通る単語で・ハイフン区切りのASCIIとし、一度公開したら変えない前提で最初に決め切る。パンくずとナビゲーションで階層を表現し、XMLサイトマップは正規URLだけの状態を保つ。そして、新カテゴリの判断ルールと公開前チェックで崩れを防ぎ、四半期ごとのAI監査で点検する。構造は地味ですが、整えたぶんだけすべての記事の評価が正しく積み上がる土台です。まずは全URLの棚卸しから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。