Website relaunch without losing rankings: redirect checklist

Most small-business redesigns change addresses without anyone deciding to. The old site had /services/web-design.html; the new one has /web-design/. Customers, directories and search engines still know the old address. If it returns an error, the link value and the rankings built on it have nowhere to go.

The fix is dull but effective: a redirect map that matches every old address to the right new one, tested before launch and watched afterwards. This guide is a working timeline for UK small and medium-sized businesses, based on Google Search Central's site-move documentation and published relaunch checklists. It makes no promises about results, because rankings also depend on content, competitors and many things a redirect cannot control.

Everything below is method, not anecdote: there are no project stories here, real or made up. If you want to see examples of our work, visit the references page.

Benchmark what you have

Record current traffic, enquiries and the pages that bring them in, using your analytics and Google Search Console. You cannot judge the effect of a relaunch without a before picture.

List every address

Google's tips for finding old URLs start with the important ones: check your sitemaps, your server logs or analytics for the most-visited pages, and the links report in Search Console. Your content management system can usually export the rest. Keep the list in a spreadsheet and mark which pages bring traffic, links or sales.

Decide the new structure

Agree the new address scheme before the build is finished. One agency checklist describes the usual way this goes wrong: the developers redirect whichever old addresses they happen to remember, and the gaps only show up after launch, when analytics reveals traffic to pages nobody thought to redirect. Starting from a full inventory, not from the new site's page list, avoids that.

One row per old address. A simple layout:

These two rows are invented examples to show the layout.

Three rules keep the map useful:

1. Match like with like. Send an old page to the new page that answers the same question. Google warns against sending many old addresses to one irrelevant destination, such as the new home page, because it can confuse users and may be treated as a soft 404. Where several old pages have been merged into one, redirecting all of them to the merged page is fine.
2. Use permanent redirects. Google recommends server-side permanent redirects, such as 301 and 308, where technically possible. According to its redirects guide, a temporary redirect such as a 302 is not used as a signal that the target should be canonical, and may help keep the old URL in search results. That is the opposite of what a relaunch needs.
3. Point straight at the destination. Googlebot can follow up to 10 hops in a chain, but Google advises redirecting to the final destination directly; if that is impossible, ideally no more than 3 hops and fewer than 5. A published redirect-map checklist sets a stricter target of zero chains longer than one hop.

Chains build up over time. If the site was relaunched before, old redirects may still exist. Merge them into the new map so that each address resolves in one step. Google adds that chains slow pages down for users and that not all browsers support long chains.

For pages you are not carrying over at all, Google's advice is that the old URLs should return a 404 or 410 status on the new site.

Canonicals

Google's site-move guide says each new URL should have a self-referencing canonical tag. Use an absolute address in it, as Google's canonical guidance advises.

Internal links

Update menus, footers and in-text links to the new addresses. Google tells site owners to link to the canonical URL within their own site, and notes that redirects are slow for users, so your own links should point to the new URLs rather than lean on redirects.

Sitemap

Put the addresses you want to appear in search results in the sitemap, which normally means the canonical ones, written as fully qualified absolute URLs. Google's sitemap guide says it uses the lastmod value only if it is consistently and verifiably accurate, and ignores priority and changefreq. One sitemap can hold up to 50,000 URLs or 50MB uncompressed. Submitting a sitemap is a hint, not a guarantee.

Separate UK and international versions

If you run different versions for different countries, hreflang annotations tie them together. Google's rules in its localised versions guide: each version lists itself and all others, the links must point both ways or they may be ignored, alternate addresses must be fully qualified including http or https, and only ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes are supported. Google's own example marks a UK English page that shows prices in pounds sterling as en-GB. For visitors whose language matches none of your versions, Google recommends an x-default fallback page. Its canonical guidance also says not to list the HTTP version of a page in sitemaps or hreflang instead of the HTTPS one. Update these annotations to the new addresses, or they will point at redirects.

1. Switch the new site live and deploy the redirect rules at the same time.
2. Crawl the old address list and check that every address returns the expected result in a single hop. Google mentions its URL Inspection tool for single addresses and scripts for testing large numbers.
3. Check that robots.txt does not accidentally block the new site, and that no leftover "noindex" rules from the test site remain, which Google's site-move checklist also flags.
4. Submit the new sitemap in Search Console. A relaunch guide from an SEO software vendor suggests adding a sitemap with both old and new addresses to the new property and then re-testing every redirect against your map. That is a practitioner's tip, not a Google requirement: Google's own guide says you can remove the old sitemap once the new one is submitted.
5. Update your Google Business Profile, social profiles and email signatures to show the new website address where needed.

If you are changing domain or subdomain as well, use the Change of Address tool in Search Console in addition to the redirects. Google says it is not needed for an HTTP to HTTPS switch, a www to non-www switch, or path changes within the same domain.

Watch for errors

The agency checklist mentioned above suggests watching Search Console daily for the first 30 days, then weekly for 90 days, then monthly for a year. Any new spike in not-found errors points to old addresses the map missed: add them and put the redirects live straight away.

Compare against your benchmark

After a few weeks, compare clicks, impressions and enquiries for your priority pages with the figures you recorded. Google says a small to medium-sized site can take a few weeks for most pages to move, that larger sites take longer, and that temporary ranking fluctuation during a move is normal. Be wary of drawing conclusions from the first few days.

Keep the redirects

Google's site-move documentation recommends keeping redirects for as long as possible, generally at least one year, and from the users' point of view suggests keeping them indefinitely. The Change of Address help page gives a minimum of 180 days, longer if Google Search still sends traffic to the old addresses. Treat the longer figure as your default.

This is a hypothetical example, not a project we ran. Imagine a small firm whose old site has 40 pages, of which 12 receive almost all the search clicks. The new site merges two service pages into one and renames the contact page.

1. The priority list contains the 12 pages that earn clicks, plus any page with outside links.
2. The two merged pages both redirect to the new combined page, because it answers the same questions.
3. The renamed contact page redirects one-to-one.
4. Four thin news posts with no traffic or links are left out of the map and return a clear not-found page with links to the main sections.
5. On launch day, all 40 old addresses are crawled, and every one in the map resolves to its target in a single step.

Nothing here is complicated. The value comes from doing it completely and checking it, which is why the map and the test log belong in the project deliverables, not in someone's head.

• Redirecting everything to the home page. It looks tidy and helps nobody.
• Leaving temporary redirects in place. A 302 left behind after launch sends the wrong signal.
• Forgetting non-page files. Google reminds site owners to include images, videos, JavaScript and CSS files in the move; PDFs and images may also carry outside links.
• Changing content and addresses together without noting it. If rankings move, you will not know why.
• Dropping redirects after a few weeks. Old links keep arriving long after launch.
• Skipping the test. A redirect that was never checked is a guess.

1. Will you deliver the redirect map as a document I can see and sign off?
2. How will you test the redirects before and after launch?
3. Who monitors errors in the first weeks, and what is the response time?
4. How are existing redirects from earlier versions of the site handled?
5. What is included if rankings dip, and what is billed separately?

A relaunch is more than a new design. Simple presentation sites start from €300 excluding VAT, and we scope bigger migrations individually. See our services or request a quote and tell us about the site you have now.

• Site moves with URL changes – Google Search Central
• Redirects and Google Search – Google Search Central
• Change of Address tool – Search Console Help
• Localized versions of your pages – Google Search Central
• Build and submit a sitemap – Google Search Central
• How to specify a canonical URL – Google Search Central
• Website redesign SEO checklist and redirect map – blennd
• How to relaunch your website without affecting SEO – Ryte