サイト構造をAIに理解させる！ナビゲーション × 構造化マークアップで設計するLLMフレンドリーなサイト

ナビゲーション構造とは：2026年の再定義

ナビゲーション構造は、本来「サイト内のページ間を移動するための仕組み」と定義されてきました。グローバルナビ、サイドナビ、パンくず、フッターリンクなどがその主要な構成要素です。しかしこの定義は、検索エンジンとAIクローラの視点を含んでいません。

2026年のSEOにおけるナビゲーション構造の正しい定義は、「人間とクローラの双方に対して、サイト内の情報階層と関連性を明示する設計」です。この定義の重要な点は、ナビゲーション構造が単なるUI要素ではなく、サイト内の「意味的な地図」を機械可読な形で提供するためのものだという認識にあります。

UI/UX文脈から機械可読性文脈への転換

観点	従来の議論（〜2023年）	2026年の議論
主役	人間ユーザー	人間＋GPTBot・ClaudeBot・Googlebot
評価軸	クリック率・直帰率	機械可読性・引用されやすさ
実装の焦点	見た目・操作性	HTMLセマンティック＋構造化マークアップ
失敗パターン	「ユーザーが迷う」	「LLMがサイト構造を再現できない」

この転換が起きた最大の理由は、AI検索エンジンがサイト構造をユーザーに「翻訳」して提示するようになったことです。ChatGPT Search や Perplexity は、ユーザーの質問に対して複数サイトから情報を抽出し、自分の言葉で再構成して回答します。

このとき、サイト構造が機械にとって明確であればあるほど、AIは正確に情報を切り出し、引用元として明示してくれます。逆に、ナビゲーション構造がCSSとJavaScriptだけで成立していて、HTMLレベルで階層が読み取れないサイトは、AIから見れば「中身のない箱」と同じです。

SEGO 2,460件診断で見えた、ナビ実装の「合格しているのに合格していない」実態

ここからは、SEGOの累計2,460件の診断データから抽出した、ナビゲーション構造に関する3つの発見を共有します。いずれも、他のSEO記事ではほぼ言及されていない一次データです。

発見1：不合格率5.5%という"見せかけの安心感"

nav_structure キーの不合格率は5.5%です。これだけ見ると、ほとんどのサイトでナビゲーション構造は問題なく実装されているように見えます。

しかし、ナビゲーション構造と密接に関わる4つの診断キー（canonical、broken_link_patterns、internal_link_count、meta_robots）と並べて比較すると、まったく別の景色が見えてきます。

この比較から分かる重要な事実は、ナビゲーション構造自体は実装されていても、それと連動して動くべきcanonical タグが18.1%のサイトで失敗しているという点です。canonical はAI検索クローラがページの正式URLを判定するために使う情報で、ここが破綻するとナビゲーション構造が正しく動いていても、サイト全体の階層解釈がずれてしまいます。詳細は canonicalタグの正しい使い方 で解説しています。

発見2：スコア分布が「3極化」する構造的理由

さらに興味深いのは、nav_structure のスコア分布です。診断ツールは0-100点でスコアを付与しますが、SEGOデータでは以下のように3つのバケットにスコアが集中しています。

このデータが示しているのは、ナビゲーション構造の実装は「正解形」「不完全形」「未実装形」の3パターンしかなく、その間のグラデーションが存在しないという事実です。これは、SEGOの診断ロジックが「主要なナビゲーション要素のセマンティックタグが揃っているか」「ARIAランドマークが正しく機能しているか」を中心に判定しているため、要素が揃えば一気に高得点、欠けると一気に低得点になる傾向があるからです。

この発見が実務にもたらす示唆は明確です。「途中まで実装した」という選択肢は事実上存在しません。やるなら90点以上の正解形まで持っていく、やらないなら諦める、という二項対立で考えるべき領域です。50-69点の「要改善」帯にある17.8%のサイトは、最も投資対効果が高いセグメントといえます。

発見3：単体ではなく組み合わせで見ないと、本当のクローラビリティは測れない

nav_structure の不合格率5.5%、canonical の不合格率18.1%、internal_link_count の不合格率7.6%。これらを「いずれか1つでも不合格のサイト」として見直すと、AI検索クローラから見たクローラビリティ問題を抱えているサイトは大きく増えます。ナビ単体で評価するのは、サイト構造の表層しか見ていないことになります。詳しい内部リンク密度の分析は 内部リンクの最適化 でも触れています。

AI検索時代のナビゲーション3層モデル

SEGOデータが示す「ナビは単独で評価できない」という事実を踏まえると、ナビゲーション構造は3つのレイヤーで構成される統合システムとして設計する必要があります。これがLLMフレンドリーなサイト構造の核となる考え方です。

このモデルの本質は、各層がそれぞれ独立した役割を持ち、かつ互いに補完関係にあるという点です。Layer 1（HTMLセマンティック）は「このブロックは何か」を伝え、Layer 2（内部リンク階層）は「他のページとの関係」を伝え、Layer 3（構造化マークアップ）は「階層全体の意味」を機械可読な形で宣言します。

1層でも欠けると、AI検索クローラはサイト構造を断片的にしか理解できません。

Layer 1 実装：HTMLセマンティックの正しい書き方

最も基礎となるのが、HTML5のセマンティックタグとARIAランドマークを正しく使うことです。具体的には、ナビゲーションブロックを <div class="nav"> ではなく <nav> 要素で記述し、必要に応じて aria-label で識別名を付与します。

避けるべき実装と推奨実装

多くのサイトで見られるアンチパターンは、ナビゲーションを汎用的な <div> やリスト要素のみで実装し、HTML5のセマンティック要素を使わないケースです。CSSで見た目を整えれば人間には十分ですが、クローラは「これがナビなのか単なるリンク集なのか」を判断できません。

<!-- 避けるべき実装 -->
<div class="navigation">
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/services">Services</a></li>
  </ul>
</div>

<!-- 推奨実装 -->
<nav aria-label="メインナビゲーション">
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/services" aria-current="page">Services</a></li>
  </ul>
</nav>

推奨実装で重要なのは、同じページ内に複数のナビが存在する場合、aria-label でそれぞれを区別することです。グローバルナビ、フッターナビ、サイドナビが同じ <nav> 要素として並ぶと、クローラはどれがメインなのかを判定できません。「メインナビゲーション」「フッターナビゲーション」「カテゴリナビゲーション」のように明示的に名付けます。

ARIAランドマークの基本セット

要素	暗黙のARIAロール	用途
<header>	banner	サイト全体のヘッダー（1ページに1つ）
<nav>	navigation	主要ナビゲーション（複数可、aria-labelで区別）
<main>	main	ページの主要コンテンツ（1ページに1つ）
<aside>	complementary	補足情報・サイドバー
<footer>	contentinfo	サイト全体のフッター（1ページに1つ）

Layer 2 実装：内部リンク階層の設計

Layer 1 がサイト構造の「役割表明」だとすれば、Layer 2 は「実体の経路」です。実際にリンクで辿れる構造がなければ、クローラは階層を確認できません。

3クリックルールの誤解

「トップから3クリック以内に全ページへ到達できるべき」というルールは、UX原則として2000年代から語られてきました。しかし2026年のAI検索文脈では、「クリック深度」よりも「階層の論理性」が重要です。

サイトマップ的に整然と階層化されていれば、深度5でも問題ありません。逆に、深度2でも論理性のないリンク構造（ランダムな関連記事リンクなど）はAIにとって混乱の元になります。

SEGOデータでも、internal_link_count の不合格率は7.6%とそこそこ低いですが、リンクの「数」だけ見ても本質的な改善にはつながりません。サイトマップの作り方とSEO効果 で解説した通り、XMLサイトマップとHTMLサイトマップが内部リンク階層と一致していることが、最低限の条件です。

アンカーテキストの一貫性

同じページへのリンクが、ページごとに異なるアンカーテキストで記述されている状況は、クローラを混乱させます。「サービス一覧」「サービス紹介」「弊社サービス」のように表記揺れがあると、AIはそれが同じページを指しているか判断に時間がかかります。アンカーテキストはサイト全体で統一するのが鉄則です。

パンくずリストの実装

パンくずリストは、Layer 2 のなかでも特にLLMが階層を理解しやすい要素です。ただし、見た目だけのパンくず（CSS装飾された矢印付きリンク）ではなく、HTML上で順序のあるリスト構造として記述し、後述の Layer 3 でJSON-LDによる構造化も同時に行う必要があります。

Layer 3 実装：構造化マークアップの組み込み

最後のLayer 3 は、サイト構造の意味をJSON-LD形式で明示的に宣言します。これにより、クローラは推測ではなく「宣言された事実」として階層を取得できます。JSON-LDの実装ガイド で基礎を解説していますが、ここではナビゲーション特化の3種類を紹介します。

BreadcrumbList（パンくずリスト）

最も実装の効果が大きく、Google検索結果のリッチリザルトとしても表示される構造化データです。以下のコードを、パンくずを表示するページの <head> 内に配置します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "ブログ",
      "item": "https://example.com/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "記事タイトル",
      "item": "https://example.com/blog/article-slug/"
    }
  ]
}
</script>

SiteNavigationElement（サイトナビゲーション）

サイト全体のグローバルナビゲーションを構造化データで宣言します。BreadcrumbList ほどメジャーではありませんが、サイト全体のナビ構造をAIに明示的に伝えられるのが利点です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SiteNavigationElement",
  "name": ["ホーム", "サービス", "事例", "ブログ", "お問い合わせ"],
  "url": [
    "https://example.com/",
    "https://example.com/services/",
    "https://example.com/cases/",
    "https://example.com/blog/",
    "https://example.com/contact/"
  ]
}
</script>

WebSite + SearchAction（サイト内検索の宣言）

サイト内検索機能を持つ場合、それをクローラに知らせる構造化データです。Googleがサイトリンク内に検索ボックスを表示する条件にもなります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

10年コンサル経験から見た、よくある実装ミス5選

これまでに数百サイトのナビゲーション構造を診断・改善してきた経験から、特に頻発する実装ミスを5つ挙げます。いずれも一見正しく見えますが、AI検索クローラの目線で見ると致命的な欠陥につながります。

ミス1：SPAでナビが空のHTMLとして配信される

React や Vue で構築したSPA（シングルページアプリ）で、初期HTMLにナビゲーション要素が含まれず、JavaScript実行後に動的に挿入されるケースです。

Googlebotは現代では JS をレンダリングしますが、GPTBot や ClaudeBot の多くは初期HTMLのみを解析するため、ナビ構造が完全に見えなくなります。SSRやSSGで初期HTMLにナビを含める設計が必須です。

ミス2：ハンバーガーメニュー内のリンクがJSで遅延ロード

モバイル対応のためハンバーガーメニューを採用するのは問題ありませんが、その中身のリンクが「メニューを開いた時に初めてDOMに挿入される」設計になっていると、クローラからは存在しないリンクとして扱われます。初期HTMLにリンクを含め、CSSで表示制御するのが正解です。

ミス3：パンくずがHTMLにあるがJSON-LDにない（または逆）

HTMLでパンくずを表示しているのに JSON-LD の BreadcrumbList を実装していない、あるいは JSON-LD だけ実装してHTMLには表示していない、というケースです。両方を一致させて実装するのが鉄則で、片方だけだとリッチリザルト表示の条件を満たせず、AI検索の評価も下がります。

ミス4：ARIAランドマークの重複

1つのページに <header> や <main> が複数存在するケースです。HTML5仕様上は許容される場合もありますが、ARIAランドマークの観点では「banner」「main」は1ページに1つが原則です。複数存在すると、AIはどれがメインのコンテンツか判定できません。

ミス5：aria-currentの未使用

現在表示中のページを示すリンクに aria-current="page" を付与していないケースです。これはスクリーンリーダー対応として知られていますが、実はAI検索クローラもこの属性を読み取り、サイト内の現在位置を把握しています。グローバルナビには必須の属性です。

自己診断チェックリスト

本記事で解説した内容を、明日から自社サイトで点検できる形にまとめました。各項目を上から順に確認してください。

Layer	チェック項目	合格基準
Layer 1	ナビが <nav> 要素で記述されているか	すべての主要ナビ
	複数の <nav> に aria-label が付与されているか	すべて区別可能
	1ページに <header> <main> <footer> が1つずつ存在するか	重複なし
Layer 2	初期HTMLにナビゲーションリンクが含まれているか	JS実行前に確認
	同一ページへのアンカーテキストが統一されているか	表記揺れなし
	パンくずがHTMLで階層構造として記述されているか	順序ありリスト
Layer 3	BreadcrumbList の JSON-LD が実装されているか	全階層ページに
	SiteNavigationElement または同等の宣言があるか	トップページに
	HTMLパンくずとJSON-LDが一致しているか	項目・順序とも

このチェックリストで1つでも不合格があれば、SEGOの無料診断で具体的な改善ポイントを確認できます。AI検索引用率を高める実装 や 検索意図に応える構造設計 と組み合わせて取り組むと、サイト全体のAI検索対応度が一気に底上げされます。

SEGOで無料診断を試す

よくある質問

Q1：ナビゲーション構造の改善で、最初に着手すべきは Layer 1〜3 のどれですか？

Layer 1（HTMLセマンティック）から始めてください。SEGOデータでも示した通り、ナビゲーション構造は「正解形」「不完全形」「未実装形」の3パターンに分かれ、中間が存在しません。Layer 1 が中途半端だと、Layer 2・3 を頑張っても効果が出ません。<nav> <header> <main> の正しい配置と、aria-label の付与から手をつけるのが最短ルートです。

Q2：SPAでもAI検索クローラに評価されるナビゲーションは作れますか？

はい、可能です。ただしSSR（サーバーサイドレンダリング）またはSSG（静的サイト生成）を採用し、初期HTMLにナビゲーション要素を含めることが必須です。Next.js の getStaticProps や getServerSideProps、Nuxt の SSR モードを使えば、SPAのUXとクローラ対応を両立できます。CSRのみのSPAは、AI検索評価では大きく不利になります。

Q3：BreadcrumbList と SiteNavigationElement は両方実装すべきですか？

優先度は BreadcrumbList が圧倒的に高いです。リッチリザルトとして表示される実利があり、AI検索クローラからの評価も明確に高まります。SiteNavigationElement は補完的な位置付けで、サイトの規模が大きく、グローバルナビの構造を明示したい場合に追加実装するのが現実的です。リソースが限られているなら、まず BreadcrumbList の全ページ実装を優先してください。