「日付だけ更新」が危ない理由｜dateModified・タイトル年号・更新履歴の設計実務

「更新日を新しくしておけば、GoogleにもAIにも『最新の記事』として扱われて引用されやすくなる」——コンテンツ運用の現場でいまだに根強い考え方ですが、これは誤解です。Googleは公式ドキュメントで「コンテンツを実質的に変更していないにもかかわらず、ページを新鮮に見せるためにページの日付を変更していますか」という問いを、避けるべき検索エンジン第一のコンテンツ作成の自己評価項目として明記しています。つまり「日付だけの更新」は、鮮度の演出どころか、品質評価上のマイナス要因になり得る行為としてGoogle自身が名指ししているのです。

結論を先に言います。AI検索時代の鮮度対策とは「日付を新しく見せること」ではなく、「中身の更新と、更新日・年号・履歴・時点表記という鮮度シグナルを一致させること」です。ここがズレた瞬間に、鮮度シグナルは偽シグナルに変わります。

定義：鮮度シグナルとは、コンテンツの新しさを検索エンジンやAIに伝えるページ上・データ上の手がかりの総称である。具体的には、構造化データのdatePublished/dateModified、ページに表示される公開日・更新日、タイトルや見出しの年号、更新履歴の記載、本文中の「2026年8月時点」といった時点修飾などが含まれる。鮮度シグナルは実際のコンテンツ更新と一致していて初めて機能し、中身を変えずに日付だけ新しくする運用は偽の鮮度シグナルとなる。

なお、古い情報をどう更新・統合・クローズするかという「コンテンツ更新の運用全体」は、姉妹記事のAI検索時代のコンテンツ更新で扱っています。この記事はその手前にある「鮮度シグナルの設計」——dateModifiedの付け方、タイトル年号の運用、更新履歴ボックスの書き方——に絞ります。

先に落とし穴から：「偽の鮮度」がリスクになる3パターン

実装の話に入る前に、やってはいけないパターンを先に押さえます。鮮度シグナルの設計は「何をやるか」より「何をやらないか」の方が重要だからです。

3つに共通するのは「シグナルと実体の不一致」です。Googleは公開日の判定について「単一の日付要素には依存しない。どの要素も問題を起こしうるからだ」と説明しており、構造化データの日付・ページ上の可視日付・実際のコンテンツ変更などを複合的に見ていると読めます。日付フィールドだけを操作しても、他の手がかりと突き合わせられれば不一致は露呈する、という前提で設計するべきです。

dateModifiedの正しい使い方：「宣言」ではなく「記録」にする

構造化データ（Article、BlogPosting等）のdatePublished / dateModifiedは、Googleが公式に指定を推奨しているフィールドです。正しく使うための原則は3つです。

原則1：dateModifiedは実質的な変更があった日だけ動かす

誤字修正やCSSの調整でdateModifiedを動かすべきかどうかは公式に細かく定義されていませんが、判断基準はシンプルに持てます。「読者にとって情報の意味が変わる更新をしたか」です。料金改定の反映、仕様変更への追随、章の追加、古い記述の訂正——これらは動かす。テンプレート変更、軽微な文言調整、画像圧縮——これらは動かさない。この線引きを社内で明文化しておくと、CMSの「保存したら自動で更新日が変わる」挙動に引きずられずに済みます。

WordPressの場合、記事を開いて保存するだけで更新日時が書き換わるテーマ・プラグイン構成が少なくありません。「保存＝更新日更新」になっていないか、軽微修正用に更新日を維持できる手段があるかを、運用開始前に確認しておくべきポイントです。

原則2：可視日付と構造化データを一致させる

Googleは「ユーザーに見える日付と、構造化データの日付（時刻・タイムゾーンを指定する場合はそれも）を一致させる」ことを明示的に求めています。ありがちな不一致は次の形です。

• テーマが表示する「最終更新日」とプラグインが出力するdateModifiedが別ソースで、片方だけ動く
• 手書きの「2026年8月更新」という本文表記と、構造化データの日付がズレたまま放置される
• タイムゾーン指定漏れで、深夜更新が日付をまたいでズレる

構造化データを直接編集しない運用の場合でも、「表示されている日付」と「ソースに埋まっている日付」をリリース後に一度突き合わせる工程を入れると、この種の不一致は大半防げます。構造化データ全般の実装の考え方はAI検索時代の構造化データで整理しています。

原則3：ページ内の「その他の日付」を最小限にする

Googleのドキュメントは、公開日・更新日以外の日付情報をページ内で最小限にすることも推奨しています。関連記事リストの日付、コメント欄の日付、サイドバーの新着日付などが本文近くに大量にあると、どれがこのページの日付なのかの判定材料が濁ります。特に一覧要素をページ上部に置いているテンプレートは注意が必要です。

タイトルの年号運用：【2026年最新】の功罪

タイトル年号は、鮮度シグナルの中で最も読者の目に触れ、最も乱用されている要素です。効果と副作用を分けて考えます。

功の側面は明確で、年号付きで検索するユーザー（「◯◯ 補助金 2026」など）の意図に正面から応えられること、そして検索結果やAIの回答画面で「いつ時点の情報か」を一目で伝えられることです。情報の時点が回答の質を左右するテーマでは、年号は読者への誠実な表示になります。

罪の側面は、年号が「更新の約束」になることです。【2026年最新】と書いた瞬間、その記事は「2026年の状況を反映し続ける」という約束を読者と交わしたことになります。守れなければ誇大表示です。そして年が変わるたびにタイトルを書き換える運用コストが発生し、書き換え忘れた記事から順に「【2024年最新】と書いてある古い記事」として信頼を毀損していきます。

判断に迷ったら「1年後にこのタイトルのまま放置されたとき、読者を騙す表示になるか」で決めるのが実務的です。騙す表示になるなら、年号はタイトルではなく本文の時点修飾（後述）に置く方が安全です。

更新履歴ボックスの書き方：「何を・いつ・なぜ」を残す

更新日そのものより雄弁な鮮度シグナルが、更新履歴です。「2026年8月5日更新」という日付だけの表示と、「2026年8月5日：◯◯の料金改定を反映し、旧料金の記述を時点明示に変更」という履歴では、読者にもAIにも伝わる情報量がまったく違います。更新履歴は「この日付は実体のある更新である」ことの証明になり、偽の鮮度との差別化そのものです。

書き方の要点は3つです。

• 変更対象を特定する：「一部更新しました」ではなく「第3章の◯◯手順をバージョンXX時点の画面に差し替え」のように、どこを変えたかを書く
• 変更理由を書く:「制度改正のため」「公式ドキュメントの記載変更のため」など、更新のトリガーを書く。読者が「次にいつ変わりそうか」を推測できる
• 履歴は消さない：直近3〜5件程度をページ内に残す。全件をだらだら載せる必要はないが、履歴の存在自体が「継続的にメンテナンスされているページ」の証跡になる

当社の自社メディア運用でも、情報が動いた記事には更新追記ボックスを置き、「何をいつ変えたか」を1行ずつ残す形をとっています。手間は1回あたり数行の記述だけですが、「更新日は新しいのに何が変わったのか分からないページ」との差は蓄積で大きくなります。

配置は記事冒頭直下か記事末尾のどちらかで統一します。冒頭直下は「最新の変更を先に伝えられる」利点があり、時点が重要なテーマ（制度・料金・仕様）に向きます。

情報が変わったときの追記：旧記述は消すより「時点を明示」する

情報が変わったとき、旧記述を黙って上書きするのは実は次善手です。推奨は「新情報を追記し、旧記述に時点修飾を付けて残す」運用です。

例えばこう書き換えます。

• 変更前：「本ツールの無料プランでは月10回まで実行できます」
• 変更後：「本ツールの無料プランでは月20回まで実行できます（2026年8月時点。2026年前半までは月10回でした）」

この「時点修飾＋旧記述の時点明示」には3つの利点があります。第一に、AI検索がこの一文だけを切り出して引用しても、いつ時点の情報かが文の中で完結します。切り出されても意味が通る文を作ることは、AI検索対策の基本原則です。第二に、旧情報しか知らない読者に「変わった」という事実そのものを伝えられます。第三に、更新履歴ボックスと本文が相互に裏付け合い、dateModifiedの変更に実体があることの証跡になります。

逆に避けたいのは「昨年」「先月」「現在」といった相対的な時点表現です。書いた瞬間は正しくても、時間が経つと意味がズレ、AIが古いスナップショットを参照した場合には誤読の元になります。時点は必ず「2026年8月時点」のような絶対表記にします。

鮮度が効くテーマ、効かないテーマの見分け方

すべての記事で鮮度を追う必要はありません。Googleは、ランキングにおけるコンテンツ鮮度の役割について「最新のニューストピックの検索では、辞書の定義の検索よりも鮮度が大きな役割を果たす」と公式に説明しています。鮮度の重みはクエリの性質によって変わる、というのが確認できる事実です。

これを記事テーマの判断に落とすと、次のように整理できます。

なお、ここで確認できているのはGoogle検索のランキングに関する公式説明です。ChatGPTやPerplexityなどのAI検索・AIアシスタントが引用元選定で更新日をどの程度重視するかは、各社が内部仕様として詳細を公開しておらず、断定できません。ただし、これらのサービスも回答生成時にWebページの本文を読み取る以上、「本文中の時点が明示されていれば古い情報を最新と誤認しにくくなる」方向の設計は、仕様の詳細に依存しない安全側の打ち手です。引用元に選ばれるページの条件整理はAI検索の引用で扱っています。

確認できる事実と、仮説として扱うべきこと

この記事の主張のうち、一次情報で確認できる範囲と仮説の範囲を明示しておきます。

実装チェックリスト

自サイトの鮮度シグナル設計を点検する際のチェックリストです。

古い記事そのものをどう扱うか（更新・統合・クローズの判断）は、コンテンツ更新の運用設計の記事のチェックリストと組み合わせて使ってください。

FAQ：更新日と鮮度シグナルでよくある質問

記事を更新したら、必ず更新日を新しくするべきですか

実質的な変更——読者にとって情報の意味が変わる更新——をしたときだけ動かすのが原則です。誤字修正やデザイン調整で日付を動かすと、日付の情報価値そのものが薄まります。逆に、大きな更新をしたのに日付が動いていないのも機会損失です。「動かす基準」を文書化して一貫させることが、どちらの失敗も防ぎます。

公開日と更新日はどちらを表示するべきですか

両方表示するのが最も誠実です。更新日だけを表示すると「元はいつ書かれた記事なのか」が隠れ、公開日だけだと更新の事実が伝わりません。Googleの構造化データはdatePublishedとdateModifiedの両方の指定に対応しており、どちらか一方またはいずれも指定できます。

タイトルの年号は毎年書き換えるべきですか

そのテーマが実際に年単位で変わり、かつ本文も年次で見直せる体制があるなら書き換えます。体制がないなら、年号をタイトルから外して本文の時点修飾に置き換える方が、放置されたときの信頼毀損を防げます。「書き換え続ける約束を守れるか」で判断してください。

更新日を新しくすれば、AI検索に引用されやすくなりますか

その保証はどこにもありません。AI検索各社は引用元選定の内部仕様を公開しておらず、更新日単独の効果は検証不能です。確実に言えるのは、中身の伴わない日付更新はGoogleが公式に避けるべきとする行為であり、リスク側に振れるということです。狙うべきは日付の操作ではなく、実体のある更新と、それを正確に伝えるシグナルの一致です。

古い記事は削除した方がいいですか

「古いから削除」は短絡です。Googleは「サイトを新鮮に見せるために大量の古いコンテンツを削除してもランキングは向上しない」と明言しています。更新して活かすか、統合するか、閉じるかの判断基準は姉妹記事のコンテンツ更新の運用設計で整理しています。

結論

鮮度シグナルの設計は、一言でいえば「日付と実体を一致させる仕組みづくり」です。

• 日付だけの更新・実体のないタイトル年号・未来日付は、鮮度ではなく偽シグナル。Googleが公式に避けるべきとする行為であり、リスクにしかならない
• dateModifiedは「実質的変更があった日」だけ動かし、可視日付と構造化データを一致させる
• 更新履歴ボックスと本文の時点修飾（絶対表記）が、日付に実体があることの証明になる
• 鮮度の重みはテーマ型で違う。速報型はフル装備、普遍型は無理に日付を動かさない

自サイトの鮮度シグナルがどう出力されているか、日付の不一致や放置された年号がないかを第三者視点で確認したい場合は、LLMO診断で構造化データ・日付表記を含むAI検索観点の現状確認ができます。まずは上のチェックリストで自己点検し、判断に迷う箇所が出てきた段階で相談していただくのが効率的です。