AI検索で更新日を正しく伝える｜dateModifiedとsitemap lastmodの設計
AI検索の更新日設計を、画面表示、datePublished・dateModified、sitemapのlastmod、RSS、検証手順から解説。日付だけを新しくする誤更新を避けます。
この記事の目次を開く
AI検索へ更新日を正しく伝えるには、本文を大幅に更新した日だけを画面上の最終更新日、Article構造化データのdateModified、sitemapのlastmodへ一貫して反映します。公開日はdatePublishedとして残し、フッターの年や自動ビルド時刻で更新日を書き換えません。
更新日の表示は、内容がいつ確認されたかを読者が判断する材料です。一方、日付を新しくすればAI回答へ引用されやすくなる、検索順位が上がるとはいえません。GoogleはAIによる概要やAIモードに特別なマークアップを要求しておらず、通常検索の技術要件とユーザー第一のコンテンツを基礎にしています。
難しいのはタグの追加より、「何を変えたら更新とみなすか」をCMS、構造化データ、サイトマップで同じ規則にすることです。日付の意味をどの層で揃え、どこまで確認すればよいのでしょうか。
AI検索の更新日も通常SEOの基盤から設計する
Google検索のAI機能に関する公式ガイドは、AIによる概要やAIモードのサポートリンクになるページについて、通常のGoogle検索にインデックスされ、スニペット表示の対象となることを要件に挙げています。AI機能専用の構造化データや機械可読ファイルは不要です。
したがって、AI検索のためだけに未知の更新日タグを追加する必要はありません。まず、読者に見える日付、標準的なArticle構造化データ、XMLサイトマップを整合させます。構造化データはページに表示される本文と一致させるという原則も、AI機能で変わりません。
更新日を整えても、クロール、インデックス、AI回答への引用は保証されません。目的は「新しいページに見せること」ではなく、公開時点と大幅更新時点を、読者と検索システムが誤解しにくい状態にすることです。
公開日と最終更新日を別の事実として残す
Googleの署名日に関するガイドは、ページが公開または更新されたとGoogleが推定した日を検索結果に表示する場合があると説明しています。判定は一つの要素だけに依存せず、複数のシグナルを使います。
ページ上では、「公開日」「最終更新日」とラベルを付け、目立つ位置に表示します。初回公開から変更がなければ公開日だけでも構いません。内容を大幅に直したら、公開日を消さずに最終更新日を追加します。
公開日: 2026年7月1日
最終更新日: 2026年8月10日
公開日を更新日で上書きすると、記事が最初に公開された履歴を失います。反対に、料金、法令、製品仕様などを大きく修正したのに公開日しか表示しなければ、読者は確認時点を判断しにくくなります。
日付の近くに、更新内容を短く示す方法もあります。
- 料金表と適用条件を2026年8月時点の公式情報へ更新
- 廃止されたAPI手順を削除し、現行エンドポイントへ変更
- 調査対象を追加し、集計方法を本文へ明記
単に「最新情報へ更新」と書くより、どの事実を確認したかが分かります。更新履歴が長くなる場合は主要な変更だけを残し、GitやCMSの履歴で詳細を追えるようにします。
datePublishedとdateModifiedを画面表示へ合わせる
ArticleやBlogPostingの構造化データでは、初回公開日をdatePublished、大幅な更新日をdateModifiedで表せます。Googleも両方またはいずれかの指定を推奨し、画面に見える日付との整合を求めています。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトル",
"datePublished": "2026-07-01T09:00:00+09:00",
"dateModified": "2026-08-10T09:00:00+09:00"
}
時刻を含める場合はタイムゾーンまで指定します。画面では8月10日、JSON-LDではUTC換算の別日、サイトマップでは8月11日という状態を避けます。CMSの保存日時、公開日時、デプロイ日時を無条件に使うとずれやすいため、記事データに「初回公開」と「意味のある最終更新」を別フィールドで持たせます。
既にLLMOの構造化データ実装がある場合も、プロパティを増やす前に画面上の本文と一致しているかを確認します。構造化データは内容を補足するもので、表示していない最新性を作る場所ではありません。
sitemapのlastmodは「最後の大幅更新」に限定する
XMLサイトマップのlastmodは、URLが最後に大幅更新された日付または日時を示します。Googleのサイトマップ公式ガイドでは、値が一貫して実際の更新と一致する場合に利用すると説明されています。
本文、構造化データ、主要な内部リンクの変更は、大幅更新の候補です。著作権年の自動更新、全ページ共通フッターの微修正、ビルドのたびに変わるハッシュは、記事のlastmodを更新する理由にしません。
<url>
<loc>https://example.com/blog/example</loc>
<lastmod>2026-08-10T09:00:00+09:00</lastmod>
</url>
よくある誤りは、デプロイ時刻を全URLのlastmodへ入れる実装です。記事本文が変わっていなくても全ページが毎日更新扱いになり、値と現実が一致しません。サイトマップ生成では、URLごとのコンテンツ更新日時を使います。集約ページは掲載記事の追加で内容が大きく変わる場合がありますが、個別記事と同じ規則をそのまま当てず、ページ種別ごとに判断します。
Googleはサイトマップの送信をヒントとして扱い、クロールやインデックスを保証していません。lastmodを更新しただけで再クロールを約束するものでもありません。正確な値を継続できないページでは、誤った値を毎回出すより省略を検討します。
RSS・フィード・内部リンクも公開前の記事を出さない
ブログではHTML、サイトマップに加え、RSSやAtom、llms.txtなど複数の一覧を生成する場合があります。未来予約の記事をHTML一覧では隠していても、フィードにタイトルとURLが出れば、公開前のURLが外部へ伝わります。
各出力は同じ公開判定を使います。
draftが解除されている- 予約日時を現在時刻が過ぎている
- URLがHTTP 200で本文を返す
- canonicalとサイトマップのURLが一致する
- 公開日・更新日が画面、構造化データ、フィードで矛盾しない
日付だけで公開を制御するサイトでは、静的生成のキャッシュにも注意します。予約時刻を過ぎても再生成されなければ、メタデータ上は公開済みなのに一覧へ出ません。公開判定とキャッシュ更新の間隔を決め、予約時刻前後のテストを用意します。
更新前後の検証手順
日付フィールドを追加したら、ソースコードだけでなく公開URLを確認します。
- ページ上に公開日と最終更新日が適切なラベルで表示される
- JSON-LDの
datePublishedとdateModifiedがページ表示と一致する - タイムゾーンを含む日時が意図した日付へ変換される
- sitemapの
lastmodが大幅更新したURLだけで変わる - RSS・Atomの公開日時と更新日時が記事データから生成される
- 予約前の記事が一覧、サイトマップ、フィード、
llms.txtへ出ない - URL検査やリッチリザルトテストで取得HTMLを確認できる
自動テストでは、予約時刻の直前と直後、公開日と更新日が同じ場合、更新日だけが変わる場合を固定時計で検証します。日付を文字列比較する場合は、YYYY-MM-DDとRFC 3339を混ぜないことも重要です。比較前に同じタイムゾーンと粒度へ正規化します。
公開後は、日付が検索結果へ必ず表示されるとは限りません。Googleの公式ガイドも表示を保証していません。Search Consoleのインデックス状況、取得日時、ページの検索パフォーマンスを確認しつつ、更新日の有無だけを順位や引用の原因と断定しません。LLMOの効果測定では、引用、流入、問い合わせを分けて記録します。
AI検索の更新日設計の完了条件
更新日設計の完了条件は、dateModifiedを追加することではありません。最初に公開した日を保持し、本文が大幅に変わった日だけを最終更新日として画面に表示し、同じ事実を構造化データとサイトマップへ反映できることです。
さらに、予約前の記事をどの出力にも出さず、公開時刻後にキャッシュが更新されることをテストします。これで、読者と検索システムへ矛盾の少ない日付情報を提供できます。AI回答への引用、再クロール、順位、流入は保証されません。日付を新しく見せる施策ではなく、更新した事実と確認時点を正確に伝える運用として続けます。