How to redesign a website without losing Google rankings

The new site is nearly ready. It looks better, it loads faster and everyone is happy, until someone asks what will happen to the visits from Google. If you want to redesign a website without losing Google rankings, the most important work happens before the launch, while the old site is still online.

In this guide you collect the old addresses, decide where each one leads, redirect them with 301s and carry over the titles and texts. You keep the test copy out of Google and know what to watch in Search Console after the launch. The checklist at the end can go straight to whoever builds the site.

Why Google rankings depend on addresses

Google keeps pages in its index, and every page has an address (URL). Over time that address collects rankings for certain searches and links from other sites. As long as it answers with the same content, all of that stays.

The trouble starts when the new site changes the addresses. If an old address returns a 404 error, Google sees a page that has disappeared and the new page starts from scratch, while links from other sites send visitors to an error page. That is how a store loses traffic without anything visibly broken on the new site.

Google treats moves with URL changes separately from moves without them. If only the hosting changes and the addresses stay the same, the risk is small, and the guide to switching hosting without downtime is a better fit. A new platform, or rebuilding a store as headless, almost always changes some addresses, because every system arranges products and categories its own way.

Collect the old addresses before you change anything

Build the list of old addresses while the old site is still running, and collect from several sources, because each one sees a different part of the site.

The sitemap

Since version 5.5, WordPress makes an XML sitemap on its own at /wp-sitemap.xml. Some SEO plugins switch it off and publish their own, as Yoast SEO has done since version 14.5, and then the address is in the plugin settings.

The command below opens the sitemap, goes through the smaller sitemaps in it and saves every address to the file old-urls.txt. Run it on a Mac or Linux computer or in cPanel's Terminal, and change the address in the first line if the sitemap comes from a plugin.

# Mac, Linux or cPanel > Terminal. Read-only, changes nothing.
curl -s https://primer.bg/wp-sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
  | while read -r map; do
      curl -s "$map" | grep -o '<loc>[^<]*' | sed 's/<loc>//'
    done > old-urls.txt

The sitemap lists only the pages WordPress considers public, so it is just the start of the list.

Search Console

In the Performance report, open the Pages tab, choose the longest period and download the table with the Export button. These pages bring visits from Google and deserve the most attention. In the Links report, the Top linked pages table shows the pages other sites link to. If one of them disappears without a redirect, those links start leading to an error.

A crawler

A crawler moves through the site the way Googlebot does and records every address with its status code, title and meta description. It also finds addresses missing from the sitemap, such as PDF files or old campaigns. Screaming Frog SEO Spider is one such tool, and its free version crawls up to 500 addresses. Keep the export, so you can compare titles and descriptions with the new site later.

Map every old address to a new one

Next to each old address, write the page on the new site that replaces it most closely.

• Same content at a new address. Redirect the old address to the new one.
• Two pages merged into one. Redirect both old addresses to the merged page, which Google explicitly allows.
• A page removed with no replacement. Let it return 404 or 410 instead of redirecting it to the home page. Google advises against sending many old addresses to one unrelated page and may treat them as soft 404s, errors that pretend to be normal pages.
• An address that does not change. It stays on the list so you can check it after the launch.

A table for a small company site might look like this.

Redirect straight to the final address. If A leads to B and B leads to C, that is a chain. Google advises going directly to the final destination, because every hop adds delay and not every browser follows long chains.

How to redirect old addresses with 301s

A 301 redirect tells the browser and Google that a page has moved permanently, and Google takes it as a strong signal that the new address is the main one. A 302 is temporary and sends a weak signal, so use 301 when you change the site.

In Apache with the .htaccess file

On Apache, the rules go into the .htaccess file in the site's main folder, usually public_html. Copy the file before you change it. The lines below redirect two old addresses. Add them above the # BEGIN WordPress line, never inside the WordPress block, because WordPress rewrites that block when the permalinks are saved.

# .htaccess in the site's main folder, above # BEGIN WordPress
RedirectMatch 301 ^/about-us/?$ https://primer.bg/company/
RedirectMatch 301 ^/blog/?$ https://primer.bg/news/

The ^ and $ signs mean the whole address has to match, and /? accepts it with or without a trailing slash. Cyrillic addresses can be written in Cyrillic, as long as the file is saved as UTF-8. To undo a redirect, delete its line.

In nginx

nginx has no .htaccess. The rule goes into the site's server block and takes effect after nginx reloads, so the host or the server administrator usually adds it.

# nginx configuration, inside the site's server block
location = /about-us/ {
    return 301 https://primer.bg/company/;
}

The = sign means an exact match, so write the old address as it appears on the list, trailing slash included.

With a redirect plugin

If you cannot edit the server files, or there are hundreds of redirects, the Redirection plugin manages them from the admin, imports lists from CSV files and logs 404 errors. Its redirects run through WordPress, while those in .htaccess or nginx run before it loads.

Check the redirects

Once the rules are live, check every address on the list. For each old address the command prints the final status code, the number of redirects and the final address.

# Mac, Linux or cPanel > Terminal. Read-only, changes nothing.
while read -r url; do
  printf '%s ' "$url"
  curl -s -o /dev/null -L \
    -w '%{http_code} %{num_redirects} %{url_effective}\n' "$url"
done < old-urls.txt

200, 1 and the new address from your table mean all is well. 200 and 2 is a chain to shorten, 404 and 0 is a missing redirect, and 200 and 0 is an address that did not change.

Keep the titles, meta descriptions and content

Redirects keep the addresses, but Google ranks pages on their content. A new design often shortens texts and drops blocks that look unnecessary, and a page that brings visits can then lose rankings even with a correct redirect.

Texts and titles

Carry over the title (the title element) and meta description of every important page, and compare them with the crawl export. Keep the headings and the main text. If a page appeared for "roof repair Sofia", its new version should answer that question at least as clearly. A product description cut to two lines loses the words people found it by. Carry over the alt text of the images too, because Google uses it to understand them.

Internal links, canonical and hreflang

The menu, the footer and links in texts should point straight to the new addresses rather than through redirects, as Google explicitly advises. The canonical tag tells Google which address is the main one for a page. Every new page should point to itself with its new address, so make sure no canonical points to the test copy or the old addresses. On a multilingual site, update hreflang as well, the links between the language versions.

Structured data

Structured data is code that describes the page to Google, for example a product with a price or a company with an address and phone number. The old site may have had it from a plugin the new one does not use, so test the main pages with the Rich Results Test before and after the change.

The full list of technical checks is in the technical SEO checklist before launch. When we rebuild a WooCommerce store on our model, we redirect the old addresses to the new ones and carry over the SEO data of every page.

Keep the test copy out of Google

A new site is usually built on a test copy (staging), for example on a subdomain. If Google indexes it, unfinished pages and duplicate content appear in the results. The three ways to hide it work differently.

• A password. Server-level password protection is the most reliable, and Google recommends it for content that only certain people should see.
• noindex. The <meta name="robots" content="noindex"> tag or the X-Robots-Tag: noindex HTTP header tells Google not to show the page. It works only if robots.txt does not block the page, because otherwise Google never sees the tag.
• robots.txt. It is not enough on its own. Google says robots.txt is not a way to keep a page out of Google, and a blocked address can still appear in results without a description.

In WordPress, the "Discourage search engines from indexing this site" box under Settings, Reading adds a robots tag with noindex and nofollow to every page. Since version 5.3 it leaves robots.txt alone, and while it is on, the sitemap is switched off too.

What to do on launch day

Launch day goes more calmly when the order is settled in advance.

1. Make a full backup of the old site, so you can go back.
2. Put the new site and the redirects live at the same moment, so the old addresses never return 404.
3. Remove noindex and check Settings, Reading and robots.txt.
4. Run the redirect check and fix every 404 and every chain.
5. Submit the new sitemap in the Sitemaps report of Search Console.
6. If the domain changes, use the Change of Address tool for the old domain. Moving from http to https, or between www and non-www, does not need it.
7. Update the addresses you placed yourself in ads, social profiles and email signatures, and contact the owners of the sites with your most important links.

What to watch in Search Console after the launch

For the first weeks, open Search Console at least once a week and look at four places.

• The Pages report. Addresses without a redirect appear under "Not found (404)", so add them to your table and your rules. "Page with redirect" is normal for the old addresses, because Google does not index an address that redirects. New pages under "URL marked 'noindex'" mean a noindex was left somewhere.
• The Sitemaps report. The new sitemap starts at zero indexed pages and grows gradually.
• The Performance report. Compare clicks and impressions with the period before the change, and watch the Pages tab for the new addresses getting impressions.
• URL Inspection. Check a few key pages to see whether they are indexed and what Google sees.

Google says most pages of a small or medium site move in the index within a few weeks, that larger sites take longer, and that rankings can fluctuate temporarily during the move. A dip and a recovery can happen even after a careful change. The aim is to keep what the site has built up, and nobody can guarantee rankings, because Google evaluates the new pages afresh. If a dip lasts several weeks, look again for 404s, a leftover noindex, shortened content and lost internal links.

Google advises keeping redirects as long as possible, generally at least a year, and for visitors with old bookmarks it makes sense to keep them for good.

Checklist

• The old addresses are collected from the sitemap, from Search Console and with a crawler.
• Every old address has a new one or deliberately returns 404 or 410, with no mass redirects to the home page.
• The redirects are 301s and go straight to the final address.
• Titles, meta descriptions, texts and image alt texts are carried over.
• Internal links, canonical tags and hreflang use the new addresses.
• The structured data of the main pages is checked with the Rich Results Test.
• The test copy is behind a password, and noindex is removed on launch day.
• Every moved address reaches 200 after a single redirect.
• The new sitemap is submitted, Search Console is reviewed weekly for at least a month, and the redirects stay for at least a year.

When you do not have to do this yourself

If only the hosting changes, the addresses stay the same and most of these steps do not apply, so follow the guide to switching hosting without downtime instead.

If you are building a new site or rebuilding a slow WooCommerce store, this work is part of our website and online store development. In a rebuild we redirect every changed address and move the content and the SEO data, while products, orders and customer accounts stay in WooCommerce. Everything goes through staging and launches with a rollback plan. The aim is to keep what the site has built up in Google, and we do not promise rankings, because they do not depend on us alone.

Sources

• Google, Site moves with URL changes
• Google, Changing your hosting
• Google, Redirects and Google Search
• Google, How HTTP status codes affect Google's crawlers
• Google, Block search indexing with noindex
• Google, Control what you share with Google
• Google, Introduction to robots.txt
• Google, Build and submit a sitemap
• Search Console Help, Page indexing report, Links report and Change of Address tool
• WordPress, Settings Reading screen
• WordPress Core, Changes to prevent search engines indexing sites (5.3)
• WordPress Core, New XML sitemaps functionality in WordPress 5.5
• Yoast, Yoast SEO 14.5 changelog
• Apache HTTP Server, mod_alias (RedirectMatch)
• nginx, location and return
• WordPress.org plugins, Redirection
• Screaming Frog, SEO Spider