技術記事のH2は書きたい話題を並べるより、読者が作業するときの順番で決めます。途中で必要な権限や準備が出てくる構成では、手順を読み直すことになります。
見出しだけを読んで作業の流れが分かるかを最初に確認します。ただし、すべての記事を同じH2へ当てはめず、説明、比較、実行のどれを主に扱うかで順番を変えます。
記事の用件から順番を決める
たとえばAPI下書き作成の記事なら、認証や利用権限をコードの後へ置かず、実行前の条件として示します。手順を終えた読者が何を見て成功と判断するかも、独立した説明にします。
背景説明が長くなる場合は、作業に必要な前提を先に置き、詳しい仕組みを後へ回す方法もあります。読者が今必要な説明かを見て決めてください。
| 記事の用件 | 見出しの順番の例 |
|---|---|
| 仕組みを知る | 何ができるか→前提→具体例→制約 |
| 操作する | 準備→手順→結果確認→失敗時の確認 |
| 選ぶ | 比較する条件→候補ごとの違い→条件別の判断 |
| 障害を調べる | 症状の記録→確認の分岐→原因別の対応→復旧確認 |
曖昧な見出しを具体的にする
「ポイント」「注意点」「確認すること」だけでは、その節で何が分かるかが伝わりません。節の内容に合わせて「投稿IDと公開状態を確認する」のように対象と作業を示します。
同じ意味のH2が複数あるなら、内容をまとめるか役割を分けます。見出しに合わせるためだけに節を増やさず、本文が数行で終わる場合も独立した節が必要かを判断します。
一つのH2に一つの主な用件を持たせると、その下に置く説明を選びやすくなります。例外、原因、操作が混在する場合は、どこまでを一緒に読む必要があるかを考えます。
階層と本文を最後に照合する
H2の中の小見出しはH3など、内容の階層に合わせます。WAIはH2から直接H4へ進むような見出しレベルの飛び越しを可能な限り避ける考え方を示しています。文字の大きさを変える目的で見出しを選びません。
確認時は目次、見出し直後の最初の文、節の終わりを順に読みます。見出しで約束した説明が本文にあるか、次の節へ進むための前提がそろうかを点検してください。
H2の数やキーワードの回数に共通の正解を置く設計ではありません。読者の用件を満たす節数と順番を選び、見出しの変更だけで検索順位が改善すると判断しないようにします。
