How to Redesign a Website Without Losing SEO

In short: the redesign SEO checklist

Before launch:

1. Export every current URL from the sitemap, CMS, crawl, analytics, Search Console, and backlink data.
2. Record which pages receive organic clicks, impressions, conversions, and external links.
3. Assign every old URL one outcome: keep, improve, merge, redirect, or intentionally remove.
4. Preserve high-performing content and the internal links that support it.
5. Build and test a one-to-one 301 redirect map.
6. Validate titles, headings, canonicals, robots rules, structured data, sitemap entries, hreflang, and status codes on staging.
7. Benchmark templates for Core Web Vitals and accessibility.

At launch:

1. Remove staging blocks from the production site—but not from staging itself.
2. deploy redirects, canonicals, analytics, and the XML sitemap with the site;
3. crawl production immediately and test the highest-value journeys by hand.

After launch:

1. Watch Search Console indexing, clicks, impressions, Core Web Vitals, and server errors daily at first.
2. Keep redirects in place for the long term and repair missed links or redirect chains quickly.

First decide whether this is a redesign or a migration

A visual redesign that keeps the same domain, URLs, content, and rendering architecture is relatively low risk. A project becomes a migration when it changes one or more of these:

• domain or protocol;
• URL paths;
• CMS or framework;
• rendering method;
• navigation and information architecture;
• large amounts of content;
• language or regional structure.

The more of these change together, the harder it becomes to identify the cause of a problem. Google's site-move documentation explicitly recommends changing one major thing at a time where practical. If you must change the brand, domain, CMS, architecture, content, and design in one release, increase the testing and monitoring budget accordingly.

Step 1: capture the current search baseline

You cannot protect what you have not measured. Before design decisions change the site, record:

• organic clicks and impressions by page and query;
• conversions or qualified actions from organic landing pages;
• indexed URLs and submitted sitemap URLs;
• pages with external backlinks;
• top internal-linked pages;
• current titles, descriptions, headings, canonicals, robots directives, hreflang, and structured data;
• status codes and redirect chains;
• Core Web Vitals field data for key templates.

Use at least twelve months of Search Console data when seasonality matters. A 28-day comparison can mistake a normal demand cycle for a redesign effect.

Do not reduce the baseline to “organic traffic.” A redesign might lose informational clicks that never mattered, gain fewer but better-qualified visits, or improve conversion while impressions remain stable. Preserve business value, not just volume.

Step 2: create a complete URL inventory

No single source contains every important URL. Combine:

• XML sitemaps;
• a full crawl of the public site;
• CMS exports;
• Search Console landing pages;
• analytics landing pages;
• server logs where available;
• backlink exports;
• paid campaign and email destination URLs.

Deduplicate and normalize the list, but retain evidence columns. A URL absent from the sitemap may still rank, receive backlinks, or support a campaign.

For each old URL, record its page type, organic performance, conversions, backlinks, target topic, and proposed new URL. This spreadsheet becomes the content plan, redirect map, and launch QA list.

Step 3: give every old URL a deliberate outcome

Use five outcomes:

Keep

The URL and intent remain correct. Preserve the address where possible; it is the lowest-risk option.

Improve

The URL remains, but the content or experience becomes better. Keep the core intent and any information that explains the page's current performance.

Merge

Several overlapping pages become one stronger resource. Redirect each retired URL to the consolidated page only if it genuinely satisfies the same intent.

Redirect

The content has a clear replacement at a new address. Use a server-side permanent redirect directly from the old URL to the closest relevant new URL.

Remove

The page has no traffic, links, conversions, useful content, or replacement. Return 410 Gone or 404 Not Found intentionally. Do not redirect every removed page to the homepage; that is unhelpful to users and may be treated as a soft 404.

This is where redesigns often go wrong. The new sitemap is designed from an ideal future state while the earned value of the existing site is ignored.

Step 4: preserve intent, not merely words

A page can keep its URL and still lose visibility if the redesign removes the reason it ranked.

For every high-value page, identify:

• the primary question or task it satisfies;
• the sections that answer related questions;
• unique evidence, examples, tools, or media;
• internal links pointing to and from it;
• the search snippet promise created by its title and description.

Improve weak writing, outdated facts, and clutter. Do not replace a useful 1,500-word guide with three brand sentences because the new layout “needs less copy.” Design the template around the information users need.

The inverse matters too: retaining every sentence can preserve content debt. Consolidate deliberately, with performance data and intent as the guide.

Step 5: keep internal authority flowing

Internal links tell users and crawlers which pages matter and how topics relate. A new navigation can quietly remove hundreds of contextual links even when every URL still exists.

Before launch:

• compare internal-link counts for priority pages;
• update links to point directly to final URLs, not through redirects;
• retain useful breadcrumb and related-content paths;
• make important pages reachable through crawlable HTML links;
• avoid navigation that depends on interaction or client-side code before links exist.

Redirects preserve old requests. They are not a substitute for updating the links you control. Troiana's guide to internal links that move rankings explains how to prioritise them.

Step 6: build a one-to-one redirect map

Google's site-move guidance recommends mapping old URLs to their corresponding new locations and using server-side permanent redirects. The essential rules are:

1. redirect each old URL to the closest equivalent content;
2. use 301 or 308 permanent redirects;
3. avoid chains such as old → interim → final;
4. do not send unrelated URLs to the homepage;
5. preserve query parameters when they carry meaningful content or tracking;
6. test every mapping before and after launch;
7. keep redirects live long enough for users, crawlers, and old links—preferably indefinitely when the old URL may still be used.

A redirect map should include old URL, new URL, outcome reason, old status, expected new status, and test result. For a large site, automate the status check; review high-value URLs manually as well.

Step 7: prevent staging accidents

A staging site should not appear in search, but the production site must be indexable at launch. This creates two classic failures:

• staging is publicly indexable and becomes a duplicate site;
• a global noindex or robots block is copied from staging to production.

Protect staging with authentication or network controls first. A robots rule alone does not make private content private. Then maintain a launch checklist that explicitly verifies production robots directives, meta robots tags, X-Robots-Tag headers, canonicals, and sitemap URLs.

Do not rely on somebody remembering to untick one CMS setting.

Step 8: run technical parity checks

Crawl the current and staging sites and compare by template. Verify:

If the redesign changes JavaScript rendering, confirm that essential content and links are present in the rendered HTML Google can process. A visually complete browser screenshot does not prove crawl parity.

Step 9: protect performance during the redesign

A more polished site can be slower if it adds large media, custom fonts, animation libraries, client-side rendering, or third-party scripts without budgets.

Benchmark current templates, then set explicit limits for:

• Largest Contentful Paint;
• Interaction to Next Paint;
• Cumulative Layout Shift;
• JavaScript and CSS transfer size;
• image weight;
• font files and variants;
• third-party scripts.

Google describes Core Web Vitals as real-world user-experience metrics, so a perfect lab run on a fast laptop is not enough. Test representative devices before launch and watch field data after real traffic reaches the new templates. See Troiana's Core Web Vitals guide for the diagnostic sequence.

Step 10: launch as a controlled release

Choose a period when the technical and content owners are available and business risk is manageable. Immediately after deployment:

1. verify the homepage and representative templates;
2. test production robots, canonicals, and status codes;
3. crawl the new site;
4. test the redirect map;
5. submit the final XML sitemap in Search Console;
6. verify analytics and conversions;
7. inspect logs and error monitoring;
8. test forms, checkout, search, login, and other priority journeys;
9. confirm staging remains inaccessible or noindexed;
10. keep a rollback plan ready for functional failures.

Do not launch on Friday evening and assume rankings can be checked on Monday. The first crawl often reveals mistakes while they are still easy to correct.

Step 11: monitor the right things after launch

Some fluctuation is normal while Google recrawls old and new URLs. Google's documentation notes that a move completes only after Googlebot has visited the old and new URLs involved; that timing varies with site size and crawl frequency.

Watch daily for the first week, then weekly through the stabilisation period:

• organic clicks and impressions by page type and query cluster;
• indexed and excluded pages;
• 404, 410, 5xx, and redirect responses;
• sitemap processing;
• duplicate or alternate canonical reports;
• Core Web Vitals field data;
• conversion rate and form completion;
• branded and non-branded search separately.

Compare like with like: day of week, season, country, device, and page type. Site-wide averages can conceal a serious loss in one valuable template.

When a page declines, check the evidence in order: status and indexability, redirect target, canonical, rendered content, title and intent, internal links, structured data, performance, then external demand. Do not rewrite everything before confirming the page can be crawled and indexed.

What not to change at the same time

If possible, avoid combining all of these in one launch:

• domain change;
• CMS or framework change;
• complete URL rewrite;
• navigation replacement;
• large content purge;
• brand rename;
• analytics migration;
• new international structure.

Sometimes the business requires a single coordinated release. When it does, document each change, preserve a strong baseline, and make the rollback boundary clear. The goal is not to fear change; it is to retain the ability to diagnose it.

Sources

• Google Search Central: Site Moves and Migrations
• Google Search Central: Understanding Core Web Vitals
• Google Search Console Help: Core Web Vitals Report

Common questions