記事の更新日はいつ変える？AI検索に備える公開日と変更内容の管理方法

更新日だけを動かす前に確認すること

記事の更新日は、単なる飾りではなく、読者が「この情報を現在の判断材料にしてよいか」を考える手がかりです。本文がほぼ同じまま日付だけが新しくなると、読者は変更内容を確認できず、価格、受付条件、提供範囲などが本当に現行なのか判断しにくくなります。

Googleの人を第一に考えたコンテンツの公式ガイドでは、内容が実質的に変わっていないのに新しく見せるためページの日付を変えていないか、自己点検するよう案内しています。これは「日付を変えれば必ず不利益がある」という説明ではありません。検索エンジン向けの見せ方を先行させず、読者にとっての実質的な改善を優先するための確認項目です。

また、GoogleのAI機能とウェブサイトに関する公式ガイドでは、AI OverviewsやAI Modeのためだけの追加要件や特別な構造化データは不要で、従来のSEOの基本が引き続き有効とされています。要件や推奨事項を満たしても、クロール、インデックス、表示は保証されません。

これらを踏まえ、本記事では「更新日を変えるか」ではなく、まず「読者の理解や判断に影響する何が変わったか」を決める順番を推奨します。更新日や技術設定は、その変更内容を正しく伝えるためにそろえます。

「実質的な更新」を作業単位で決める

どこからを実質的な更新と呼ぶかについて、すべてのサイトに共通する文字数や割合の基準はありません。実務上は、修正量ではなく、修正によって読者の理解、比較、申込みなどの判断が変わるかで整理すると扱いやすくなります。

更新日を変える候補になる変更

• 料金、提供内容、対応地域、営業時間、申込条件など、意思決定に関わる事実を修正した
• 制度やサービス仕様の変更を一次情報で確認し、説明や結論を見直した
• 古い案内を削除し、現在の手順や選択肢を追加した
• 誤解を招く表現を訂正し、根拠となる公式リンクを追加または差し替えた
• 記事の対象読者や検索意図に合わせ、複数の節を再構成した

日付変更を急がず、内部記録でも管理できる変更

• 意味を変えない誤字、句読点、空白だけを修正した
• 見た目を保ったまま装飾や余白だけを調整した
• フッターの著作権年だけを変更した
• 読者が見る情報に影響しない管理上の編集を行った

上の分け方はGoogleが定める一律の規則ではなく、AI BRAND CHECK運営者による実務上の提案です。境界が曖昧な場合は、公開日を上書きするのではなく、初回公開日を残したまま更新日を追加し、変更内容を一行で記録する方法があります。

社内の更新記録には、更新日、担当者、変更したページ、変更内容、確認した出典、構造化データとサイトマップの確認結果を残しておくと、後から「日付だけが変わったのか」を判別しやすくなります。これは運営者による管理方法の提案であり、検索表示の効果を保証するものではありません。

公開日と更新日を読者に分かる形で示す

Googleの検索結果に表示される日付に関する公式資料では、Googleはページの公開日または大幅な更新日を複数の要素から推定すると説明しています。そのうえで、ページ上の目立つ場所に、公開日や最終更新日と分かるラベル付きの日付を表示する方法が案内されています。

同資料では、ページ上で読者に見える日付と、構造化データの日付・時刻を一致させることも案内しています。将来の日付や、記事内で扱うイベントの開催日を、記事自体の公開日・更新日として指定しないことも注意点です。ガイドに沿っても、検索結果に日付が表示される保証はありません。

これらを踏まえ、実務上は次のように役割を分けることを推奨します。

• 初回公開日：そのページを最初に公開した日として保持する
• 最終更新日：読者の判断に関わる内容を最後に見直した日として表示する
• 情報の基準日：料金表や対応状況など、個別情報が「いつ時点」かを本文の近くで示す
• 開催日・終了日：セミナーやキャンペーンなどの対象日として、記事の更新日とは分けて示す

WordPressでは、テーマやSEOプラグインが投稿日や更新日を自動出力する場合があります。小さな修正でも最終更新日が自動で変わる構成なら、自社の編集方針と合うかを公開前に確認してください。本文中に日付が多く、検索結果で意図しない日付が選ばれる場合は、Googleの案内どおり、役割の曖昧な日付を減らせるかも点検します。

Article構造化データの日付を本文と合わせる

GoogleのArticle構造化データの公式資料では、記事の初回公開日時を示すdatePublishedと、直近の変更日時を示すdateModifiedが推奨プロパティとして案内されています。値はISO 8601形式を使い、より正確な日時情報のためタイムゾーンを含めることが推奨されています。

GoogleのAI機能向けに特別なスキーマを追加する必要はありません。むしろ公式ガイドでは、構造化データをページ上で見える内容と一致させることがSEOの基本として挙げられています。たとえば、画面上の最終更新日が9月15日なのに、構造化データのdateModifiedが別の日付になっていれば、情報源同士が食い違います。

実務上は、テーマやSEOプラグインがArticle系の構造化データをすでに出力しているかを最初に確認すると整理しやすくなります。自動出力がある状態で別の仕組みを追加すると、同じページに複数の記述が生じることがあるためです。手動で追加する前に、公開ページのソースとリッチリザルトテストで、種類、日付、見出し、著者、画像が実際の内容と一致するかを確認してください。

サイトマップのlastmodを正確に保つ

Googleのサイトマップ作成に関する公式資料では、XMLサイトマップのlastmodは、そのページに最後の重要な更新を行った日時を反映させるよう案内しています。本文、構造化データ、ページ上のリンクの変更は一般に重要な更新に当たり、著作権年だけの変更は該当しない例として示されています。

Googleは、lastmodが継続的かつ検証可能な形で正確な場合に使用すると説明しています。一方、priorityとchangefreqの値は無視されます。また、サイトマップの送信はヒントであり、ダウンロードやクロールへの利用を保証するものではありません。

これらを踏まえ、本記事では、サイト全体の再生成や軽微な編集のたびに全URLのlastmodを同じ日にする運用を避けることを推奨します。CMSが自動生成する場合でも、代表的な記事URLをサイトマップ内で検索し、画面上の最終更新日や構造化データと合っているかを確認します。キャッシュを利用しているサイトでは、更新後に古いサイトマップが残っていないかも点検対象です。

小規模事業者向けの記事更新手順

限られた人数ですべての記事を同じ頻度で見直すのは現実的ではありません。以下は、公式資料を踏まえてAI BRAND CHECK運営者が整理した実務手順です。

1. 変化しやすい記事を先に選ぶ：料金、営業時間、提供地域、申込条件、製品仕様など、古い情報が読者の行動に影響しやすいページから確認します。
2. 一次情報を確定する：自社の現行資料や提供元の公式ページを確認し、何年何月何日時点の情報かを記録します。
3. 変更前後を残す：変更した見出し、削除した説明、追加した根拠を短く記録し、日付変更の理由を説明できる状態にします。
4. 本文を実質的に直す：古い断定、リンク切れ、終了した案内、現在のCTAと合わない説明を点検し、読者の判断に必要な内容を更新します。
5. 日付情報をそろえる：表示される最終更新日、Article構造化データのdateModified、サイトマップのlastmodを確認します。
6. 下書きで確認する：PC・スマートフォンの表示、見出し、リンク、画像、表現、出典を確認し、運営者が手動で公開します。
7. 公開後の出力を確認する：公開ページのソース、リッチリザルトテスト、サイトマップ、必要に応じてSearch ConsoleのURL検査で、意図した状態になっているかを確認します。

定期点検に加え、料金改定、利用規約や仕様の変更、問い合わせで誤解が判明したとき、公式リンクが切れたときなどを更新のきっかけにすると、カレンダーだけに頼らず管理できます。どのきっかけを優先するかは、ページの役割と自社の運用体制に合わせて決めてください。

公開前後の確認リスト

内容と出典

• 変更した事実を、現時点の公式資料または自社の確定情報で確認したか
• 古い料金、条件、日付、リンク、画像が残っていないか
• 更新日を変える理由を、更新記録から説明できるか
• 効果、実績、比較、推薦などの表現に確認できる根拠があるか
• 画像・文章・レビューなど、第三者コンテンツの掲載権限を確認したか

日付と技術出力

• 初回公開日と最終更新日の役割が読者に分かるか
• 画面上の日付とdatePublished・dateModifiedが一致しているか
• 記事URLのlastmodが実際の重要な更新日を反映しているか
• canonical URL、インデックス可否、内部リンクが意図どおりか
• 公開後のページとサイトマップが、古いキャッシュのままになっていないか

記事を更新しても、AI検索の回答が直ちに変わる、引用される、順位が上がるといった結果は保証できません。更新作業の目的は、まず読者に現在の正確な情報を届け、ページ内外の日付情報を矛盾させないことです。