Moving a website without losing Google rankings

Anyone who moves their website is usually afraid of one thing: that the pages that bring in visitors now will be nowhere to be found afterwards. That fear is justified, but the cause is rarely where you expect it. A new host or a new design does not cost you rankings. Addresses that vanish without a signpost do. This piece explains how to make those signposts, in what order, and what to check once the new site is live.

First: which kind of move is it

Google distinguishes two kinds of move, and they call for different approaches. If you only switch to another host or another CDN and every address stays the same, there is essentially one action: the DNS settings of your domain point to the new place. Google describes that route in the guide for a site move without URL changes (accessed on 20 September 2026).

If addresses do change, for example through a new domain, a new folder structure or the switch from HTTP to HTTPS, the rules in the guide for a site move with URL changes apply (accessed on 20 September 2026). Everything below is about that second kind, because that is where it goes wrong. Do not take the first kind lightly either, but you do not need an address map for it, only a good test and a clean switchover.

Move one thing at a time

The temptation is strong to do everything in one go: new domain, new system, new design, new copy. Don’t. Google recommends planning your changes one by one (accessed on 20 September 2026). If your rankings drop after the move, you want to know why. Change four things at once and you never will, and you cannot roll anything back in a targeted way either.

Plan the move in a quiet period, too. If your business has a season or a day of the week when things are slow, fewer visitors are hit by a mistake. Then allow for fluctuations. Google writes that for a medium-sized site it can take a few weeks or longer before the new addresses replace the old ones in the search results (accessed on 20 September 2026). A dip in the first days is therefore normal and no reason to panic and roll back.

Make the map first, then the move

The most important work happens before anything moves. Make a list of every address that currently exists and put next to it the address where that page will live. Google calls this an address map, in English a URL mapping (accessed on 20 September 2026). Without that map you move on gut feeling, and gut feeling forgets the page that once ranked well and has since gone unnoticed.

Here is how to build the list:

• Pull the addresses from several sources: your sitemap, a crawl of your own site and the performance report in Search Console. The sitemap alone misses addresses that used to exist.
• Note next to each address what it currently delivers: impressions and clicks from Search Console, and whether other sites link to it. That determines the order in which you check things.
• Give each address a destination: the page that answers the same question. If it no longer exists, an error is more honest than a redirect to something else. In that case Google asks for a 404 or 410 as the error code (accessed on 20 September 2026).

Don’t send everything to the homepage

This is a common mistake, and we made it ourselves. If you do not know where an old address should go, the homepage is the easy way out. Google explicitly warns against it: sending many old addresses to one irrelevant destination, such as the homepage, can be treated as a soft 404 (accessed on 20 September 2026). With a soft 404 the redirect does not count as proof that the content has moved.

On 22 July 2026 we went through our own redirect table using Search Console data for the three months up to and including 19 July 2026. It turned out that 40 of our 49 redirects pointed to the homepage, while Google can treat such redirects as soft 404s (accessed on 20 September 2026). Some of those old addresses were still getting impressions. That tells you something: people were still searching for that content and Google still showed them the old address, but they landed on a page that did not answer their question. We repointed 30 of them to the page that does answer the original question. The method is simple and repeatable: export the redirects, export the impressions per address, and see which destinations have nothing to do with the search query.

Make the redirect permanent and single-step

For a move, a permanent redirect is the right choice. Google explains that a 301 or 308 signals that the new destination is the canonical one, and that a temporary redirect such as 302 or 307 keeps the old address in the search results (accessed on 20 September 2026). Using a temporary redirect for a lasting move is therefore a subtle way of blocking your own move.

Also choose a redirect that happens on the server, not in JavaScript. Google calls JavaScript redirects only suitable if you cannot do anything else (accessed on 20 September 2026). And keep it to one step: an old address that goes through an intermediate address to the new one is slower for visitors and gives more chances for something to break along the way.

Google advises keeping the redirects in place for at least 1 year (accessed on 20 September 2026), so that Google can transfer all signals, including the links from other sites to your old addresses. For visitors, you never really need to remove them. Do update your own links, though, because a redirect is slower than a direct address.

How we did it with our own blog

A move on a small scale is good practice, so let us take our own blog as the example. Up to and including 14 September 2026, the Dutch FWRD blog lived at /blog/. On 15 September 2026 it moved to /nl/blog/. Four days after that, on 19 September 2026, /blog/ became the English blog, with German, French, Spanish and Portuguese versions alongside it under their own language folder.

There were three choices in that, and you will find them in every move:

• A fixed list instead of a wildcard rule. The convenient solution was one rule that sends everything under /blog/ to /nl/blog/. But now that /blog/ holds English articles, that rule would hijack every English article and send it to a Dutch page. Only three Dutch articles ever lived at the old address, so we recorded those three as a fixed list. Anything not on the list is not redirected.
• Take all variants of an address along. A page has more addresses than you think. Besides the article itself, the version without a trailing slash, the plain-text version for machines with the extension .md and the author pages moved too. If you only redirect the article, you leave the rest behind.
• Deliberately not redirecting something. The blog feed, /blog/rss.xml, has belonged to the English blog since that switch. Had we redirected it to the Dutch feed, every English page would have announced a feed in another language. We only found that out in the first round of translations. A redirect must therefore follow the intent of the old address, not just the path.

That last point is the core of this whole piece: a redirect is a statement about what an address means. That statement has to be correct, even when the question behind it changes. The result can be checked with an ordinary command on the command line or in your browser: the old address must reach the new page in one step with a permanent redirect. That is how we checked it on 15 September 2026, and that is how you should walk through every address in your own map.

What to check right after the move

As soon as the redirects are live, there is a short list to work through. Google names the key points in the guide for starting the move (accessed on 20 September 2026):

• Test the redirects. Do that for your most important addresses with the URL Inspection tool in Search Console, and for the rest with a script that walks the whole map.
• Check that the canonical reference on the new pages points to the new addresses, and not still to the old ones.
• Remove the noindex rule you set while building to keep the new site from being indexed too early. This mistake stays invisible until your rankings are gone, because the new site simply looks fine.
• Check your robots.txt. Many builders block all crawling in it during development and forget to lift that.
• Submit the new sitemap in Search Console.
• If you are moving to a different domain, there is also the Change of Address tool in Search Console. For a move within the same domain, such as from HTTP to HTTPS or from one folder to another, you do not need it.

In the weeks that follow, look every day at the indexed pages report and the performance report, per address and not just as a total. A move happens per address, so you also see per address whether it worked.

What often goes wrong

Four mistakes are easy to make. The first is building the map from what you see on the site instead of what Google already knows. The second is leaving a build setting such as noindex in place. The third is moving and rewriting the content at the same time, so that you can no longer explain a dip. The fourth is cleaning up the redirects after a few weeks because the old site is gone anyway.

If you would rather not work this out yourself, you can have your website moved over, where your existing copy and structure are the starting point of the new site. If you first want to know what is on your site now and what Google makes of it, start with an audit of your website.