毎日更新はSEOに効く？公式が問うのは更新の理由

毎日書けば順位が上がるはず。中身は同じでも日付を今日にすれば、新しい記事として扱われるはず。——このどちらも、Google の公式ドキュメントが実際に書いていることとは噛み合いません。

公式が有用なコンテンツの評価として書いているのは、「そのコンテンツを作った主な理由は何か」という観点です。そして日付については、どう表示するかの条件が具体的に示されています。

だから、決めることは2つに分かれます。更新するかどうかは読者側の理由で決める。日付は公式が挙げる条件どおりに正確に出す。この2つを混ぜたまま運用すると、手元に残るのは中身のない更新カレンダーだけになります。

公式が並べているのは「更新したか」ではなく「なぜ作ったか」

Google の「有用で信頼性の高い、ユーザー第一のコンテンツの作成」は、自分のコンテンツを自分で評価するための問いを並べたページです。冒頭に置かれている前提は、はっきりしています。Google の自動ランキングシステムは、有用で信頼できる情報を優先的に表示することを目的としていて、その情報は利用者に役立つことを目的とするものであり、検索エンジンのランキングを操作するためのものではない、と書かれています。

そのうえで、線が1本引かれています。

コンテンツを作る主な理由が、そのコンテンツによって検索エンジンからの訪問を集めることであるなら、Google のシステムのランキング要素とは合致しない。公式ドキュメントには、そう書かれています。

これを更新の話に当てはめると、問いの順番が入れ替わります。「更新したほうがいいですか」ではなく、「その更新は、何のためにやるのですか」が先に来る。検索エンジンに新しく見せるため、というのが唯一の答えなら、その更新は公式が並べている評価の軸に乗っていません。

このページには、もうひとつ実務的な指示があります。検索での成績が落ちたときには監査を行い、どのページが最も影響を受けたか、どの種類の検索キーワードが成績に影響したかを見つけることを検討するように、と書かれています。落ちたから全記事の日付を更新する、ではありません。まず、どこが落ちたのかを特定する。順番はここでも同じです。

なお、自動化した仕組みでコンテンツを大量に作る話も、同じページで触れられています。自動化技術（AI による生成を含む）を使ってコンテンツを作る主な目的が検索順位の操作である場合、それはスパムに関するポリシーの違反にあたる、という書き方です。「毎日1本」を人手で埋められなくなって自動生成に寄せる運用は、この線に近づいていきます。更新頻度を目標にすると、質を落とす方向に力がかかる。そこは意識しておく価値があります。

日付について公式が言っているのは、見せ方の条件だけ

では日付そのものはどう扱えばいいのか。ここは、公式に具体的な指示があります。

「Google 検索結果に日付情報を表示するおすすめの方法」には、次の内容が書かれています。目立つ、利用者から見える日付を追加し、それに「公開日（Published）」または「最終更新日（Last updated）」というラベルを付けること。あわせて構造化データ（検索エンジンにページの情報を伝えるための専用のコード記述）を使い、Article や BlogPosting といった型で datePublished（公開日）や dateModified（更新日）を指定すること。そして日付と時刻は、利用者から見える表示と構造化データとの間で一致していて、正確で、未来のものではないこと。加えて、それ以外の日付はページ内で最小限にすること。

並んでいるのが何なのかを、もう一度見てください。

ラベルを付ける。構造化データで指定する。表示と一致させる。正確にする。未来にしない。それ以外の日付は減らす。——どれも、日付が正しく揃っているかどうかの条件です。日付を新しくすることが何をもたらすか、という話ではありません。日付は成果を作るレバーではなく、点検する対象として書かれている、と読めます。

この読み方をすると、「中身を変えずに日付だけ新しくする」がどこで詰まるかが見えます。本文をまったく直していないのに dateModified を今日にすると、「正確である」という条件と自分で衝突することになります。何も更新していない日を最終更新日として出しているからです。順位に効くかどうか以前に、公式が挙げた条件のほうを外しにいっている状態と言えます。

検索結果に出る日付そのものが古いままで困っている場合は、条件の当てはめ方を検索結果の日付表示の記事のほうで細かく扱っています。

更新するかどうかを決める6ステップ

更新の是非を、頻度ではなく理由から決める手順です。1記事あたり5分程度で回せます。

1. 「何が変わったか」を1行で書いてみる。 更新作業に入る前に、メモに1行だけ書きます。「料金表が新プランに変わった」「手順3の画面名が変わった」「よく聞かれる質問が抜けていた」。ここで手が止まって1行が書けないなら、その記事は今日直す記事ではありません。これがこの手順の中心です。以降のステップは、1行が書けたときだけ進みます。
2. その1行が、読者の行動を変えるか確かめる。 書けた1行を、記事を読みに来る人の立場で読み直します。この情報が古いままだと、読者は間違った操作をするか、探しものを見つけられません。そう言えるなら直す価値があります。言えないなら、優先度は下がります。誤字1つの修正は、直してよいのですが、更新日を動かすほどの変更かは別の判断です。
3. 本文を直す。 1行で書いた内容を、実際に本文へ反映します。差し替えるのは、その1行に対応する箇所です。ついでに全体をなんとなく書き換えると、後から「何を直したか」が追えなくなります。追えなくなると、次の効果確認ができません。
4. 利用者から見える日付にラベルを付ける。 記事の上部か下部に、日付とセットで「公開日」「最終更新日」の表記があるかを見ます。日付だけがぽつんと置かれていると、それが公開日なのか更新日なのか、読む側には区別がつきません。公式が挙げているのは、「公開日」または「最終更新日」とラベルを付けた、目立つ日付を追加することです。
5. 構造化データの日付と突き合わせる。 ページのソースにある datePublished と dateModified を確認し、画面に見えている日付と一致しているかを見ます。ずれていたら直します。あわせて、未来の日付になっていないかも確認します。予約公開の設定が残っていると、ここが未来日になっていることがあります。
6. 1行のメモを更新ログとして残す。 ステップ1で書いた1行を、日付とセットで記録します。スプレッドシート1枚で足ります。この記録があると、次に成績を見たときに「本文を直したページ」と「触っていないページ」を分けて比べられます。記録がないと、比べる相手が作れません。

この6ステップの実質は、ステップ1だけです。1行が書けない更新をやめる。それだけで、更新頻度を目標にする運用からは抜けられます。

ひとつ通してみる：「更新から3か月たった導入手順の記事」

手順を1本、実際の場面に通してみます。ここでは、自社サイトに「◯◯の初期設定手順」という記事があり、最後に触ったのが3か月前、という状況を想定します。

ステップ1。「何が変わったか」を1行で書こうとします。ここで、書けるものが2つ出てきました。「設定画面のメニュー名が『アカウント設定』から『管理』に変わった」「無料枠の上限が変わった」。2つとも書けたので、この記事は直す対象です。逆に、もし出てきたのが「3か月たった」だけだったなら、ここで終わりでした。

ステップ2。この2つは、読者の行動を変えるでしょうか。変えます。メニュー名が違えば、読者は手順3の画面にたどり着けません。無料枠の数字が古ければ、判断を間違えます。両方とも直す価値がある、と決まります。

ステップ3。本文のうち、メニュー名が出てくる2か所と、無料枠の数字が出てくる1か所を直します。ついでに導入文の言い回しを整えたくなりますが、今回は触りません。次にこの記事の成績を見るとき、「画面名と数字を直した記事」として比べたいからです。

ステップ4と5。記事下部の日付を見ると、「2026年5月10日」とだけ書かれていました。これがどちらの日付なのかが分かりません。「最終更新日：2026年8月11日」の形に直します。続いてソースを見ると、datePublished は入っているのに dateModified がありません。追加して、画面表示と同じ日付を入れます。ここで公式の条件のうち、ラベル・一致・正確の3つが揃いました。

ステップ6。更新ログに1行残します。「2026-08-11 ／ ◯◯の初期設定手順 ／ 管理画面のメニュー名（2か所）と無料枠の数字（1か所）を修正」。

3か月ぶんの「更新していない負い目」から始まった作業が、記録に残る3か所の修正になりました。ここで大事なのは、直したことよりも、直せる1行があったから直した、という順番のほうです。

引き金別・更新するかの判定表

更新したくなる場面ごとに、どこまでやるかを整理した表です。

表の1行目は、さきほどの「無料枠の数字が変わった」がまさにこれです。4行目は、通そうとしてステップ1で止まったほうの記事。5行目については、公式が挙げている「どのページが最も影響を受けたか」「どの種類のキーワードが影響したか」の2つが、そのまま調べる順番になります。どの記事から手を付けるかまで含めた優先順位のつけ方は、リライトの優先順位の記事で扱っています。

つまずきやすいところ

「更新頻度を落としたら評価が下がるのでは」という不安。 ここで頼れるのは、公式ドキュメントに書かれているほうです。日付については、ラベル・一致・正確・未来でないという表示の条件が示されています。有用なコンテンツの評価については、そのコンテンツを作った主な理由を問う自己評価の観点が示されています。更新の本数を目標に置く運用は、この2つのどちらからも導けません。落とすかどうかは、書く本数ではなく、直すべき1行があるかどうかで決めるほうが説明もつきます。

日付を消してしまう対処。 古く見えるのが嫌で、日付表示そのものを消す運用があります。ただ公式が挙げているのは、ラベル付きの目立つ日付を追加する方向です。消す方向は勧められていません。控えるように書かれているのは、ページ内のそれ以外の日付のほうです。関連記事一覧の日付、コメントの日付、フッターの年号。こうしたものが本文の日付と混ざると、どれがこのページの日付なのか判断しにくくなります。

未来の日付が出ているケース。 予約公開の設定や、テンプレートに入れた「更新予定日」が、そのまま構造化データに入ってしまうことがあります。公式の条件では、日付は未来のものであってはいけません。予約公開を使っているサイトでは、公開後に一度だけ実際の日付になっているかを見ておくと安全です。

大量の記事を一括で更新したくなったとき。 一括置換で全記事の dateModified を今日に揃える、という操作は技術的には簡単です。ただしこれは、直した記事と直していない記事の区別を、自分から消す作業でもあります。あとで成績を見たときに、比べる相手がいなくなります。それに、変更していないページの更新日を新しくすることは、正確さの条件から外れます。

残すか消すかで迷っている古い記事。 更新の話とは別に、そもそも残すべきかという判断があります。こちらは古い記事を消すか更新するかの記事で、公開日ではなく有用性で仕分ける手順を扱っています。

公開前に見る5点

更新作業を終えたら、公開の直前にここだけ見ます。

• 本文の変更点を1行で説明できるか（説明できないなら、更新日は動かさない）
• 画面に見える日付に「公開日」か「最終更新日」のラベルが付いているか
• 画面の日付と構造化データの dateModified が一致しているか
• 日付が未来になっていないか
• ページ内のそれ以外の日付が、本文の日付と紛らわしくないか

2つめから5つめは、公式が日付について挙げている条件から取っています。1つめだけは、この記事のステップ1をそのまま点検に回したものです。逆に言えば、日付について自分でコントロールできるのは、ここまでと考えておくのが安全です。

まとめ

毎日更新するかどうかを、公式ドキュメントは直接の論点にしていません。そこに書かれているのは、そのコンテンツを作る主な理由が検索エンジンからの訪問を集めることなら、Google のシステムのランキング要素とは合致しない、という前提のほうです。

だから、更新の判断はこう組み替えられます。まず「何が変わったか」を1行で書く。書けたら直す。書けなければ、その日は更新しない。日付は、ラベルを付けて、構造化データと一致させて、正確に、未来にしない。

やることは、この2つだけです。更新カレンダーの空欄を埋める作業は、ここには入っていません。