リライトしたら更新日は変える？公開日は動かさない理由と線引き

リライトした記事の更新日は、中身を実質的に変えたなら今日の日付にしてかまいません。公開日のほうは、最初に公開した日のまま動かしません。 記事を直し終えて保存する直前に、「公開日を今日にしたほうが新しく見えるのでは」「誤字を直しただけでも更新日は変わるのか」で手が止まった人に向けて書いています。 読み終えると、今回の直しで更新日を変えるかどうかと、画面の日付・構造化データ・WordPress の設定のどこを確かめればいいかが決まります。

日付の前に「そもそもどの記事を直すか」を決める作業は、機械に任せる手もあります。それは記事の最後に書きます。

リライトで「公開日を今日にする」のが、定義から外れる理由

記事の日付には、公開日と更新日の2つがあります。どちらも気分で決める値ではなく、意味が決まっています。記事（Article、NewsArticle、BlogPosting）の構造化データのドキュメントは、2つの項目をこう説明しています。

datePublished: 記事が最初に公開された日時（ISO 8601 形式）。…

dateModified: 記事が最後に変更された日時（ISO 8601 形式）。…

公開日は「最初に」公開された日です。リライトは同じ記事を直す作業なので、何回直しても最初に公開した日は変わりません。リライトのついでに公開日を今日にすると、ずっと前からある記事が「今日公開された」と名乗ることになります。読者から見ても、検索エンジンから見ても、事実と違う日付です。

日付を新しく見せたい気持ちそのものについては、有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成に、作り方を見直すべき警告として次の質問が載っています。

コンテンツを実質的に変更していないにもかかわらず、ページを新鮮に見せるためにページの日付を変更していますか。

この質問が対象にしているのは、中身が変わっていないのに日付だけを動かすことです。中身を変えずに日付だけ新しくするのが成り立たない理由と、古い情報をどの順で直すかは古い記事の情報を更新するリライトの方法、優先順位は3段階、日付だけ変えても意味がないに書きました。この記事では、中身を直したあとに「どの日付を、どこまで直したら動かすか」のほうを扱います。

公開日の扱いは、このサイトでも一度間違えています。ブログを始めた2026年8月、既存7本の公開日が8月14日〜22日という未来の日付になっていて、公開したサイトの記事一覧と sitemap に未来の日付が出ていました。 Google のGoogle 検索で署名日に影響を与えるは、未来の日付を指定しないことと、ここで指定する日付はページの公開日または更新日であることを挙げています。2026年8月11日に、全10本を実際に書いた日(記事を追加した日)に揃え直しました。公開日は見栄えで決める値ではなく、記録です。

更新日を変えるのは、どこまで直したときか

更新日のほうは、リライトで動かしてかまいません。問題はどの程度の直しで動かすかです。 署名日のドキュメントは、Google が日付を推定するときの考え方をこう書いています。

1 つの日付要素だけに依存すると問題が生じやすいため、Google は複数の要素を基に判定しています。つまり、複数の要素を検討して、ページが公開された日または大幅に更新された日をできるだけ正確に推定するようにしています。

英語版も "published or significantly updated" で、同じく「大幅に」が付いています。 Google が知りたいのは、ページが最後に保存された日ではなく、中身が大きく変わった日です。更新日を前に出すのは、前に読んだ人がもう一度読む理由になる直しをしたとき、と私は線を引いています。

ただし、何文字・何割変えたら「大幅」かという基準は、私が確認した Google の3ページ(署名日、ユーザーを第一に考えたコンテンツの作成、記事の構造化データ)のどれにも書かれていません。下の表は、その空白を埋めるための私の線引きです。

定義の字面では、誤字の修正も「変更」に当たります。それでも私が誤字では動かさないのは、署名日で Google が推定しようとしているのが「大幅に更新された日」だからで、どちらに寄せるかはサイトの判断です。

このサイトでは、本文に書いていた期待CTRの数値が古い計算のまま残っていた記事を、2026年10月4日にまとめて直し、それらの記事の更新日を同じ日付にしました。数字が変わると、読者が受け取る結論が変わるからです。 一方で、関連記事への案内を足しただけの記事は、2026年10月6日から更新日を動かさない運用にしています。

1本の記事を1回のリライトでまとめて直すなら、更新日もその回に1回変えれば足ります。どの日に何を変えたかは、更新日とは別に自分で控えておきます。CMS の更新日時は何かを触ったことまでしか教えてくれない、という話はリライトの記録は5項目で足りる、効果測定のやり方は変える前の数字で決まるに書いています。

日付の扱いが決まっても、先に決まっていないといけないのは「どの記事を直すか」です。サーチコンソールの数字からその1本を選ぶところは、道具に任せることもできます。詳しくは記事の最後に書きます。

画面の日付と構造化データの日付を、食い違わせない

日付を決めたら、それが2か所で同じになっているかを確かめます。署名日のドキュメントは、日付の伝え方として、ページ上に見える日付を置くことと、構造化データで datePublished・dateModified を指定することを挙げ、おすすめの方法の中でこう書いています。

日時の整合性に注意する: ユーザーに表示されるデータと対応する構造化データの間で、日付（および任意で指定する時刻とタイムゾーン）が整合するようにしてください。…

画面には「更新日 2026年10月6日」と出ているのに、構造化データの dateModified が2年前のまま、という状態は、テーマやプラグインを入れ替えたあとや、手で日付を書き換えたあとに起きることがあります。どちらかを直したら、もう片方も同じ日付になっているかを見るのが、リライトの最後の作業です。

表示のしかたについては、同じドキュメントに次の2点があります。

• 「日付には、「公開日」や「最終更新日」などのテキストで適切にラベル付けしてください。」。日付だけを裸で置かず、どちらの日付かが分かる言葉を付けます
• 「公開日と最終更新日の両方またはいずれかを指定できます。」。両方を出すか、片方だけにするかはサイトが選べます

このサイトは、記事の上に「公開」と「更新」の両方を出し、一度も更新していない記事には「更新」を出していません。数字を扱う記事が多く、いつの数字かが読者の判断材料になるからです。構造化データも画面と同じ値から作っていて、更新日が無い記事は公開日を dateModified に入れています。画面と構造化データを同じ値から作る仕組みは構造化データのSEO効果は順位ではない、個人ブログがJSON-LDを入れる順番に書きました。

自分の記事で確かめる手順

1. リライトした記事をブラウザで開き、画面に出ている公開日・更新日をメモする
2. ページのソースを表示し、「datePublished」と「dateModified」で検索する
3. 見つかった日付が、1でメモした日付と同じかを比べる。dateModified が古いままなら、テーマやプラグインのどこで出力されているかを調べる
4. どちらも見つからなければ、そのページは構造化データで日付を渡していない

4のとき、エラーを探して Google のテストツールにかけても、気づけないことがあります。記事の構造化データのドキュメントには、datePublished と dateModified のどちらにも「リッチリザルト テストでは、このプロパティに対する警告は表示されません。」とあります。同じドキュメントによると Article には必須プロパティが無く、日付の2項目は、サイトに当てはまると判断した場合にだけ使うよう勧められている推奨プロパティです。日付が入っているかどうかは、ソースを自分で見て確かめます。

もう1つ、ページの中の日付を増やしすぎないことも署名日のドキュメントにあります。おすすめの方法を取り入れても別の日付が選ばれてしまう場合は、「ページ内の他の日付を全部または一部削除することを検討してください。」とされています。本文に「2024年3月追記」「2025年5月追記」のような日付が多い記事は、どれが記事の日付なのかが機械にも読者にも分かりにくくなります。

WordPressで日付を確かめる2か所

WordPress を使っているなら、公開日を設定する場所と、更新日を画面に出している部分の2か所を見ておきます。ここでは WordPress.org の公式ドキュメント(英語)に書かれている範囲だけを書きます。日本語の画面での項目名と、テーマやプラグインごとの既定の動きは確かめていないので、自分の管理画面とテーマの説明書で照らし合わせてください。

公開日: 投稿の設定サイドバーの「Publish」

Settings Sidebarのドキュメントによると、投稿の設定サイドバーの「Publish」は投稿がいつ公開されるかを決める設定で、カレンダーを使って過去の日付にも未来の日時にも変えられます。 つまり公開日は、エディタのこの設定から書き換えられる値です。リライトのときにここを今日の日付にしない、というのが WordPress での具体的な注意点です。

更新日: テーマが「最後に変更された日」を出しているか

更新日を画面に出すかどうかは、テーマ次第です。ブロックテーマなら、Post Date blockのドキュメントにあるとおり、投稿日を表示する Post Date ブロックを、更新日を表示する Modified Date ブロックに変換できます。テンプレートにどちらが置かれているかで、記事の上に出る日付が決まります。

クラシックテーマで更新日を出しているなら、テーマの中でthe_modified_date()などのテンプレートタグが使われていることがあります。公式リファレンスはこのタグを "Displays the date on which the post was last modified." と説明し、まだ変更されていない投稿では作成日と同じ日付になる、と書いています。説明には変更の大きさで区別する話は出てきません。

そのため、更新日を自動で出すテーマでは、誤字を1つ直して保存しただけでも、画面の更新日が新しくなることがあります。公式ガイドの質問が問題にしているのは「ページを新鮮に見せるために」日付を変えることで、誤字を直した結果として更新日が動くことまで問題にした記述は、私が見た Google の3ページにはありません。 気をつけるのは、直すものが無いのに日付を動かす目的で保存し直すことのほうです。小さな直しで日付が動くのを避けたい場合、テーマやプラグインに設定があるかは、それぞれの説明書で確かめてください。

日付を整えても、検索結果に出る日付は選べない

ここまでやっても、検索結果に表示される日付をこちらで決めることはできません。署名日のドキュメントは、ページ上に見える形でも構造化データの形でも、署名日が必ず検索結果に表示されるとは限らないと書いています。冒頭の定義も「ウェブページが更新または公開されたと Google が推定した日付」で、決めるのは Google の側です。 リライトしたのに検索結果の日付が変わらないときに何ができるかは、古い記事の情報を更新するリライトの方法のよくある質問に書きました。

こちらでできるのは、公開日を動かさないこと、更新日を中身の変わった日にすること、画面と構造化データを一致させること、未来の日付を入れないこと、記事の日付と紛らわしい日付を本文に増やしすぎないこと、の5つまでです。検索結果での日付の見え方はその先の話で、こちらでは決められません。

よくある質問

リライトしたら、公開日と更新日のどちらを表示すればいいですか

どちらか片方でも、両方でもかまいません。署名日のドキュメントに「公開日と最終更新日の両方またはいずれかを指定できます。」とあります。両方を出すなら、「公開日」「最終更新日」のようにどちらの日付かが分かるラベルを付けてください。このサイトは両方を出し、更新していない記事には更新日を出していません。

リライトのたびに公開日を新しくして、新着記事として出し直してもいいですか

おすすめしません。構造化データのドキュメントは公開日(datePublished)を「記事が最初に公開された日時」と定義しています。直した日を伝えたいなら、更新日(dateModified)と画面の「最終更新日」を使います。

dateModified だけを入れて、datePublished は省いてもいいですか

構造化データのドキュメント上は、どちらも推奨プロパティで、必須ではありません。署名日のドキュメントも「datePublished フィールドと dateModified フィールドの両方またはいずれかを指定することをおすすめします。」と書いています。ただし画面に公開日を出しているなら、構造化データにも同じ日付を入れておくほうが、2か所を突き合わせやすくなります。

更新日を新しくすると、順位は上がりますか

そう書いた公式の記述は、私が確認した3ページにはありません。公式ガイドが日付について挙げているのは、中身を実質的に変えずに新鮮に見せるために日付を変えていないか、という見直しの質問です。日付で順位を動かそうとするより、直す中身に時間を使うほうが、公式ガイドの考え方に沿っています。

まとめ

• 公開日(datePublished)は「記事が最初に公開された日時」。リライトしても動かさない。WordPress なら、投稿の設定サイドバーの「Publish」を今日の日付にしない
• 更新日(dateModified)は「記事が最後に変更された日時」。Google が推定しようとしているのは「ページが公開された日または大幅に更新された日」なので、私は更新日を前に出すのを、事実・数字・手順など中身を実質的に変えたときに限っている
• 何文字・何割で「大幅」かの基準は、確認した Google の3ページには無い。この記事の表は私の線引き
• 中身を変えずに日付だけ新しくするのは、公式ガイドが「再評価する必要があるという警告」の質問に挙げている行為
• 画面に出す日付と構造化データの日付を一致させる。ページのソースで datePublished と dateModified を検索して確かめる。日付が無くてもリッチリザルト テストは警告を出さない
• 日付を整えても、検索結果に日付が必ず表示されるとは限らない

リライトの日付で迷ったら、日付の定義に戻ります。公開日は最初の日、更新日は中身が変わった日。この2つを守っていれば、少なくとも公開日を偽ったり、直していない記事を新しく見せたりする状態にはなりません。

ここから先は、私が作ったツールの話です。

日付の扱いは、記事を直したあとの話です。その前の「どの記事を直すか」を決めるところを自動でやるツールを作りました。サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差の多い順に並べて出します。診断カードには、今回まとめて反映することの一覧と、変更前の控えをコピーするボタンがあります。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、記事の公開日や更新日を見ていません。サーチコンソールのページ単位のCSVに日付の列が無いためです。この記事で書いた更新日の判断と、画面・構造化データの日付の確認は、自分で行ってください。また、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。