Website Redesign Without Losing SEO: A Practical Migration Guide

A redesign is usually driven by good reasons: the old site looks dated, it is slow on mobile, the CMS is painful to update, or the business has changed. The risk is that search engines do not care how the new site looks. They care whether the pages they already trust still exist, still answer the same queries and still load properly. When a relaunch breaks those signals, organic enquiries can drop for weeks or months.

This guide walks through the migration process we follow when rebuilding sites, in the order the work actually happens. It applies whether you are moving from an old custom build to Laravel, from WordPress to Shopify, or simply refreshing templates on the same platform.

Why redesigns lose rankings

Most traffic losses after a relaunch come from a short list of avoidable problems:

• URLs change without redirects. Google and every site linking to you still point at the old addresses. Without redirects they hit a 404 and the accumulated value of those pages is lost.
• Content gets cut. Designers often trim long pages to make layouts cleaner. If the text that answered a searcher's question disappears, the ranking usually follows it.
• The staging block goes live. A "noindex" tag or a blanket robots.txt disallow that protected the test site gets copied to production.
• Internal links are rebuilt from scratch. Menus, footers and in-content links that pointed to important pages are simplified, so those pages lose internal authority.
• Technical changes happen at the same time. A new domain, HTTPS change, platform switch and redesign all at once make problems hard to diagnose.

None of these are unusual. They happen because SEO is treated as a launch-day task instead of a requirement from the first planning meeting.

Step 1: Benchmark and crawl the current site

Before anyone touches the design, record what the current site is doing. You cannot protect what you have not measured.

• Export performance data from Google Search Console for the last 12 months: pages, queries, clicks and impressions.
• Export landing page data from GA4, including which pages generate form submissions, calls or sales.
• Crawl the full site with a crawler such as Screaming Frog or Sitebulb and save the list of every URL, title, meta description, H1, canonical and status code.
• Export your backlink list from Search Console's Links report, plus any third-party tool you use, to see which pages other sites link to.
• Save a copy of your XML sitemap and robots.txt.

Combine these into one spreadsheet. The result is your inventory of pages that matter, and it becomes the backbone of the redirect map.

Step 2: Build the URL map and 301 redirects

Every old URL that has traffic, rankings, backlinks or conversions needs a destination on the new site. The rule is simple: redirect to the closest equivalent page, not to the homepage.

How to map URLs

1. List every old URL in column A.
2. In column B, write the new URL that serves the same purpose. A service page maps to the new version of that service page; a blog post maps to the same post at its new address.
3. Where two old pages are being merged, point both to the merged page.
4. Where a page is being removed with no replacement, decide deliberately: redirect to the nearest parent category if it is genuinely relevant, or let it return a 410 or 404 if nothing fits.
5. Flag any redirect chains (A to B to C) and collapse them so A goes straight to C.

Use permanent 301 redirects at the server or application level. In Laravel this is typically a redirect table or route definitions; in WordPress, a redirect plugin or server rules; in Shopify, the built-in URL redirects tool. Avoid JavaScript or meta-refresh redirects for SEO-critical pages.

Illustrative example: an old site has /services.php?id=4 for its interior design service. The new Laravel site uses /services/interior-design/. The map pairs them one to one, and the old query-string URL returns a 301 to the new clean URL.

Google Search Central's documentation on site moves with URL changes is worth reading before you start; it explains how Google processes redirects and why keeping them in place long term matters.

Step 3: Keep content parity

Content parity means the new version of a page covers at least what the old one did. It does not mean nothing can change. You can rewrite, restructure and improve, but the page should still clearly answer the queries it ranked for.

• Check the Search Console queries for each important page and confirm the new copy still addresses them.
• Keep or improve title tags and H1s for pages that rank well. If you change them, change them for a reason.
• Carry over FAQs, specifications, pricing explanations and other detail that searchers used.
• Keep image alt text and structured data (for example Organization, LocalBusiness, Product or FAQ markup where it was valid).
• Make sure content hidden in tabs or accordions is still in the HTML on page load, not fetched only after a click.

If the redesign is also a content overhaul, consider staging it: launch the new design with existing content first, let rankings settle, then improve pages in batches. That way you know which change caused which effect.

Step 4: Protect the staging site properly

Your staging site should never be indexed, but the method you use matters. The safest option is password protection (HTTP authentication), because search engines simply cannot reach the pages. A noindex meta tag or X-Robots-Tag header also works. A robots.txt disallow alone is weaker, because blocked URLs can still appear in results if they are linked from elsewhere.

Whatever method you use, write it down in the launch checklist so someone is explicitly responsible for removing it on the new production site.

Step 5: Pre-launch and launch-day checklist

Pick a launch time when your team can watch the site for several hours afterwards. A Friday evening launch with nobody available until Monday is a common and avoidable mistake.

Step 6: Monitor after launch

Some ranking movement after a migration is normal while Google recrawls and reprocesses the site. What you are watching for is anything that looks like a broken signal rather than normal settling.

First week

• Crawl the old URL list against the live site and confirm every redirect resolves correctly.
• Check the Pages report in Search Console for sudden jumps in "Not found (404)" or "Excluded by noindex".
• Use URL Inspection on your most important pages to confirm Google can fetch and render them.
• Confirm form submissions, calls and purchases are still being recorded.

First two to three months

• Compare clicks and impressions for your top pages against the benchmark you saved in Step 1.
• Investigate any important page that loses visibility and does not recover: check content, redirects, internal links and indexing.
• Keep the 301 redirects in place. Google recommends keeping them for at least a year, and in practice there is rarely a good reason to remove them.

If you want a broader list of technical checks to run once things settle, our technical SEO checklist covers crawlability, indexing and performance in more depth.

Choosing the right partner for a redesign

A redesign touches design, development, content and SEO at once, and problems usually appear at the handover points between them. When you brief a developer or agency, ask to see how they handle redirect mapping, who owns the launch checklist and how they monitor after go-live. A team that builds websites with SEO requirements built in from the start will treat the URL map as a project deliverable, not an afterthought. If the migration involves significant platform or architecture changes, a dedicated technical SEO review before launch is a sensible safeguard.

Key takeaways

• Benchmark traffic, rankings, conversions and backlinks before the redesign begins.
• Map every valuable old URL to its closest new equivalent with a single 301 redirect.
• Keep the content that answered searchers' questions, even if the design changes.
• Protect staging with a password, and make removing any noindex a named launch task.
• Change as few things at once as possible so problems are easy to trace.
• Monitor Search Console, redirects and conversions closely for the first few weeks, and keep redirects long term.