Website migration — hosting, domain and 301 redirects

A website migration does not end on the day the site runs on the new server or at the new address. It ends when Google notices — and that can take weeks. We know this from our own site: the Polish edition of this very article went through a migration.

Until 14 September it lived at an address in a guides section of our Polish site that we closed down. That day it got a permanent redirect to its current address. Five days later, Search Console showed this:

A reader who clicks the old link lands on the new address from the first second. But Google only learns about the redirect on its next visit to the old address — and it last visited in July. Until then, the index holds an address that no longer exists, while the new one waits in the queue. Google's documentation says so directly: for a small or medium site, moving most addresses takes "a few weeks", and fluctuations in visibility during that time are "normal".

This is not an argument against migrating. It is an argument for planning a migration as if Google will find out about it late — because it will.

Three migrations under one name

"Website migration" is a word used for three different operations. They differ in what changes from the search engine's point of view — and that determines what can go wrong.

Hosting change — the same site, the same addresses, a different server. For Google nothing happens except that a different machine answers at a known address. It is the safest of the three, provided everything was moved.

Domain change — every address on the site becomes new. For Google it is a move of the entire site, which has to be reported and carried out with redirects, address by address.

Structure or platform change — a new content management system, a new shop, a reorganisation of sections. The domain stays, but some addresses change. This is the most common source of losses, because it looks like a "purely technical" change, while for the search engine every changed address without a redirect is a new, empty page.

In practice these operations often come together — a new platform on new hosting, sometimes under a new domain. In that case it is worth separating them in time if you can. Google allows large sites to be moved section by section and recommends moving all addresses at once for smaller ones; either way, it is easier to find the cause of a drop when one thing changed in a given week, not three.

Moving a website to new hosting

Google describes moving a site to new hosting without changing addresses in a separate document, and it contains three recommendations worth taking literally.

Lower the TTL at least a week in advance. Google suggests a value of "a few hours" set "at least a week in advance". Why so early is explained in the next section; in short, lowering it only takes effect once the old, longer value remembered by servers along the way has expired.

Do not switch off the old hosting on moving day. Google advises watching the old server's logs and switching it off only once traffic to it has dropped to zero. For several days, some visitors — and some crawlers — will still reach the old IP address. If the old server no longer responds, those are lost visits. Incidentally, that is an argument against giving notice on the old hosting contract so that it ends on migration day.

A drop in Googlebot activity after the move is normal. According to the documentation, right after launch on the new server Google usually slows crawling temporarily, then gradually speeds up over the following days. There is no need to react.

What Google's documentation does not say, because it is not its business: what has to be moved. The site's files are only part of it. Add the database, files uploaded by users, scheduled tasks, server configuration, the certificate and email — if it was on the same hosting, moving it is a separate operation that is easy to overlook, because "the site works". And the PHP version: if the new server runs a newer one than the old, an older plugin can stop working on moving day. Before anything is switched, you need a backup that can actually be restored — ideally on the new server itself, because then testing the backup and rehearsing the migration are one and the same task.

DNS propagation is TTL, not 48 hours

A common line about DNS changes is that "propagation takes up to 48 hours". It sounds as if the news of the new address spreads across the internet like a wave. It does not. Nothing spreads — the copies that servers along the way have remembered expire, and how long they are kept is set by the owner of the record. That is the TTL, the record's time to live, given in seconds.

If the record pointing to the server's address has a TTL of 86,400 seconds — a day — then a server that asked for it just before the change will keep sending visitors to the old address for the next day. If it is 300 seconds, for five minutes. That is why the TTL is lowered in advance: first the old, long value has to expire, and only then will the address change spread within the new, short one.

We checked both values on our own .ch domain. The records pointing to our server's address have a TTL of 300 seconds. The .ch registry publishes the information about which name servers handle the domain with a TTL of 3,600 seconds — an hour. That is much shorter than on other extensions: for our .eu domain the same information carries 86,400 seconds, a full day. This creates a practical difference between two operations that are named similarly in control panels:

• Changing records (server address, email) — a DNS change with your current provider. It takes effect within the TTL you set yourself.
• Changing name servers (moving DNS hosting to another company) — here the registry's own TTL is added, which you cannot shorten. For a .ch domain it is an hour; for many other extensions it is a day, which is where the popular "24–48 hours" comes from.

The same applies to moving email, even if the email itself is not going anywhere. When you change name servers, the new DNS provider does not know your existing records — you have to recreate them, including the mail records (MX) and the ones that confirm you are allowed to send email from the domain (SPF, DKIM). If they are missed, the site will start working on the new server at the very moment email stops arriving. So before changing name servers, it is worth exporting the whole zone, not just noting down the server address.

The conclusion for migration day: when changing hosting, it is better to change the records with your current DNS provider than to move DNS hosting elsewhere on the same day. Two changes at once mean two different clocks.

Transferring a .ch domain — the Auth-Code

A domain transfer is a change of the company that manages your domain — the registrar. It does not change the owner, does not change the site's address and does not by itself affect how the site works. But it is where most migrations get stuck, and almost never for technical reasons.

For .ch domains the rules are set by Switch, which runs the registry for Switzerland and Liechtenstein. You cannot register or manage a .ch domain directly with Switch — only through an accredited registrar, and the transfer works like this:

1. The Auth-Code. To move a domain to another registrar, you need a transfer code. Your current registrar provides it.
2. Handing it over. You forward the code to the new registrar, who takes over management of the domain.
3. A lock afterwards. After a successful transfer, the registry sets a status that prevents another transfer for 60 days (according to Switch's EPP manual). Two registrar changes in a row, in the middle of a migration, are therefore not possible.

Switch adds one sentence that matters more than it seems: the contract with the registrar is private, and any dispute arising from it must be settled in the civil courts. There is no registry complaint procedure to fall back on. If the registrar does not hand over the code, or the registrar account belongs to someone else, you are dealing with a contractual problem, not a technical one.

And that is where transfers most often get stuck: whose name and whose account the domain is registered under. If the domain was registered years ago by an agency or by an employee who has since left, the registrar account and the contact address on record may belong to them — and getting the code turns into a negotiation.

It is the same problem we describe under website maintenance services: the domain should be registered to the company, with an email address someone reads. During a transfer this stops being good practice and becomes a precondition.

Changing a domain

A domain change — a new company name, a move from a .com to a country domain, the merger of two sites — is the only one of the three migrations for which Google provides a dedicated tool. Search Console has a Change of Address feature; according to the documentation, it is used when moving from one domain or subdomain to another, not when switching to HTTPS, changing between www and non-www, or moving pages within the same domain.

Three rules from Google's documentation decide the outcome:

• Every old address redirected to its counterpart, not to the home page of the new domain. Redirecting everything to the home page tells the search engine that the subpages no longer exist.
• Permanent server-side redirects — 301 or 308.
• Keep them "for as long as possible, generally at least 1 year". So the old domain has to be paid for at least a year after the change — a cost worth putting into the moving budget before someone decides that "we are not renewing the old one".

301 redirect — the map of old addresses

A 301 redirect is the server's answer "this address has moved permanently, over there". It is the heart of every migration in which addresses change, and the most common place where a migration breaks.

Google distinguishes two groups. Permanent redirects — 301 and 308 — are treated by Google as a signal that the target address should be the right, canonical one. With temporary ones — 302, 303, 307 — it follows the redirect but does not pass that signal to the target. A 302 redirect set by mistake during a migration is therefore a redirect that works for people and does not work for the search engine. Google treats an instant meta refresh in the page code as permanent and a delayed one as temporary. A JavaScript redirect only when nothing else is possible, because Google may not execute it.

A redirect map is a spreadsheet with two columns: old address, new address. The list of old addresses is best assembled from three sources, because each shows something different: the current sitemap, the pages report in Search Console and the list of addresses that external links point to. Every row has a target — even if a page disappears, the redirect goes to the closest page on the same topic, not to the home page.

Where a 301 redirect is set. On Apache servers it is done in the .htaccess file in the site's directory — one line per address, for example Redirect 301 /old-address/ https://www.example.com/new-address/. For dozens of addresses sharing a pattern, rules with regular expressions are used, but every such rule carries the risk of redirecting more than intended — so after adding one, you also check the addresses that were meant to stay untouched. Nginx servers do not read .htaccess at all; there, redirects live in the server configuration, usually on the hosting side. In WordPress, plugins handle it. In systems like ours, the rules are part of the code and go through the same review as any other change. Wherever it is set, one rule applies: the redirect should be answered by the server before the page starts — not by a script on the page.

Two things to check after deployment:

• Chains. If address A redirects to B, and B — from a previous migration — to C, every further change adds a link. Old rules have to be repointed so that they lead straight to the target.
• Whether the redirect works in production at all. It sounds obvious, but we have fresh proof that it is not. Our site runs 318 redirect rules. On 9 September one of them was written, approved and deployed — and the old address still answered 200 with the old content, because the rule went into the source code but not into the file the server actually reads. Nothing signalled it. The only test that caught it was checking the old address's response after deployment.

That test is one command or one online tool: for every old address on the map — does it answer 301 or 308, and does it end, after the redirect, on a page answering 200. For a few dozen addresses it takes a quarter of an hour. After a migration where "everything works", that quarter of an hour is the only proof.

WordPress migration — the address lives in the database

WordPress has one property that changes how a migration is done when the domain changes: the site's address is stored in the database, and in many places — in settings, in content, in theme and widget configuration. Moving the files and the database to a new server under the same domain does not touch this. Changing the domain touches everything.

The intuitive solution is to search the whole database for the old address and replace it with the new one. The WordPress documentation warns against exactly that: such a replacement "can cause issues with data serialization", because some themes and widgets store values together with their length. The new address has a different number of characters from the old one, the stored length no longer matches, and settings silently disappear. To change the address in a WordPress database, you use tools that understand this format — not a plain "find and replace".

The second rule from the same documentation is put even more strongly: the GUID column in the posts table is "never, ever" to be changed. It is the post's identifier, not its address — change it and RSS feed readers will show every post again as new.

The first week after a migration

For the first week after a migration, what you check is not whether the site works, but whether the things you cannot see on the home page work:

• Forms — whether messages arrive. A new server often sends email differently from the old one.
• Email on the domain — sending and receiving, if it was moved.
• Payments and customer accounts — one real transaction instead of an assumption.
• Search Console — the pages report and the list of 404 errors. Every new 404 is an address that fell out of the redirect map; how to read and fix it is covered under 404 errors.
• Uptime monitoring — pointed at the new server, not the old one; separately on what it should check.

If the site's speed changed after the migration, compare data from the same source. A lab test score and data from real users measure different things, and the latter are collected over 28 days — we explain this under Core Web Vitals.

What this article deliberately leaves out

• Shop migration — moving a shop between platforms has its own risks (products, variants, customer accounts, order history); there is also a checklist for it.
• The decision whether to rebuild the site — that is redesign or optimisation.
• Choosing new hosting — how to choose hosting, and what it costs together with a domain — hosting and domain costs.
• Who has access to the domain and server — website maintenance services, with a list of access rights that should belong to the company.

The shortest summary: name which of the three migrations you are doing, and separate them in time if they come together. When changing hosting, watch the TTL and the old server. When changing addresses — the redirect map and checking that it works. And then give Google weeks, not days: our own moved address was still in the index five days after the redirect, and that was not a failure, just the crawler's calendar.