HTTP 410 Gone

Quick reference

410 vs 404: when permanence matters

RFC 9110 describes 404 as the server not knowing whether the resource exists or ever existed. 410 is a stronger statement: the server knows the resource existed and knows it is permanently gone. The spec acknowledges that maintaining a record of every deleted resource is often impractical, which is why 404 is acceptable for most deletions — but 410 is preferred when you have the information and care about signaling removal clearly.

The practical difference for crawlers: when Googlebot hits a 404, it may revisit the URL repeatedly over weeks, hoping the resource returns or that it was a transient error. When Googlebot hits a 410, it understands the resource is permanently removed and removes it from the index significantly faster — often within days rather than weeks.

For SEO operations: when you intentionally delete a page with no replacement, return 410. When a URL never existed or you are uncertain about its history, return 404. When the content moved to a new URL, return 301 to redirect to the new location.

Common use cases

Expired promotional or event pages: A sale that ended, a webinar registration that closed, a product launch countdown that is over. These pages existed, served their purpose, and are permanently gone. 410 tells crawlers and users there is nothing here anymore rather than implying the URL might be valid again.

Deprecated API endpoints: An API that moved from v1 to v2 and permanently retired the v1 endpoints. Returning 410 from the old paths is more informative than 404 because it tells API clients: this endpoint existed, it is gone, update your code.

GET /api/v1/users/profile HTTP/1.1

HTTP/1.1 410 Gone
Content-Type: application/json

{"error": "gone",
 "message": "API v1 was retired on 2025-01-01.",
 "migration_guide": "https://docs.example.com/api/v2/migration"}

Deleted user accounts: A user account that was permanently deleted (not just deactivated). Profile pages, posts authored by that user, or public-facing user content that no longer exists can return 410 to clearly communicate permanent removal.

GDPR/data deletion compliance: Content that was removed on legal grounds (user right-to-erasure request, court order) should return 410 to clearly communicate the resource is not temporarily unavailable but permanently removed, which is important for cache invalidation and crawler deindexing.

Implementing 410

Since a server returning 410 must “know” the resource was permanently removed, you need a record of deletions. Common approaches:

Deletion log table: When a resource is deleted from the primary table, insert its URL or identifier into a deletions table with the deletion timestamp. Requests to deleted paths query this table and return 410.

-- PostgreSQL: check deletion record before returning 404
SELECT deleted_at FROM deleted_resources
WHERE path = $1 AND deleted_at IS NOT NULL;

-- If row exists: return 410
-- If no row: return 404

nginx map for static URL lists: For a known list of retired URLs, use nginx to return 410 without hitting the application:

map $request_uri $gone {
    /old-product-page  1;
    /api/v1/legacy     1;
    /promo/2024-sale   1;
    default            0;
}

server {
    if ($gone) {
        return 410;
    }
}

Express.js middleware:

const goneUrls = new Set(['/api/v1/users', '/legacy/endpoint']);
app.use((req, res, next) => {
  if (goneUrls.has(req.path)) {
    return res.status(410).json({
      error: 'gone',
      message: 'This resource has been permanently removed.'
    });
  }
  next();
});

Caching 410 responses

RFC 9110 states that 410 responses are cacheable by default (like 200 and 404). A CDN or browser that caches a 410 will serve it directly without contacting the origin for subsequent requests to the same URL. This is the desired behavior for permanently deleted resources: once the CDN learns a resource is gone, it does not need to re-ask the origin on every request.

To make a 410 cacheable with a specific TTL: add Cache-Control: max-age=31536000 (one year) for truly permanent deletions. If there is any chance the URL will be repurposed later, use a shorter TTL or omit the Cache-Control header to allow the server to send a different response when needed.

410 vs 404 vs 301 vs 451

Frequently asked questions

What is the difference between 404 and 410?

404 means the server cannot find the resource and makes no statement about whether it existed. 410 means the server knows the resource existed and is permanently removed. 410 gives crawlers a stronger signal to remove the URL from their index faster.

Can 410 ever become 200 again?

RFC 9110 says 410 indicates the resource is permanently gone. In practice, nothing prevents a server from later returning 200 for the same URL — HTTP has no enforcement mechanism — but doing so after returning 410 breaks the semantic contract and will confuse clients that cached the 410 response.

Does returning 410 help with SEO?

Yes. Google has confirmed that 410 causes faster deindexing than 404. For pages you want removed from search results quickly, 410 is more effective than 404. For pages where you are unsure whether to permanently remove them, use 404 to preserve the option of re-adding the content later.

Does 410 pass PageRank or link equity?

No. Neither 404 nor 410 passes link equity to another page. If the removed page had valuable inbound links and you have a replacement page, use 301 instead to transfer the link equity to the new URL.

Related guides

HTTP 404 Not Found · HTTP 301 Moved Permanently · HTTP 451 Unavailable For Legal Reasons

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15.5.11. Human-readable guidance by ErrorLookup. · HTTP 410 quick reference →