"2026年8月版"にしただけで更新日まで8月になる設計をやめた話

情報サイトでは、

「いつの情報なのか」

がかなり重要です。

うにラボで運営している「ABCクッキング攻略ノート」でも、

• 2026年8月版
• 今月のキャンペーン
• 最終更新日
• 公開日

など、日付をいろいろな場所で扱っています。

ところがサイトを見直していると、

ページの内容を変更した日と、表示されている更新日が必ずしも一致していない

ことに気づきました。

原因は、複数の意味を持つ日付を使い回していたことです。

そこで、

「情報の対象期間」と「ページを更新した日」を完全に分ける

ようにしました。

「8月の情報」と「8月に更新した」は別

たとえば、

2026年8月キャンペーン

というページがあるとします。

キャンペーン期間が、

2026/08/01〜2026/08/31

なら、8月1日という日付を持っています。

でもこれは、

キャンペーンが始まる日

です。

そのページを作った日でも、

内容を修正した日でもありません。

仮に7月28日にページを作っていたとしても、

キャンペーン開始日は8月1日です。

逆に8月15日に条件を修正したとしても、

キャンペーン開始日は8月1日のままです。

この2つを同じ日付として扱うのはおかしいと気づきました。

sitemapのlastmodにも開催日を使っていた

問題は画面に表示する日付だけではありませんでした。

sitemapには、

lastmod

という、そのURLが最後に更新された日時を伝える項目があります。

以前の実装では、キャンペーンページについて、

キャンペーン期間の開始日

を lastmod として使っていました。

つまり、

「8月1日開始のキャンペーンだから、このページの更新日も8月1日」

という扱いです。

でも実際には、

7月中に作っているかもしれないし、

8月途中で内容を修正しているかもしれません。

意味の違う日付を代用していました。

固定ページにも共通の日付を使っていた

同じような問題は固定ページにもありました。

料金情報を8月版に更新したとき、

サイト全体の「現在版」の日付を使って、

複数ページをまとめて更新扱いにしていました。

でも、

料金データを更新したからといって、

• 会社説明ページ
• FAQ
• ライセンス解説
• その他の固定ページ

まで全部その日に変更したとは限りません。

それなのに共通の日付を参照すると、

触っていないページまで「最近更新されたページ」に見えてしまう

可能性があります。

更新日はページ自身に持たせることにした

そこで、固定ページについては、

site_config.json

にページごとの更新情報を持たせるようにしました。

ページごとに、

• publishedAt
• updatedAt
• updateSummary

を管理します。

たとえば料金ページを8月8日に直したなら、

料金ページだけ8月8日。

FAQを8月6日に直したなら、

FAQは8月6日。

という形です。

「今は2026年8月版だから全部8月更新」

とはしません。

キャンペーンにも公開日と更新日を追加した

キャンペーンデータにも、

• publishedAt
• updatedAt
• updateSummary

を追加しました。

そして、

キャンペーンの開催期間から公開日・更新日を推測しない

ようにしました。

さらに、これらの日付が入っていなければ、

ビルドを失敗させる

ようにしています。

少し厳しい作りですが、

日付を入れ忘れたときに適当な値で公開されるより、

ビルド時に気づける方が安全です。

ブログも「更新日」を1か所から取るようにした

ブログ記事にも似た問題がありました。

記事には、

• 一覧に表示する更新日
• 記事上部に表示する更新日
• Open Graphの更新日
• Article構造化データの dateModified
• sitemapの lastmod

があります。

ここで、それぞれ別の処理を書くと、

画面では8月8日なのに、構造化データでは8月6日

のようなズレが起こり得ます。

そこで、

postUpdatedAt()

という共通処理を作り、

ブログ記事の更新日はすべてそこから取るようにしました。

現在は、

• 記事ページの「更新日」
• metadata
• Articleの dateModified
• sitemapの lastmod

が同じ値を参照します。

「SEOのために更新日を新しくする」はしない

SEOについて調べていると、

「更新日を新しくすると有利」

という話を目にすることがあります。

その結果、

本文をほとんど変えていないのに、

日付だけ新しくする運用も考えられます。

でも、今回のサイトでは逆の方向にしました。

内容を変えたページだけ更新日を変える。

変えていないなら、そのままです。

これは検索エンジン対策以前に、

読者に対してその方が自然だからです。

「2026年8月8日更新」と書いてあるなら、

8月8日に何かを直したページであってほしいと思います。

「情報確認日」と「ページ更新日」も分けた

もうひとつ分けたのが、

情報を確認した日

と、

ページを更新した日

です。

料金データについて、

「2026年8月時点の料金を確認した」

という日付があります。

これは料金情報の鮮度を示すには便利です。

でも、その日付を別のページの lastmod に使うのは違います。

そのため、

料金の版や確認日は、

「この料金情報はいつのものか」

を示すためだけに使います。

ページの更新日はページ自身が持ちます。

この2つを分けました。

日付は1種類だと思うと事故る

今回整理してみると、サイトには思った以上に多くの日付がありました。

• 公開日
• 最終更新日
• キャンペーン開始日
• キャンペーン終了日
• 情報確認日
• 料金版の日付

全部「日付」ですが、意味は違います。

これらを、

「とりあえず一番新しい日付」

で代用すると、どこかで意味が崩れます。

更新履歴も正確になった

この変更によって、

TOPの「最新更新情報」も扱いやすくなりました。

以前は共通日付を使っていたため、

実際には変更していない固定ページまで、

新しく更新されたように並ぶ可能性がありました。

現在は各コンテンツ自身の updatedAt を使います。

そのため、

実際に最近変更したコンテンツが上に来る

ようになります。

さらに、

updateSummary

として、

「何を変更したのか」

も持てます。

単に、

「8月8日 更新」

だけではなく、

「支払い方法をスタジオ確認結果に更新」

のような履歴を残せます。

sitemapも「実際に変わった日」を出す

sitemap側でも同じです。

固定ページなら、そのページの updatedAt。

キャンペーンなら、そのキャンペーンページの updatedAt。

ブログなら postUpdatedAt()。

という形に統一しました。

これで、

「キャンペーン開始日をlastmodとして送る」

「料金版を変えたら全固定ページが更新扱いになる」

という状態をやめています。

見た目では分かりにくいけれど、サイトの信頼性に関わる

この修正をしても、デザインはほとんど変わりません。

新しい便利機能が増えるわけでもありません。

でも、

• ユーザーに見せる更新日
• 構造化データ
• sitemap
• 更新履歴

が同じ事実を表すようになります。

情報サイトを運営するなら、

こういう「地味だけど嘘にならない設計」も大事

だと思っています。

ABCクッキング攻略ノートでは、毎月情報が変わります。

だからこそ、

「最新版」

と書くだけではなく、

「何をいつ確認し、どのページをいつ変更したのか」

を区別できるようにしました。

情報の鮮度をアピールするための日付ではなく、

実際の運用履歴としての日付にする。

今回の改善では、そこをかなり意識しました。