ブログの目次はSEOに効く？必要かの判断と、見出しからの作り方

ブログの目次は、検索順位のためではなく、長い記事の中から自分の答えの節を探す読者のために付けます。 「目次はSEOに良い」と聞いてプラグインや目次機能を入れるか迷っている人、短い記事にも付けるべきか分からない人に向けた記事です。 読み終えるころには、自分の記事に目次が要るかどうかを決められ、付けるならどこを確かめればいいかが分かります。

目次を整える前に「どの記事から手を入れるか」を決めたいなら、そこを手伝う道具もあります。記事の最後に書きます。

目次を付けると検索に効くのか

先に答えを書くと、目次そのものが検索順位にどう効くかは、私が確認したGoogleの公式ページには書かれていません。2026年10月7日に、目次と関係しそうな4ページ(下で引くSEO スターター ガイド、スニペット、強調スニペット、URL構造のページ)の日本語版と英語版の本文を取得して確かめました。4ページとも、本文に「目次」という語は1回も出てこず、英語版の "table of contents" も出てきません。

ですから、この記事では「目次を付けると順位が上がる」とは書きません。かといって「目次は意味がない」とも書けません。公式が書いているのは、目次のまわりにある2つのこと、つまり見出しと、ページの途中へ飛ぶリンクのほうです。目次をどう扱うかは、この2つから組み立てられます。

Googleが書いているのは、見出しとページ内の移動のこと

見出しは、読者がページの中を移動するためのもの

SEO スターター ガイドは、読みやすく整理された文章の条件として、こう書いています。

長い文章は段落や章などに分け、全体を見通せるように見出しを付けてください。

英語版では "provide headings to help users navigate your pages"(読者がページの中を移動する助けになるよう見出しを付ける)です。見出しの役目として、ページの中を移動することが名指しされています。目次は、その見出しを冒頭に一覧にして、押せば飛べるようにしたものです。目次が無くても見出しは働きますが、長い記事では、見出しを探してスクロールする手間を目次が省きます。

なお、これは見出しについての文で、目次を付けるよう求めた文ではありません。見出しの数や順番について公式に何が書かれているかは見出しタグはSEOに効く？h1の数と順番をGoogleの原文で確認に分けて書きました。

検索結果からページの途中へ飛ぶリンクに、目次は求められていない

目次を付けるとSEOに良い、と言われる理由としてよく聞くのが「検索結果に、記事の途中へ飛ぶリンクが出やすくなる」という話です。公式の記述を確かめると、少し違います。

検索結果のスニペットを管理するには、「続きを読む」ディープリンクという項目があります。

「続きを読む」ディープリンクは、スニペット内のリンクで、ユーザーをそのページの特定のセクションに誘導します。

このリンクが表示される可能性を高める方法として挙がっているのは3つです。内容が折りたたみやタブの裏に隠れずにすぐ見えていること、ページを開いたときにJavaScriptでスクロール位置を動かさないこと、そしてURLのハッシュ フラグメント(#から後ろ)を消さないことです。3つ目は原文ではこう書かれています。

ページ読み込み時に history API 呼び出しや window.location.hash の変更を行う場合は、URL からハッシュ フラグメントを削除しないでください。削除すると、ディープリンクが正しく機能しなくなります。

3つの中に「目次を付ける」はありません。また、あくまで「可能性を高める」方法で、守れば必ず出るという書き方でもありません。

強調スニペットのページのよくある質問には、クリックしたあとの動きが書かれています。

ユーザーが強調スニペットをクリックすると、強調スニペットに表示されているページのセクションに直接移動します。スニペットに表示されている位置まで自動的にページがスクロールし、サイト側でアノテーションを追加する必要はありません。

続けて、ブラウザが対応していない場合や、ページのどこへ移動すればいいかをGoogleが判断できない場合は、ページのトップに移動すると書かれています。つまり、少なくとも強調スニペットは、サイト側が目次や目印を用意しなくてもページの途中へ飛ばせるように作られています。「続きを読む」のおすすめの方法にも、目次や目印を用意せよという項目はありません。

ただし、上の3つの方法は、目次を入れるときに確かめる点として役に立ちます。目次のプラグインやテーマには、JavaScriptでスクロールやURLの「#」を扱うものがあるからです。確かめ方は下の「付けるときの作り方」に書きます。

目次の「#」付きリンクは、URL構造の注意に当たるのか

目次の項目は、https://example.com/post/#midashi-1 のように「#」の付いたリンクです。Google の URL 構造に関するベスト プラクティスに「Google 検索は通常、URL フラグメントをサポートしていないため、ページのコンテンツを変更する際にフラグメントを使用しないでください。」とあるので、心配になる人もいると思います。

この注意の対象は、見出しのとおり「#」の後ろを変えることで、ページに表示する中身を切り替える作りです(例として https://example.com/#/potatoes が挙がっています)。同じページは続けて「JavaScript でコンテンツを変更する場合は、代わりに History API を使用してください。」と書いています。目次のリンクは、すでにページにある本文の位置へ移動するだけで、中身は切り替わりません。ですから、ふつうの目次はこの注意には当たらない、と私は読んでいます。これは私の読み方で、目次のリンクについて公式が直接書いた文ではありません。

目次が必要な記事、無くてもいい記事

目次が順位の道具ではないとすると、付けるかどうかは読者がその記事をどう読むかで決まります。頭から順に読む記事なら、目次を押す場面はほとんどありません。一部だけを探しに来る読者が多い記事なら、目次は探す手間を省きます。私は次の表で分けています(公式の基準ではなく、私の目安です)。

よく聞く「見出しが何個以上なら付ける」という数の基準は、私は使っていません。見出しが少なくても手順を探す記事なら目次は役に立ちますし、見出しが多くても頭から読む記事なら押されません。迷ったら、その記事の検索キーワードを見て、読者が「全部」を知りたいのか「その中の1つ」を知りたいのかで決めてください。

付けると決めたら、次は目次の中身です。中身は見出しで決まるので、手を入れるのは見出しのほうになります。どの記事の見出しから直すかを決めるなら、検索から読まれている記事が先です。その記事を選ぶところは機械に任せることもできます。

目次を付けるときの作り方

WordPressの目次プラグインや、はてなブログやアメブロの目次機能には、本文の見出しを拾って自動で目次を作るという設定を持つものがあります。ですから「目次を作る」作業の中心は、目次の設定ではなく見出しを整えることです。私が確かめているのは次の4つです。

1. 目次だけを読んで、答えの場所が分かるか

記事を開き、本文を読まずに目次だけを読みます。自分がこの記事を検索した読者だとして、答えがどの項目の先にあるかが目次だけで分かるかを確かめます。「はじめに」「〜とは」「ポイント」「まとめ」のような名詞だけの項目が並んでいると、目次を読んでもどこへ飛べばいいか決められません。

項目を直すときは、見出しを読者の問いの形にします。h2をどう問いにするかは記事構成の作り方(SEO)、検索意図から逆算する4ステップの「h2とh3の使い分け」に、すでに公開している記事の見出しを直す手順は見出しのリライトが効くのは11位より下のページ、h2をSEOで直す判断基準に書きました。

2. 目次に出すのは、まずh2だけにする

目次プラグインには、h3やh4まで目次に出す設定を持つものがあります。h3まで出すと項目が増え、目次が長くなって冒頭の画面を埋めてしまいます。最初はh2だけを出し、手順記事のようにh3まで飛びたい読者が多い記事だけh3を足します。

3. 目次は、冒頭の結論の後に置く

目次をタイトルのすぐ下、結論より前に置くと、検索から来た読者は答えを読む前に目次をスクロールすることになります。冒頭の1段落で答えを書き、その後に目次を置きます。目次を自動で差し込む位置が「最初の見出しの前」になっているなら、最初のh2の前に結論の段落を書いておけば、自然とこの順番になります。

冒頭の結論を書いておくことには、もう1つ理由があります。説明文(メタディスクリプション)を書かないと、検索結果に目次の項目が並んだだけの断片が出ることがある、という話をメタディスクリプションの意味と書き方、書き換えられたら本文の1段落目を直すに書きました(公式の記述ではなく、このブログで書いた話です)。

4. 目次を押したとき、URLの「#」が残るか

最後に、上で引いた「続きを読む」ディープリンクの3つの方法に沿って、目次の動きを確かめます。手順は次のとおりです。

1. 公開済みの記事をブラウザで開き、目次の項目を1つ押す。アドレスバーのURLの末尾に #〜 が付いたままになっているかを見る
2. そのURLをコピーし、新しいタブで開く。押した見出しの位置で開くか、ページの一番上に戻されるかを見る
3. 本文の節が、折りたたみやタブの裏に隠れていないかを見る

1で「#」が消える、2で毎回ページの一番上に戻される、という動きなら、テーマかプラグインのスクロールの処理を疑います。公式が「ページ読み込み時に history API 呼び出しや window.location.hash の変更を行う場合は、URL からハッシュ フラグメントを削除しないでください。」と書いているのは、ページを開いたときの話なので、2の確かめ方がそれに近いものです。

3で気をつけたいのは、折りたたんでいいのは目次で、本文ではないということです。公式の「すぐに表示される状態」は本文の内容の話です。目次を最初は閉じた状態にする設定は、本文を隠すこととは別のものです。

目次の項目は、同じページの中へのリンクです。他の記事へのリンクをどこに置くかは別の話で、内部リンクはどこに貼るか、記事末尾のリンク集より本文中が押されるに分けています。

このブログには、目次を置いていない

正直に書くと、このブログの記事ページには、2026年10月7日の時点で目次を置いていません。その時点で登録済みの記事(この記事を除く221本)を数えると、h2の数は5〜13個で、7個の記事が86本、8個の記事が55本でした(よくある質問とまとめのh2も含めた数です)。見出しの数だけで見れば目次を付けるサイトもありそうな数ですが、上の表のとおり、私は数ではなく記事の形で決めています。

代わりにしているのは、冒頭に「この記事のまとめ」の囲みを置いて答えを先に書くことと、h2を読者の問いの形にすることです。この記事のh2も「目次を付けると検索に効くのか」「目次が必要な記事、無くてもいい記事」のように、問いか、答えの場所が分かる言い方にしています。目次が無い理由を数字で確かめたわけではありません。ただ、目次を付けると決めたときも、手を入れるのは見出しのほうだ、という点は変わらないと考えています。

よくある質問

目次プラグインを入れると、SEOに効きますか

効くとも効かないとも、私が確認した公式の4ページには書かれていません。プラグインが作るのは、見出しを一覧にしたページ内リンクです。検索との関係で確かめておきたいのは、上の4つ目の手順で、押したときにURLの「#」が残るかどうかです。

目次は最初から開いておくべきですか、閉じておくべきですか

どちらでも構いません。公式が「すぐに表示される状態」を求めているのは本文の内容で、目次の開閉についての記述はありません。閉じておくなら、目次の下の本文が早く見えます。開いておくなら、h2だけに絞って目次が長くなりすぎないようにします。

短い記事にも目次は必要ですか

頭から読む短い記事なら、無くていいと私は考えています。すべての記事に一律で付けるより、上の表のように記事の形で分けるほうが読者に合います。プラグインに「見出しが一定数以上のときだけ表示」の設定があっても、数で一律に分けるより、記事ごとに上の表で決めるほうが読者に合います。

アメブロやはてなブログの目次機能でも同じですか

考え方は同じです。見出しから目次が作られるので、見出しを問いの形にすることが先です。アメブロの目次機能(見出しを入れると自動で作られ、1記事に1つまで)と、ヘルプに検索への効果が書かれていないことはアメブロはSEOに弱い？自分で設定できる項目と確かめる数字の表にまとめています。

まとめ

• 目次そのものが検索順位にどう効くかは、私が確認したGoogle公式の4ページ(SEOスターターガイド、スニペット、強調スニペット、URL構造)には書かれていない
• 公式が書いているのは、見出しは読者がページ内を移動する助けになること、少なくとも強調スニペットからページの途中へ飛ぶ動きはサイト側の目印なしで動くこと
• 付けるかどうかは、読者が頭から読むか(無くていい)、一部を探すか(付ける)で決める
• 付けるなら、目次だけで答えの場所が分かる見出しにし、まずh2だけを出し、結論の後に置き、押したときにURLの「#」が残るかを確かめる

次にやるのは、検索からいちばん読まれている自分の記事を1本開き、本文を読まずに目次(目次が無ければh2の並び)だけを読んで、答えの場所が分かるかを確かめることです。分からなければ、直すのは目次の設定ではなく見出しです。見出しの直し方は見出しのリライトが効くのは11位より下のページ、h2をSEOで直す判断基準で確かめてください。

ここからは、私が作ったツールの話になります。

目次や見出しを直す前に決めたいのは、どの記事から手を入れるかです。そこを自動でやるツールを作りました。サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、目次の有無や良し悪しを判定するものではありません。診断カードは記事の本文を先頭から一定の字数だけ読むので、目次が <nav> や <aside> の外、記事本文の領域の中に置かれているテーマでは、目次の文字も本文の一部として読みます。目次の直し方は、この記事の4つの確かめ方で手で行ってください。また、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。