404と410はどちらを返す？削除ページの選び方と設定手順

キャンペーンが終わった。商品の取り扱いもやめた。そのページを消すとき、サーバーに返させるのは404か、410か。「410のほうが検索から早く消える」という話も耳にします。

先に答えを書きます。Google検索の処理に限って言えば、どちらを選んでも扱いは同じです。 Googleのドキュメントは、429を除く4xx（「クライアント側のエラー」を表す400番台のステータスコード）はすべて同じに扱う、と明記しています。だから迷うべきは404か410かではありません。確かめるべきは、次の2点です。

• そのURLを本当に「消す」べきか（代わりのページへ転送すべきではないか）
• サーバーが本当にそのコードを返しているか

どちらも、つまずく人が多いのは設定の中身より確認の手順です。ここからは、判断の根拠になる公式の記述、URLの仕分け方、Apache・Nginxでの410の書き方、そして curl での確かめ方までを順に通します。

公式ドキュメントに書かれていること

ステータスコードとは、サーバーがブラウザや検索エンジンに「このページがどんな状態か」を伝える3桁の数字です。200は正常、404は「見つからない」、410は「消滅した（もう戻らない）」を意味します。

Googleの「HTTPステータスコードがGoogle検索に与える影響」のページには、4xxについてこう書かれています。429を除く4xxエラーはすべて同じように扱われ、Googleのクローラー（ページを読みに来るロボット）は「そのコンテンツは存在しない」と次の処理システムに伝える。Google検索の場合、以前インデックスに登録されていたURLは、インデックス登録の仕組みによってインデックスから削除される。そしてクロールの頻度は徐々に下がる。

同じページの一覧には、404（not found）と410（gone）が並んで載っています。つまり410は、404と別の特別な扱いを受けるコードとしては書かれていません。

もう一つ、Google検索セントラルの公式ブログ（2011年）には、もっと直接的な一文があります。コンテンツを完全に削除し、同じ用途を満たすページがサイトに無いなら、古いURLは404か410を返すべきだ。そして、現在Googleは410を404と同じに扱っているので、どちらを返しても自分たちには関係がない、と。

古い記事なので、これだけを根拠にするのは心もとないところです。ただ、現行のドキュメントも「429以外の4xxは同じ扱い」と書いており、中身は食い違っていません。

では、消したページが「エラー」として残り続けるのは問題なのか。Search Consoleヘルプの「ページのインデックス登録」レポートの説明は、インデックスに登録されなくても問題ない正当な理由の例として、削除して代わりのページも無いページの404を挙げています。Search Console（自分のサイトが検索でどう扱われているかを見る、Googleの無料ツール）に404が並んでいても、それが意図して消したページなら、慌てて件数を減らす必要はありません。

「410のほうが早く消える」は確かめられるか

ここが一番よく聞かれるところです。

公式の記述に照らすと、404と410で速度に差があるとは書かれていません。書かれているのは「同じに扱う」だけです。少なくとも、Googleの公式ドキュメントを根拠に「410にすれば早く消える」と言うことはできません。

一方で、「今すぐ検索結果から見えなくしたい」という事情はあり得ます。その場合の手段は、ステータスコードの選び方ではなく別にあります。Googleの「Google検索から情報を削除する」ページは、削除ツール（Search Consoleの「削除」機能）でのリクエストは約6か月有効で、恒久的に検索結果から外すにはページのコンテンツを削除または更新する、といった対応をとるよう案内しています。

整理すると、役割はこう分かれます。

• 急ぎで一時的に隠す: Search Consoleの削除ツール（効果は約6か月）
• 恒久的に外す: ページそのものを消して404か410を返す

410を選ぶこと自体は間違いではありません。ただ、Google検索での速さを期待して410にするのは、公式の記述からは支持されない、ということです。

404と410、それぞれを選ぶ理由

Google検索での扱いが同じなら、何で決めればいいのか。決め手は検索エンジンの外側にあります。

表の3行目と5行目が、実務ではいちばん効きます。404は「何もしなければ返る」ことが多い。410は「意図して設定しないと返らない」。設定の手間をかけられないなら、404で十分です。

410に意味があるのは、人間やほかのシステムに向けて「これは消し忘れではなく、意図して廃止した」と残したい場合です。たとえばアクセスログや監視の集計で、404（誤ったリンク・打ち間違いを含む）と、意図的に廃止したURLを分けて数えたいとき。そうした運用上の区別は、410を使うと付けやすくなることがあります。

消す前に決めること：本当に「消す」URLか

404か410かの前に、そもそも消すべきかを決めます。公式ブログの条件は「コンテンツを完全に削除し、同じ用途を満たすページがサイトに無い」ことでした。裏返すと、同じ用途を満たすページがあるなら、そのURLは消す対象ではなく転送の対象です。

仕分けは次の順で進めます。

1. 削除したいURLを一覧にする。 終了したキャンペーン、取り扱いをやめた商品、統合した記事など、消す理由も1行ずつ書き添えます。
2. 代わりになるページがあるかを1本ずつ判断する。 後継商品のページ、内容を統合した先の記事など、「そのURLに来た人が同じ目的を果たせるページ」があるかどうかで見ます。あるなら、恒久的な転送（301リダイレクト）の候補に回します。
3. 代わりが無いものだけを「消す」グループにする。 関係のないトップページへまとめて転送するのは避けます。行き先が元の内容とかけ離れていると、たどり着いた人の目的が果たせないからです。
4. 消すグループに返すコードを決める。 上の表を見て、404で済ませるか、410を設定するかを決めます。迷ったら404で構いません。
5. サーバーに設定する。 410を返す場合の書き方は次の節に載せます。
6. curl で、返っているコードを確かめる。 画面に「ページが見つかりません」と出ていても、実際のコードが200のことがあります。これを必ず見ます。

例：3本のURLを仕分けてみる

架空のサイトで、次の3本を消すことになったとします。

• /campaign/2025-summer/（2025年夏のキャンペーン。終了済み・次回の予定なし）
• /products/old-model-a/（旧モデルA。後継の /products/model-b/ がある）
• /blog/2019-event-report/（2019年のイベント報告。内容が古く、統合先もない）

手順2で見ると、旧モデルAには後継ページがあります。旧モデルAのページに来た人は、後継モデルの情報を探している可能性が高い。だから旧モデルAは消さず、/products/model-b/ への301転送に回します。

残る2本は、代わりのページがありません。夏のキャンペーンは、今後使わないと決まっています。社内で「終了済みの企画」として区別して記録しておきたいので、410を返すことにしました。2019年のイベント報告は、CMSで記事を消せば自動で404が返る設定です。こちらは追加の設定をせず、404のままにします。

結果は「301が1本、410が1本、404が1本」です。 Google検索から見れば、410と404の2本は同じ「存在しない」として処理されます。違うのは、社内の運用記録としての意味だけです。

410を返す設定の書き方

ここからは、サーバーを自分で触れる担当者向けの設定例です。例のURLは上の /campaign/2025-summer/ を使います。

Apache（.htaccess）

mod_alias の Redirect ディレクティブは、gone を指定すると410を返します。

# 1本だけ
Redirect gone /campaign/2025-summer/

# 配下をまとめて
RedirectMatch gone ^/campaign/2025-summer/

mod_rewrite を使っているサイトなら、[G] フラグでも同じことができます。

RewriteEngine On
RewriteRule ^campaign/2025-summer/ - [G,L]

既存の RewriteRule がある場合は、置く順番に注意します。先に書かれた転送ルールに一致すると、410まで届きません。

Nginx

location ブロックで return 410; を書きます。

# 1本だけ
location = /campaign/2025-summer/ {
    return 410;
}

# 配下をまとめて
location ^~ /campaign/2025-summer/ {
    return 410;
}

どちらのサーバーでも、410のときに表示するページは別途指定できます（Apacheは ErrorDocument 410、Nginxは error_page 410）。指定しなければサーバー既定の簡素な画面になりますが、ステータスコードの働きは変わりません。

CMS・静的ホスティングの場合

CMSでは、リダイレクト管理のプラグインや機能に410を返す設定があることがあります。ない場合、無理に410にこだわる理由はありません。ページを消して、404が返ることを確認すれば足ります。静的サイトのホスティングも同じで、任意のステータスコードを返せないなら404で終わりにします。

返っているコードを curl で確かめる

設定したら、必ず実際の応答を見ます。公式ブログにも、ページに「404 Not Found」と表示されているからといって、実際に404のコードを返しているとは限らない、という注意があります。

ブラウザの表示だけでは判断できません。見るのは応答の1行目、ステータス行です。

1. ターミナルで次を実行します。-I は本文を取らずヘッダーだけを見るオプションです。

   curl -sI https://example.com/campaign/2025-summer/
   

2. 1行目を見ます。HTTP/1.1なら HTTP/1.1 410 Gone、HTTP/2なら HTTP/2 410 と出ます。HTTP/2ではコードの後ろに「Gone」の文字が付かないので、数字だけで判断します。

3. 1行目が 301 や 302 なら、どこかで転送されています。location: の行で転送先を確かめ、410のルールより先に一致している転送ルールを探します。

4. 1行目が 200 なら、ソフト404の状態です。画面は「ありません」と言っているのに、サーバーは「正常」と答えています。

5. 消したURLがいくつもあるときは、一覧をファイルにして、コードだけを並べて確かめます。

   while read -r url; do
     printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$url")" "$url"
   done < removed-urls.txt
   

   -L（転送を追いかけるオプション）は付けません。付けると転送先の最終結果が表示され、途中に余計な転送が挟まっていても気づけなくなります。

ブラウザで確かめたい場合は、Chromeのデベロッパーツールを開き、「Network」タブでそのURLを読み込み直します。一覧の「Status」列に410や404が出ていれば正しく返っています。

4の状態は、Search Consoleでは「ソフト404」として表示されることがあります。Googleのドキュメントは、200を返していても中身が空のページやエラーメッセージのように見える場合、Search Consoleがソフト404エラーを表示すると説明しています。直し方はソフト404の直し方にまとめています。

よくある取り違え

一時停止に404や410を使う

メンテナンスやサーバーの引っ越しで一時的にページを出せないだけなら、4xxは合いません。4xxは「存在しない」という意味で、以前インデックスに登録されていたURLは削除の対象になります。

一時的な停止に合うのは5xx（サーバー側のエラー）です。Googleのドキュメントには、5xxと429を受けるとクロールを一時的に遅くし、Google検索ではインデックス済みのURLはインデックスに保持される（ただし最終的には削除される）、とあります。つまり5xxでも、長く続けばいずれ外れます。停止は短く終えるのが前提です。詳しくは5xxサーバーエラーの記事で扱っています。

404を「放置すると評価が下がるエラー」と思い込む

冒頭で見たとおり、Search Consoleヘルプは「削除して代わりのないページの404」を問題ない例に挙げています。件数を減らすために、関係のないページへ一括で転送する必要はありません。404の件数との付き合い方は404エラーは放置していい？で、放置してよい404と手を入れるべき404の選り分け方を書いています。

自己点検チェックリスト

消す作業を終えたら、1本ずつ当てはめます。

表の3行目で 200 が出たURLは、最初に直す対象です。さきほどの例でいえば、CMSで消した /blog/2019-event-report/ について、テーマ側の「ページがありません」画面が200で返っていたら、それがこれにあたります。自動で404が返るはずの設定でも、一度は確かめておきます。

まとめ：迷ったら404でいい

404か410かは、Google検索の処理の上では同じです。力を入れるべきは、消す前の仕分け（代わりのページがあれば301）と、消した後の確認（curl で実際のコードを見る）の2つです。410は「意図して廃止した」と運用上明示したいときに、設定の手間をかけられるなら選べばよいコードです。

まずは、削除予定のURLを1本選び、curl -sI で今返っているコードを確かめるところから始めてみてください。転送と削除の使い分けに迷ったら、301と302の違いもあわせて参照してください。