Website Relaunch Guide

A website relaunch rarely loses its rankings on launch day. They are lost weeks beforehand at the kick-off meeting, when everyone is talking about colours, visuals and the new CMS, and nobody asks which old pages are actually generating the traffic.

Google describes the situation in its documentation on website migrations. Anyone changing URLs must expect temporary fluctuations in rankings. For medium-sized websites, it can take several weeks or longer for Google to gradually start displaying the new URLs. This is the norm. It’s the permanent loss that proves costly, and this arises from gaps that can be identified in advance: missing redirects, deleted pages that used to generate traffic, a forgotten ‘noindex’ tag.

This guide walks you through a relaunch in the order in which you make your decisions. First, the type of project; then the six phases, the baseline assessment, the SEO checklist for go-live, the first 30 days, AI visibility and the costs. Finally, we outline the seven mistakes we consider to be the most costly.

Relaunch, Redesign or Replatforming: What do you really need?

With a redesign, the website gets a new look, whilst URLs and text remain largely unchanged. With replatforming, the underlying infrastructure – such as the CMS, shop software or hosting. A website relaunch rebuilds the page structure, content, design and often the system itself as part of a single project. With every level that changes, the number of signals that Google has to re-index increases.

‘Relaunch’ literally means a fresh start. In a web project, this means the website goes live with a new structure and, in most cases, new URLs. This is precisely what makes a relaunch challenging from an SEO perspective. Every changed address is a point where rankings, backlinks and bookmarks can be lost if there is no redirect in place to catch them.

If a domain change is involved, adding the address change in Search Console should be on the list. Google provides this tool for changing domains or subdomains. It is not necessary for switching from HTTP to HTTPS.

Our recommendation: Only change what needs to be changed. If the CMS is on its last legs but the structure is sound, a replatforming with stable URLs is the lower-risk option than a major overhaul. If the structure and content no longer match your offering, a relaunch is unavoidable. In that case, SEO migration should be included in the first week of the project.

The same logic applies to online shops, albeit with more URLs. The Bike-Discount: To switch from Shopware 5 to Shopware 6, a completely new shop was created which continues to use all existing interfaces to payment methods, stock and ERP. According to the project report, it now handles around 6,000 orders per day.

Anyone facing this step themselves can find the roadmap on the page for Shopware migration. If, on the other hand, the company website is being turned into a shop for the first time, this is more like building something from scratch, complete with product range, payment methods and processes. In that case, having an online shop created is the better way to start.

The six phases of a website relaunch

A website relaunch consists of six phases: assessment, concept and structure, UX and design, development and migration, go-live and monitoring. As a guide, on our page on website relaunches we estimate four to eight weeks for a redesign, two to four months for the relaunch of a corporate website, and three to six months for projects involving interfaces or multiple languages.

This is followed by a 30-day monitoring period. How the time is allocated across the individual phases depends heavily on the project. Two factors have the greatest impact on the schedule: when the text and images are ready, and how many rounds of feedback each approval requires.

The most important line is right at the top. SEO begins in Phase 1, not two weeks before go-live. And no phase begins until the results of the previous one have been approved.

If you’re outsourcing the project, set out the objectives, page types, languages and interfaces in advance in a specification document. This makes it easier to compare quotes. And it prevents the SEO migration from ending up as an addendum in the change request.

Before the relaunch: the inventory

Before the relaunch, you need a complete URL inventory and verified baseline data. To do this, you need to cross-reference four sources: a website crawl, the XML sitemap, performance data from Google Search Console and the backlinks. Each source shows only a snapshot. Only when combined do they provide the list of pages that carry rankings, links and search queries.

The scale of the gaps is illustrated by the relaunch of Xtreme Events from WordPress to Shopware 6. In this case, the crawl, XML sitemap and Search Console each represented only a fraction of the indexed pages. It was only by cross-referencing these sources that the actual total of 1,125 legacy URLs was revealed, including pages with significant search volume that did not appear in any other source. In the end, there were 934 redirects.

Crawl and Sitemap

A crawler such as Screaming Frog or Sitebulb captures all internally linked URLs along with their status code, title, canonical tag and indexing status. The XML sitemap supplements pages that are scarcely linked to internally. What’s interesting is what both overlook: pages that are now only accessible via old backlinks or Google Search. It is precisely these that appear in the next two sources.

Search Console and Web Analytics: the Baseline

Before the relaunch, export the performance data from the Google Search Console for each URL and each search query: Clicks, impressions, position. Google only retains this data for the last 16 months. Use web analytics to identify which pages generate enquiries or revenue. This baseline will later be your only evidence of whether the relaunch has cost anything.

Backlinks and content audit

Pages with external backlinks definitely need a redirect, even if they themselves receive hardly any traffic. The link data is provided by the Search Console’s Links report; for more detailed information, use an SEO tool such as Ahrefs, Semrush or Sistrix.

This list forms the starting point for the content audit. For each URL, a decision is made as to whether it should remain, be merged with another, or be removed. At Xtreme Events, a particular focus was placed on pairs of pages competing for the same search terms. Each pair was assessed individually using ranking data from Semrush and Search Console. If one page ranked significantly higher, a redirect was set up to consolidate the signals onto it.

The SEO checklist for go-live

The SEO checklist for go-live includes redirects according to the redirect map, canonical tags pointing to the new URLs, a new XML sitemap in Search Console, hreflang for all language versions, no blocks from the test environment, clean internal links, stable Core Web Vitals and implemented structured data. Check each point immediately after the switch.

The thresholds for Core Web Vitals are Google’s benchmarks for a good user experience, measured at the 75th percentile of page views (web.dev). A relaunch is the moment when these metrics are most likely to deteriorate: new fonts, larger images, a new cookie banner, additional tracking scripts. Therefore, measure the same page types before and after going live.

301 or 308: Which redirect to use for a relaunch?

For Google, both are equivalent. According to the Google documentation on redirects, 301 and 308 are permanent redirects that Google uses as a signal for the canonical URL. 302, 303 and 307 are considered temporary and do not carry this signal. Therefore, only 301 or 308 redirects are suitable for a relaunch.

The difference lies in the HTTP standard. With a 301, browsers are permitted, according to RFC 9110, browsers may, for historical reasons, repeat a POST request as a GET; a 308, however, retains the method. This is irrelevant for page URLs, but does matter for form or API endpoints that are being moved. The 308 status code was only introduced in 2014. RFC 9110 states that not every client may recognise it.

Next.js, for example, sets a 308 by default. This is not a problem for Google.

In short: for pages, the 301 is the robust standard; a 308 is equivalent for Google. The destination is more important than the status code. If you redirect a large number of old URLs en masse to the homepage, Google may interpret this as a ‘soft 404’ according to its relocation documentation. The signals from the old pages will then not reach anywhere.

You should also avoid chains. According to its documentation on HTTP status codes, Google follows up to ten redirects in a row; however, each additional step still costs in terms of crawling and loading time. And leave the redirects in place: Google recommends keeping them for as long as possible, usually at least one year.

Our wiki explains what a 301 redirect means in technical terms. You can find out how to set up the redirect map for a shop with thousands of product and category URLs in the article Shop Migration without SEO Loss.

The noindex trap from the test environment

A test environment should not be included in the index, so it is often hidden using ‘noindex’ or ‘disallow’ in the robots.txt file. Both can easily carry over when the site goes live. A ‘noindex’ tag on the new website gradually removes the pages from the index, whilst a blocked robots.txt file prevents Google from crawling them. Google explicitly mentions removing such restrictions as a step in the migration process.

Furthermore, the two restrictions are incompatible. According to Google, ‘noindex’ only works if the page is not blocked by robots.txt. Otherwise, the crawler will never see the instruction. A blocked page may still appear in search results, for example if other pages link to it. The neat solution for the test environment is therefore password protection. That way, nothing is accidentally carried over when the site goes live.

hreflang and language versions

If your website has an English version, the potential for errors doubles. Google requires that each language version references itself and all other versions. If two pages do not link to one another, Google ignores the information (Google documentation on localised versions). After the relaunch, the hreflang specifications in all languages must point to the new URLs. With ‘x-default’, you specify which page users will see if their language is not covered.

A pitfall that is easily overlooked: the English version goes live later and is set to ‘noindex’ in the meantime. In this case, the German pages use hreflang to link to pages that must not be included in the index. At Xtreme Events, we have ensured that the canonicaland hreflang tags in all three languages.

After go-live: the first 30 days

In the first 30 days after going live, monitor indexing in Search Console, 404 errors and redirects, clicks and rankings of the most important pages compared to the baseline, and crawler activity. Fluctuations in the first few weeks are normal. If a key page experiences a sustained drop in performance, this warrants troubleshooting specifically for that URL.

Day 1

Visit the top URLs from the baseline one by one and check the status code, redirect destination, canonical tag and meta-robots tag. Submit the new XML sitemap in Search Console and submit the most important pages via the URL inspection tool for indexing via the URL Inspection tool. To monitor progress, Google recommends also submitting the previously saved sitemap containing the old URLs: the number of indexed pages in that sitemap will gradually drop to zero over time, whilst the new sitemap’s figures increase. Also check tracking and consent banners; otherwise, you’ll be missing data from the very first few days.

Week 1

The first 404 errors are now appearing in the page indexing report. Each of these is either a missing redirect or a page that has been deliberately deleted, and you should know which of the two it is. The server logs show which old URLs Googlebot is still accessing.

Also watch out for server errors. According to Google, 5xxerrors and status code 429 slow down crawling, and this particularly affects a website that has just been moved. You can find out more in the wiki entry on the crawl budget.

Weeks 2 to 4

Now you’re comparing on a per-URL basis, not per website. A slight drop in the overall figure may mean that everything is fluctuating a little. However, it may also mean that the pages with the most requests have dropped off and the rest have improved. Check pages that are significantly below their baseline by the end of the monitoring period individually: redirects, content, internal links, canonical tags.

The migration isn’t always fully complete after 30 days. Google states that for medium-sized websites, it can take several weeks or more for the new URLs to be recognised. For large online shops, it is therefore worth allowing for a longer observation period.

AI visibility after the relaunch

For ChatGPT, Perplexity and Google’s AI responses, the same fundamentals apply as for traditional search: the page must be accessible, indexable and, for most AI crawlers, readable directly from the delivered HTML. A relaunch can inadvertently break exactly that, for example through a JavaScript application without server-side rendering or a new robots.txt file that blocks AI crawlers. Check both before going live.

For the AI Overviews and AI Mode, there are, according to Google, no additional requirements. A page must be indexed and permitted to appear in search results with a snippet. There is expressly no need for new machine-readable files, AI text files or special markup. If you work through the checklist above thoroughly, you’ll have done the bulk of the work for Google.

For other AI crawlers, JavaScript is the bigger hurdle. An analysis by Vercel in December 2024 found that, apart from Gemini – which uses Googlebot’s infrastructure – and AppleBot, none of the major AI crawlers executed JavaScript, including GPTBot, ClaudeBot and PerplexityBot. This is a snapshot, and the crawlers are evolving rapidly.

Google also states that server-side or pre-rendering is still a good idea, as not all bots can execute JavaScript. If your relaunch is based on a single-page application, server-side rendering should therefore be included in the requirements before the front-end is finalised.

The second item is the robots.txt file. OpenAI separates the crawlers for search and training: OAI-SearchBot includes pages in ChatGPT’s search results, whilst GPTBot collects content for training the models. You can allow one and block the other. On Google, the ‘Google-Extended’ token controls usage for Gemini and, according to Google, it influences neither inclusion in Google Search nor ranking.

It is important that someone makes this decision consciously. Otherwise, a robots.txt file copied from the test environment will make it for you. Also check the botprotection settings with your new host or CDN: Google explicitly mentions this infrastructure alongside the robots.txt file, and a blocking rule there will keep crawlers out, even if the robots.txt file allows them in.

And what about llms.txt? The file is a proposal by Jeremy Howard from September 2024, now in version 2 (as at 10 August 2026), and is not an adopted standard. According to its own statements, Google does not require AI text files for its own AI functions. However, an llms.txt file costs very little and provides language models with an overview of the website. At Xtreme Events, we have created one editorially in three languages and specifically granted access to the crawlers from OpenAI, Anthropic, Perplexity and Google. Our llms.txt check verifies what should be included in an llms.txt: llms.txt check.

In terms of content, what counts is the same as in traditional search: pages that directly answer genuine questions. This includes a short answer under each heading, FAQ sections with comprehensive answers, and structured data that matches the visible text. Google explicitly cites this last point as a best practice for its AI features.

The AI Visibility Check shows how visible your website is in AI answers today. The AI Crawler Check checks whether the crawlers can access your site at all. The strategic aspect of this is known as GEO, Generative Engine Optimisation.

What factors determine the cost of a website relaunch?

The costs of a website relaunch depend on five factors: the number of pages and the scope of the content migration, the design, the technical infrastructure, the interfaces and multilingual support. A reliable figure can only be provided once an initial assessment has been carried out. You can find our price ranges by project type, from redesign to relaunch with interfaces, on the website relaunch page.

There’s one item you should plan for early on: Accessibility. The Accessibility Enhancement Act has been in force since 28 June 2025, applying, amongst other things, to e-commerce services provided to consumers. It’s best to clarify whether your offering falls under this before the relaunch. The BFSG Check provides an initial assessment.

The SEO migration doesn’t necessarily have to be handled by the team responsible for design and coding. If another agency or your own IT department is developing the website, an SEO agency can take responsibility for the aspects that affect rankings, from the initial assessment right through to monitoring after the switch.

Also check for funding opportunities before you sign. The KfW information sheet on the ERP digitalisation grant-backed loan (511/512, as at 23 April 2026) cites the “fundamental redesign of a company website or app with new functionalities” as an example of an eligible project. According to the information sheet, a prerequisite for this funding tier is that digital systems are interconnected. You should submit your application to a financing partner, such as your main bank, before the project begins.

If your project goes beyond a company website – for example, towards an online shop, web app or customer portal – the project calculator will give you an initial estimate of the budget, timeframe and effort required.

The seven most expensive relaunch mistakes

The most expensive relaunch mistakes include a missing URL inventory, deleted pages with traffic, bulk redirects to the homepage, temporary redirects left in place permanently, restrictions from the test environment carried over, content that only appears in the browser, and redirects that disappear too soon. Here they are listed for the project kick-off, in the order in which they occur.

1. There is no URL inventory. Without cross-checking the crawl data, sitemap, Search Console and backlinks, the redirect map is missing precisely those pages that nobody had on their radar.
2. Pages with traffic are removed. What ‘no longer fits’ the new concept may have been generating enquiries for years. Read the baseline first, then remove.
3. Old URLs end up grouped together on the homepage. Google may interpret this as a soft 404, and the signals from the old pages will be lost.
4. Temporary redirects remain in place permanently. A 302 or 307 is not a signal to Google that the new URL is the canonical one. Check the status code that the server actually returns.
5. Restrictions from the test environment carry over to the live site. A single ‘noindex’ in the page template is enough to remove all pages using that template from the index.
6. Content is only generated in the browser. Many AI crawlers cannot see content that is loaded solely via JavaScript.
7. Redirects disappear after a few months, when the server is migrated or when the configuration is tidied up. Google recommends at least one year; for URLs with backlinks, there is no reason not to use a permanent redirect.

Frequently asked questions about SEO during a website relaunch

What does a website relaunch mean?

‘Relaunch’ literally means a fresh start. It refers to a project in which a website goes live with a new page structure, revised content, a new design and, often, on a new system, usually under new URLs. If only the appearance changes, it is a redesign.

How long should I keep redirects after a relaunch?

Google recommends keeping redirects in place for as long as possible, usually for at least a year. There is no reason not to keep old URLs with external backlinks permanently. A redirect rule costs next to nothing, whereas a lost backlink certainly does.

Do I need to redirect every old URL?

No. You must redirect any URL that has traffic, rankings or backlinks to the new page with matching content. URLs without any of these – such as old filter or test pages – may return a 404. It is a mistake to take the easy way out by redirecting them all to the homepage across the board.

When will the rankings stabilise after the relaunch?

Google states that for medium-sized websites, it takes a few weeks or more for the new URLs to gradually appear in search results, and expects fluctuations during this time. If, following monitoring, an important page is still significantly below its baseline, check the redirect, content and canonical tag for that specific page.

Can I combine a relaunch with a domain change?

Technically, yes. For the domain change, you’ll also need to use the address change tool in Search Console. The downside is that if rankings drop, you won’t know whether it’s due to the domain, the structure or the content. If the domain change isn’t essential, carry out the two steps separately.

Do I need an llms.txt after the relaunch?

It isn’t mandatory. According to Google itself, it does not require AI text files for AI Overviews and AI Mode. More important are server-side rendering, a robots.txt file that allows the desired crawlers, and content that that answer the questions directly. An llms.txt is a useful addition once this foundation is in place.

Conclusion: The relaunch is decided before the first draft

A website relaunch without permanent loss of ranking is a craft that follows a set sequence. First, decide whether it will be a redesign, a replatforming or a relaunch. Then build up the URL inventory before anyone deletes a page. Check the redirect map in the test environment, remove the blocks when going live, and monitor the situation closely for 30 days. If you take server-side rendering and crawler access into account, you’ll also be prepared for AI-powered searches.

Therefore, plan the SEO migration as a separate work stream with its own budget and clear lines of responsibility, starting from the very first week of the project. Planning a relaunch? We’ll safeguard your rankings with a redirect map and 30-day monitoring. You can find out how we do this on the page about website relaunch.