Web

Website Redesign Without Losing SEO Rankings: A Step by Step Checklist

Talha Aslan 19 min read 5 views

How do you handle a website redesign without losing Google rankings?

A website redesign keeps its rankings when the old URLs, content and technical signals move to the new site without gaps. Before launch, you build a URL inventory, map every old address to its closest new page with a 301, keep the staging site closed, and then watch Search Console closely after go-live.

In short, the look can change, but the signals Google uses to understand your pages should stay the same or move in a controlled way. At Talha Aslan and team, we plan every website redesign by setting up this safety net before any visual work starts. That way, design decisions in a web design project move forward without putting organic traffic at risk. This guide walks a business owner through the steps in order.

A quick note on scope. If your project also changes hosting or the domain, the server side is a separate topic. For that, see our checklist for changing web hosting without downtime. Here we focus only on a visual and structural refresh on the same domain.

Why does a redesign cause ranking drops?

A new design alone rarely hurts rankings. The trouble comes from things that change quietly alongside it. For example, the URL pattern changes, old product pages merge, long copy gets trimmed "to look cleaner," or some pages drop out of the menu. Google then has to evaluate much of the site again.

In our field experience, these are the most common causes of loss:

  • Old URLs return a 404 error with no redirect.
  • Many old pages point to the homepage.
  • Title tags and H1 headings switch to generic template text.
  • Internal links shrink, and key pages fall out of the menu.
  • A noindex tag from staging slips onto the live site.
  • Structured data disappears with the old theme.

So in a website redesign, the thing to protect is not the design itself. Instead, you protect this whole bundle of signals. Each item also affects the others. Even a perfect redirect plan cannot save a page whose content you emptied out. For that reason, we suggest you treat the steps below as one checklist rather than separate tasks.

How do you build a URL inventory before a website redesign starts?

A URL inventory lists every address that exists on your site today and that Google knows about. Google Search Central's guide to site moves with URL changes also recommends pulling this list from several sources, such as sitemaps, server logs, analytics and your content management system.

In practice, we combine these sources:

  1. The current XML sitemap and any child sitemaps.
  2. Pages with clicks or impressions in the Search Console performance report.
  3. Landing pages that drew visits in your analytics tool recently.
  4. Every published page, post, category and product URL in your CMS.
  5. Embedded files such as images, PDFs and download links.

Then you merge these lists into one website redesign sheet and remove duplicates. Old campaign pages and PDF catalogs often get forgotten. However, they may have earned links from other sites. The inventory forms the base for every later decision. Therefore, we recommend you finish this sheet before anyone signs off on design mockups.

Which pages carry traffic and links?

Not every URL in the inventory has the same value. Some pages bring in most of your organic traffic. Others get few visits but hold links from external sites. Giving every page equal attention wastes time. On the other hand, missing one valuable page causes real loss.

So we add a few columns to the sheet: recent organic clicks, impressions, the main query each page targets, and whether it has external links. The Search Console performance report fills the first three. For links, the Links report in Search Console makes a good starting point.

Next, you sort pages into three groups. Group one holds pages that carry traffic or links and must have a match on the new site. The second group holds similar pages you can merge. Group three holds content that is truly outdated and that nobody searches for. In other words, this grouping shows the whole team which pages are "untouchable" during design. Once designers and developers see the list, they also make menu and template choices with it in mind.

How do you prepare a 301 redirect map?

A 301 redirect map is a table that shows where each old URL will permanently point on the new site. Google recommends server-side permanent redirects (301 or 308) and asks you to send each old URL straight to its final destination. In other words, no second or third hop should sit in between.

We follow these rules when we build the map:

  • Each old URL goes to the new page with the closest content.
  • Pages whose URL stays the same need no redirect.
  • You never send old pages to the homepage in bulk.
  • Pages with no match and no value return a 404 or 410.
  • You never create redirect chains.

If you have the old and new URL lists ready, our redirect mapping tool can pair similar URLs and give you a first draft. Still, a person should make the final call. The tool looks at URL similarity, not content similarity. How long redirects should stay live is a separate question. We cover it in our post on how long 301 redirects should stay.

What decisions go into the redirect map?

For each row in the map, you pick one type of decision. The table below sums up the cases we see most often in redesign projects and the approach we suggest.

SituationSuggested actionWatch out for
URL stays the sameNo redirectKeep content and title intact
URL changes, content staysOne to one 301Point straight to the final URL
Several pages merge into one301 all of them to the new pageThe new page must truly cover each topic
Page removed, similar page exists301 to the closest pageWeak topic match risks a soft 404
Page removed, nothing similar404 or 410Avoid bulk redirects to the homepage
Image or PDF URL changes301 per fileKeep image search traffic in mind

For example, if you fold three service subpages into one page, the new page must actually cover all three topics. Otherwise, Google may find the redirect irrelevant and treat it as a soft 404. Also, the final version of this table becomes part of the technical brief you hand to your developer.

Why should you keep content and headings?

Google understands a page more by its content than by its URL. If copy gets shorter, subheadings vanish, or the main topic shifts, the page may lose its spot for old queries even with a correct redirect. So we ask design teams to build the layout around the copy, not to squeeze the copy into the layout.

For each priority page, you compare these elements: the H1, the H2 and H3 subheadings, the scope of the main copy, FAQs, tables and image alt text. Each should keep its place in the new template. Text inside accordions or tabs should still exist in the page source. Content that loads from the server only after a click carries more risk.

That said, a redesign also gives you a good chance to strengthen weak content. However, if you ship big content edits on the same day as the new design, you will struggle to pin down the cause of any drop. So we suggest you make large content changes in a later phase, after the design settles. That way, you can measure the effect of each change on its own.

How do you carry over title tags and meta descriptions?

The title tag and meta description form the first text a user sees in search results. New themes often generate these fields from the page name. As a result, titles you refined for years can turn into generic text like "Services | Company Name" overnight.

To prevent this, add two more columns to your inventory: the current title and the current meta description. A crawler can scan the live site and export these fields. Then you check each priority page on the new site one by one.

Here is what we watch during the move:

  • The main query stays near the start of the title tag.
  • The canonical tag points to the new URL, not the old one.
  • On multilingual sites, hreflang tags point to the new URLs.
  • Open Graph tags show the right image for social shares.

If you want to catch canonical issues after launch, our guide to finding canonical issues in Search Console helps. Still, the cheapest fix is to find the problem on staging before launch.

How do you update internal links in the new structure?

Internal links help Google see which pages you consider important. In a new design, the menu often gets simpler, the footer gets shorter, or the sidebar goes away. With these changes, some key pages can end up with almost no internal links.

So you handle two separate jobs. First, update old links inside your content to the new URLs. Even with redirects in place, linking to a redirected URL adds a needless hop. Google also recommends updating internal links to the new addresses. Second, confirm that the priority pages in group one still get enough links from the new menu and templates.

For example, a service page that sat in the main menu on the old site may now get a link from only one subpage. Its visibility can weaken as a result. After launch, you can check for leftover chains with our redirect checker. If you wonder why chains cause trouble, read our post on what a redirect chain is and how to fix it.

What happens if structured data disappears in the new design?

Structured data is code that describes your page content to Google in a machine-readable way. Markup for business details, products, FAQs or breadcrumbs often depends on the theme or a plugin. When the theme changes, this markup can vanish silently.

Structured data alone does not guarantee rankings. However, it affects whether a page can earn rich results. If you miss the loss, your click-through rate may fall, and you may only spot the cause much later. Therefore, we suggest you note in the inventory which schema types the old site used.

The checks stay simple:

  1. Run priority pages of the old site through Google's Rich Results Test and record the types it finds.
  2. Test the same pages again on staging.
  3. Add any missing types to the new template.
  4. After launch, watch the related enhancement reports in Search Console.

If you need to rewrite missing markup, our schema generator gives you a quick start. For the basics, our post on what schema markup is makes a good entry point.

Why should the staging site stay noindexed?

A staging site is the copy where you try out the new design before it goes live. If search engines can reach that copy, Google may see the same content at two addresses. Worse, half-finished pages may show up in search results. So you must keep staging closed.

The safest option puts staging behind password protection. Then neither search engines nor strangers can reach it. You can also add a noindex tag on top. Google's documentation notes that a noindex rule only works if robots.txt does not block the page. If Google cannot crawl the page, it cannot see the tag either.

The real risk, though, lies less in staging and more in launch day. When you copy the new site from staging to live, the noindex tag or robots.txt block can come along. In that case, the new site starts to drop out of the index within days. In short, removing the block at launch should be a written step in the plan, just like adding it. We suggest you assign this step to a named person in the contract and the brief.

What should you check on launch day?

Launch day tests all your website redesign preparation. So you work from a written list, in order, rather than from memory. If you can, pick a low-traffic hour and assign at least one person to checks only.

Here is the list we use at launch and right after:

  1. Confirm in the page source and HTTP headers that no noindex remains on the live site.
  2. Make sure robots.txt does not block key sections.
  3. Pick random and priority URLs from the map and test for a 301 response.
  4. Check that canonical tags point to the new URLs.
  5. Submit the new XML sitemap in Search Console.
  6. Test forms, phone links and conversion tags.
  7. Inspect priority pages with the URL Inspection tool in Search Console.

For general go-live steps, you can also use our pre-launch testing and QA checklist. In addition, Google suggests keeping a sitemap of the old URLs for a while. That helps Google follow the redirects, and you can track the decline in the report.

What should you monitor in Search Console after a website redesign?

The weeks after a website redesign goes live matter most for catching problems early. Search Console becomes your main data source here. Google also recommends watching the sitemap report, the indexing reports and search performance after a move.

These are the main signals we track:

  • A rise in not found (404) errors in the page indexing report.
  • How fast URLs in the new sitemap get indexed.
  • Click and impression trends for priority pages.
  • Shifts in average position for main queries.
  • New errors in structured data and enhancement reports.

Short swings are normal, because Google recrawls and reassesses the new structure. However, if you see a lasting drop in one group of pages, check that group's redirects and content right away. If you are new to the tool, our Google Search Console guide makes the reports easier to read. To dig into a decline in detail, see our post on diagnosing a traffic drop in Search Console.

What should you do if traffic drops in the first weeks?

First, stay calm and define the scope of the drop. Does it hit the whole site or one group of pages? That split gives you the fastest route to the cause. For instance, if only blog posts drop, a change in the blog URL pattern is the likely culprit.

Then we check in this order. First, we confirm the noindex and robots.txt status again, because the biggest and fastest losses usually start there. Next, we test the old URLs of the pages that dropped. Does the 301 reach the right target, or does it return a 404? After that, we compare content, titles and internal link counts between the old and new pages.

Once you fix what you found, you can request recrawling for those pages with the URL Inspection tool. On the other hand, rolling back to the old design right away rarely solves the problem. Instead, it shows Google a second major change. So we suggest you find the cause first and then make targeted fixes. Recovery speed depends on site size and crawl frequency, so we avoid promising a fixed timeline.

How do you pick the right timing?

For a website redesign, timing matters as much as technical prep. If you push a large structural change live during your busiest sales season, any dip hurts more. So know your season, and place the launch in a quieter period.

We also suggest an early weekday. A site that goes live on Friday evening may spend the weekend with a problem nobody sees. If you launch on Monday or Tuesday, the full team can check things during the first days. Also, your host, developer and content team all stay reachable at once.

That said, include your ad campaigns in the plan. If the landing URLs of your Google Ads or social ads change, update them on launch day. Otherwise, ad traffic passes through redirects or lands on an error page. In short, the launch date should have sign-off from marketing and sales too, not only from the design team.

Finally, set a content freeze for the last few days before launch. In other words, you stop adding pages or changing URLs on the old site during that window. That way, the inventory and the live site stay in sync, and the redirect map stays current.

Which data should you back up before a website redesign?

A backup means more than a copy of files and the database. From an SEO view, the most useful data documents how the old site looked and how it performed. If a problem shows up after launch, you need a quick answer to "what did this page say before?"

So we suggest you save these records before launch:

  • A full crawl export with URL, status code, title, meta description, H1 and canonical.
  • The copy and a screenshot of each priority page.
  • An export of Search Console performance data.
  • The landing page report from your analytics tool.
  • The current robots.txt file and XML sitemap.

These records serve as your baseline for comparison after launch. For example, when a page loses clicks, you can pull up the old title and copy at once and set them next to the new version. Also, if ownership of the site files or domain is unclear, sort that out before the project starts.

Why should you check speed and the mobile experience of the new design?

A new design often brings larger images, animations and extra fonts. These look impressive. However, they can slow down loading and responsiveness. Google measures user experience with the Core Web Vitals metrics it explains on web.dev. Therefore, a design change also changes these numbers.

So we suggest you compare the speed of priority pages on staging against the old site. On mobile in particular, look at how fast the first screen appears, how quickly buttons respond to taps, and whether content shifts while the page loads. Also confirm that the mobile menu gives easy access to priority pages, because Google mainly evaluates the mobile version of your site.

For example, if the new homepage has a large video background, swapping it for a light image on mobile improves both speed and experience. As a result, the new design beats the old one on the devices most of your visitors use, not only on desktop.

What should you clarify with your agency on a website redesign project?

Even with solid technical steps, vague roles let tasks fall through the cracks. For example, the design agency may see redirects as "the SEO team's job," while the SEO side only notices a leftover noindex after launch. So we suggest you put who does what in writing at the start.

These are the main points to settle:

  • Who builds and who approves the URL inventory and the redirect map?
  • Who owns the move of titles, meta descriptions and structured data?
  • Whose job is closing staging and opening the live site?
  • How many weeks of monitoring and fixes come after launch?
  • Who keeps access to the domain, hosting and Search Console?

We explain how to write these into a contract in our post on what to include in a web design contract. If you have not chosen your platform yet, our comparison of website templates and custom web design also shapes this plan. Ready-made themes may set URL patterns and template tags by their own rules.

How does a redesign differ from a site migration?

A redesign renews the interface, the templates and often the information architecture on the same domain. A site migration changes the infrastructure, such as the domain, protocol or server. The two can happen in one project. Still, their risks and checklists differ.

In a redesign, the main risk sits in content, templates and internal links. In a migration, the risk centers on DNS, certificates, server responses and domain-level redirects. For that reason, we suggest you avoid doing both on the same day. If you do one first and let it settle, you can tell the causes of any issue apart.

For projects where the domain or URL structure changes a lot, our website migration SEO checklist gives a broader framework. We also wrote a shorter overview on protecting SEO during a redesign. The steps in this guide go deeper into the redesign part of that framework, so you can use them together.

What are the most common redesign mistakes?

In our experience, most mistakes come from last-minute rush, not from lack of knowledge. The design gets approved, launch day nears, and teams push technical checks to "after launch." Yet a few hours of checks can prevent weeks of recovery.

These are the mistakes we see most often. Teams write redirects only for main pages and forget blog and product URLs. Old URLs go to the homepage in bulk. Image URLs get ignored entirely. Next, the staging block slips onto the live site. Teams also forget to add analytics and conversion tags to the new template. Some teams also delete the old sitemap right away, which makes tracking old URLs harder.

Another mistake: saying "traffic dropped" or "all good" without measuring. So set a baseline period before launch and record clicks and impressions for priority pages. Then you compare with real data after launch. Also, to account for seasonal swings, look at the same period last year if you can.

What is the short summary for a redesign that keeps rankings?

In short, a successful redesign depends on the prep you do before design starts. You build the URL inventory, flag valuable pages, prepare the 301 map, and protect content, titles, internal links and structured data. You keep staging closed, open it at launch, and then watch Search Console data on a regular basis.

None of these steps guarantees rankings, because Google reassesses every change. However, a controlled process clearly lowers the risk of lasting loss and helps you catch issues early.

If you want to plan your new site with this safety net, our web design service makes the URL inventory, redirect map and post-launch monitoring part of the project from day one. That way, the new design does more than look better. It also carries over the organic visibility you already earned.

Frequently Asked Questions

Does a website redesign always lower rankings?
No, it does not. Losses usually come from missing redirects, trimmed content, changed titles or a noindex tag left on at launch. If you move these signals in a controlled way, the risk drops clearly. Still, Google reassesses every change, so you may see short swings. For that reason, we suggest you watch Search Console data closely after launch.
Do I still need prep if my URLs stay the same?
Yes, you do. Even with unchanged URLs, a new template can affect title tags, internal links and structured data. So we suggest you still build a URL inventory and compare the content and meta fields of priority pages with the old site. Closing staging and opening the live site at launch matters just as much in this case.
Why is redirecting every old URL to the homepage a problem?
Because Google may not treat a bulk redirect to an unrelated page as a true permanent redirect and may see it as a soft 404. Users also land on the homepage instead of the content they wanted. Instead, send each old URL to the new page with the closest content. For pages with no real match, a 404 or 410 is the more honest choice.
What is the safest way to protect a staging site?
The safest way puts staging behind password protection. Then neither search engines nor strangers can reach it. You can add a noindex tag on top. The point that needs the most care is launch day. The staging block must not carry over to the live site, and this check should be a written step on your launch list.
How long should I monitor after launch?
We avoid giving a fixed period, because recovery speed depends on site size and how often Google crawls it. We suggest daily checks in the first days and weekly checks after that. Keep monitoring until click and impression trends for priority pages return close to their old level and the 404 report shows no new rise.
  • website redesign
  • 301 redirects
  • technical seo
  • search console
  • site migration
  • web design
Share:
Talha Aslan

Google Partner digital marketing expert. Hands-on with SEO, Google Ads, web design and e-commerce projects since 2012; every post here comes from that experience.

Next project

Get a quote for your project.

Your brief goes straight to Talha Aslan and team: strategy led by Talha, delivery by an experienced team. We reply the same day and send the scope, timeline and price as a written quote within 1 business day.