Switch-over day — and the four weeks after it

The moment the new website goes live is the only one in the whole project that cannot be repeated. Everything before it can be changed. From now on customers see what is there.

This article goes through what has to be prepared beforehand, what happens on the day itself and what gets checked in the weeks after.

When to switch over

Not on a Friday. Not before a public holiday. Not before a holiday.

The reason is banal: if something does not work, someone is needed to fix it. A website switched over on Friday afternoon that has a problem on Saturday is broken until Monday — and with it the form through which enquiries come in.

The best time is Tuesday or Wednesday morning. Enough time on the same day, enough buffer days in the week.

And if there is a seasonal pattern: not in high season. A trade business does not switch over in April, a tax adviser not in May.

What has to be ready beforehand

The way back. The most important thing. It has to be possible to restore the old website within a short time.

In practice that means: a complete, checked backup of the old state, and a clear procedure for restoring it. Not “it is somewhere at the host”, but a file whose location someone knows and which they know how to restore.

The way back is almost never needed. It is the reason you can stay calm when something is not right.

The certificate for the live address. A certificate that is only valid for the test address produces a warning page at the switch-over. That has to be sorted out beforehand.

The DNS changes, if the provider changes. Important here: DNS changes take time until they have arrived everywhere — sometimes hours. During that time some visitors see the old site, others the new one. That is normal and can be shortened by lowering the time-to-live of the DNS records a few days before.

The caching and delivery configuration.

And the redirects, set up and tested.

(Own checklist website-relaunch)

The check right after the switch-over

This list is worked through on the same day, not the next:

1. The staging blocker is gone. The most important point of the whole list. If “discourage search engines” was switched on in the staging environment and this setting moved along, the new website is invisible to Google.

That is the most expensive mistake in a relaunch. It is often only noticed after weeks — namely when traffic collapses and someone looks for the cause.

Check: open yourdomain.com/robots.txt, and search the source for noindex.

2. Click through all pages. Desktop and phone. Not as a sample — completely, if there are fewer than fifty.

3. Test the forms. Submit, check the confirmation, and look in the inbox to see whether the mail arrived. That is the point that breaks most often in a migration: the mail sending depended on a configuration of the old server.

And every form, not only the contact form.

4. Test redirects as a sample. Open the most important old addresses.

5. Encryption on all pages, without mixed content.

6. Submit the new sitemap in Search Console.

7. Request indexing of the most important pages.

8. Check the analytics: is data being recorded? In a rebuild the tracking code likes to get lost.

9. Measure the loading time and record the value. As a starting point for later.

And one point that is on no technical list: tell your customers. A short note on the home page or in the newsletter — “our website is new, if something does not work, please let us know” — creates goodwill and brings in the best bug reports.

(Own checklist website-relaunch)

The first two weeks

Now the part begins that many projects leave out — and in which it is decided whether the relaunch becomes a success.

Daily: check Search Console. New error pages, fetch problems, indexing messages. Every error address that shows up is a forgotten redirect and is added.

That is the most productive quarter of an hour of the whole project. The error messages of the first weeks are the most complete list of what was missing from the redirect plan — more complete than any advance check, because they are based on actual requests.

Watch the visitor numbers in comparison. A drop in the first days is normal — indexing takes time. A drop that lasts two weeks is not.

Check the form submissions. Are enquiries actually arriving? Compared with before, that is. A form can work technically and still bring fewer enquiries, because it is harder to find.

Collect customer feedback. The most useful source of errors there is. Customers use the website differently from the builder.

Check external services. Newsletter system, booking system, review display, appointment scheduling. Everything that accesses the website or is addressed from it. These connections regularly break in a migration, and nobody notices, because they are not visible on the home page.

(Own checklist website-relaunch)

After four weeks

The time for the honest assessment. Four weeks are chosen because loading-time data from real visits needs about 28 days to become meaningful.

Compare positions: old against new. This is where the inventory pays off — without it the comparison is not possible.

Check the indexing status. Are the new pages in? Are the old ones out?

Look at the loading-time values from real user data in Search Console.

Document the before-and-after comparison. Loading time, positions, visitor numbers, enquiries. That is the answer to the question “was it worth it” — and that question will certainly come.

Go through the redirects completely once more. Experience says something is still missing by then.

And close the project formally: a conversation with the client, clarify open points, and ask the question about ongoing support.

(Own checklist website-relaunch)

What is normal and what is not

Because the first weeks are unsettled, here is how to read them:

Normal:

• A drop in visitor numbers in the first one to two weeks.
• Individual pages that briefly disappear from the index and come back.
• Error page messages in Search Console — that is the mechanism working.
• Fluctuating positions.

Not normal, and then look immediately:

• Traffic that stays clearly below the old level for more than two weeks.
• The home page is not indexed.
• Form submissions stop completely.
• The message “Excluded by noindex tag” on important pages.
• A message in the security issues section.

And in most cases the cause is one of three: the staging blocker came along, the redirects are missing, or the mail sending does not work.

What to do

Beforehand:

1. Set the date — Tuesday or Wednesday, not before public holidays, not in high season.
2. Prepare the way back and check the backup.
3. Sort out certificate, DNS, caching, delivery.
4. Set up and test the redirects.

On the day itself:

5. Remove the staging blocker. First of all.
6. Click through everything, on mobile and desktop.
7. Test every form through to the mail arriving.
8. Check redirects as a sample.
9. Submit the sitemap, request indexing.
10. Check analytics and loading time.
11. Tell your customers.

Afterwards:

12. Two weeks of Search Console every day.
13. Add missing redirects.
14. Check external services.
15. After four weeks, take stock and document it.

What I tell clients about this: switch-over day is not the end of the project, but the start of the most important four weeks. Whoever does not look after it learns about problems only from a customer who calls — or not at all.

Sources

• Own checklist website-relaunch — securing the go-live with setting the date (not on a Friday, not before public holidays), the prepared way back for quickly restoring the old site, the planned DNS changes when changing provider, the certificate ready for the live address and the prepared delivery and caching configuration; the checklist right after the switch-over with clicking through all pages on desktop and mobile, testing the forms through to the mail arriving, checking the redirects as a sample, submitting the new sitemap, requesting indexing of important pages, checking the analytics, encryption without mixed content, removing the staging blocker from the robots.txt and measuring and documenting the loading time; the points for the first two weeks with daily checks of Search Console, comparing visitor numbers, identifying error pages and adding redirects, collecting customer feedback, checking form submissions and checking external services; and the points after four weeks with position comparison, indexing status, loading-time values from about 28 days of field data, a documented before-and-after comparison, checking the redirects again, closing the project with the client and the conversation about ongoing support.
• Own checklist projektablauf-relaunch — the division of the project into phases and where the go-live phase sits.
• Rheinwerk, Website-Konzeption und Relaunch, ch. 6.3 — the distinction between a switch-over in one go and a gradual switch-over, and the preconditions of each.
• Atlas, seo/technical-audit.md — auditing the noindex directives as a regular check, especially after a relaunch.
• Own audit practice — the recommendation of Tuesday or Wednesday morning and the seasonal consideration, lowering the DNS time-to-live a few days before the change, the advice to tell customers about the rebuild, the classification of what is normal in the first weeks and what is not, the three most common causes of conspicuous findings, and the observation that the error page messages of the first weeks provide the most complete list of forgotten redirects.