How to Redesign Your Website Without Losing Your Google Rankings

A new website should bring in more enquiries than the old one. Sometimes the opposite happens: the new site launches, looks great, and within a few weeks the phone goes quiet because the pages that used to rank in Google have disappeared from the results.

In almost every case I’m asked to look at, the cause isn’t the new design. It’s that the old site’s addresses, content and signals weren’t carried across properly. The good news is that this is very preventable. Google itself says that permanent redirects don’t cause a loss of ranking signals, so a well-planned redesign shouldn’t cost you your search traffic.

This is the process I follow when I rebuild a site for a client, whether it’s a WordPress brochure site, a WooCommerce or Magento shop, or a move to Shopify. You can use it as a checklist for your own project, or to check that whoever is building your new site has it covered.

Google ranks individual pages, not whole websites. When a redesign changes or removes the pages Google already trusts, the rankings attached to them can be lost. The most common causes are:

• Changed URLs with no redirects. If /services/kitchen-fitting becomes /kitchens and nothing tells Google, the old page simply returns “not found”.
• Content removed or cut down. A page that ranked because it answered a question in detail won’t keep ranking once that detail is replaced with a slogan and a stock photo.
• Development settings left switched on. A “noindex” tag or a robots.txt rule that kept the staging site out of Google, accidentally carried over to the live site.
• Broken internal links. Menus and in-page links still pointing at old addresses, which weakens how Google understands your site’s structure.
• Rewritten page titles and headings that no longer match what people search for.
• A slower site. Heavier designs, page builders and extra scripts can make pages noticeably slower than before.

Each of these is avoidable with planning before launch, which is where most of the work should happen.

You can’t protect what you haven’t measured. Before any design work starts, I take a snapshot of the current site so there’s something to compare against after launch:

• A full crawl of the existing site using a tool such as Screaming Frog, which lists every URL along with its page title, description, headings and status code.
• Google Search Console performance data for the last 12 to 16 months, exported by page and by search query, so seasonal patterns are visible.
• Analytics landing page data showing which pages bring in visitors and, more importantly, enquiries or sales.
• The pages other websites link to, from Search Console’s links report. These links are valuable and need to keep working.
• The current XML sitemap, plus any PDFs, images or downloads that get traffic of their own.

Keep this snapshot somewhere safe. It is the single most useful thing to have if anything goes wrong later.

A redesign is a good opportunity to tidy up, but every page needs a deliberate decision. I sort the old URLs into three groups:

• Keep: pages that rank, get traffic, earn links or convert. These move to the new site with their content intact, even if the layout changes.
• Merge: thin or overlapping pages, such as three short pages about variations of the same service, combined into one stronger page.
• Remove: out-of-date pages with no traffic, links or purpose.

Pages you genuinely remove can return a normal “not found” (404) or “gone” (410) response. What you shouldn’t do is redirect everything you remove to the homepage. Google’s guidance warns that mass redirects to an irrelevant page can confuse visitors and may be treated as a “soft 404”, so you get none of the benefit of a redirect.

The redirect map is the heart of a safe redesign. It’s a spreadsheet with every old URL in one column and its new equivalent in the next. Some practical rules I stick to:

• Redirect one-to-one wherever possible. Each old page should point to the most relevant new page, not a general category or the homepage.
• Use server-side permanent redirects. Google recommends permanent redirects such as 301 or 308, set up on the server or in the platform, rather than JavaScript or meta refresh redirects.
• Avoid redirect chains. If an old page was already redirected once, point it straight at the final destination. Google can follow several hops but advises redirecting directly, and keeping any chain short.
• Don’t forget files. Images, PDFs and other downloads that have their own traffic or links need redirecting too.
• Update internal links on the new site to point at the new URLs directly, so visitors and Google aren’t relying on redirects to get around.

• WordPress and WooCommerce: redirects can live in the server configuration (for example an .htaccess file on Apache hosting, common on cPanel) or be managed through a redirect plugin.
• Shopify: URL redirects are managed in the admin and can be imported in bulk from a CSV. Shopify uses fixed URL patterns such as /products/ and /collections/, so moving a shop to Shopify almost always means a full redirect map.
• Magento 2: URL rewrites are built in, and Magento can create them automatically when product or category URL keys change, but imported or migrated products need checking carefully.
• Bespoke Laravel sites: redirects can be handled in the application’s routing or at server level, ideally from a maintained list rather than scattered rules.

If you’re also changing platform, my comparison of Shopify, WooCommerce and Magento covers what each one does differently.

A fresh design doesn’t mean fresh words everywhere. For the pages that already rank, I’m careful to keep the things Google relies on:

• Page titles and meta descriptions that already perform, improved rather than replaced wholesale.
• The main heading and body content. Tighten it, update it and make it easier to read, but keep the substance that answers the searcher’s question.
• Structured data such as local business, product, review or FAQ markup, rebuilt on the new templates.
• Image alt text, which helps both accessibility and image search.
• A self-referencing canonical tag on each new page, pointing at its own new URL.
• Page speed. A redesign is the ideal time to make pages faster, not slower. I compare loading times on the old and new versions before launch.

I build every new site on a private staging copy that’s blocked from Google, then test it properly before it goes live. On launch day I work through the same checklist every time:

1. Remove any “noindex” tags and staging-only robots.txt rules from the live site.
2. Switch the redirects on, then test them in bulk by crawling the full list of old URLs and confirming each returns a single 301 to the right page.
3. Check that every page uses HTTPS and that the www and non-www versions redirect to one preferred address.
4. Confirm the analytics tracking and Search Console verification still work on the new templates.
5. Generate a fresh XML sitemap containing only the new URLs, and submit it in Search Console.
6. Test forms, checkout and any key conversion paths with real submissions.
7. Spot-check important pages with Search Console’s URL Inspection tool.

If the domain name itself is changing, Search Console’s Change of Address tool should be used as well. Google notes it isn’t needed for an HTTP to HTTPS move, a www change or new paths on the same domain.

Some movement in rankings is normal while Google recrawls the site. Google says a small to medium-sized site can take a few weeks for most pages to move over, with larger sites taking longer. What matters is catching genuine problems quickly:

• Check Search Console’s page indexing report and look for a spike in “not found” errors.
• Compare clicks and impressions for your most important pages against the snapshot from step 1.
• Watch your server logs or hosting stats, because Google crawls more heavily than usual straight after a migration.
• Ask the sites that link to you most often to update their links to the new addresses.

Keep the redirects in place for the long term. Google recommends at least a year, and from a visitor’s point of view there’s rarely a good reason to remove them at all.

Google’s own advice is to avoid changing everything at once. A new domain, a new platform and a new design all in one launch makes it very hard to tell which change caused a problem. Where budget and timescales allow, I’d rather stagger them: move the platform or domain first, let it settle, then roll out the design. When they do have to happen together, the redirect map and launch checks above become even more important.

It’s also worth timing the launch for a quieter period. For a retailer that usually means avoiding the run-up to Christmas; for a seasonal service business it means launching outside your peak months.

If your traffic falls sharply after a new site goes live, act quickly rather than waiting for it to recover on its own:

1. Check the live site isn’t blocking Google with a noindex tag or robots.txt rule. This is the fastest fix and the most damaging mistake.
2. Take your list of old URLs from before the launch and crawl it. Any that return a 404 or redirect to the wrong place need fixing.
3. Compare your top pages before and after. If important content was removed or thinned out, restore it.
4. Check page speed and mobile usability on the new templates.

Most post-launch drops I’ve been asked to investigate come down to missing redirects or content that was cut, and both can be put right. The sooner they’re fixed, the sooner rankings tend to return.

Written by Steve Davis, a UK freelance web developer trading as Envy Creative. I design, build and look after websites and online shops on WordPress and WooCommerce, Shopify, Magento 2 and Laravel, including the hosting and server work behind them.

• Google Search Central: How to move a site with URL changes
• Google Search Central: Redirects and Google Search
• Google Search Console Help: Change of Address tool