記事の見出しを点検する｜目次だけで内容と順序が伝わるか

目次だけで内容を説明できるか試す

完成物は、現在の見出し、問題、修正案、確認結果の一覧です。本文を一度隠して、目次だけで扱う仕事と順序が分かるか確認します。「特徴」「ポイント」「まとめ」ばかりでは、読者が必要な条件へ移動しにくくなります。

節名は「CSVを取り込む前にIDの重複を確認する」のように、何をする場所か分かる言葉にします。ただし長い文章をそのまま見出しにせず、本文で説明すべき条件は段落へ分けます。

見た目の文字サイズと構造を分ける

太字や大きな文字で表示されていても、実際には見出しではない場合があります。逆に補足を見出しとして大量に並べると、目次が細かくなり過ぎます。見出しのタグ、表示、目次の三つを対応させます。

同じ階層の項目は同じ粒度に揃え、ある項目だけが別の章全体を含まないようにします。画面幅で文字が折り返しても内容が読めるかを確認し、サイズを小さくして無理に一行へ収めないようにします。

各節の約束と本文を照合する

見出しを抜き出してから、各節に目的、条件、操作、判断のいずれが書かれているかを読みます。「料金の計算方法」とあるのに料金表だけなら、計算例を足すか見出しを変更します。本文がない見出しも確認します。

似た見出しが二つ続く場合は、違いを説明できるか確認します。内容が重なるなら統合し、必要な別節なら「登録前の確認」と「公開後の確認」のように時点や判断を名前に反映します。

目次の並びと作業の実際の順番が違う場合は、先に必要な操作を節の後半へ埋め込んでいないか確認します。見出しだけを具体的にしても、節の最初が長い一般論では目的の答えへ着きません。各節の冒頭にその節で行うことを置き、例外や補足を続けます。同じ操作の説明が離れた二節に分かれている場合は、片方へまとめるか、相互に参照できるようにします。

連携ガイドの目次を直す例

架空の旧構成が「準備」「設定」「確認」「注意」だったとします。本文を読むと、それぞれ必要な列、項目の対応、重複登録、失敗時の再実行を説明していました。見出しをその内容に合わせて変更します。

章の順序も、設定前に必要な列を確認し、試行後に重複と失敗を調べる順へ揃えます。見出しの変更だけでリンク先のIDが変わる実装なら、既存の目次や外部からの節リンクが使えるかも確認します。

見出しの修正案は、元の形と並べて担当外の人にも読んでもらいます。「費用が知りたい」「失敗した処理をやり直したい」という二つの探し物を設定し、どの節を開くかを確認します。答えを先に説明せずに探してもらうと、言葉は具体的でも読者の意図に合っていない見出しを見つけられます。正しい節へ着いても答えが遠い場合は、目次を増やす前に節の冒頭と段落の並びを見直します。確認した探し物と修正理由を残します。

目次の移動とスマホの表示を確認する

公開前に目次から各節へ移動し、狙った見出しが見えるか確認します。固定ヘッダーで隠れる、同じIDが二つある、日英版で別の節へ飛ぶ、といった問題を確認します。

スマートフォンでは長い見出しと目次の折り返しを見ます。構成が良くても補足文字が薄いと読めないため、本文、見出し、リンクの濃さも確認します。画像の上へ見出しを載せる場合は、画像により読みにくくならないか別途点検します。

件数ではなく探しやすさで評価する

有料ツールがなくても、目次と本文の読み比べで始められます。Screaming Frogなどで全体の見出しを抽出する場合も、文字数やタグ件数だけで良否を決めず、代表記事を実際に読みます。

Googleは特定の見出し数で順位が上がるという保証をしていません。費用は抽出作業と編集確認を分け、まず入口記事や長い操作記事から直します。完了条件は、読者が目的の節を探せ、見出しが約束した説明をそこで読めることです。

• SEO記事の企画書を作る｜読者の質問・根拠・完成条件を先に決める
• 内部リンクの点検方法｜リンク切れ・孤立・不自然な関連記事を直す
• 公開前後のSEO確認｜URL・検索除外・言語版を検証する