Website redesign without losing SEO: a migration checklist

A redesign feels like pure upside — a faster, better-looking, more modern site. Then it launches, and organic traffic falls off a cliff. It is one of the most avoidable disasters in digital marketing, and we have been called in to clean it up more times than we would like. The rankings are almost never lost because the new design is worse. They are lost because the migration quietly broke the things search engines relied on: the URLs, the redirects, the titles, the internal links, the structured data. This is the checklist that keeps those things intact.

Why redesigns tank rankings

Google's index is a map of your site as it exists today. Every ranking page has a specific URL, and every link and every stored signal points at that URL. A redesign that changes the URL structure — moving from /services/seo to /what-we-do/seo, dropping a folder, switching CMS — invalidates that map overnight. If the old address returns a 404 instead of pointing at its replacement, the page's accumulated authority has nowhere to go and the ranking evaporates. Add in titles that got rewritten by a theme, internal links that now point at dead pages, and schema that never made it across, and you have the classic post-launch collapse. The design was never the problem. The plumbing was.

Before you touch the design: crawl and inventory

You cannot preserve what you have not measured. Before a single page is rebuilt, crawl the live site and export a complete URL inventory. For each URL, record the current title and meta description, the H1, the indexation status, the structured data present, and — most importantly — its organic performance. Pull the pages that earn clicks and impressions from Search Console, and the pages that earn links from your backlink tool. This tells you which URLs are load-bearing. A page with no traffic and no links can be retired without ceremony; a page that brings in leads every week gets a one-to-one replacement, no exceptions. This inventory becomes the specification the rest of the migration is checked against.

Map every old URL to a new one

With the inventory in hand, build a redirect map: a spreadsheet with the old URL in one column and its destination in the next. The goal is a one-to-one 301 for each removed or changed address, pointing at the most relevant new page — not a lazy blanket redirect of everything to the homepage, which Google treats as a soft 404 and which throws away the signals you were trying to keep. Where a page genuinely has no equivalent, decide deliberately whether to recreate the content or let it 410. Watch for redirect chains, too: old URL to interim URL to final URL bleeds authority and slows crawling, so collapse every chain to a single hop.

Preserve titles, meta, schema and internal links

URLs get the attention, but on-page signals matter just as much. Carry over the title tags and meta descriptions from the inventory rather than letting a new theme auto-generate them — a redesign that silently rewrites every title is quietly re-optimising your whole site by accident. Re-implement the structured data on the new templates so your technical SEO foundation survives the move. Rebuild the internal linking so navigation, related links and in-body links point at the new URLs, not at redirects. And keep the canonical tags honest: each page should self-canonical to its new address, with no leftovers pointing back at the old structure.

Build and test on staging

Do this work on a staging environment that is blocked from search engines — a login wall is safest, since a stray noindex can slip into production if you rely on it alone. Before launch, crawl the staging site exactly as you crawled the live one and diff the two. Check that every important page renders its intended title, meta and schema, that internal links resolve, that the XML sitemap lists only the new canonical URLs, and that the robots file is not accidentally disallowing the whole site. Run the templates through mobile and performance testing while you are here; a redesign is the ideal moment to fix the site speed issues that were dragging you down, rather than importing them into the new build.

Launch day: verify, do not assume

Launch during a low-traffic window and treat the first hours as active verification, not celebration. Spot-check a sample of redirects from the map and confirm each returns a single 301 to the right destination. Confirm the homepage and top revenue pages are indexable, render correctly and load the right metadata. Submit the new sitemap in Search Console and use the URL Inspection tool on a handful of critical pages to confirm Google can fetch and render them. Keep the old sitemap available so the redirects get discovered quickly. If something is wrong, you want to know within the hour, not from a traffic report next week.

Monitor for eight weeks

A migration is not finished at launch; it is finished when the data says it settled. For the eight weeks after go-live, watch Search Console for a spike in 404s and crawl errors, and fix any missed redirect the moment it surfaces. Track your priority keywords and the organic performance of the load-bearing pages against your pre-launch baseline. Some short-term fluctuation is normal as Google re-crawls and re-processes the new structure — a temporary wobble is expected, a sustained decline is a signal to investigate. Re-crawl the full site a couple of times across those weeks to catch broken links and orphaned pages. Done properly, the site recovers to where it was and then benefits from the faster, cleaner build. Done carelessly, you spend the next quarter clawing back rankings you already owned.