Redesigning or migrating your website without losing traffic

Redesigns, re-platforms and domain moves are when websites lose the most organic traffic, and the causes are usually avoidable: missing redirects, content that didn’t make it across, a staging block that went live. Keeping your search visibility through a migration isn’t luck. It comes from an inventory, a one-to-one redirect map, parity checks and close monitoring, all planned well before launch.

Know what kind of migration you’re running

Migration	What changes	Risk
Redesign on the same URLs	Templates, design and often content	Lower, if content and markup survive
URL changes	Site structure and paths	Medium: every changed URL needs a redirect
Re-platforming	CMS, templates, often URLs and rendering	Medium to high
Domain change	Every URL, plus the signals tied to the old domain	High
Merging sites	Two inventories become one	High: content decisions as well as redirects

Most projects combine several of these. A re-platform usually brings new URLs and a new design with it, so plan for the riskiest element involved.

Start with a complete inventory

You can’t redirect a URL you don’t know exists. Build a single list from:

• A full crawl of the current site, with titles, canonicals and status codes.
• Search Console: every page with impressions or clicks. It keeps 16 months of performance data, so export a baseline before anything changes.
• Analytics: organic landing pages and the pages behind key events such as enquiries and sales.
• Backlinks: URLs other sites link to, from Search Console’s Links report and your backlink tool.
• XML sitemaps, current and old, which often list URLs that a crawl misses.

Tag each URL with its traffic, links and conversions, then decide whether to keep, merge or retire it.

Map every old URL to one new URL

• One-to-one 301s. Redirect each old URL to its closest new equivalent, in a single hop. Where a redirect from an earlier project already exists, update it to point at the new final URL, so you don’t create chains.
• No blanket redirects to the homepage. Google says redirecting many old URLs to one irrelevant page, such as the homepage, can be treated as a soft 404, and visitors land somewhere that doesn’t answer their question.
• Honest endings. A page that’s retired with no equivalent can return a 404 or 410. That’s better than a redirect to something unrelated.

Test the map on staging with a crawler in list mode, before launch rather than after.

We like to start around 12 weeks before launch. The phases overlap on purpose: mapping begins while the inventory is being finished, parity checks run alongside staging QA, and monitoring carries on well past the end of the plan.

Keep content and metadata parity

A new design shouldn’t mean new content by accident. On staging, check that every important page keeps:

• its title, meta description, H1 and heading structure;
• its body copy, images and alt text;
• its internal links, including navigation and footer links;
• its structured data;
• a self-referencing canonical that points at the live domain, not at staging;
• its hreflang annotations, updated to the new URLs in every language version.

Check performance too. New templates often ship more JavaScript than the old ones, and Core Web Vitals are measured on real visits, so a slower template only shows up after launch. Our guide to finding and fixing slow interactions explains where to look.

Protect staging properly

Staging has to stay private until launch, and the way you protect it matters.

If you also add noindex to staging templates, keep a list of where it is, so none of it survives launch.

Pre-launch QA

Crawl staging with its credentials and compare the result with your inventory: every important URL should either exist with the same content or redirect correctly. Check that analytics and key events fire on every new template, that the error page returns a real 404 status, and that the production robots.txt and XML sitemaps are ready to deploy.

Launch day

Launch-day checklist

• ✓Redirects live and tested on your top URLs
• ✓Staging blocks removed and the production robots.txt in place
• ✓No stray noindex tags on live templates
• ✓Canonicals and hreflang pointing at live URLs
• ✓New XML sitemap submitted in Search Console
• ✓Change of Address submitted, for a domain move
• ✓Analytics and key events recording
• ✓Logs watched for 404s and server errors

For a domain move, verify both domains in Search Console and submit the Change of Address once the redirects are live. Google’s site move guidance also suggests submitting sitemaps for both the old and the new URLs when the move starts; warnings about redirects in the old one are expected.

After launch: monitor and be patient

Check daily for the first two weeks, then weekly for at least two months:

• server logs and Search Console for 404s, server errors and redirect loops;
• the Page indexing report and sitemap status for the new URLs;
• clicks and rankings for your top pages against the baseline you exported.

Expect some fluctuation. Google warns that rankings can move around during a move, and that new URLs can take a few weeks or more to appear for a medium-sized site, and longer for a large one.

Organic clicks around a planned and a rushed migration

PlannedRushed

Launch

W−4W0W4W8W12

Organic clicks, pre-launch level = 100

Keep the redirects for at least a year, as Google recommends, and for longer if old URLs still attract links or visits. After a domain change, keep the old domain registered so the redirects keep working.

Redirect mapping, parity checks and launch monitoring are built into every web design and development project we run, and site migrations are a core part of our technical SEO work. Our B2B SaaS re-platforming playbook shows how the phases fit together on a larger project.

---

Got a relaunch date in the diary? Talk to us early and we’ll review your redirect map and launch plan before anything goes live.