410 Gone

What an HTTP 410 Gone status is, how Google de-indexes 410 pages faster than 404s, when to use 410 vs. 404 for permanently deleted content, and how it affects crawl budget.

First published: Jun 27, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #8 in HTTP Errors#14 in HTTP Status Codes#84 in Technical SEO#110 on the site
1 evidence signal on this page

A 410 Gone status code tells search engines a page was intentionally and permanently removed — versus a 404, which just says 'not found' without saying why. Both drop the page from the index eventually; 410 signals permanence more strongly, so Google confirms and removes it a little faster and re-checks it a little less often. The difference is real but modest — not the dramatic '3x faster' figure that circulates online. For most one-off deletions a 404 is fine; 410 earns its keep at scale (mass deletions, migrations with no equivalent URL, spam cleanup). The bigger mistake than picking 404 vs. 410 is a soft 404, which wastes crawl budget forever.

TL;DR — 410 and 404 both remove a URL from Google’s index over time; the real question is speed of the removal decision and crawl-budget efficiency, not whether removal happens. Google’s reference docs treat 404/410 as one 4xx bucket. The “410 is faster” claim is a field-tested, rep-acknowledged nuance — small, not dramatic. The honest number: Google confirms a 410 removal a little faster and re-crawls 410s less often. The oft-repeated “3x faster, 4 vs 12 days” figure is unverified folklore — don’t repeat it. 410 earns its keep at scale (mass deletions, migrations with no equivalent URL, spam/hacked cleanup), and the bigger mistake is a soft 404, which wastes crawl budget indefinitely.

What 410 actually is

410 Gone is a client-error status in the 4xx family. Semantically it’s the “stronger 404”: the resource existed, it was intentionally and permanently removed, and no forwarding address is offered. A 404 makes no claim about intent or permanence — it’s just “not found right now.”

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 Gone

RFC 9110 §15.5.11, the actual HTTP standard, is specific about what “gone” means: the condition is likely permanent — and if you genuinely don’t know whether it’s permanent, the spec’s own guidance is to use 404 instead. Its stated purpose is to help maintenance by telling clients (and crawlers) the link should be removed. Two nuances the spec adds that most write-ups skip: it does not require every permanently-gone resource to use 410, and it does not require the 410 status to stay in place forever — both are left to the origin’s discretion. It also notes a 410 response is heuristically cacheable by default, so an intermediate cache or CDN can keep serving that response until it expires unless you set explicit cache-control headers.

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 Gone

For SEO the distinction lives entirely in intent signaling. Both codes tell a crawler the page shouldn’t be served. The 410 adds “…and don’t expect it back,” which is the bit search engines can act on.

Does Google de-index 410s faster than 404s?

Short answer: yes, but modestly. Here’s the honest version, separated into the three things people conflate.

1. What Google’s documentation actually says. Google’s reference docs don’t carve out special 410 timing. Its crawler documentation states the grouping directly: “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” 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 Its Search docs describe the same mechanics in different words: “Google doesn’t use the content from URLs that return 4xx status codes… URLs that are already indexed and return a 4xx status code are removed from the index.” The removal mechanics are described for 404s and apply the same way — “the indexing pipeline removes the URL from the index if it was previously indexed… The crawling frequency gradually decreases.” At the documentation level, 404 and 410 are functionally identical — 429 is the one 4xx code that gets different treatment (it’s a “try again later,” not a removal signal).

2. What John Mueller has said. Google’s own spokesperson has been on both sides of this, which is itself instructive. Early on he called the difference negligible. Later, after double-checking internally, he corrected himself: “it appears I was wrong there — we do treat 410s slightly differently than 404s,” and 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.” So there is a difference — a slightly faster index-removal decision — it’s just small. Critically, switching to 410 does not stop Google from occasionally re-checking the URL, especially if it still has inbound links.

3. What independent testing shows. The best real data I’ve seen is Reboot Online’s controlled experiment: 119 test URLs over 3+ months. Their finding was about crawl frequency, not raw days-to-deindex — “404’s are, on average, crawled 49.6% more often than 410’s.” In other words, Googlebot spends noticeably less budget re-checking 410s. That’s the crawl-budget argument in concrete form. (Note the caveat: they measured re-crawl frequency because the GSC API couldn’t cleanly measure “still indexed vs. removed.”)

My own framing in HTTP Status Codes: A Complete List has been consistent with all of this: “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.” Believe the “slightly” and disbelieve the “3x.”

The myth to drop

You’ll see “410 de-indexes 3x faster — 4 days vs. 12 days” repeated across a lot of blogs. I’ve never been able to trace that figure to an original, methodology-documented study — it looks like a mutated re-telling of the Reboot number. Don’t cite it. The defensible claim is “a little faster and re-crawled a little less,” full stop.

When to use 410 vs. 404 vs. a redirect

This is a three-way decision, not two.

  • Use 410 when you’re certain the content is gone forever and you want to actively signal that: bulk deletions, retired product lines, spam/hacked-content cleanup, site consolidations where a set of URLs has no replacement. 410 is you taking a position.
  • Use 404 when you’re uncertain, the page might return, or it’s simply not worth the engineering cost to special-case the response. For low-volume, one-off deletions, 404 is fine — the SEO difference won’t be worth a custom implementation.
  • Use a 301 redirect when an equivalent page exists. Don’t 410 something that has a natural replacement — redirect it, pass the signals, and keep the demand. 410 throws that away by design.

One more thing worth being explicit about: none of this — 410, 404, or a redirect — is a lever on backlink equity or topical authority by itself. Whether inbound links keep sending value depends on where they point after you act (a redirect can pass signals to the new target; a 410 doesn’t have anywhere to pass them), not on some automatic property of the status code. Treat backlink and authority consequences as evidence-dependent — check what’s actually linking in and where it goes — rather than assuming a status-code choice guarantees an authority outcome either way.

The soft-404 trap (the mistake that actually costs you)

Picking the “wrong” 4xx code is a rounding error next to serving a soft 404 — a page that returns 200 OK with “not found” messaging in the body. Google keeps crawling soft 404s because, as far as the status code is concerned, they’re live pages. They “will continue to be crawled, and waste your budget.” If you’re deleting content, the goal is a real 404/410, not a friendly “oops, that’s gone” page that still answers 200.

410 during migrations and mass deletions

This is where the choice stops being academic. On a re-platform or a large content prune, you’re deciding the fate of thousands of URLs at once.

  • Migrations: Google’s migration guidance is explicit that content you’re not carrying over should return a real 404 or 410 on the new site. The mental model: redirect what has an equivalent, 410 what’s deliberately retired with no equivalent, and don’t sweat leaving genuinely uncertain URLs as 404s. Keep any redirects in place for a long time (Google suggests at least a year) — but a URL with nothing to redirect to is a 410 candidate, not a forced redirect to a vaguely-related page.
  • Mass deletions (ecommerce delistings, content pruning, consolidations): this is the strongest case for 410. When you kill 50,000 discontinued SKUs or a whole subsection, the crawl-budget savings from 410’s lower re-crawl frequency compound. A quick judgment call for retail: a product that’s genuinely discontinued forever is a 410; a product that’s temporarily out of stock but returning is not — keep that live (a stockout is not a deletion).
  • Implementation at scale: do it with rules, not one page at a time. Match URL patterns in your server config, CDN/edge worker, or CMS — an Nginx location block, an Apache RewriteRule … [R=410], or a bulk plugin — so the whole retired set answers 410 without hand-editing pages.

See the Playbooks tab for a step-by-step mass-deletion runbook.

How Bing handles it (and how to speed it up)

Bing’s mechanism is the same in spirit: delete the page so it returns 404 or 410, keep the URL crawlable (not blocked in robots.txt) so Bingbot can observe the status, and Bing removes it after a re-crawl confirms the removal. Bing’s practical accelerant is IndexNow — ping it on deletion so Bing learns to revisit the URL sooner, and keep your sitemap current. For urgent takedowns (leaked/compliance cases), Bing’s Block URLs tool hides a URL for ~90 days as a stopgap while the permanent 410 propagates.

A caveat on that last paragraph: Bing’s help pages render via JavaScript, which has blocked a clean automated re-verification of the exact current wording. Treat the mechanism above as Bing’s documented practice rather than a freshly-confirmed quote — check Bing Webmaster Tools’ live help page before treating specifics like the ~90-day Block URLs window as final.

How to verify a 410 is working

  • Check the raw status. curl -I https://example.com/gone-page/ should show HTTP/… 410. Browser DevTools → Network tab shows the same. Don’t trust the visible page — trust the header.
  • URL Inspection (GSC). Confirms how Google last crawled it and what status it saw.
  • Coverage / Page Indexing report. Watch for the removed URLs moving out of the indexed set over the following crawls.

Remember the expectation-setting from my remove URLs guide: a page is “removed from the index shortly after the page is re-crawled. Until it is removed, the page may still show in search results.” A 410 doesn’t beat the re-crawl — it just wins the decision once the re-crawl happens.

Related reading in this cluster: the general 404 Not Found status, the head-to-head 404 vs. 410 comparison, and the soft 404 pitfall above.

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 from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin an expert quote first.