How to Protect SEO During a Website Redesign: A Guide to Relaunching Without Losing Traffic

How do you protect SEO during a website redesign?

Treat the website redesign as a move, not a makeover: inventory every URL that earns traffic, map each old address to a new one, test the redirects and technical signals on staging, launch with an hourly checklist, then monitor Search Console for 90 days. I have followed this five phase method on redesigns since 2012, and it works.

Put simply, Google does not rank your design; it ranks URLs, content and signals attached to them. A website redesign changes all three at once. However, most site owners plan only the visual part and discover the SEO part when traffic drops. In this guide I walk you through every phase in the order I actually use it with clients, so you can relaunch without losing what you built.

I work without agencies or middlemen, so the steps below are the ones I run myself. Some of them I handle within my web design service, where I plan the redesign and the SEO migration as one project instead of two.

Why does a website redesign cause organic traffic to drop?

In my experience, a website redesign hurts organic traffic for five root causes, and they usually arrive together. Each one is preventable, but only if you know it exists before the launch date.

1. URL changes without redirects: the old address returns 404, and Google drops the ranking it held.
2. Deleted or merged content: pages that quietly earned long tail traffic disappear because nobody checked their numbers.
3. Lost internal links: a simplified menu orphans deep pages, so crawlers and users stop reaching them.
4. Slower performance: a heavier theme pushes Core Web Vitals over the thresholds Google watches.
5. Staging leaks or launch mistakes: a noindex tag or a blocked robots.txt travels from staging to the live site.

None of these is a penalty in a website redesign. Instead, they are lost signals. For example, when 15 percent of your URLs return 404, Google simply has nothing to rank there anymore. Therefore, the whole method below exists to keep signals intact while the design changes around them.

What data should you record before the redesign starts?

I call this phase "freezing the measurement". Before anyone touches the new design, you record what the current site earns, page by page. Otherwise you cannot prove a drop later, and you cannot prioritise fixes. In practice, it takes an afternoon.

• Export 16 months of Search Console performance data by page and by query.
• Export the GA4 landing page report with sessions and conversions for the last 12 months.
• List every page that has external backlinks, using whatever backlink tool you already pay for.
• Take a ranking snapshot for your 50 to 100 most important keywords.
• Crawl the whole site and save the export: URLs, titles, meta descriptions, H1s, canonicals, status codes.
• Save a copy of the current sitemap.xml and robots.txt.
• Take a full file and database backup and store it off the server.

As a result, you now hold an address book of the old site. Every later decision, from which pages to keep to which redirects to write first, comes from this list. Keep it in a shared spreadsheet, because you will open it every day of the website redesign project.

Which pages should you keep, merge or delete?

Next, once the inventory exists, I score every URL against three signals: organic traffic, backlinks and conversions. A page that scores on any of the three goes on the "untouchable" list. In addition, pages with none of the three become candidates for merging or deletion.

Here is an example calculation, labelled as an example rather than a client case. For instance, imagine a 400 page site. Search Console shows that 80 percent of clicks come from 60 pages. Those 60 pages therefore keep their content, their titles and ideally their URLs. The remaining 340 pages get a decision each: keep, merge into a stronger page, or delete with a redirect to the closest topic.

If 120 of them merge, you end up with a 120 row redirect map for that group alone. That said, deletion is not the enemy. Thin pages that earn nothing dilute the site, and a website redesign is the natural moment to prune them. Above all, never delete a URL without deciding where its redirect points.

Do you have to change the URL structure?

No, and in most cases you should not. Keeping URLs identical is the single biggest risk reducer in a website redesign. As a result, Google keeps the ranking history, the backlinks keep pointing to a live page, and you skip the redirect map entirely for those pages.

However, sometimes a change is justified. For example, an old CMS may have forced ugly parameter URLs, or the language folders may be inconsistent. In that case I change only what is broken, and I keep the rest. Use a slug generator so new addresses stay short, lowercase and free of special characters.

Google's own guidance on site moves with URL changes makes a related point: change one thing at a time. Swapping the CMS, the design and the domain in one release multiplies the places where something can break. Therefore, if URLs must change, keep the domain and the hosting stable during the same launch.

How do you prepare a 301 redirect map?

The redirect map is a spreadsheet with one row per old URL that will no longer exist. It is the heart of every website redesign, so I build it before the new site is even half finished. In practice, my columns are always the same.

• Old URL, copied exactly from the crawl export.
• New URL, the final address on the redesigned site.
• Status code, almost always 301.
• Priority, based on clicks and backlinks from the inventory.
• Test result, filled in on staging and again on launch day.

Three technical rules protect the map. First, redirect every old URL directly to its final destination, never to another redirect. Chains waste crawl budget, and Google's documentation on HTTP and network errors notes that its crawlers follow at most 10 redirect hops by default. Second, avoid loops, where A points to B and B points back to A. Third, never point everything at the homepage; that is a soft 404 in Google's eyes.

After the map is live, I sample it with my redirect checker to see the real status codes and the number of hops for each row. Then I fix what fails before I move on.

301 or 302: how does the redirect type affect rankings?

The redirect type tells Google whether the move is permanent. According to Google's redirect documentation, permanent redirects such as 301 and 308 signal that the target should become the canonical URL. Temporary redirects like 302, 303 and 307 do not send that signal. For a website redesign, permanent is almost always the right choice.

The same document also explains a few edge cases. An instant meta refresh of zero seconds counts as permanent, while a delayed meta refresh counts as temporary. JavaScript redirects only get processed after rendering, so Google recommends them only when a server side redirect is impossible. In short, use server side 301s and nothing else if you can help it.

When do you need the Change of Address tool?

You need the Search Console Change of Address tool only when the domain or subdomain changes. A redesign on the same domain, a move from HTTP to HTTPS, or a switch between www and non-www does not require it. Google states this directly in its Change of Address help page.

If the domain does change, however, a few conditions apply. You must verify both the old and the new property, and you must use the same Google account for both. The tool then forwards signals to the new site for 180 days. In addition, Google asks you to keep the redirects in place for at least 180 days, and longer if the old domain still receives traffic from Search.

My own rule for a website redesign is stricter, though. I keep redirects for as long as the site exists, because the site move documentation itself suggests keeping them "as long as possible, generally at least one year". Redirects cost nothing to keep; deleting them, on the other hand, costs rankings.

How do you hide staging from Google and open it safely at launch?

Staging is where most website redesign disasters begin. The wrong protection lets Google index a half finished copy; the right protection, left switched on, makes the live site invisible. My preferred order is HTTP authentication first, noindex second, and robots.txt last.

The reason lies in how these signals interact, specifically in crawl order. Google's page on blocking indexing explains that a noindex rule only works if the crawler can fetch the page. If robots.txt blocks the URL, Googlebot never sees the noindex tag, and the page can still appear in results. So a robots.txt Disallow on staging feels safe, yet it actually hides your safety net.

At launch, meanwhile, the reverse mistake appears. Someone copies the staging configuration to production, and the new site launches with noindex on every page. Therefore, my launch checklist for staging includes these points.

• Remove HTTP authentication from the production server.
• Confirm no template still outputs a noindex meta tag.
• Replace the staging robots.txt with the production version, built with a robots.txt generator if needed.
• Check that every canonical tag points to the live domain, not the staging domain.
• Regenerate the sitemap with an XML sitemap generator and submit it in Search Console.

How do you carry titles, meta descriptions and H1s into the new design?

Template migrations lose metadata more often than they lose content. The developer builds a new theme, the CMS field for the meta description changes name, and hundreds of hand written titles fall back to the page name. Consequently, click through rates drop even when rankings hold.

Fortunately, the crawl export from the inventory phase is your insurance, so use it. Before launch, I crawl staging with the same tool and compare title, description and H1 columns row by row against the old export. Then, any page where the old value was custom and the new value is generic goes back to the content team.

For pages that need new metadata, I write titles with my meta tag generator and preview them in the Google SERP preview so nothing gets cut off. In addition, I check that every page has exactly one H1 in the new template. For instance, some modern themes wrap the logo in an H1, which pushes the real heading down to H2 and confuses the page's topic.

What happens to internal links when the menu changes?

A cleaner menu is usually a good design decision in a website redesign and a bad SEO decision, unless you plan for it. When a redesign cuts the navigation from 40 links to 8, the removed pages lose most of their internal links overnight. As a result, Google crawls them less often and treats them as less important.

Therefore, my approach is to build an internal link map in the same spreadsheet as the redirect map. For every important page, I note how many internal links point to it today and how many will point to it after launch. Pages that fall to zero need a new home: a footer group, a related content block, a hub page or in-text links from strong articles.

Also, check the links inside the content itself. A website redesign that changes URLs leaves hundreds of old links in blog posts and product descriptions. They will redirect, but a redirect inside your own site is a chain waiting to happen. Instead, run a find and replace on the database, or at least on the top 60 pages from the inventory.

Will the new theme hurt Core Web Vitals?

It can, and this is where many beautiful redesigns quietly lose ground; in practice it is the most common regression I measure. Google's Core Web Vitals documentation sets clear thresholds: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Google also states that these metrics align with what its core ranking systems seek to reward.

INP replaced First Input Delay as a Core Web Vital on 12 March 2024. Unlike its predecessor, INP measures the latency of every click, tap and keyboard interaction across the whole page lifetime. Heavy JavaScript themes, animation libraries and third party widgets are, in practice, the usual culprits. For example, a slider that loads five scripts on every page can push INP over the threshold on mobile devices.

So I test in two stages. On staging, I run Lighthouse on the homepage, a category page and a content page, and I compare the numbers against the same pages on the live site. After launch, I watch the Core Web Vitals report in Search Console, which uses real user data from the Chrome User Experience Report. In short, lab numbers tell you what to fix; field numbers tell you whether it worked.

Is a JavaScript based design a risk for SEO?

Frameworks like React, Vue and headless setups can rank well; however, they raise the cost of mistakes. Google processes JavaScript in three stages: crawling, a render queue, and indexing. Its JavaScript SEO documentation notes that waiting in the render queue may take seconds, but can also take longer. Content that only exists after rendering therefore reaches the index later than plain HTML.

Google still describes server side rendering and pre-rendering as a great idea, and I agree, especially for a website redesign that moves to a framework. If the redesign moves to a JavaScript framework, I insist on one of those two options for every page that should rank. Titles, meta tags, canonical links and the main content need to exist in the initial HTML response.

There is also a second trap specific to single page applications. When a route does not exist, the app often shows a "not found" message while the server returns 200. Google calls this a soft 404 and asks for meaningful status codes such as 404 and 401. In practice, this means the server, not the front end, must answer with the right code. So test a handful of fake URLs on staging before you trust it.

When is the right time for a website redesign launch?

Launch during your lowest traffic period, and change only one major variable at a time. Both points come straight from Google's site move guidance, and both match what I see in the field. For example, a retailer should not relaunch in November, and a tourism site should not relaunch in June.

Low season buys you two things. First, if something breaks, fewer visitors and fewer sales are affected. Second, Google's transition to the new URLs, which on a medium sized site can take several weeks or more, overlaps with the period when the site matters least. Consequently, by the time high season returns, the dust has settled.

There is also a paid search angle to consider. If you run campaigns, a website redesign that changes landing page URLs breaks the final URLs in your ads. Coordinate the launch with whoever runs your Google Ads management so the campaigns are paused or updated in the same hour. Otherwise you pay for clicks that land on a 404.

What does a launch day checklist look like?

Launch day is a protocol, not a celebration, so I treat it that way. I run it hour by hour and I keep the old server alive until every check passes. Here are the ten items I never skip.

1. Lower the DNS TTL 24 hours before, so the switch propagates quickly.
2. Switch the site during a quiet hour in your main market.
3. Watch the server logs for 5xx errors for the first hour.
4. Confirm the production robots.txt is live and does not block the site.
5. Confirm no page carries a noindex tag by fetching five random URLs.
6. Submit the new sitemap in Search Console and remove the old one if URLs changed.
7. Sample 50 rows from the redirect map with the redirect checker and record the result.
8. Run the URL Inspection live test on the homepage and three key pages.
9. Check that analytics, conversion tags and Google Ads tags fire on the new templates.
10. Test the contact form, the checkout and the search box as a real user.

Server errors, moreover, deserve special attention. Google's documentation explains that 5xx errors temporarily slow crawling, and crawl rate only recovers gradually once the server returns 2xx again. So an hour of instability on launch day costs you days of crawl budget afterwards.

What should you monitor in Search Console after launch?

For the first two weeks I check Search Console daily; after that, I check weekly until day 90. The reports that matter most are Pages (indexing), Performance, Crawl Stats and Core Web Vitals. Each one, in other words, answers a different question about the website redesign.

The URL Inspection tool is my first stop for individual pages. It shows whether a URL is in the index, when Google last crawled it, which Googlebot crawled it, and whether a live test confirms the redirect works. Then I move to the Pages report to watch the "Not found (404)" and "Page with redirect" counts. A rising 404 count, put simply, means the redirect map missed something.

Also, expect the numbers to wobble. Google's guidance says a medium sized site can take several weeks or more before new URLs replace old ones in results. Therefore, I do not react to a single bad day. I react to patterns: three days of falling clicks on the same group of pages, or a sudden jump in excluded URLs. This kind of monitoring is a standard part of my SEO consulting work after every relaunch.

Traffic dropped after the redesign: what do you do in the first 72 hours?

Follow a fixed diagnosis order instead of guessing. Most post launch drops have a technical cause that a methodical check finds within a day. Here is the sequence I use.

1. Open the 404 report and match every listed URL against the redirect map.
2. Test the top 20 old URLs with the redirect checker and confirm a single 301 hop.
3. Fetch the source of five key pages and search for noindex; then read the live robots.txt.
4. Check the canonical tag on those pages and make sure it points to the live URL, not staging.
5. Run a speed test and compare against the pre-launch numbers you saved.

Next, prioritise by impact. Here is an example, not a client case: 200 old URLs, of which 15 return 404. If the inventory shows those 15 pages carried 22 percent of all clicks, they come first, sorted by clicks. The remaining 185, meanwhile, can wait a day. In addition, keep a log of every fix with a timestamp, because you will want to link the recovery to the change when you review the project later.

How do you handle hreflang and multilingual sites during a redesign?

My own site runs in Turkish, English and German, so I have lived this problem. A website redesign on a multilingual site multiplies every task by the number of languages, and hreflang adds a dependency: every language version must reference every other version, and each must reference itself.

In practice, the most common failure is partial launch. The Turkish pages go live with new URLs, the English pages follow a week later, and in between the hreflang tags point to addresses that do not exist yet. As a result, Google ignores the cluster. Instead, I launch all languages of a page on the same day, even if that means delaying the whole release.

After launch, I regenerate the annotations with my hreflang generator from the final URL list and validate a sample. Also, check that the language switcher links directly to the translated page rather than to the homepage of the other language. That small detail keeps users on the page they wanted and keeps the cluster consistent for crawlers.

How do you protect product and category URLs on an ecommerce site?

Ecommerce redesigns carry the highest risk, because they carry the most URLs. Categories, filters, pagination and thousands of product pages all need a decision. My rule for stores is to keep category and product URLs unchanged wherever the platform allows it, even if the new design changes everything else.

Filter and parameter URLs, moreover, need extra care. Old platforms often generate crawlable filter combinations that earned no traffic; the redesign is the moment to block them or canonicalise them. However, some filter pages do rank, for example "red running shoes" style combinations. Check the inventory before you block anything.

Out of stock and discontinued products are, likewise, the other blind spot. Deleting them creates 404s on pages that may still hold backlinks. Instead, redirect discontinued products to the parent category or the closest replacement. When I take on this kind of migration through my ecommerce consulting, the product URL map is usually the largest single deliverable of the project.

Should you hire an expert or run the redesign yourself?

You can run a small website redesign yourself if you keep the URLs, keep the content and follow the checklists above. The method, after all, is not secret. The risk grows with the number of URLs, the number of languages and the share of revenue that comes from organic search.

Here is an honest comparison, then. A designer or a template will give you a modern look but rarely owns the redirect map, the metadata migration or the Search Console monitoring. A developer will implement redirects but usually does not decide which pages to keep. Someone has to own the whole chain, and that is the part I do.

Above all, write the line of responsibility down. Before I start, I agree with the client which pages are untouchable, who approves the redirect map and who watches Search Console after launch. You can see how I package this work on my packages page, or simply contact me with your current URL count and I will tell you whether you need help at all.

When can you call the new site a success?

I judge a website redesign on day 90, not on launch day. By then Google has crawled the new structure, the redirects have passed their signals and the seasonal noise has averaged out. The comparison uses the frozen measurement from phase one against the same 90 day window on the new site.

The durations above are starting ranges from my field experience, not guarantees. Specifically, three numbers decide the verdict: the count of ranking queries, total clicks, and conversions from organic traffic. If all three sit within a few percent of the old site, the migration held. If they rose, the redesign did its job. In short, a website redesign succeeds when the design changed and the numbers did not fall.