記事の更新日は、SEO目的で日付だけを進めず、読者に必要な内容を実質的に変更した場合に、その変更を公開した日に合わせて設定することをおすすめします。
これは、Googleの指針を踏まえた編集部の提案です。まず記事の古い情報や説明の不足を探して修正し、変更内容を記録して日付の整合性を確認します。公開後は、修正した本文と日付が意図どおりに表示されているかを確かめます。
日付だけを新しくする運用を勧めない理由
Googleは、内容を実質的に変えず、新鮮に見せるためにページの日付を変更していないかを、コンテンツの制作方針を見直すための問いの一つに挙げています。日付を進めても、古い料金や適用条件が残っていれば、読者に必要な情報を更新したことにはなりません。
ただし、この説明だけで、日付変更が個別のページで必ず無効になる、あるいは必ずペナルティになるとは断定できません。
出典：Google「有用で信頼性の高い、ユーザー第一のコンテンツの作成」
一方、Googleには、新しい情報が期待される検索に対して、検索にふさわしい鮮度を評価する仕組みがあります。公式資料では、公開されたばかりの映画を検索する人は、撮影開始時の記事よりも最近のレビューを求めている可能性がある、という例が示されています。
これは検索する人が必要とする情報の新しさについての説明です。すべての記事の日付を新しくすれば順位が上がる、という根拠にはできません。
まず、読者の判断に関わる古さや不足を探す
更新対象を選ぶときは、記事が答えている疑問、その答えが当てはまる条件、根拠となる資料を確認します。料金や利用条件を扱う記事なら、提供元の現在の案内と照合し、読者が誤った判断をしそうな箇所から見直すと進めやすくなります。
以下は、Googleの指針を更新作業に応用した編集部の手順です。Googleが定めた公式の作業順ではありません。
更新対象の確認
↓
内容の修正
↓
変更記録・日付の照合
↓
公開後の確認たとえば、架空のサービス料金を案内する記事を考えます。提供元の料金案内で、金額だけでなく、対象者や適用条件も確認します。金額が変わっていなくても、利用できる人の条件が変わっていれば修正対象です。
確認先が見つからない場合は、記事の記述をそのまま正しいと判断しないでください。確認できていない箇所と、追加で必要な情報を記録し、提供元への確認などにつなげます。
内容を直したら、文字数よりも意味の変化を見る
更新日を変更するか迷ったら、修正によって読者に伝える意味や判断材料が変わったかを、編集上の目安にすることを提案します。
参照したGoogleの公式資料には、更新日の変更に必要な修正文字数や割合、固定の更新頻度は示されていません。この目安も、Googleが「大幅な更新」と判定することを保証する基準ではありません。
次は、架空の編集ケースです。
- 料金や適用条件を修正した場合：読者の判断材料が変わるため、実質的な内容更新として記録し、更新日の変更を検討します。一文字の訂正でも、金額や条件の意味が変わるなら、変更量だけで軽微と判断しません。
- 判断に必要な説明を補足した場合：利用できない条件を追加するなど、読者の選択に関わる説明が増えた場合は、その役割を記録します。文章量を増やしたこと自体を基準にはしません。
- 意味に影響しない誤字や表記を訂正した場合：訂正は履歴に残し、記事を新しく見せる目的で更新日を進めない方針を提案します。これは編集部の運用案であり、Googleが定めた誤字訂正の規則ではありません。
- 再確認した結果、変更が不要だった場合：確認した箇所、確認先、確認日を内部記録に残し、内容を更新した場合と区別します。読者にも確認日を示すなら、「情報確認日」など、更新日と区別できるラベルを検討できます。この表示方法も編集部の提案です。
変更の意味を整理するときは、たとえば「対象者の条件を修正し、利用できるか判断できるようにした」と書けば、何のために直したのかが明確になります。
変更を記録し、表示日付と構造化データを照合する
日付を設定する前に、変更箇所、変更前後の内容、変更理由と確認先、作業日、更新日の扱いを記録しておくことをおすすめします。日付を変える理由を後から確認でき、表示に食い違いがあったときの照合にも使えます。
先ほどの架空の料金案内記事なら、次のように記録できます。
- 変更箇所：料金と適用条件の説明
- 変更前後：旧料金を現行料金へ修正し、対象者の条件を追加
- 変更理由・確認先：提供元の料金案内との相違を修正。確認したURLと確認日を記入
- 作業日：実際に原稿を修正した日
- 更新日の扱い：実質的な変更を公開した日に合わせる
原稿を修正した日と、その変更を公開した日が異なる場合は、両者を分けて記録します。編集部では、更新日を読者が修正後の内容を読めるようになった日に合わせる運用を提案します。
公開日・更新日・出来事の日付を分ける
公開日は記事を最初に公開した日、更新日は記事の内容を更新して公開した日として区別します。制度の施行日やイベントの開催日は、記事内で扱う出来事の日付です。
Googleは、ページの公開日・更新日として、未来の日付や、記事内のニュース・イベントの日付を指定しないよう案内しています。たとえば、将来開催されるイベントについて書いても、その開催日を記事の更新日にはしません。開催日を本文で説明することとは別の話です。
画面上の日付と、検索エンジンに伝える日付をそろえる
Googleは、複数の要素からページの公開日または大幅に更新された日を推定します。そのための日付情報として、ページ上の目立つ位置に「公開日」「最終更新日」などのラベルを付けて表示する方法を案内しています。公開日と更新日は、両方またはいずれかを指定できます。
また、構造化データで日付を指定することも推奨しています。構造化データは、ページの情報を検索エンジンなどに伝えるための形式です。ArticleやBlogPostingなどでは、公開日を示すdatePublished、更新日を示すdateModifiedの両方またはいずれかを指定できます。
表示と構造化データを確認するときは、対応する日付同士を照合します。
| 画面に表示する日付 | 対応する構造化データ |
|---|---|
| 公開日 | datePublished |
| 最終更新日 | dateModified |
時刻やタイムゾーンを指定している場合は、それらにも矛盾がないかを確認してください。構造化データに時刻とタイムゾーンを含めても、画面上に時刻まで表示するかどうかは任意です。
公開後は、修正内容と日付を実際のページで確かめる
公開後は、変更記録を手元に置き、公開ページで次の点を確認します。
- 修正した本文や追加した条件が反映されているか
- 日付に「公開日」「最終更新日」などのラベルが付いているか
- 表示日付が、意図した公開日・更新日になっているか
- 表示日付と、対応する構造化データの日付が整合しているか
たとえば架空のケースとして、料金の説明は修正されていても、画面の最終更新日とdateModifiedが異なっていることがあります。その場合は変更記録と照合し、日付を出力する設定や処理を調べ、修正後に公開ページを再確認します。
表示と構造化データの整合性は、実際のページを調べて判断する必要があります。特定のWordPressテーマやプラグインの日付処理はここでは確認していないため、操作方法を一律には案内できません。
ここまでで確かめられるのは、修正した内容と日付設定が意図どおりに公開されたことです。Googleは、日付情報を整えても検索結果に日付が必ず表示されるとは限らないと説明しています。検索結果に日付が出ないことだけで更新作業の失敗とは判断せず、順位向上や日付の反映時期も、この確認からは保証できません。
