When a 410 Is Better Than a 404 (and How to Actually Implement It)

A 410 is not just an angrier 404

In our article on 301 vs 404, 410 showed up as one line in a decision list, as the stronger alternative to 404 for content that is gone for good. It deserves its own explanation, because it is the only one of the four status codes (301, 302, 404, 410) that requires certainty, not just an observation. A 404 is almost always a server or application's automatic default whenever something does not respond: nobody actively "chooses" it line by line, it just happens when nothing matches. A 410, on the other hand, always has to be declared on purpose, by a rule someone writing the site deliberately set, because it communicates something the server cannot know on its own: not just "there is nothing here right now" (a 404 already says that), but "there will never be anything here again, and we know it for certain".

That difference has a practical consequence on how search engines behave: a crawler that hits a 404 still keeps the possibility open that the URL will come back (a temporary error, a half-finished deploy, a product back in stock) and generally keeps rechecking that URL for a while before actually removing it from the index. A 410 is a deliberate permanent-removal signal, and Google itself has repeatedly stated it tends to process it faster for dropping a URL from results, even though neither case is instant. So the difference is not "how severe the error is", it is "how certain you are that nothing will ever live at that address again".

Where a 410 actually backfires

Precisely because a 410 communicates certainty, using it when that certainty does not exist is the costliest mistake among the four codes. Two typical cases where it backfires:

• Seasonal or temporarily suspended content. A product discontinued for good is a solid candidate for a 410. A product that is out of stock and will be back in two months is not: a 410 discourages the search engine from rechecking that URL right when, a few weeks later, you actually want it to. In that case the right tool is still a 404 (or, if genuinely temporary with a known date, a 302 toward a heads-up page), not a 410.
• Rules that are too broad. A 410 set on a wildcard pattern or a query-string condition has to be written with the same care as a firewall rule: a condition that is too generic can trigger the 410 on legitimate URLs that only share part of the pattern, permanently shutting the door on real traffic instead of only the traffic you actually meant to stop. Unlike a 301, where getting the destination wrong still sends the visitor somewhere, a wrong 410 simply closes the door, and if the door was the wrong one, the only person who finds out is whoever walks into it.

What a properly implemented 410 actually looks like

In our own redirect module, 410 is picked from the rule-type menu next to 301 and 302, and for that type of rule the destination address is not needed and gets ignored: there is no "where to send" the visitor, only a "there is nothing here anymore, permanently". The technically interesting part is where the response gets generated: it has to fire as early as possible in the request's lifecycle, before the application builds the theme, fetches the product from the database, or prepares page rendering, otherwise you have still wasted all the work a 410 is supposed to avoid in the first place. A correct response includes three elements that are often forgotten when a 410 gets hand-rolled into a config file:

• A real HTTP 410 Gone status, not a 200 with text saying "product unavailable" (the same soft-404 mistake already covered in the previous article, and it applies identically here).
• An X-Robots-Tag: noindex header, which reinforces the signal for crawlers that read that header independently of the status code.
• A minimal page body, translated into the visitor's language, instead of a blank page: a 410 is still a response a real person can land on by clicking an old link, not only something a crawler sees.

A real case: a crawler looping on a poisoned parameter

On our own store, a crawler (Meta's) was looping on URLs shaped like /login?back=... that still carried, inside the parameter's value, the store's old domain from before an address change: over 36,000 requests in a single night, more than 90% of all traffic the server received, each one served with a 200 response and a full page render, meaning the same CPU cost as a genuine request. The problem was not the URL itself (/login is a perfectly legitimate address), it was the combination with that specific parameter value, which no real visitor would ever produce.

We confirmed that a single 410 rule with a query-string condition solves exactly this case, without touching the web server and without touching legitimate traffic: the rule only fires when the back parameter contains the old domain, not on every request to /login. Test results, on three different PrestaShop versions:

• /login?back=http%3A%2F%2Fold-domain.example%2Fx returns 410
• /login?back=https%3A%2F%2Fold-domain.example%2Flogin returns 410
• /login?back=/my-account (legitimate traffic) still returns 200, unchanged

It is the clearest example of what separates a well-built 410 from a hastily built one: the rule does not say "block /login", it says "block only the exact combination we know is the problem", and it checks that condition before building a single line of the page.

In short

404 is almost always a default, 410 is always a deliberate choice, and it should only be used when there is genuine certainty the URL is never coming back. Done right, it is a real HTTP status generated as early as possible in the request lifecycle, with a matching robots header, without wasting the work it is meant to avoid; done with a rule that is too broad, it can permanently shut the door on traffic that was legitimate. For anyone who wants to manage these rules without touching server configuration, a module such as cll_seoredirect is one option, but the criterion for deciding when a 410 is the right call stays the same regardless of the tool.

Module installation and configuration guide

SEO Redirects - 301/302/404 managerManage 301/302 redirects (plain, wildcard or safe regex), monitor 404s and turn them into redirects in one…€49.99View product