Out-of-stock and discontinued products: what to do with their URL without losing SEO or sales
Disabling an out-of-stock product looks like the tidy option, but it turns a URL with traffic into an error. We explain what to do in each case (temporarily out of stock, discontinued with a replacement and without one), which HTTP status code applies and how to offer alternatives.
A product sells out. Someone in the store disables it so that it doesn't show up in the category. A week later, Google crawls its URL and finds an error; the customer who arrives from an old link, a search or an email from months ago sees a "not found" page and leaves. That product page had years of links, reviews and rankings.
What to do with a product that can't be bought depends on why it can't be bought. A product out of stock for two weeks is not the same as one you will never stock again.
Three different situations
| Situation | What to do with the URL | HTTP status code |
|---|---|---|
| Temporarily out of stock | Keep the product page, notify and offer alternatives | 200 |
| Discontinued with a direct replacement | Redirect to the replacement | 301 |
| Discontinued without a replacement | A page that explains and offers alternatives, or let it disappear | 404 or 410 |
Temporarily out of stock: the page stays
If the product is coming back, the product page must stay live:
- It returns 200, with its price and its content.
- In the structured data, availability changes to
OutOfStock. That way Google knows and doesn't show the product as available in the results when it isn't. - A clear notice above the add-to-cart button, with the button disabled or replaced by "Notify me when it's back".
- If you know when it is coming back, say so.
- Available alternatives just below: same category, same brand, similar features.
What you must not do is disable it. A disabled product stops being a page and becomes a redirect or an error, depending on how it is configured.
Discontinued with a replacement: 301
When the manufacturer brings out a new model that replaces the old one, or you change supplier and have an equivalent, a permanent 301 redirect to the replacement's product page is the right answer. It passes on most of the signal the old URL had, and the customer lands on something they can buy.
The condition: the replacement must genuinely be equivalent. Redirecting a specific coffee maker to another coffee maker from a different range, or worse, to the "Small appliances" category, confuses the customer.
Discontinued without a replacement: 404 or 410, but with a way out
If the product isn't coming back and there is no equivalent, the URL should stop existing for search engines. A 404 status code says "not here"; a 410 says "gone and not coming back". Google treats both in a similar way and stops crawling the URL over time; 410 is the more explicit signal when the decision is final.
That doesn't mean visitors have to see an empty page. The error page can show the name of the product they were looking for and a selection of alternatives from its category. The search engine gets the right status code and the customer gets something to buy.
What PrestaShop does out of the box
In the SEO tab of the product page you can specify what to do when a product is disabled: show an error or redirect (permanently or temporarily) to another product or to a category. It works, but it has limits:
- It has to be configured product by product, and nobody does that when disabling fifty references.
- If the product is deleted, the setting disappears with it and the URL simply returns an error.
- There are no alternatives on the error page.
In addition, the behaviour varies between versions. PrestaShop 9 handles route errors differently from PrestaShop 8 in some cases of products or categories that no longer exist, and an un-updated 1.7 or 1.6 store carries even bigger differences. If you are thinking of migrating, make a note: it is a good moment to review how old product pages respond.
Migrations and URL changes
When you change platform or URL structure, or reorganise the catalogue, the problem multiplies: hundreds of old addresses that no longer correspond to anything. You need a mapping table (old URL, destination, redirect type), applied only when the URL really doesn't exist, so as not to slow down the pages that work. Check for chains too: if A goes to B and B to C, redirect A straight to C.
What also needs cleaning up
- Internal links: menus, featured product blocks, blog posts and emails that point to withdrawn products.
- Sitemap: it should not include URLs that redirect or return errors.
- Feeds for Google Shopping and marketplaces: an out-of-stock product should be listed as such or removed, depending on the platform.
- Search Console: the pages report warns you about 404s and soft 404s.
Common mistakes
- Disabling temporarily out-of-stock products.
- Redirecting everything withdrawn to the home page or to a general category.
- Deleting products with a history instead of disabling them and redirecting.
- Structured data that still says "InStock" for an out-of-stock product.
- Redirect chains after several reorganisations.
- An error page with no route to other products.
Checklist
- Decide per product: temporary, replacement or permanent withdrawal.
- Out of stock: 200, OutOfStock, notice and alternatives.
- Replaced: 301 to a genuine equivalent.
- Withdrawn: 404 or 410 with visible alternatives.
- A mapping table for every migration, with no chains.
- Clean internal links, sitemap and feeds.
- Check Search Console every month.
How to do it in PrestaShop
RKR Product Rescue handles each case appropriately: an out-of-stock product keeps its page with a notice, a disabled button, alternatives and OutOfStock with the real price; a disabled product leads to an alternatives page with a temporary redirect and noindex; a deleted product shows alternatives and returns a 404. Alternatives can be chosen by hand per product or in smart mode, and the module tells you how many sales it has recovered. For old URLs after a migration, RKR Redirecciones stores each mapping with a 301 or 410, only acts once PrestaShop has decided that the URL doesn't exist, imports the list from the previous store while flattening chains and includes a URL tester.