言語

410 Gone（永久削除）

HTTP 410 Goneステータスとは何か、Googleが410ページを404より速くインデックスから外す仕組み、永久削除したコンテンツで410と404を使い分ける方法、クロールバジェットへの影響を解説します。

初回公開：2026年6月27日 · 最終更新：2026年8月22日 · 上級者向け
AI執筆者：AI v2
このページには証拠シグナルが1件あります

410 Goneは、ページを意図的かつ永久に削除したことを検索エンジンへ伝えます。理由を示さない404とは違い、410は永続性を強く示しますが、どちらも最終的にはインデックスから外れ、差は小さいものです。単発削除なら404で十分で、大量削除、同等URLのない移行、スパム整理では410の価値があります。404と410の選択より大きな失敗は、ソフト404でクロールバジェットを浪費することです。

TL;DR — 410と404はどちらも時間とともにGoogleのインデックスからURLを外します。問うべきなのは削除されるかではなく、削除判断の速さとクロールバジェットの効率です。Googleの参照文書は404/410を1つの4xxグループとして扱います。「410のほうが速い」という主張は、現場のテストと担当者の説明が示す小さなニュアンスであり、劇的な差ではありません。正直な数字は、Googleが410の削除を少し速く確認し、410を再クロールする頻度も少し低いということです。繰り返される「3倍速い、4日対12日」という数字は検証されていない俗説なので、繰り返さないでください。410が有効なのは大規模な削除、同等URLのない移行、スパムやハッキングの整理です。より大きな失敗は、クロールバジェットをいつまでも浪費するソフト404です。

410の実際の意味

410 Goneは4xxファミリーのクライアントエラーです。意味としては「より強い404」で、リソースは存在していましたが、意図的かつ永久に削除され、転送先も示されません。404は意図や永続性について何も主張せず、単に「今は見つからない」と伝えるだけです。

この主張の根拠 RFC 9110 defines 410 Gone as indicating that access to the target resource is no longer available and is likely to remain unavailable. 対象範囲： HTTP semantics for 410 responses; servers should use 404 when permanence is unknown. 信頼度： 高 · 検証日： IETF: RFC 9110 §15.5.11 — 410 Gone

実際のHTTP標準であるRFC 9110 §15.5.11は、「gone」の意味を具体的に定めています。その状態はおそらく永久であり、本当に永久か分からないなら、仕様自身の案内は404を使うことです。目的は、クライアントやクローラーにリンクを削除すべきだと伝え、保守を助けることです。多くの解説が省くニュアンスもあります。永久に消えたリソースすべてに410を要求しているわけではなく、410を永遠に返し続けることも要求していません。どちらもオリジンの裁量に委ねられます。また410レスポンスは既定でヒューリスティックにキャッシュ可能なので、明示的なCache-Controlヘッダーを設定しないと、中間キャッシュやCDNが期限切れまでそのレスポンスを返し続けることがあります。

この主張の根拠 RFC 9110 does not require every permanently unavailable resource to return 410, nor does it require the 410 status to remain in place indefinitely — both are left to the origin server's discretion. A 410 response is also heuristically cacheable by default unless cache-control headers say otherwise. 対象範囲： HTTP semantics for 410 responses; deployment scope, duration, and caching are origin/CDN-level decisions, not protocol requirements. 信頼度： 高 · 検証日： IETF: RFC 9110 §15.5.11 — 410 Gone

SEO上の違いは、すべて意図のシグナルにあります。どちらのコードもページを配信すべきでないとクローラーに伝えます。410は「……そして戻ることを期待しないでください」という一文を加え、その部分を検索エンジンが利用できます。

Googleは410を404より速くインデックスから外すのか

短く答えると、はい。ただし差は小さいです。 人々が混同する3つの事柄を分けて、正直に説明します。

1. Googleの文書が実際に言っていること。 Googleの参照文書は410の特別なタイミングを定めていません。クローラー文書は、グループ分けを直接こう述べています。 “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クローラーは次の処理システムにコンテンツが存在しないと伝えます。」 この主張の根拠 Google treats 404, 410, and other 4xx responses except 429 the same for Search, does not use their content, and removes previously indexed URLs over time. 対象範囲： Google Search handling of 4xx responses; no exact removal timetable is promised. 信頼度： 高 · 検証日： Google: HTTP status codes and Search Google: How HTTP status codes affect Google's crawlers 検索文書も同じ仕組みを別の言葉で説明しています。“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time.” (翻訳)「Googleは4xxステータスコードを返すURLのコンテンツを使いません。以前使われていたURLが今4xxを返している場合、Googleのシステムは時間とともにそのURLの利用をやめます。」削除の仕組みは404について説明されていますが、同じように適用されます。“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.” (翻訳)「以前インデックスされていたURLはインデックス処理のパイプラインから削除され、新しく見つかった404ページは処理されず、クロール頻度は徐々に下がります。」文書レベルでは404と410は機能的に同じで、異なる扱いを受ける4xxは「後で再試行」を意味する429です。

2. John Muellerが述べたこと。 Googleの広報役はこの問題について両方の説明をしており、それ自体が参考になります。初期には違いは無視できるほど小さいと述べました。その後、内部で確認して訂正し、“it appears I was wrong there — we do treat 410s slightly differently than 404s,” (翻訳)「どうやら私は間違っていました。410は404と少し違う扱いをしています」とし、Googleは*“will sometimes want to confirm a 404 before removing a URL from the index, and we tend to do that faster with a 410.”* (翻訳)「URLをインデックスから外す前に404を確認することがあり、410ではそれを速く行う傾向がある」と説明しました。つまり違いはあります。インデックスから外す判断が少し速いのです。ただし差は小さく、410へ切り替えても、特に被リンクが残っていればGoogleがURLを時々再確認することは止まりません。

3. 独立したテストが示すこと。 私が見た中で最も有用な実データは、Reboot Onlineの管理実験です。119個のテストURLを3か月以上追跡しました。結果が示したのは、インデックスから外れるまでの日数ではなく、クロール頻度です。“404’s are, on average, crawled 49.6% more often than 410’s.” (翻訳)「404は平均すると410より49.6%多くクロールされます。」つまりGooglebotが410を再確認するために使うバジェットは明らかに少ないということです。これがクロールバジェットの議論を具体化します（GSC APIでは「まだインデックスにあるか、削除されたか」をきれいに測れなかったため、再クロール頻度を測定したという注意が必要です）。

私の*HTTP Status Codes: A Complete List* での整理も、これらすべてと一致しています。“404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster. In practical applications, they’re roughly the same.” (翻訳)「404と410は似た扱いです。どちらもページをインデックスから外しますが、410のほうが少し速い。実務上はおおむね同じです。」信じるべきなのは「少し」であり、「3倍」ではありません。

捨てるべき俗説

「410は3倍速くインデックスから外れる、4日対12日」という数字が多くのブログで繰り返されています。私はその数字を、方法論が記録された原典までたどれたことがありません。Rebootの数字が変形して伝わったものに見えます。引用しないでください。 守れる主張は「少し速く、少し再クロールが少ない」までです。

410、404、リダイレクトの使い分け

これは2択ではなく、3方向の判断です。

  • 410を使う場合： コンテンツが永久に消えたと確信し、そのことを積極的に示したいときです。大量削除、終了した商品ライン、スパムやハッキングコンテンツの整理、代替URLのないサイト統合などが該当します。410は自分の判断を明示するコードです。
  • 404を使う場合： まだ不確実、ページが戻るかもしれない、またはレスポンスを特別扱いする実装コストに価値がないときです。少量の単発削除なら404で十分で、SEO上の差はカスタム実装に見合いません。
  • 301リダイレクトを使う場合： 同等のページが存在するときです。自然な置き換えがあるものを410にしないでください。リダイレクトしてシグナルと需要を引き継ぎます。410は設計上、それらを捨てます。

もう1つ、明確にしておく価値があります。410、404、リダイレクトのいずれも、それ自体が被リンクの価値やトピカルオーソリティを操作するレバーではありません。インバウンドリンクが価値を送り続けるかは、実施後にどこを指すかで決まります（リダイレクトなら新しい対象へシグナルを渡せますが、410には渡す先がありません）。ステータスコードの自動的な性質だと考えず、実際にどこからリンクされ、どこへ向かうかを確認して、被リンクとオーソリティへの影響を証拠に基づいて判断してください。

ソフト404の罠（実際にコストが発生する失敗）

「間違った」4xxコードを選ぶことは、ソフト404を返すことに比べれば丸め誤差です。ソフト404とは、本文に「見つかりません」と表示しながら200 OKを返すページです。ステータスコード上はライブページなので、Googleはソフト404をクロールし続けます。“will continue to be crawled, and waste your budget.” (翻訳)「クロールが続き、バジェットを浪費します。」コンテンツを削除するなら、目標は本物の404／410です。200を返し続ける、親切な「おっと、消えました」ページではありません。

移行と大量削除で410を使う

ここで選択は学問上の問題ではなくなります。プラットフォーム移行や大規模なコンテンツ整理では、一度に何千ものURLの運命を決めることになります。

  • 移行： Googleの移行ガイダンスは、新しいサイトへ持ち越さないコンテンツには本物の404または410を返すよう明示しています。考え方は、同等のものがあればリダイレクトし、代替なしで意図的に廃止したものは410にし、本当に不確かなURLは404のままにして慌てないことです。リダイレクトは長期間（Googleは少なくとも1年を提案）残します。ただし、リダイレクト先がないURLは、曖昧に関連するページへ無理に送るのではなく、410の候補です。
  • 大量削除（ECの掲載終了、コンテンツ整理、統合）： 410の最も強い利用場面です。5万件の終了SKUやサブセクション全体を削除するなら、410の低い再クロール頻度によるクロールバジェットの節約が積み重なります。小売での簡単な判断は、永久に終了した商品は410、一時的に在庫切れで戻る商品は410ではないというものです。在庫切れは削除ではないため、ページを生かします。
  • 大規模実装： 1ページずつではなくルールで実施します。サーバー設定、CDN／エッジワーカー、CMSでURLパターンを照合します。Nginxのlocationブロック、ApacheのRewriteRule … [R=410]、または一括プラグインを使えば、ページを手で編集せず退役セット全体が410を返せます。

手順化した大量削除のランブックは、Playbooksタブを参照してください。

Bingの扱い（そして速める方法）

Bingの仕組みも基本は同じです。ページを削除して404または410を返し、Bingbotがステータスを確認できるようURLをクロール可能に保ち（robots.txtでブロックしない）、再クロールで削除を確認した後にBingが外します。Bingで実務上使える加速策はIndexNowです。削除時に通知してBingが早くURLを再訪できるようにし、サイトマップも最新に保ちます。漏えいやコンプライアンス対応など緊急の削除では、恒久的な410が伝播するまでの暫定措置としてBingのBlock URLsツールが約90日URLを非表示にします。

ただし最後の段落には注意が必要です。BingのヘルプページはJavaScriptで描画されるため、現在の正確な文言を自動で再検証できませんでした。上記の仕組みは、最新の引用としてではなく、Bingが文書化している実務として扱ってください。約90日のBlock URLs期間のような細部を最終的な事実として扱う前に、Bing Webmaster Toolsのライブヘルプで確認します。

410が機能していることを確認する方法

  • 生のステータスを確認します。 curl -I https://example.com/gone-page/ は HTTP/… 410を表示するはずです。ブラウザーのDevToolsのNetworkタブでも同じものを確認できます。見えているページを信用せず、ヘッダーを信用してください。
  • URL Inspection（GSC）。 Googleが最後にどうクロールし、どのステータスを見たかを確認します。
  • Coverage／Page Indexingレポート。 その後のクロールで削除URLがインデックス済みセットから外れていくかを追跡します。

私の*remove URLs* ガイドにある期待値も覚えておきましょう。ページは*“removed from the index shortly after the page is re-crawled. Until it is removed, the page may still show in search results.”* (翻訳)「再クロールされた後まもなくインデックスから外れます。外れるまでは検索結果に表示されることがあります。」410は再クロールを飛び越えません。再クロールが起きた時点で、削除判断を有利にするだけです。

このクラスターの関連読解は、一般的な404 Not Foundステータス、正面比較の404 vs. 410、上で扱ったソフト404の落とし穴です。

実際に試す

これはシミュレーションではなく、このサイト上の実際のエンドポイントです。ボタンからアクセスするか、新しいタブで開くか、 curl -i をターミナルで実行すると、サーバーがこの記事で扱う実際のステータスコードを返します。

新しいタブで開く ↗

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。