記事の更新日を表示する―updatedAtとサイト運用情報を整える

ブログの記事は、公開したあとも修正します。

ところが公開日しか表示していないと、

「この記事はいつ書かれたのか」は分かっても、
「最後にいつ内容を見直したのか」が分かりません。

ゆまラボでも記事を修正する機会が増えたため、Frontmatterへ更新日を持たせ、記事ページに公開日と更新日の両方を表示するようにしました。

同じタイミングで、お問い合わせ先を独自ドメインメールへ変更し、AdSenseを意識したプライバシーポリシーの記載も見直しています。

この記事では、記事のupdatedAtを表示する仕組みを中心に、ブログを継続運用するための情報を整えた内容をまとめます。

公開日だけでは記事をいつ直したか分からない#

AIモデル、Cloudflare、Astro、npm、Wranglerのような内容は、公開後に仕様が変わることがある。公開日だけでは、記事をあとから実質的に修正した日を読者へ伝えられない。

FrontmatterへupdatedAtを追加する#

記事の表示については、これまでpubDateだけを使っていた。

今回はContent CollectionsのschemaへupdatedAtを追加した。

updatedAt: z.coerce.date().optional()

既存記事には、初期値としてpubDateと同じ日付を入れている。

pubDate: '2026-09-07'
updatedAt: '2026-09-07'

ここで更新日をGitのコミット日時やファイルの更新日時から自動生成する方式にはしていない。記事本文を実質的に修正したときだけ、FrontmatterのupdatedAtを手動で変更する。

記事ページへ公開日と更新日を表示する#

修正前の記事上部は公開日だけだった。

修正前の記事上部。公開日のみを表示している

記事詳細では、公開日と更新日を近い位置に並べて表示するようにした。

公開日と更新日を表示するようにした記事上部

更新していない記事をどう扱うか#

ファイルを開いて保存しただけで更新日が変わる状態にはしていない。記事を実際に更新したときだけupdatedAtを変更し、更新日がない記事では公開日を基準にする。

一覧ページの日付はこれまでどおりpubDateだけを使っている。並び替えも公開日を基準にする。

sitemap.xmlのlastmodにも更新日を使う#

その後、記事の更新日は画面表示だけではなく、sitemap.xmlの<lastmod>にも利用するようにした。

記事を実際に更新した日をFrontmatterで管理しておけば、記事ページの表示とサイトマップで別々の日付を手入力する必要がない。lastmodも記事側の更新日を基準にする。

現在の実装では、scripts/postbuild.mjsが記事のupdatedAtを優先し、未指定の場合はpubDateを使って生成済みsitemapへ<lastmod>を追加する。記事一覧やカテゴリ、テーマ別まとめなどは、掲載記事の更新日から妥当な日付を導出できる場合だけ追加している。

お問い合わせ先を独自ドメインメールへ変更する#

お問い合わせページには、以前mailto形式のフォームを追加している。

その時点では、連絡先としてYahooメールを直接公開していた。

修正前のお問い合わせページ。旧メールアドレスは公開用画像では伏せている

機能としてはこのままでも使える。ただ、Cloudflare Email Routingの設定記事で、独自ドメインメールをすでに作成している。

その作業は、独自ドメインメールの受信設定をまとめた記事に残している。

独自ドメインのメールアドレスを作る―Cloudflare Email Routingを設定する

第1回で取得したcontact@bringain.comを、実際のお問い合わせ先として使うことにした。

変更したのは、ページに表示するメールアドレス、通常のmailto:リンク、フォームから生成するmailto:の宛先の3か所。

お問い合わせ先をcontact@bringain.comへ変更したページ

フォーム自体の仕組みは変えていない。名前、件名、お問い合わせ内容を入力して「メールアプリを開く」を押すと、入力内容を使ったmailto:を生成する。サイト側から自動送信するフォームにはしていない。

実際のメールアプリでも宛先がcontact@bringain.comになり、件名と本文が入ることを確認した。

フォームからメールアプリを開き、独自ドメインの宛先が入った状態

Cloudflare側のEmail Routing設定には手を入れていない。今回はサイト上で公開する宛先を、すでに取得済みの独自ドメインメールへ変更しただけになる。

プライバシーポリシーも現在の運用へ合わせる#

プライバシーポリシーには、Google AdSenseに関する説明を追加している。

修正前の状態でも、Googleなどの第三者配信事業者がCookie等を利用する場合があること、過去のアクセス情報に基づいて広告を配信する場合があること、Googleの広告設定からパーソナライズド広告を無効にできることまでは書いていた。

修正前のGoogle AdSense欄

今回はGoogle AdSenseの必須コンテンツをもう一度確認し、第三者配信事業者や広告ネットワークについての説明を追加した。

追加後は、Google AdSenseを通じて第三者配信事業者や広告ネットワークの広告が掲載される場合があること、それらの事業者がパーソナライズド広告の配信にCookieを使う場合があることを明記している。

Cookieの利用やパーソナライズド広告を無効にできる場合があることも追加し、Googleが案内しているオプトアウト手段としてaboutads.infoへのリンクも置いた。

第三者配信事業者と広告ネットワークの説明を追加したGoogle AdSense欄

既存の「Googleの広告設定」へのリンクはそのまま残している。プライバシーポリシー全体を書き換えたわけではなく、Google AdSense欄へ必要な文章を追加しただけにしている。

H1とfaviconも同じタイミングで小さく修正した#

同じ記事上部を見ていると、記事詳細のH1も少し大きく感じていた。

ただし、サイト全体の見出しサイズを変えるほどではない。

そこで記事詳細のH1だけを対象に、PC側の最大サイズを少し下げた。

修正前は、

clamp(2rem, 5vw, 2.65rem)

修正後は、

clamp(2rem, 5vw, 2.5rem)

としている。

スマホ側で使っている1.75remは変更していない。カテゴリページやTOP、固定ページのH1には影響させていない。

faviconを現在のロゴへ変更する#

最後にブラウザタブのfaviconを変更した。

修正前は、ヘッダーで使っている現在のロゴとは別のfaviconが表示されていた。

ヘッダーですでに使っているsrc/assets/yumaru-logo.pngを再利用している。

BaseHead.astro側のfavicon参照を変更し、ブラウザタブでも現在のゆまラボのロゴが表示されるようにした。

faviconはブラウザ側にキャッシュされやすいので、本番へ反映したあとにも実際のタブ表示を確認する。

ビルドして既存機能を確認する#

今回の変更では、Content Collectionsのschemaと30記事分のFrontmatterも変更している。

作業後に次を実行した。

npx astro sync --force
npm run build
node scripts/verify.mjs
git diff --check

当時のAstro buildは成功し、109ページを生成した。これは今回のタグページ廃止前の確認記録である。

当時はRSS、sitemap、タグページのnoindexとサイトマップ除外、パンくず、BreadcrumbList、前後記事リンクも確認していた。現在はタグページ自体を廃止している。

320px、360px、390px、768px、1280pxでも横方向のオーバーフローがないことを確認した。

更新履歴を持つようにして分かったこと#

今回は、公開後の運用を続けるための変更をまとめて入れた。

Google AdSense欄へ第三者配信事業者・広告ネットワークの説明を追加
お問い合わせ先を取得済みのcontact@bringain.comへ変更
既存30記事へupdatedAtを追加
記事詳細で公開日と更新日を表示
記事詳細H1の最大サイズを少し下げる
faviconを現在のゆまラボのロゴへ変更

独自ドメインメールは別連載で作成したものを、今回実際のお問い合わせ導線へ使う形になった。