Website redesign or migration without losing SEO

An old website usually gets replaced for good reasons: the design has aged, it's awkward to use on a phone, the CMS is clumsy, or the platform itself is no longer supported. The new site is almost always better. And yet it's common to see Google traffic halve a few weeks after launch.

The cause is rarely the new design or the new platform. Google ties rankings to addresses, content and links — not to whether the site runs on WordPress, Shopify or Next.js. Keep those three through the move and the rankings stay. Lose them and the new site starts, in many ways, from zero.

Below is a checklist that applies to any redesign: a new look, a platform switch, a change of URL structure, a domain move or an online store migration. It doesn't matter whether you're moving to WordPress, away from it or somewhere else entirely. If you're specifically leaving WordPress for a code-based site, there's a separate overview: migrating from WordPress without losing your SEO.

SEO issues when migrating a site: why rankings drop

The causes are few and they repeat:

• URLs change without redirects. Google's index and other sites' links still point to old addresses that now return 404. Whatever trust a page had built up goes with the address.
• Content gets thinner. The new design is airier, texts are shortened to look "modern", titles and meta descriptions are rewritten or left empty. A page that held page one with 800 words may not hold it with 150.
• Internal links disappear. The menu is simpler, the footer no longer lists the services, and blog posts no longer point to service pages.
• The staging block goes live. The Disallow: / in robots.txt or the noindex tag that kept the test site out of search is still there at launch.
• Canonicals and hreflang point the wrong way — to the staging domain, to old addresses, or nowhere.
• The new site is slower. Heavy images and heavy JavaScript. How to measure it is covered in the website speed guide.

All of these are avoidable, and almost all of them have to be dealt with before launch.

Before launch

1. Inventory every URL

The first job is a list of every address on the old site. The sitemap alone is not enough — it often misses old campaign pages, PDFs and pages someone removed from the menu years ago that are still indexed. Build the list from four sources:

• the old sitemap.xml;
• the Google Search Console performance report, broken down by page (at least the last 12 months);
• the pages visited according to your analytics;
• pages that other sites link to (from a backlink tool).

On top of that, run a crawler over the old site — it finds addresses that none of the sources above know about.

2. Decide what happens to each URL

Every URL gets one of four decisions: keep, change, merge into another page, or remove. The best decision is always the first one — an address that doesn't change needs no redirect and loses nothing.

This also answers whether to change the URL structure during a redesign. If the current addresses are readable and logical, don't — a prettier structure doesn't earn rankings, but every changed address is a small risk. Change it when the old structure is genuinely bad (?page_id=123, dates in the path, languages mixed together).

3. A one-to-one redirect map

Every address that changes, merges or goes away gets a row in a table: old URL → new URL. The new address must be the closest equivalent in content — service page to service page, post to post, category to category.

The most common mistake is redirecting everything to the home page. It feels safe, but Google essentially treats such a redirect as a 404 (a soft 404), so the page's value is lost anyway. If a page genuinely has no counterpart, it's more honest to let it return 404 or 410 — and to have a proper 404 page that helps the lost visitor onward.

4. Extra checks for an online store

A store has tens or hundreds of times more addresses, and they are generated automatically. Check separately:

• product pages — if the platform changes the URL pattern (e.g. /product/name/ → /products/name), the redirects can be done with a rule rather than by hand;
• categories and subcategories — often the strongest pages in a store;
• discontinued products — redirect to the nearest category or a replacement product, not the home page;
• filter and sort parameters — these don't need redirecting one by one, but make sure the new store doesn't generate endless indexable combinations;
• product images — if images bring traffic from Google Images, their addresses change too.

5. Keep content, titles and internal links

On pages that bring traffic today, keep the title, meta description, H1 and body text. The design can change completely, but the text Google ranks the page for shouldn't disappear at the same time. If you want to rewrite content, do it after launch and one page at a time — then you can see what effect each change had.

The same goes for internal links: if the old site linked from the blog to the services and from the footer to every main page, the new one has to do the same. What else to check on the content side is in the list of 25 actions.

On launch day

• 301, not 302. A 301 says the move is permanent. A 302 is a temporary redirect, and Google may keep showing the old address in results.
• No redirect chains. The old address goes straight to the final one, not old → intermediate → new. If rules from a previous redesign are still around, point those directly at the new addresses too.
• One canonical host. http → https, and www → non-www (or the other way round) — one choice, and every other variant redirects there.
• Check robots.txt and noindex. The most classic mistake of all: the staging block goes live with the site and Google stops indexing it. Also check that canonical doesn't point to the staging domain.
• Submit the new sitemap in Search Console. It contains only final addresses that answer with 200 — nothing redirected or removed.
• Test the redirect map with a machine. Clicking a few links by hand is not a test. A simple script that goes through the list of old addresses is enough — each line of the file holds the full old and new address:

while read -r old new; do
  r=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")
  [ "$r" = "301 $new" ] || echo "FAIL: $old -> $r"
done < redirects.txt

Every line that reaches the screen is an address that doesn't redirect where it was supposed to.

After launch

For the first few weeks, two Search Console reports matter:

• "Not found (404)" — every old address that shows up here is a missing redirect. Add the rule and check again.
• "Page with redirect" — for old addresses this is expected, not an error. Google is telling you the address redirects elsewhere, exactly as planned. There is nothing to fix and nothing to validate.

It also pays to compare the old sitemap against the new site regularly, so that no URL disappears without a redirect. ArborIT does this before every upload with a script that compares the live site's sitemap with the fresh build and flags every address that would turn into a 404.

Redirects stay in place for at least a year, preferably for good. Old links on other sites, in bookmarks and in old emails don't go anywhere.

And finally: a few weeks of fluctuation is normal. Google has to recrawl the new addresses and move the signals over. Look at it page by page, not just the site-wide chart — then you can tell whether one page dropped (and why) or everything at once (in which case the culprit is usually noindex or robots.txt).

Our own lesson

All of this sounds obvious, but the mistake usually doesn't come from the big redesign — it comes from a small change later.

On our own site, after publication, the slug of one Swedish-language service page was renamed. No redirect was added. The old address had been the best-ranking page of that language version, so for a while Google showed a link in its results that led to a 404.

Since then the rule is: changing a published URL always requires a 301, and it's checked automatically before every upload. A migration doesn't end on launch day — every later change of address is a small migration of its own.

When to get help

A small site of ten pages can be redesigned properly on your own with this checklist. But if the site has hundreds of addresses, an online store or several languages, or if a significant share of your customers comes from Google, the redirect map and launch checks are worth handing to someone who does this regularly.

If you want to know where your current site stands before you start, request a free website audit. If a redesign is coming up, we can help with both website development and SEO — including when the new site is already live and the rankings have dropped.