検索ブランド相談室 | 検索と評判の専門メディア

サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準

部署:マーケティング担当者レベル:実践SEOWebサイト改善、Web集客
サービス終了ページを200、noindex、301、404・410のどれで処理するか検討するイメージ

サービスを終了したからといって、そのページをすぐ削除すればよいとは限りません。旧サービス名で検索する人には、終了理由や問い合わせ先を伝える必要が残っていることがあります。ほぼ同じ役割を引き継ぐ後継サービスがあるなら、そこへ案内したほうがよい場合もあります。

判断の軸は、過去のSEO評価を残せるかどうかだけではありません。先に確かめるのは、「旧ページを訪れた人に、今も提供すべき情報があるか」と「同じ目的を満たす明確な移転先があるか」の2点です。

この記事では、サービス終了ページの処理を「残す」「残して検索から外す」「301で転送する」「404/410にする」の4パターンに分け、選び方の基準から、内部リンクやサイトマップ、Search Consoleでの確認まで、実務の手順として整理します。読み終えると、自社の終了ページをURLごとにどのパターンにするか、順を追って決められるようになります。

クロール・インデックス・リダイレクトなど技術面の全体像を先に確認したい場合は、テクニカルSEOの実務チェックリストを確認してください。

結論:サービス終了ページは4パターンで判断する

サービス終了後のURLは、ページに残る役割と移転先の有無によって、次の4つの処理に分けて考えると判断しやすくなります。表では、状況ごとの基本処理、HTTPステータス、Google検索での扱いを並べています。

状況 基本的な処理 HTTPステータス Google検索での扱い 向いているケース
終了後も案内する情報がある ページを残す 200 検索表示を継続できる 終了告知、サポート、移行案内などを探す人がいる
ページは必要だが検索結果には出したくない ページを残してnoindex 200 クロール後に検索結果から除外 既存顧客向け案内など、直接アクセスには残したい
同じ目的を引き継ぐ後継ページがある 301リダイレクト 301 転送先を恒久的な移転先として扱う 後継サービスや統合先が明確
代替先も案内する情報もなくなった URLを廃止 404または410 インデックスから外れていく 完全終了し、残す役割がない

表に出てくる用語を先に整理します。noindexは、ページを検索結果に表示しないよう検索エンジンへ伝える指定で、ページ自体は公開したままなので、URLを直接開いた人には見えます。301は旧URLから新URLへ恒久的に転送する設定、404と410は、ページが見つからない、または削除されたことを返す設定です。クロールは、検索エンジンがページを巡回して内容を取得することを指します。

Googleは、削除したページに明確な代替ページがある場合は301リダイレクトを、代替がない場合は404または410を返すよう案内しています。

ここで避けたいのは、「終了ページはすべて301にする」「SEO評価があるページは残す」と一律に決めることです。利用者が何を知る必要があるのか、移転先が本当に同じ役割を担っているのかを確認してから、処理を選びます。

サービス終了ページを案内情報と後継ページの有無から200、noindex、301、404・410に分類する判断フロー

図は、判断の順番を示しています。まず利用者へ残す情報があるかを確認し、次に同じ目的の後継ページがあるかを確認すると、処理を決めやすくなります。

まず確認するのは、利用者に残す情報があるかどうか

処理に迷ったときは、検索順位や被リンクより先に、「そのURLを今後訪れる人が何を知りたいか」を確認します。

サービスを終了しても、旧サービス名で検索する人がすぐにゼロになるとは限りません。既存顧客であれば、終了日、サポート期限、データの扱い、後継サービス、問い合わせ先などを探すことがあります。新規の利用検討者が、古い比較記事やブックマーク、外部サイトのリンクからアクセスする場合もあります。

こうした情報が必要な期間は、ページ自体に役割が残っています。その役割の残り方によって、次のように処理の選び方が分かれます。

終了後も案内が必要ならページを残す

次のような情報を確認する人がいる場合は、サービス終了と同時にURLを消すより、終了ページとして残すほうが利用者にとって分かりやすくなります。

  • サービスがいつ終了したのか
  • 現在は申し込めないのか
  • 既存契約はどうなるのか
  • サポートをいつまで受けられるのか
  • 後継サービスや代替手段はあるのか
  • 問い合わせ先はどこか

残す場合は、元の商品紹介文をそのまま置くのではなく、「終了済み」であることをページ上部ではっきり示し、現在必要な情報に更新します。

明確な後継サービスがあるなら301を検討する

旧サービスと後継サービスの目的や対象がほぼ同じで、旧ページを訪れた人がそのまま後継サービスを利用できるのであれば、301リダイレクトが有力です。Googleも、ページが移動した場合や明確な置き換え先がある場合には、恒久的なサーバー側リダイレクトとして301や308を利用できると説明しています。

ただし、「評価を渡したいから」という理由だけで、トップページや関係の薄いサービスページへ転送するのは避けます。転送先は、旧URLを訪れた人の目的を実質的に引き継いでいる必要があります。

役割がなくなれば404または410にする

後継サービスがなく、終了案内やサポート情報を掲載し続ける必要もなくなったURLは、404または410にできます。先ほど触れたとおり、Googleは削除したコンテンツに代替ページがない場合、404または410を返すことを案内しており、無関係なページへリダイレクトする必要はありません。

サービス終了の時期に合わせて処理を変える

サービス終了は一日で終わる作業ではありません。「終了前」「終了直後」「後継サービスへの移行」「案内の役割が終わった後」という時間軸で考えると、各時期にどの処理が合うかを整理しやすくなります。表の最後の行だけは時期を問わず、ページは残すが検索流入は不要な場合の処理です。

時期 ページの主な役割 処理例
終了予定の告知期間 利用者へ終了日や今後の対応を知らせる 200で公開を継続
終了直後 既存顧客や検索利用者を案内する 200で終了案内を掲載
後継サービスへの移行が定着 同じ目的のページへ案内する 条件が合えば301
案内・サポートの必要がなくなった後 URLとしての役割を終了する 404または410
ページは残すが検索流入は不要 直接アクセス用に維持する 200+noindex

サービス終了前の告知から終了直後、後継ページへの移行、URL廃止までの処理を示した時系列図

図は、告知から終了直後、後継ページへの移行、URL廃止までの流れを示しています。処理を切り替える時期は一律に決めず、告知やサポートなど、ページにまだ残っている役割に合わせて変えます。

期間も「3か月」「1年」と一律に決めるのではなく、契約状況、サポート期間、旧サービス名での問い合わせ、外部サイトからのアクセスなどを見て決めます。特に既存顧客がいるサービスでは、検索エンジン向けの処理だけで終了時期を決めないようにしましょう。

301は明確な移転先がある場合に使う

301リダイレクトを選ぶ基準は、「旧ページにSEO評価があるか」ではなく、「ページの役割が恒久的に別URLへ移ったか」です。

たとえば、次のケースは301を検討しやすい状況です。

  • 旧サービスが名称変更して新サービスへ移行した
  • 複数サービスを1つへ統合し、機能や対象顧客を引き継いだ
  • サービスページのURLだけを変更した
  • 後継サービスが旧サービスとほぼ同じ課題を解決する

一方、旧サービスとは対象や機能が大きく異なる商品を「代替サービス」と呼んでいるだけなら、自動的に301へ転送する必要はありません。その場合は、終了ページを一定期間残し、「このサービスは終了しました。現在は○○を提供しています」と案内したほうが、利用者が状況を理解しやすいこともあります。

旧サービスページから同じ目的の後継サービスへ301する場合と、関係の薄いページへ転送する場合を比較した図

図のように、301は「似たページがあるから」ではなく、旧ページを訪れた人の目的を転送先が引き継げるかで判断します。

Googleは恒久的なリダイレクトについて、検索結果では最終的な転送先を表示する方向で処理すると説明しています。このため、転送先が旧URLを探した人の目的に合っているかどうかが、そのまま利用者の体験を左右すると考えます。

404と410はSEO差ではなくURLの状態で選ぶ

404と410には、HTTP上の意味の違いがあります。違いを押さえたうえで、SEO上の差ではなく、URLの状態に合わせて選びます。

RFC 9110では、404は「現在そのリソースを見つけられない」状態で、恒久的かどうかまでは示しません。一方、410は「意図的に削除され、恒久的に利用できない可能性が高い」ことを示すステータスです。

ただし、Google検索では「410にすれば404よりSEO上有利」「410なら必ず早く消える」といった使い分けを前提にしない方が安全です。Googleは429を除く4xx系レスポンスについて、検索インデックスから除外する方向で扱うと説明しています。

実務では次のように整理できます。

  • 完全に廃止したことを明確に表現したい:410
  • 削除済みだが恒久性まで厳密に管理しない:404
  • SEO効果の差だけを期待して404と410を使い分けない

404・soft 404をURLごとに原因分類し、維持・復旧・リダイレクト・リンク修正まで判断する場合は、404・soft 404のSEO監査方法を確認してください。

検索には出したくないページはnoindexで残せる

「既存顧客にはページを見せたいが、新規の検索結果には出したくない」というケースでは、ページを200で残したままnoindexを指定する方法があります。

Googleのnoindexは、ページへのアクセス自体を止めるものではありません。Googleがページをクロールしてnoindexを確認すると、そのページを検索結果へ表示しないよう処理します。GoogleのクローラーであるGooglebotがnoindexを確認できるよう、robots.txtでクロール自体を遮断しないことも必要です。

たとえば次のような場合に検討できます。

  • 既存顧客向けの終了案内としてURLを残す
  • メールや管理画面から案内ページへ誘導する
  • 問い合わせ対応のため、過去サービスの情報を参照できる状態にする
  • 新規のサービス比較では検索結果に出したくない

「残すか削除するか」の二択ではなく、「利用者には残すが検索表示は止める」という選択肢も持っておくと、終了ページを整理しやすくなります。

内部リンクとサイトマップも同時に整理する

HTTPステータスだけ変更しても、サイト内の導線が古いままでは運用は完了しません。終了URLごとに、少なくとも次の項目を確認します。表では、処理のパターンごとに、各項目で必要な対応をまとめています。

確認項目 200で残す 301 404/410
サイト内リンク 終了済みと分かる文脈に変更 転送先URLへ直接変更 リンクを削除または代替先へ変更
グローバルナビ 原則見直す 新ページへ変更 削除
XMLサイトマップ 検索表示させる場合のみ掲載を検討 元URLは除外 除外
canonical ページ内容に合う指定を確認 転送先側を確認 不要
構造化データ 終了後の内容と矛盾しないよう見直す 転送先で確認 元URLでは不要

Googleは、サイトマップにはGoogle検索結果へ表示したい正規URLを記載するよう案内しています。そのため、301の転送元や404/410になったURLをサイトマップへ残し続けず、現在公開したいURLへ整理します。

内部リンクも同様です。301が正しく動いていても、サイト内のリンクを古いURLのまま放置するより、可能な箇所は最終的なURLへ直接更新したほうが、サイト構造を管理しやすくなります。

Search Consoleで処理後の状態を確認する

設定後は、Google Search ConsoleのURL検査やページのインデックス登録状況を使い、意図した処理になっているか確認します。インデックス登録とは、検索エンジンにページ情報が登録されることです。

サービス終了URLの処理後にHTTPステータス、内部リンク、サイトマップ、Search Consoleを順番に確認するフロー

図のとおり、HTTPステータス、内部リンク、サイトマップ、Search Consoleの順に見ていくと、検索エンジンが意図した状態を認識しているかを漏れなく確認できます。

確認したいポイントは次のとおりです。

  • 301が想定したページへ転送されているか
  • 404/410が200として返っていないか
  • noindexページをGoogleが認識できているか
  • 削除済みURLがXMLサイトマップへ残っていないか
  • 新しい後継ページがクロール・インデックス可能か

検索結果から急いで一時的に隠したい場合は、Search Consoleの削除ツールも利用できます。ただし、Googleはこの機能を恒久的な削除方法ではなく、一時的な非表示手段として案内しています。恒久的に処理する場合は、404/410やnoindexなどURL側の対応も必要です。

迷いやすいケースはどう判断するか

実際の運用では、判断に迷うケースが出てきます。表に、ケースごとの考え方をまとめました。

ケース 推奨する考え方
サービス名だけ変わり、内容はほぼ同じ 新サービスへ301を検討
後継サービスはあるが対象顧客や機能が異なる 終了案内を残し、後継サービスを選択肢として紹介
完全終了し、代替サービスもない 案内期間終了後に404/410を検討
終了後も既存顧客の問い合わせが続く 200で終了案内を残す
ページは参照用に必要だが検索流入は不要 200+noindexを検討
一時的な販売停止・休止 恒久終了として301や410にしない
トップページしか転送先がない 無理に301せず、終了案内または404/410を検討

「似ているページが存在する」というだけで301を選ぶのではなく、旧サービスを探した人にとって、そのページが本当に次の行き先になるかを確認します。表でも、後継サービスの対象や機能が異なる場合や、トップページしか転送先がない場合は、301を避ける方向の判断になっています。

サービス終了URLのチェックリスト

サービス終了時は、URL単位で次の項目を確認すると、判断漏れを防ぎやすくなります。

  • サービス終了日が確定している
  • 既存顧客向けに残す情報を整理した
  • サポートや問い合わせがいつまで必要か確認した
  • 同じ目的を満たす明確な後継ページがあるか確認した
  • 200・noindex・301・404/410のどれにするか決めた
  • サイト内の古いリンクを確認した
  • グローバルナビや一覧ページからの導線を確認した
  • XMLサイトマップを更新した
  • canonicalや構造化データとの矛盾を確認した
  • 処理後にSearch Consoleで状態を確認した
  • 外部サイトや広告など、旧URLへの主な流入元を把握した
  • 後継サービスへ誘導する場合、利用者の目的が本当に一致しているか確認した

複数の終了URLがある場合は、URL、サービス終了日、後継ページ、残す案内、HTTPステータス、内部リンク、サイトマップ対応を一覧にすると、担当者ごとの判断差を減らせます。

まとめ:役割の有無から順に判断する

サービス終了ページは、終了したという理由だけで一律に削除するものではありません。次の順に考えると整理できます。

  1. 終了後も利用者へ知らせる情報があるなら、200で残す
  2. ページは必要でも検索結果へ出す必要がなければ、noindexを指定する
  3. 同じ目的を満たす後継ページがあるなら、301で転送する
  4. 代替先も案内する役割もなくなったら、404または410にする

特に避けたいのは、過去のSEO評価を残すためだけに、無関係なページへ301転送することです。旧サービスを検索した人が次に何を知る必要があるかを基準に、ページの役割を決めてください。

そのうえで、内部リンク、XMLサイトマップ、canonical、Search Consoleまで一緒に整理すれば、終了したURLがサイト内に残り続ける状態も防ぎやすくなります。

最初の一歩は、対象URLごとに「残す情報」「後継ページの有無」「HTTPステータス」「内部リンク」「サイトマップ」の対応を一覧にすることです。複数URLの判断を社内で統一したい場合にも、この一覧が共通の基準になります。

参考文献・データ元

この記事で参照した情報を確認できます。

Redirects and Google Search|Google Search Central
恒久的・一時的リダイレクトとGoogle検索での扱いを確認。2026年4月14日更新。
Google Search Central「Redirects and Google Search」

Troubleshoot Google Search Crawling Errors|Google Search Central
削除ページに代替がある場合の301、代替がない場合の404/410に関する公式案内を確認。2025年12月18日更新。
Google Search Central「Troubleshoot Google Search Crawling Errors」

Build and submit a sitemap|Google Search Central
サイトマップに掲載するURLの考え方を確認。2026年7月8日更新。
Google Search Central「Build and submit a sitemap」

Block Search indexing with noindex|Google Search Central
noindexの動作とクロール条件を確認。2025年12月10日更新。
Google Search Central「Block Search indexing with noindex」

Removals and SafeSearch reports tool|Google Search Console Help
検索結果からの一時的な非表示と、恒久的な削除には追加対応が必要であることを確認。
Google Search Console Help「Removals and SafeSearch reports tool」

RFC 9110: HTTP Semantics|IETF
301、404、410のHTTP上の定義を確認。2022年6月公開。
RFC 9110「HTTP Semantics」

‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

関連記事

関連テーマ