404エラーとリダイレクトの違い|ページ削除・URL変更時の対処

SEO・集客
404 ERROR & REDIRECT GUIDE

404エラーとリダイレクトの違い
ページ削除・URL変更時の対処

ホームページのページを削除したり、 URLを変更したりしたときは、 旧URLを404エラーのままにするか、 新しいURLへリダイレクトするかを判断する必要があります。 404は「このURLにページは存在しない」と伝えるHTTPステータスです。 リダイレクトは、ページが別のURLへ移動したことを 利用者と検索エンジンへ伝え、新しいページへ自動転送する仕組みです。 代わりとなるページがない削除URLは、 404または410を返すことが正しい対応です。 一方、同じ内容を新URLへ移した場合や、 複数ページを一つへ統合した場合は、 関連する移転先へ301リダイレクトを設定します。 すべての削除URLをトップページへ転送すると、 利用者が目的の情報を見つけられず、 Googleからソフト404と判断される可能性があります。 本記事では、404・410・301・302の違い、 状況別の判断基準、WordPressでの設定、 リダイレクトチェーンや一括転送の注意点、 Search Consoleでの確認方法まで解説します。

404エラー 301リダイレクト URL変更 ページ削除
404・410 代替ページがない
完全な削除

存在しないURLとして正しい4xxを返し、サイトマップや内部リンクから外します。

301・308 内容が新URLへ
永久に移動

旧URLと対応する新URLがある場合に、利用者とGoogleを新ページへ案内します。

302・307 一時的にだけ
別ページへ転送

元URLへ戻す予定がある、短期間のメンテナンスや提供停止などで使います。

SECTION 01

404はページが存在しない状態 リダイレクトは移転先へ案内する処理

URLがなくなったのか、別の場所へ移ったのかを正しいHTTPステータスで伝えます。

CORE DIFFERENCE 存在しないか
移動したか

404 Not Foundは、 リクエストされたURLに該当するページが存在しないことを示す HTTPステータスコードです。 以前あったページを完全に削除し、 同じ目的を満たす代替ページもない場合は、 404を返すことが自然な対応です。

リダイレクトは、 旧URLへアクセスした利用者や検索エンジンを 別のURLへ自動的に案内する処理です。 ページのURLを変更した場合、 サイトを別ドメインへ移した場合、 複数ページを一つへ統合した場合などに使います。

Googleは、301や308などの永続的リダイレクトを、 リダイレクト先を正規URLとして処理すべきことを示す 強いシグナルとして利用します。 404などの4xxを返すURLはインデックスされず、 既に登録されていた場合も徐々に検索インデックスから削除されます。

状態
利用者の動き
Googleへの意味
404 Not Found
404案内ページが表示される
URLにコンテンツが存在しないことを伝えます。
410 Gone
削除済みの案内が表示される
コンテンツがなくなったことを伝えます。Google検索では404と同様の4xxとして扱われます。
301・308
新URLへ自動転送
永続的な移転先を正規URLとして処理する強いシグナルになります。
302・307
一時的に別URLへ転送
元URLを今後も利用する可能性がある一時移動として扱われます。
404がSearch Consoleに表示されたからといって、 すべてが修正必須のエラーではありません。 削除済みで代替ページがないURLや、 入力ミスによって作られた存在しないURLは、 正しく404を返していれば問題のない状態です。
SECTION 02

同じ目的を満たす移転先があるかで 404と301を判断する

「検索評価がもったいないから」という理由だけで無関係なページへ転送しません。

状況
主な対応
判断理由
ページURLだけを変更した
新URLへ301
同じコンテンツが別の場所へ永久に移動したためです。
旧記事を新記事へ統合した
統合先へ301
旧ページの検索目的と内容を新ページが引き継いでいる場合に設定します。
商品・サービスを完全終了した
代替なしなら404・410
同等の商品・サービスや後継ページが存在しないためです。
後継サービスがある
関連性が高ければ301
対象者・内容・目的が近く、旧ページ利用者の次の選択肢になる場合です。
誤入力・存在したことがないURL
原則404のまま
頻繁な誤入力や誤リンクでなければ、転送を作る必要はありません。
よくあるスペルミス・旧表記
正しいURLへ301を検討
実際に利用者が間違えやすく、対応するページが明確な場合です。
一時的な在庫切れ・休止
ページ維持または一時転送
再開予定があるならURLを廃止せず、状況説明や302・307を検討します。
質問 01
コンテンツは別URLへ移ったか

ページ内容や検索目的がそのまま新URLへ移動したなら、 旧URLから新URLへ301を設定します。

質問 02
関連性の高い後継ページがあるか

旧ページを訪れた人が、 転送先を見て「探していた内容の続き」と理解できるかを確認します。

質問 03
元URLへ戻す予定があるか

一時的な休止なら302・307やページ維持、 永久に戻さないなら301・404を検討します。

質問 04
トップページ転送で解決するか

多くの場合は解決しません。 元ページと無関係なトップへの一括転送は避けます。

301の転送先は、 旧URLと内容・目的が最も近いページを選びます。 関連ページがない場合は無理にトップページやカテゴリ一覧へ送らず、 404・410を返して、見やすい404ページからサイト内検索や主要ページを案内しましょう。
SECTION 03

永久移動には301・308 一時移動には302・307を使う

可能な限りサーバー側のリダイレクトを利用し、最終URLへ直接転送します。

PERMANENT 301・308
永久的な移動

URL変更、サイト移転、ページ統合など、 元URLへ戻す予定がない場合に使用します。

Googleは転送先を処理すべきことを示す強いシグナルとして利用します。
TEMPORARY 302・307
一時的な移動

メンテナンス、短期間の提供停止、 キャンペーン切替など、元URLへ戻す予定がある場合に使います。

検索結果には元URLを残したい意図を伝える方法です。
CLIENT SIDE meta・JavaScript
代替手段

サーバー側の設定ができない場合に、 meta refreshやJavaScriptで転送する方法です。

Googleはサーバー側を最も確実な方法として推奨しています。
01
旧URLと新URLの対応表を作る

どの旧ページを、どの新ページへ移すのかを 一対一で整理します。

対応
02
サーバー側で301を設定する

Apache、NGINX、レンタルサーバー、 CMSなど環境に合う方法で永久転送します。

実装
03
最終ページへ直接転送する

旧URLから中間URLを何度も経由せず、 現在の正規URLへ一回で転送します。

短縮
04
内部リンクを新URLへ更新する

リダイレクトへ頼り続けず、 メニュー、本文、ボタン、パンくずを直接新URLへ変更します。

更新
05
リダイレクトを長期間維持する

Googleはサイト移転時のリダイレクトを 一般的に1年以上保持するよう案内しています。

維持
06
利用者と検索状況を監視する

旧URLへのアクセス、転送エラー、 新URLのインデックス、検索流入を確認します。

監視
リダイレクトチェーン

旧Aから旧B、旧Bから新Cのような連鎖を避け、 旧A・旧Bの両方から新Cへ直接転送します。

リダイレクトループ

AからB、BからAへ戻る設定や、 HTTPS・wwwのルール競合を防ぎます。

トップページへの一括転送

関連性の低い多数の旧URLをトップへ送ると、 ソフト404と判断される可能性があります。

一時移動に301を使う

元URLへ戻す予定があるなら、 ページ維持または302・307が適しています。

転送先も404・noindex

最終URLが正常に200表示され、 検索へ出したい状態か確認します。

JavaScriptだけに依存

サーバー側の転送が可能なら、 より確実な301・308を優先します。

Googlebotは複数のリダイレクトをたどれますが、 Google公式は最終URLへ直接転送することを推奨しています。 長いチェーンは表示の遅延や設定ミスを増やすため、 サイト改修時に古い転送ルールも整理しましょう。
SECTION 04

削除URLは正しい404・410を返し 案内用404ページで次の行動を示す

見た目が404でもHTTP 200を返すページや、無関係なページへの転送に注意します。

CORRECT RESPONSE 見た目だけでなく
HTTP 404・410

削除済みページに代替コンテンツがない場合は、 サーバーがHTTP 404または410を返すようにします。 Google検索では、404と410はいずれも コンテンツが存在しない4xxとして扱われ、 既に登録されているURLは徐々にインデックスから削除されます。

404ページは、利用者にとって行き止まりにならないよう、 「ページが見つかりません」と明確に伝えたうえで、 トップページ、主要サービス、サイト内検索、 問い合わせなどへのリンクを用意します。 ただし、案内ページを表示しながらHTTP 200を返すと、 検索エンジンには正常なコンテンツに見えるため注意が必要です。

存在しないURLをすべてトップページへ301転送したり、 内容のない「ページはありません」という画面を200で返したりすると、 Googleがソフト404と判断する可能性があります。 ソフト404はHTTP上は成功や転送でも、 実質的には有用なコンテンツが存在しない状態です。

状態
適切か
改善方向
削除ページがHTTP 404を返す
適切
内部リンクとサイトマップから削除し、404画面の案内を整えます。
削除ページがHTTP 410を返す
適切
完全削除を明示したい場合に利用できます。Googleでは404と同様に処理されます。
404の見た目でHTTP 200
不適切
テーマやアプリのレスポンスを修正し、正しい4xxを返します。
全削除URLをトップへ301
原則不適切
関連する移転先があるURLだけ個別転送し、ほかは404・410にします。
404をrobots.txtでブロック
不要
Googlebotが4xxを確認できる状態にし、自然に処理させます。
404ページへ検索フォームや人気ページへのリンクを設置しても、 HTTPステータスまで200へ変更してはいけません。 利用者向けの案内画面と、 検索エンジン・ブラウザへ返すHTTPステータスは別の役割です。
SECTION 05

WordPressでは変更内容を記録し 必要な旧URLだけ個別に転送する

プラグイン・サーバー設定・テーマのうち、管理しやすい一つの方法を中心に運用します。

01
変更前のURLを記録する

スラッグ変更、ページ統合、削除の前に、 現在公開されている完全なURLを保存します。

記録
02
新URLまたは削除方針を決める

同一内容の移転先があるか、 統合先があるか、代替なしで終了かを判断します。

判断
03
301を設定する

サーバー管理画面、リダイレクトプラグイン、 .htaccessなど、環境に合う方法で設定します。

転送
04
404テンプレートを確認する

代替なしのURLでは、 WordPressテーマの404.phpなどから適切な案内を表示します。

案内
05
キャッシュを削除して動作確認する

ブラウザ、WordPress、サーバー、 CDNのキャッシュを更新し、古い応答が残らないようにします。

反映
06
転送ルールを台帳管理する

旧URL、新URL、設定日、理由、担当者、 動作確認日を一覧に残します。

管理
WordPressでの変更
確認事項
主な対応
投稿・固定ページのスラッグ変更
旧URLの流入・リンク
旧スラッグから新スラッグへ301を設定します。
複数記事を一記事へ統合
統合先との関連性
各旧記事から統合後の記事へ個別に301を設定します。
古いお知らせを削除
今後も必要な情報か
代替なしなら404。情報を残す価値があるなら内容更新やアーカイブを検討します。
サービスページを廃止
後継サービスの有無
関連性が高い後継があれば301、なければ404・410にします。
カテゴリ・パーマリンク変更
多数URLへの影響
全URLの対応表を作り、チェーンや404が発生しないよう一括検証します。
WordPressのプラグインを使う場合も、 追加したリダイレクトの目的と転送先を記録してください。 複数のプラグイン、.htaccess、サーバー機能へ同じルールを重複設定すると、 ループや予期しない転送が起こりやすくなります。
SECTION 06

URL対応表を作り 転送・内部リンク・サイトマップを同時に更新する

リダイレクトだけ設定して、サイト内に旧URLを残し続けないようにします。

01
変更対象URLを収集する

XMLサイトマップ、Search Console、 アクセス解析、内部リンク、外部リンクから旧URLを集めます。

収集
02
流入・リンク・問い合わせ実績を確認する

重要度の高いURLを優先し、 削除による利用者と集客への影響を把握します。

評価
03
新URL・統合先・404を決める

各旧URLについて、 301、302・307、404・410、ページ維持のどれかを決定します。

方針
04
転送とHTTPステータスを実装する

一対一の転送を設定し、 404対象は正しい4xxを返すようにします。

実装
05
サイト内の参照先を更新する

内部リンク、canonical、パンくず、 構造化データ、ナビゲーション、QRコードを新URLへ変更します。

統一
06
新サイトマップを送信し監視する

XMLサイトマップから旧URLを外し、 Search Consoleで転送・404・新URLの登録状況を確認します。

監視
更新対象
変更内容
確認理由
内部リンク
旧URLから新URLへ直接変更
毎回リダイレクトを経由せず、利用者とGoogleを直接案内します。
XMLサイトマップ
新URLだけを掲載
転送元・404 URLを検索登録候補として送信しないためです。
canonical
新URLの自己参照へ変更
旧URLやテストURLを正規として指定する矛盾を防ぎます。
外部プロフィール・広告
主要リンクを新URLへ変更
表示速度と利用者体験を改善し、転送への依存を減らします。
404ページ
主要ページ・検索・問い合わせを案内
削除ページを訪れた利用者がサイトを離れる前に次の選択肢を示します。
URL変更時は、一括で実施できる範囲をまとめて変更し、 旧URL・新URL・転送先が混在する期間を短くします。 大規模な変更では、実装前にバックアップとテスト環境での検証を行いましょう。
SECTION 07

Search Consoleと実際のHTTP応答で 転送・404・新URLの状態を確認する

Search Consoleの件数だけでなく、意図したURLが正しく処理されているかを確認します。

01
旧URLをブラウザ・確認ツールで開く

301・302・404・410など、 実際に返っているHTTPステータスを確認します。

応答
02
旧URLをURL検査する

Search Consoleで、 「リダイレクトのあるページ」「見つかりませんでした」などの状態を確認します。

旧URL
03
新URLのインデックス状態を見る

正常に200表示され、 index可能で、正しいcanonicalを持つか確認します。

新URL
04
ページのインデックス登録レポートを確認する

404、ソフト404、リダイレクトエラー、 リダイレクトのあるページの増減を見ます。

全体
05
サイトマップとリンク切れを再確認する

旧URLがサイトマップや内部リンクに残っている場合は修正します。

参照
06
一定期間後に再検査する

Googleの再クロールとインデックス更新には時間がかかるため、 クロール日時を見ながら追跡します。

追跡
削除URLと移転URLを分けて一覧化した
代替ページがないURLは404・410にした
同一内容の移転先があるURLへ301を設定した
一時移動と永久移動を区別した
無関係なトップページへ一括転送していない
旧URLと新URLの対応表を保存した
転送先がHTTP 200で正常表示される
転送先にnoindexが設定されていない
リダイレクトチェーン・ループがない
内部リンクを新URLへ直接変更した
XMLサイトマップから旧URLを削除した
canonicalを新URLへ更新した
404画面が正しいHTTP 404を返している
404画面に主要ページへの案内がある
Search Consoleで旧URLと新URLを検査した
リダイレクトを長期間維持する計画がある
Search Consoleの「見つかりませんでした(404)」は、 代替のない削除URLなら正常な除外理由です。 修正すべきなのは、 サイト内からリンクしている404、 サイトマップに掲載した404、 本来は移転先があるのに転送されていない404、 正常なページが誤って404になるケースです。
URL CHANGE MANAGEMENT

ページ削除とURL変更を整理し 利用者と検索エンジンを正しい場所へ案内する

404・転送・内部リンク・サイトマップを一つの作業として管理しましょう。

URL変更の基本 判断から確認まで
4段階
収集・判断・実装・監視

合わせて確認したい内容

  • サイト内のリンク切れ
  • 404・410とカスタム404ページ
  • 301・308の永久リダイレクト
  • 302・307の一時リダイレクト
  • リダイレクトチェーン・ループ
  • 内部リンク・canonical・サイトマップ
  • WordPressのスラッグ・パーマリンク変更
  • Search ConsoleのURL検査

※リダイレクトの設定によって、 旧ページの検索順位、アクセス数、リンク評価が 必ずそのまま移行することを保証するものではありません。 関連性の高い移転先を選び、 新ページの内容・内部リンク・公開状態も整えてください。

リンク切れの確認方法を見る →
移転先があるなら301
代替がない完全削除なら404でよい

404エラーは、代替ページのない削除URLに必要な正常な応答です。 URL変更やページ統合など、 同じ目的を引き継ぐ新ページがある場合は301リダイレクトを設定します。 すべてをトップページへ転送せず、 旧URLと最も関連する移転先を個別に選びましょう。 内部リンク、XMLサイトマップ、canonical、 WordPressの設定、Search Consoleまで確認し、 利用者が迷わないURL変更を行うことが重要です。

404・HTTPステータス・リダイレクトについて

本記事は、2026年7月時点で公開されている Google検索セントラルおよびSearch Consoleの公式情報を参考に作成しています。 Googleのクロール・インデックス処理、 Search Consoleの表示、WordPress・サーバーの設定方法は 変更される場合があります。 最新の公式情報と実際のHTTPレスポンスを確認しながら対応してください。