ブログのリライトで公開日を書き換えない運用ルール

記事をリライトしたとき、frontmatterのdateもつい最新の日付に書き換えていないでしょうか。

筆者もtoolarc.jpの運用初期は、リライトのたびに公開日を最新化していました。しかし、これを続けていると「公開日」がいつの間にか「最終編集日」と同じ意味になってしまい、読者にも自分自身にも記事の本当の情報鮮度が伝わりにくくなります。

この記事では、Next.js＋Markdownブログを例に、新規公開とリライトを区別したうえで公開日をどう扱うかの運用ルールを整理します。社内メモというより、同じ構成でブログを運用している人向けの実務Tipsとして書いています。

今日の結論

• リライトでは date（公開日）を書き換えない
• 実装した日付は last_update（最終更新日）と免責文の「執筆時点」だけに反映する
• 新規公開のときだけ、公開日と公開日時管理用のフィールド（例: サイト側のpublishedAt）を実装日で揃える

---

なぜ公開日を書き換えない方がいいのか

公開日は「この記事がいつ世に出たか」を示す情報です。ここをリライトのたびに更新してしまうと、次のような問題が起きます。

• 読者が「新しい記事だ」と誤解し、実際にはどの部分が更新されたのか分かりにくくなる
• 自分自身も「この記事は本当はいつ書いたものか」を後から追いにくくなる
• 検索エンジンに対しても、公開日と最終更新日が本来持つ意味が曖昧になる

検索エンジンの評価に対する具体的な影響は、執筆時点で公式に断定できるものではありません。ただし、公開日と更新日を実態どおりに分けておくことは、読者への誠実さという観点だけでも運用ルールにしておく価値があります。

手順1｜作業がリライトか新規公開かを先に判定する

まず、これから行う作業が「既存記事のリライト（統合・改稿を含む）」なのか「新規記事の公開」なのかを最初に判定します。

ここを曖昧にしたまま作業を始めると、あとから公開日を書き換えるべきか迷う原因になります。判定は着手前の1ステップとして、必ず先に済ませます。

手順2｜リライトの場合は公開日を据え置く

リライトと判定した場合は、Markdown側のdateと、サイト側で公開日を保持しているフィールド（例: publishedAt）を変更しません。

実装した日付を反映するのは、次の2箇所だけです。

• frontmatterのlast_update（最終更新日）
• 記事末の免責文にある「執筆時点」の記述

こうしておくことで、「いつ生まれた記事か」と「いつ手を入れたか」が明確に分かれます。

手順3｜新規公開の場合は公開日と実装日を揃える

新規公開と判定した場合は、これまでどおり実装日の日付をdateとpublishedAtの両方に設定します。

新規公開時に日付を仮置きしていた場合も、実装のタイミングで実際の日付に統一します。ここは従来の運用と変わりません。

---

確認チェックリスト

• □ 作業前に「リライトか新規公開か」を判定した
• □ リライトの場合、date／publishedAtを書き換えていない
• □ リライトの場合、last_updateと免責文の「執筆時点」だけを実装日にした
• □ 新規公開の場合、dateとpublishedAtを実装日で揃えた

まとめ・次に読む

公開日と最終更新日を分けて運用するのは、地味ですが記事の信頼性を保つうえで効果のあるルールです。特に記事数が増えてリライトの機会が多くなるほど、この区別があるかどうかで運用の分かりやすさが変わってきます。

Next.js・Markdownでのサイト構築や公開の全体的な流れは、シリーズのHub記事 AI初心者がゼロからWebサイトを公開するまでにやったこと・詰まったこと全部まとめ にまとめています。

---

※ 本記事は執筆時点（2026-07-18）のtoolarc.jpでの運用ルールに基づいています。検索エンジンの評価基準は公式に全てが開示されているわけではないため、断定的な効果を保証するものではありません。