ブログ記事の更新日、入れるべきか迷いませんか。私も最初は「新しい日付が出たほうがよさそう」くらいで考えていました。でも、本文が古いまま日付だけ新しい記事は嫌です。読者を待たせたうえで、古い地図を渡している感じがあります。
更新日は飾りではなく、本文を実質的に直した記録として見せるものです。料金、条件、手順、結論など、読者の判断や行動を変える箇所を確認して直したなら更新日を出す意味があります。誤字や語尾を整えた、壊れたリンクを同じ内容のURLへ差し替えただけなら、私は日付を動かしません。
更新日は、本文を直した証拠として出します
読者が見ているのは、日付そのものではありません。「この情報を今も信じていいのか」を見ています。だから更新日を出すなら、本文のどこを確認し、読者の判断材料をどう直したのかが近くに必要です。料金を現行プランへ直した。終了した手順を置き換えた。比較の結論が変わった。そういう作業があって、初めて日付が意味を持ちます。
たとえば、2024年に書いたツール紹介の記事で、料金プランが変わっていたとします。この場合は、料金部分を直して更新日を出すのは自然です。逆に、本文の「です」を「ます」に直しただけなら、読者の判断材料は変わっていません。そこまで更新日を動かすと、日付の信用が薄くなります。
日付だけ新しい記事は、読む側が困ります
更新日が新しいと、読者は「確認済みなんだな」と受け取ります。そこで古い画面名や終了したサービス名が出てくると、読者はどこまで信じていいか分からなくなります。記事全体が疑われるというより、読みながら一回止まります。その停止がもったいないです。
操作手順の記事なら、画面名がひとつ違うだけで読者は迷います。SEO設定の記事なら、プラグインのメニュー名が変わっただけでも手が止まります。古い画面を残すなら、古い画面であることを書いたほうがいいです。何も書かずに更新日だけ新しい状態がいちばん困ります。
更新した場所を本文に残します
更新日を変えるなら、本文中に確認した場所を残します。大げさな更新履歴はいりません。「料金プランを確認しました」「画面名を現行表示に合わせました」くらいで足ります。読者が知りたいのは、この記事全体の努力ではなく、自分が判断に使う情報が今も合っているかです。
更新履歴を記事の上に長く置きすぎるのも避けます。更新履歴が長いと、本文に入る前に読者が止まります。必要なのは、本文の判断に関係する更新です。細かい誤字修正や表記ゆれの整理まで毎回並べると、記事が作業ログになります。
更新日を変えないほうがいい作業
言い回しを整えた、画像の角丸を直した、改行を詰めた。このあたりは、読者の判断材料を変えていません。もちろん読みやすくする価値はあります。でも、それは更新日で知らせるより、黙って読みやすくしておけばいい作業です。
日付を変えないと損をする気がするかもしれません。私もその気持ちはあります。ただ、更新日を信用の印にするなら、使いどころを絞ったほうがいいです。毎回日付が動くサイトより、必要なときだけ日付が動くサイトのほうが、読み手としては判断しやすいです。
迷ったときの確認順
更新日を変えるか迷ったら、本文の中で読者が判断に使う箇所を探します。料金、手順、比較条件、注意点、結論。このどれかを実際に確認し、答えを実質的に直したなら更新日を変えます。確認しても答えが変わらなかった、または軽微な保守だけなら、日付はそのままにします。
この順番にすると、更新日の扱いが楽になります。「直したから変える」ではなく、「読者の判断材料を直したから変える」です。ここを分けると、日付をむやみに動かさなくて済みます。
もうひとつ見るなら、記事の冒頭です。更新日だけ新しくしても、冒頭が昔のままだと読者はそこで引っかかります。「最近は」や「現在は」と書くなら、本当に現在の話になっているかを確認します。ここを放置して日付だけ変えると、本文の中でいちばん目立つ場所が古いままになります。
更新日を変える理由を一文で残します
公開前に、更新した理由を一文で書けるか確認してください。「料金を現行プランに直した」「終了した機能の説明を削った」「今の画面に合わせて手順を書き直した」。こう書けるなら更新日を変えます。「読みやすくした」だけなら、今回は日付を動かさない。私はその線引きで運用します。
Googleの公開日・更新日のガイドでは、検索結果に表示する日付を、ページが公開または大幅に更新された時期として推定すると説明しています。更新日は、読者に向けた「答えを確認して直しました」のサインです。だから、サインだけ立てない。まず直すべき記事か迷うならリライトのタイミングへ、残す・統合する・削除する判断も見たいなら古い記事の判断順へ進めます。
コメント