Skip to content

Website

Website migration SEO: how to redesign without losing your rankings

Redesigning or moving your website without losing rankings: redirect mapping, 301s, a launch-day checklist and what to expect afterwards, per Google.

Author
Mücahit Arslan · Co-founder
Published
Reading time
10 min read
A monitor on a desk shows an arrow from an old website layout to a new one, with a rising green line beneath.
Contents
  1. Why do rankings drop after a redesign?
  2. How risky is each kind of migration?
  3. What should you do before the migration?
  4. What else has to move besides redirects?
  5. What is a 301 redirect, and how is it different from a 302?
  6. When should you go live?
  7. What should you check on launch day?
  8. What changes if the domain changes?
  9. What should you expect after launch?
  10. Why won't our own site need redirects?
  11. What should you ask your agency before a migration?

You keep your Google rankings through a redesign or migration by deliberately carrying everything the old site has built up in Google over to the new one: every old address is matched to its counterpart on the new site, changed addresses are linked with permanent 301 redirects, content that ranks well isn't lost, and on launch day you check that no technical block is left behind. According to Google, it takes a few weeks for the new addresses to settle on a medium-sized site; temporary fluctuation during that time is normal, while lasting losses are usually the result of an unplanned migration.

Why do rankings drop after a redesign?

Rankings usually drop after a redesign not because of the new design, but because what the old site had built up in Google wasn't carried over. Four causes are the most common:

  1. Addresses changed without redirects. Pages Google has known for years start returning errors overnight. Links from other websites lead nowhere.
  2. Well-ranking content disappeared. In the new design, text was cut, pages were merged or dropped. Google no longer finds an answer for those searches.
  3. A technical block was left in place. The noindex rule or robots.txt block meant to keep Google out of the test site is still active on the live site. Google can't read the new site at all.
  4. Internal links and the sitemap point to old addresses. The site links internally to redirects or error pages, and Google understands the new structure late and incompletely.

All four are avoidable. What they have in common is that the redesign was treated purely as a design project.

How risky is each kind of migration?

Not every redesign carries the same risk. The risk depends on how much of what Google already knows is changing:

Type of changeDo addresses change?Risk
New design only, same addresses and contentNoLow
New platform (a different CMS, for example), addresses keptNoLow to medium
New address structure (page names, folders, language prefixes)YesHigh
New domainYes, all of themHigh
Merging several websitesYesHigh

Knowing which row you are in tells you how much planning the job needs. Not changing addresses unnecessarily, even in a pure design refresh, removes most of the risk from the start.

What should you do before the migration?

The most important job before a migration is a complete inventory of the old site and a decision on where each old address will lead. Google calls this URL mapping and recommends it as the first step of any move.

Inventory. List every address on the old site: pages, blog posts, products, PDFs, images. The list from your CMS isn't enough; in Google Search Console, check which pages actually get clicks and impressions, and which pages have links from other websites. The most valuable pages often show up exactly there.

Redirect map. Match each old address to the single page on the new site whose content is closest. Three rules apply:

  • Match one to one: old service page to new service page, old post to new post.
  • Don't funnel lots of old pages to the homepage. Google explicitly calls redirecting many old URLs to one irrelevant destination, such as the homepage, a mistake.
  • Pages with no real equivalent, and with no traffic or links, don't have to be redirected; they can go.

Content check. The text of pages that rank well must not vanish on the new site. If it has to be shortened, decide based on which searches each section ranks for.

What else has to move besides redirects?

Redirects move the addresses, but a page's strength in Google doesn't come from its address alone. Five things are easily lost when pages are rebuilt, and each has to be carried over on its own.

Page titles and descriptions. The title and description shown in search results are often texts refined over years that earn clicks. Every page on the new site needs a deliberate equivalent; leave the fields empty and the system generates its own title, usually a worse one.

Heading structure and text. A page's main heading and subheadings help Google understand what it is about. If the new design turns them into decorative slogans, the page loses strength for the same searches.

Structured data. If the old site had structured data for business details, products, FAQs or articles, the new site must carry the same information at least as well. If it disappears, enhanced appearances in search results can disappear with it.

Images. Image addresses and alt text rank too, in image search. If the addresses of important images change, redirect them as well and keep their descriptions.

Internal links. Links within your text to important pages tell Google which pages matter. If the new site reduces them to the navigation menu, important pages lose visibility.

What these five have in common is that they are content and SEO work, not design work. That is why someone on the redesign team has to own them from the start.

What is a 301 redirect, and how is it different from a 302?

A 301 redirect is the server's answer that a page has moved permanently. According to Google's documentation on redirects, with a permanent redirect (301 or 308) Google follows it and uses it as a signal that the target should be the canonical address. With a temporary redirect (302 or 307), Google still follows it but doesn't treat the target as canonical:

RedirectMeaningHow Google treats itIn a migration
301, 308PermanentThe new address becomes canonicalRight choice
302, 307TemporaryThe old address may stayOnly for genuinely temporary cases

Google recommends using permanent server-side redirects wherever possible. JavaScript redirects are a last resort, because Google may not always execute them. Two more rules: don't chain redirects, so every old address goes straight to its final destination; and keep redirects, as Google recommends, for at least a year and in practice for good.

When should you go live?

Go live in the quietest period for your business, and at the start of a working day. A few weeks of temporary fluctuation are most expensive when they land in your busiest season: the last quarter for an online shop, the peak booking months for a practice, the start of the season for a travel company. Just before a big campaign is also a bad time, because organic and paid traffic would both hit a new site that may still have issues.

Make sure the team is reachable in the days that follow; a site launched on a Friday evening can lose two days to a problem nobody notices over the weekend. Before launch, keep a full backup of the old site and the final version of the redirect map. If something goes wrong, they are the quickest way back, or to the page that went missing.

What should you check on launch day?

Launch day is when the new site opens to Google. A short checklist catches the most expensive mistakes on the day:

  1. Do the redirects work? Open a sample of old addresses from the map; each should go straight to the right new page.
  2. Are the test blocks gone? Noindex rules and robots.txt blocks from the test environment must be removed. Google specifically lists them as things to remove after a move.
  3. Are canonical tags right? Every page should point to its own new address as canonical.
  4. Is the sitemap up to date? The new sitemap contains only new addresses and is submitted in Search Console.
  5. Do internal links point to new addresses? The menu, footer and in-text links should go straight to new pages, not through redirects.
  6. Is hreflang right on multilingual sites? Every language version should point to the new addresses of the others.
  7. Is measurement running? Analytics and conversion tracking must be set up on the new site, or you'll never see the effect of the migration.

What changes if the domain changes?

If the domain changes, everything above still applies, and one step is added: the Change of Address tool in Google Search Console. It tells Google your site has moved from one domain to another. There are two prerequisites: a 301 redirect from the old homepage to the new homepage, and ownership of both domains verified in Search Console.

The tool's effect is limited: according to Google, its actions continue for 180 days after you start the move, after which Google no longer recognises a relationship between the old and new sites. So the redirects stay in place even when you use the tool. If only folders or page names change, the tool isn't used; redirects alone are enough.

What should you expect after launch?

After launch you spend a few weeks watching Google gradually learn the new site. According to Google, for a medium-sized website it can take a few weeks or more before the new addresses replace the old ones, and longer for large sites. Temporary fluctuation during this time is normal.

In the first weeks, keep an eye on:

  • the Search Console indexing report: are new addresses being indexed and old ones dropping out?
  • error pages: unexpected 404s mean an address was missed in the map; redirect it straight away.
  • your most valuable pages: are the successors of your highest-traffic pages taking over their rankings?
  • conversions: watch enquiries and sales as well as traffic; it is the only way to see how the new design performs.

If traffic hasn't moved back towards its previous level after a few weeks, something is usually missing from the plan: a forgotten group of pages, lost content, a block left in place.

Why won't our own site need redirects?

So that no addresses have to change after launch, we fixed our site's address structure beforehand: the domain, language prefixes and page names are recorded as decisions that won't change once the site is live. Any address change after launch would mean redirects across the whole site, so we made every change before launch.

Two real examples:

  • On 22 September 2026 we changed the address of our web design service page in all three languages. German customers search for "Onlineshop", and the word in the old address was industry jargon. Had the site already been live, that would have meant separate 301 redirects in three languages.
  • On 24 September 2026 we removed an older blog post that didn't meet our standard, in all three languages. The reasoning was a single sentence: "The site isn't live, so no 301 is needed."

On top of that, the www version of our domain permanently redirects to the address without www. Automated tests check on every change that all internal links open and that no page is left without an internal link. We use the same check on migration projects; the "internal links" item on the launch-day checklist is done by a test, not by hand.

What should you ask your agency before a migration?

Ask the agency rebuilding your site these questions before you talk about designs:

  1. How will you build the inventory of the old site, and will you use Search Console data?
  2. Can I see the redirect map before launch?
  3. Will addresses change, and is that really necessary?
  4. How will the content of well-ranking pages be preserved?
  5. What checks will you run on launch day?
  6. For how many weeks, and based on which data, will you monitor after launch?

An agency without clear answers may build you a beautiful new site but won't necessarily protect your place in Google. What else to look for when commissioning a site is covered in our guide on what a business website should include, and why the address structure has to be right from day one on multilingual sites in our guide to a multilingual website for Germany.

Frequently asked questions

It can, but it doesn't have to. A redesign that keeps the same addresses and content carries little risk. Rankings usually drop when addresses change without redirects, when well-ranking content disappears, or when a technical block from the test site stays in place after launch. With a redirect map, content checks and a launch-day checklist, most redesigns keep their rankings after a few weeks of normal fluctuation.

A 301 is permanent, a 302 temporary. According to Google, a permanent redirect signals that the new address should be treated as the main one; with a temporary redirect, Google follows it but may keep the old address in search results. Using a 302 for pages that have moved for good delays the new page taking over the ranking. In a migration, a 301 is almost always right.

Google says that for a medium-sized website it can take a few weeks or more before the new addresses gradually replace the old ones in search, and longer for large sites. Temporary fluctuation during that time is normal. If redirects are right and no content has been lost, traffic usually returns to its previous level within weeks. If it is still down after months, something is missing from the plan.

Google recommends keeping redirects for as long as possible, generally at least a year. That is how long ranking signals need to pass from the old addresses to the new ones. In practice there is no reason to ever remove them: old links on other websites can still bring visitors years later. Treat the redirect list as a permanent part of the website.

You can, but it comes at a cost. A deleted page loses its place in search results and the value of the links other sites point at it, and anyone arriving lands on an error page. Removing pages with no equivalent, no traffic and no links is fine. Redirecting everything to the homepage is not a fix, though; Google explicitly calls that a mistake.

Usually not, as long as the addresses stay the same. Moving to a different server or host doesn't change any page addresses, so no redirects are needed. The risks lie elsewhere: the site being unreachable during the move, the new server being slower, or files going missing along the way. Schedule the move for a quiet time and check your pages and loading speed afterwards.

Questions about this topic?

Write to Mücahit Arslan directly. You will be talking to the person who wrote this article.

Contact 

More articles