Search Consoleに「見つかりませんでした（404）」や「ソフト404」と表示されても、すべてのURLをリダイレクトする必要はありません。まずは、そのURLが本来存在すべきか、内容が対応する移転先があるかを確認し、URLごとに処理を分けることが重要です。
404は、サーバーが「このURLのページは存在しない」と正しく伝えるHTTPステータスです。一方のソフト404は、200 OKなどを返しているにもかかわらず、Googleが実質的なエラーページや内容の乏しいページと判断した状態を指します。
この記事では、Search Consoleでの確認手順、404・410・301リダイレクト・ページ復活の選び方、ソフト404の主な原因、WordPressでの確認箇所、修正後の検証方法を解説します。
404エラーとソフト404の違い｜最初にURLごとの対応を決める
404とソフト404の違いは、404がサーバーから返されるHTTPステータスコードであるのに対し、ソフト404はGoogleがHTTP応答やページ内容を基に行う判定である点です。Search Consoleの表示だけで一律に修正せず、URLの実態に合う応答を返すことを優先してください。
| 状態 | 意味 | 基本的な対応 |
|---|---|---|
| 404 | 対象URLのページが見つからないことを返している | 削除済みで代替先がなければ、そのままで問題ありません |
| 410 | 対象URLのページが恒久的に削除されたことを返している | 今後も復活しないページで、代替先がない場合に検討します |
| ソフト404 | 200 OKなどを返す一方、Googleがエラーページまたは内容不足と判断している | HTTP応答、本文、レンダリング、リダイレクト先を確認します |
| 301リダイレクト | ページが恒久的に別URLへ移転したことを示す | 旧URLと内容的に対応する移転先がある場合だけ設定します |
404は「存在しない」と正しく伝えている状態
404 Not Foundは、削除済みのページや、そもそも存在しないURLに対して返す正常な応答です。Googleは、代替ページのない削除済みURLについて、404を返すこと自体は問題ではないと案内しています。外部サイトの古いリンク、URLの入力ミス、過去に削除した記事などにより、404が検出されることは珍しくありません。
優先して修正したいのは、自サイト内のリンクやXMLサイトマップに掲載しているURLが404になっているケースです。反対に、存在しないURLに外部サイトからアクセスされているだけで、対応するページもない場合は、無理に転送先を作る必要はありません。
出典：Google Search Console Help「404 (Page Not Found) errors」
ソフト404は成功応答とページ実態が一致していない状態
ソフト404は、URLへのアクセス時に200 OKのような成功ステータスを返しているにもかかわらず、画面には「ページが見つかりません」といったエラー文が表示される場合や、本文がほぼ空の場合に発生しやすい状態です。Googleは、ページの内容などから実質的なエラーページと判断したURLを、Search Consoleでソフト404として報告することがあります。
ただし、200 OKを返すページがすべてソフト404になるわけではありません。本来は有効なページでも、Googlebotが重要なJavaScriptや画像などを取得できず、空白に近い状態でレンダリングした場合、または目立つエラーメッセージが表示された場合には、ソフト404と判定される可能性があります。
出典：Google Search Central「Fix soft 404 errors」
Search Consoleで404・ソフト404のURLを確認する手順
Search Consoleでは、ページインデックス登録レポートで問題の傾向とURL例を確認し、URL検査ツールで個別URLの状態を調べます。レポートはGoogleがクロールした時点の情報であるため、表示だけで即座に設定変更しないことが大切です。
ページインデックス登録レポートで該当URLを確認する
Search Consoleで対象プロパティを開き、左メニューの「ページ」を選択します。「ページがインデックスに登録されなかった理由」から「見つかりませんでした（404）」または「ソフト404」を開くと、Googleが検出したURL例を確認できます。
URL一覧を見たら、次の観点で分類すると対応を判断しやすくなります。
- 自サイトの内部リンクから到達しているURLか
- XMLサイトマップに含まれているURLか
- 以前は公開していたが、意図して削除したURLか
- URL変更、カテゴリ変更、サイト移転などにより移転先があるURLか
- 存在したことのない誤記URL、または外部サイト由来のURLか
404のURLは、Googleがしばらく再クロールすることがあるため、設定を直してもレポート上の表示がすぐに消えるとは限りません。まずは現在のHTTP応答とページ内容を個別に確認しましょう。
出典：Google Search Console Help「Page indexing report」
URL検査とHTTPレスポンスの確認を分けて行う
URL検査ツールでは、Googleが最後にクロールした際に把握した情報と、「公開URLをテスト」で取得する現在の情報を確認できます。ソフト404を調査する場合は、ライブテスト後にテスト済みページの表示を確認し、Googlebotに空白ページやエラーメッセージが見えていないかを調べると有効です。
一方、実際にサーバーが返しているHTTPステータスは、Search Consoleの表示だけで断定しないでください。ブラウザの開発者ツール、HTTPヘッダー確認ツール、サーバーアクセスログ、ホスティングの管理画面などを用いて、対象URLが200・301・404・410のどれを返しているか確認します。
ブラウザで404用のデザインが表示されていても、HTTPステータスが200 OKなら、検索エンジンには正しい404として伝わりません。見た目とHTTP応答は別に確認する必要があります。
出典：Google Search Console Help「Inspect and troubleshoot a single page」
404・ソフト404の対処法｜URLごとの判断基準
404やソフト404への対応は、Search Console上の問題表示を消すことではなく、訪問者と検索エンジンにURLの正しい状態を伝えることが目的です。対象URLの経緯と代替先の有無から、次のように対応を選びます。
| URLの状況 | 推奨する対応 | あわせて確認する項目 |
|---|---|---|
| 誤って削除した、本来は公開すべきページ | ページを復活させる | 内部リンク、canonical、XMLサイトマップ、noindex |
| URL変更後、内容が対応する新ページがある | 旧URLから新URLへ301リダイレクト | 転送先の内容、リダイレクトループ、内部リンク |
| 削除済みで、内容の近い代替先がない | 404または410を返す | サイトマップや内部リンクから削除できているか |
| 存在しないURLで200 OKを返している | 404または410を返すよう修正 | テーマ、CMS、サーバー、CDNの設定 |
| 空に近い検索結果・一覧ページ | 内容を充実させるか、実態に応じた処理を検討 | レンダリング、JavaScript、表示条件 |
| 無関係なページへ転送している | 関連する移転先へ変更、または404・410へ変更 | トップページ・カテゴリページへの一律転送の有無 |
関連性の高い移転先がある場合は301リダイレクトする
記事URLの変更、後継商品の公開、サイト移転などで、旧ページと内容的に対応する新ページがある場合は、301リダイレクトを設定します。301は恒久的な移転を示すリダイレクトであり、Googleは恒久的なリダイレクトを移転先URLを正規URLとして扱うためのシグナルの一つとして利用します。
ただし、削除した記事をすべてトップページへ送る、終了した商品をすべて商品カテゴリへ送るといった無関係な一律リダイレクトは避けるべきです。訪問者は求める情報に到達できず、Googleにも適切な移転として理解されにくくなります。内容が対応しない場合は、404または410を返すほうが自然です。
出典：Google Search Central「Redirects and Google Search」
削除済みで代替先がない場合は404または410を返す
公開終了したキャンペーン、統合先のない古い記事、再販予定のない商品など、ページを削除し、内容の近い代替先もない場合は、404または410を返します。404は「見つからない」、410は「恒久的に削除された」ことを示す応答です。どちらを使うか以上に、存在しないページに200 OKを返さないことが重要です。
404ページは検索エンジン向けのコンテンツではなく、迷って訪問したユーザーを支援するためのページです。サイト内ナビゲーション、主要カテゴリ、サイト内検索などを設置すると、次に読むページを探しやすくなります。ただし、カスタム404ページを用意しても、HTTPステータスは404で返す必要があります。
出典：Google Search Central「Fix soft 404 errors」
誤削除・URL変更ならページを復活させるか正しいURLへ転送する
重要な記事や商品ページが誤って削除されていた場合は、まず元のURLでページを復活できるかを検討します。元URLを維持できない場合は、旧ページの内容や検索意図を引き継げる新URLへ301リダイレクトします。
単に似たカテゴリがあるだけでは、適切な転送先とはいえません。旧ページを訪れた人が必要な情報を得られるかを基準に判断してください。復活または移転後は、サイト内リンク、パンくずリスト、canonicalタグ、XMLサイトマップ、メニュー、関連記事リンクなどに旧URLが残っていないかも確認します。
ソフト404になりやすい原因と修正方法
ソフト404は、存在しないURLに成功応答を返す設定だけでなく、有効なページがGooglebotに正常表示されていない場合にも起こり得ます。HTTP応答・本文・リダイレクト先を順番に点検すると、原因を切り分けやすくなります。
存在しないURLや空のページが200 OKを返している
代表的な原因は、存在しないURLに対して404ページ風のテンプレートを表示しながら、サーバーが200 OKを返している設定です。また、検索結果が0件の内部検索ページ、投稿がないタグ・著者・絞り込み一覧、データベースエラーなどで本文が表示されないページも、内容によってはソフト404として扱われる可能性があります。
本当に存在しないURLなら、テーマや独自プログラムを修正し、404または410を返すようにします。有効なページなら、本文が出力されるか、JavaScript・CSS・画像などの重要なリソースをGooglebotが取得できるか、エラーメッセージが本文の大半を占めていないかを確認してください。
出典：Google Search Central「Fix soft 404 errors」
在庫切れ・終了済みページの扱いが実態と合っていない
在庫切れの商品、終了したイベント、募集を停止したサービスのページは、一律に削除すればよいわけではありません。再入荷予定、後継商品、代替プラン、仕様情報、サポート情報など、ユーザーにとって有益な情報が残る場合は、ページを維持して状況を明記する選択肢があります。
一方、再開予定がなく、情報も古く、対応する後継ページもない場合は、404または410が自然です。明確な後継商品や後継イベントがある場合のみ301リダイレクトを検討します。ページの実態と応答を一致させることが、ソフト404を防ぐ基本です。
無関係なページへのリダイレクトが設定されている
存在しないURLをトップページへ自動転送する設定は、WordPressテーマ、リダイレクト用プラグイン、サーバー設定、CDNのルールなどで意図せず入っていることがあります。しかし、訪問者が探していたページと転送先が無関係なら、ユーザーにとっても検索エンジンにとっても分かりにくい処理です。
リダイレクトは、旧URLと新URLの内容が対応する場合に限ります。対応するページがないなら、転送を外して404または410を返す設定に変更してください。
出典：Google Search Console Help「404 (Page Not Found) errors」
WordPressで確認したい404・リダイレクト設定の注意点
WordPressでは、管理画面の投稿状態だけでなく、テーマ、プラグイン、キャッシュ、CDN、サーバー設定が最終的なHTTP応答に影響します。画面のデザインではなく、実際に返るHTTPレスポンスを基準にすることが重要です。
カスタム404ページでもステータスコードが200になっていないか調べる
WordPressの404テンプレートをカスタマイズしている場合、見た目は404ページでも、独自コードやテーマの実装によって200 OKが返ることがあります。存在しないと分かるURLを実際に開き、開発者ツールやHTTPヘッダー確認ツールで404が返っているか調べましょう。
独自テーマや外部制作会社によるカスタマイズがある場合は、404テンプレートだけでなく、URLの振り分け処理、PHPのヘッダー送信、キャッシュ処理も確認対象になります。修正方法が不明な場合は、テーマ制作者やサーバー管理者に「存在しないURLで200ではなく404を返したい」と、目的と対象URLを添えて依頼すると伝わりやすくなります。
リダイレクト・キャッシュ・CDNの設定をまとめて点検する
リダイレクトは、WordPressプラグインだけで設定されるとは限りません。.htaccessなどのサーバー設定、Webサーバー設定、CDNやWAFのルール、ホスティング会社の管理画面など、複数の場所で設定されていると、リダイレクトループや意図しない転送の原因になります。
変更後も古い挙動が続く場合は、WordPressのキャッシュプラグイン、サーバーキャッシュ、CDNキャッシュ、ブラウザキャッシュを考慮します。ただし、キャッシュを削除しただけでHTTPステータスの設定ミスが直るわけではありません。設定変更前にはバックアップやステージング環境の利用を検討し、反映後に対象URLの応答を再確認してください。
修正後に行う確認とSearch Consoleでの検証
設定を変更したら、Search Consoleの表示が消えるのを待つだけでは不十分です。対象URLが意図した応答を返し、内部リンクなどにも矛盾がないことを確認してから、必要に応じてSearch Consoleで検証します。
対象URL・内部リンク・サイトマップを再確認する
301リダイレクトを設定した場合は、旧URLが1回の転送で正しい新URLへ到達するかを確認します。リダイレクトチェーンやループがあると、ユーザーにもGoogleにも余分な負担がかかります。ページを復活した場合は、200 OKで本文が表示され、noindexや誤ったcanonicalタグが残っていないかを確認してください。
404または410にするURLについては、内部リンクやXMLサイトマップから可能な限り削除します。外部サイトからのリンクは自分で修正できないこともありますが、まず自サイト内で案内しているリンクを正すことが優先です。
出典：Google Search Central「Site Moves and Migrations」
URL検査と修正の検証を使い分ける
修正後はURL検査ツールで対象URLを調べ、「公開URLをテスト」を実行します。有効なページを修正した場合は、必要に応じてインデックス登録をリクエストできます。404やソフト404の問題が複数URLに及ぶ場合は、ページインデックス登録レポートの「修正を検証」を利用する方法があります。
ただし、インデックス登録リクエストや検証開始は、検索結果やレポートへの即時反映を保証する操作ではありません。Googleが再クロールして再評価するまでには時間がかかります。修正内容と確認結果を記録すると、後日の再確認や原因調査がしやすくなります。
出典：Google Search Console Help「Inspect and troubleshoot a single page」
よくある質問
404・ソフト404の対応で判断に迷いやすい点を補足します。
Search Consoleに404が出たら、必ず修正すべきですか？
いいえ。削除済みで代替先がないURL、存在したことのない誤記URL、外部サイトからの誤ったリンクによるURLなら、適切に404を返せていれば緊急の修正は不要です。ただし、自サイトの内部リンクやXMLサイトマップに404 URLが残っている場合は修正してください。
404をトップページへ301リダイレクトしてもよいですか？
旧URLとトップページの内容が実質的に対応する特殊な場合を除き、推奨できません。削除したページに代替先がないなら、404または410を返すほうが自然です。関連性がない転送は行わないことが基本です。
カスタム404ページを作るとSEOに悪影響はありますか？
ユーザーが次のページを探しやすいカスタム404ページ自体は問題ありません。ただし、存在しないURLに対してHTTP 404を返すことが条件です。デザインだけ404風でHTTP 200を返している場合は、ソフト404の原因になり得ます。
ソフト404を直した後、いつSearch Consoleから消えますか？
Googleの再クロールと再評価のタイミングに左右されるため、具体的な日数は保証できません。修正後はライブテストで現在の状態を確認し、必要に応じてインデックス登録リクエストまたは修正の検証を実行したうえで、レポートの更新を待ちます。
まとめ
404は、存在しないURLに対して正しく返されているなら、SEO上の問題とは限りません。一方、ソフト404は、200 OKを返すエラーページや内容の乏しいページなどをGoogleが検出した状態であり、HTTP応答とページ内容の両方を確認する必要があります。
対応の基準は明確です。関連する移転先があるURLだけ301を使う、代替先のない削除ページは404または410を返す、本来あるべきページは復活させる、という方針で判断してください。Search Consoleのレポート、URL検査、実際のHTTPレスポンスを組み合わせ、URL単位で状態を整えることが不要なインデックス問題を減らす近道です。
