Google Search Consoleに大量の404やsoft 404が表示されると、「すべて直した方がよいのでは」と考えがちです。しかし、404は存在するだけでSEO上の問題になるわけではありません。
404・soft 404を含む技術課題の全体像から確認したい場合は、[テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト](https://rebranding.co.jp/media/technical-seo/)を先に確認してください。
重要なのは、URLごとに「本来存在すべきページか」「別URLへ移転したか」「完全に削除したか」「内部リンクやサイトマップから参照されているか」を確認し、処置を分けることです。
この記事では、404・soft 404を抽出し、原因を分類したうえで、301リダイレクト、404・410の維持、ページ復旧、内部リンク修正、サイトマップ除外まで判断する監査方法を解説します。
404監査は「エラー数」ではなくURLの状態と重要度で判断する
結論からいうと、404監査では「404が何件あるか」だけを見ても、修正の優先順位は決められません。
Googleは、存在しないURLが正しく404を返すこと自体は通常の状態であり、404があるだけでサイトの検索パフォーマンスに悪影響が出るわけではないと説明しています。また、特に確認すべき404として、自サイトからリンクしているURLやサイトマップに掲載しているURLを挙げています。
そのため、404監査では少なくとも次の5点をURL単位で確認します。
- 本来そのURLにページが存在すべきか
- 同じ目的を持つ移転先・統合先があるか
- サイト内からリンクされているか
- XMLサイトマップに掲載されているか
- 過去の流入や外部サイトからのリンクが残っているか
この確認結果によって、「修正すべき404」と「正常なので残してよい404」を分けます。
| 状態 | 基本判断 | 主な処置 |
|---|---|---|
| 本来存在すべきページが404 | 問題 | ページ復旧・設定修正 |
| URL変更後の旧URL | 要対応 | 新URLへ301または308 |
| 完全に削除し代替ページなし | 正常 | 404または410を維持 |
| 内部リンク先が404 | 要対応 | リンク先を直接修正 |
| サイトマップ掲載URLが404 | 要対応 | URL修正またはサイトマップから除外 |
| 存在しない誤URLへのアクセス | 原則問題なし | 404を維持 |
| 本来存在するページがsoft 404 | 問題 | 表示・レスポンス・コンテンツを確認 |
| 削除ページが200を返している | 問題 | 404または410へ修正 |
404をゼロにすることではなく、URLの実態とHTTPレスポンスを一致させることが監査の目的です。
404とsoft 404の違いを最初に確認する
404とsoft 404では、修正方法が異なります。
404はHTTPステータスそのものですが、soft 404はページ内容などからGoogleが実質的なエラーページと判断する状態です。
通常の404は、サーバーが「対象リソースが見つからない」ことをHTTPステータスコード404で返している状態です。HTTP仕様のRFC 9110でも、404は対象リソースの現在の表現が見つからない場合のステータスとして定義されています。
一方、soft 404はHTTPステータスコードそのものではありません。
Googleは、存在しないページのような内容を表示しながら200 Successを返すページや、メインコンテンツがほとんど存在しないページなどをsoft 404として判定する場合があります。
| 項目 | 404 | soft 404 |
|---|---|---|
| HTTPレスポンス | 404 | 200などの場合がある |
| ページの実態 | URLが存在しない | 存在しない・空・読み込み失敗など |
| Googleの扱い | 存在しないURLとして処理 | 内容を見てエラーページ相当と判断 |
| 主な対応 | 状態に応じて維持・301 | 原因を確認してレスポンスまたはページを修正 |
soft 404だからといって、必ずページを削除するわけではありません。
Google公式では、soft 404を次の3状態に分けて判断しています。
- ページが本当に存在しない
- ページが別の場所へ移動した
- ページは現在も存在する
つまり、まず「Googleの判定を消す方法」を探すのではなく、そのページを今後どう扱いたいのかを確定することが先です。
404・soft 404監査は5ステップで進める
404監査は、次の順番で行うと処置を誤りにくくなります。
- 404・soft 404のURLを抽出する
- URLが発生した原因を分類する
- URLごとの正しい処置を決める
- 事業・SEO上の重要度から優先順位を付ける
- 修正後にHTTPレスポンスとGoogle側の認識を再確認する
404監査は、URL抽出後すぐに修正するのではなく、原因を分類してから処置と優先順位を決めます。
特に重要なのは、URL抽出直後に一括リダイレクトしないことです。
404には「直すべき404」と「404のままが正しいURL」が混在しています。原因を分類せずにすべてトップページやカテゴリページへ転送すると、URLと転送先の内容が一致しない状態を増やしてしまいます。
STEP1｜Search Consoleだけに頼らず404 URLを抽出する
最初に、404・soft 404になっているURLを一覧化します。
1. Google Search Consoleを確認する
Search Consoleの「ページのインデックス登録」レポートでは、「見つかりませんでした（404）」や「soft 404」と判定されたURLを確認できます。
soft 404については、公開URL検査を使ってGoogleが取得したページやレンダリング結果を確認することも重要です。正常なページでも、重要なJavaScriptやその他のリソースをGooglebotが取得できず、ほぼ空のページとして認識された場合にはsoft 404になる可能性があります。
2. サイトクロールで内部リンク切れを抽出する
Search Consoleに出ているURLだけでなく、サイト内のリンク先が404になっていないかも確認します。
サイトクローラーを利用し、
- 404を返すURL
- 404へリンクしているページ
- リンク元の数
- ナビゲーションや関連記事など重要導線からのリンク
を一覧化します。
404 URLだけを見るのではなく、「どのページからその404へ到達するのか」をセットで記録することがポイントです。
3. XMLサイトマップと照合する
404 URLがXMLサイトマップに残っている場合は、優先的に確認します。
Googleはサイトマップについて、検索結果に表示させたいURLを掲載し、基本的には正規URLを指定するよう案内しています。
すでに削除したURLをサイトマップへ残したままにするのではなく、削除方針が確定しているならサイトマップからも除外します。
4. 過去の流入と外部リンクを確認する
以前は検索流入やコンバージョンがあったURL、外部サイトからリンクされているURLは、単純な404より優先度を上げます。
特にURL変更によって旧ページが404になっている場合は、内容が対応する新URLがあるかを確認します。
外部リンクのある404については、Ahrefsなどの外部リンク調査ツールでも抽出できます。
STEP2｜404が発生した原因を6種類に分類する
URLを抽出したら、原因を分類します。
A. URL変更
ページ自体は残っているものの、URLだけ変更されたケースです。
旧URLと新URLの内容が対応していれば、恒久的なリダイレクトを設定します。
B. ページ統合
複数ページを1ページへ統合した結果、旧URLが消えたケースです。
統合先が旧URLの検索意図や内容を実質的に引き継いでいるなら、統合先へのリダイレクトを検討します。
C. 完全削除
終了したサービス、古いキャンペーン、不要になった記事など、代替コンテンツが存在しないケースです。
この場合は、無理に別ページへリダイレクトする必要はありません。正しい404または410を返します。
D. 内部リンクのURL間違い
ページは存在しているのに、リンク先の入力ミスやURL変更後の更新漏れによって404になっているケースです。
リダイレクトだけで処理するのではなく、リンク元のURLそのものを修正します。
E. 存在しないURL
タイプミス、外部サイトの誤リンク、クローラーが生成したURLなど、そもそもコンテンツが存在したことのないURLです。
自社サイトから参照されておらず、重要な外部流入もないなら、404のままで問題ありません。
F. soft 404
本来存在するページの読み込み失敗、空ページ、エラーテンプレートなどにより、Googleが実質的な404と判断しているケースです。
この場合はステータスコードだけでなく、Googlebotが実際に取得したコンテンツまで確認します。
STEP3｜URLごとに301・404・410・復旧を判断する
404監査で最も重要なのが処置の決定です。
次の表を基本の判断表として利用できます。
| URLの状態 | 代替ページ | 処置 |
|---|---|---|
| URLだけ変更した | あり | 301または308 |
| ページを統合した | 明確な統合先あり | 301または308 |
| 完全に削除した | なし | 404または410 |
| URLを打ち間違えている | 正しいURLあり | 内部リンクなら直接修正 |
| サイトマップ掲載URLが404 | 状況による | URL修正またはサイトマップ除外 |
| 削除ページが200を返す | なし | 404または410へ変更 |
| 本来存在するページがsoft 404 | ― | ページ表示・リソース・内容を修正 |
| 有効ページを誤って404にした | ― | ページを復旧して200を返す |
404を一律にリダイレクトするのではなく、URLが存在すべきか、移転したか、完全削除かによって処置を分けます。
Googleは、ページが移動した、または明確な代替ページが存在する場合には301による恒久的なリダイレクトを案内しています。
また、検索結果に表示されるURLを恒久的に変更する場合には、サーバー側の301または308などの永続的なリダイレクトが推奨されています。
404と410はどう使い分けるか
HTTP仕様上、404は「現在そのリソースが見つからない」状態を示し、一時的か恒久的かまでは示しません。
410 Goneは、「そのリソースが恒久的に利用できなくなった」と分かっている場合に使うステータスです。
SEO監査では、削除したURLだからといってすべて410へ変更する必要はありません。
- 完全削除であることを明確に管理している → 410も選択肢
- 通常の削除・存在しないURL → 404で問題なし
という運用で十分です。
STEP4｜404修正の優先順位を4段階で決める
数百、数千URLの404がある場合、すべてを同じ優先度で処理すると工数が膨らみます。
そこで、次の4段階で優先順位を付けます。
| 優先度 | 状態 | 主な対応 |
|---|---|---|
| P0 | 本来公開中の重要ページが404・soft 404 | 即時復旧 |
| P1 | 移転先がある旧URL、重要内部リンク、サイトマップ掲載URL、価値ある外部流入あり | 301・リンク修正 |
| P2 | 削除済みだが内部リンクやサイトマップに残っている | 参照元を整理し404維持 |
| P3 | 存在実績がなく参照もない誤URL | 原則対応不要 |
大量の404はすべて同時に修正せず、本来存在するページや移転URLなどP0・P1から優先して対応します。
P0｜本来存在するページの404を最優先する
商品ページ、サービスページ、問い合わせ導線、検索流入のある記事など、本来200を返すべきページが404になっている場合は最優先です。
soft 404についても、本来公開すべきページが誤判定されている場合はP0として扱います。
P1｜移転URLとサイト内から参照される404を修正する
URL変更やページ統合によって新しいページが存在する場合は、対応する新URLへリダイレクトします。
同時に、サイト内リンクは可能な限り新URLへ直接書き換えます。
また、XMLサイトマップに残る404も、サイト側がGoogleへ発見を促しているURLであるため、早めに整理します。
P2｜正しい404でも参照元だけ整理する
ページそのものは削除して正しい404を返していても、サイト内からリンクされ続けている場合があります。
この場合、404レスポンスを200に戻す必要はありません。
- 内部リンクを削除・変更する
- サイトマップから除外する
- canonicalなどから参照されていないか確認する
といった周辺の参照関係を整理します。
P3｜価値のない未知URLは追いかけない
入力ミスやbotなどによって生成された未知URLまで、すべてリダイレクトする必要はありません。
Googleも、存在しないことが明確なURLについては正しく404を返せばよいと説明しています。
監査工数をP0・P1へ集中させることが重要です。
STEP5｜修正後はHTTPレスポンスとGoogle側の表示を再確認する
404監査は設定変更で終了ではありません。
修正後は、最低でも次の4点を確認します。
1. HTTPステータスコード
旧URL・新URLをそれぞれ確認します。
たとえばコマンドラインでは次のように確認できます。
curl -I https://example.com/old-url
301を設定した場合は、
- 旧URL：301または308
- Location：正しい新URL
- 新URL：200
になっているか確認します。
2. リダイレクト先
旧URLと関係の薄いトップページや一覧ページへ一律転送していないかを確認します。
「転送できているか」ではなく、「旧ページを探していたユーザーが新しいURLで目的を達成できるか」で判断します。
3. 内部リンクとサイトマップ
301を設定しても、内部リンクやXMLサイトマップが旧URLのままであれば、サイト内部には古いURLが残り続けます。
リダイレクト設定と同時に参照元も更新します。
4. Search Console
soft 404の場合はURL検査から公開URLをテストし、Googlebotがページを正常に取得できるか確認します。
Google公式も、正常なページがsoft 404になった場合にはURL検査でレンダリングされた内容とHTTPコードを確認するよう案内しています。
404監査でよくある3つの誤り
すべての404をトップページへリダイレクトする
削除ページとトップページに内容上の対応関係がなければ、ユーザーが探していた情報には到達できません。
明確な代替ページがない場合は、404を正しく返す方が適切です。
カスタム404ページを200で返す
見た目だけ「ページが見つかりません」と表示し、HTTPステータスが200になっているとsoft 404の原因になります。
カスタム404ページを作る場合でも、サーバーは404を返す必要があります。Googleも、カスタム404はユーザー向けに用意しつつ、HTTPレスポンスとしては404を返すよう案内しています。
Search Consoleから404が消えることだけを目的にする
監査の目的はSearch Consoleのエラー件数をゼロにすることではありません。
完全削除したページが404として認識されているなら、それは正常な場合があります。
重要なのは、
- 本来存在するページが正常に表示される
- 移転したページが正しいURLへ移動する
- 削除ページが正しく削除状態を返す
- サイト内から不要な404へリンクしない
という状態を作ることです。
404・soft 404監査チェックリスト
最後に、実務で確認する項目をまとめます。
- Search Consoleから404 URLを抽出した
- soft 404 URLを抽出した
- サイトクロールで内部リンク切れを抽出した
- XMLサイトマップと404 URLを照合した
- 過去に流入があったURLを確認した
- 外部リンクがある旧URLを確認した
- URL変更・統合・削除・誤URLを分類した
- 明確な移転先があるURLだけ301・308を設定した
- 代替ページがない削除URLは404・410を維持した
- 本来存在するページの404を復旧した
- soft 404のレンダリング結果を確認した
- 内部リンクを新URLへ直接更新した
- 404 URLをXMLサイトマップから除外した
- 修正後のHTTPレスポンスを確認した
- Search ConsoleのURL検査で再確認した
このチェックリストをURL単位の管理表へ追加すると、担当者が変わっても同じ基準で監査できます。
まとめ
404・soft 404のSEO監査で重要なのは、エラー件数を減らすことではありません。
URLごとに「本来存在すべきか」「移転したか」「完全に削除したか」を確認し、さらに内部リンク、XMLサイトマップ、過去流入、外部リンクを照合して処置の優先順位を決めます。
本来存在するページの404・soft 404は最優先で修正します。明確な移転先があれば301または308、代替ページがなければ404または410を返します。
そして、正しい404を無理に消すのではなく、内部リンクやサイトマップなど「404を参照している側」を整理します。
404監査を「エラーを消す作業」ではなく、URLの役割とサイト内外の参照関係を整える技術監査として運用することで、修正すべきURLへ工数を集中できます。
参考文献・データ元
404（ページが見つかりません）エラー
発表元：Google Search Console Help
更新状況：2026年8月確認
使用内容：404自体の検索パフォーマンスへの考え方、削除URL・移転URLの処置
URL：Google Search Console「404 エラー」
Google 検索のクロールエラーのトラブルシューティング
発表元：Google Search Central
更新状況：2026年8月確認
使用内容：soft 404の定義、削除・移転・現存ページ別の修正方法
URL：Google Search Central「クロールエラーのトラブルシューティング」
リダイレクトと Google 検索
発表元：Google Search Central
更新状況：2026年8月確認
使用内容：301・308など恒久的なリダイレクトの考え方
URL：Google Search Central「リダイレクトと Google 検索」
Build and Submit a Sitemap
発表元：Google Search Central
更新状況：2026年8月確認
使用内容：サイトマップへ検索結果に表示させたい正規URLを掲載する考え方
URL：Google Search Central「Build and Submit a Sitemap」
RFC 9110: HTTP Semantics
発表元：RFC Editor
公開：2022年6月
使用内容：HTTP 404 Not Found、410 Goneの正式な定義
URL：RFC 9110 HTTP Semantics
リンク切れの被リンク
発表元：Ahrefs
更新状況：2026年8月確認
使用内容：404 URLに残る外部リンクの確認方法
URL：Ahrefs「リンク切れの被リンク」