記事の目次に見出しが出ない?本文と目次の集め方を確認する

自社の記事に目次を置いたのに、読みたい章が出ないと困っていませんか。本文の見出しと、目次が項目を集める範囲を照合する方法を説明します。
本文の見出し、目次の集め方、リンクの行き先をひと組で確認します。項目があることと、実際に章へ進めることは別に確かめます。

どの記事の、どの章へ進む目次?
目次は、記事にどんな章があるかを見渡し、読みたい部分へ進むための一覧です。会社案内やサービス一覧など別のページへ進むサイト全体のメニューと、役割を分けます。W3Cの目次に関する技法も、文書の構成を示し、その節へ進む役割を説明しています。すべての記事へ必ず設置するという義務や、サイト全体の適合を認めるものではありません。
まず点検する記事を一つ開き、読みたい章を一つ選んでください。例えば料金の記事なら「料金の決まり方」という本文の見出しと、そこへ進む目次項目を組にします。記事の題名とURL、目次が置かれている場所を控え、別の記事の目次を見ていないかも確認します。
サイドバーは、本文の横などに置く案内の領域です。そこに目次らしい箱が見えても、今開いた記事の見出しを集める仕組みかは、その箱の見た目だけでは決まりません。複数のページで使う共通レイアウトの目次なのか、記事ごとに作った一覧なのかを制作担当と確認します。
WordPress.comの相談フォーラムには、目次ブロックをサイドバーに置いたが投稿本文の見出しを検出しないという本人の報告があります。これは個別の相談です。すべてのサイドバーでは使えない、特定の設定が原因、という一般則にはしません。まず自社の目次が何を対象にしているかを調べます。
本文は、見出しとして作られている?
見出しは、本文の大きな章や、その中の小さな節を示す要素です。WordPressのブロック編集画面では、段落や見出しなどのひとかたまりをブロックとして扱います。太字や大きい文字にした段落と、見出しブロックは同じではありません。
編集できる担当者が、目次へ載せたい本文を選び、見出しブロックとして作られているかを確認します。H2やH3は見出しの階層を示す指定で、H2を大きな章、H3をその章の小さな節として構成できます。文字を大きくしたいだけで階層を選ばず、内容の親子関係を読みます。
例えば「料金の決まり方」の説明の中に「追加作業がある場合」という小さな節があるなら、二つが同じ大きさの章なのか、前者の中に後者が入るのかを先に整理します。目次でどこまで細かく見せるかは、読者が探す内容と使う仕組みの設定を見て決めます。すべての階層を並べることを目的にはしません。
本文に章名が見えているのに目次に出ない場合は、「見出しとして作られているか」と「その階層を目次が対象にするか」を分けて調べます。見出しの名前、階層、本文での順序を確認してから、目次の設定と比較すると、どちらを直す必要があるかを具体化できます。
自動で集める目次?手で作った一覧?
目次には、本文の見出しから項目を自動で集めるものと、担当者がリンクを並べて作った一覧があります。見た目が似ていても更新のされ方は違います。使っているブロックや機能の名前を調べ、本文のどの範囲と階層を対象にしているか、記事の途中でページを分けているかを確認します。
WordPress.comの目次ブロックの公式案内では、同ページの見出しブロックから項目を作り、追加・改名・並べ替えに追従する仕組みが説明されています。収集する階層や、ページを分けた場合の対象にも設定があります。このブロックを利用できる環境での説明であり、すべてのWordPressやテーマへ同じ機能が標準で入っているとは限りません。
プラグインは、WordPressに機能を追加する仕組みです。同案内にはGutenbergプラグインの有効状態に関する注意もあります。ただし、目次が見つからないからといって、その場でプラグインを追加したり停止したりする手順にはしません。自社で使っている目次の提供元と利用条件を制作担当へ確かめ、既存の構成への影響を先に調べます。
自動の目次を編集可能な一覧へ切り離す機能を使った場合は、その時点の項目が残っても、新しい見出しが自動で追加されなくなります。手で作った一覧も、本文を書き換えるたびに項目名・順序・行き先を自分で照合する必要があります。自動か手動かを確認せず、本文を直したから目次も更新された、と扱わないことが要点です。
次の章では、先頭に手で作った静的な目次と、別記事の自動収集の目次を例にします。二つは別の記事・別の方式の記録です。同じ記事を直す前後の結果や、どちらが優れるかを示す比較ではありません。
項目名と行き先を、本文の見出しにそろえる
たとえば、本文冒頭に手で作った目次の項目「料金の決まり方」があり、本文の同名見出しがH2、idがfees、リンク先が#feesなら、名前と行き先の対応を読み取れます。実際にリンクを起動して章へ進めるかは、別に操作して確認します。
HTMLアンカーは、ページ内で移動先にする場所へ付ける名前です。HTMLはページの内容や要素を表す記述で、idはその要素を識別する名前です。リンクに書く#から始まる行き先と、そのページの見出し側の名前を組にして確認します。

手動の目次と別記事の自動目次を、項目・見出し・行き先で確認
目次の項目と集め方を、項目ごとに比べる
最初は手で作った目次、次は別記事の自動目次です。各記録から、項目の表示・リンク先・実際に章へ進めるかのどこまで確認できるかを読みます。
先に比べるところ|項目の確認結果と、集め方の違い
本文冒頭の目次は手動の一覧で、「料金の決まり方」という項目を確認しています。別記事のサイドバーは自動収集の目次で、確認時に項目を見つけられませんでした。項目の文字を確認したことと、実際に章へ移動できたことは別です。
別々の記事の目次について、同じ項目を続けて比べます。
目次項目を確認した記録
- 本文冒頭の目次
- 項目を確認した
- 別記事のサイドバー
- 確認時に項目を見つけられなかった
項目の集め方
- 本文冒頭の目次
- 手動で作った静的な一覧
- 別記事のサイドバー
- 見出しから自動収集する目次
目次を置いた場所
- 本文冒頭の目次
- 記事本文の冒頭
- 別記事のサイドバー
- サイドバー
目次項目の表示名
- 本文冒頭の目次
- 料金の決まり方
- 別記事のサイドバー
- 未確認
目次に指定した行き先
- 本文冒頭の目次
- #fees
- 別記事のサイドバー
- 未確認
本文の見出しの名前
- 本文冒頭の目次
- 料金の決まり方
- 別記事のサイドバー
- 相談前に用意する資料
本文の場所に付けた名前
- 本文冒頭の目次
- fees
- 別記事のサイドバー
- prep
記事と目次の記録
- 本文冒頭の目次
- 本文冒頭の静的な目次
- 別記事のサイドバー
- 別記事のサイドバーの目次
両方に共通する記録
- 見出しの階層の指定
- H2
- 実際に章へ移動できた結果
- 未確認
- 個別の原因
- 未確認
- 修正後の結果
- 未確認
どちらも見出しの階層はH2という記録です。実際に章へ移動できたか、個別の原因、修正後の結果は両方とも未確認です。
静的一覧を編集する場合の具体的な操作は、WordPress.orgのページ内リンクの公式手順で確認できます。対象の見出しブロックを選び、設定の「高度な設定」(Advanced)にある「HTMLアンカー」へ名前を入れます。続いて目次項目の文字を選び、リンクの入力欄へ、その名前の先頭に#を付けて指定します。表示名が訳されている場合は、使っている編集画面の項目名を確認してください。
この架空例なら、見出し側がfees、リンク側が#feesという組です。すでに名前がある見出しを変更すると、ほかのページからのリンクへ影響する場合があります。既存の指定を先に読み、同じ名前を重ねて増やさず、必要な箇所だけ直します。WordPressの入力欄では大文字小文字を区別し、同じ文書内で一意にし、空白を入れない等の条件を確認します。
<a href="#fees">料金の決まり方</a>
<h2 id="fees">料金の決まり方</h2>
「料金の決まり方」という名前を変えたら、目次の表示名も照合し、行き先の名前まで変えた場合は参照するリンクも確認します。
別記事のサイドバーの例では、本文にH2「相談前に用意する資料」とprepという場所の名前がありますが、確認時に目次項目を見つけられませんでした。目次の項目文と行き先は未取得で、空の文字列や0ではありません。収集対象や設定、個別原因を調べる前に、全サイドバーが使えないと断定しないでください。両例とも原因と修正後の結果は未確認です。
保存後も、同じ項目から章へ進める?
変更を保存する前に、本文と目次を同じ記事のプレビューで並べて確認します。項目名と順序は本文に合っているか、小さな節の入り方は意図したものか、新しく足した見出しが反映されたかを読みます。自動の目次では更新された結果を、静的一覧では手で直した結果を、それぞれ確かめます。
保存後は、編集画面のプレビューだけで終えず、実際に表示される同じ記事を開きます。目次の項目をクリックし、意図した章が画面に現れるかを読みます。続いてTabキーでその項目へ進み、Enterでリンクを起動して行き先を確認します。Tabは次の操作対象へ進むキーです。使うブラウザーや端末でキーの扱いが異なるときは、試した条件も残します。
スマートフォンでは、長い項目名が折り返しても途中で切れないか、項目どうしを区別できるかを見ます。画面上部に残る案内に移動先の見出しが隠れる場合は、どの幅・項目で起きたかを記録して担当者へ伝えます。順序や行き先が合うこと、画面に章が見えること、今の操作対象が分かることは別々に確認します。
リンクを起動した後の操作対象や、次のTabの行き先まで調べる必要がある場合は、画面の移動と次のTabを分けて確認する記事が役立ちます。そこでは本文へ進む一経路の仕組みを扱います。今回は、記事中の複数の章を探す目次の項目と、本文との対応に絞っています。
目次の設定や本文を直したら、同じ記事・ブラウザー・画面幅・項目から再確認します。変えた見出しだけでなく、同じ目次に残るほかの項目にも影響がないかを見ます。この二つの記録では、原因と変更後の結果は未確認です。
まとめ:見出しと目次項目を一組で確かめる
記事の目次を点検するときは、本文の見出し、目次が集める範囲と階層、項目名・順序・行き先を一組で確かめます。自動収集と手で作った一覧を分け、本文を書き換えた後も同じ記事で結果を読み直してください。項目が存在することと、目的の章へ実際に進めることを分けると、足りない確認を具体化できます。
最初の一歩は、記事を一つ選び、読みたい章と目次の項目を一組照合することです。本文の見出しとしての指定、目次の提供元と対象、行き先の名前を確認し、分からない点を担当者へ返します。原因が未確認なら、見つからなかった条件と、まだ確かめていないことを分けて残しましょう。
キーボード、入力、拡大などサイト全体の点検へ広げる場合は、企業サイトのアクセシビリティ点検の記事へ進んでください。記事の最初に何を伝えるかを整えたい場合は、本文の答えと範囲から冒頭を作る記事が役立ちます。目次の項目を整える作業と導入文を書く作業を分け、今必要な箇所から確認します。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


