検索結果の日付が古いまま？公式の3条件で直す

記事を全面的に書き直した。なのに検索結果に出ている日付は、2年前のまま。——この状態を直そうとして、多くの人はまず記事の日付表示を書き換えます。それでも変わらないことがあります。

先に結論を書きます。Google のドキュメントが日付について求めているのは、ユーザーに見える日付と構造化データの日付が一致していること、正確であること、そして未来の日付でないことの3つです。そのうえで「それ以外の日付は最小限に」と続きます。つまり作業の本体は、日付を新しく書き換えることではありません。ページの中に散らばっている日付を数えて、減らすことです。

順番に見ていく前に、ひとつ前提を置いておきます。日付は必ず出るものではありません。

そもそも日付は「いつも出る」ものではない

Google 検索セントラル ブログの「Help Google Search know the best date for your web page」（2019年3月）は、こう始まります。

Sometimes, Google shows dates next to listings in its search results.

「ときどき（Sometimes）」です。検索結果の各項目のとなりに日付が出ることがある、という書き方になっています。すべてのページにいつも出るとは書かれていません。

だから、日付が出ていないこと自体を不具合と決めつけないほうが安全です。直す対象は「出ている日付が、こちらの意図と違う」ケースに絞れます。古い日付が出ている、更新したのに変わらない、そもそも身に覚えのない日付が出ている。この3つです。

同じ記事には、日付の判断について次の一節があります。

multiple factors, including visible dates and structured data

複数の要素（multiple factors）で決まる、そこには見える日付と構造化データが含まれる——という書き方です。「見える日付と構造化データだけで決まる」とは書かれていない点に注意してください。ここは押さえておく価値があります。手を入れられるのは、公式が名前を挙げているこの2つが中心になる、という意味だからです。

公式が挙げる3条件と「それ以外は最小限に」

日付の扱いをいちばん具体的に書いているのは、検索セントラルの「検索結果に最適な日付を指定する」です。該当箇所はこうなっています。

add a prominent, user-visible date labeled as "Published" or "Last updated." Also, use structured data (e.g., Article, BlogPosting) to specify datePublished and/or dateModified. Dates and times should be consistent between user-visible and structured data, accurate, and not in the future. Minimize other dates

分解すると、要求は4つです。

1. 目立つ形で、ユーザーに見える日付を置く。しかも「Published（公開日）」「Last updated（最終更新日）」といったラベルを付ける
2. 構造化データを使う。Article や BlogPosting といった型で、datePublished（公開日時）や dateModified（更新日時）を指定する
3. 見える日付と構造化データの日付・時刻を、一致・正確・未来でない状態にする
4. それ以外の日付は最小限にする

3つめが本丸です。「一致（consistent）」「正確（accurate）」「未来でない（not in the future）」。この3語がそのまま点検項目になります。

そして4つめ。ここが見落とされがちなところです。ページに置いてよい日付の数には、公式が明確に「最小限に」と言っている。記事本文の日付だけを直しても検索結果が変わらないとき、疑うべきはこちらです。

日付が置かれやすい場所を挙げてみます。記事の冒頭。記事の末尾の「この記事の更新履歴」。サイドバーの「最近の記事」一覧。関連記事カードの日付。コメント欄の投稿日時。フッターの著作権表記の年。パンくずの下に出る小さな更新日。——1ページに7カ所。珍しくない数です。

これらを全部消せ、という話ではありません。「最小限に」の一語しか根拠はないので、判断の線引きは自分で引く必要があります。次の手順は、そのための棚卸しです。

ページ内の日付を棚卸しする6ステップ

対象は、検索結果の日付が意図と違っている記事1本です。

1. その記事をブラウザで開き、目に見える日付をすべて書き出す。本文だけでなく、サイドバー・関連記事・コメント・フッターまで含めます。数を数えるのが目的なので、まずは場所と日付の文字列だけ控えれば十分です
2. ページのソースを表示し、構造化データの datePublished と dateModified の値を取り出す。application/ld+json のブロックを探すのが早道です。値が2つとも入っているか、片方だけかも記録します
3. 1と2を突き合わせて「一致」を見る。見える日付が「2024年1月5日」で、datePublished が 2024-01-05T08:00:00+08:00 なら日付は合っています。ずれていたらここで止めて、どちらが本当かを決めます
4. 「正確」を見る。実際に本文を書き直したのはいつか。更新履歴やコミットログと照らして、dateModified が実態と合っているかを確認します
5. 「未来でない」を見る。予約投稿や下書きの日付がそのまま出ていないか。タイムゾーンの指定漏れでも起きうるので、次の節で扱います
6. 1で書き出した日付のうち、記事そのものの日付ではないものに印を付ける。関連記事カードの日付、コメントの日時、サイドバーの一覧。これが「最小限に」の対象候補です

3つめのステップで止まる人がいちばん多いはずです。CMS のテンプレートは、見える日付を「投稿日」から、構造化データを「更新日」から出していることがあります。どちらも間違いではないのに、並べると食い違って見える。この場合は出力元をそろえるところからになります。

タイムゾーンを書かないと何が起きるか

5つめのステップに関わる話です。「記事（Article）の構造化データ」には、dateModified の説明としてこう書かれています。

The date and time the article was most recently modified, in ISO 8601 format. We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot.

ISO 8601 形式（YYYY-MM-DDThh:mm:ss+09:00 のように日時と時差をまとめて書く国際的な表記）で書くこと。そしてタイムゾーン情報を入れることを推奨する。入っていなければ、Googlebot が使うタイムゾーンが既定になる——と書かれています。

同じドキュメントに載っている例は、こうなっています。

"datePublished": "2024-01-05T08:00:00+08:00", "dateModified": "2024-02-05T09:20:00+08:00"

末尾の +08:00 が時差の指定です。日本時間で運用するなら +09:00 を書く形になります。

ここで注意したいのは、「時差を書かないと日付が1日ずれる」と公式が書いているわけではない点です。書かれているのは「推奨する」「なければ Googlebot のタイムゾーンが既定になる」まで。ただ、深夜0時をまたぐ時刻を扱うなら、既定のタイムゾーン次第で日付の表記が変わることはありえます。夜間に自動更新をかけている場合は、書いておくほうが読みが安定するはずです。

なお、dateModified は「その記事が最後に変更された日時」です。ニュースのヘルプにも同じ説明があり、「より正確な日付情報を Google に提供するために、このプロパティを追加してください」と続きます。ここで読み取れるのは、プロパティの追加を促すところまでです。どの程度の変更で書き換えるかの線引きは、この一節からは決まりません。自分のサイトの方針として決めることになります。

どの日付を残し、どれを減らすか——判定表

6つめのステップで印を付けた日付を、ここに当てはめます。

いちばん上の行は、さきほどの3ステップめで食い違いが見つかったケースがまさにこれです。公式が求めているのは、ラベルの付いた日付でした。日付の文字列だけを置くと、それが公開日なのか更新日なのかは読み手の推測にゆだねられます。逆に下から2行めの更新履歴は、判断が割れるところです。読者にとっては親切な情報なので、「最小限に」を理由に一律で消す必要はありません。

3行めと4行めが、冒頭で触れた「記事の日付だけ直しても変わらない」ケースの主犯候補になります。とくに関連記事カードは、テンプレートの共通部品として全記事に入っていることが多い。1カ所直せば全ページに効く、という意味でもあります。

ワークスルー：更新したのに日付が2年前のまま

オウンドメディアの記事1本で、実際に通してみます。仮に、2024年1月公開・2026年7月に全面改稿した「料金比較」の記事だとします。

ステップ1。見える日付を書き出すと、冒頭に「2024.01.05」、サイドバーの新着一覧に5件分の日付、記事下の関連記事カードに3件分の日付、コメント欄に4件。合計13カ所ありました。冒頭の1カ所以外は、すべて他の記事かコメントの日付です。

ステップ2。構造化データを見ると、datePublished は入っているが dateModified がない。改稿しても、構造化データ側には更新日が存在しない状態でした。

ステップ3と4。見える日付「2024.01.05」は datePublished と一致しています。一致はしている。しかし7月の改稿はどこにも反映されていません。ここで**「一致」と「正確」は別の条件だ**とわかります。両方そろっていないと、条件を満たしたことにはなりません。

ステップ5。未来の日付はなし。ここは問題ありませんでした。

ステップ6。減らす候補は12カ所。うち関連記事カードとサイドバーは共通テンプレート由来です。

打ち手は3つになります。冒頭に「最終更新日：2026年7月18日」をラベル付きで追加する。dateModified に 2026-07-18T10:00:00+09:00 を追加する。関連記事カードとサイドバーの日付表示を、件数を絞るか非表示にするか決める。——最初の2つは公式が名前を挙げている箇所への対応で、3つめが「最小限に」への対応です。

なお、直したあとに検索結果へいつ反映されるかは、ここで使った出典からは見積もれません。期日を約束する形で社内に共有しないほうが安全です。サイトマップの日付側の扱いはサイトマップのlastmodはいつ更新する？公式の3条件と書き方で扱っています。

ニュース面に出しているサイトは条件が1段きびしい

ここまでは通常の検索結果の話です。Google ニュースに記事を出している場合、要求が具体的になります。前掲の2019年のブログ記事には、こう書かれています。

For Google News, both visible date/time and structured data are required, positioned between the headline and content.

Google ニュースでは、見える日付・時刻と構造化データの両方が必須で、しかも見出しと本文の間に配置する——と読めます。通常の検索結果では「目立つ形で見える日付を置く」までだったものが、ニュースでは配置場所まで指定されている形です。

ニュースのヘルプには、もうひとつ実務的な記述があります。

slightly updated story from a previously published one, then delete the old story and redirect to the new one.

すでに公開した記事を少し更新したものを別記事として出す場合は、古いほうを削除して新しいほうへリダイレクトする、という趣旨です。同じ内容の記事を日付違いで並べない、という運用になります。ニュース面を使っていないサイトでも、考え方は流用できるはずです。

同じヘルプは、構造化データで「正しいタイムゾーンとともに datePublished または dateModified を使う」ことと、ニュース用サイトマップを作っている場合は公開日を含むエントリを使うことにも触れています。タイムゾーンの話が、ここでもまた出てきます。

公開前・改稿後のチェックリスト

記事を出すとき、あるいは改稿したときに通す項目です。

• 冒頭に、ラベル付きの日付がある（「公開日」「最終更新日」など、何の日付かがわかる）
• 構造化データに datePublished がある
• 改稿したなら dateModified もある
• 見える日付と構造化データの日付が一致している
• その日付が、実際に書いた日・直した日と合っている
• 未来の日付になっていない（予約投稿の設定値が残っていないか）
• 日時に時差の指定がある（+09:00 など）
• このページに出ている「記事本体以外の日付」の数を数えた
• 数えた結果、減らせるものを減らした（または減らさない理由を決めた）

最後の2行は、他の項目と性格が違います。合格・不合格を機械的に決められないからです。それでも数えるところまではやる価値があります。7カ所あると知って残すのと、知らずに放置するのは別のことなので。

検索結果に出る文言そのものが意図と違う場合は、日付ではなく説明文側の問題かもしれません。そちらはメタディスクリプションが反映されない理由と、抽出元を特定する手順にまとめています。