情報の鮮度とAI検索対策｜更新日の正しい示し方と記事更新の優先順位

「去年書いた料金比較の記事は、そのままでいいのだろうか」。「更新日を新しくすれば、検索にもAIにも有利になるのではないか」。

自社サイトを運用していると、情報の新しさについて、こうした迷いが出てきます。

ChatGPTやPerplexity、GoogleのAI Overviewsのような検索は、Web上の情報を集めて答えを組み立てます。古い料金や終了したサービスの記述が残っていれば、読者にもAIにも、誤った情報を渡すことになります。

一方で、日付だけを新しくする「見せかけの更新」には、Googleが公式に注意を促しています。

この記事は、自社サイトを運営する中小企業のWeb担当者や経営者に向けて書きました。更新日をページ、構造化データ、サイトマップの3か所でそろえる方法と、どの記事から更新するかの決め方を、公式の説明に沿って整理します。

GoogleとBingの公式ページは、2026年10月18日に開いて確かめました。書き方の型や例は、筆者の提案で、例の会社名・日付・記事名はすべて架空です。

日付だけを変えたときにAIの引用がどうなるかという研究は、別の記事にまとめています。この記事は、その続きとして「日付をどう示し、何をいつ直すか」に絞ります。

日付だけ更新すればAIに引用されるのかの記事

先に結論：鮮度対策の6つの要点

要点を、先に表にします。

番号	要点	理由
1	日付は、ページの表示・構造化データ・サイトマップの3か所でそろえる	Googleは、表示と構造化データの日付を一致させるよう案内している
2	更新日を変えるのは、実質的に内容が変わったときだけにする	内容が変わっていないのに日付を変える行為は、Googleの自己点検の問いに挙がっている
3	サイトマップのlastmodは、本当に変わった日時だけを入れる	GoogleもBingも、実態と合う値を求めている
4	料金や仕様には「2026年10月時点」のように時点を書く	読む人が、情報の新しさを自分で判断できる
5	更新の順番は、アクセス・問い合わせ・古さ・変わりやすさで決める	全記事は一度に直せないため（筆者の提案）
6	役割を終えた記事は、統合・301・削除を使い分ける	内容の関係が薄いページへの一括転送は避ける

6つのうち、1から3が日付の示し方で、4から6が更新の進め方です。

使った情報源

この記事の公式情報は、次のページです。

情報源	確かめた内容
Google検索セントラル「検索結果に出る日付に影響を与える方法」	日付の表示、ラベル、構造化データ、他の日付の扱い
Google検索セントラルのブログ（2019年3月）「ページに最適な日付をGoogleに伝える」	大きく更新したときの日付、タイムゾーン、一貫性
Google検索セントラル「Article構造化データ」	datePublishedとdateModified、ISO 8601
Google検索セントラル「有用で信頼性の高いコンテンツの作成」	日付だけを変えていないかを問う自己点検
Google検索セントラル「ランキングシステムのガイド」	新しさが求められる検索の鮮度のしくみ
Google検索セントラル「サイトマップの作成」と2023年6月のブログ	lastmodの使われ方と、正しい入れ方
Bing Webmaster Blog（2025年7月31日）	サイトマップのlastmodと、AI検索の鮮度
Google検索セントラル「リダイレクト」「サイト移転」「クロールエラーの確認」	301、ソフト404、404と410

ChatGPTやClaudeなど、Google以外のAIサービスが日付をどう扱うかについては、確かめられた公式の説明がありません。そのため、Googleの仕組みについては「Googleでは」、Bingの仕組みについては「Bingでは」と範囲を限って書きます。

鮮度について、公式に確かめられること

Google：新しさが求められる検索には、鮮度のしくみがある

Googleのランキングシステムのガイドには、新しさが求められる検索向けのしくみが載っています。名前は「query deserves freshness」で、新しい情報がふさわしい検索には、より新しい内容を出すための仕組みです。

公式の例は2つです。公開されたばかりの映画を調べる人には、制作が始まった頃の記事より、最近のレビューが役立ちます。

「地震」の検索は、ふだんは備えの情報が中心でも、地震が起きた直後は、ニュースなど新しい内容が出ることがあります。

新しさが効くのは、新しい情報を求める検索

ガイドの書き方から読み取れるのは、新しさが効くのは「新しい情報が期待される検索」だという点です。ここは筆者の読み方です。

長く変わらないテーマの記事で、日付が新しいだけのページが優先されるという説明は、このガイドにはありません。

Google：日付だけ変えて新しく見せることへの注意

Googleの「有用で信頼性の高いコンテンツの作成」は、検索エンジン向けに作った内容かどうかを確かめる問いを並べています。その中に、次の2つがあります。

• 内容が実質的に変わっていないのに、新しく見せるためにページの日付を変えていないか
• 新しく見せるために、大量の内容を追加したり削除したりしていないか。公式の注記は、それが順位の助けにはならないというもの

Googleが求めているのは、日付の新しさよりも、内容が今も正しく役立つことです。

Bing：サイトマップの更新日時を、AI検索の鮮度の手がかりにしている

Bingの公式ブログ（2025年7月31日）は、AIを使った検索では、鮮度の信号が、更新が検索結果やAIの回答に反映される速さに影響すると説明しています。サイトマップのlastmodは、再取得するURLを選ぶ手がかりで、内容が変わっていないURLを後回しにする目安にもなります。

この記事の後半で、lastmodの入れ方を詳しく説明します。

Googleの生成AI機能に、日付だけの専用ルールは見当たらない

Googleは、AI OverviewsやAI Modeに表示されるための追加の技術要件はないと案内しています。AI向けの専用ファイルや専用の構造化データも、要らないとあります。

この案内には、日付だけの専用ルールは見当たりませんでした。日付の基本は、通常の検索の案内に従うことになります。

AI検索が新しい情報を好むかどうかは、断定できない

各AI検索サービスが、日付や更新の新しさをどれだけ重く見るかについては、確かめられた公式の説明がありません。

2025年9月にarXivで公開された論文は、検索評価用のデータの文章に人工的な公開日を付け、7つの言語モデルに並べ替えさせました。調べた全モデルで新しい日付の文章が上位に寄り、モデルが大きいほど弱まるものの、なくならなかったと報告しています。

ただし、これは研究用のデータに日付を足した実験で、実際のAI検索サービスの動きを示すものではありません。詳しくは、先ほどの記事で扱っています。

更新日は、3か所でそろえて示す

日付を示す場所は、大きく3つあります。読む人が見るページ上の表示、検索エンジン向けの構造化データ、サイトマップのlastmodです。

場所	主な読み手	書く内容
ページ上の表示	読む人と検索エンジン	「公開日」「最終更新日」のように、ラベルを付けた日付
構造化データ	検索エンジン	datePublishedとdateModified
サイトマップのlastmod	検索エンジンのクローラー	ページを最後に実質的に変更した日時

3つの日付は、同じ出来事を指しているようにそろえます。1つだけ違う日付が混ざると、どれが正しいのか判断しにくくなります。

ページ上の表示

Googleは、検索結果に出る日付を「バイライン日付」と呼んでいます。Googleが推定した、ページの公開日または更新日のことです。

Googleは、この日付を1つの要素だけに頼りません。ページ上の日付、構造化データなど、複数の手がかりから推定すると説明しています。

ページ上では、利用者に見える日付を目立つ場所に置き、「公開」や「最終更新」のようなラベルを付けるよう案内されています。日本語のサイトなら、「公開日」「最終更新日」の表記が分かりやすい例です。

公開日と更新日の両方を見せても構いません。その場合は、読者に見分けがつくようにします。

他の日付を減らす

正しい日付が選ばれないときの対処も、案内されています。ページ上の他の日付を減らすことです。

たとえば、関連記事の一覧に日付が並んでいると、どれがこのページの日付か分かりにくくなります。公式の説明に沿って、本文まわりの日付の表示は、必要なものに絞っておきます。

構造化データのdatePublishedとdateModified

構造化データとは、ページの内容を検索エンジンが読み取りやすい形で書き添えるものです。Googleは、Articleなどの型にdatePublishedとdateModifiedを指定するよう勧めています。

日時はISO 8601の形式で書きます。タイムゾーンを書かないと、Googlebotが使うタイムゾーンとして扱われると、Articleの公式ページにあります。

項目	意味	書き方の例（架空）
datePublished	ページを最初に公開した日時	2025-04-10T09:00:00+09:00
dateModified	ページを最後に実質的に更新した日時	2026-10-01T14:30:00+09:00

日本時間なら、末尾に+09:00を付けます。

日付は必須で、時刻は任意

Googleの案内では、日付は必要で、時刻は必須ではありません。ただし、構造化データには時刻とタイムゾーンを書くと、精度が上がるとされています。

ページに見える日付と、構造化データの日付は、同じにします。見える側の日付に、時刻やタイムゾーンを書かなくても構いません。

未来の日付や、出来事の日付は使わない

日付には、そのページ自体を公開した日か、更新した日を使います。イベントの開催日や、将来の発売日は、ここには入れません。

予約投稿で公開を遅らせる場合も、公開された時点の日付になっているかを確かめます。イベントの情報は、別にEvent型の構造化データで伝えられると、公式ページにあります。

よくある食い違い

構造化データの書き方は、中小企業のWordPressサイトなら、テーマやプラグインが自動で出力していることが多いです。食い違いが起きやすい場面を、表にまとめます。

食い違いの例	起きること	対処（筆者の提案）
表示は公開日だけで、構造化データは保存のたびに更新される	表示とデータが食い違う	実質的な更新のときだけ更新日が変わる設定にする
サイト全体の更新日を、全記事に表示している	ページ自体の更新日ではない	ページごとの日付を表示する
記事で扱うイベントの日を、datePublishedに入れている	出来事の日付が、公開日として扱われる	公開日は、ページを公開した日にする
予約投稿の日付が、未来のまま残っている	未来の日付は使わない案内に反する	公開時点の日付になっているか確かめる

構造化データ全般の書き方と確認の手順は、別の記事にまとめています。

中小企業の構造化データ入門の記事

サイトマップのlastmodは、実際に変わった日時だけを入れる

lastmodとは

XMLサイトマップは、サイト内のURLの一覧を検索エンジンに伝えるファイルです。URLごとに付けるlastmodは、そのページを最後に変更した日時を表します。

Googleは、2023年6月のブログで、lastmodを、すでに知っているURLの再取得を計画する信号として使っていると説明しています。

Googleの説明

Googleのサイトマップのページと、2023年6月のブログの説明を、表にまとめます。

論点	Googleの説明
lastmodの使われ方	一貫して、検証できる形で正確なときに使われる
入れるべき日時	最後に「重要な」変更があった日時
重要な変更の例	本文、構造化データ、リンクの更新
重要でない変更の例	著作権表示の年の更新、サイドバーやフッターのささいな文言の変更
実態と合わない値	続くと、そのlastmodを信用されなくなる
付けるページ	全ページでも、確信のあるページだけでもよい
priorityとchangefreq	Googleは使わない

ブログには、7年前に変わったページのlastmodに「昨日変わった」と書き続けると、いずれ信じてもらえなくなる、という趣旨の例が載っています。

Bingの説明

Bingの公式ブログ（2025年7月31日）は、AIを使った検索の時代のサイトマップを説明しています。

• lastmodは、再取得するURLを選ぶ手がかりになり、変更のないURLを後回しにする目安にもなる
• 形式はISO 8601で、日付だけでなく時刻も含めるよう推奨している
• サイトマップを作った時刻を、そのままlastmodに入れないよう注意している
• changefreqとpriorityは、Bingも使わない
• 更新をすぐ知らせる仕組みとして、IndexNowとの併用を勧めている

分からないページは、省略してよい

lastmodは、確信のあるページだけに付けてよいとされています。2008年のGoogleの公式FAQにも、最終更新日が分からないURLについては、値を作るよりも省略したほうがよいとあります。

古い記事の最終更新日が分からないときに、サイトマップの生成日を全URLに入れるのは避けます。

lastmodの点検ポイント

• サイトマップの全URLで、lastmodが同じ日時になっていないか。生成した時刻が入っている可能性がある
• lastmodと、ページ上の最終更新日と、dateModifiedがそろっているか
• 軽い修正やコメントの投稿で、lastmodが変わる設定になっていないか
• 削除したページや、転送しているURLがサイトマップに残っていないか

「実質的な更新」の線引き

更新日を変えてよいのは、読む人が受け取る情報が、意味のある形で変わったときです。Googleがlastmodについて示している考え方が、参考になります。

本文、構造化データ、リンクの更新は重要な変更で、サイドバーやフッターのささいな変更、著作権表示の年の更新は重要な変更ではありません。この線引きを、ページの表示の日付にも当てはめます。

更新日を変えてよい変更の例

• 料金、プランの内容、仕様、手順など、事実が変わった部分の書き換え
• 法令やガイドラインの改正に合わせた修正
• 読者の疑問に答える新しい章や、具体例・手順の追加
• 内容に関わる誤りの訂正
• 終了したサービスや使えなくなった方法の削除と、代わりの方法の追記

更新日を変えなくてよい変更の例

• 誤字脱字や句読点の修正
• 内容が同じ画像の差し替えや、デザインとレイアウトの変更
• サイドバー、フッター、広告枠、関連記事リンクの入れ替え
• 言い回しを少し整えただけの修正

迷ったときの問い

これは筆者の提案です。「前の版を読んだ人が、この変更を知らないと困るか」と考えてみてください。

困るなら実質的な更新で、困らないなら更新日は変えません。この問いは、Googleの「実質的に変わっていないのに日付を変えていないか」という自己点検の問いとも、向きがそろっています。

再確認しただけのときは、更新日を変えない

情報を一次情報で見直して、変更がなかった場合の扱いは、判断が分かれます。筆者は、ページの更新日とlastmodはそのままにして、本文の「時点」の表記だけを更新する運用をすすめます。

内容が変わっていない以上、日付を新しくする理由が見つからないからです。再確認した記録は、次の節の「時点」と、更新履歴に残します。

変わりやすい情報には「2026年10月時点」と書く

時点は「確認した年月」を書く

料金や仕様のように変わりやすい情報には、本文中に「2026年10月時点」のように、時点を書くことをおすすめします。読む人が、情報の新しさを自分で判断できます。

AIが引用するときにも、時点が一緒に伝わりやすくなると、筆者は考えています。ただし、これは推測です。

書く年月は、その情報を一次情報で確認した月です。記事を公開した月とは限りません。

どの情報に付けるか

情報の種類	時点の表記	例（架空）
料金・プラン	付ける	2026年10月時点の公式サイトの情報です
ツールの画面・仕様	付ける	2026年10月時点の画面で説明しています
法令・制度	付ける（施行日も書く）	2026年10月時点の内容です
統計の数字	付ける（調査の時期も書く）	2025年の調査の結果です
考え方・手順の説明	付けない	付けなくてよい

章の冒頭か、表の注記にまとめる

時点は、1文ごとには付けません。読みにくくなるためです。

章の冒頭か、表の下の注記に、まとめて書きます。

「以下の料金は、2026年10月時点で、公式サイトで確認した内容です」のように、時点と確認の方法を一緒に書くと、読む人に伝わります。

出典の種類も添える

「公式サイトで確認」「公式ヘルプで確認」「担当者への問い合わせで確認」のように、何で確かめたかを一言添えます。同じ時点でも、確認の方法によって、情報の確かさが違うからです。

更新履歴の書き方

更新履歴を残す理由

更新の内容を記事の末尾か冒頭に残すと、読む人は、どこが変わったかを確認できます。運営する側も、経緯を追えます。

Googleが更新履歴の掲載を求めているわけではありません。実質的な更新を、読む人に正直に伝える方法として、筆者がすすめるものです。

書き方の例

次の表は、更新履歴の例です。日付と内容は架空です。

日付	内容
2026年10月1日	料金プランの改定に合わせて、「料金の目安」の表を更新。旧プランの記述を削除
2026年6月15日	設定画面の変更に合わせて、手順3から5の説明と画像を差し替え
2026年3月2日	料金を再確認（変更なし）
2025年4月10日	公開

書くときのルール

• 日付と、何を変えたかを1行で書く。「内容を更新しました」だけでは伝わらない
• 事実の訂正は、訂正と明記する。以前の記述が誤っていたときは、その旨を隠さずに書く
• 誤字の修正など、軽微な変更は載せなくてよい
• 最新の更新日を、ページ上部の「最終更新日」と、dateModifiedにそろえる

再確認だけで変更がなかった場合は、履歴に「再確認（変更なし）」と書いても、ページの更新日は変えません。

更新の優先順位の決め方

記事が数十本以上あると、一度に全部は見直せません。

ここからは筆者の提案です。4つの観点で点数を付け、合計の高い順に進めます。

4つの観点で点数を付ける

観点	確認すること	点数の目安
アクセス	直近の閲覧数、検索やAI検索からの流入	多い記事ほど高く
問い合わせへの影響	問い合わせや資料請求への導線か、営業の場で見せているか	直接つながる記事ほど高く
情報の古さ	最後に内容を確かめてからの経過期間	長いほど高く
変わりやすさ	料金、仕様、法令、画面、統計の数字を含むか	含むほど高く

点数は、各観点を3段階（高・中・低を3・2・1）にする程度で十分です。精密さよりも、毎月同じ基準で見直すことが大切です。

特に優先する、変わりやすい情報

• 料金とプラン：改定が多く、古いままだと信頼を損ねやすい
• ツールの仕様と画面：画面が変わると、手順の記事が実行できなくなる
• 法令と制度：改正や施行日によって、正しさが変わる
• 統計の数字：新しい調査が出ると、古い数字が誤解のもとになる
• 自社の情報：所在地、営業時間、窓口、提供するサービスの範囲

古い料金や終了したサービスの記述は、AIの回答にそのまま使われるおそれがあります。間違いが実害につながる情報は、アクセスが少なくても、優先度を上げます。

月に1回の見直しの回し方

作業	内容	目安
一覧づくり	記事ごとに「最後に確かめた日」と「次回の確認予定日」を表計算ソフトに書く	最初の1回だけ
点数付け	4つの観点で点数を付ける	月に1回
見直し	点数の高い記事を数本選び、一次情報で確かめて直す	月に数本
変更への対応	自社の料金改定など、変更が分かった時点で、関係する記事を洗い出す	随時

古い記事を削除するかどうかの判断は、別の記事で詳しく扱っています。

古い記事を削除するかリライトするかの記事

年号入りタイトルの注意

「【2026年版】○○の選び方」のように、タイトルに年号を入れる方法はよく使われます。この方法について、今回確かめたGoogleの公式ページには、専用の案内が見当たりませんでした。

以下は、筆者の実務上の考えです。

年号を入れるなら、その年の内容に更新する

タイトルだけを「2026年版」にして、中身が前の年のままなら、日付だけを新しく見せる行為と同じ問題を抱えます。Googleの自己点検の問いが指しているのは、こうした状態です。

年が変わったら、必ず見直す

「2025年版」のまま年を越すと、読む人には古い記事に見えます。年号を付けた記事は、毎年の見直しの一覧に入れておきます。

URLには年号を入れない

年ごとにURLを変えると、リンクの評価が分かれやすく、転送の手間も増えます。URLは年号なしにして、タイトルと本文だけを更新する形が扱いやすいです。

長く変わらないテーマには、年号を付けない

基本的な考え方を説明する記事に年号を付けると、毎年の更新の義務を、自分で増やすことになります。変わりやすい情報を扱う記事にだけ付けます。

古い記事を統合・削除するとき

見直しを進めると、直すよりも、まとめるか消したほうがよい記事が出てきます。

判断の目安

記事の状態	おすすめの対応
内容は今も役立つが、情報が古い	更新する（実質的な更新として、更新日を変える）
同じテーマの記事が複数あり、内容が重なっている	1本に統合し、ほかのURLは統合先へ301で転送する
サービス終了などで役目を終えたが、後継の情報がある	後継のページへ301で転送する
役目を終え、代わりになるページもない	削除して、404か410を返す
歴史的な記録として残す価値がある	残したうえで、冒頭に「○年○月時点の情報です」と書く

この表は、筆者の整理です。古い記事の数字による振り分けは、別の記事で詳しく扱っています。

301は「恒久的に移動した」ことを伝える

Googleのリダイレクトのページによると、恒久的なリダイレクトは、移動先を正規のURLとする信号として使われます。元に戻さないと決めたときに使います。

統合した記事は、統合先へ301で転送するのが基本です。転送の種類と注意点は、別の記事で詳しく扱っています。

リダイレクトとGoogle検索の記事

関係の薄いページへ、まとめて転送しない

サイト移転のページは、多数の古いURLを、関係のない1つのURL（新しいサイトのトップページなど）に転送しないよう案内しています。利用者を混乱させ、ソフト404として扱われることがあるからです。

一方、複数のページにあった内容を新しい1つのページにまとめた場合は、古いURLをそのまとめたページに転送してよいとされています。

削除したページが、200を返していないか確かめる

ソフト404とは、ページがないと表示しながら、正常を意味する200を返す状態です。クロールエラーの公式ページは、このような状態を、利用者にとってよくない体験として説明しています。

ページを削除し、代わりのページもないときは、404か410を返します。どちらも、ページが存在しない、検索に載せたくないという意味を、検索エンジンに伝えます。

統合の手順

1. 同じテーマの記事を洗い出し、アクセスと外部からのリンクが最も多い記事を、残す記事に決める
2. ほかの記事から、残す価値のある内容（独自の事例、図表、よくある質問）を移す
3. 情報を最新にして、更新履歴に「○○の記事を統合」と書く
4. 統合元のURLを、残す記事へ301で転送する
5. サイト内のリンクを新しいURLに張り替え、サイトマップから統合元のURLを外す

ニュース記事を扱うサイトには、注意があります。Googleの2019年のブログは、少しだけ更新した記事を新規に作り、古い記事を削除して転送する方法を、記事URLのガイドラインに反するものとして挙げています。

内容を足さずに、URLだけを新しくする統合は避けます。

鮮度対策のチェックリスト

日付の示し方

• [ ] 公開日と更新日が、ページ上にラベルつきで表示されている
• [ ] 構造化データのdatePublishedとdateModifiedが、ページ上の表示と一致している
• [ ] 日時はISO 8601の形式で、日本時間なら+09:00が付いている
• [ ] 未来の日付や、記事で扱うイベントの日付を入れていない
• [ ] 誤字の修正などの軽微な変更で、更新日とlastmodが自動で変わらない
• [ ] サイトマップのlastmodが、全URLで同じ日時になっていない

本文と運用

• [ ] 料金・仕様・法令・数字に、「○年○月時点」が付いている
• [ ] 記事ごとに、最後に内容を確かめた日を管理している
• [ ] 更新履歴に、日付と変更の内容が具体的に書かれている
• [ ] 年号入りタイトルの記事が、その年の内容に更新されている

統合と削除

• [ ] 統合した記事は、統合先へ301で転送している
• [ ] 削除した記事は、404か410を返している
• [ ] 関係のないページへ、まとめて転送していない
• [ ] 統合や削除したURLが、サイトマップに残っていない

よくある質問

Q1. 更新日を新しくすれば、検索順位やAIの引用は上がりますか。

日付を新しくするだけで上がるとは言えません。Googleは、内容が実質的に変わっていないのに日付を変えていないかを、自己点検の問いに挙げています。

新しく見せるために大量の内容を足したり削ったりしても、順位の助けにはならないとも、公式ページに書かれています。

Q2. 公開日と更新日は、どちらを表示すればよいですか。

両方を表示して構いません。両方を見せる場合は、読む人が見分けられるように、ラベルを付けます。

一度も更新していない記事は、公開日だけで足ります。

Q3. 構造化データを入れていないと、日付は伝わりませんか。

Googleは、日付を1つの要素に頼らず、複数の手がかりから推定すると説明しています。構造化データがなくても、ページ上に見える日付があれば、手がかりになります。

確実に伝えたいなら、ページ上の表示と構造化データの両方をそろえます。まずは、ページ上にラベル付きの日付を出すことから始めてください。

Q4. 最終更新日が分からない古い記事は、どうすればよいですか。

サイトマップのlastmodは、確信のあるページだけに付ければよく、分からないページは省略して構いません。2008年のGoogleの公式FAQも、不確かな値を作るよりも省略するほうがよいとしています。

今日の日付を一律に入れるのは避けます。

Q5. AI検索向けの、特別な日付の書き方はありますか。

確かめられた公式の説明は、見当たりませんでした。GoogleのAI機能の案内は、追加の要件はないとしています。

Bingは、サイトマップのlastmodをISO 8601の形式で、時刻まで入れるよう推奨しています。日付を正確に、人にも機械にも読める形で示すことが基本です。

Q6. 記事を直したら、AIの回答にすぐ反映されますか。

すぐに反映されるとは言えません。GoogleのAI機能の案内には、取得し直されるまでに数日から数か月かかることがあると書かれています。

Bingも、情報がいつどのように生成AIの結果に出るかは、どの仕組みでも保証できないと述べています。更新したページを、検索エンジンに知らせる手段は、サイトマップとIndexNowなどがあります。

Q7. 内容を見直して、変更がなかったときは、更新日を変えますか。

筆者は、ページの更新日とlastmodは変えず、本文の「時点」と更新履歴だけを新しくする運用をすすめます。内容が変わっていないのに日付を新しくすると、Googleの自己点検の問いに当たるおそれがあるからです。

この扱いは、公式に明記された内容ではありません。筆者の考えです。

Q8. 古い記事は、冒頭に注記を付けるだけで足りますか。

過去のお知らせのように、歴史的な記録として残す記事なら、「○年○月時点の情報です」という注記で足ります。

料金や手順のように、今の判断に使われる情報は、注記だけでは足りません。更新するか、役目を終えたものとして統合や削除を検討します。

まとめ

情報の鮮度で大切なのは、日付を新しく見せることよりも、内容を今の事実に合わせて、その事実を正直に示すことです。

次の点を意識して、自社サイトを点検してください。

• 公開日と更新日は、ページ上にラベル付きで表示し、構造化データと一致させる
• 更新日を変えるのは、実質的に内容が変わったときだけにする。サイトマップのlastmodも同じ
• 料金や仕様には、確認した年月を「○年○月時点」と書く
• 更新の内容は、日付と一緒に、更新履歴へ具体的に残す
• 4つの観点で優先順位を付け、毎月少しずつ見直す
• 役目を終えた記事は、統合・301・404か410を使い分ける

AI検索が新しい情報をどの程度重く見るかは、まだ公式に詳しく説明されていません。それでも、正確な情報を正直な日付とともに示すことは、読む人にとってもAIにとっても使いやすい情報源の条件だと考えます。

まずは、料金や仕様を載せている記事を一覧にして、「最後に確かめた日」を書き込むところから始めてみてください。

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。