SEO Playbook · Element

タイムライン:イベントとフェーズを順序正しく提示する方法

日付のあるイベントと順序付けられたフェーズの意味を保持するタイムラインを構築し、読者と機械が何がいつ変更され、なぜそれが重要なのかを理解できるようにします。

3 min read

タイムラインとは、イベント、マイルストーン、または名前付きフェーズの順序付き記録であり、その位置が何がいつ起こったか、またはテーマがどのように発展したかを伝えます。読者は順序を観察します。再現するよう指示されているわけではありません。

  1. 1
    2025年3月 — 研究承認
    チームはデータ収集開始前に、コホート、質問、比較方法を確定しました。
  2. 2
    2025年4月~5月 — ベースライン収集
    定義された収集期間中、すべての参加者について同じ指標が記録されました。
  3. 3
    2025年6月 — 結果公開
    レポートは、方法、制限事項、次のレビュー日とともに結果を公開しました。

このレンダリング例は、完了した研究の流れを説明しています。その順序は承認、収集、公開の関係を説明していますが、どのエントリーも読者にそれらのアクションの実行を命令するものではありません。

この要素が重要な理由

人々は変化を再構築するために、何が起こったのか、いつ起こったのか、そしてそれは何を引き起こし、可能にしたのかという3つの質問をします。タイムラインは、それらの質問に1つの繰り返しパターンで答えます。日付またはフェーズマーカーが方向性を作り出し、イベントタイトルが変化に名前を付け、説明が重要性を説明します。読者は既知のマイルストーンをスキャンしたり、イベント間のギャップを比較したり、現在の状態がなぜ以前には存在し得なかったかを理解したりできます。

その視覚的なリズムは記憶への負荷も軽減します。通常の散文では、日付が修飾するイベントから分離される可能性があり、読者は年代を組み立てる前にいくつかの文を頭の中で保持する必要があります。境界のあるタイムラインは、各マーカーをそのイベントに結び付け、欠落や説明のない飛躍を可視化します。これは、文章の主張が順序に依存する場合に特に有用です。介入後に観察された結果は、介入前に収集された結果とは異なる意味を持ちます。

機械抽出可能性とは、クローラー、検索エンジン、AI回答システム、または公開アダプターが、順序やフィールドを失うことなく各レコードを分離できる能力です。一貫した日付、タイトル、説明領域を持つ意味的な順序付きリストは、段落に散在する日付よりも強力な構造を機械に提供します。システムは3番目のイベントを3番目のイベントとして識別し、「2025年6月」と「結果公開」の関係を保持し、説明を誤って4月に結び付けることなく引用できます。

優先順位ルールとして要素作成ルール を使用してください。文章の目的が時間の経過に伴う変化を記録することである場合は、見出しと数段落で同様に見えても、型付きタイムラインを使用してください。目的が指示、比較、または独立した検証である場合は、デザイナーがその横に垂直線を描けるかどうかに関わらず、対応する要素が優先されます。

使用すべき場合

順序付けが主張の一部であり、各項目がイベント、マイルストーン、状態遷移、または文書化されたフェーズを表す場合にタイムラインを使用してください。適切な対象には、企業の歴史、製品のリリース、規制の採択と施行日、完了したケーススタディの段階、またはレポートの収集と公開フェーズが含まれます。

選択する前に2つのテストを適用してください。

  1. 交換テスト: 隣接する2つのエントリーを入れ替えます。その説明が歴史的に偽りになる、因果関係を誤解させる、または時間的に混乱を生じさせる場合、順序に意味があります。
  2. 観察者テスト: 読者が何が起こったかを学んでいるのか、何をすべきかを指示されているのかを問いかけます。観察はタイムラインを示し、実行はステップリスト を示します。

類似しているが異なる構造には、別の構造が必要です。

  • 手順: 「データをエクスポートし、クリーニングし、アップロードする」は読者に指示します。歴史的なイベントの説明ではなく、アクション、成功シグナル、回復パスが必要です。
  • チェックリスト: 「所有者、日付、ソース、ステータスを確認する」は独立した検証ゲートを含みます。それらの順序は意味を生み出しません。
  • 機能リスト: 「レポート、統合、アラートをローンチ」は単に機能を列挙している可能性があります。日付のあるリリースとその結果が重要な場合にのみタイムラインになります。
  • 前後比較の主張: 2つの状態は通常、直接比較として示す方が明確です。最小項目数を達成するために装飾的な中間点を追加しないでください。
  • プロジェクト計画: 予定日は、スケジュール済みまたは予測として明確にラベル付けされている場合にのみタイムラインを使用できます。意図を完了した歴史として提示しないでください。
  • プロセスの概要: ページがプロセスの編成方法を説明する場合、名前付きフェーズはタイムラインを使用できます。読者がそれらのフェーズを実行する必要がある場合は、代わりにステップリストまたはチェックリストを使用してください。

日付の存在だけでは十分ではありません。無関係な会議の日付のリストはカレンダーまたはリストです。タイムラインには1つのテーマと一貫した発展の流れが必要です。

配置する場所

タイムラインは、そのテーマ、範囲、方向を記載した短い文の直後に配置してください。「以下のマイルストーンは設立から現在の製品までを示しています」で十分です。読者は最初の項目が最も古いのか、最新なのか、完了したのか、予定なのかを推測する必要があってはなりません。

正確な位置はその役割によって異なります。

  • 歴史的なタイムラインは、テーマの定義または現状の要約の後、その歴史がなぜ重要なのかの分析の前に配置します。
  • ケーススタディのタイムラインは、開始状況と範囲の後、詳細な結果の前に配置し、読者がベースライン、介入、測定を区別できるようにします。
  • リリースタイムラインは、現在のリリース要約の後に配置します。最新の変更の発見が主要タスクである場合は新しい順を使用し、その方向をラベル付けします。
  • 実装またはポリシーの年表は、ルールの範囲の後、現在の義務の前に配置します。発効日は、折りたたまれたインターフェースの外側でも表示されたままである必要があります。
  • 研究タイムラインは、収集のタイミングが解釈に影響を与える場合、方法の要約の後、結果の前に配置します。

タイムラインは、どのブロックが履歴を記録し、どのブロックがアクションを指示するかを説明するトランジションなしに、同じテーマに関するステップリストのすぐ隣に配置してはなりません。主張とその裏付けソースの間、警告とその結果の間、または比較セルの中に挿入してはなりません。2つのタイムラインを連続して配置しないでください。テーマと規模を共有している場合は結合するか、2番目のシーケンスがなぜ異なるのかを説明する分析で区切ってください。

イベント間にプロモーショナルな Call to Action を配置しないでください。これは時系列の流れと順序付きリストのセマンティクスの両方を損なうものです。プロモーションはタイムライン全体とその解釈の後に配置してください。

構造

ラベル付きの構造には7つの部分があります。

  1. 範囲見出し: コレクションが表すテーマと時間範囲を指定します。
  2. 方向の手がかり: 周囲の文脈で明白でない場合、古い順から新しい順、または新しい順から古い順を明記します。
  3. 順序トラック: 基礎となる <ol> がスタイリングなしで順序を保持しながら、レコードを視覚的に接続します。
  4. 日付またはフェーズマーカー: 利用可能な最も正直な精度で、イベントがいつ発生したかを識別します。
  5. イベントタイトル: コンパクトな過去形または現在形のフレーズで、変更またはマイルストーンを述べます。
  6. 説明: 何が変わったのか、なぜこのイベントがシーケンスに属するのかを説明します。
  7. ステータス: オプションで、完了、現在、予定、遅延、中止のイベントを色だけでなく言葉で区別します。

線、ドット、アイコンは装飾です。日付、タイトル、説明、順序、ステータスはコンテンツであり、テキスト、印刷、CSSなしの出力でも利用可能でなければなりません。

デザイン例

サポートされているすべてのバリアントは、1つの順序付きリストと同じ項目フィールドを保持します。バリアントは密度や強調を変更しますが、意味は変えません。

標準垂直

3〜8個のイベントに1〜2文の説明でデフォルトを使用します。可変長のテキストに折り返しの余地を与え、狭い画面でも確実に機能します。

コンパクトチェンジログ

リリースのような短く頻繁な記録にはコンパクトな間隔を使用します。タイトルが先行し、説明は1文に留めます。新しい順は、見出しまたは方向の手がかりがそう述べている場合にのみ許可されます。

マイルストーン強調

2〜6個の転換点がそれらの間隔よりも重要な場合にマイルストーン強調を使用します。強調表示された現在のマイルストーンには、可視の「現在」という言葉を含める必要があります。サイズや色だけでは不十分です。

フェーズタイムライン

正確な日付が利用できないか、ライフサイクル上の位置よりも有用でない場合に名前付きフェーズを使用します。フェーズマーカーは相互に区別可能で、一貫した粒度でなければなりません。「発見」、「収集」、「公開」であって、「発見」、「5月12日」、「後日」ではありません。

水平ワイドスクリーン

水平プレゼンテーションは、3〜5個の簡潔なマイルストーンにのみ、かつソース順序を変更せずに小さな画面で垂直順序付きリストになる場合にのみ使用してください。イベントを発見するために水平スクロールを必要としないでください。

混合ステータスロードマップ

完了イベントと予定イベントの両方を含む本格的なロードマップには、このバリアントを使用します。すべての項目にテキストによるステータスが必要であり、不確かな日付にはでっち上げの日付ではなく「2026年第4四半期」などの正直な範囲を使用します。

パラメータ

契約は、コレクション設定と繰り返しのイベントレコードを分離します。最初の親見出しがコレクションタイトルを提供し、各項目の最初の見出しがそのイベントタイトルを提供します。

名前必須最小/最大デフォルトソース
titleプレーン文字列はい3〜12語;90文字なし親本文の最初の見出し
variant列挙型いいえverticalcompactmilestonephasedhorizontal、またはroadmapvertical属性
direction列挙型いいえascending または descendingascending属性
items順序レコードコレクションはい3〜12項目なしネストされた本文項目
item.markerプレーン文字列またはISO日付はい1〜6語;40文字なし項目属性
item.titleプレーン文字列はい2〜10語;80文字なし項目本文の最初の見出し
item.description制限付きMarkdownはい12〜60語;最大120語最初の見出し以降のコンテンツ項目本文
item.dateISO 8601日付いいえ1つの有効な日付省略項目属性
item.status列挙型いいえcompletedcurrentscheduleddelayed、またはcanceledcompleted項目属性
item.id小文字識別子リンクされるまでいいえページ内で一意;2〜8のハイフン区切り語タイトルから生成、その後固定項目属性

marker は可視であり、「2025年5月」や「2026年第3四半期」など、読者が理解できる精度の日付を含めることができます。date は、ソースが機械可読なカレンダー日付をサポートする場合にのみ指定してください。「2025年春」のようなマーカーは、でっち上げのISO日付に変換してはなりません。フェーズバリアントでは、marker にフェーズ名が含まれ、date は通常省略されます。

構文とコード例

以下の3つの形式はすべて、同じ完了した年表をエンコードしています。ポータブルディレクティブが正規の作成構造であり、プラットフォームアダプターは順序、フィールド、可視の表現を保持する必要があります。

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

:::timeline{variant=vertical direction=ascending}
## 研究と公開のタイムライン

::item{marker="March 2025" date="2025-03-01" status=completed id="research-approved"}
### 研究承認

チームはデータ収集開始前に、コホート、質問、比較方法を確定しました。
::

::item{marker="April–May 2025" status=completed id="baseline-collected"}
### ベースライン収集

定義された収集期間中、すべての参加者について同じ指標が記録されました。
::

::item{marker="June 2025" date="2025-06-18" status=completed id="findings-published"}
### 結果公開

レポートは、方法、制限事項、レビュー日とともに結果を公開しました。
::
:::

範囲「April–May 2025」には date 属性がありません。これは、1つのISO日付では複数月にわたるイベントを誤って表現するからです。

Hugoショートコード

{{< timeline_with_icon >}}
[
  {"title":"March 2025 — Research approved","description":"The team fixed the cohort, questions, and comparison method before collection began."},
  {"title":"April–May 2025 — Baseline collected","description":"The same measures were recorded for every participant during the defined window."},
  {"title":"June 2025 — Findings published","description":"The report released its results with methods, limitations, and a review date."}
]
{{< /timeline_with_icon >}}

既存のHugoレンダラーは、title とオプションの description フィールドを持つJSON配列を受け入れ、ソース順でレコードをレンダリングします。マーカーとタイトルを title に結合することは、現在のアダプターマッピングです。よりリッチなレンダラーは、正規コンテンツを変更せずにこれらの可視領域を分離する場合があります。

WordPressブロック

<!-- wp:amicited/timeline {"variant":"vertical","direction":"ascending"} -->
<!-- wp:amicited/timeline-item {"marker":"March 2025","date":"2025-03-01","status":"completed","id":"research-approved"} -->
<h3>Research approved</h3>
<p>The team fixed the cohort, questions, and comparison method before collection began.</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"April–May 2025","status":"completed","id":"baseline-collected"} -->
<h3>Baseline collected</h3>
<p>The same measures were recorded for every participant during the defined window.</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"June 2025","date":"2025-06-18","status":"completed","id":"findings-published"} -->
<h3>Findings published</h3>
<p>The report released its results with methods, limitations, and a review date.</p>
<!-- /wp:amicited/timeline-item -->
<!-- /wp:amicited/timeline -->

WordPressはレコードを、編集時に順序がずれる可能性のある無関係なビジュアルカードとしてではなく、子項目を持つ1つの順序付き親ブロックとして保存する必要があります。

良い例:規制の実装履歴

2024年1月 — ルール公開。 規制当局が最終テキストを発行し、対象範囲内の組織を確認しました。

2024年7月 — 移行期間開始。 対象組織は、従来の形式が引き続き受け入れられている間、新しい報告形式を採用できました。

2025年1月 — 要件発効。 新しい提出物は公開された形式を使用する必要があり、移行オプションは終了しました。

2025年4月 — ガイダンス明確化。 規制当局は、修正提出物が元の報告期間をどのように識別すべきかを説明しました。

これは優れたタイムラインです。すべてのエントリーが文書化されたイベントを説明し、精度が一貫しており、順序が公開から移行、施行、明確化への移行を説明しているからです。読者は、将来の期限を過去のイベントと誤認することなく、現在の義務を理解できます。

悪い例:記事最適化のタイムライン

1 — 例を追加。 記事に有用な例を含めます。

2 — 見出しを確認。 見出しが各セクションを説明していることを確認します。

3 — 内部リンクを追加。 関連コンテンツにリンクします。

これは悪い例です。なぜなら、これは年表でも適切な手順でもないからです。番号には日付やフェーズがなく、アクションは結果を変えずに異なる順序で実行できます。これをタイムラインと呼ぶことは、独立したチェックを誤った順序で飾り立てることです。独立したレビューゲートにはチェックリストを使用し、依存関係によって実行順序が必要な場合にのみステップリストを使用してください。

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

Schema.orgには汎用の Timeline タイプはありません。発明されたプロパティを出力したり、ブロックを構造化されたように見せるためだけに ItemList を追加したりしないでください。タイムラインは、適切な語彙がすでに存在する場合(例えば、ソフトウェア関連ページに公開リリース日がある場合)、ページレベルの構造化データに可視の事実を提供することができますが、そのマッピングはビジュアルコンポーネントではなく、ページのスキーマ契約によって管理されます。構造化データには、可視のタイムラインから省略されたイベント、日付、またはステータスを含めてはなりません。

信頼できる機械可読ベースラインは、セマンティックHTMLです。意図された読み順の1つの <ol> と、イベントごとに1つの <li> です。<time datetime="2025-06-18">June 2025</time> は、機械日付がソースによって裏付けられている場合にのみ使用してください。可視マーカーが四半期、季節、範囲、または名前付きフェーズである場合、プレーンテキストがでっち上げの datetime 値よりも誠実です。

アクセシビリティは、グラフィックトラックに依存せずに順序を保持することに依存します。見出しがテーマと方向を指定し、順序付きリストが数と位置を提供し、各イベントはマーカー、タイトル、説明、ステータスをまとめて保持します。装飾的な線、ドット、アイコンは空の代替を使用するか、支援技術から隠されます。ステータスはテキストとして書かれ、緑、琥珀、または塗りつぶされた円だけで伝えられてはいけません。

タイムラインを読むためにキーボード操作を必要とすべきではありません。個々のイベントがエビデンスや詳細にリンクする場合は、通常の説明的なリンクと可視のフォーカス状態を使用してください。水平レイアウトは、キーボードやタッチユーザーを横スクローラーに閉じ込めるのではなく、リフローする必要があります。200%ズーム、狭いビューポート表示、印刷出力、CSSなしの出力は、すべて同じ順序を保持する必要があります。

作成ルール

1つのタイムラインには3〜12個のイベントを使用してください。3つ未満の場合は、通常の散文または直接的な前後比較の方が明確です。12を超えると、読者は全体像を失います。イベントを名前付きの時代にグループ化するか、独立した範囲を持つ個別のタイムラインを作成してください。

各イベントタイトルは2〜10語で、説明は12〜60語で記述してください。タイトルは変更点から始め、「要件発効」は「重要な新しい段階」よりも強力です。説明は何が変わったのか、なぜそのイベントが重要なのかに答えてください。完了したイベントには過去形、現在の状態には現在形、予定のイベントには未来形または予定を表す表現を使用してください。

日付の精度はエビデンスに従わなければなりません。ソースが年のみをサポートする場合は、年を公開してください。四半期をサポートする場合は、表示やメタデータのために四半期の初日をでっち上げないでください。タイムライン内では1つの日付スタイルを使用してください。「2025年6月18日」は「06/20/25」の隣にあってはならず、数値日付は地域による解釈があいまいな場合には避けるべきです。

粒度を一貫させてください。「会社設立」、6つのマイナーな毎週のパッチ、「国際展開を達成」を組み合わせたタイムラインは、戦略的マイルストーンよりもルーチンの変更に視覚的重みを与えます。リリースを一貫して記録するか、マイルストーンを一貫して選択し、選択ルールを明記してください。

イベント内に以下を決して配置しないでください。

  • 読者が実行する必要のある複数ステップの指示
  • 無関係なプロモーショナルな Call to Action
  • イベントの証拠として使用される推薦文
  • 展開の背後に隠された重要な警告
  • 項目数を減らすために結合された複数の独立したイベント
  • ソースがサポートしていない日付またはステータス

トーンは事実に基づき、コンパクトで、具体的であるべきです。「ゲームチェンジングなマイルストーン」などの祝賀的な表現は、ページがそれを引用として帰属させ、文脈を提供する場合を除き避けてください。タイムラインは熱意ではなく、検証可能な順序を通じて信頼性を確立します。

使用する投稿タイプ

以下の行は postTypes フロントマターによって駆動され、登録された投稿タイプスラグのみを使用します。

投稿タイプ使用頻度配置
ケーススタディ通常、タイミングがベースライン、介入、測定結果を区別する場合。開始状況と範囲の後、詳細なエビデンスと結果の前。
リリースノート頻繁に、リリースシリーズ内の日付付き製品変更に。現在のリリース要約の後。ラベル付けされている場合のみ新しい順。
会社概要時々、選択的でソースのある企業履歴に。現在のアイデンティティ要約の後、現在の事業やリーダーシップの前。
ベンチマークレポート時々、研究フェーズが解釈に影響を与える場合。方法と範囲の後、結果の前。
標準・規制ページ頻繁に、公開、移行、発効、レビュー日が異なる場合。範囲の後、現在の義務とコンプライアンス詳細の前。
究極ガイドまれに、トピックの展開が現在の形式を理解するために必要な場合。概念が定義された後、ガイドの現状分析の前。

ページに意味のある年表がない場合、投稿タイプテンプレートを満たすためにタイムラインを追加しないでください。フロントマターはサポートされる関係を表現しますが、すべてのインスタンスがその要素を含む必要があるという要件ではありません。

QAチェックリスト

公開前に、以下すべてを確認してください。

  • すべての項目がイベント、マイルストーン、状態、またはフェーズを記録しており、読者に指示していない。
  • 隣接するイベントを入れ替えると、説明が偽り、誤解を招く、または理解しにくくなる。
  • 導入部がテーマ、範囲、および時系列の方向を指定している。
  • タイムラインに3〜12の項目が含まれているか、明確なグループ化の決定が文書化されている。
  • 日付の精度とステータスがソースによって裏付けられている。正確な日付がでっち上げられていない。
  • タイトルは2〜10語、説明は通常12〜60語である。
  • イベントは一貫したレベルの粒度と1つの日付スタイルを使用している。
  • 完了、現在、予定、遅延、中止の記録が可視テキストで区別されている。
  • ソースは順序付きコレクションであり、出力はイベントごとに1つの <li> を持つ1つの <ol> を使用している。
  • マーカー、タイトル、説明、ステータスが印刷、CSSなし、狭い画面の出力でまとまっている。
  • 装飾的な線、アイコン、色は、テキストにない情報を伝えていない。
  • 構造化データは可視イベントと正確に一致し、ページに適切な語彙のみを使用している。
  • ポータブルMarkdown、Hugo、WordPressのマッピングが同じ順序と意味を保持している。
  • 配置がエビデンス、警告、指示、または最終的な解釈を妨げていない。

FAQ

タイムラインとステップリストの違いは何ですか? タイムラインは何が起こったかを記録します。ステップリストは読者に何をすべきかを伝えます。観察者テストが選択を決定します。

すべてのタイムライン項目に正確な日付が必要ですか? いいえ。エビデンスが裏付ける最も正確なマーカー(月、四半期、年、または名前付きフェーズを含む)を使用してください。

タイムラインにはいくつのイベントを含めるべきですか? 3〜12個を使用してください。より長い履歴は名前付きの時代または別々のシーケンスにグループ化してください。

タイムラインには独自のSchema.orgタイプがありますか? いいえ。セマンティックな順序付きリストHTMLと、適切な語彙に正直に一致するページレベルの構造化データのみを使用してください。

タイムラインを新しい順から古い順に並べることはできますか? はい。最新優先の発見が読者の主要タスクである場合に可能です。方向をラベル付けし、一貫性を保ってください。

← All SEO Playbook guides

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

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