Do you always lose rankings in a relaunch?

No, a relaunch can be done without one. Google states that permanent redirects do not cause a loss in PageRank. What costs visibility is missing or wrong redirects, pages with no successor, and content that got trimmed during the rebuild. Expect fluctuation in the first weeks regardless, because Google has to fetch and reassess every address.

How long until Google shows the new addresses?

For a small to medium site Google says a few weeks for most pages to move across. Larger sites take longer. The speed depends on the number of addresses and on how fast your server responds. Submitting a sitemap speeds up discovery but does not force anything.

Does it have to be 301, or is 302 fine?

A relaunch calls for 301, the permanent redirect. 302 means temporary and tells Google the old address stays the authoritative one. Many systems default to 302, so the setting is worth checking. Ours was set that way and had to be changed before the move.

How long do the redirects need to stay in place?

Google recommends at least one year. In practice there is little reason to ever remove them: they cost nothing and they catch old links in directories, signatures and emails that still get clicked years later.

What is the Change of Address tool for?

Only for moving from one domain or subdomain to another, such as example.com to example.net. It does not apply to an http to https switch, a www to non-www switch, or new paths inside the same domain. Clean redirects cover those cases.

What is the most common mistake after a move?

A block that was meant for the build phase and stays behind. A noindex in the head or an entry in robots.txt keeps the construction site out of search, and it keeps the finished site out just as well. The second common one is internal links still pointing at the old addresses, which sends every click through a redirect.

Website relaunch without losing rankings: a 301 checklist

When people talk about a relaunch they talk about how it looks. What actually gets lost is something else: the addresses. Every page Google knows, every link from a directory, every recommendation in an email points at an address that may not exist after the rebuild.

We went through this in July 2026 with our own site: out of WordPress, into a new system, new structure, three languages instead of one and a half. This is the list we worked through, including the one thing that slipped past us anyway.

First, the inventory

Before anything gets built, everything gets counted. Without that list the rest is guesswork.

Ours came back with 14 reachable pages, 11 of them in the sitemap. And a handful of things nobody knew.

Finding	Count
Pages with no meta description	10 of 14
Pages with no h1	3
Test pages, public and in the sitemap	2
Off-topic page in the index	1
Pages with hreflang markup	0, despite a Spanish version existing
Spanish pages declaring `lang="de"`	all of them

The two test pages and the off-topic page had been indexable for years without anyone noticing. A relaunch is the best moment to find that sort of thing, because you touch every address once anyway.

How to build your own list:

Open sitemap.xml and copy every address
Export the indexed addresses from Google Search Console under Pages
Export the pages with the most clicks over the last twelve months
Merge the three lists and remove duplicates

The third list matters most. It tells you which pages actually bring visitors, and those are exactly the ones that must not get worse.

Mapping old to new

Now every old address gets a new one. A two column table is enough, and there are exactly four cases.

Case	What to do
The address stays the same	Nothing. The best case.
The content moves	301 to the new address
The content is absorbed into a bigger page	301 to that page, to the section if possible
The content is gone for good	301 to the nearest topic, otherwise 410

Redirecting to the home page is the emergency exit. Sending everything there tells Google none of those pages has a successor, and Google often treats such redirects like a 404. The nearest matching page is better, even when it only half fits.

On our site the home page, contact, blog, meeting page and both blog posts kept their addresses with no redirect at all. That was a decision: you can rebuild a site completely and still keep the addresses.

The redirects almost everyone forgets

This is the difference between a list from the sitemap and a complete list. A content system generates addresses nobody ever created, and they sit in the index all the same.

For WordPress those are:

Category pages, /category/web-design/
Tag pages, /tag/…
Author pages, /author/name/
Feeds, /feed/ and one per post at /post/feed/
Search, /?s=term
Attachment pages, one per uploaded image
Files under /wp-content/uploads/, which may be linked in emails and proposals
Date archives, /2024/10/

Then there is a detail that slips past easily: the trailing slash. WordPress serves addresses with a / at the end by default, many other systems without. /contact/ and /contact are two different addresses to a server. If all your old addresses had a slash, all your redirects have to match it.

Redirect permanently with 301

Google is explicit: permanent redirects, meaning 301 or 308. They cause no loss in PageRank.

302 means temporary, which says the opposite: the old address remains authoritative and the new one is a detour. For a relaunch that is wrong.

The catch is that many systems default to 302. Ours did, and the setting had to be changed before the move. One line checks it:

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://your-site.com/old-address/

301 and the right target means it is fine. 302 means go find the setting.

Keep chains short. Google recommends no more than three redirects in a chain and names five as the limit. Chains appear on their own when an old rule from a previous move is still around: old address to interim address to new address. Check with curl -L -I how many hops actually happen.

What happens on moving day

Turn the redirects on and spot check them, at minimum the twenty addresses with the most clicks.
Remove the blocks. The noindex from the build phase and every robots.txt entry that shielded the construction site. Google names this explicitly as a typical post-move mistake, and it is the most expensive one: the site is live and invisible.
Rewrite internal links. Every link pointing at your own pages gets the new address. Do not let the redirect do the work. Google recommends this explicitly, because it takes load off the server and shortens the path for visitors.
Submit the new sitemap and leave the old one in place for now. Google recommends both. Over the weeks the indexed count in the old sitemap drops to zero while the new one rises. That is your progress bar.
Check the canonicals. Every page should point at itself, with the new address.
Handle the old site deliberately. If it stays up under a different address, put it on noindex or it competes with the new one for the same terms. We took our old version down a day after launch.

The Change of Address tool in Search Console is only for a domain change, such as example.com to example.net. It is not meant for new paths inside the same domain.

The first few weeks

Google talks about a few weeks for a small to medium site before most pages have moved across. Fluctuation during that time is normal and not a reason to start fiddling with the redirects.

What to watch:

Where	What for
Search Console, Pages	Is the indexed count rising? Any new errors?
Search Console, Performance	Clicks and impressions against the same period last year
Server log or 404 report	Which old addresses run into nothing?
Manual spot check	The twenty most important addresses, once a week

The 404 report is the most productive of the four. It shows exactly the addresses your list did not have, and each one can be redirected after the fact.

The mistake we made anyway

We had a list, we had the redirects, and after the move eight dead links sat live for a week.

The cause was not the redirects but the multilingual setup. Our English and Spanish pages live under /en and /es, and the system puts that prefix in front of every link by itself. In the translated posts it had also been typed by hand. The result was /es/es/contacto, which is a 404.

Why nobody noticed for a week: the German pages were flawless. There the prefix is empty, so /kontakt stays /kontakt. Anyone clicking through their own site in their own language never sees it.

The check has been one line ever since, and it has to come back empty:

grep -rnE '\]\(/(en|es)/' content/pages/

The lesson generalises past our case: test the language you do not use yourself. And after a move, check every internal link mechanically instead of trusting your own clicking.

The list in short

Before

Collect every address from sitemap, Search Console and the click report
Map each old address to a new one, no blanket redirect to the home page
Add the system generated addresses: categories, tags, authors, feeds, search, attachments
Mind the trailing slash
Set the redirect type to 301

On moving day

Turn redirects on and spot check them
Remove noindex and any robots.txt blocks
Rewrite internal links to the new addresses
Submit the new sitemap, leave the old one for now
Canonical on every page pointing at itself
Take the old version down or set it to noindex

Afterwards

Check Search Console weekly for at least eight weeks
Work the 404 report and add the missing redirects
Check redirect chains, three hops maximum
Check internal links mechanically, including the languages you do not read
Keep the redirects at least a year, preferably forever

If a relaunch is coming up and you want to know which of your addresses have something to lose, drop us a line. We will reconcile your sitemap with Search Console and send you the list of addresses that need a redirect.

Relaunching a website without losing rankings: our working list