古いブログ記事は削除する？更新・統合・非公開を分けるコンテンツ整理

古いブログ記事は、公開から年数がたったという理由だけで削除する必要はありません。アクセスがほとんどない記事も同じです。まず確認したいのは、そのURLが今も誰かの疑問に答えているか、事業に必要な情報を担っているか、検索結果や外部サイトからたどられているか、そして役割を引き継げる別ページがあるかです。

判断は「残すか、消すか」の二択ではありません。内容が今も正確なら維持し、需要やURLの蓄積を活かせるなら更新します。似た目的の記事が複数あるなら統合し、利用者には残したいが検索結果へ出す必要がないページはnoindexを検討します。役割も代替先もなく、誤解を招くなら削除します。この記事では、長くブログを運用してきた中小企業が、記事ごとの判断理由を説明できる状態まで整理する順番を示します。

古い記事の整理で最初に決めるのは、残す・消すではなく「今の役割」

記事一覧を開き、公開年の古い順やアクセスの少ない順に削除候補へ入れると、必要なURLまで巻き込みやすくなります。古い記事の整理は、各ページが現在担っている役割を言葉にするところから始めます。公開時の企画意図ではなく、今の読者と事業にとっての役割です。

たとえば、月間の閲覧が少なくても、既存顧客へ案内する手順書、営業担当が商談後に送る補足記事、採用候補者が企業理解のために読む記事なら、検索流入だけでは価値を測れません。反対に、アクセスが残っていても、終了したサービスや古い料金、現在とは異なる手順を案内している記事は、読者を誤らせる可能性があります。閲覧数の多寡と、残すべきかどうかは別の問いです。

まず各URLを、少なくとも次の四つの役割から見ます。複数に当てはまって構いません。

役割	確認すること	判断への影響
検索から新しい読者へ答える	今も検索される疑問か、表示される検索語と本文が合っているか	需要があり内容を直せるなら更新候補
事業やサービスの理解を助ける	現在の提供内容と矛盾せず、相談・比較の前提を説明しているか	流入が少なくても維持または更新候補
既存顧客・社内向けの案内になる	メール、営業資料、マニュアル、他ページから参照されているか	検索表示が不要ならnoindexも選択肢
過去の記録として残す	終了情報であることが明示され、現在情報への導線があるか	アーカイブとして維持、または検索対象外を検討

役割を一文で書けない記事は、すぐ削除するのではなく「何のために公開されているか不明」と記録します。その後、検索データ、内部リンク、外部リンク、内容の正確性、近いページを確認してから処置を決めます。ここで役割を先に置くと、数字だけで機械的に削ることも、念のため全部残して整理を先送りすることも避けやすくなります。

棚卸し表は、URL・読者・事業との接点を一行に置く

棚卸しはタイトルの一覧だけでは足りません。同じタイトルでも内容や役割が変わっていることがあり、CMSの管理画面では公開ページの表示崩れ、古い導線、リンク切れに気づきにくいためです。スプレッドシートなどにURLを一行ずつ置き、公開ページを実際に開きながら記録します。

最低限、URL、記事タイトル、公開日、最終更新日、想定読者、今の役割、現在の事業との接点、情報の正確性、近い内容のURL、検索表示、アクセス、内部リンク、外部リンク、仮の処置、判断理由を並べます。担当者や確認期限も加えると、専門部署への事実確認が必要な記事を止めずに進められます。

この段階で大切なのは、数値がない欄をゼロとみなさないことです。計測を始める前に公開した記事、URL変更でデータが分断された記事、計測タグが入っていないページ、外部から直接使われているページなどは、分析画面だけでは利用実態が見えません。「0」と「未確認」を分け、未確認は何を見れば確かめられるかまで書きます。

公開ページでは、本文だけでなく次も確認します。タイトルと本文の約束が合っているか、ページが200番台の正常な状態で開くか、canonicalが意図したURLを指しているか、サイト内検索やカテゴリから到達できるか、本文中のリンク先が今も有効か、著者・更新日・監修情報が現在の運用に合っているかです。古い記事の問題は文章だけでなく、ページの置かれ方に表れることがあります。

一度に全記事を精読するのが難しい場合は、誤情報の影響が大きい分野、事業との接点が強い記事、検索表示が多い記事、似たURLが多いテーマから着手します。公開年の古さは、優先順位を補助する条件にはなりますが、処置を決める条件にはしません。

Search Console・GA4・被リンクは、同じ「人気」の数字として足さない

古い記事の判断では、Google Search Console（Search Console）、Google Analytics 4（GA4）、被リンクの確認が役立ちます。ただし、三つは見ているものが違います。数値を一つの点数へまとめると、何が弱く、何を残すべきかがかえって見えにくくなります。それぞれを別の証拠として読みます。

確認先	主に分かること	読み違えやすい点
Google Search Console	Google検索での表示回数、クリック、検索語、掲載ページの傾向	表示やクリックが少ないだけでは、需要がないのか、順位・タイトル・内容に問題があるのか分からない
GA4	計測できた閲覧、入口ページ、回遊、行動の傾向	未計測や同意設定、URL表記の違いがあると「利用なし」に見える。検索以外の利用価値も混ざる
内部リンク・外部リンク	サイト内での位置づけ、他サイトや資料から参照されている可能性	Search Consoleのリンクレポートは全件保証ではない。リンク元の質と文脈を確認する必要がある

Search Consoleでは、対象URLをページで絞り、どの検索語で表示されているかを見ます。クリックが少なくても表示が継続しているなら、タイトルの約束、検索意図とのずれ、順位、本文の不足を分けて考えられます。期間は直近だけでなく、前年同期間や季節性のある時期も比較します。イベント、制度、繁忙期にだけ使われる記事は、短い期間のゼロだけで判断できません。

GA4では「ページとスクリーン」だけでなく、入口として使われているかをランディングページでも確認します。検索からは少なくても、メール、SNS、営業資料、ブックマークから利用されている場合があります。反対に、閲覧があるから残すのではなく、読者が古い情報を読んで離脱していないか、次に必要なページへ進めているかも見ます。

被リンクは、削除前に必ず確認したい項目です。外部サイトから参照されているURLを消すと、相手のリンクが切れ、読者の到達経路も失われます。ただし、リンクが一つあるだけで永久に残す必要があるわけではありません。リンク元が何を根拠に紹介しているか、現在の別ページで同じ期待に答えられるかを確認し、明確な代替先があれば統合と301リダイレクトを検討します。

「表示ゼロ・閲覧ゼロ・リンクゼロ」は、削除の確定条件ではなく、追加確認の合図です。記事の役割、情報の正確性、サイト内での利用、近いページを確認して、初めて処置の候補が絞れます。

情報が古い記事は、アクセスの大小より誤解リスクを先に見る

古い記事の中でも、読者の行動や取引に直接影響する情報は優先して確認します。料金、仕様、申込条件、営業時間、対応地域、制度、法令、補助金、募集要項、セキュリティ手順、サポート期限などです。これらが現在と異なる場合、アクセスが少なくても誤解による損失が起こり得ます。

確認するときは「更新日を新しくする」だけで済ませません。本文中の条件、画像内の文字、表、PDF、構造化データ、ページタイトル、メタディスクリプション、内部リンク先まで同じ前提になっているかを見ます。古いスクリーンショットや資料が残っていれば、本文だけ直しても誤解は解消しません。

内容を更新できるなら、何が変わったかを把握したうえで現在の情報へ置き換えます。過去情報を残す必要がある場合は、冒頭で「現在は終了」「当時の記録」と明示し、現行ページへ案内します。正確性を確認できない記事は、確認が済むまで検索結果から外すことを検討できますが、noindexにすれば内容が安全になるわけではありません。URLを知っている人は閲覧できるため、機密情報や個人情報を隠す手段にはなりません。

更新不能で、誤解や不利益を生む内容なら、流入があることを理由に公開を続けない判断も必要です。検索から来た人が期待する情報を別ページで正確に提供できるなら統合し、代替できないなら削除します。アクセスの維持より、現在の読者へ正しい情報を返すことを優先します。

似た記事があるときは、キーワードではなく検索目的を比べる

同じ言葉を含む記事が複数あるだけで、すぐ「カニバリゼーション」と決める必要はありません。カニバリゼーションは、近い検索意図に対して複数URLが競い、どのページを主に見せたいのか不明瞭になる状態です。同じテーマでも、初心者向けの基礎、比較、手順、事例、トラブル対応など役割が分かれていれば、別URLで残す理由があります。

比較するときは、各記事について「誰が」「どの場面で」「何を決めるために」読むのかを書きます。Search Consoleで表示される検索語が重なるか、見出しが同じ問いへ答えているか、読後の行動が同じか、サイト内リンクがどちらへ集まっているかも見ます。タイトルの単語ではなく、回答の役割で主ページを選びます。

統合する場合は、検索表示やリンクが多い方を自動的に残すのではなく、今後も維持しやすく、検索意図へ最も直接答えられるURLを主ページにします。もう一方から独自の説明、図、事例、よく参照される箇所を移し、重複する文章は整理します。移行後は旧URLから内容が近い主ページへ301リダイレクトし、サイト内リンクも新しい行き先へ直します。

一方、検索目的が違う記事まで一つへ詰め込むと、長いだけで答えが探しにくいページになります。「似ている」ではなく「同じ問いに同じ答えを返している」かを統合条件にするのが安全です。

維持・更新・統合・noindex・削除をどう使い分けるか

棚卸しと確認が終わったら、各URLへ処置と理由をセットで記録します。処置名だけでは、後から別の担当者が見たときに判断を再現できません。次の表は、代表的な使い分けです。

処置	向いている状態	実施時の要点
維持	今も正確で、読者・事業・検索・参照のいずれかに明確な役割がある	無理に日付や文章を変えず、リンク切れや軽微な表示だけ直す。次回確認日を決める
更新	検索需要や利用目的があり、現在の情報へ直すことでURLを活かせる	検索意図、事実、構成、画像、内部リンクを必要な範囲で改める。更新日の変更だけで終えない
統合	同じ目的のページがあり、内容・リンク・検索表示を一つへ集めた方が分かりやすい	主URLを決め、独自要素を移し、旧URLを近いページへ301。内部リンクとサイトマップも更新する
noindex	利用者には公開URLとして残す理由があるが、検索結果へ出す必要がない	ページをクロール可能にしたままnoindexを設定する。robots.txtで遮断しない。機密保護には使わない
削除	役割がなく、内容を直す価値もなく、代替先もない。誤情報や不要情報として公開を続ける理由がない	バックアップと参照元を確認し、代替がなければ404または410を返す。関連リンク・サイトマップから外す

維持は「放置」と違う

維持を選んだ記事も、確認日と確認理由を残します。長く読める基礎解説は頻繁に書き換えなくてよい一方、リンク先や前提条件は変わります。年に一度など一律の周期ではなく、情報が変わりやすい度合いに合わせて次回確認を決めます。

更新は、元のURLが答えるべき問いを守る

更新時に検索語を増やそうとして対象を広げすぎると、元の読者が欲しい答えがぼやけます。表示されている検索語と記事の役割を確認し、古い事実の修正、足りない判断条件の追加、不要部分の削除を行います。別の検索目的まで扱う必要があるなら、統合ではなく別ページとの役割分担を検討します。

noindexは「とりあえず残す箱」にしない

noindexは、検索結果へ出さないための指示です。社内外でURLを共有する資料、過去イベントの記録、絞り込み結果など、公開状態で残す理由があるページに向きます。役割のない記事を判断せず大量にnoindexへ移すと、不要な更新対象だけが残ります。残す利用目的がなければ削除、近い代替先があれば統合の方が明確です。

削除は最後の手段だが、避け続けるものでもない

Google Search Centralは、内容を改善できる場合はまず改善し、削除は救済できないときの最後の手段として扱う考え方を示しています。ただし、誤情報で役割もなく、代替もない記事を「SEOが不安だから」と残し続ける必要はありません。削除前に利用経路と代替先を確認し、削除後の状態を正しく返すことが重要です。

統合・削除時の301・404・410・noindexを取り違えない

内容の判断が正しくても、実装を誤ると読者と検索エンジンへ違う意味を伝えてしまいます。処置を決めた担当者と、WordPressやサーバーを操作する担当者の間で、URLごとの最終状態を共有します。

• 301リダイレクト：旧ページと同じ目的を満たす明確な移行先があるときに使います。旧URLへのアクセスを新URLへ恒久的に送ります。関連が薄いページやトップページへ一律転送すると、読者の期待に答えられません。
• 404または410：代替ページがなく、URLを公開し続けないときに使います。どちらも「このURLの内容は提供されない」状態を伝えます。削除したのに200を返すエラーページは、ソフト404と判断されることがあります。
• noindex：ページは閲覧可能なまま、検索結果への掲載を望まないときに使います。Googleがnoindexを確認できるよう、robots.txtでクロールを止めないことが必要です。
• 一時的な検索結果からの非表示：緊急時にSearch Consoleの削除ツールを使う場合も、恒久対応ではありません。最終的には削除、更新、認証、noindexなど、ページ側の状態を整えます。

統合後は、旧URLの301設定だけで終えません。本文やメニュー、カテゴリ、パンくず、関連記事、XMLサイトマップなどから旧URLへ向くリンクを新URLへ直します。画像やPDFへ直接リンクされている場合も確認します。サイト内に旧URLが残ると、利用者とクローラーが不要な転送を繰り返すことになります。

削除したURLをサイトマップから外し、意図した404・410・301が返るかを実際に確認します。Search ConsoleのURL検査は、公開ページがGoogleからどう見えるかを確かめる補助になりますが、再クロールや反映の時期を保証するものではありません。実装直後の一回だけで判断せず、後日も状態を確認します。

実行は小さなまとまりで行い、変更前後を記録する

数百記事を一度に削除・統合すると、問題が起きても原因を特定しにくくなります。まず、同じテーマや同じ部門など、影響を追える小さなまとまりで実施します。各URLについて、変更前のタイトル、検索表示、クリック、閲覧、入口利用、主な内部リンク、外部リンク、処置、実施日、移行先、確認担当を記録します。

実施後は、検索結果の順位だけを見ません。Search Consoleで対象ページや移行先の表示・クリック・インデックス状況を確認し、GA4で入口と回遊の変化を見ます。サイト内検索、問い合わせ前の閲覧、営業資料からのアクセスなど、記事の役割に合わせた利用も確認します。統合先で必要な情報が見つけにくくなっていないか、古いURLへの内部リンクが残っていないか、404が想定外に増えていないかも見ます。

変化があっても、直前の処置だけが原因とは限りません。季節性、検索結果の変化、サイト全体の改修、計測設定、競合ページの更新などが重なるためです。「何日に、どのURLへ、何をしたか」を残しておくと、影響を比較しやすくなります。検索順位や流入の回復を保証する作業ではなく、不要な重複や誤情報を減らし、必要なページへ役割を集める運用として評価します。

更新・統合・noindexは、必要に応じて見直せるように原稿や設定の履歴を残します。削除も、公開を戻す前提ではなくてもバックアップを保管します。判断の根拠が誤っていた場合や、事業の再開で過去情報が必要になった場合に、ゼロから作り直さず検証できます。

最終判断メモは、一つの数値ではなく理由を残す

最終的に必要なのは、URLごとに「なぜこの処置か」を短く説明できる状態です。次の七つへ答えると、担当者が変わっても判断を追いやすくなります。

1. この記事は今、誰のどの疑問または業務に使われているか。
2. 本文、画像、リンク、条件は現在も正確か。誤解させる危険はないか。
3. Google検索でどの語に表示され、クリックの有無をどう解釈したか。
4. GA4で入口・閲覧・回遊が見えるか。未計測と利用ゼロを分けたか。
5. 内部リンク・外部リンク・資料から参照されていないか。
6. 同じ目的を担うページ、または内容を引き継げる代替ページがあるか。
7. 維持・更新・統合・noindex・削除のうち、読者へ最も自然な状態はどれか。

このメモで根拠が弱いURLは、削除候補ではなく追加確認候補です。事実確認ができない、計測がない、代替先の内容が足りないなど、判断を止めている理由を明示します。逆に、役割がなく、誤情報で、参照もなく、代替先もないと確認できたなら、古いという理由ではなく「公開を続ける理由がない」という根拠で削除できます。

サイト全体で何から改善するかを先に決めたい場合は、関連記事「中小企業が押さえておきたいSEOの優先順位：何から始める？」と分けて考えると整理しやすくなります。この記事で扱うのは、優先テーマが決まった後に、個々の古いURLをどの状態へ移すかという判断です。

古いブログ記事の整理は、ページ数を減らすこと自体が目的ではありません。必要な情報は見つけやすく保ち、古い誤情報と重複を減らし、検索とサイト内の導線を今の事業へ合わせる作業です。公開年やアクセスゼロを入口にはしても、それだけで結論を出さず、役割・正確性・検索表示・被リンク・重複・事業との接点・代替先をそろえてから処置を分けます。