HTTP 410 Gone: what it means and when to use it

A 410 response tells the client “this resource existed here, but it is gone and it is not coming back.” The URL used to serve something real, it has been intentionally removed, and there is no replacement to redirect to. 410 is a 4xx error like 404 is, but it carries a different meaning: 404 means “not found” (maybe it never existed, maybe it was moved, maybe it is just missing), while 410 means “I am telling you deliberately that this is over.”

The distinction sounds academic but has real consequences for search engine indexing, crawl budget, caching behavior, and how automated systems handle your URLs. Returning 410 instead of 404 for pages you actually deleted gives search engines a clearer signal and gets the dead URL out of the index faster.

410 vs 404: the useful difference#

Both are client errors. Both mean the requested resource is not available. But they differ in two important ways:

• Permanence. A 404 is ambiguous: the resource might come back, the URL might be fixed, the 404 might be a bug. A 410 is explicit: the resource is gone on purpose and will not return.
• Search engine behavior. Google treats 410 as a stronger signal than 404. A URL returning 410 gets dropped from the index faster than one returning 404. Google documentation used to say 410 removal was faster; their current guidance says they treat both the same, but independent tests and webmaster experience consistently show 410 results in faster deindexing.

For a URL you deleted with intent – a discontinued product, a canceled campaign landing page, a deprecated API endpoint – 410 is the correct status code. For a URL that is missing by accident or was never supposed to exist, 404 is correct.

When to return 410#

A few clear-cut scenarios where 410 is the right answer:

• Deleted products. You removed a product from your store and you are not replacing it with something similar. Returning 410 tells search engines to stop showing the product page in results. Returning 404 achieves the same eventually, but takes longer.
• Canceled campaigns. A seasonal promotion ended, the landing page is gone, and you do not want it cached. 410 signals the end cleanly.
• Deprecated API endpoints. You removed /api/v1/users in favor of /api/v2/users . If the old URL is not being redirected (more on that below), returning 410 tells API consumers clearly that the endpoint is retired.
• Removed content. An article you took down for legal reasons, a video you unpublished, a blog post you deleted – all valid cases for 410 if you do not intend to replace or redirect them.
• Abandoned user accounts. User profile pages that no longer exist because the user deleted their account can return 410.

The common thread: you deliberately ended the resource and you are not replacing it with something at a different URL. If you are replacing it, use a 301 redirect instead.

When to use 301 instead of 410#

Before returning 410, ask whether there is something equivalent at a different URL. If yes, 301 is almost always better.

• Product replaced by a newer version. Redirect /products/widget-v1 to /products/widget-v2 with a 301. The old URL passes its search ranking signals to the new one. If you 410 the old URL, you discard that signal.
• Old blog post replaced by an updated version. 301 from the old slug to the new one.
• URL structure changed. If you moved /about-us/ to /company/about/ , redirect with 301 across the board. Do not 410 every old URL.
• Domain migration. When you change your WordPress domain, redirect old URLs to the new domain, do not 410 them.

The rule: 301 if there is a destination, 410 if there is not. A 410 is a dead end; a 301 is a forwarding address. Use the right one and search engines will handle the migration gracefully.

Why 410 matters for SEO#

A URL that returns 200 (success) tells search engines the page exists and should stay in the index. A URL that returns 404 says “not found right now, try again later.” A URL that returns 410 says “stop looking, this is permanent.”

Deindexing speed

Google recrawls URLs it knows about on a schedule. When a URL returns 404, Google assumes it might be temporary: a server glitch, a misconfiguration, a brief outage. It keeps the URL in the index for some time, coming back to check again later. Eventually, after enough failed checks, it drops the URL.

When a URL returns 410, Google’s crawler gets a direct signal that the page is permanently gone. It treats this as stronger evidence to remove the URL from the index. The deindexing timeline is shorter, though not immediate.

For sites with a lot of deleted content – discontinued products, expired job postings, removed user profiles – returning 410 cleans up the index faster than 404. This matters because:

• Crawl budget. Search engines allocate a fixed amount of crawling per site. URLs that return 410 get dropped from the crawl queue faster than 404 URLs, freeing up crawl budget for pages that matter.
• Search snippets. An indexed URL that returns 404 can still show up in search results with a “This page no longer exists” snippet until Google removes it. A 410 gets removed faster.
• Site quality signals. A high ratio of 404 URLs in Google Search Console can look like a site with broken links. Cleaning up deleted content with 410 instead of 404 makes the site health signals better.

What 410 does not do

Some important non-claims to avoid making:

• 410 does not prevent crawling. Googlebot will still request the URL to confirm it is gone. Block crawling via robots.txt if you do not want the URL requested at all, but note that a robots.txt block can prevent Google from seeing the 410 and processing it – the URL might stay in the index longer. In most cases, letting the crawler see the 410 is the right move.
• 410 does not pass ranking signals. Unlike a 301, which transfers link equity to the new URL, a 410 discards it entirely. If the deleted page had incoming backlinks you cared about, 301 those URLs to a relevant destination instead.
• 410 is not reversible without recrawl. If you return 410 and then decide to put the page back, search engines will eventually re-index it when they recrawl, but the delay can be significant. Do not use 410 casually – use it when you are certain the URL is gone for good.

How to return 410 in Nginx#

For a single URL or a specific path:

location = /discontinued-product {
    return 410;
}

For a list of specific URLs:

location = /old-page-1 { return 410; }
location = /old-page-2 { return 410; }
location = /old-page-3 { return 410; }

For a pattern (all URLs under /archive/2018/ ):

location ~ ^/archive/2018/ {
    return 410;
}

You can also serve a custom 410 page so visitors see something friendly instead of the raw error:

error_page 410 /gone.html;
location = /discontinued-product {
    return 410;
}
location = /gone.html {
    internal;
}

After editing nginx config, reload with nginx -s reload and verify with curl:

curl -I https://yoursite.com/discontinued-product

The response should include HTTP/1.1 410 Gone . If you see 404, nginx is not returning 410 – check your config. This is the same kind of status-code verification you do when diagnosing 404 errors except now you are confirming the error is intentional.

How to return 410 in Apache (.htaccess)#

Apache uses the RewriteRule directive with the [G] flag:

RewriteEngine On
RewriteRule ^discontinued-product/?$ - [G]

The - tells Apache not to rewrite to a new URL, and [G] means “return 410 Gone.” For multiple URLs:

RewriteEngine On
RewriteRule ^old-page-1/?$ - [G]
RewriteRule ^old-page-2/?$ - [G]
RewriteRule ^archive/2018/.*$ - [G]

Custom 410 error page in Apache:

ErrorDocument 410 /gone.html

Place this at the top of your .htaccess and create a /gone.html file in your web root with the message you want visitors to see.

How to return 410 in WordPress#

WordPress is built on the assumption that every URL routes through index.php , so returning a raw 410 at the web server level requires intercepting the request before WordPress handles it. Three approaches:

Server-level (most efficient)

Use the Nginx or Apache examples above. The request returns 410 without WordPress ever processing it. This is the fastest and most reliable option, especially for a long list of URLs. On shared hosting where you do not have access to the web server config directly, fall back to the WordPress options below.

Redirection plugin

The Redirection plugin (by John Godley) is widely used and supports 410 responses. Install it, go to Tools > Redirection, add a new redirect, and set the HTTP code to 410. The plugin intercepts the request and returns 410 before WordPress renders the missing page.

Redirection plugins add some overhead because PHP still has to load to handle the request. But they are simple to manage through the admin UI, especially if you are handling a handful of URLs rather than a pattern.

Code in functions.php

If you prefer not to add a plugin:

add_action('template_redirect', function() {
    $gone_urls = [
        '/discontinued-product/',
        '/old-page-1/',
        '/old-page-2/',
    ];
    $current_path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
    if (in_array($current_path, $gone_urls)) {
        status_header(410);
        nocache_headers();
        exit;
    }
});

This hooks into the template_redirect action before WordPress renders the page. For a dynamic list of URLs – stored in a custom post meta field, for example – replace the hardcoded array with a query.

Any of these approaches will work, but server-level rules are the most efficient and the most resilient. If your site gets hit with millions of bot requests for deleted URLs, server-level 410 responses do not exhaust PHP workers the way WordPress-level handlers do. The Hostney Cache plugin caches 410 responses at the edge where configured, so repeated requests for the same gone URL do not keep hitting PHP.

The common mistake: returning 200 for deleted content#

One of the most damaging mistakes when you delete content is letting the URL return 200 with a “This post has been removed” message. From a user perspective, it looks clean – visitors see an explanation. From a search engine perspective, it is a disaster:

• Google still indexes the URL. Returning 200 tells Google the page exists and should stay in the index.
• The soft 404 problem. Google has detection for “soft 404s” – pages that return 200 but appear to be error pages based on content. These get flagged in Search Console under “Indexed, though blocked by robots.txt” or similar reports, but the detection is imperfect. Some soft 404s stay indexed indefinitely.
• Duplicate content. If dozens of deleted pages all return the same “This content is gone” message with a 200 status, Google sees many pages with identical content. This can dilute quality signals across the site.

Always return the correct status code. If the page is gone, return 410 (or 404 if you want the ambiguity). Do not return 200 with a “gone” message. The content shown to the user matters less than the status code, as far as search engines are concerned.

410 and robots.txt#

A common question: should I block crawlers from the gone URL via robots.txt after setting up 410? In most cases, no. Here is why:

• Blocking crawls prevents the 410 from being seen. If robots.txt disallows /discontinued-product/ , Googlebot will not request the URL and will not see the 410. The URL can stay in the index longer because Google cannot verify its status.
• robots.txt applies to crawling, not indexing. A URL blocked by robots.txt can still appear in search results (usually without a snippet, just the URL) if it is linked to from other pages. Returning 410 is the way to get the URL deindexed.

The exception: if a URL is causing abuse or bot traffic that you want to stop at the robots.txt level regardless of search engine handling, you can block it. But for pure SEO cleanup of deleted content, let the crawler see the 410 and do its job.

When bots still hammer gone URLs#

Even after returning 410 for a URL, bots and scrapers may keep requesting it for weeks or months. Googlebot will revisit and eventually drop it, but less polite crawlers and scrapers often ignore status codes and keep retrying. If your logs show heavy traffic to deleted URLs, the bot detection layer can distinguish verified search engine bots (which should see the 410) from scrapers (which can be blocked or rate-limited at the edge). On Hostney, scrapers hammering gone URLs trigger the edge scraper detection automatically, so they stop being a resource drain quickly.

410 headers and caching#

A 410 response should include cache headers that signal it is cacheable but worth recrawling periodically. A reasonable default:

HTTP/1.1 410 Gone
Cache-Control: max-age=86400
Content-Type: text/html

This caches the 410 for a day, so browsers and CDNs do not keep re-requesting it every time. Search engines have their own caching logic and will recrawl based on their schedule regardless of what you set.

Do not cache 410 forever ( max-age=31536000 is a year). Search engines need to recrawl to confirm the status, and your CDN should revalidate periodically in case you bring the URL back. A day or a week is usually appropriate.

Verifying 410 is working#

After setting up 410 responses, verify with curl:

curl -I https://yoursite.com/discontinued-product

Look for HTTP/1.1 410 Gone in the response. If it says 404, your configuration is not active yet – check for syntax errors, reload nginx or Apache, and verify the URL matches your pattern.

You can also check Google Search Console’s URL Inspection tool. It shows the status code Google most recently got when crawling the URL. If you recently changed a page to return 410, request re-indexing so Google recrawls and picks up the new status.

When 410 is not worth the effort#

For small sites with a handful of deleted pages, 404 is usually fine. The extra cleanup speed of 410 matters most for:

• Sites with hundreds or thousands of deleted URLs (product stores, classifieds, job boards).
• Sites where deleted URLs are actively being crawled and you want them out of the index fast.
• SEO-sensitive migrations where you need a clean deindexing signal.

For a personal blog where you deleted one old post, letting it 404 is fine. For an e-commerce site that deletes 500 products a month, 410 is worth setting up as a standard pattern. The correct status code for deliberately removed content is 410, and picking the right status code every time is a habit worth having even on smaller sites.

Quick reference#

• Resource deleted on purpose, no replacement: 410
• Resource deleted on purpose, replacement exists: 301 redirect to replacement
• Resource missing by accident or unknown reason: 404
• Resource moved, both old and new should work: 302
• Resource renamed or restructured permanently: 301

Pick the right status code and search engines, browsers, CDNs, and API clients will handle the rest correctly.