無料配布中:AIブログ設計GPTで、ジャンル設計・記事テーマ・収益導線を整理できます。 無料で受け取る

ブログをリライトしたら日付は変える?公開日・更新日の使い分けと設定手順

同じ記事の公開日と更新日の役割を、本と2つのカレンダーで分けた図
  • URLをコピーしました!

記事をリライトした。さて、公開日も今日に変えたほうがいいのか。

結論から言うと、同じ記事を改善する通常のリライトなら、最初の公開日は残し、内容を改めたことを更新日で伝える。この運用をおすすめします。

「古い日付だと読まれないかも」と不安になる気持ちは分かります。でも、日付だけ若返らせても、記事の中身は若返りません。

大事なのは、読者が今日その記事を読んだときに、古い料金で比較したり、存在しないボタンを探したりせずに済むこと。その改善をしたうえで、いつ直した情報なのかを正しく伝えるのが日付の役割です。

この記事では、公開日と更新日の違い、更新として伝える修正の基準、WordPressで確認する場所を整理します。最後まで読めば、「日付をどうしよう」と迷うところから、元のURLを守ってリライトを完了するところまで進められます。

目次

ブログのリライトでは「公開日」と「更新日」を分ける

同じ記事の公開日と更新日の役割を、本と2つのカレンダーで分けた図
公開日は記事の出発点、更新日は内容を改めた時点です。

公開日は記事の出発点、更新日は内容を改めた時点

公開日は、その記事を最初に公開した日。更新日は、公開した記事を後から変更した日です。同じ場所に表示されることがありますが、伝えている情報は違います。

例えば、2025年4月に公開したサーバー比較記事を、2026年10月に現行プランで比較し直したとします。これは説明用の例ですが、「公開:2025年4月」「更新:2026年10月」と分ければ、以前からある記事を今の情報に直したことが伝わります。

私がおすすめするのは、このように記事の履歴と情報の鮮度を両方伝える形です。古い公開日は、恥ずかしくて隠すものではありません。内容が維持されているなら、過去から育ててきた記事として扱えばよいのです。

一方、過去の出来事を記録する記事は、その当時の日付にも意味があります。「2023年に利用した感想」を、体験まで今年のものになったように見せてはいけません。現在の情報を追記するなら、過去の体験と追記部分を区別します。

検索結果の日付は、こちらの設定どおりに固定できない

記事の上に表示する日付と、Googleの検索結果に表示される日付も、同じものではありません。

Googleは複数の情報から公開・更新の時期を推定します。ページに適切なラベル付きの日付を示すことはできますが、検索結果にその日付が必ず出るわけではありません。Google公式の日付に関する説明

つまり、WordPressで更新日が表示できたのに、検索結果では以前の日付のままということはあり得ます。それだけで「リライトに失敗した」と判断するのは早いです。

ここを混同すると、記事の内容は十分に改善できているのに、検索結果の日付を動かすためだけに公開日を何度も書き換えることになります。まず分けて見るべきなのは、記事の改善、サイト上の表示、Google側の表示の3つです。

日付の変更自体をSEO対策の主役にしない

「日付を今日にすれば、Googleに新しい記事だと思ってもらえるのでは」。そこに期待する運営はおすすめしません。

Googleのコンテンツ評価の自己点検項目にも、実質的に内容が変わっていないのに、日付を変更して新しく見せていないか、という問いがあります。Google公式の有用なコンテンツに関する説明

これは、誤字を直して更新日が変わっただけで、直ちにペナルティになるという話ではありません。日付の操作を、内容の改善の代わりにするなという話です。

読者は「今日更新された」という数字だけを買ってくれるわけではない。比較して選べる、疑問が解ける、次にやることが分かる。その価値を直さずにカレンダーだけ動かしても、ブログを育てたことにはなりません。

どこまで直したら更新日を変える?文字数ではなく変更の意味で判断する

判断が変わる修正、誤字の訂正、情報確認の3パターンを比較した図
修正の量ではなく、読者の判断に何が変わるかで整理します。

料金・手順・結論が変わる修正は、更新内容を伝える

「何文字直せば更新してよいか」という基準を探すより、修正前と修正後で、読者の判断や行動が変わるかを見てください。

料金が月額1,000円から2,000円になったなら、数文字の変更でも比較結果に影響します。反対に、同じ説明を長く言い換えて1,000文字増やしても、読者が得る情報は増えていないかもしれません。

私は、次のように整理するのが実用的だと考えます。これはGoogleが定めた文字数ルールではなく、ブログを管理するための判断例です。

直した内容 読者にとっての変化 日付・補足の扱い方
料金、条件、提供終了したサービス 選ぶ商品や予算が変わる 更新日と、何を更新したかを示す
現在の画面に合わせた操作手順 実際に操作できるようになる 更新日を示し、必要なら対応環境も書く
追加検証でおすすめの結論を変更 選び方や判断が変わる 更新理由と新しい結論を説明する
誤字、句読点、余分な空白 情報の意味はほぼ同じ 大幅更新として宣伝しない
公式情報を確認したが変更なし 確認できた時点が分かる 必要な箇所に情報の確認日を添える

特におすすめが変わったときは、日付だけで済ませないほうが親切です。「料金改定に伴い、初心者向けのおすすめを見直しました」と一文あるだけで、以前読んだ人にも変更の意味が伝わります。

誤字の修正で自動更新された日付を、無理に巻き戻さなくてよい

WordPressでは、保存に伴って更新日時が変わり、それをテーマなどが表示する構成があります。そのため、「誤字しか直していないのに更新日が変わった」という場面も出てきます。

ここで、検索エンジンに怒られるのではと慌てて、データベースやテーマのコードを触る必要はありません。小さな訂正をしたことと、情報を全面的に最新化したと宣伝することは別です。

もし更新日の扱いを細かく分けたいなら、まず使用中のテーマに「更新日を変更しない」などの機能があるかを、そのテーマの説明で確認します。機能名や対応状況は環境によって違うので、すべてのWordPressにある前提では探さないでください。

大事なのは、見せ方が実態を超えないことです。句読点を直しただけなのに、タイトルを「完全最新版」にする。このような扱いをやめれば、日付に振り回される必要はかなり減ります。

「確認した日」と「記事全体を更新した日」を混ぜない

一部分だけ確認した場合は、その範囲を示します。例えば「料金は2026年10月7日に公式サイトで確認」と、料金表の近くに書く形です。

ただし、料金表だけ見て、手順も機能も比較の結論も確認していないなら、「記事全体を最新情報に更新しました」とは書けません。確認した範囲を広げて見せないことがポイントです。

また、情報に変更がなかった確認作業は、記事の大幅な書き直しとは違います。管理メモに確認日を残し、読者の判断に役立つ場合に本文にも示す。このくらいに分けると扱いやすくなります。

日付の表示を増やしすぎるのも逆効果です。タイトル下には公開日と更新日、条件が変わりやすい表の近くには情報確認日。何の日付なのかを、読者が推理しなくてよい状態にしてください。

WordPressでリライトする手順:公開日時より先に本文を直す

元の情報を残し、本文修正、表示確認、変更記録と進めるリライト手順
通常のリライトは既存記事を編集します。図内のURL・記録日は説明用の例です。

編集前に、元のURL・公開日・本文を残しておく

まず、直したい記事の公開ページを開きます。そのURLと最初の公開日、現在の本文を残してください。大きく直すときは、元の本文を別ファイルに控えるか、利用できるリビジョンを確認しておくと、比較や差し戻しがしやすくなります。

次に「今回何を直すのか」を一文で決めます。「内容を良くする」では曖昧です。「申込画面が変わって操作できないので、現行画面の手順に置き換える」なら、修正後のチェック項目まで明確になります。

ここを決めないままAIに全文を書き直させると、残したかった体験談や、読者によく伝わっていた説明まで消えることがあります。直す範囲と、残す範囲は先に渡したほうが良いです。

なお、検索順位がついている記事を「古いから」というだけで全面改稿するのはおすすめしません。情報の誤りは直すとしても、日付の古さと文章の悪さは別々に判断しましょう。

既存の記事を編集し、「公開」のカレンダーは変更しない

WordPressの管理画面で「投稿」から対象の記事を開き、本文や画像を修正します。同じ検索意図の記事を改善するなら、新しい投稿にコピーするのではなく、基本的には既存の記事を編集します。

編集画面の投稿設定にある「公開」の日時は、最初に公開した時点を扱う項目です。リライトした日を伝えたいからといって、ここを今日へ変更する必要はありません。WordPressの画面はバージョンで見た目が変わりますが、公開日時と本文の保存は区別してください。WordPress公式の投稿設定の説明

本文を直したら、プレビューで確認し、「保存」または「更新」のボタンで反映します。確認するのは文章だけではありません。古いスクリーンショット、終了した商品のリンク、表と本文で食い違う数字も対象です。

公開日時のカレンダーを未来に動かすなど、公開状態まで変える操作は避けます。「リライトのつもりだったのにページが見られなくなった」という余計なトラブルを作らないためです。

更新日が表示されないときは、テーマの表示設定を確認する

保存したのに、記事上には公開日しか出ていない。この場合、本文の保存に失敗したとは限りません。更新日を表示するかどうかは、テーマやテンプレートの設定も関わります。

まず使っているテーマのマニュアルで、記事タイトル周辺の「公開日・更新日」の表示設定を探します。テーマに機能があるなら、既存の設定を使うのが分かりやすいです。設定を変えたときは、対象の記事以外にも表示が変わる可能性を確認します。

ブロックテーマのサイトエディターを使う構成では、更新日を表示する「Modified Date」ブロックも選択肢です。ただし、すべてのテーマで同じ編集画面になるわけではありません。WordPress公式の更新日ブロックの説明

表示を整えたら、編集画面ではなく、実際の公開ページを開いて確認します。ログインしていない画面でも新しい本文が出るか、スマホでも日付のラベルが読めるかを見る。古い表示が残るなら、利用中のキャッシュ機能の説明に沿って確認してください。

日付入りURLと、新規投稿へのコピーには注意する

公開日を気軽に動かさない理由は、履歴だけではありません。URLに公開年月日を含める設定の場合、日付の変更がURLに影響することがあります。

例えば、URLが /2025/04/10/example/ のような構成なら要注意です。WordPressには年・月・日をURLに組み込む設定があります。一方、投稿名だけのURLでは、同じ理由で日付部分が変わるわけではありません。WordPress公式のパーマリンク設定

通常のリライトなら、URLを維持して内容を改善するのが扱いやすいです。日付対策のためだけに、サイト全体のパーマリンク設定まで変更する必要はありません。

同じ内容を新しい記事として公開し直し、元の記事も残す方法も安易に選ばないでください。読者からすると、どちらを読めばよいか分からなくなります。意図してURLを変える場合は、旧URLからの転送や内部リンクの修正まで含む別の作業として扱いましょう。

日付の表示だけでなく、検索エンジンに渡す情報も揃える

公開日とdatePublished、更新日とdateModifiedの対応を示す図
公開日と更新日を同じ値にするのではなく、同じ意味の項目同士を揃えます。

見える日付と、記事データの意味を合わせる

サイトの表面では「更新日」と出ていても、裏側のデータは別の日時になっている場合があります。ここで出てくるのが、検索エンジンに記事の情報を伝える「構造化データ」です。

難しいコードを自分で書く必要はありません。まず知っておきたいのは、datePublished は公開日時、dateModified は更新日時を表すという違いです。同じ意味を持つ画面上の日付とデータの値が矛盾しないようにします。

確認する場合は、記事のページソースや構造化データの検査結果で、この2つの名前を探します。公開日と更新日が別の日なのは当然あり得ますが、画面上の「更新日」と記事データの更新日時が食い違っていたら、出力しているテーマやSEOプラグインの設定を確認します。

時刻付きのデータは、タイムゾーンも見てください。日本時間では翌日でも、UTC表記では前日になることがあります。日付の文字だけを見て誤りと決めず、同じ時点を表しているかで比べます。

既にテーマやプラグインが出力しているなら、分からないまま別のコードを追加しないこと。同じ記事の日時が複数の仕組みから食い違って出ると、確認も修正も複雑になります。

サイトマップの更新日を、全記事まとめて今日にしない

サイトマップには、ページの最終更新を表す lastmod が含まれることがあります。読者に見える日付とは別に、ページの変更を伝えるための情報です。

Googleは、正確で一貫した lastmod を利用すると説明しています。ページの主要な内容などに実質的な変更があった時点を反映するのが基本で、フッターの著作権年を変えただけのような修正とは区別されています。Google公式のサイトマップの説明

ブログ初心者が、ここを手作業で書き換える必要は通常ありません。サイトマップを生成している機能を確認し、日付がどう出力されるかを把握すれば十分です。そもそも lastmod を出していない構成もあります。

問題なのは、記事を直していないのに、毎日すべてのページの日付を新しくするような仕組みをわざわざ入れることです。管理すべきなのは「新しく見せる方法」ではなく、「実際の変更が正しく伝わる仕組み」です。

リライトしたのに検索結果の日付が変わらないときの確認順

公開ページ、日付データ、クロール、検索結果の順で確認する図
検索結果だけを見ず、サイト側から切り分けます。画面・日付は説明用の模式図です。

公開ページ、出力データ、クロールの順に切り分ける

検索結果の表示が気になると、ついGoogleの画面ばかり見てしまいます。でも、確認は自分のサイトから始めたほうが早いです。

「WordPressには保存できているが、一般の閲覧者には古い本文が出る」なら、検索結果の日付を考える前の問題です。逆に、ページも日付も正しく、Googleがまだ変更後のページを取得していないなら、設定を何度も変える場面ではありません。

現在の状態 まず見る場所 次の対応
公開ページ自体が古い 保存結果、表示しているURL、キャッシュ 本文が正しく反映される状態にする
本文は新しいが、表示日付やデータが不一致 テーマ・SEOプラグインの出力 日付の意味とタイムゾーンを確認する
サイト側は正しいが、最終クロールが修正前 Search ConsoleのURL検査 必要に応じて再クロールを依頼する
修正後にクロールされても検索の日付が変わらない Googleの表示判断、ページ内の他の日付 設定を壊さず、内容と表示の整合性を保つ

上の順番なら、直す場所が絞れます。「とりあえず公開日を今日にしてみる」は、原因の確認を飛ばしています。数字が動いたとしても、なぜ動いたか分からない運営になってしまいます。

URL検査を使っても、日付の書き換えを予約できるわけではない

Search Consoleでは対象URLを検査し、Googleが取得したページの情報や、最終クロールの時点を確認できます。大きくリライトした記事なら、必要に応じてインデックス登録をリクエストします。

ただし、これは「検索結果の日付を今日にしてください」という申請ではありません。Googleにページを再確認してもらうための依頼です。何度も押せば速くなるものでもありません。Google公式の再クロール依頼について

また、公開ページをその場で確認するテストと、既にGoogleが保持している情報は区別します。今のページが問題なく読めることを確認できても、検索結果の表示まで更新済みとは限りません。

記事内にイベント開催日や過去の体験日がある場合も、何の日付か分かるラベルを付けます。正しい歴史的な日付や体験の日時を、検索表示を変えたい一心で消してしまうのは本末転倒です。

日付が新しくなったかと、リライトの成果は別に測る

確認の最後に、元々の目的へ戻ります。今回直したのは、検索順位を改善するためか、クリックされるようにするためか、読者が申し込みまで進めるようにするためか。

例えば、検索意図に合わせて結論を整理したなら、対象ページの検索語句や掲載順位を見ます。古い商品リンクを直したなら、紹介先へ進めるかも確認する。日付が変わったことだけをもって成功とはしません。

比較するときは、変更日をメモし、同程度の期間で見ます。ただし、季節性や検索需要の変化もあるので、翌日の数字だけで良し悪しを決めないこと。日付の表示が変わる前に、記事の利用状況が変わる可能性もあります。

どの記事を直すか、Search Consoleのどの数字を見るかを詳しく整理したい場合は、サーチコンソールを使ったブログのリライト手順も参考にしてください。この記事の日付確認と、成果の診断は分けて進めると迷いません。

リライトの日付は、記事を育てた記録として使う

私がアクセスを伸ばしたのは、日付ではなく記事に向き合ったから

以前の私は、新しい記事を作ることにかなり力を入れていました。それでも思うようにアクセスが伸びず、あまり新規更新をしていないのに強いブログは何をしているのか、自分なりに調べました。

そこでリライトに力を入れるようになりました。直していない記事がたくさんあったので、リライトに集中した結果、時間の関係で約2か月、新しい記事を書けなかったんです。その後、アクセスは1.8倍になりました。

この経験を「新規更新を止めれば伸びる」と受け取ってほしくはありません。まして、日付変更の効果を比べた実験でもありません。記事を増やすこと以外にも、成果につながる仕事があると実感した経験です。

今はAIがあるので、書き直す作業そのものはかなり速くできます。だからこそ、「更新しました」という見た目を作るのは簡単です。でも、読者の疑問が前より解決できるかを確かめる仕事は、省いてはいけない。リライトの価値は、そこにあります。

更新メモは「いつ」だけでなく「何を、なぜ」まで残す

何十記事も管理していると、日付だけでは何を直したか思い出せなくなります。私なら、管理する項目を次のように絞ります。これはそのまま使える管理例です。

  • 対象URLと初回公開日
  • 今回の修正日と、修正前に困っていたこと
  • 変更した内容と、あえて残した内容
  • 公開ページ・日付・リンクの確認結果
  • 次に確認する指標やタイミング

例えば「10月7日、料金改定で比較表が古くなったため修正。おすすめの対象者も見直した。初回公開日とURLは維持。表示とリンクを確認済み」という記録なら、後から変化を追えます。

これを「日付更新済み」だけで終わらせると、何を改善したのかが消えてしまいます。大げさな監査表は不要ですが、次の自分が判断できる記録は残しておきましょう。

具体的な本文の直し方や、AIに任せる範囲で迷う場合は、AIを使ったブログのリライト方法で、記事の内容を改善する流れを確認できます。

最後に直すべきなのは、カレンダーではなく読者が困る場所

通常のリライトは、公開日とURLを残して、内容を改善する。意味のある変更を更新日や短い補足で伝える。表示がおかしいときは、サイト側から順に確認する。まずは、この流れで十分です。

それでも日付の古さが気になって仕方がないなら、記事を一度、読者として読み直してみてください。「この情報は今も使えるか」「この説明で実行できるか」「この商品を勧める理由は今も通るか」。そこには、日付をいじるより大事な仕事が見つかるはずです。

もし記事を直し続けても成果につながらず、ジャンルや読者設定、収益への導線から考え直したい段階なら、日付の調整だけでは解決できません。私はAIブログ収益化フルプロデュースで、ブログの設計から初期記事・導線まで整えたブログを制作しています。運営の土台からプロに任せたい方は、内容を確認してください。

日付は、改善した事実を伝えるためのもの。改善したつもりになるためのものではありません。

あなたの記事を良くするのは、今日という日付ではなく、今日入れた修正です。

同じ記事の公開日と更新日の役割を、本と2つのカレンダーで分けた図

この記事が気に入ったら
いいねしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次