Separate discontinued sales from discontinued information
A product can stop accepting new orders while customers still need its wiring diagram, dimensions or maintenance guide. Begin by asking why someone follows the old model URL today. Search queries, support enquiries and links from manuals can help identify that purpose, but a lack of recorded visits does not by itself prove that the information is useless.
Ask product and service teams to distinguish end of sale, remaining stock, support availability and replacement status. Publish only the dates and commitments that have been confirmed. For an exporter, those conditions may differ by market or distributor. The page should explain the applicable scope instead of presenting one broad obsolete label as the complete answer.
Choose a URL action using the remaining purpose
Review the old URL together with its documents, current role and possible destination. The table below is a decision framework rather than an instruction to keep every product forever. A meaningful archive can remain useful; an empty page that only announces removal does not become useful merely because it returns a success response.
Record the decision and the responsible reviewer before implementation. During a catalogue redesign, this prevents a broad redirect rule from overriding the judgement made for a high-value support page. Keep equivalent language versions in the review where they exist, since one market’s replacement may not apply to every translated page.
| Current situation | Likely action to assess | Content or evidence to confirm |
|---|---|---|
| Installed customers need documents | Keep a useful archive | Approved manuals and support scope |
| Sales ended but stock varies | Keep status page with accurate enquiry route | Market-specific availability process |
| Same content moved to an archive | Permanent redirect to that archive | Destination preserves the old purpose |
| Successor exists but compatibility differs | Keep old page and explain successor link | Confirmed differences and limitations |
| Content genuinely consolidated elsewhere | Assess redirect to consolidated page | Legacy information remains findable |
| No useful content or relevant destination | Return appropriate 404 or 410 | Removal decision and useful error-page navigation |
Download the planning worksheet (CSV) Editable planning framework; example entries are not measured business results.
Build an archive that answers the old model query
Retain the exact model identifier and mark the sales status near the start. Preserve approved specifications and documents that still support the installed product, with their revisions and limitations. Remove or revise purchase actions that imply ordinary availability. Provide the appropriate support route and say what information a customer needs to supply for a compatibility or replacement check.
If a successor exists, link to it with an explanation of the relationship. A newer model is not necessarily a direct substitute. Record material differences, such as mounting or interface changes, only when the product team has confirmed them. An archive can introduce a replacement while remaining the correct destination for the original model’s documentation.
Use redirects for relevant replacement destinations
Google's site-move guidance cautions against redirecting many old pages to an unrelated homepage, which may be treated as soft 404s. Apply that principle when retiring product URLs: a redirect should send the visitor to information that reasonably fulfils the old page’s purpose. A generic category page is not automatically a relevant substitute.
For example, if an old product page has been moved intact into a support archive, a permanent redirect to that archive can preserve the route. If its content has been genuinely consolidated into a replacement page with the necessary legacy information, review that destination carefully. Otherwise, keeping an archive with a separate successor link may explain the transition more accurately.
Google Search Central: Site moves with URL changes Primary reference for the point discussed in this section.
Return real missing-page responses when removal is appropriate
Google's HTTP status documentation states that 404 and 410 responses are not indexed, and previously indexed URLs returning those responses are removed over time. Use an appropriate missing-page response when the content is gone and no suitable destination remains. A 200 response with only an error message can instead be identified as a soft 404.
The visible error page can still help a person recover through product search, useful categories or support contact. Avoid implying that a suggested product is compatible merely because it appears there. Distinguish a permanently removed item from a temporarily unavailable page, and have the developer verify the actual server response rather than judging the result from appearance alone.
Google: How HTTP status codes affect Google's crawlers Primary reference for the point discussed in this section.
Check documents, links and the resulting buyer route
Update catalogue links and other active navigation to the intended current destinations. Include downloadable files in the review: a preserved page is incomplete if its manual disappears, while an outdated public document may contradict the new status. Keep a record of the old URL, final action, destination and reason so future editors understand the decision.
Test a retained archive, a redirected model and a removed URL from a fresh browser session. Check the status response, redirect destination and contact action. Afterwards, investigate unexpected missing-page reports and support complaints rather than assuming every reported 404 is a defect. The purpose is an accurate route for each old model request; no single URL policy guarantees retained rankings or AI citations.
Sources and scope
- Google Search Central: Site moves with URL changesdevelopers.google.com
Supports relevant permanent destinations and cautions against unrelated homepage redirects.
- Google: How HTTP status codes affect Google's crawlersdevelopers.google.com
Supports 404/410 indexing behaviour and the distinction between real status codes and soft 404 pages.