記事の鮮度はどの検索で効く？更新すべき記事の選び方

全部の記事を毎月見直すのは、正直つらい。でも放っておくと順位が落ちる気がする。——その不安の大半は、手放して大丈夫です。

Google の公式ガイドが「鮮度」について書いているのは、新しい情報が期待される検索に対して、新しいコンテンツを出す仕組みがあるということです。裏を返せば、新しさが期待されない検索では、この仕組みが働く場面は限られると読めます。

だから最初にやるのは、記事を直すことではありません。自社の記事が「どんな検索で読まれているか」を見て、鮮度が問われる記事とそうでない記事を分けることです。

公式が書いている「鮮度」は、検索の種類で決まる

Google 検索セントラルの「ランキング システムのガイド」には、「Freshness systems（鮮度に関するシステム）」という項目があります。そこには、Google には「query deserves freshness（その検索は新しさに値する）」と呼ばれる複数のシステムがあり、新しいコンテンツが期待される検索で、より新しいコンテンツを表示するように設計されている、と書かれています。

例も2つ挙がっています。

1つめは、公開されたばかりの映画を調べている人です。この人はおそらく、制作が始まったころの古い記事ではなく、最近のレビューを読みたい。2つめは「地震」という検索です。ふだんなら、備えや役立つ情報が出てくることがある。ところが最近地震が起きたのであれば、ニュース記事や新しいコンテンツが出てくることがある、という説明です。

ここで大事なのは、主語が「記事」ではなく「検索」になっている点です。

記事を新しくしたから上がる、とは書かれていません。新しさを期待する検索があり、そこでは新しいコンテンツが出やすい。書かれているのはそこまでです。つまり、鮮度を気にすべきかどうかは、その記事がどんな検索で読まれているかで決まります。

「新しく見せる」更新は、公式の自己点検で問われている

では、鮮度が問われない記事の日付を新しくしておくのは、保険として悪くないのでしょうか。

公式の「有用で信頼性の高い、ユーザー第一のコンテンツの作成」には、自分のコンテンツを点検するための問いが並んでいます。その中に、次の2つがあります。

• 中身が実質的に変わっていないのに、新しく見せるためにページの日付を変えていないか
• サイトを「新しく」見せれば検索順位全体に役立つと考えて、大量のコンテンツを追加したり古いコンテンツを削除したりしていないか

2つめの問いには、括弧書きで「(No, it won't)」、つまり「役立ちません」と添えられています。

保険のつもりの日付更新は、この自己点検の問いにそのまま当てはまります。鮮度が問われない記事に手を入れるなら、日付ではなく中身のほうです。日付の扱い方そのものは、毎日更新はSEOに効くかの記事で詳しく扱っています。

自社記事を3群に分ける判定表

公式が挙げた2つの例を、自社サイトの記事に当てはめやすい形に広げたのが、次の3群です。この分け方は公式の分類ではなく、例から組み立てた実務上の目安です。

表の右端の「つまずき所」は、どれも同じ形をしています。

直す理由がないのに手を入れるか、直す理由があるのに手を入れていないかのどちらかです。出来事型は触りすぎ、定期改訂型は直し漏れ、普遍型は見せかけの更新が起きやすい。3群に分けると、記事ごとにどちらの失敗に寄りやすいかが見えてきます。

1つの検索が、ある日から出来事型に変わる

判定表には、1つ注意があります。

「地震」の例をもう一度見てください。同じ言葉の検索でも、ふだんは備えの情報が出てくることがあり、最近地震が起きたあとはニュースや新しいコンテンツが出てくることがある。つまり、群は記事に固定されたラベルではなく、時期によって入れ替わることがあります。

自社サイトに置き換えると、こういうことです。「◯◯の設定方法」という普遍型の記事があったとします。ところが製品の画面が大きく変わった月だけは、「新しい画面での設定方法」を探す人が増えるかもしれません。その期間だけ、この記事は出来事型に近い扱いになります。

逆の動きもあります。新機能の紹介記事は、出たばかりのうちは出来事型です。半年もすれば「その機能の使い方」を調べる検索が中心になり、普遍型に寄っていくことがあります。

だから仕分けは一度で終わりにせず、製品の大きな変更や制度の改訂があったときに見直す。この運用にしておくと、群の入れ替わりを取りこぼしにくくなります。

Search Console で確かめる6ステップ

記事の群を「なんとなく」で決めないために、Search Console の検索パフォーマンスレポートを使います。このレポートでは、レポート上部の期間の絞り込みで対象の期間を変えられます。表は、選んだ項目（たとえば検索キーワード、ページ、国）ごとにまとめて表示されます。見る数字は、クリック数（検索結果からサイトがクリックされた回数）、表示回数（検索結果にサイトが表示された回数）、平均掲載順位（サイトの中でいちばん上に出た結果の平均順位）の3つです。

1. 見直し候補の記事を10本選ぶ。 全記事を一度に仕分けようとすると止まります。まずは更新のことで悩んでいる記事、または表示回数の多い記事から10本に絞ります。
2. 記事ごとに、読まれている検索キーワードを書き出す。 検索パフォーマンスレポートで、その記事が表示されている検索キーワードを確認し、表示回数の多い順に上位3つをメモします。記事のタイトルではなく、実際の検索キーワードで判断するのがこの手順の要です。
3. キーワードに「いつの話か」が含まれているかを見る。 年号・「最新」・「新しい」・製品の新しいバージョン名・「変更」などが入っていれば、出来事型か定期改訂型の候補です。入っていなければ、普遍型の候補です。
4. 期間を切り替えて、表示回数の山を見る。 期間を長めにとり、表示回数が特定の時期だけ跳ねていないかを見ます。決まった時期に毎年山があるなら定期改訂型、一度だけ大きな山があってその後は落ち着いているなら出来事型が終わった後の可能性があります。山が見当たらず横ばいなら普遍型と考えてよさそうです。
5. 判定表に当てはめて、群と見直しの時期を決める。 出来事型なら「次の出来事が起きたら」、定期改訂型なら「◯月の改訂時」、普遍型なら「誤りが見つかったら」と、見直しのきっかけを1行で決めます。
6. 年間の予定表に書き込む。 定期改訂型だけを、改訂の時期にあわせて予定表に入れます。出来事型と普遍型は予定表に入れず、きっかけが来たときに動く記事として一覧にしておきます。

この6ステップで減らしたいのは、作業の量そのものより「毎月全部見なければ」という不安のほうです。予定表に載るのは定期改訂型だけになるので、多くのサイトでは見直しの対象がかなり絞られるはずです。

ひとつ通してみる：業務ソフトの会社のブログ5本

手順を実際の場面に通してみます。ここでは、請求書や経費精算のソフトを提供している会社が、自社ブログに次の5本を持っている状況を想定します（記事名と検索キーワードは説明のための架空のものです）。

• A「新機能：請求書の一括送信に対応しました」
• B「経費精算の締め日を決めるときの考え方」
• C「インボイスの記載事項チェックリスト」
• D「年末調整のスケジュール」
• E「請求書の書き方の基本」

ステップ2で、それぞれの上位キーワードを書き出しました。A は「請求書 一括送信」、B は「経費精算 締め日」、C は「インボイス 記載事項」、D は「年末調整 スケジュール 2026」、E は「請求書 書き方」でした。

ステップ3。年号が入っているのは D だけです。A は記事名に「新機能」とありますが、実際の検索キーワードには「いつの話か」が入っていません。ここで、記事名ではなく検索キーワードで見る意味が出てきます。

ステップ4。期間を長めにとって表示回数を見ると、D は毎年秋から冬にかけて山があり、それ以外の時期はほとんど表示されていませんでした。A は公開直後に山があり、その後は低い水準で横ばいです。B・C・E は大きな山がありません。

ステップ5で判定表に当てはめると、こうなります。

• D は定期改訂型です。表の2行目、「年号だけ書き換えて、中身の数字を直し忘れる」が最も起きやすい記事なので、見直しは秋の山の前に、日付ではなく中身の日程から確認します。
• A は、出来事型が終わった後の記事です。検索キーワードが「一括送信」という機能の使い方に移っているので、今は普遍型に寄っていると判断し、機能の画面が変わったときだけ直すことにします。
• C は、制度の内容を扱うので定期改訂型の候補です。ただし大きな山はないので、決まった月ではなく「制度の改正が発表されたら」を見直しのきっかけにします。
• B と E は普遍型です。決まった周期では触りません。

ステップ6で予定表に入ったのは、D の1本だけでした。毎月5本を見直していた運用が、年1回の D の見直しと、きっかけ待ちの4本に変わります。

よくある誤解

「普遍型の記事は、一度書いたら放置してよい」わけではありません。 普遍型は、決まった周期で触らなくてよいというだけです。誤りや説明不足が見つかったら直します。公式の自己点検の問いも、内容が実質的に変わったかどうかを問題にしています。中身を良くする更新まで止める理由にはなりません。

「出来事型の記事は、毎日更新すべき」とも限りません。 公式の説明は、新しいコンテンツが期待される検索でより新しいコンテンツを表示する、というものです。古い記事を何度も触り直すより、出来事ごとに新しい記事を書くほうが、検索している人の期待に合う場合もあります。どちらがよいかは、出来事の大きさと既存記事との重なりで決めるのが現実的です。

「検索結果に出る日付を新しくすれば、鮮度があると見なされる」とも読めません。 公式の日付のページには、検索結果に出る日付は、Google がページの公開や更新の日付を推定したものだと書かれています。そして、すべての要素には問題が起こりうるので、1つの要素に頼らず、複数の要素から公開日や大幅な更新日を推定している、とも書かれています。日付の表示は、見える場所に日付を目立つように置き、構造化データで datePublished（公開日）や dateModified（更新日）を指定する、という正確さの話として扱うのが安全です。表示されている日付が古いままで困っている場合は、検索結果の日付表示の記事で点検の手順を扱っています。

仕分けを終えたら見る5点

• 群を決めた根拠が、記事のタイトルではなく実際の検索キーワードになっているか
• 定期改訂型の記事に、見直す月が決まっているか
• 定期改訂型の見直しで、年号だけでなく数字・日程・条件を確認する段取りになっているか
• 普遍型の記事で、日付だけを新しくする作業が予定表に残っていないか
• 製品の大きな変更や制度の改訂があったときに、群を見直すきっかけを決めてあるか

1つめが崩れると、残りの4つも崩れます。仕分けの土台は、いつも検索キーワードの側にあります。

まとめ

公式ガイドが書いている鮮度の仕組みは、新しいコンテンツが期待される検索で、新しいコンテンツを出すためのものです。だから、全部の記事を同じ頻度で新しくする必要はありません。

まず、記事が読まれている検索キーワードを見る。出来事型・定期改訂型・普遍型に分ける。予定表に入れるのは定期改訂型だけにして、残りはきっかけが来たら動く。

見直しの優先順位を、表示回数や順位の伸びしろで決めたい場合は、リライトの優先順位の記事の手順と組み合わせると進めやすくなります。