ソフト404の直し方：正しいステータスコードで「存在しない」を返す

Search Console で「ソフト404」という見慣れない警告が出て、どう直せばいいのか分からず調べている方が多いはずです。エラーとは書いてあるものの、そのページをブラウザで開くと普通に表示される――ここが混乱の入口です。

この記事は「自分のサイトを自分で直す」立場のエンジニア／サイト担当者に向けて、ソフト404の正体と、サーバーが返す「HTTPステータスコード（サーバーからの応答を表す3桁の数字）」を正しく設定して解消するところまでを、実際の削除作業を1回通してみせながら解説します。

ソフト404とは「中身は無いのに成功を返している」状態

ソフト404とは、ページの中身が実質的に存在しない（削除済み・在庫ゼロ・検索ヒットなし など）のに、サーバーが「200 OK（＝正常に取得できました、という成功の応答）」を返してしまっている状態を指します。人間の目には「該当する商品がありません」といったエラー画面に見えても、サーバーの応答としては「成功」のままです。この「見た目はエラーなのに、応答は成功」というズレた状態を、一般にソフト404と呼びます。

つまりソフト404は「サーバーの応答（ステータスコード）」と「ページの実際の中身」がズレている状態のことです。本物の404（ページが見つからない）とは違い、サーバー自身は問題を認識していません。だからこそ、放置すると気づかないうちに積み上がります。

なぜ放置すると損なのか：クロールを無駄づかいする

Google は、サイトを巡回（クロール）するために割り当てる時間とリソースの量を「クロールバジェット（クロールの割り当て）」と呼んでいます。ここでいうクロールとは、Googlebot（Googleの巡回ロボット）がページを見て回ることです。

Google 検索セントラルの公式ドキュメントは、ソフト404について明確にこう述べています。ソフト404のページはその後も巡回され続け、クロールの割り当てを浪費するためだ、と。そのうえで「ソフト404を解消すること」「サイトマップを最新に保つこと」を対処として挙げています。中身の無いページを何度も巡回させることは、本来クロールしてほしい重要なページに回るはずだった巡回を奪う、ということです。

一方で、クロールの必要量（Google がどれだけ巡回したいか）は、サイトの規模・更新頻度・ページの品質・関連性によって変わる、とも説明されています。ですから数千ページ規模の一般的なサイトにとって現実的な論点は、「クロールバジェットの総量を増やす」ことよりも、「無駄なソフト404を作らない・放置しない」ことのほうです。ここは実務判断として押さえておきたいポイントです。

まず「本当に200を返しているか」を確認する

直す前に、対象URLが実際にどのステータスコードを返しているかを自分の目で確かめます。見た目のエラー画面に惑わされず、応答そのものを見るのが要点です。

1. Search Console のインデックス カバレッジ レポート（サイトのインデックス状況を示すレポート）を開き、「ソフト404」に分類されているURLの一覧を書き出します。公式ドキュメントも、ソフト404はこのインデックス カバレッジ レポートで確認できると案内しています。
2. 対象URLを1つ選び、Chrome で開いて「デベロッパーツール（F12）」→「Network（ネットワーク）」タブを表示した状態でページを再読み込みします。
3. 一番上（そのページ自身のリクエスト）の「Status（ステータス）」列を見ます。ここが 200 になっていれば、中身が無いのに成功を返している＝ソフト404の典型です。

この「見た目」ではなく「応答コード」で判断する一手間が、原因の取り違えを防ぎます。

5ステップの直し方（廃止した製品ページ30件を例に）

たとえば「終了したキャンペーンの製品ページ30件」を片付ける場面を、順番に通してみます。ポイントは「全部まとめてトップページへ転送」で済ませないことです。

1. 仕分けする：30件を「後継・類似ページがある」ものと「代わりが無い（完全に廃止）」ものに分けます。この仕分けが対処の分岐点です。
2. 後継がある → そのページへ転送する：関連性の高い後継ページへ転送（301リダイレクト＝恒久的な転送）を設定します。転送先は「近い内容のページ」にします。関係のないトップページへ逃がさないのが原則です。
3. 代わりが無い → エラーを正しく返す：サーバー設定で、そのURLに「404（見つからない）」または「410（消滅した）」を返すようにします。どちらも「このページはもう無い」を伝える応答です。200を返し続けないことが目的です。
4. 巡回をブロックしない：消したいURLを robots.txt でブロックしてはいけません。後述のとおり、ブロックすると逆効果になります。
5. 後始末をする：XMLサイトマップから対象URLを外し、サイト内の他ページに残っているそのURLへのリンクも消します。仕上げに Search Console で対象URLを再確認し、応答が変わったかを見届けます。

対処の早見表：状況別に何を返すか

noindex（検索結果に出さない指示）は、使いどころを選びます。公式ドキュメントによれば、noindex は <meta> タグや HTTP レスポンスヘッダーで設定するルールで、noindex に対応する検索エンジン（Google など）が、そのコンテンツをインデックスに登録するのを防ぐものです。逆に言えば、noindex に対応していない検索エンジンには効きません。さらに重要なのは、後述のとおり、robots.txt でそのページをブロックしていると Googlebot が noindex タグ自体を読み取れない、という点です。noindex は「Googlebot から見える状態」にして初めて機能します。

よくある誤解：この2つは逆効果

誤解1：「消したいページは全部トップページへリダイレクトすればいい」 関係のないトップページへまとめて転送するのは避けるのが無難です。転送先の内容が元のページと大きく異なると、たどり着いたユーザーが目的の情報を得られず、転送の意味が薄れてしまうためです。転送は「内容の近いページ」へ、代わりが無いなら素直に404／410を返すのが基本、と考えておくとよいでしょう。

誤解2：「早く消したいから robots.txt でブロックする」 消したい一心で robots.txt でブロックすると、かえって逆効果になりがちです。公式ドキュメントは、robots.txt でブロックされたURLは巡回のキュー（順番待ちの列）に長くとどまり、ブロックが外れたときに改めて巡回される、と説明しています。さらに noindex を付けた場合も、robots.txt でブロックしていると Googlebot はそのタグを読み取れません。Google は「ページのブロックを解除するには robots.txt ファイルを編集し、noindex を Googlebot から見える状態にする必要がある」と述べています。ここから実務上言えるのは、ブロックしたままだと Googlebot はそのページを見に来られず、「もう無い（404／410）」という応答も、noindex という指示も読ませる機会が作れない、ということです。消したいなら、ブロックせず、正しいエラー応答や noindex を読ませることを先にするのがよいでしょう。

自己点検チェックリスト

自分のサイトのソフト404を直したあと、次の観点でひと通り確認します。

このうち1つでも「見た目はエラー画面なのに200を返している」ものが残っていれば、それが次に直すソフト404です。

まとめ

ソフト404は「サーバーの応答」と「中身」のズレです。直し方の芯は、後継があれば内容の近いページへ転送し、無ければ素直に404／410を返し、消したいページを robots.txt でブロックしない――この3点に尽きます。デベロッパーツールで応答コードを1件ずつ確かめ、上のチェックリストで後始末まで見届ければ、無駄なクロールを減らし、サイトの状態を検索エンジンに正しく伝えられます。

関連して、noindex を付けたのに検索結果から消えないケースは 検索結果からページが消えない原因（robots.txtとnoindexの関係） で、新規ページがインデックスされない側の切り分けは インデックスされない原因の診断 で扱っています。