Website Redesign Checklist: How to Redesign Without Losing Your Google Traffic

The short answer: A website redesign is a migration as well as a design project. To keep your Google traffic, record what you have before you start, keep the content and addresses that bring visitors, map every old address to its new one with permanent redirects, keep the staging site private, and launch with a tested redirect map, a new sitemap and clean robots rules. Then watch Search Console for a few weeks. Google says that when addresses change, small and medium sites usually need a few weeks or more to settle, and that temporary ranking movement is normal.

A new design can win you more enquiries. It can also quietly cost you the traffic you already have. The usual culprits are not the colours or the layout. They are pages that vanish, addresses that change without a redirect, a staging site left open to Google, and a robots.txt file copied across from development. A good website redesign checklist is mostly about preventing exactly those.

I build and rebuild business websites, and this year I rebuilt my own, moving it from WordPress to a custom-built site. Every old WordPress address needed a decision. This website redesign checklist is the process I would follow for yours. Wherever I describe what Google does, I link to Google's own documentation, because the details are easy to get wrong and you should be able to check them.

If very few people visit your site today, a redesign will not fix that on its own, so start with SEO for business websites. If your goal is more enquiries, pair this guide with how to get more quote requests from your website, because a redesign is the best moment to fix both.

Should You Redesign, or Fix What You Have?

Not every problem needs a new website. Sometimes a smaller fix does the job, and it carries far less risk to your traffic.

If you are not sure what a business website must do in the first place, read why your business needs a website and the requirements it must meet. If you decide to go ahead, treat it as a migration from the start. That one change in thinking prevents most of the damage.

Treat a Redesign as a Migration

To Google, a redesign that changes addresses is a site move. Google's guide to site moves with URL changes sets out four steps in this order:

1. Prepare the new site and test it thoroughly.
2. Prepare a map from each old address to its new one.
3. Start the move by setting up redirects from old addresses to new ones.
4. Monitor traffic on both the old and new addresses.

The rest of this checklist follows that order and adds the practical details owners tend to miss.

Step 1: Record What You Have Before You Touch Anything

You cannot tell whether the redesign worked unless you know where you started. Spend an afternoon on this before any design work begins.

• List every address on the site. Export it from your CMS or sitemap, or crawl the site with a tool. Include blog posts, service pages, landing pages and files people link to.
• Export your Search Console data. Google's Performance report shows clicks, impressions, click-through rate and average position, and it can be exported. The default view covers the past three months, so save a copy before you launch.
• Note which pages bring enquiries, not just visits. Look in your analytics at the landing pages behind form submissions, calls and WhatsApp messages. A page with modest traffic that produces most of your enquiries is a page you must protect.
• Record the titles and headings of your top pages. A simple spreadsheet is enough.
• Record your speed. Google's Core Web Vitals report uses real-user data from the last 28 days. A URL is "good" at an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, according to Google's report documentation.
• Note the pages other sites link to. Search Console and SEO tools can show them. Those pages carry value that you do not want to lose.

From this, make a keep list: the pages that earn traffic or enquiries. Everything in the next steps is about protecting that list.

Step 2: Decide What Must Not Change

The safest redesign changes the look and structure that visitors see while keeping what already works for search. Before the design starts, agree on four things.

• Keep content that ranks. Improve it, tighten it and make it clearer, but do not delete a page that brings traffic just because it no longer fits the new layout.
• Keep addresses the same when you can. The best redirect is no redirect. If your new platform allows the same address structure, use it.
• Carry titles, headings and descriptions across. Rewrite them on purpose if they are weak, not by accident because the new template left them blank.
• Decide what happens to pages you remove. Send visitors to the closest relevant page. Google advises against redirecting many old addresses to one irrelevant page, such as the new home page.

Step 3: Map Every Old Address to a New One

This is the most important document in the whole project, and it is a spreadsheet, not a design file. Build it with one row per old address. Here is a small example (the first two rows are from my own site, the last two are made up to show the idea):

Then set the redirects up properly:

• Use permanent, server-side redirects. Google supports 301 and 308 redirects as permanent redirects, and says server-side redirects are the most reliably interpreted. Script-based redirects are a last resort. See Google's page on redirects.
• Send each old address straight to its final destination. Avoid chains, where one redirect leads to another. Google's site move guide says to keep chains short, and the simplest rule is no chain at all.
• Do not worry about losing link value. Google states that permanent redirects do not cause a loss in PageRank.
• Keep the redirects for at least a year. That is Google's minimum, and from a visitor's point of view it is worth keeping them for good.

On my own site, each old WordPress address got a permanent redirect to its nearest new page. The old /portfolio now goes to /work and the old /blog goes to Insights, and I set the rules so that an address with or without a trailing slash reaches its destination in one step.

One lesson from that project: test redirects in a fresh browser or with a command-line tool. Browsers can remember a permanent redirect. When I later built a real page at an old address that had been redirected, my own browser kept bouncing me away from it even after I removed the rule. So never ship a permanent redirect for an address you might want to use again.

Step 4: Build on a Staging Site, and Keep It Private

Do the work on a copy of the site, not on the live one. Then make sure Google never sees that copy.

• Put the staging site behind a password. In my view this is the safest way, because nobody can reach the pages, including search engines.
• Do not rely on robots.txt to hide pages. Google's guide to blocking indexing says robots.txt is the wrong tool for keeping a page out of search: if crawling is blocked, Googlebot never sees a noindex rule, so the page can still appear in results if other pages link to it.
• Do not combine the two. A staging site with Disallow: / in robots.txt and a noindex tag looks careful, but the first rule hides the second from Google. Pick one method, and a password is the best.
• Plan the clean-up for launch day. Google calls leftover noindex tags and robots.txt blocks from development a common mistake when a site goes live. Prepare the production robots.txt before launch, and make a list of every page that needs the noindex tag removed.

Step 5: Build the New Pages With the Old Ones in Mind

While the new site is being built, check these items against your baseline.

Two of these come straight from Google's site move guide: give each new address a self-referencing rel="canonical" tag, and update your internal links.

The redesign is also the time to make the page do its job. Put a short form and proof in the first screen, and follow the advice in the quote request form guide. If you want to see how this looks on real businesses, my work page shows several live sites.

Step 6: Launch Day

Launch day should be dull. If it is exciting, something was not tested. Work through these in order.

1. Test every redirect on your map, on the live server. Each old address should return a permanent redirect straight to the right new page, in one step.
2. Remove the staging rules. Take out every noindex tag and robots.txt block that was only there for development, and check the production robots.txt. If you have no robots.txt file, the address should return a proper "not found" response.
3. Submit the new sitemap in Search Console. Google says you can then remove the old sitemap, and that a warning about old addresses redirecting is expected and can be ignored.
4. Send a test enquiry through every form, and check that the message arrives and the event shows up in analytics.
5. Update the links you control. Business profiles, social pages, email signatures, adverts and directory listings should point to the new addresses. Google recommends updating external and profile links where you can, starting with the busiest.
6. If the domain name changes, use Change of Address. Google asks for this in Search Console for a domain change. A redesign that keeps the same domain does not need it.

The First Month After Launch

Expect some movement. Google says that when addresses change, small and medium sites can take a few weeks or more before Google gradually shows the new addresses instead of the old ones. It adds that Googlebot has to visit every old and new address at least once, that there is no fixed crawl schedule, and that temporary ranking fluctuations are normal.

Fix real faults quickly, such as a page that used to bring traffic and now returns an error. Do not rewrite the whole site because of a dip in the first week. If traffic is still down after a few weeks, go back to your records and check the usual suspects: a missing redirect, a stray noindex tag, a blocked page, or a keep-list page that was removed.

Questions to Ask Your Designer Before They Start

If someone else is redesigning your site, these questions show quickly whether they treat it as a migration. A good answer is specific. A vague one is a warning sign.

1. Will you give me a list of every current address, and a redirect map, before launch?
2. Which addresses will change, and why?
3. How will you keep the staging site out of Google?
4. Who tests the redirects after launch, and how?
5. Will my titles, headings and content carry over, and who decides what changes?
6. How will you measure speed before and after?
7. What happens to the pages you plan to remove?
8. Who watches Search Console in the first month, and is that included?

I work in five stages: Discover, Design, Develop, Launch and Support, with milestones and pricing agreed up front. You can read how a project runs from first call to launch.

A Website Redesign Checklist You Can Copy

Before you start

• We have a full list of current addresses
• We exported Search Console data and saved it
• We know which pages bring enquiries, not just visits
• We recorded titles, headings and speed for the top pages
• We made a keep list of pages that must not be lost
• We know why we are redesigning and what success looks like

While it is being built

• A redirect map has one row for every old address
• The staging site is behind a password
• Titles, descriptions and key content are carried across
• Internal links point to the new addresses
• Each page has a self-referencing canonical tag
• The sitemap lists the new addresses only
• Forms, calls and WhatsApp work and are counted

On launch day

• Every redirect was tested on the live server, one step each
• All staging noindex tags and robots.txt blocks are removed
• The new sitemap is submitted in Search Console
• A test enquiry arrived and was tracked
• Profiles, adverts and directories point to the new addresses

After launch

• We check errors and indexing every week for a month
• We compare clicks, enquiries and speed against the baseline
• We keep the redirects for at least a year
• We fix real faults first and avoid panic rewrites

Common Redesign Mistakes

Frequently Asked Questions

What is a website redesign checklist?

A website redesign checklist is a list of the steps that protect your search traffic and your enquiries while a site is rebuilt. It covers what to record beforehand, which pages to keep, how to redirect old addresses, how to keep the staging site private, what to test at launch and what to watch afterwards.

Will a redesign hurt my SEO?

Not necessarily. Google says temporary ranking fluctuations are normal when addresses change. The real risks are avoidable: addresses that change without redirects, content that is removed, and staging rules left on by mistake. The steps above deal with each of them.

Should I change my URLs during a redesign?

Only if you have a good reason. Keeping the same addresses removes the biggest source of risk. If the new platform or structure makes changes necessary, give every old address a permanent redirect to its new one.

Do I need 301 redirects?

Yes, whenever an address changes. Google supports 301 and 308 as permanent redirects and says server-side redirects are the most reliably interpreted. Send each old address straight to its final destination, and avoid chains.

How long should I keep redirects in place?

At least one year, according to Google's site move guide, and from a visitor's point of view it is worth keeping them for good. There is rarely a good reason to remove them, and removing them can break old links.

Do I need to tell Google about a redesign?

Not specially. Submit your new sitemap in Search Console and make sure Google can crawl the new site. The one exception is a domain name change, where Google asks you to use the Change of Address tool.

How long until my traffic recovers?

Google gives no fixed time. For small and medium sites it says a few weeks or more once addresses change. If traffic is still well below your baseline after a few weeks, check your redirect map, stray noindex tags, robots.txt and any removed pages first.

Should I redesign in stages or all at once?

Both can work. Changing a site in stages lets you test one change at a time and see its effect. A single launch is cleaner when you are moving to a new platform. In my view, the bigger the change in structure, the more a staged approach helps you find problems early.

Should I redesign with WordPress or a custom build?

Choose by what the site has to do. WordPress suits teams that want to edit pages themselves without a developer. A custom build suits sites with unusual features or demanding speed needs. I build both, so the right answer depends on your team, your budget and the job the site must do.

Planning a Redesign?

A redesign should leave you with more enquiries, not fewer visitors. The difference is almost always in the preparation: a clear record of what works today, a complete redirect map, and a launch that has been tested.

If you are planning one, write a short brief on my contact page and tell me what the site must keep. I will reply with an honest view and next steps. You can also see examples of live client sites I have built, or browse everything I can help with.