410 Gone

The short version: If you are a visitor, there is nothing to fix. The page was removed deliberately and no replacement exists, so search the website or use its navigation instead. If you own the website, confirm the 410 is intentional; where a genuine replacement exists, serve a 301 to that specific URL rather than a 410.

Key takeaways

• 410 Gone means the resource was here, has been removed deliberately and permanently, and no forwarding address exists. It is a statement of intent, which is exactly what a 404 is not.
• A 404 is agnostic: the server cannot find anything at that URL and does not claim to know why, or whether it ever existed. A 410 says the removal was on purpose and is not going to be reversed.
• Google treats 410 as a marginally stronger removal signal than 404 and such URLs tend to leave the index slightly sooner, but both eventually get there. Speed is not the main reason to use it.
• Use 301 instead when a genuine replacement exists. Redirecting a deleted page somewhere loosely related is worse than a clean 410, and search engines discount irrelevant redirects as soft 404s regardless.
• A high count of 410s is not a problem in itself. It is a correct response, so a site retiring expired listings properly will produce many. A sudden spike on URLs that should still work is the thing to investigate.

Error type

HTTP 4xx client error

Whose side

Almost always the website, and usually on purpose

Fix difficulty

Easy

Common cause

The resource was permanently removed

What does 410 Gone mean?

A 410 Gone is an HTTP status code telling the client that the resource was available at this URL, has been intentionally removed, and will not be available again. RFC 9110 frames it as the origin server knowing the condition is likely permanent, and recommends it where the removal is deliberate and the owner wants remote links to that resource to be removed as well. That last part is the point of the code. A 404 says only that nothing was found, which could mean a typo, a broken link, a resource that never existed, or one that is temporarily missing. A 410 removes the ambiguity by stating that the absence is intentional and settled.

For search engines the difference is real but modest. Google treats 410 as a slightly stronger removal signal than 404, and URLs returning it tend to fall out of the index a little sooner, though both arrive at the same destination in the end. The stronger argument for using it correctly is operational. Expired job listings, discontinued products, deleted user content, and sunset API versions are all genuinely gone, and saying so plainly stops crawlers and clients retrying indefinitely, keeps your own error reporting honest, and makes a spike of unexpected 410s a signal worth acting on rather than noise mixed in with ordinary 404s.

410

HTTP status code

4xx

Client-side error class

301

Use this instead when a replacement exists

How the 410 Gone error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

410

Gone

This resource has been permanently removed.

• 410 Gone
• HTTP Error 410
• Error 410
• HTTP 410
• 410 Gone nginx
• Status 410

410 vs 404, 301 and 503

These are the four honest answers for a URL that is not serving its usual content, and they differ on permanence and replacement.

Choosing between 410, 404, 301 and 503

All four are legitimate answers for a URL that is not serving its usual content, and the right one depends on whether the resource is coming back and whether anything replaces it.

What causes 410 Gone?

• Content retired on purpose: an expired job posting, a discontinued product, a closed event, or an old promotion that the website removes as a matter of routine.
• A user or author deleting their own content, where the website chooses to record the removal as permanent rather than serving a generic 404.
• An API version being sunset, where the endpoint answers 410 to make clear the version is withdrawn rather than temporarily broken.
• A deliberate cleanup of URLs that were indexed by mistake, using 410 to have them dropped rather than waiting out repeated 404 crawls.
• A rewrite rule, plugin, or CDN configuration returning 410 by accident on URLs that should still be live, which is the one case where a 410 really is a fault.
• A migration that removed a whole section of the website and mapped it to 410 wholesale, including URLs that did have valid replacements and should have been redirected.

How to find the cause fast

1. Run curl -I on the URL to confirm the status is genuinely 410 rather than a 404 or a soft 404 page returning 200.
2. Check the URL against your own list of retired content. If it should still be live, the 410 is coming from a rule rather than from your application logic.
3. Look at whether a specific replacement exists. A URL that has a direct successor should be serving a 301 to it rather than a 410.
4. Watch the trend rather than the count. A steady stream of 410s from expiring content is healthy; a sudden spike is a deployment or configuration problem.

Terminal

curl -I https://example.com/jobs/expired-listingHTTP/1.1 410 Gone# deliberate: the listing expired and is not coming back

How 410 Gone looks from the outside

A 410 is a valid response, so the server looks entirely healthy from outside and an up-or-down check will report the website up. That is usually correct, because most 410s are deliberate. The failure worth catching is the inverse: a rule or a deployment that starts returning 410 on URLs that should be serving content, which silently removes those pages from search results while every infrastructure dashboard stays green. Watching the actual status code on the URLs that matter, rather than whether the host answers, is what separates an intentional 410 from an accidental one.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 410 Gone

If you are a visitor

1. Accept that the page is gone. A 410 is deliberate, so reloading, clearing cache, or trying another browser will not bring it back.
2. Use the website's search or navigation to look for a current equivalent, such as a newer listing or a replacement product.
3. Check an archive service if you need the old content for reference rather than for a live transaction.
4. If you reached the page from a link on another website, that link is simply out of date, and the website owner cannot fix it from their side.

If you run the website

1. Confirm each 410 is intentional. Compare the URLs returning it against the content you actually retired, and treat anything unexpected as a configuration fault.
2. Serve a 301 instead wherever a genuine, specific replacement exists. Redirecting to the homepage is not a replacement and will be treated as a soft 404.
3. Return a helpful body with the 410 for anything a person may land on: a short explanation plus a link to the relevant category or a search box.
4. Do not use 410 for content that might return. Use 404 where you are unsure and 503 with Retry-After for planned downtime.
5. For a sunset API version, include a body naming the replacement version and announce the date well ahead of the change, so callers are not diagnosing it in production.
6. Make sure your custom error page returns the 410 status itself rather than a 200. A page that says the item is gone while returning 200 is a soft 404.
7. Exclude deliberate 410s from your error alerting thresholds, so a real spike stands out instead of being buried under routine expiry.

Still not fixed? Next steps

• Confirm the 410 is deliberate. Run curl -I on the URL and check whether your application meant to send it or whether a rule, plugin, or deployment is returning it by accident.
• If a spike appears in your logs or in Search Console, compare the affected URLs against what you actually retired. Anything on the list that should still be live points at a bad rewrite rule or a failed deploy.
• Check whether a replacement exists for each removed URL. Where one does, a 301 to the specific successor serves visitors and preserves ranking signals far better than a 410.
• For API versions being sunset, pair the 410 with a body naming the replacement version, and announce the date in advance. A caller who hits an undocumented 410 has no way to know what to do next.
• Make sure the 410 is not being served with a 200 status by a custom error page. A page that says the item is gone while returning 200 is a soft 404, and search engines treat it as one.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Return 410 for a retired path in nginx

# a single retired section, answered without hitting the app
location /promotions/summer-2024/ {
  return 410;
}
# use "return 301 /promotions/current/;" instead when a replacement exists

Return 410 with a useful body from the application

http_response_code(410);
header("Content-Type: application/json");
echo json_encode([
  "error"   => "This API version was retired on 2026-01-31.",
  "use"     => "https://api.example.com/v3/",
]);
// a bare 410 leaves the caller with nowhere to go

Check the status rather than trusting the page text

curl -I https://example.com/jobs/expired-listing
# HTTP/1.1 410 Gone      <- correct
# HTTP/1.1 200 OK        <- soft 404: the page says gone, the status disagrees

How to prevent 410 Gone

The 410 worth catching is the one you did not intend, where a rule or a deployment starts returning it on pages that should be serving content and quietly removes them from search results. Nothing about that looks like an outage, so infrastructure dashboards stay green while traffic drains away. Pulsetic checks your website from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment a URL stops returning the status code you expect, so an accidental 410 surfaces in minutes rather than in next month's traffic report.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• MDN: 410 Gone
• RFC 9110: HTTP Semantics (15.5.11 410 Gone)
• Google Search Central: HTTP status codes and how Google handles them
• RFC 9110: HTTP Semantics