SEO Playbook · Element

箇条書きリスト:書き方のルール、構造、例

箇条書きリストを使用して、並列的で独立したポイントをスキャンしやすく抽出しやすくしながら、それらに文脈を与える推論、階層、議論を維持します。

2 min read

箇条書きリストは、関連性のある独立したポイントの順不同の集合です。これにより、読者はカテゴリを一度認識した後、段落から抽出することなく各メンバーをスキャンできます。箇条書きは、項目が同じ論理レベルにあり、その順序が意味を変えない場合にのみ使用します。

  • すべての項目を同じ文法形式で開始する。
  • すべての項目を同じ長さ帯に収める。
  • 最初の箇条書きの前に集合を導入する。
  • 最後の箇条書きの後に推論に戻る。

上記のレンダリング例は真のリストです。4つのピアルールで、すべて命令文で表現され、位置に依存しません。上の段落がカテゴリを確立し、下の文が集合が何を証明するかを説明しています。箇条書きは、議論を置き換えることなく、議論へのアクセスを向上させます。

この要素が重要な理由

読者は段落を文の集まりとしてスキャンしません。彼らは主張を探し、アイデア間の関係を追跡し、説明が注目に値するかどうかを判断します。箇条書きリストはその読み行動を変えます。その垂直的なリズムは、「これらのポイントは同等です。一つずつ確認しても構いません」というシグナルを送ります。これにより、関連する要件、オプション、症状、特性を見つけるために必要な労力が軽減されます。

同じ境界が機械抽出性、つまり検索エンジン、AIシステム、またはコンテンツ変換ツールが共有コンテキストを保持しながら項目を分離する能力を向上させます。意味論的な順不同リストは、コレクションとそのメンバーを明示的に公開します。また、並列的な冒頭の単語は、機械が項目が同じ役割を果たしていることを推測するのにも役立ちます。「管理者アクセスが必要」「検証済みドメインが必要」「アクティブなサブスクリプションが必要」は、質問、断片、解説が混在する3つの項目よりも明確なセットを形成します。

箇条書きは散文よりも自動的に明確になるわけではありません。段落は、文と接続詞を通じて原因、対比、条件付け、順序、結論を表現します。それを箇条書きに変換すると、これらの関係が消失する可能性があります。リストは見た目は簡単になりますが、伝える内容は少なくなります。これがこの要素の中心的なリスクです。視覚的なスキャン容易性が、失われた推論を隠してしまう可能性があります。

要素の書き方ルール が優先されます。外観を選択する前に、その一節が何をするのかを特定してください。結論の要約は、たとえその要素が箇条書きをレンダリングしても、キーテイクアウェイ に属します。順序付けられた指示はステップリスト に属します。箇条書きリストが正しい要素となるのは、その目的が、周囲の議論の中で順不同の同等項目のセットを提示することである場合のみです。

使用するタイミング

一つのリードインが正確に3つ以上の項目を統括でき、各項目が独立して読んでも有用である場合に、箇条書きリストを使用します。強力な使用例としては、要件、特性、1つのカテゴリからの例、非順序的なオプション、障害症状、包含基準、同等の優先度のコンパクトな推奨事項などがあります。

散文を変換する前に3つのテストを実行します:

  1. 同等性テスト: すべての項目が同じ暗黙の質問に答えることができますか?
  2. 順序テスト: 隣接する2つの項目を入れ替えても、指示や結論は変わりませんか?
  3. コンテキストテスト: リードインは各項目に十分なコンテキストを提供し、各項目がそれを繰り返す必要はありませんか?

3つすべてが合格すれば、箇条書きはおそらく有効です。順序テストに失敗した場合は、番号付き指示または時系列の散文を使用します。同等性テストに失敗した場合は、素材を別の段落または見出しに分割します。コンテキストテストに失敗した場合は、各ポイントに独自の説明が必要です。

特に注意すべきニアミスのケース:

  • 一連のアクションは、あるアクションが次のアクションを可能にする場合、箇条書きリストではなく、順序付けられた手順です。
  • 一連の主張は、2つ目が1つ目を条件付け、3つ目が結論を導き出す場合、リストではなく、議論です。
  • 一連の製品は、読者が基準ごとの評価を必要とする場合、必ずしもリストとは限りません。比較表 を使用します。
  • 一連の完了ゲートは、読者がそれぞれを確認する必要がある場合、単なる情報提供ではなく、チェックリストです。
  • 2つの選択肢が箇条書きを正当化することはほとんどありません。それぞれにかなりの説明が必要でない限り、「Xを使用する場合…;Yを使用する場合…」と記述します。

長すぎる段落を、なぜ長いのかを診断する前に箇条書きで救おうとしないでください。段落には複数の主張、不足している見出し、または未発展の因果関係が含まれている可能性があります。最初にその構造を修正してください。箇条書きは万能の整理ツールではありません。

配置する場所

集合を命名し、読者がそれを必要とする理由を説明する完全なリードインの直後に箇条書きリストを配置します。「移行に必要なもの:」は文法的ですが、結果を確立しないため弱いです。「ロールバックで元の状態を復元できるように、移行前にこれら4つの入力を収集してください:」は、項目が何であるか、なぜ重要かを読者に伝えます。

項目が決定や主張をサポートする場合は、リストの直後に解釈を配置します。閉じの段落は、集合によって作成されたパターン、優先順位、例外、または次のアクションを特定する必要があります。リストが純粋に列挙的な目的の場合、小さな参考セクションを終了しても構いませんが、議論を宙ぶらりんのままにしてはいけません。

正確な配置ルール:

  • リードインとリストを同じセクションに配置します。読者が箇条書きが何を列挙しているのかを知るために見出しをまたがせることは決してしないでください。
  • 証拠はそれがサポートする主張の隣に配置します。主張とその引用、計算、または条件付けの間にリストを挿入しないでください。
  • 意味の変化を説明する遷移なしに、順不同リストを順序付きリストのすぐ隣に配置しないでください。
  • 2つの箇条書きリストを連続して積み重ねないでください。解釈を追加するか、真の同等項目を統合するか、各集合に説明的な小見出しを付けます。
  • 両方が同じ素材を要約している場合、一般的な箇条書きリストをキーテイクアウェイボックスのすぐ下に配置しないでください。
  • 最後の箇条書きの中にコールトゥアクションを配置しないでください。集合を閉じ、結論を説明し、その後アクションを別に提示します。

この要素は長いページに複数回出現することがありますが、散文がそれらのリスト間の関係を伝える必要があります。すべてのセクションが見出しと箇条書きになると、ページは孤立リスト障害を発症します。コレクションは存在しますが、それらがどのように関連しているかを説明するものは何もありません。

構成

完全な箇条書きリストには5つの意味領域があります:

  1. コンテキスト: コレクションを関連性のあるものにする先行する主張または説明。
  2. リードイン: 共有カテゴリを命名する完全な文。
  3. リストコンテナ: 項目間の関係を確立する1つの意味論的な順不同リスト。
  4. 項目: 並列文法と一貫した詳細レベルを持つ同等のステートメント。
  5. 解釈: 集合を議論に再接続する後続の文または段落。

マーカー、インデント、および間隔は階層を見えるようにしますが、それを定義するものではありません。スタイル、スクリプト、視覚マーカーがない場合でも、ソース構造は順不同リストのままである必要があります。

デザイン例

デザインシステムは3つのバリエーションをサポートしています。それらのコンテンツ契約は同じままです。密度とレイアウトのみが変更されます。

デフォルト

完全な文章とほとんどの編集コンテンツには、デフォルトのシングルカラムバリアントを使用します。各項目にスキャンするのに十分な分離を与えながら、集合を視覚的につなぎ合わせます。

コンパクト

ラベル、短い要件、または3〜12語の値にはコンパクトな間隔を使用します。コンパクトは、推論を断片に圧縮する許可ではなく、周囲の散文が依然としてコンテキストを提供します。

2カラム

2カラムは、レンダラーの読み取り順序で理解可能なままの6〜10個の短く独立した項目にのみ使用します。狭い幅では、レイアウトは1カラムに折りたたまれる必要があります。説明付きのポイント、手動のカラム間順序付け、または順序がランキングを示唆する項目には使用しないでください。

ネイティブのリスト意味論を装飾的なアイコンや無関係なコンテナで置き換えるバリアントはありません。視覚的なカスタマイズは、1つのコレクションとステートメントごとに1つの項目を維持する必要があります。

パラメータ

以下の制限は、リストがセクションになるべきサイズに拡大するのを防ぎます。「Source」は、正規の値が作成される場所を示します。

名前必須最小/最大デフォルトソース
variantEnumいいえdefaultcompact、または two-columndefaultディレクティブまたはショートコード属性
titleプレーン文字列いいえ2〜8語;60文字省略本文の最初の見出し。投稿タイプがタイトル付きブロックを要求する場合のみ
leadInプレーンMarkdownはい8〜35語;1文なしリストの前の本文
itemsMarkdownリストはい3〜10項目;目標3〜7なし本文
itemプレーンMarkdownはい3〜45語;リストごとに1つの選択された長さ帯なし各本文リスト項目
item.linkルート相対またはHTTPS URLいいえ項目あたり0〜1のプライマリリンク省略インライン本文リンク
interpretationMarkdownリストが議論をサポートする場合に必須10〜80語;1段落純粋に列挙的な参照リストの場合は省略リストの後の本文

レンダラーはリードインからタイトルを推測しません。タイトルは再利用可能または投稿タイプ定義のブロックを命名します。リードインは、周囲の散文と項目の間の文レベルの関係を完成させます。ほとんどのインラインリストにはタイトルは必要ありません。

構文とコード例

3つのマッピングすべてが同じリードイン、項目、バリアント、および解釈を保持します。ポータブルディレクティブが正規です。HugoとWordPressの例はプラットフォームアダプターを説明しており、ページ固有のスタイリングを許可するものではありません。

ポータブルMarkdownディレクティブ

:::bullet-list{variant=default}
公開前にこれらの条件を確認してください:

- 主張はその範囲と期間を明示しています。
- ソースは使用された正確な表現をサポートしています。
- ページは重要な制限事項を説明しています。

これらのチェックを合わせることで、防御可能な主張が過大評価になるのを防ぎます。
:::

Hugoショートコード

{{< bullet-list variant="default" >}}
公開前にこれらの条件を確認してください:

- 主張はその範囲と期間を明示しています。
- ソースは使用された正確な表現をサポートしています。
- ページは重要な制限事項を説明しています。

これらのチェックを合わせることで、防御可能な主張が過大評価になるのを防ぎます。
{{< /bullet-list >}}

プロジェクトがそのアダプターを登録するまでは、ローカルなショートコードを発明するのではなく、通常の意味論的Markdownとしてコンテンツをレンダリングします。ソースは依然として編集契約を満たします。

WordPress

<!-- wp:amicited/bullet-list {"variant":"default"} -->
<p>公開前にこれらの条件を確認してください:</p>
<ul>
  <li>主張はその範囲と期間を明示しています。</li>
  <li>ソースは使用された正確な表現をサポートしています。</li>
  <li>ページは重要な制限事項を説明しています。</li>
</ul>
<p>これらのチェックを合わせることで、防御可能な主張が過大評価になるのを防ぎます。</p>
<!-- /wp:amicited/bullet-list -->

カスタムブロックが存在しない場合、ネイティブのWordPressリストブロックと段落ブロックが正しいアクセシブルなフォールバックです。テーマがサポートしている場合のみ、ラッパーのバリアントを保持します。

良い例:並列的な公開前チェック

比較を承認する前に、すべてのオプションが同一の処理を受けていることを確認します:

  • すべてのオプションに同じ評価基準を適用します。
  • 同等の期間からの証拠を使用します。
  • 重要な制限事項は、影響を受ける主張の隣に明記します。
  • 測定された事実と編集上の判断を分離します。

これらの項目は、1つの質問(比較を公平にするものは何か)に答え、それぞれが命令形の動詞で始まり1つの目的語が続くため、機能します。長さは類似しており、順序は交換可能で、閉じの文は共通の基準を説明しています。

悪い例:箇条書きに分解された議論

  • 読者はページをスキャンします。
  • スキャンが一般的だから、リストは有用です。
  • しかし、リストは接続詞を削除します。
  • したがって、リストは慎重に使用し、アクセシビリティもテストしてください。これはスクリーンリーダーにも重要であり、いくつかの実装の詳細があります。

これは悪い例です。なぜなら、項目が同等ではないからです。それらは前提、推論、条件付け、結論を形成しており、移動すると議論が変わります。文法と長さも揺らいでいます。この一節を箇条書きに書き換えることで、接続的な推論が削除された一方で、隠れた段落を明らかにする遷移語は保持されています。散文として記述します:読者はページをスキャンするため、リストは同等のポイントを見つけるのに役立ちます。しかし、リストは接続詞を削除するため、作成者は集合の前後で推論を維持する必要があります。

スキーママークアップとアクセシビリティ

通常の箇条書きリストには、スタンドアロンのスキーママークアップは必要ありません。それは、それを囲む ArticleTechArticle、製品説明、または他のページレベルのタイプ内の可視コンテンツのままです。HTMLに <ul> が含まれているという理由だけで ItemList マークアップを作成しないでください。構造化データは、意味のあるエンティティのコレクションを表すべきであり、すべての視覚的な列挙を表すべきではありません。

ItemList は、リスト自体が主要で有限なコレクション(宣言されたロケーションのセットやランク付けされた製品など)であり、すべての可視項目が実際の ListItem にマッピングされる場合に適切です。順不同のコレクションの場合、position を通じてランクを発明したり、優先度を暗示したりしないでください。スキーマ出力は、可視の数と名前と一致する必要があります。ほとんどの編集用箇条書きは、スキーマプロパティに直接フィードされません。

アクセシビリティは <ul> と項目ごとの1つの <li> から始まります。段落内に箇条書き文字を入力したり、改行を挿入して項目を模倣したり、CSSがマーカーを描画できるという理由だけで一連の <div> 要素を使用したりしないでください。スクリーンリーダーはネイティブリストの境界と項目数をアナウンスし、可視読者が受け取るのと同じカテゴリシグナルをユーザーに提供します。

ネストは1レベルまでにし、すべての子がその親に属する場合にのみ行います。ネストされたリストには少なくとも2つの項目が必要です。単一のインデントされた項目は通常、別の文です。カスタムアイコンが装飾的である場合、競合するアクセシブルな名前を持たないようにしてください。リンクはそのリンク先を説明し、意味がマーカーの色、形状、またはカラム位置に依存してはいけません。2カラム出力は、予測可能なソースとキーボード読み取り順序を維持する必要があります。

書き方ルール

3つの項目長さ帯のうち1つを選択し、リスト全体でそれを使用します:

  • スキャンラベル:3〜12語。 ツール、要件、症状、またはコンパクトなカテゴリメンバーに使用します。
  • 完全な文章:8〜25語。 独立して成立するルール、利点、基準、推奨事項に使用します。
  • 説明付きポイント:20〜45語。 各項目に1つの理由または条件付けが必要な場合に使用します。より長い説明は散文またはサブセクションに移動します。

通常は3〜7項目を使用します。2項目は文または対比に収まります。8〜10項目には明確な理由、意図的なグループ化、および通常はコンパクトまたは2カラムのバリアントが必要です。10項目を超えると読者は自分でカテゴリを作成する必要があるため、集合を分割するか小見出しを導入します。

並列構造は必須です。すべての項目を同じ品詞で開始し、同じ暗黙の主語を維持します。良いセットは命令形動詞(「確認」、「記録」、「テスト」)、名詞(「アクセス」、「証拠」、「所有権」)、または完全な平叙文を使用します。ある項目を動詞で始め、別の項目を「〜すべきです」で始め、3つ目の項目を質問で始めないでください。

トーン、時制、句読点、大文字小文字、詳細レベルを一致させます。文先頭の大文字化(センテンスケース)を使用します。完全な文にはピリオドで終了し、短い断片からはピリオドを省略します。長く同一の冒頭を繰り返す代わりに、差異化する単語を早めに配置します。太字は短いラベルとそれに続く説明を識別するために使用できますが、すべての項目が同じラベルパターンを使用する必要があります。

通常の箇条書きリストの中に以下を決して入れないでください:

  • 順序が結果に影響する必須の順序付きアクション。
  • 複数の段落、複数の見出し、または項目ごとの独立したミニ記事。
  • 表、フォーム、ビデオプレーヤー、テスティモニアル、またはプロモーションカード。
  • 正確さを保つために項目外のコンテキストに依存する無限定の主張。
  • 要件、例、結論、コールトゥアクションの混合。

孤立リスト障害を避けてください。これは、ほとんどすべての段落が箇条書きに変換され、原因、対立、証拠、または結論を確立する散文が残らなくなったときに発生します。実用的なレビューシグナルは、それぞれが短いリードインとリストを含むが解釈段落を含まない3つの連続したセクションです。最も強い主張を散文に戻し、重複するコレクションを統合し、同等性、順序、コンテキストテストに合格するリストのみを保持します。

使用する投稿タイプ

以下の行は postTypes フロントマターによって駆動されます。「Use」は箇条書きの役割を説明しており、すべてのページに強制する要件ではありません。

投稿タイプ使用位置
アルティメットガイド通常は、同等の特性、例、要件、またはコンパクトなセクション要約に使用。関連する教育セクション内、コンテキストの後、解釈の前。
ハウツーガイド場合により、順不同の前提条件、消耗品、結果、またはトラブルシューティング症状に使用。順序付きステップの前、またはサポート説明内。手順の代わりとしては決して使用しない。
リスティクルガイド通常は、各エントリ内の一貫した機能や基準に使用。各エントリ内の評価の後、すべてのエントリに同じ項目パターンを使用。
A対Bの比較場合により、オプション間のスキャンを必要としない同等の強みや制約に使用。基準の説明の下。読者が行を直接比較する必要がある場合は表を使用。
チェックリスト記事控えめに、完了ゲートではないコンテキストや例に使用。チェック可能なセットの外側で、意味の違いを明示する遷移を伴う。
トラブルシューティングガイド通常は、順序が関係しない症状、考えられる原因、または収集する証拠に使用。症状の説明の後、順序付き診断または修復の前。
ドキュメンテーション記事通常は、要件、受け入れ可能な値、権限、非順序的なオプションに使用。それが条件付けする機能または設定の隣。コマンドとその結果の間には配置しない。

QAチェックリスト

公開前に、すべての項目を確認します:

  • リードインは1つのカテゴリを命名し、その集合がなぜ重要なのかを説明している。
  • すべての項目が同じ暗黙の質問に答え、同じ論理レベルにある。
  • 項目の並べ替えても指示、順序、または議論が変わらない。
  • すべての項目が並列的な文法、トーン、時制、大文字小文字、句読点を使用している。
  • すべての項目が選択された1つの長さ帯内に収まり、リストが3〜7項目(または正当な例外)を含む。
  • リストが装飾的な箇条書き文字ではなく、意味論的な <ul><li> 出力を使用している。
  • ネストされた項目は1レベルで停止し、カラムは予測可能な読み取り順序を保持している。
  • リンクは説明的で検証済みであり、項目ごとに1つのプライマリリンクに制限されている。
  • 集合が議論をサポートする場合、リストの後の段落が解釈を述べている。
  • リストが型指定された要約、チェックリスト、ステップリスト、表、または他の目的固有の要素を重複していない。
  • ページがコレクション間の推論を伝えるのに十分な散文を含み、孤立リスト障害を回避している。
  • ポータブルMarkdown、Hugo、WordPressマッピングが同じ項目と意味を保持している。

FAQ

箇条書きリストは何項目を含むべきですか? 通常は3〜7を使用します。読者が自分で分類する必要がないように、より長いセットはグループ化または分割します。

各箇条書きの長さはどのくらいにすべきですか? リスト全体で1つの帯を選びます:3〜12、8〜25、または20〜45語。最大値に達することよりも一貫性が重要です。

箇条書き項目には句読点を付けるべきですか? 完全な文にはピリオドを使用し、短い断片には末尾の句読点を付けません。選択を一貫して適用します。

箇条書きリストにリンクを含めることはできますか? はい、ただし説明的なアンカーテキストを使用し、通常は項目ごとに1つ以下のプライマリリンクにします。

箇条書きはいつ番号付きステップにすべきですか? 順序が結果に影響する場合は番号を使用します。順不同の箇条書きは、順序が重要でないことを約束します。

箇条書きリストは、実際のコレクションを公開し、散文が推論を続けることを可能にする場合に機能します。目標はあらゆる行でスキャン容易性を最大化することではなく、それらを意味のあるものにする関係を破壊することなく、同等のポイントを見つけやすくすることです。

← All SEO Playbook guides

実践する準備はできましたか?

無料チェック · 7日間お試し · クレジットカード不要