削除したページに何を返すか ── 404・410・ソフト404の使い分けを確認する15項目

01 何が起きたか — 消したページに何を返すべきか、公式は優先順位を示している

「404」「410」「ソフト404」、混同されやすい3つの状態

WEBサイトの記事やページを削除・非公開にするとき、サーバーが何を返すかによって、Googleの扱いは変わる。よく混同される3つの状態が、404（Not Found）・410（Gone）・ソフト404である。404と410はどちらも「そのURLにコンテンツが存在しない」ことを伝えるHTTPステータスコードだが、ソフト404はステータスコードの話ではない。HTTPステータスは200（成功）を返しているのに、中身がエラーメッセージや空白ページになっているという食い違いを、Googleが検出したときに付けるラベルである。放置してよいものと、直すべきものを切り分けるには、この3つの違いを先に理解しておく必要がある。

この判断は、サイトの規模が大きくなるほど頻繁に発生する。キャンペーンページの終了、在庫切れ商品ページの扱い、古い記事の統廃合、URL構造の変更など、ページを削除・非公開にする場面は日常的に発生し、その都度「何を返すべきか」を判断することになる。判断のたびに迷っていては運用が止まるため、この記事では判断の基準を先に整理し、迷わず選べる形にしておく。

公式ドキュメントが定義する「エラー」の扱われ方

Google Search Centralの「HTTPおよびネットワークエラー」ページには、4xx・5xxの各ステータスコードがGoogleの処理システムにどう伝わるかが一覧で示されている。同じページには、Search Consoleの「ページのインデックス登録」レポートに表示される「見つかりませんでした（404）」と「ソフト404」という2つの状態を区別するための判断材料も記載されている。この記事では、この公式情報をもとに、削除したページに何を返すべきかの判断を、WEBディレクターが自分のサイトで確認できる手順にまで落とし込む。

404そのものは、必ずしも悪いことではない。むしろ、削除したページが本当に消えたことをGoogleに正しく伝える、正常な合図である。問題になるのは、意図と実際の応答が食い違っている場合だけである。恒久的に消したつもりが一時的な扱いのままになっている、逆に一時的なつもりが恒久的な削除として処理されている、あるいはエラーのはずのページがHTTP 200を返し続けている、といった食い違いが、実際の運用でしばしば起きる。この記事は、消すこと自体を問題視するのではなく、意図と応答を一致させることに焦点を当てる。

02 なぜ・背景 — 「存在しない」と「一時的に遅い」は別の合図

4xxエラーは「そのコンテンツは存在しない」という合図

Google公式ドキュメントは、4xxエラーの扱いについて次のように明記している。

"All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist."

（訳: 429を除くすべての4xxエラーは同じ扱いを受ける。Googleのクローラーは、後続の処理システムに「コンテンツが存在しない」ことを伝える。）

(Common HTTP and network errors and how to fix them（訳: よくあるHTTP・ネットワークエラーとその修正方法）)　これは404も410も、429（Too Many Requests）を除けば「同じ扱いを受ける」ことを意味する。410の方が404より速く削除される、あるいは強い信号として扱われるという記述は、このページのどこにも見当たらない。「410は404より即効性がある」という理解は、現時点の公式ドキュメントの記述としては裏付けが見つからない。

クロール頻度は「徐々に」下がる — 即座には止まらない

404・410と判定されたページについて、公式ドキュメントは処理の流れをこう説明している。

"In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren't processed. The crawling frequency gradually decreases."

（訳: Google検索の場合、インデックスパイプラインは、以前インデックスされていたURLをインデックスから削除する。新しく検出された404ページは処理されない。クロール頻度は徐々に低下する。）

(前掲のCommon HTTP and network errors)　「404を返せば即座にインデックスから消える」わけではなく、除去とクロール頻度の低下は段階的に進む。この段階的な処理を理解していないと、404にした直後にSearch Consoleを確認して「まだ残っている」と誤って心配することになる。逆に、大量のページを一度に404化した場合、除去にかかる時間はページ数やクロール頻度によって変わるため、翌日にすべてが反映されていることを前提にした確認スケジュールは組まないほうがよい。

03 この記事で出てくる用語

なぜ「200なのにエラー」が起きるのか

ソフト404は、多くの場合、サイトの実装側の設計に起因する。よくある原因は、削除したページのURLへアクセスした際に、サーバーがエラーコードを返さずにトップページやカテゴリページへ内容を差し替えて表示し、HTTPステータスは変更せずに200のまま応答してしまうケースである。ユーザーの体験としては「案内が出て親切」に見えても、Googleから見ると「このURLには本来あるべき固有の内容が無い」という不一致の合図になる。もう一つのよくある原因は、在庫切れの商品ページなどで、内容がほぼ空になっているのにステータスコードだけが200のまま残っているケースである。

CMSやフレームワークの初期設定では、存在しないURLへのアクセスに対して自動的にトップページへリダイレクトする、あるいはトップページの内容をそのまま表示する挙動が組み込まれていることがある。「404ページを個別に用意していない」こと自体が、ソフト404を生む設計上の原因になりうる。削除したページには、サーバー側で明示的に404または410のステータスコードを返す実装になっているかを、まず確認する必要がある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どの状況で、どのコードを返すか

削除・非公開にする理由によって、返すべきコードは変わる。恒久的に、二度と使わないURLであれば404または410を返す。サービスの終了・キャンペーンページの完全撤去・記事の完全削除などが該当する。一時的に非公開にしたいだけ（メンテナンス・在庫の一時切れ・季節限定コンテンツの休止期間・イベント終了後の再開予定があるページなど、いずれ復活する予定がある）であれば503を返す。内容が別のURLに移った、あるいは統合された場合は301リダイレクトで新しいURLへ送る。URL構造を変更した、複数の記事を1本にまとめた、といった場合がこれにあたる。削除ではなく検索結果への非表示だけが目的であれば、ページ自体は200のまま残し、noindexを設定する（noindex・robots.txtの使い分けは別の回で扱っている）。この4つを状況ごとに正しく割り当てることが、この記事全体の主題になる。

実務でとくに迷いやすいのが、「一時的」のつもりで放置しているうちに、実質的に二度と使わないままになってしまうケースである。季節商品のページを翌シーズンまで503で残す想定だったが、翌シーズンに商品自体が廃番になり、結局そのまま二度と使わなくなる、という展開は珍しくない。503のまま長期間放置すると、Googleは徐々にそのURLを恒久的なエラーとして扱うようになるため、「一時的」と判断したページには、再確認する期限をあらかじめ決めておくことが望ましい。

🅱 この記事が測っていないこと・分からないこと

公式ドキュメントを確認しても、明確に書かれていない点がいくつかある。第一に、404と410のどちらがどれだけ速く処理されるかという具体的な速度差は、現在のドキュメントには記載がない。第二に、ソフト404と判定されるまでにかかる具体的な日数や、どの程度の割合のコンテンツがエラーを示していれば判定されるのか、という閾値は公開されていない。第三に、301リダイレクトの送り先について、公式ドキュメントは「ページを削除し、ユーザーを新しいページへ送りたい場合」という利用例は挙げているが(Redirects and Google Search（訳: リダイレクトとGoogle検索）)、送り先が元のページとどの程度 内容的に関連していなければならないか、という具体的な基準までは明記されていない。第四に、503を何日間 返し続けると恒久的なエラーとして扱われ始めるのか、という具体的な日数も公開されていない。この4点を断定的に語ることはできない。

🅲 手順 — 判断から実装まで

実際の判断は、次の4段階で進める。第一に理由の切り分けとして、そのページを消す理由が「恒久的」か「一時的」か「移転・統合」かを決める。第二にコードの選択として、前章の型に沿って404・410・503・301のいずれかを選ぶ。第三に実装の確認として、実際にそのURLへアクセスし、ブラウザの開発者ツールで意図したステータスコードが返っているかを確認する。第四に周辺の整合として、sitemap.xmlや内部リンクなど、そのURLを参照している他の場所も合わせて更新する。この4段階を実際の作業に翻訳したものが、次章のチェックリストである。

05 明日、自分のサイトで確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、現状把握（削除済みURLの棚卸し）、実装の確認（実際のステータスコード）、Search Consoleでの確認、内部参照の整合、の4つに分かれる。

• 直近30日以内に削除した記事・ページのURLを一覧にする
• 削除したURLのうち、内容的に関連する代替ページが存在するものが何件あるか数える
• 代替ページが存在するURLに、301リダイレクトが設定されているか、1件ずつ実際にアクセスして確認する
• 代替ページが存在しないURLについて、ブラウザの開発者ツールのNetworkタブで実際のステータスコードが404を返しているか確認する
• 恒久的に二度と使わないと決めたURLに、404ではなく410を明示的に返す設定になっているか確認する
• 一時的に非公開にしているだけのページが、誤って404や410を返していないか、503になっているか確認する
• Search Consoleの「ページのインデックス登録」レポートを開き、「見つかりませんでした（404）」の件数を確認する
• 同じレポートで「ソフト404」の件数を確認する
• ソフト404と判定されたURLを3件開き、実際の表示内容が「エラーです」「該当ページがありません」等の文言だけになっていないか確認する
• 自社サイトが自分でリンクしている、またはsitemapに掲載している404が何件あるか数える
• sitemap.xmlを開き、既に削除して404を返しているURLが何件残っているか数える
• 残っていた場合、sitemapから該当URLを削除して再送信する
• サイト内の内部リンクの中に、404を返すURLへのリンクが何本残っているか、リンクチェックツールで数える
• 見つかった404への内部リンクを、正しいURLへ差し替える
• 1ヶ月前に対応した404・ソフト404の項目を再度開き、Search Consoleの件数が実際に減っているか確認する

15項目の内訳と、かかる時間の目安

15項目は4つの観点に対応している。それぞれの観点にどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1サイトあたり40〜50分程度である（Search Consoleのレポートを新規で確認する場合は、データの反映を待つ時間が別途必要になる）。削除したURLの件数が多い場合は、まず内容的に重要度が高いページから確認するとよい。5番目・6番目の項目（410と503の使い分け）は、恒久的な削除と一時的な非公開を取り違えていないかを確かめる項目であり、この記事の02章・04章で扱った混同を、自分のサイトの実装に照らして確認する作業にあたる。

06 代替・他の選択肢（表で）

4つの対応の、できることとできないこと

ここまで見た404・410・301・503に、削除ではなく検索結果からの非表示だけを目的とするnoindexを加えると、選択肢は実質的に5つになる。ただしnoindexはページ自体を消すものではないため、ここでは「削除・非公開にする」ための4つの対応に絞って、それぞれができることとできないことを整理した。

大量に削除する場合の考え方

1件ずつ手作業で対応するのが現実的でないほど大量のページを削除する場合も、基本的な考え方は変わらない。まずsitemap.xmlから削除済みURLを除いて再送信し、301で評価を引き継がせられるページとそうでないページを仕分ける。301の被リンク評価の引き継ぎ方については、詳しく検証した回がある(301リダイレクトは被リンクの評価を引き継ぐか？)。sitemap.xml自体の作り方・運用については、別の回で手順を整理している(XMLサイトマップの作り方と運用)。

すべての404を追いかける必要はない、という点も押さえておきたい。Search Consoleの「ページのインデックス登録」レポートは、次のように案内している。

"In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap."

（訳: 一般的には、自サイトからリンクしている、またはサイトマップに掲載している404エラーだけを修正することを推奨する。）

(Page indexing report（訳: ページのインデックス登録レポート）)　同じレポートは「そのページが代替なしに削除されたのであれば、404レスポンスは必ずしも問題ではない」とも述べている（同ページ）。さらに「GoogleはこのURLを、明示的なリクエストやサイトマップなしに発見した」というケースについても言及があり（同ページ）、これは他サイトが偶然リンクしてきただけのURLが404として記録されている状態を指す。外部サイトが偶然リンクしてきただけの404まで、すべて追いかける必要はない。優先すべきは、自社サイト自身が参照している404である。

もう一点、「関連するページへ送る」という基準は、公式には明記されていない点にも注意したい。削除したページを301で別のページへリダイレクトする際、「できるだけ内容が近いページへ送るべきだ」という理解は広く共有されているが、この基準自体を公式ドキュメントの原文から見つけることはできなかった。公式が挙げている利用例は「ページを削除し、ユーザーを新しいページへ送りたい場合」という一文にとどまり(前掲のRedirects and Google Search)、送り先の関連性の度合いまでは踏み込んでいない。ただし、同じドキュメントは301を「Googleがリダイレクト先を処理すべき強い信号として使う」とも説明しており（同ページ）、関連性のないページへ機械的にまとめて送ると、その「強い信号」が実態と合わなくなる可能性は残る。この点は公式の明文規定ではなく、実務上の判断として扱うべきである。

07 自社サイトで確認したこと — 削除する前に、重複かどうかを確かめる

「消す」前に「重複しているか」を確かめる

削除するかどうかを判断する前段階として、そのページが本当に不要（重複）なのかを確かめる作業がある。ある記事を「同じ内容の記事が既にあるはずだ」と思い込んでnoindexや削除の対象にする前に、タイトルの一致だけに頼らず、内容が実際に重複しているかを数分で確かめる方法を扱った回がある(archives/129)。削除して404にするか、301で統合するか、そのまま残すかの判断は、重複の有無を確かめてから決めるべきであり、この確認を省略すると、まだ固有の価値があるページを誤って消してしまう可能性がある。

「消す」と「統合する」は、結果が別のものになる

同じ内容を持つページが複数あると判明した場合、単純に片方を404で消すのと、301でもう片方へ統合するのとでは、結果が異なる。前者はそのページが持っていた被リンクの評価を失う可能性があるのに対し、後者は評価を引き継がせられる。どちらを選ぶかは、消去法ではなく、06章の比較表と合わせて、内容の重複度合いを確認したうえで決める必要がある。

実務上の判断としては、次のように整理できる。内容がほぼ完全に重複しているなら301で統合し、被リンクとページの評価を1本にまとめる。一部だけ重複していて、それぞれに固有の価値がある部分が残っているなら、どちらも残したままcanonicalタグで正規URLを明示する選択肢もある（canonicalの使い方は別の回で扱っている）。重複ではなく、単純に情報が古くなって価値を失ったページなら、404または410で削除する。「なんとなく古い」という印象だけで、内容の重複度合いを確認せずに一律で削除すると、実際には固有の検索流入を持っていたページまで失うことになりかねない。

08 このテーマの、これまで

内部リンクの点検で、404以外の食い違いも見つかった回

内部リンクの点検を「リンク切れ（404）が発生していないか」という観点だけで行い、いったんは0件という結果を得た回がある。しかし、リンク先のHTTPステータスをさらに詳しく調べたところ、リンク切れではないものの、内部リンクの59.2%がnoindexを設定した記事への導線になっていたことが記録されている(archives/134)。404の有無だけを見るチェックでは、リンクは生きているが検索結果には出ないページへの導線という、別の種類の食い違いは見つからない。本記事05章のチェックリストが、404チェックと内部参照の整合を別項目として分けているのは、この実例を踏まえたものである。

この実例が示しているのは、「リンク切れ」という1つの観点だけでリンク構造の健全性を判断すると、見落としが生まれるということである。404を返すリンクだけでなく、正常に200を返すが検索結果には出ないページ、あるいは301で転送先が変わってしまったページなど、リンク先の状態はいくつかの種類に分かれる。本記事06章の比較表と組み合わせて、リンク先のステータスコードだけでなく、そのページが実際に検索結果に出る状態かどうかまで確認すると、より正確な点検になる。

「測定中」のまま止まっていた回と、その後の運用

ラベルとして「測定中」と書いてあると、実際にはその測定が長期間行われなくなる、という事例を、公開から52日分のログを開いて確認した回がある(archives/135)。本記事05章の最後の項目「1ヶ月前に対応した項目を再度開き、件数が実際に減っているか確認する」は、この事例と同じ失敗を繰り返さないための項目である。404対応を1回実行して満足するのではなく、Search Consoleの件数が実際に動いたかを、日を置いて確認し直す習慣が要る。

本記事の02章で確認したとおり、404の除去とクロール頻度の低下は「段階的に」進む。この「段階的」という性質そのものが、「一度対応したら終わり」という運用を成立させにくくしている。1回目の確認で件数が減っていなかったとしても、それが対応の失敗を意味するとは限らず、まだ処理の途中である可能性がある。逆に、何ヶ月も経ってなお件数が減らない場合は、実装そのものに問題がある可能性を疑う必要がある。「いつ、何を、どう確認したか」を記録に残しておくことが、この段階的な処理と付き合ううえでの実務上の要点になる。