How to Plan Old URL Redirects When You Redesign or Relaunch a Business Website

2026-10-24

The short answer

Before launch, list every old URL that matters, including downloads and images. Then give each one a decision: KEEP, MOVE, MERGE or RETIRE. KEEP means the address stays the same. MOVE means the page lives at a new address, so the old one needs a permanent redirect to it. MERGE means several old pages now live in one page, so they all redirect to that page. RETIRE means the content is gone for good and there is no true replacement.

This article separates what Google documents from my own planning advice. The Google facts come from Google's site move guidance and its redirect documentation. The rest is practical suggestion, not a rule and not a promise about traffic.

Changing URLs is not required in a redesign. If an address still makes sense and the page still exists, keeping it is often the simplest and safest option. Redirects matter only for the addresses that change or disappear.

What Google says

These points come from the sources above, paraphrased:

Google advises mapping old URLs to their new equivalents and, once the new site is ready, using server side permanent redirects from the old URLs to the new ones.
Of the redirect types, 301 and 308 are the HTTP permanent redirects Google names as recommended where technically possible. Both say that a page has moved permanently.
Temporary redirects such as 302 and 307 are not the signal Google uses to treat the new URL as the permanent, canonical one. For a lasting move, use a permanent redirect.
Google suggests pointing each old URL straight to its final destination and keeping any chain of redirects short.
Google warns against sending many old URLs to one irrelevant destination such as the new home page, because this can confuse users and might be treated as a soft 404. It makes an exception for content that was truly consolidated into a single new page.
If you are not moving some old content to the new site, Google says those URLs should correctly return an HTTP 404 or 410 error response.
Google says to keep redirects as long as possible, generally at least 1 year, so that signals can transfer, including links on other websites that still point to old addresses.
Google also says visibility can fluctuate temporarily during a move, and that how long this takes depends on how many URLs you have and how fast your server responds.

Step 1: Build the list of old URLs

Google's guidance suggests starting with the important URLs. It points to sitemaps, server logs or analytics for the most visited pages, and the Links report in Search Console for pages with internal and external links. Your content management system can often export a full list too. It also says to include images, videos, JavaScript and CSS files that are part of the move.

My practical addition: include downloadable files such as PDFs, price sheets and manuals. They are easy to forget, and people may have bookmarked or emailed those links.

Step 2: Decide KEEP, MOVE, MERGE or RETIRE

This is my planning method, not a Google requirement.

KEEP. The URL stays exactly as it is. Nothing to redirect. Check that it still returns the page and that the content is still right.

MOVE. The page has a matching page on the new site at a different address. Redirect old to new with a 301 or 308, in one hop, to the closest matching page.

MERGE. Two or three thin pages became one stronger page. Redirect each old URL to the merged page. This fits the exception Google describes for consolidated content, but only when the new page really covers what the old ones did.

RETIRE. The service, product or notice no longer exists and nothing matches it. Do not force a redirect to the home page. For genuinely deleted content with no replacement, Google's site move guidance says the old URLs should correctly return an HTTP 404 or 410 error response. Which of the two you choose is a team decision. Either way, a helpful not found page with links to your main sections is good practice, and that suggestion is mine, not Google's.

A worked example (hypothetical)

This is an illustrative example for a made up bakery site. It is not a real client or a real site.

Old URLs and decisions:

/about : KEEP. The address is unchanged.
/cakes.html : MOVE to /cakes/ (301 or 308).
/wedding-cakes.html : MOVE to /cakes/wedding/ (301 or 308).
/birthday-cakes.html and /party-cakes.html : MERGE into /cakes/celebration/ (both redirect there).
/files/2019-price-list.pdf : RETIRE. It is outdated and nothing replaces it, so it returns 404 or 410.
/files/allergen-guide.pdf : MOVE to /downloads/allergen-guide.pdf.
/images/shop-front.jpg : MOVE to /media/shop-front.jpg, if other sites link to it and you want those links to keep working.
/christmas-2018-offer : RETIRE. The offer is long over.

Notice what is missing: no rule sends everything to the home page. A visitor following an old wedding cake link lands on wedding cakes, which is what they expected.

One extra planning detail: if /cakes.html were once redirected to /cakes and later to /cakes/, you would have a chain. Rewrite the first rule so it goes straight to the final address.

Step 3: Assign ownership before launch

A mapping spreadsheet with no owner tends to get half done. Before launch, name one person who owns the decisions for each content group, and one person who owns the technical setup. Typical columns are: old URL, decision, new URL, redirect type, who approved it, and a verified column to tick off after launch.

Ask your developer or host which kind of server side redirect your setup supports. Google's documentation notes this may be rules in a server configuration file or redirect functions in your CMS, and that some platforms have built in options. Client side methods such as JavaScript are a last resort in Google's guidance.

If you are scoping a redesign and want redirects handled as a written deliverable rather than an afterthought, the website project brief guide is a good place to note it. If you would like to discuss a relaunch, you can use the work with me page to send an enquiry, and you will get a written initial response.

Step 4: Update the new site as well

Google's guidance says each new URL should have a self referencing canonical tag, that internal links should point to the new addresses, and that multilingual annotations, if you use them, need the new URLs. It also says that if you added noindex rules to keep new pages from being indexed too early, you should update them once redirects are active.

My caution on that last point: it applies only to development time restrictions on pages that are meant to be public. Keep any intentional noindex or robots exclusions, such as private pages, admin areas or thank you pages. A staging copy should stay protected from the public and from search engines. Keep a sitemap of the new public URLs ready to submit.

Handover and acceptance checklist

Before launch:

Every important old URL, including images and downloads, has a decision.
Every MOVE and MERGE points to a relevant final page, not the home page.
Permanent moves use 301 or 308 and go in one hop.
No accidental temporary redirects remain on permanent moves. Temporary redirects that are intentional, such as for a short notice, are fine.
RETIRE addresses return 404 or 410 as decided, with a helpful not found page.
Canonicals, internal links and the sitemap use new URLs.
Development only noindex or robots blocks are removed from pages meant for public indexing. Intentional exclusions stay, and staging remains protected.
A named person owns the mapping file after launch.

After launch:

Test a sample of old URLs, then all high value ones, with a command line tool or script. Google also mentions the URL Inspection tool for single URLs.
Confirm status codes and destinations match the spreadsheet.
Submit the new sitemap in Search Console.
Watch Search Console for errors and unexpected not found pages, and add missing redirects.
Click through key old links from emails, social profiles and other sites you control.
Update your own links to point to the new addresses, because redirects add a step for users.
Put a review date on the calendar, and do not remove redirects within the first year unless you have a clear reason.

What to expect in search

Google says visibility may move around during a significant change and that things settle over time, depending on site size and server speed. For a small to medium site it describes a few weeks for most pages to move, though it gives this as a general rule, not a deadline. Careful redirects reduce avoidable problems, but no one can promise your traffic will be unchanged, and a redesign changes more than URLs. Content, speed and structure also affect results.

FAQs

Should I use 301 or 308? Both are permanent, and Google names both as recommended. Either is fine for most business sites. Choose whichever your server or platform supports, and use it consistently.

Can I just redirect everything to the home page to save time? This is the mistake Google specifically warns about. It can confuse visitors and might be treated as a soft 404. Redirect each page to its closest match, and let truly deleted pages return 404 or 410.

How long should I keep the redirects? Google says as long as possible, generally at least 1 year, and suggests considering indefinitely from a user perspective. In practice, review the list rather than deleting it on a schedule, and keep redirects unless there is a strong reason to remove them.

Sources

Google Search Central, Site moves with URL changes: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Google Search Central, Redirects and Google Search: https://developers.google.com/search/docs/crawling-indexing/301-redirects