フレッシュネススタンプ：公開日・更新日のルール

フレッシュネススタンプは、ページがいつ公開されたか、依存されている情報が最後にいつ変更されたか、そして必要に応じて何が確認されたかを読者に伝えます。これはオープニング要素です。時間の経過によって、その下にあるすべての主張の解釈が変わる可能性があるからです。

2026年8月27日更新 · 2025年3月14日公開 · 価格と機能の可用性を確認済み

このレンダリングされた標本は3つの異なる主張を行っています。「公開」は原点を保持し、「更新」は実質的な変更を記録し、範囲フレーズはレビューがカバーした範囲を示しています。日付は来歴のシグナルであり、装飾や古いコンテンツを新しく見せるためのショートカットではありません。

この要素が重要な理由

読者は日付を使ってリスクを評価します。3年前の数学的概念の説明は完全に信頼できるかもしれませんが、3ヶ月前のソフトウェア価格の比較はすでに間違っている可能性があります。可視的なスタンプは、読者がページを信頼するか、変動しやすい主張を検証するか、新しい情報源を探すかの判断に役立ちます。両方の日付を表示することで履歴も保護されます。読者は、成熟したリソースが維持されてきたのか、新しく公開されたかのように偽って表示されているのかを確認できます。

ラベルが過剰に主張すると心理的効果は失敗します。「本日更新」は、読者が依存する情報を誰かが変更したことを示唆します。変更が日付だけ、句読点の修正、またはページを新しいテンプレートに移動しただけの場合、ラベルは信頼を獲得することなく製造します。コンテンツ管理システムが編集を容易にしても、コンテンツに実質的に触れることなく更新日を変更することはポリシー違反です。

機械による抽出可能性により、ソフトウェアは散文から推測することなく、公開時間、変更時間、レビュー範囲、およびそれらの関係を特定できます。安定したフィールドは、ページテンプレート、フィード、監査、構造化データに値を提供できます。クローラーはdatePublishedとdateModifiedを区別でき、編集モニターはレビュー期間が切れた変動ページを特定できます。「最近リフレッシュしました」のような曖昧な表現は、使用可能なタイムスタンプも検証可能な主張も提供しません。

型付き要素は、通常の散文に手入力された日付よりも優先されます。要素の記述ルール に従ってください。コンポーネントは正規の日付フィールドを読み取り、一貫してレンダリングする必要があります。作成者はメタデータから乖離する可能性のある2つ目の日付を手入力してはいけません。

使用すべきタイミング

年齢がページの安全性、正確性、有用性を実質的に変える場合にフレッシュネススタンプを使用します。一般的なトリガーは、価格、製品機能、在庫状況、法律、規格、統計、ランク付けされた推奨、互換性の指示、資格ルール、スケジュール、指名された担当者です。これらの事実は、散文が変わらなくても世界が変わるため劣化します。

公開者が定義された主張を再確認することを約束する場合、生きたリソースに使用します。ソフトウェアの比較では「プランと機能制限を確認済み」、ドキュメントでは「バージョン6.8で確認済み」、規制説明では管轄区域と有効なルールを記載する場合があります。範囲は、1つのテーブルの最近のチェックが、すべての文、リンク、結論が同様に精査されたことを示唆するのを防ぎます。

エバーグリーンコンテンツは、可視的なフレッシュネススタンプを必要としない場合があります。安定した定義、歴史的記録、固定されたケーススタディ、リリースノート、またはクローズドデータセットに関連する研究レポートは、通常、正直な公開日のみを必要とします。解釈が変更された場合は修正ノートや別の更新ログを追加しますが、不変の記録が四半期ごとに新しい日付を受け取るようなメンテナンスの見せかけを作ってはいけません。

類似するが異なるものには以下が含まれます：

• 自動的な現在日付： リクエストのたびに今日の日付をレンダリングすることはレビュー活動について何も伝えず、常に禁止されています。
• タイトル内の年：「 2026年ベストツール」は現在のカバレッジに関する主張であり、ページが2026年にチェックされた証拠ではありません。
• ビルドタイムスタンプ： サイトの再構築はファイルを変更しますが、編集上の実質は変えません。
• 範囲や所有者のないレビューバッジ： 監査可能な行為なしに権威を作り出します。
• 変更された製品フィード： 自動化された価格更新は特定のフィールドを更新するかもしれませんが、結論が再確認されない限り、周囲の編集分析を「更新」としてマークする正当な理由にはなりません。

配置場所

スタンプはヒーローメタデータ行に配置します。H1と1行の説明の下、かつイントロダクションまたは最初の直接回答要素の前に配置します。読者は、劣化する可能性のある主張に遭遇する前に時間的文脈を受け取る必要があります。長いページでは、特定のテーブルや証拠ブロックに独自のより狭い検証日がある場合、スタンプはその変動要素の横にも表示されることがあります。

テンプレートがサポートする場合、作成者とレビュー者の識別情報は同じ来歴領域に保持しますが、明確な読み取り順序（作成者、公開/更新日、レビュー範囲）を維持します。スタンプは読了時間の推定値の横に配置しても構いません。どちらも中立的なメタデータだからです。プロモーションバッジ、割引カウントダウン、「トレンド」ラベル、スター評価の横には配置してはいけません。これらのシグナルは、編集上の日付を緊急性や推奨のように見せる可能性があります。

イントロダクションの中、最初の変動主張の後、フッターのみ、または画像内にスタンプを配置しないでください。ヒーロー、サイドバー、テーブルで矛盾する日付を繰り返さないでください。セクションに独自のデータの年代がある場合は、ページレベルの更新日を変更するのではなく、「2026年6月までのデータ」または「2026年8月27日確認の価格」のようにラベルを付けます。

構成

1. プライマリラベル： 有効な変更が存在する場合は「更新」、それ以外の場合は「公開」。アイコンやツールチップではなく、可視テキストである必要があります。
2. プライマリ日付： 正規のメタデータから派生した、人間が読めるカレンダー日付。
3. オリジナル公開： プライマリラベルが「更新」で、来歴の表示が有益な場合に保持されます。
4. レビュー範囲： 実際に確認された事実、バージョン、管轄区域、またはデータセットを指定する、オプションの短いテキスト。
5. 機械タイムスタンプ： HTMLのdatetime属性内の完全なISO 8601値。時刻が保存されている場合はタイムゾーンを含みます。
6. ドキュメント内の関係： 要素はページヒーローに属します。より狭い証拠日付は、それが修飾する証拠の横に属します。

色、アイコン、間隔、区切り文字はレンダラーに属します。CSSが利用できない場合でも、意味的な順序は正しく読める必要があります。

デザイン例

サポートされているバリエーションは、外観上の好みではなく、異なる編集状態を反映しています。

公開のみ： 新しいページ、または実質的な改訂を受けたことのない安定したページに使用します。これがデフォルトです。

公開および更新： 実質的な改訂後に使用します。「更新」が先に来るのは、それが意思決定に関連する日付だからです。公開は履歴として残ります。

範囲指定検証： 定義された変動主張のみが再確認された場合、またはページがバージョンにバインドされている場合に、短い範囲を追加します。範囲はより広範な監査を含意してはいけません。

変更なしのレビュー： 実際のレビューでページがまだ正確であると判断された場合のみ使用します。reviewedAtを別途記録し、dateModifiedを変更せず、イベントを「更新」とラベル付けしないでください。

狭いビューポート： 完全なアイテム間で自然に折り返すことを許可します。日付を切り詰めたり、「公開」を非表示にしてラベルのない数字だけを残したりしないでください。

パラメータ

日付フィールドはメタデータ属性であり、作成された本文コピーではありません。これにより、可視ラベルがフィードやスキーマと矛盾するのを防ぎます。フロントマター仕様 は、ドキュメントレベルの値に関して権威を持ちます。

この要素には本文はなく、最初の見出しマッピングもありません。本文があると、作成者が正規のメタデータを複製する可能性があります。スコープは短く、安定しており、機械可読であるため、意図的に属性です。

構文とコード例

すべてのアダプターは同じ公開、変更、およびスコープ値を読み取ります。ロケールに合わせて日付をフォーマットしても構いませんが、その意味を変えてはいけません。

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

:::freshness-stamp{published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified"}
:::

Hugoショートコード契約

{{< freshness-stamp published="2025-03-14T09:00:00+01:00" updated="2026-08-27T10:00:00+02:00" scope="Pricing and feature availability verified" >}}

Hugoでは、推奨されるプロダクションアダプターはページメタデータから.Dateと承認されたupdatedパラメータを読み取るべきであり、作成者がそれらを繰り返す必要はありません。上記の明示的な値はポータブルフィールドマッピングを文書化したものであり、2番目の真実のソースをハードコードする許可ではありません。

WordPressブロック

<!-- wp:amicited/freshness-stamp {"published":"2025-03-14T09:00:00+01:00","updated":"2026-08-27T10:00:00+02:00","scope":"Pricing and feature availability verified"} /-->

WordPressアダプターは、投稿レコードからpublishedとupdatedをデフォルト設定し、スコープを編集フィールドとして公開し、日付のみの更新ワークフローが実際には行われなかった改訂を黙って提示するのを防ぐべきです。

例

2026年8月27日更新 · 2025年3月14日公開
価格、プラン制限、機能の可用性をベンダーページで確認済み。

これは適切な例です。ラベルが両方のイベントを保持し、スコープが変動しやすい事実を指定し、その主張をページの編集履歴とソース履歴に対して監査できるためです。レビュアーはここでの「更新」の意味を理解できます。

本日新しく更新しました！
最近公開されました。

これは不適切な例です。「今日」は編集イベントなしに移動し、「新しく」はプロモーション的であり、「最近」は履歴を消去し、どちらの行も機械可読なタイムスタンプを公開していません。ページが単に再フォーマットされただけの場合、これらのフレーズを正確な日付に置き換えても誤解を招くままです。正しい対応は、元の公開日を保持し、更新日を省略することです。

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

スタンプは、包含するArticle、TechArticle、NewsArticle、またはその他の正確なページタイプにdatePublishedとdateModifiedを提供できます。datePublishedは元の公開記録から取得されます。dateModifiedは最新の実質的なコンテンツ変更からのみ取得されます。何も変更しない別途記録されたレビューはdateModifiedを上書きしてはいけません。スキーマはレビューイベントを誤った変更に変えるべきではありません。

FreshnessStamp Schema.orgタイプを発明しないでください。レビュースコープは通常、可視テキストと内部監査メタデータとして残ります。ページが変動しやすい事実を引用する場合は、最近の日付がそれらを証明することを示唆するのではなく、ソースブロック にそれらの証拠を保持してください。

各日付は意味的な<time datetime="…">要素でレンダリングします。可視形式はページのロケールに従い、datetime値は曖昧さのない機械タイムスタンプを保持します。ラベルはテキストである必要があります。時計アイコン、緑色、ツールチップ、「2ヶ月前」のような相対的な表現に依存しないでください。装飾的にマークされた区切り文字は支援技術によって無視されるべきであり、折り返しは論理的な読み取り順序を保持する必要があります。

スタンプは静的なメタデータであるため、ARIAライブリージョン、ボタンロール、フォーカスターゲット、アナウンスメントは必要ありません。更新ログがリンクされている場合は、「もっと見る」ではなく、「変更内容を見る」のような説明的なラベルを使用してください。

記述ルール

ラベルは事実に基づく来歴として記述します：「公開」、「更新」、または「レビュー済み」。「今日」、「最近」、「新しい」、「フレッシュ」ではなく、絶対的なローカライズ日付を使用します。スコープは3～12単語に抑え、確認した対象を明示します：「コンテンツを確認しました」よりも「プラン価格と制限を確認済み」の方が強力です。感嘆符、緊急性、SEOの主張、またはページが完全に正確であるという約束を追加しないでください。

実質的な変更は、読者が依存する情報を改善する場合にのみupdatedをリセットします。正当なトリガーには、重要な事実の修正、古い価格や仕様の置き換え、製品変更後の指示の改訂、重要な証拠の追加、再評価後の推奨変更、回答を変えるのに十分な範囲の拡大、または意味のあるコンテンツ変更をもたらす文書化されたレビューの完了が含まれます。

以下はupdatedをリセットしません：タイプミスの修正、句読点、フォーマット、画像圧縮、CSSやテンプレートの変更、アナリティクスタグ、リンクトラッキング、メタデータのみの編集、自動ビルド、カテゴリ変更、著者プロフィールのフォーマット、または単にページを確認して変更の必要がなかった場合。壊れたリンクの置き換えは、移動先が証拠やガイダンスを変更する場合にのみ日付をリセットします。同等の動作するURLを交換するだけではリセットしません。

「Googleは新鮮なコンテンツを評価する」などの主張、プロモーションメッセージ、割引の有効期限、読了時間、著者経歴、ソースリスト、変更ログ、完全なレビュー方法論をスタンプ内に決して入れないでください。これらは異なる目的を持っています。更新を過去の日付に設定したり、公開日を上書きしたり、リポジトリから変更時刻を派生させたり、将来の更新日をスケジュールしたりしないでください。

これを使用する投稿タイプ

postTypesフロントマターがこのマッピングのソースです。含まれていることは、その形式に定期的な劣化リスクがあることを意味します。すべてのインスタンスが更新日を表示しなければならないわけではありません。

安定した用語集の定義、歴史的記録、クローズドデータセットの研究、リリースノートは通常、継続的な鮮度を主張することなく公開日を保持します。それらの証拠期間やリリースバージョンは、ロール式の「更新」ラベルよりも解釈の役割を果たします。

QAチェックリスト

• 元の公開日が保持され、その後のすべてのイベントよりも前または同じ日付である。
• updatedが、コンテンツまたは文書化された証拠に表示される実質的な変更に対応している。
• コンテンツ変更のないレビューは、updatedやdateModifiedではなくreviewedAtを使用している。
• 可視日付、フロントマター値、フィード値、構造化データ値が一致している。
• スコープは正確に何が確認されたかを示し、1つのブロックのみが変更されたのに全ページ監査を示唆しない。
• スタンプが変動主張の前にヒーローに表示され、より狭い日付がより狭い証拠の横にある。
• 絶対日付と可視テキストラベルが、色、アイコン、CSS、周囲の散文なしでも理解可能である。
• 各機械タイムスタンプが有効なISO 8601構文と正しいタイムゾーンを使用している。
• ビルド時間、ファイル変更時間、現在年のトークン、または自動的に移動する日付が要素に供給されていない。
• 編集履歴がなぜ日付が変わったかを説明できる。日付のみの編集はレビューに不合格となる。
• 公開、更新、レビュー済みのイベントが可視コピーとスキーマで区別されたままである。
• ページの投稿タイプと劣化リスクが要素の表示を正当化している。

FAQ

すべての記事に最終更新日を表示すべきですか？

いいえ。実質的な変更があった場合にのみ更新日を表示してください。安定したエバーグリーンページは公開日のみを表示できますが、劣化する可能性のあるページは、最新の有効なレビューの日付と範囲を明示する必要があります。

タイプミスの修正は更新日の変更を正当化しますか？

いいえ。タイポグラフィ、フォーマット、トラッキング、テンプレート、メタデータのみの編集は、読者が依存する情報を変更しないため、更新日をリセットしません。

変更が必要なかった場合、ページにレビュー日を表示できますか？

はい。資格のある担当者が定義された範囲を実際に確認し、ラベルが「更新」ではなく「レビュー済み」と表示されている場合に可能です。公開日と変更日は変更せず、レビューは別途記録してください。

更新後に公開日を削除すべきですか？

通常はいいえ。来歴が重要な場合は、元の公開日をメタデータに保持し、更新日の横に表示してください。更新日がページの履歴を書き換えてはいけません。

フレッシュネススタンプだけでランキングは向上しますか？

いいえ。日付ラベルはページの正確性の証拠にはなりません。その価値は、真実に基づくメンテナンス、一貫したメタデータ、そして実際に表明されたレビューを反映したコンテンツから生まれます。