WordPressの目次が見出しへ飛ばないとき｜ID・固定ヘッダー・読込後のずれを確認

WordPressの記事で目次を押しても見出しへ移動しないときは、リンクの「#」以降と移動先のIDが一致するかを先に確認します。目的の見出しへ移動するのに固定ヘッダーへ隠れる場合や、画像の読込み後に位置がずれる場合は、別の原因です。目次の見た目だけを直さず、どの操作でどこに止まるかを記録して切り分けましょう。

この記事は、記事を更新する担当者と、テーマや目次の修正を担う制作会社向けです。標準の見出しブロック、目次生成機能、独自実装では操作が異なります。IDとリンクの点検、固定ヘッダー、遅延読込み、既存リンクを守る修正と検収を説明します。自動生成されたIDを一括で変える前に、現在の構成と影響を確認してください。

1. 押せない、別の見出しへ行く、隠れる、後でずれるを分ける

問題が起きる操作を一つにする

「目次が動かない」には複数の現象があります。どの記事のどの項目を、どの端末で押し、どの場所へ移動したかを記録します。表示直後か、すべての画像が読み込まれた後かも分けてください。再現しない条件は未確認として残します。

別ページへのリンク点検全体は内部リンクの点検ガイドで扱います。本稿は一つの記事内の見出しへ移動する不具合に絞ります。同じ症状に見えても、対象IDと位置の問題を混ぜないことが出発点です。

2. hrefの断片と、公開HTMLのIDを照合する

同じページのリンクがhref="#preparation"なら、移動先には対応するid="preparation"が必要です。例えば<h2 id="preparation">公開前の準備</h2>とリンクを組み合わせます。これは説明用の構造で、現在のテーマへそのまま挿入する指示ではありません。

MDNのid属性の説明に沿い、IDは同一文書内で重複させません。同じ見出しブロックをコピーした場合や、PC/SPの別表示を同じHTMLに持つ場合、同一IDが残ることがあります。見た目で一つしか見えなくても、公開DOMに二つあるかを実装担当が調べます。

リンク値とIDでは、大文字小文字、綴り、余分な空白、文字のエンコードがずれていないかを確認します。「#」はリンクで付ける区切りです。見出し側のアンカー欄へ#を含める方式とは通常異なるため、使用する編集機能の仕様を見ます。別ページなら対象ページのURLと断片が両方必要です。

公開画面の検査では、リンクのhref、対象のid、個数、実際の見出しを対応表へ記録します。管理画面で入力した値が、そのまま公開HTMLへ出るとは限りません。テーマが自動採番する、目次機能が別のIDを追加する場合は、どの処理が正本かを確認します。

3. 見出しブロックのHTMLアンカーと目次の生成方法を調べる

手で設定する目次と自動生成を分ける

標準のブロック編集では、見出しを選び、ブロック設定の詳細にあるHTMLアンカーへ識別名を設定できる場合があります。WordPressのページ内移動の公式資料は、見出しのアンカーと#を付けたリンクを組み合わせる方法を示しています。環境の画面やブロックによって設定位置が違うため、まず使っている編集方式を確認します。

手動目次なら、アンカーを設定した後に対応するリンクを入力します。自動目次なら、テーマや追加機能が見出しを拾い、IDを作る条件を調べます。両方の方式を重ねて導入せず、既存の機能を使って直せるかを見てください。

見出し本文を変えるとIDも変わる方式、表示順の番号からIDを作る方式、固定の独自アンカーを維持する方式は、修正時の影響が異なります。どの方式か不明なら、下書きや検証用の複製で変更前後を比較します。公開中の見出しを試験のためだけに動かさないようにします。

目次に載る見出し階層も確認します。H2とH3の扱い、除外項目、目次を作るタイミングが本文と合っているかを見ます。文字を大きくした段落は、意味上の見出しと違います。目次へ載せるために全段落を見出しにせず、文章の構造から適切に整理してください。

4. 固定ヘッダーに隠れる場合は、必要なスクロール余白を検討する

リンクとIDが一致し、対象位置まで移動しているのに見出しが見えない場合、固定ヘッダーや固定メニューが覆っていないかを見ます。ページの先頭からの距離と、画面内の位置は別です。上端へ移動する仕様でも、ヘッダーの下で内容を読めることが必要です。

MDNのscroll-margin-topの資料は、スクロール時の上側余白に関係するCSSを説明しています。実装担当は対象の見出しに適切な余白を設ける方法や、スクロール側の設定を検討できます。ただし、全サイトへ思いつきの固定値を追加する手順ではありません。

ヘッダーの高さはPC/SP、メニューの状態、文字サイズ、スクロール後の縮小などで変わる場合があります。対象の幅と状態を測り、目次移動、別ページからの直接リンク、キーボード操作を同じ条件で確認してください。既存のスクリプトが位置を補正している場合、CSSと両方で補正して空白が過大になることも調査します。

5. 読込み後にずれる場合は、レイアウトの変化を観察する

最初の訪問と読込み済みの再訪を比べる

画像、埋込み、フォント等で上の内容の高さが変わると、目次移動後の位置が変わることがあります。対象記事を初めて開いたときと、素材が読み込まれた後を分け、どの要素が変わったかを見ます。再訪で動くという結果だけで解決としないでください。

画像の寸法や縦横比を事前に確保できるか、埋込みの領域が後から広がらないかなどは、実装の確認事項です。GoogleのCLSの説明は、予期しないレイアウト移動を調べる資料になります。移動の数値だけで目次の正しさを判断せず、読者の実操作を見ます。

「少し待ってからスクロールすればよい」という説明だけでは、直接アンカー付きURLから訪問した人の問題が残る場合があります。遅い通信、画像の遅延読込み、動きを抑える設定でも必要な見出しが読めるかを確認します。原因を見ずに長い待機や強制スクロールを追加しないようにします。

6. 既存のアンカーリンクを調べてからIDを変更する

見出しのIDは、目次だけでなく、ほかの記事、メール、資料からのリンクにも使われる場合があります。全文を書き換える際にIDを一括で採番し直すと、本文が読めても以前の「#」付きリンクが目的の章へ届かなくなることがあります。

変更前のID、リンク元、変更後の見出しを保存します。既存のIDを維持して本文を直せるなら、その方法を検討します。章を統合する場合は、旧アンカーを残せるか、移動先に意味のある対応を設けられるかを実装担当と判断します。無関係な見出しへ飛ばして形式上だけ動かす方法は避けます。

アンカーの扱いは、ページ自体のURL変更やリダイレクトとは別の問題です。記事内の不具合を理由に、公開URLや索引設定までまとめて変える必要はありません。必要な変更だけを、差分と影響、承認者、戻し方を付けて提案してください。

7. PC・スマホ・キーボード・直接URLで検収する

hrefの存在だけで合格にしない

公開前には原本、対象IDとリンク、修正差分、戻し方を保存します。公開後には、実際に目次の項目を押し、目的の見出しが読めるかを確認します。長いページでは最後の項目、階層が異なる項目、見出しを変更した項目を含めます。試していない項目まで合格にしないようにします。

動きを抑える設定や拡大表示でも、強制的なアニメーションが必要な情報を妨げないかを見ます。クリックで位置が変わったことと、キーボードや支援技術で読み進められることは別なので、必要な対象利用で確認します。公開後にキャッシュされた別の版が出る場合も、対象URLと版を記録して調べます。

8. 依頼票には、問題の項目と期待する見出しを書く

依頼時は対象URL、押す目次、期待する見出し、実際の移動、端末・幅、初回/再訪、読込み条件、使用する目次機能、変更した履歴を渡します。実装担当はID、リンク、重複、固定ヘッダー、レイアウト変化の調査結果を分け、限定した修正案を示します。

解決状態は、必要な項目から対応する章へ移動でき、読込み後にも内容を読め、既存の入口と他ページへの影響が確認され、次の改稿で守るIDと担当が分かることです。目次修正だけで順位やAI検索への掲載を保証するものではありません。

自社で標準アンカーを直せる場合は、下書きで一項目を試して公開確認を進められます。テーマや追加機能の調査が必要な企業は企業向けWeb支援で対象を整理できます。制作会社が実装・検収を依頼する場合は制作会社向け支援から、支給情報と対象外を合わせてください。相談窓口には再現するURLと項目を伝えると調査の範囲を決めやすくなります。対応可否と費用は環境ごとに確認します。

一次資料の確認日：2026年10月5日。標準機能と利用中の実装の違いを確認してから操作してください。