MUbase

Solutions for your tasks

Online base9 min readUpdated:

Moving a domain: protect your search visibility

Moving a domain with 301 redirects, sitemap and consistent page titles: the right order of steps, typical mistakes and a checklist for SMEs.

KMU | base editorial team

By emailLinkedIn
Open map with wooden markers

Your website is moving: to a new platform, to another provider or even under a new domain name. Anyone moving a domain usually has one worry: will people still find me afterwards? There is no guarantee, because search engines decide for themselves how they rank a website. But you can do a lot to make sure nothing is lost unnecessarily. This guide explains how SMEs go about a move: with redirects, a sitemap, consistent page titles and the right order of steps.

Three kinds of move, three different risks

Companies mean very different things by “moving a domain”. First work out which case applies to you:

Kind of moveWhat changes?Risk to visibility
New server, same domain and same addressesOnly the target in the DNSLow, if pages and addresses stay the same
New platform, same domain, different addressesDomain stays, some page addresses changeMedium: redirects are needed
New domain nameAll addresses changeHigh: every old address needs a destination
Kind of move
New server, same domain and same addresses
What changes?
Only the target in the DNS
Risk to visibility
Low, if pages and addresses stay the same
Kind of move
New platform, same domain, different addresses
What changes?
Domain stays, some page addresses change
Risk to visibility
Medium: redirects are needed
Kind of move
New domain name
What changes?
All addresses change
Risk to visibility
High: every old address needs a destination

Transferring the domain name from one registrar to another is something else again: it concerns the administration of the domain, not the content of the website. For .ch domains, registration is governed by SWITCH; your provider knows the procedure.

What search engines see and what can be lost

A search engine knows your website as a collection of addresses. Each address has content, a title, a description and incoming links from other pages. If you move and the old address suddenly answers “not found”, the search engine loses this connection, and so do visitors who use an old link or a bookmark. So it is not only rankings that can be lost, but also links from directories, trade pages, brochures and email signatures.

Careful preparation can limit this, but not rule it out. Even with a perfect move it can take a while until the search engine has picked up the new addresses, and rankings can shift. You should therefore read promises from providers such as “without any loss” with scepticism.

Redirects: using 301 correctly

A redirect tells the visitor and the search engine: “This page is now at a different address.” The status code 301 stands for “moved permanently” and is described in the HTTP standard (RFC 9110, section 15.4.2). For a move, it is the right choice. Other codes exist for redirects meant to last a few days; they are not suitable here.

For planning, a table with two columns, “old address” and “new address”, has proved its worth. Observe these rules:

  • Every old address gets a destination that matches in content. Do not redirect everything to the home page across the board, because visitors will not find what they were looking for there.
  • No chains and no loops. A link should arrive with a single redirect, not via three intermediate stops.
  • The destination must exist. A redirect to a page that does not exist is an error with a detour.
  • Addresses that stay the same do not need a redirect.
  • Redirects stay in place for a long time, at least as long as old links are in circulation. Do not remove them after a few weeks.

The inventory of existing pages from the relaunch provides the list of old addresses. Add the addresses that are linked only from outside.

Titles, descriptions and sitemap

Every page should have its own title and a short description that match its content. The search engine shows both in its results. During the move, keep the proven titles and descriptions of the pages that work well, and change them only on purpose. Do not use the same text everywhere.

The sitemap is a list of all addresses you want to make public, in the format of the sitemap protocol (sitemaps.org). It helps the search engine find the new pages. After the move it should contain only the new addresses and be reachable on the new domain. A further file, “robots.txt”, controls what search engines may read; make sure it does not block the new website by mistake, as is often the case in test environments.

The right order

Most problems come from the wrong order. This sequence has proved its worth:

  1. Create the inventory and assign a destination to every old address.
  2. Build the new website as a draft, without switching off the old one.
  3. Prepare redirects, titles, descriptions and sitemap and check them in the draft.
  4. Back up the DNS settings. Note the current entries of the domain so that you can go back if there are problems. If possible, first reduce the validity period (TTL) of the entries so that the switch takes effect faster.
  5. Switch the domain, check the certificate for the encrypted connection.
  6. Test old and new addresses, go through samples from the redirect table.
  7. Submit the sitemap and a check with the search engine’s tools, if you use them.

Never switch first and build the redirects afterwards: every hour in between shows error pages to visitors and search engines.

Do not forget email

Domain moves often affect email as well. The entries for mail traffic (MX, SPF and others) sit in the same DNS zone as the entries for the website. When switching, replace only the entries meant for the website and leave the mail entries unchanged as long as you are not deliberately changing mail provider. Everything about mailboxes is in the guide Email mailboxes on your own domain.

Watching after the move

Expect an observation phase of several weeks after the move. Check whether old addresses still return error pages, whether the contact form works and whether the pages appear in the search engine with their new addresses. Small fluctuations are normal. If an important page is missing for good, first check the redirect, the sitemap and robots.txt.

Practical example: Muster Bergblick Treuhand AG

Muster Bergblick Treuhand AG is a fictitious fiduciary firm. Its old website has 22 pages and is to appear on a new platform under the same domain. The new structure has 15 pages. The inventory shows: 9 old addresses stay unchanged. The other 13 need a redirect. Of these, 8 lead to a suitable successor page, for example the individual service pages to the new services overview with an anchor, and 5 to the respective parent page because there is no direct successor. Together that is 9 plus 13, so all 22 old addresses are covered.

The firm creates the redirect table with 13 rows, checks that no row points to another redirect and keeps the titles of the five most visited pages unchanged. The six mailboxes are with an external provider and are left alone; the mail entries are not touched during the switch. After the switch in the morning, the office manager tests all 13 redirects by hand, sends a test enquiry through the form and checks over the following weeks whether old addresses still produce errors. On the third day she changes the destination of two redirects to a more suitable one.

Checklist

  • Kind of move clarified (server, platform or domain name)
  • Inventory of all old addresses created, including those linked only from outside
  • Every old address assigned a suitable destination, no chains, no loops
  • Titles and descriptions of the most important pages kept or deliberately revised
  • Sitemap with the new addresses prepared, robots.txt checked
  • Current DNS entries backed up
  • Mail entries unchanged if the mail provider does not change
  • New website checked as a draft before the switch
  • After the switch, certificate, redirects and form tested
  • Observation phase of several weeks planned

How KMU | base helps

In Online | base the move is part of the process. In detail:

1. Redirects in the editor. For each website you maintain a list of redirects: old address and new page. The system checks that the destination is an existing page, that no old address appears twice and that a redirect does not point to itself. An existing page also cannot be entered as an old address at the same time. When your current website is taken over, our team transfers the checked 301 rules directly into the draft.

2. Title, description and preview image per page. In the editor you maintain the title and description for search engines for every page, as well as a preview image for sharing. The sitemap and the robots.txt file are generated automatically by the delivery for each connected domain.

3. Connect and check the domain. You add the domain and receive the DNS entries you need: a proof as a TXT entry, then an A or CNAME entry pointing to the target. With “Check connection” you see the status of the connection and the certificate. Our support has the certificate activated. When switching we back up the current DNS zone and leave existing mail entries (MX/TXT) untouched; if problems occur, we go back to the saved values.

4. Check first, then publish. The new website first appears as a draft with a preview. Your old website stays online until you give approval. We check how the old addresses behave after the domain change and document the result.

What Online | base cannot do: give guarantees about rankings in search engines. How quickly a search engine takes up the new addresses is not in our hands. And the completeness of the inventory depends on you also telling us about addresses that are linked only from outside.

More about the product on the Online base page. Take a look at the demo or open a test account. If you have questions, we will help you via the contact page. Current terms are under Prices.

Sources

  • IETF: RFC 9110, HTTP Semantics, section 15.4.2 “301 Moved Permanently”, June 2022: rfc-editor.org, accessed on 04.11.2026.
  • sitemaps.org: Sitemap protocol, page without date: sitemaps.org, accessed on 04.11.2026.
  • SWITCH: .ch domain names, page without date: nic.ch, accessed on 04.11.2026.

This guide does not replace legal or tax advice. Information as at 04.11.2026.

Back to top

Collaboration ×

The next step starts with a conversation.

What does your business need?