410 Gone(永久削除)
HTTP 410 Goneステータスとは何か、Googleが410ページを404より速くインデックスから外す仕組み、永久削除したコンテンツで410と404を使い分ける方法、クロールバジェットへの影響を解説します。
言語
このページには証拠シグナルが1件あります
- 関連するライブツールHTTP Status & Redirect Checker
410 Goneは、ページを意図的かつ永久に削除したことを検索エンジンへ伝えます。理由を示さない404とは違い、410は永続性を強く示しますが、どちらも最終的にはインデックスから外れ、差は小さいものです。単発削除なら404で十分で、大量削除、同等URLのない移行、スパム整理では410の価値があります。404と410の選択より大きな失敗は、ソフト404でクロールバジェットを浪費することです。
TL;DR — 410 Goneは、検索エンジンに「このページは以前存在したが、意図的に削除し、もう戻らない」と伝えるステータスコードです。理由を示さず「見つからない」とだけ伝える404(Not Found)に似ていますが、意図が加わります。404は「ここにはない」、410は「設計上、永久に消えた」という意味です。どちらも最終的にはGoogleからページを外しますが、Googleは検索上の扱いを同等として文書化しています。
410とは何か
ブラウザーや検索エンジンがサーバーにページを求めると、サーバーはステータスコードで答えます。200は「ここにあります」、404は「そのURLには何も見つかりません」という意味です。410は「ここには何かがあったが、永久に消えた」という意味です。
404と410の違いは、確実性にあります。404は曖昧です。ページが削除されたのか、誰かがURLを打ち間違えたのか、バグがあり明日には戻るのか分かりません。410はその曖昧さをなくし、意図的に削除し、戻らないと世界に明示します。
Evidence for this claim RFC 9110 defines 410 Gone as indicating that access to the target resource is no longer available and is likely to remain unavailable. Scope: HTTP semantics for 410 responses; servers should use 404 when permanence is unknown. Confidence: high · Verified: IETF: RFC 9110 §15.5.11 — 410 GoneSEOで重要な理由
ページを削除して404または410を返すと、Googleは最終的に検索結果からそのページを外します。重要なのはここです。どちらのコードでも目的は達成できます。 Googleの公開ガイダンスは、検索における2つのコードを同じように扱い、410について特別な削除日程を約束していません。 Evidence for this claim 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. Scope: Google Search handling of 4xx responses; no exact removal timetable is promised. Confidence: high · Verified: Google: HTTP status codes and Search Google: How HTTP status codes affect Google's crawlers
初心者が間違えやすい点を挙げます。
- 即時ではありません。 Googleは新しいステータスに気づくためにURLを再クロールする必要があります。それまでは、ページが検索結果に残ることがあります(キャッシュ済みスニペットが表示される場合もあります)。410が速めるのは判断であって、クロールの予定ではありません。
- URLをブロックしないでください。 ページを削除して
robots.txtでもブロックすると、Googleは410を確認するためにクロールできず、削除を処理できません。クロールできる状態にします。 - 適切な置き換えがあるなら、先にリダイレクトします。 コンテンツが移動した、または自然な代替ページがある場合、通常は
301リダイレクトのほうが適切です。410はページとそこへの需要を消すため、送るべき有用な場所があるときには望ましくありません。
単純なルール
ページが永久に消えたと確信し、それを明確に伝えたいなら410を使います。終了した商品、削除したセクション、スパムの整理などです。まだ分からない、ページが戻るかもしれない、または特別扱いする実装コストに見合わないなら404を使います。1ページだけの削除なら、通常の404でまったく問題ありません。
「どれくらい速いのか」のデータ、John Muellerが実際に述べたこと、移行時に大規模に実施する方法を知りたいなら、Advancedタブへ切り替えてください。
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は意図や永続性について何も主張せず、単に「今は見つからない」と伝えるだけです。
実際のHTTP標準であるRFC 9110 §15.5.11は、「gone」の意味を具体的に定めています。その状態はおそらく永久であり、本当に永久か分からないなら、仕様自身の案内は404を使うことです。目的は、クライアントやクローラーにリンクを削除すべきだと伝え、保守を助けることです。多くの解説が省くニュアンスもあります。永久に消えたリソースすべてに410を要求しているわけではなく、410を永遠に返し続けることも要求していません。どちらもオリジンの裁量に委ねられます。また410レスポンスは既定でヒューリスティックにキャッシュ可能なので、明示的なCache-Controlヘッダーを設定しないと、中間キャッシュやCDNが期限切れまでそのレスポンスを返し続けることがあります。
Evidence for this claim 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. Scope: HTTP semantics for 410 responses; deployment scope, duration, and caching are origin/CDN-level decisions, not protocol requirements. Confidence: high · Verified: IETF: RFC 9110 §15.5.11 — 410 GoneSEO上の違いは、すべて意図のシグナルにあります。どちらのコードもページを配信すべきでないとクローラーに伝えます。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クローラーは次の処理システムにコンテンツが存在しないと伝えます。」
Evidence for this claim 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. Scope: Google Search handling of 4xx responses; no exact removal timetable is promised. Confidence: high · Verified: 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の落とし穴です。
AI要約
Advanced版の要点を短くまとめます。
- 410 Gone=意図的かつ永久の削除。 「見つからない」とだけ伝える404と違い、410はページを意図的に削除し、戻らないことを明示します。
- どちらも最終的にインデックスから外れます。 Googleは404と410を同じ
4xxグループに置き、4xxを返すインデックス済みURLを時間とともに削除し、クロールを減らします。 - 410のほうが速いが、差は小さい。 MuellerはGoogleが410を「少し違う」扱いにして「より速く」削除すると確認しています。Reboot Onlineの119 URLテストでは、404は410より約49,6 %多くクロールされました(インデックス削除までの日数ではなく、クロール頻度の代理指標です)。
- 「3倍速い/4日対12日」という統計を繰り返さない。 出典を追えない俗説です。
- 即時ではなく、再クロールも止まりません。 Googleは特にインバウンドリンクがあるURLを410でも時々再確認します。
- 判断ルール: 410は確実かつ永久の削除(大量削除、同等URLのない移行、スパム整理)、404は不確実または低コスト、301は同等ページがある場合です。
- ソフト404のほうが悪い失敗です。 「見つからない」と表示する
200ページはクロールバジェットをいつまでも浪費します。 - **大規模運用では、**サーバー/CDN/CMSのルールで410を実装し、Bingを速めるためIndexNowを使い、ボットがステータスを見られるようURLをクロール可能に保ちます。
公式ドキュメント
検索エンジンによる一次資料です。
プロトコル
- RFC 9110 §15.5.11 — 410 Gone — おそらく永久の利用不能、保守とリンク削除の目的、適用範囲と期間に関する所有者の裁量、ヒューリスティックなキャッシュ可否を定めるHTTP標準です。
- HTTPステータスコード、ネットワークおよびDNSエラーがGoogle検索に与える影響 —
410 (gone)を含む4xx表と、Googleが4xxURLをインデックスから外す仕組みを説明します。 - HTTPステータスコードがGoogleのクローラーに与える影響 —
429を除くすべての4xxコードが同じように扱われると直接述べます。 - クロールバジェットを最適化する — 永久に削除したページには404/410を返し、ソフト404をなくすよう案内します。
- ソフト404エラー — ソフト404とは何か、本物の404/410より悪い理由を説明します。
- URL変更を伴うサイト移転 — 新サイトへ持ち越さない削除/統合コンテンツには404/410を返し、リダイレクトを維持する期間を案内します。
Bing/Microsoft
- BingまたはCopilotからURLやページを永久に削除する方法 — 404/410を返すよう削除し、クロール可能に保ち、緊急時はBlock URLsツールを使う方法を説明します。
- IndexNow / indexnow.org — 変更/削除したURLを通知し、Bingが早く再確認できるようにします。
出典からの引用
Google、その担当者、独立したテストによる記録上の発言です。各公式リンクは、出典ページの引用箇所へ深くリンクしています。
Google — 410を含む4xxの扱い
- “All
4xxerrors, except429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (翻訳)「429を除くすべての4xxエラーは同じように扱われ、Googleクローラーは次の処理システムにコンテンツが存在しないと伝えます。」 — Googleのクローラー文書。 引用箇所へ - “Google doesn’t use the content from URLs that return
4xxstatus codes. If a URL was previously used but is now returning4xxstatus code, Google systems will stop using the URL over time.” (翻訳)「Googleは4xxステータスコードを返すURLのコンテンツを使いません。以前使われていたURLが今4xxを返している場合、Googleのシステムは時間とともにそのURLの利用をやめます。」 — Google Search Centralの文書。 引用箇所へ - “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ページは処理されず、クロール頻度は徐々に下がります。」 引用箇所へ
Google — クロールバジェットと永久削除
- “Return a
404or410status code for permanently removed pages. Google won’t forget a URL that it knows about, but a404status code is a strong signal not to crawl that URL again.” (翻訳)「永久に削除したページには404または410ステータスコードを返します。Googleは知っているURLを忘れませんが、404ステータスコードはそのURLを再びクロールしないよう強く示すシグナルです。」 — Google Search Centralの文書。 引用箇所へ - “Eliminate
soft 404errors.soft 404pages will continue to be crawled, and waste your budget.” (翻訳)「soft 404エラーをなくしてください。soft 404ページはクロールされ続け、バジェットを浪費します。」 引用箇所へ
John Mueller、Google(二次報道経由)
- “It’s good to double-check these things, and it appears I was wrong there — we do treat 410s slightly differently than 404s.” 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 HTTP result code.” (翻訳)「こうしたことを再確認するのはよいことです。どうやら私は間違っていました。410は404と少し違う扱いをしています。」Googleは「URLをインデックスから外す前に404を確認することがあり、410ではそれを速く行う傾向がある」と述べています。 Muellerのフォローアップに関するSearch Engine Roundtableの報道経由です。最終的な根拠として扱う前にライブソースで再確認してください。 報道を読む
独立したテスト — Reboot Online
- “An analysis of the Google Search Console API data looking at our sample of 119 test web pages shows that 404’s are, on average, crawled 49.6% more often than 410’s.” (翻訳)「119個のテストページを対象にGoogle Search Console APIデータを分析したところ、404は平均して410より49.6%多くクロールされました。」 インデックスから外れるまでの日数ではなく、測定可能な代理指標である再クロール頻度を測っています。 実験を読む
URLを大量に410にするランブック(削除または移行)
一度に多数のURLを退役させるときに使います。終了した商品の範囲、整理するコンテンツセクション、または新サイトへ意図的に持ち越さないコンテンツが対象です。上から順に進めます。
-
URLが本当に永久に消えることを確認します。 410は一方通行です。戻る可能性があるもの(季節商品、一時的な在庫切れ)は410ではありません。ページを生かします。同等の置き換えがあるものは410ではなく301リダイレクトです。将来も戻らず、置き換えもないURLだけを410の一覧に入れます。
-
URLセットを明確なルールに分けます。 5万行のスプレッドシートではなく、パターンを作ります。パス接頭辞(
/archive/、/discontinued/)、クエリの特徴、またはmapで表現できるリストです。ルールとして表現できないなら、安全に扱うには複雑すぎることが多いため、手順1をもう一度確認します。 -
エッジまたはサーバーで410を一括実装します。
- Nginx:
location /discontinued/ { return 410; } - Apache/.htaccess:
RewriteRule ^discontinued/ - [R=410,L](またはRedirect gone /old-path)。 - CDN/エッジワーカー: 一致するパスに
410レスポンスを返します。大量セットへ素早く配信でき、キャッシュにも適しています。 - CMS/プラグイン: 多くのプラットフォームやリダイレクト/410プラグインでは、各ページに触れずURLリストへ410を一括設定できます。
- Nginx:
-
ソフト404ではなく、本物の410本文を返します。 レスポンスヘッダーに
410ステータスが必要です。「消えました」と伝える親切な本文は、ステータスが200ではなく410である限り問題ありません。サンプルを確認し、curl -I <url>がHTTP/… 410を表示することを確認します。 -
URLをクロール可能に保ちます。
robots.txtでブロックしないでください。ボットがURLをクロールできなければ410を見られず、削除を処理できません。そのセットに競合するDisallowルールがあれば削除します。 -
内部リンクとサイトマップを整理します。 退役URLをXMLサイトマップと内部ナビゲーションから削除し、ボットや利用者を死んだページへ積極的に案内しないようにします。Googleが410を再確認し続ける主な理由は、残ったインバウンドリンクです。
-
再クロールを速めます。 Bingには削除URLをIndexNowで通知します。Googleには一括削除を速める方法はありませんが、URL Inspectionと更新済みサイトマップが早く気づく助けになります。数時間ではなく、複数回のクロールが必要になると見込んでください。
-
インデックスからの削除を監視します。 その後数週間、GSCのPage IndexingレポートとBing Webmaster Toolsでセットがインデックスから外れるか追跡します。URLが残る場合は、(a)意図しない
robots.txtブロック、(b)200のソフト404、(c)クローラーにとってURLを「興味深い」ままにする強いインバウンドリンクがないか再確認します。
このランブックを実行しない場合
- 1ページだけの削除: 通常の404で十分です。専用の410ルールは実装コストに見合いません。
- 一時的な削除/在庫切れ: ページを生かします。戻るものを410にしないでください。
- 移動したコンテンツ: 新URLへ301を返します。410は残したい需要を壊します。
- 緊急の法的/漏えい削除: 410を設定し、ステータスが伝わるまでの即時抑制としてBingのBlock URLsツールとGoogleのRemovalsツールも使います。
誤った410を診断する
あるURLが410を返しているのにそうなるはずがない場合、アプリケーションコードのバグだと決めつける前に、次を確認します。大量ルールの失敗には予測できるパターンがあります。
- オリジン、エッジ、CMSのルール。 サーバー設定、CDN/エッジワーカーのルール、CMSレベルのリダイレクトまたはステータスプラグインを確認し、意図より広いパスパターンに一致していないか調べます。
- キャッシュ/CDN層。 410は既定でヒューリスティックにキャッシュ可能です。古いキャッシュ済み410は、元のルールを直した後も、キャッシュエントリが期限切れになるかパージされるまで返り続けることがあります。
- 内部リンクとサイトマップ。 意図した退役セットより広いパス接頭辞の一致によって、対象URLが一括410ルールへ巻き込まれていないか確認します。
- canonical、hreflang、フィード。 URLを指すcanonicalの対象、hreflangの代替、商品/コンテンツフィードの項目があると、410の影響はその1ページを超えます。URLを参照するものを、URLそのものだけでなく追跡します。
- ロールバック。 誤った一致が出たとき、ゼロからルールを再診断せず直ちに戻せるよう、展開前のルール/設定を手元に残します。
このURLは410を返すべきか
What should happen to the removed URL?
削除一覧を分類するプロンプト
Classify each URL in this deletion spreadsheet as keep live, 301 redirect, 404, 410,
or needs human review. Use only the columns I provide: current status, replacement
candidate, permanence, traffic/backlink notes, internal links, and sitemap membership.
Explain each 410 decision, flag unsupported replacement mappings, and output a CSV
plus a validation sample. Do not invent destinations or assume a product is permanent.
[PASTE ROWS AND COLUMN DEFINITIONS]一括410ルールをレビューするプロンプト
Review this server, CDN, or application rule that returns 410 for retired URLs. Find
overbroad path matches, conflicts with redirects, robots.txt blocking, soft-404 200s,
and URLs that might return. Give a minimal safer rule and a pass/fail test matrix.
Preserve the configuration language I provide and do not invent provider syntax.
[PASTE RULE AND REPRESENTATIVE URLS] 退役URL一覧を確認するShell
macOS/Linuxターミナルで、1行に1つの絶対URLを置いたgone-urls.txtを使って実行します。
while IFS= read -r url; do
code=$(curl -sS -o /dev/null -w '%{http_code}' "$url")
printf '%s,%s\n' "$code" "$url"
done < gone-urls.txt410以外の結果は自動的に書き換えず、レビューしてください。リダイレクトやライブURLが意図されたものかもしれません。
同じ一覧を確認するPowerShell
Get-Content .\gone-urls.txt | ForEach-Object {
$r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
[PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\gone-results.csv -NoTypeInformation退役パスへのリンクを探すDevTools Console
パス接頭辞を置き換えてから、ブラウザーのConsoleで実行します。
console.table([...document.links].filter(a => new URL(a.href).pathname.startsWith('/retired/')).map(a => ({text: a.textContent.trim(), href: a.href}))); 410を実装・確認するツール
- 一括HTTPステータスコードチェッカー: 退役セット全体を確認し、誤った200s、リダイレクト、不一致のレスポンスを検出します。
- リダイレクトマップビルダー: 410ルールを書く前に、実際の代替があるURLと削除すべきURLを分けます。
- SEO移行プランナー&バリデーター: 一部のURLを退役させる移行で、リダイレクトマッピングと配信済みステータスを確認します。
- リンクアナライザー: まだ削除URLを指している内部リンクを見つけ、サイトが死んだ移転先を案内し続けないようにします。
- Search Console URL InspectionとPage Indexing: Googleが最後に観測したレスポンスを確認し、再クロール後にセットがインデックスから外れるか監視します。
410の展開を検証する
ステータスと範囲のテスト
実行するテスト: 一括HTTPステータスコードチェッカーで代表的な一致、ニアミス、例外を確認します。**期待結果:**承認した退役URLだけが410を返します。**失敗の解釈:**ルールが広すぎる、狭すぎる、または別のルールに隠れています。**監視期間:**エッジ/オリジンを展開するたびに直後。**ロールバック条件:**ライブURLまたはリダイレクト可能なURLが410になること。
クロール可能性と本文のテスト
**実行するテスト:**各サンプルを通常どおり取得し、robots.txtと生のステータスを調べます。**期待結果:**クローラーがURLを要求でき、レスポンスが410で、親切な本文がそれを200へ変えていません。**失敗の解釈:**robotsルールがシグナルを隠しているか、エラーテンプレートがソフト404を作っています。**監視期間:**直後。**ロールバック条件:**展開が退役パスのクロールをブロックするか200を返すこと。
内部シグナル整理のテスト
**実行するテスト:**内部リンクをクロールし、退役セットについてXMLサイトマップを確認します。**期待結果:**承認した410 URLが現在のナビゲーションとサイトマップに存在しません。**失敗の解釈:**サイトが競合する発見シグナルを送り続けています。**監視期間:**次のサイトマップ/ビルド公開後。**ロールバック条件:**整理が承認セット外のURLのリンクまたはサイトマップ項目まで削除すること。
誤った410の診断テスト
**実行するテスト:**予期せず410を返すURLについて、オリジン/エッジ/CMSルールの範囲、キャッシュ/CDN層、そのURLを参照するcanonical、hreflang、フィード項目を確認します。**期待結果:**一致は意図したもので、canonical、hreflang、フィードの対象に影響がありません。**失敗の解釈:**広すぎるルール、古いキャッシュ済み410、または範囲を誤ったcanonical/hreflang/フィード項目が間違ったステータスを生成しています。**監視期間:**予期しない410が報告されたらすぐ。**ロールバック条件:**直近の既知の正常なルール/設定へ戻し、該当パスのキャッシュをパージすること。
自分で確認する:410 Gone
410の意味と使いどころについて5問です。それぞれ答えを選んでから、解答を確認してください。
時間を使う価値のあるリソース
関連する自分の解説
- HTTPステータスコード完全ガイド — 404と410は「実務上はおおむね同じ」という整理を含む、ステータスコード全体のリファレンスです。
- Google検索からURLを削除する方法(5つ) — 削除手段の中で404/410がどこに位置し、なぜ削除が再クロールに遅れるのかを説明します。
- テクニカルSEO入門 — ステータスコードをより大きな技術的文脈に置く入門書です。
自分の講演
- How Search Works (SlideShare)— クロール、インデックス、ステータスコードがパイプラインへ入る仕組みを説明する講演です。(継続的な免責が適用されます。「これは私が理解しているシステムの説明であり、100%完全または正確とは限りません。」)
業界の資料
- RFC 9110 §15.5.11 — 410 Gone (IETF)— ステータスコードの実際の定義を示すHTTP標準です。
- HTTPステータスコードがGoogle検索に与える影響 (Google Search Central)— 権威ある
4xx処理文書です。 - HTTPステータスコードがGoogleのクローラーに与える影響 (Google)— 429を除く4xxのグループ分けを直接述べます。
- クロールバジェットを最適化する (Google Search Central)— 404/410とクロールバジェットの理由を最も明確に結び付ける公式文書です。
- URL変更を伴うサイト移転 (Google Search Central)— 新サイトへ持ち越さないコンテンツに404/410を使う方法です。
- 404対410:テクニカルSEO実験 (Reboot Online)— 119 URLを3か月以上追跡した管理テストで、404は410より約49,6 %多くクロールされました。
- GoogleのJohn Muellerが404と410のSEO上の混乱を説明 (Search Engine Journal)— Muellerが初期に「実質的な差はない」とした説明を扱います。
- Googleが404と410のレスポンスコードを同じように扱うようになった (Search Engine Roundtable)— Muellerが小さな差を認めたフォローアップを扱います(タイトルは皮肉なので本文を読んでください)。
- BingまたはCopilotからURLを永久に削除する方法 (Bing Webmaster Tools)— Bingの404/410とIndexNowによる削除の仕組みです。
変更履歴
2026年8月22日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月8日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月8日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
Try it live
This is a real endpoint on this site — not a simulation.
Hit it from the button, open it in a new tab, or
curl -i it from your terminal, and the server answers with the actual status code this article is about.