The Relaunch Safety Net: Keeping Search Visibility When You Rebuild a UK Website

Redesigns are sold on the promise of a cleaner brand, faster pages and a better user experience. All good. But there is a moment after launch when the team pops the prosecco, the analytics dashboard updates, and organic sessions start to sag. It is not bad luck. It is usually a handful of preventable migration mistakes that were hiding in plain sight during the build.

The launch-day traffic cliff is not inevitable. It is a risk you can manage. The trick is to treat a website rebuild as a search migration with a design layer, not a design project with a search afterthought.

Why the traffic cliff happens

Most post-launch drops come down to a few familiar culprits. URLs change and no one maps the old ones. Content gets trimmed because the new template looks better with fewer words. Internal links point to pages that no longer exist. A staging site gets indexed, or a robots.txt file blocks the live site for a few days. Page speed improves in the lab but worsens in the wild because a consent banner, chat widget or font loader gets added at the last minute.

There is also the quiet problem: content migration. Teams often rewrite pages to fit a new design system and accidentally remove the phrases, headings and internal links that helped those pages rank. The new site may look sharper, but Google is comparing it with the old one and finding less substance.

Pre-launch: audit the site you already have

Before anyone starts mapping redirects, get a clear picture of what you are moving. Crawl the live site and export every URL that returns a 200 status. Add pages that sit behind filters, search results or faceted navigation if they attract traffic. Pull a year of data from Google Search Console and your analytics platform. Identify the top landing pages, the pages with the most backlinks, and the pages that drive enquiries or sales.

Then build a content inventory. For each important URL, note the page title, meta description, H1, word count, internal links in and out, canonical tag, and whether it has a conversion action. This is boring work. It is also the difference between a clean launch and a month of firefighting.

Redirect mapping that actually holds up

A redirect map is not a list of old URLs with the new homepage pasted next to them. It should be a one-to-one map wherever possible. If a product page moves, redirect it to the new product page. If a category is retired, redirect it to the closest relevant category, not the homepage. Avoid chains and loops. A 301 is still the right tool for permanent moves, but it only works if it lands somewhere useful.

Pay attention to query strings, tracking parameters and trailing slashes. Test the map in staging before launch. Then test it again after launch with a crawler and a manual spot-check. If you have a large ecommerce site, prioritise the pages that already earn organic revenue. The long tail can be tidied after launch; the money pages cannot wait.

Content migration is not a copy-and-paste job

When content moves into a new template, the temptation is to cut, rewrite and improve everything at once. That creates too many variables. Keep the launch migration as close to the original as possible. Preserve titles, headings, body copy, internal links and image alt text unless there is a clear reason to change them. If you want to rewrite content, do it as a separate phase after launch so you can measure the impact.

Check that metadata survives the move. Check that canonical tags point to the right place. Check that structured data is valid. Check that internal links go to the new URLs, not the old ones. A broken internal link is not just a UX annoyance; it is a signal that the migration was rushed.

Technical launch checks

This is the unglamorous list that saves careers. Remove noindex tags from the live site. Make sure robots.txt is not blocking important areas. Disable staging-site access or password-protect it. Submit the new sitemap in Google Search Console. Verify that canonicals are self-referencing where they should be. If you run a multi-market site, check hreflang. Confirm analytics and consent management are firing correctly. Test forms, checkout flows and key landing pages on mobile.

Also check the things that slow a site down after launch: cookie banners, chat widgets, tag managers, font loaders and hero videos. A site can pass a lab test and still feel sluggish on a mid-range Android phone on a train. UK audiences are not patient with slow retail pages, and neither is Google.

The stakeholder checklist

Someone must own the migration. Not a committee. One person who can say yes or no. Before launch, agree a content freeze, a launch window, a rollback plan and a post-launch monitoring routine. Make sure SEO, development, content, analytics and marketing are in the same room, even if that room is a video call. Assign owners for redirects, tracking, content sign-off and technical checks.

Launch-readiness scorecard

Use this as a blunt yes or no test. If you cannot tick most of these, delay the launch.

What goes wrong in the wild

A common pattern is the UK retailer that rebuilds its category pages, changes the URL structure, and redirects everything to the homepage. Organic revenue drops because Google has lost the page-level relevance. Another is the B2B manufacturer that trims product descriptions to fit a new card layout, then wonders why long-tail enquiries disappear. A third is the membership site that leaves a noindex tag on the new site for four days because no one checked the live environment after the DNS switch.

None of these are exotic failures. They are process failures. They happen when the launch date becomes more important than the launch readiness.

The takeaway

A redesign can absolutely improve search visibility. But it will not do that by default. Protect what you already have first. Audit, map, migrate, test and monitor. Then use the new site as a platform for growth rather than a reason to explain a traffic dip.