Typical errors in a website relaunch and how to avoid them

The classic mistake. The importance of correct redirects when the URL structure changes should be common knowledge. Even so, it is surprising how often they are neglected. In a staging check in 2026, 92 old URLs had no destination. After go-live these pages would have returned a 404 error.

If the URL structure does not change, no redirects are needed. If it does, we recommend these steps:

1. Record all old URLs: combine the sources: a crawl of the old website, pages from Google Search Console, web analytics, ranking URLs from SISTRIX or a comparable tool and all URLs with backlinks. Remove the duplicates.
2. Assess the URLs: traffic, rankings and links show which pages must survive the relaunch. If a strong page has no equivalent in the new structure, its content should be carried over.
3. Rules before individual mapping: check which redirects can be solved with rules. If /our-services/ becomes /services/ after the relaunch, one line with a regular expression is enough. Rules are generally preferable to a redirect matrix because they avoid errors and keep the configuration lean.
4. A matrix for the rest: for all URLs not covered by a rule, create a 1:1 mapping table.
5. Redirect permanently and directly: in its guide to site moves, Google recommends permanent redirects with status code 301 or 308. Googlebot does follow up to ten redirects in a row, but Google advises redirecting straight to the final destination and using no more than three hops.
6. Keep them long enough: according to Google, redirects should stay active for as long as possible, generally at least one year.

Quality control matters! Test every old URL before and after go-live. A good tool for bulk checks is our HTTP status code checker.

Not all redirects are equal. A common misconception is that a 301 redirect of all subpages to the homepage is enough. There are three reasons not to:

Users: for a certain period the old pages are still in the index and appear for certain queries. Anyone who lands on the homepage instead of the page they were looking for rarely bothers to search again, and two clicks later they are on a competitor’s site.

Links: depending on how old and successful the old website was, it has been linked to more or less often, frequently to subpages. According to Google, a permanent redirect passes these signals on without any loss of PageRank. But if all links point to the homepage after the relaunch instead of the matching subpage, they lose their topical value.

Google itself: Google explicitly warns against redirecting many old URLs to a single, irrelevant destination such as the homepage. This confuses users and may be treated as a soft 404. Pages that really no longer exist may return a 404 or 410 status code.

Besides faulty redirects, changed content and a new information architecture are the most common reasons for losses in visibility. In a relaunch, texts are often unintentionally shortened, merged or moved into PDFs. Bear in mind that search engines value relevant, detailed, high-quality content. Invest your time in a good structure rather than in cutting text. Jump links and a table of contents help long pages more than a red pen.

Check these points as well:

• Internal links: menus, body text and teasers point to the new addresses and do not run through redirects.
• Canonical: every new page references itself with a canonical. A canonical pointing to a redirected, blocked or non-indexable URL sends contradictory signals.
• Language versions: hreflang annotations must be reciprocal. If two language versions do not point to each other, Google ignores the annotation.
• Page titles and descriptions: they are often lost when the system changes, or replaced with placeholders.
• Trust signals: for health, financial and legal topics, known as YMYL topics, author details, expert profiles and sources matter particularly. They have to be migrated completely.

The same is true for AI search. If details about services, prices or locations are missing after the relaunch, ChatGPT, Gemini and other systems answer imprecisely or wrongly.

A test environment should not appear in search results. The safest protection is a password. A block in robots.txt only prevents crawling. The address can still end up in the index without a description.

Things become critical on the day of go-live. Google lists it among its own common mistakes: noindex or robots.txt blocks that were only meant for development are not removed after the move. We saw exactly this at a go-live in 2026. The setting that discourages search engines and the robots.txt of the test environment had moved over and were corrected straight afterwards.

So check immediately after go-live:

• Does the homepage return status code 200, and can it be indexed?
• Does robots.txt allow crawling, and does it respond without errors? If it returns a server error, Google will, according to its documentation, initially stop crawling the website for twelve hours.
• Does the XML sitemap contain only indexable addresses of the new website?
• Do canonicals and internal links point to the live domain and no longer to the test environment?

Hosting and protection systems belong on the checklist too. On one website, an IP blocklist at the hosting provider locked out Googlebot. Visibility fell by around two thirds within a week and was back at its previous level two weeks after the correction.

Modern websites often build their content in the browser with JavaScript. Google can process this, but in two steps: first the delivered HTML is read, and rendering follows later in a queue. Google itself writes that server-side rendering or pre-rendering is still a great idea because it makes the website faster and not all bots can run JavaScript.

For AI systems the point matters even more. A study by Vercel and MERJ from December 2024 found that the crawlers from OpenAI, Anthropic, Meta and Perplexity do not execute JavaScript; only Google’s Gemini and AppleBot rendered it. Content that is not in the delivered HTML does not reach these crawlers.

Typical errors in JavaScript projects:

• Content is only loaded via an API and is missing from the HTML source.
• Page title, canonical and meta information are only set in the browser.
• Navigation works only with JavaScript and does not produce real links.

The solution is server-side rendering or pre-rendering for all content that should be found. That belongs in the architecture decision at the start of the project. With one online shop in 2026, we were able to prevent the new website from launching without server-side rendering shortly before go-live.

During the relaunch, also check whether firewall, bot protection and robots.txt let the AI crawlers you want through. OpenAI, for example, recommends allowing OAI-SearchBot if the website is to appear in ChatGPT search answers. A log file analysis shows whether the crawlers actually arrive.

To make a website faster, developers use many techniques: server-side compression, asynchronous loading and minification of JavaScript and CSS. With the latter there is a risk that an error affects the layout and the website no longer adapts to the device. Responsive display is often checked only with emulators on a desktop. However, desktop browsers are more forgiving of errors than their mobile counterparts. So test the new website on real mobile devices as well before the relaunch.

Loading time is measured against Google’s Core Web Vitals. Good values are a Largest Contentful Paint of no more than 2.5 seconds, an Interaction to Next Paint of no more than 200 milliseconds and a Cumulative Layout Shift of no more than 0.1. Interaction to Next Paint replaced First Input Delay in March 2024. Older checklists still name the old metric.

Two points are often forgotten:

• Images and downloads: image and PDF addresses change too. Google recommends including them in the move like all other content. Images are crawled less often, so changes take longer to show in image search.
• Structured data: markup for the organisation, products and articles is often lost when the system changes and has to be rebuilt in the new template. But do not expect every earlier search result format: Google has not shown the FAQ rich result since 7 May 2026.

Even without your help, search engines will notice the changes at some point. The old pages disappear and the new ones appear in the index. You can speed this process up:

• Set up Search Console: make sure the website is registered in Google Search Console and Bing Webmaster Tools. With URL Inspection you can see how Google fetches and renders a page, and request indexing for important pages.
• Submit the new sitemap: submit the current XML sitemap and reference it in robots.txt.
• Add a sitemap of the old URLs: temporarily submit a sitemap with all old, redirected addresses as well. Google then fetches them specifically, follows the redirects and updates the index faster. Google describes this approach itself: the number of indexed pages from the old sitemap falls to zero over time while that of the new one rises. Warnings about the redirects are normal. Once the old sitemap has run empty, it can be removed again.
• Change of Address only for a domain change: if the domain or subdomain changes, tell Google using the Change of Address tool in the Search Console settings. It is not intended for new paths within the same domain.
• Soft launch: take the website live without advertising pressure at first and watch the crawling. In the first 14 days we check traffic, index coverage, error pages and loading times daily.

Allow for some patience. According to Google, it takes a few weeks for most pages of a small or medium-sized website to move, and longer for large ones. Temporary ranking fluctuations are normal during this time.

Besides a complete list of the old URLs, backups are essential. Nothing is more reassuring than being able to roll back quickly if there are problems. So do not just back up all data; run through the restore once as a test before the relaunch.

Tip: if you decide on a rollback, decide quickly. Search engines notice a new website fast and index it. The longer you hesitate, the more new pages are in the index and the greater the effort to clean this up again.

Not every relaunch goes smoothly. Time pressure often plays a part, or a detail has been overlooked. The basic rule: do not panic! Slight losses in visibility in the first weeks are not unusual. If you have followed the points in this article, visibility generally recovers. If the losses are above 30 per cent, however, there is a problem that should be found quickly.

An analysis in Search Engine Journal from January 2025 shows how costly errors can be. It looks at 892 domain migrations based on estimated tool data. On average it took 523 days for the new domain to reach the organic traffic of the old one again. 17 per cent had not regained it even after 1,000 days. A domain change is the hardest case, so the figures do not apply to every relaunch. But they show why preparation pays off. Our rule of thumb: an SEO requirement that is only implemented after go-live costs around three times as much.

If you want to play it safe from the outset, we support your project with our SEO relaunch support: from the requirements catalogue and the redirect plan to monitoring after go-live.