We began rebuilding our website on September 5, 2026, and it’s now live. A relaunch is more than a new design, because addresses change and search engines have to find the new pages. Visitors shouldn’t end up on error pages along the way. This article describes the steps we followed, and at the end there is a checklist for your project.
Set the goals
Before the first draft, we decided what stays and what changes. We kept the logo and colors. We wanted an ASCII look and an English version, and we wanted the website to be easier to find in search engines.
Write such goals down before anyone designs or programs. Every later decision can be measured against them, and you can recognize requests that only come up during the project as additions to the scope.
Take stock
The project started with an inventory. We collected all projects and facts that were to appear on the website. From then on, every statement about projects and clients had to rest on this collection.
The list of existing addresses is just as important. Our old website had only two public pages, the homepage and the legal notice. Both addresses still work. For a larger website, you collect the addresses from the sitemap and from Google Search Console. Also note forms, integrations and files that other websites link to.
Plan the structure and addresses
The new website has a German and an English address for every page. All addresses are defined in a single place in the code. Canonical URLs and language alternates are derived from it instead of being maintained by hand on every page.
Settle the new structure before content moves, because the redirects depend on it. Short addresses in the language of the page are easier for visitors to read.
Set up redirects
Every old address needs a destination. If an address changes, a permanent redirect with status 301 leads to the matching new page. Google recommends keeping such redirects for as long as possible, generally at least one year. According to the same guide, you shouldn’t point many old addresses at the homepage across the board. You avoid chains of several redirects by pointing every redirect straight at the final destination.
At Ruxiom, the former English domain permanently redirects to the English pages, and the path is preserved. German paths, however, have no English twin with the same name. For these, such as the legal notice, separate rules therefore have to come before the general redirect. Addresses with a leading www lead to the domain without that prefix.
Use a staging environment
Before anything goes public, every change runs on a staging environment under its own address. This environment blocks search engines through robots.txt, and every page also carries the noindex directive. The canonical URLs still point to the future live domain, so staging and live operation differ only in the environment.
On staging we read every page ourselves and submit the contact form in both languages. Only when both messages arrive is the form done. For your relaunch, the person responsible for the content should also read and approve the pages on staging.
Tests before the switch
Every change goes through automated tests before it is released. Some of them examine the finished, built website. These tests make sure that every page exists in both languages and points to its counterpart. Canonical URLs, the sitemap and robots.txt are covered too. After every release, a short test requests the website that was just released and fails if it doesn’t respond as expected.
Without automated tests, I’d at least check every redirect on your list one by one before the switch.
Switch over
We planned the move so that the old website stayed reachable until the last moment. The new website runs on Cloudflare® Workers and takes over the addresses through routes that take precedence over the old installation. The old installation stays in place unchanged for at least a week after the switch.
Before the switch, it’s worth looking at settings at your host that change files such as robots.txt. At Cloudflare, settings for AI crawlers can rewrite robots.txt before it reaches the visitor.
After the switch, we check the most important addresses and redirects on the live domain again. Then we submit the sitemap in Google Search Console and in Bing Webmaster Tools. Preview cards on social networks often still show the old page afterward, so we have them reloaded on the services that offer this.
Define the rollback plan
The rollback plan is set before the switch. If only one release is faulty, we roll back to the previous one. If the new environment is fundamentally broken, we remove its route, and the old website responds again within seconds. That’s why we only delete the old installation once the new one has run without errors for a week.
The same principle applies when you change hosts. Cancel the old contract only once the new website has run without errors for a while.
Checklist for your relaunch
- Write down your goals and what should stay.
- Collect all existing addresses from the sitemap and Search Console.
- Set a destination for every old address and set up redirects with status 301.
- List the forms and integrations that have to move along.
- Set up a staging environment with noindex and read every page there.
- Submit every form in every language and check that it is delivered.
- Define the rollback plan and leave the old website unchanged until the new one has run without errors for at least a week.
- After the switch, check the redirects, robots.txt and sitemap on the live domain.
- Submit the new sitemap in Search Console.
The article The new Ruxiom describes what our new website looks like and what changed. If your website moves to a new host with the relaunch, you’ll find the process on the migration to Cloudflare page.
The websites page shows how we build a new site. Tell us your current web address and what needs to change, and we’ll plan the relaunch with you.