410 vs 404: everything engineers need to know in practice

You're sitting in your incident dashboard when the product team decides to kill an old feature page. You grab your server config and return a status code, but which one: 410 or 404? The difference between these two HTTP responses determines how fast search engines stop indexing your dead content—and it matters more than most developers realize. Let me walk you through 410 vs 404, why they're not the same thing, and when each one serves your SEO strategy.

Understanding 404: Not Found

A 404 status code means "Not Found." It tells the browser and search engines that the resource requested doesn't exist right now, but it might exist in the future. This is the catch-all response for broken links, mistyped URLs, and pages that have been temporarily removed. Google treats 404s with patience because they're ambiguous—the server isn't saying whether the page is gone forever or just temporarily unavailable.

In a real scenario, imagine you're running an e-commerce platform. A customer bookmarks a product page. Six months later, you discontinue that product and serve a 404 on that URL. Google will crawl it, see the 404, and eventually stop indexing it. But "eventually" can mean weeks or months because Google assumes the page might come back.

Here's what a basic 404 response looks like in Node.js with Express:

app.get('/old-product/:id', (req, res) => {
  res.status(404).send('Product not found');
});

Or in .NET with ASP.NET Core:

[HttpGet("/old-product/{id}")]
public IActionResult GetOldProduct(int id)
{
    return NotFound(); // Returns 404
}

The 404 response is useful for genuinely broken URLs or pages that might be restored. But if you're intentionally removing content that will never return, 404 is the weaker signal to search engines.

Understanding 410: Gone

A 410 status code means "Gone." It's a permanent removal signal—you're telling search engines "this resource no longer exists and will never exist at this URL again." It's more specific, more intentional, and it forces search engines to act faster.

When you return 410, Google treats it as a definitive instruction to deindex the page. You're not saying "maybe it'll be back"; you're saying "it's permanently removed." Search engines respect this and stop crawling and indexing that URL much sooner than they would with a 404.

Here's the 410 implementation in Express:

app.get('/discontinued-feature', (req, res) => {
  res.status(410).send('This feature has been permanently removed');
});

And in ASP.NET Core:

[HttpGet("/discontinued-feature")]
public IActionResult GetDiscontinuedFeature()
{
    return StatusCode(410); // Returns 410 Gone
}

In practice, let's say you're operating a SaaS platform and you're sunsetting an old integration endpoint. You return 410 on that endpoint. Within days, Google stops crawling it. Within weeks, it's removed from the search index. With 404, that process stretches across months.

How Google Treats Them Long-Term

Here's the nuance that confuses most developers: long-term, Google eventually treats 404 and 410 the same way. Both will eventually be removed from the index. The key word is "eventually."

Google's crawl budget is finite. Every request to your server costs time and resources. When you return 404, Google assumes there's a possibility the page will return, so it recrawls periodically to check. This recrawling consumes your crawl budget. When you return 410, Google says "okay, it's gone forever" and stops wasting crawl budget on that URL.

In a large-scale application, this matters. If you have 10,000 discontinued product pages returning 404, Google might spend weeks or months recrawling them all looking for changes. With 410, that crawl budget is freed up for pages that actually matter—your live products, blog posts, and new features.

Over time (typically 6-12 months), both status codes result in deindexing. But the speed and efficiency are different. The HTTP specification is clear: 410 is permanent, while 404 is ambiguous.

410 Speeds Up Removal of Dead Content

This is the practical win. When you're deliberately removing content—killing a deprecated API endpoint, shutting down a feature, discontinuing a product line—410 is the faster path to deindexing.

Let's say you're running a ride-hailing platform and you're shutting down operations in a specific city. You have 500 location-specific pages that need to disappear from search results. You have two options:

1. Return 404 and wait for Google to eventually deindex them (8-12 weeks)
2. Return 410 and have them removed much faster (2-4 weeks)

The second option also preserves crawl budget. Google won't waste requests checking for updates on those pages. Instead, it can spend that budget crawling your active pages and discovering new content.

Here's a practical middleware approach for handling bulk removals in Express:

const permanentlyRemovedUrls = [
  '/old-blog-post-1',
  '/old-blog-post-2',
  '/discontinued-product-123'
];

app.use((req, res, next) => {
  if (permanentlyRemovedUrls.includes(req.path)) {
    return res.status(410).send('This page has been permanently removed');
  }
  next();
});

Or in ASP.NET Core with a middleware:

public class PermanentRemovalMiddleware
{
    private readonly RequestDelegate _next;
    private readonly HashSet _removedUrls = new()
    {
        "/old-blog-post-1",
        "/discontinued-product-123"
    };

    public PermanentRemovalMiddleware(RequestDelegate next) => _next = next;

    public async Task InvokeAsync(HttpContext context)
    {
        if (_removedUrls.Contains(context.Request.Path.Value))
        {
            context.Response.StatusCode = 410;
            await context.Response.WriteAsync("Permanently removed");
            return;
        }
        await _next(context);
    }
}

This approach gives you a single source of truth for permanently removed URLs and ensures consistent 410 responses across your platform.

Common Mistakes

Mistake 1: Using 404 for intentional removals. If you're deliberately removing content, 404 forces Google to keep recrawling. Use 410 instead. It's the correct signal and it's faster.

Mistake 2: Forgetting to return 410 for API endpoints. Developers often focus on 410 for web pages but forget about API endpoints. If you're deprecating an API endpoint, return 410 (or 410-equivalent if you're using JSON). Search engines may not crawl your API, but the status code still matters for clients and monitoring tools.

Mistake 3: Using 410 for temporary redirects. If content might come back (seasonal pages, temporarily offline features), use 404 or a temporary redirect (307). Don't use 410. Once you serve 410, Google assumes it's gone forever, and resurrecting it becomes harder.

Mistake 4: Not using redirects alongside 410. If you're removing a page but you have replacement content, redirect to the replacement and return 200. Don't use 410 with a redirect—it creates confusion. Either 410 (no replacement) or 301/302 redirect (replacement exists).

Mistake 5: Ignoring crawl budget implications. On large sites, the crawl budget impact of 404 vs 410 is measurable. If you're removing 1,000+ pages, 410 genuinely helps Google spend time on pages that matter.

Key Takeaways

• 404 means "not found, maybe temporary"; 410 means "gone permanently and won't return"
• Google eventually deindexes both, but 410 does it much faster (weeks vs. months)
• Use 410 for intentional, permanent removals; use 404 for broken links or ambiguous cases
• 410 preserves crawl budget by signaling to Google that recrawling is unnecessary
• Avoid mixing 410 with redirects; use redirects (301/302) or 410 alone, not both
• Implement 410s with a centralized list on large sites to ensure consistency
• Long-term SEO impact is similar, but short-term and crawl efficiency favor 410 for intentional removals