Buying a website

Website redesign checklist: how not to lose your Google rankings

To keep your Google rankings through a redesign, make sure every page Google already knows about still leads somewhere sensible, and that the pages that ranked keep the words that made them rank. Most drops after a redesign come from a short list of avoidable mistakes. The checklist below puts them in the order they happen, so you can use it to check your developer’s work without touching any code. It cannot guarantee your rankings, because Google looks at every page again once it changes, but it removes the usual reasons they fall.

Why rankings drop after a redesign

Google knows your pages by their addresses (the text in the browser bar, such as yoursite.com/services/roof-repair). Each address builds up a history with Google over time. If the new site uses different addresses and the old ones show “page not found”, Google sees the old pages as broken and the new ones as pages it has never met. The history does not carry over by itself.

The other common causes:

  • Page titles and text that were ranking get rewritten or cut during the redesign.
  • The new site is slower, especially on phones.
  • The new site accidentally tells search engines not to list it.
  • Tracking stops working, so nobody notices the drop until weeks later.

Each step below deals with one of these.

Before you build

  1. List every page on the current site and its address. Put them in a spreadsheet. If you have Google Search Console (Google’s free tool that shows how your site appears in search) or analytics, note which pages bring in visitors. In Search Console, the Performance report lists your pages by clicks from Google.
  2. Save the current page titles, descriptions and main headings. The title is the blue link people see in Google results, and the description is the short text under it. Copy them into the same spreadsheet. Once the old site is gone, this is hard to recover.
  3. Decide which pages stay, which merge and which go. Write the decision next to each address. A page that brings in visitors should rarely be deleted outright.
  4. Confirm you control the domain name and know where its DNS is managed. DNS is the set of settings that points your domain to the server that hosts your site. You need the login for whichever company holds it. Launch day is a bad time to find out a former developer set it up under their own account.

While you build

  1. Keep addresses the same wherever you can. An address that does not change needs no further work.
  2. For every address that does change, set up a permanent redirect. This is usually called a 301. It sends visitors and Google from the old address to the new one and tells Google the move is permanent. Point each old address at the closest matching new page. Sending everything to the homepage is a common shortcut, and Google tends to treat it much like a missing page. Ask your developer for the redirect list as two columns: old address, new address.
  3. Keep the text that was ranking, or improve it. A redesign is a good time to tidy copy, but if a page ranked for “emergency plumber Fort Lauderdale”, the new version still needs to talk about that clearly.
  4. Give every page its own title and description. Duplicate titles across pages make it harder for Google to tell them apart.
  5. Keep the preview copy of the site hidden from search engines, and make sure the live one is not. Developers usually build on a staging copy (a private preview address) and block search engines from it with a password or a “noindex” instruction. The mistake is carrying that instruction over to the live site at launch. Ask your developer to confirm it is removed.
  6. Check speed and the phone layout before launch. Google mainly looks at the phone version of a page when deciding how to rank it, and page speed is one of the signals it uses. Google’s free PageSpeed Insights tool gives a quick read on both. Fixing these before launch is far easier than after.

At launch

  1. Switch the domain to the new site, then test the old addresses one by one. Go down your spreadsheet, type each old address into a browser and check it lands on the right new page. This is tedious and it is the single most useful check on the list.
  2. Submit the new sitemap in Google Search Console. A sitemap is a file that lists every page on your site, often found at yoursite.com/sitemap.xml. Submitting it helps Google find the new pages.
  3. Check that analytics is recording visits. Open the real-time report in your analytics tool, visit the site from your phone, and watch for your visit to appear.
  4. Pick one address format and redirect the other to it. Your site should live at either www.yoursite.com or yoursite.com, with the other one redirecting. If both load separately, Google may see two copies of every page.

After launch

  1. Watch Search Console for pages reported as not found, for a few weeks. The Pages report lists addresses Google tried to visit and could not find. Each one is usually a missing redirect, and it can be fixed by adding one.
  2. Expect some movement in rankings in the first weeks. Some ups and downs are normal while Google works through the changes. A sudden large drop that does not recover usually means something on this list was missed, and the steps above are the places to look.
  3. Keep the old site’s files for a while. If a question comes up about what a page used to say or where it lived, you will want to be able to look it up.

What we learned moving our own site

In 2026 we moved the VC Media site from a 2019 React app hosted on Netlify to a new Astro site on Vercel, and moved the domain’s DNS at the same time. A few things from that move line up with the checklist.

The old site was still running a version of Google Analytics that Google had shut down. It had been recording nothing for some time, and nobody had noticed. Check your tracking works before you need it.

Our Search Console ownership had been proven with a tag inside the old site’s pages. The new site did not carry that tag over, so we redid the verification through a DNS record instead. A DNS record sits with the domain, so it survives any future redesign.

The old site was a single page, so there were very few addresses to redirect. Most business sites have many more, which is why the spreadsheet in the first step matters.

For a short time during the switch, the new build and the old site were both reachable at public addresses. Every page on the new site declares its one official address with a canonical tag (a line in the page code that tells Google which copy counts), so Google knew which version to list.

What to do next

If your site has a handful of pages and your developer is careful, you can run this checklist yourself. Share it with them before work starts, and ask for the page list and the redirect list as deliverables. If you would rather hand the whole move to someone who does this routinely, our website redesign service covers every step above, and our technical SEO work can check a redesign that has already launched. Either way, you are welcome to get in touch with questions.

Keep reading

Have a project in mind?

Tell us what you're building and we'll come back with next steps.

Start a project