目次(table of contents)は SEO と AI 引用に効くのか
目次は、長い記事の冒頭に置く「見出しへのページ内リンク集」です。読者は目的の節へ一足飛びに移動でき、検索エンジンは目次を手がかりに検索結果へ「ジャンプリンク」を表示することがあり、AI 検索は該当箇所を名指しで引用しやすくなります。ただし効くのは中身の長い記事だけで、短いページに付けても意味はありません。
目次には何の効果がありますか?
目次は主に 3 つの効果があります。第一に読者が目的の節へ即座に移動でき、長い記事の離脱を減らします。第二に Google が検索結果に見出しへの「ジャンプリンク」を表示する手がかりになります。第三に AI 検索が、記事全体ではなく該当する節を名指しで引用しやすくなります。いずれも、見出しに id を振ってページ内リンクにすることが前提です。
目次は「あると丁寧」という飾りではなく、読者・検索エンジン・AI の三者に効く実装です。ただし共通の前提があります。見出しに id が付いていること。id の無い見出しは、目次からも、外部からも名指しできません。
どんなページに目次を付けるべきですか?
見出しが複数あり、本文がある程度長い記事に付けます。目安は、スクロールしないと全体が見えない長さで、節が 3 つ以上あることです。逆に、トップページや短いランディングページ、1 画面で読み切れるページに目次を付けても、かえって邪魔になるだけで効果はありません。長さと構造がそろって初めて価値が出ます。
目次はどう実装すればいいですか?
各見出しに一意の id を付け、目次から同じ id へのアンカー(#id)でリンクします。目次自体は nav 要素で囲むと、これは本文のリストではなく案内であることが支援技術に伝わります。JavaScript は不要で、素の HTML で完結します。id は英数字で分かりやすく付けると、そのままアンカー付き URL として共有・引用できます。
<!-- 目次: nav で囲む。中身はページ内アンカー -->
<nav aria-label="目次">
<ol>
<li><a href="#intro">はじめに</a></li>
<li><a href="#setup">初期設定</a></li>
<li><a href="#faq">よくある質問</a></li>
</ol>
</nav>
<!-- 見出しに、目次と一致する id を振る -->
<h2 id="intro">はじめに</h2>
…
<h2 id="setup">初期設定</h2>
…
<h2 id="faq">よくある質問</h2>目次を nav で囲むのは、これが本文のリストではなく案内だと支援技術に伝えるためです。ランドマークとしても機能し、スクリーンリーダーが目次を領域として扱えます。
/* アンカーで飛んだとき、固定ヘッダーに見出しが隠れないよう余白を確保する */
:target,
h2[id] {
scroll-margin-top: 6rem;
}目次は自動生成すべきですか、手書きすべきですか?
見出しから自動生成するのが現実的です。手書きだと、見出しを増減したときに目次の更新を忘れ、リンク切れや抜けが起きます。ビルド時に見出しを走査してアンカーを生成すれば、本文と目次が常に一致します。ポイントは、生成を JavaScript の実行に依存させないことです。サーバー側やビルド時に HTML として出力しておけば、JavaScript を実行しない AI クローラーからも目次が見えます。
手書きの目次は、記事が短いうちは楽ですが、見出しを足すたびに更新が要り、いつか必ず本文とずれます。 ずれた目次はリンク切れや抜けを生み、かえって信頼を損ないます。見出しを走査してアンカーを組み立てる自動生成にしておけば、この保守コストが消えます。
注意点は 1 つだけ。生成をブラウザの JavaScript 実行に頼らないことです。クライアント側で目次を組み立てる実装は、JavaScript を実行しない AI クローラーや、スクリプトが失敗した環境では目次が存在しないのと同じになります。 サーバー側レンダリングやビルド時生成で、最初から HTML に目次が入っている状態にしておくのが確実です。
目次は AI 検索の引用に本当に効きますか?
直接のランキング要因ではありませんが、引用されやすさには寄与します。見出しに id が付いていると、AI 検索や Google は「ページ内の特定の位置」へ直接リンクできます。回答の根拠として記事の一節を示すとき、名指しできるアンカーがあるページの方が引用先に選ばれやすくなります。id の無い見出しは、その機会を自ら捨てていることになります。
AI 検索は、回答に根拠を示すとき「ページのどこに書いてあるか」まで示せると信頼性が上がります。見出し id は、その名指しのための住所です。 質問形の見出しと簡潔な回答をセットにする 回答ブロックと組み合わせると、引用されやすさはさらに高まります。
Google のジャンプリンク(サイトリンク)は目次で出せますか?
確実に出す方法はありません。ジャンプリンクは Google が自動で判断して表示するもので、目次と見出し id はその判断材料になりますが、付ければ必ず出るわけではありません。過度に期待せず、まずは読者の移動を助けるために目次を置く、という姿勢が正解です。表示されればもうけもの、くらいに捉えてください。
目次は具体的にどんな体験を改善しますか?
検索から記事に来た読者は、多くの場合ページ全体ではなく「自分の疑問に答える一節」を探しています。目次があれば、その節へ 1 クリックで移動でき、目当ての情報が本当にあるかも一目で判断できます。これが離脱の抑制につながります。モバイルでは特に、長い記事の全体像を先に見せる意味が大きくなります。
スクロールに追従する目次(sticky)は付けるべきですか?
デスクトップの長い記事では有効ですが、必須ではありません。追従する目次は現在地を示し、いつでも別の節へ移動できる利点があります。一方でモバイルでは画面を圧迫するため、折りたたむか、冒頭の目次だけに留めるのが無難です。実装で忘れがちなのは、追従要素が本文やフォーカスの邪魔をしないこと、そして固定ヘッダーと重ならないよう scroll-margin を確保することです。凝る前に、まず素の目次を正しく置くのが先です。
追従目次は「あると便利」ですが、優先順位は高くありません。まず素の目次(見出し id とページ内アンカー)を正しく置くことが土台で、 追従はその上の装飾です。実装するなら、次の点だけ外さないようにします。
- モバイルでは畳む — 狭い画面で常時表示すると本文を圧迫する。開閉式にするか、冒頭の目次に留める
- フォーカスを奪わない — 追従要素がキーボード操作の順序を乱さないようにする
- 固定ヘッダーと重ねない — アンカー移動時に見出しが隠れないよう
scroll-margin-topを確保する
目次が正しく機能しているか、どう確認しますか?
目次の各リンクをクリックして、対応する見出しまでスクロールするかを確かめます。移動しなければ、見出しの id と目次の #id がずれています。加えて、目次が nav で囲まれていること、見出しすべてに id があることを確認します。本ツールの AEO 診断は、本文の長い記事にページ内アンカーの目次があるかを検出します。
目次の実効性は「クリックして目的の見出しへ飛ぶか」で確認できます。飛ばないなら id とアンカーの不一致です。 記事の信頼性そのものを高める要素は E-E-A-T にまとめています。