Website relaunch for SaaS companies: the practical guide

For SaaS companies, a website relaunch is one of the biggest marketing projects there is. It ties up budget, team time and attention for months. And it carries real risk: get it wrong and you lose rankings, leads and, ultimately, pipeline.

Most relaunches don't fail on launch day. They fail months earlier: on positioning that was never decided, on 80 feature pages nobody has time to rewrite, or on a URL structure that gets changed one week before go-live. That's why classic checklists start too late. They list what to check right before launch, when the decisions that matter were made long ago.

In this guide, we walk you through the full process of a SaaS relaunch in eight steps, from the first goal to optimization after go-live. It's based on relaunches for more than 120 software companies, on migrations from TYPO3, WordPress and other systems to Webflow, and on the mistakes we've seen along the way. You also get realistic costs, a detailed relaunch checklist and our page structure sheet as a template.

Key takeaways

• The relaunch type determines the risk. A pure platform migration is usually low-risk, a domain change is the opposite. Define the type before you plan.
• Foundation first. Pages that rank and convert well get migrated 1:1 first. Optimization comes afterwards, controlled and measurable.
• The most important decisions happen before the project starts: positioning, pricing, ownership and an approved page structure.
• Budget realistically: depending on scope, a SaaS relaunch starts at around €20,000 and takes between 6 weeks and 6 months.
• Launch is day one. The real work on rankings, conversions and AI visibility starts afterwards.

What is a website relaunch?

A website relaunch is the comprehensive rebuild of an existing website. Depending on the project, the technology, design, content, page structure or even the domain changes, often several at once.

Relaunch or redesign? The terms are used very inconsistently in practice. Here's how we draw the line: a redesign changes how the website looks. A relaunch is the umbrella term for rebuilding the site. It can include a redesign, but also technology, content and structure.

More important than the term is the question of what exactly changes. Risk, effort, cost and the scope of redirects all depend on it. That's why the first decision in every project is: which type of relaunch is this?

The four relaunch types

Platform migration. You switch systems, for example from TYPO3 or WordPress to Webflow, and keep your content and URLs. Because the content doesn't change, ranking losses are rare. You often even see an uplift, because older platforms tend to have gaps in technical SEO, such as missing schema markup. How big the effect is depends on how well the old platform was set up.

Design relaunch. New design and new templates, same content. The risk is similarly low, as long as the new templates don't lose content. That happens more often than you'd think: copy gets cut to fit the new layout, H1s disappear, internal links get dropped.

Full relaunch. Technology, design, content and page structure are all rebuilt at the same time. It's what most teams want, and of the first three variants it's the riskiest. If everything changes at once, you can't tell afterwards what caused a drop, and you can't roll it back selectively. The foundation first principle shows how to keep the risk low anyway.

Domain change. All the authority you've built with Google and AI search engines sits on your domain. A domain change has to transfer all those signals, and that takes time. One study of domain migrations found it took an average of 523 days for organic traffic to return to its previous level. 17% of sites hadn't recovered even after 1,000 days. So think very carefully about a domain change. If it's necessary, it belongs in the hands of a specialized SEO agency, supported by the website agency.

By the way: the horror numbers on traffic loss that appear in many relaunch articles almost always come from domain changes. They're not representative of a clean platform migration.

Signs your website needs a relaunch

A relaunch makes sense when your website is slowing down growth and smaller optimizations no longer fix it. The most common signs:

• Your marketing team can't ship a landing page the same day. Every new page, every campaign and every copy change ends up in the dev backlog and waits for the next sprint. Tests and variants practically never happen.
• Your website still tells the old product story. New modules, new ICPs or a new category don't show up, or only on a few subpages. Your product has outgrown your website.
• Sales has to correct the website on calls. If your sales team doesn't send prospects to the website, or first has to explain what you actually do, the site is working against you instead of for you.
• You don't know which pages drive pipeline. Forms aren't cleanly connected to the CRM, demo requests can't be traced to a source, attribution and tracking have gaps.
• Every page looks different. Over the years, pages from different campaigns, agencies and designs have piled up. There's no design system, and new pages don't match the rest.
• New markets or languages are a major project. Adding a language version or a country page means weeks of development instead of a click in the CMS.
• You don't show up in AI answers. When prospects ask ChatGPT or Google AI Mode for solutions in your category, competitors get named and you don't. Often the technical foundation is missing: no schema markup, content in images instead of text, unclear structure.
• The tech is holding you back. The CMS no longer gets updates, plugins break with every update, the site loads slowly and is clunky on mobile.

Wrong expectations

One sentence should make you pause: "We're relaunching so we rank better." A relaunch alone won't make you more visible. If you already have strong content and good rankings but the tech is holding you back, a clean migration can deliver a noticeable uplift. But if the content isn't there yet, no new design will change that. A migration or design relaunch can still make sense, but the real work comes afterwards, in the content.

When you should postpone

If you're in the middle of an internal discussion about positioning or pricing, wait with the relaunch until it's decided. These discussions almost always take longer than planned, and the website needs their outcome as its foundation. More on this in step 1.

How often should you relaunch?

Common rules of thumb suggest a relaunch every two to five years. We prefer a different approach: improve the website continuously based on real data instead of rebuilding everything every few years. This approach is also known as growth-driven design. A big relaunch is only needed when the foundation itself is outdated: platform, design system or information architecture. A good relaunch lays exactly that foundation so you can keep optimizing afterwards.

The core principle: foundation first

Before we get into the individual steps, one principle runs through the entire guide: the relaunch lays the foundation. Optimization comes afterwards.

Many relaunches are supposed to solve everything at once: better rankings, more conversions, a platform marketing can finally work with, a new design, all without risk. That's too many goals for one project. In the end, a lot gets improved a little, nothing gets improved properly, and the risk of something going wrong goes up.

Foundation first means:

1. Pages that rank or convert well today get migrated 1:1. New design and new tech, yes. Content changes, no. That way you see what the migration alone does.
2. Weak pages get improved right away. Where there's little traffic and no rankings, the risk is low and the upside is high.
3. New pages that aren't strictly needed for launch get built afterwards. Templates and components are ready by then.
4. After two to three months, you optimize in a controlled way. With real data from the new site, you know where to start and can attribute every change to its effect, positive or negative.

Why so few agencies recommend this. In the sales call, it's usually the C-level in the room, and they want a completely new website: new templates, new content, everything new. It's uncomfortable to say: "These pages rank well, we wouldn't touch them." A full relaunch is simply easier to sell. In our experience, the controlled approach is still the only right one, especially for large websites. It's exactly how we set up every website relaunch for B2B SaaS.

The website relaunch process in 8 steps

A relaunch breaks down into eight steps. Important: the biggest risks arise in the first three steps, not on launch day.

1. Clarify goals, scope and internal foundations: What should the relaunch achieve, which type is it, and are positioning and pricing decided?
2. Audit the current state: Which pages drive traffic and leads today? What are your competitors doing? What does your ICP need?
3. Define information architecture and page structure: Which pages will exist, under which URLs?
4. Develop design and UX: Wireframes, components, mobile experience.
5. Create and migrate content: What gets carried over, what gets rewritten, and how does content get into the new system?
6. Implement tech and SEO migration: CMS, tracking, integrations, redirects, technical SEO.
7. Test and launch: QA in the right order and a clear plan for go-live.
8. Monitor and optimize after launch: monitoring first, then controlled optimization.

In practice, some steps run in parallel, design and content for example. But the order of decisions should stay exactly like this.

Step 1: Clarify goals, scope and internal foundations

In this step, you decide what the relaunch should deliver and what it shouldn't. It's the most important step of the whole project, because the biggest blocker in relaunches is rarely the content itself. It's fundamental decisions that only surface during the project and then have to be discussed at the highest level.

Set realistic goals

Define which problem the relaunch should solve: more qualified leads, a marketing team that can work independently, a website that fits the new product strategy, or a better technical foundation. Prioritize. If you go after every goal at once, you usually reach none of them properly. Start with the concrete issues that triggered the relaunch, and define a KPI for each goal, for example demo requests per month or the time-to-launch for a new landing page.

Define scope and relaunch type

Decide which of the four relaunch types this is. Without that decision, you can't realistically plan cost, time or the effort for redirects. Be honest with yourselves: "We'll redo all 80 feature pages" is easy to say at kickoff. During the project, most teams realize they can't manage that on top of their day-to-day work.

Decide on positioning and messaging

By the time you get to the homepage at the latest, the question comes up: what should visitors perceive you as? A CRM, an HR tool, newsletter software? This framing determines how everything after it gets read.

An analogy: if someone tries to sell you insurance at a birthday party, you're not in the right frame of mind for it. At the bank, it's different. In the same way, the first impression of your website sets the frame in which visitors read everything else.

In these conversations, many teams realize their positioning isn't actually settled internally. The result is long alignment rounds at C-level and delays in the timeline. In a website strategy engagement, an agency can advise and bring the tools, but positioning has to come from within. A website project is often the trigger for revisiting it. But it should be decided internally and then brought onto the website, not decided based on the website.

Clarify pricing

A surprising number of SaaS companies only start thinking about their pricing once the website project begins. The agency can help with how the pricing page looks and works. But which plans, modules and prices exist is something only the company can decide.

Define ownership

Name one owner who consolidates feedback and makes decisions. When three founders comment independently, often contradicting each other, it costs everyone time. The same goes for SEO: on your side, you need someone who takes professional ownership of rankings and content.

Common mistakes in this step

• Starting the relaunch while positioning or pricing is still being discussed
• Too many goals at once and no clear KPIs
• Committing to the content effort in the sales call without checking your own team's capacity

Step 2: Audit the current state

Before you change anything, document what works today. This audit is also your baseline after launch. Without it, you won't know later whether the relaunch helped or hurt.

Check your tracking

First, check whether your tracking is reliable at all. Often it isn't implemented properly: conversions are miscounted, forms aren't captured, AI visibility was never measured. Then you lack the basis for deciding, with data, which pages matter. You can work from experience and best practices, but after launch you'll have nothing to compare against. If your tracking is unreliable, fix it first, for example with a clean tracking setup using GA4 and Google Tag Manager.

Secure your baseline

• Search Console: clicks, impressions and rankings per URL for at least twelve months
• Analytics: traffic and conversions per page, especially for demo, trial and contact forms
• Backlinks per URL, including PDFs and images
• A full crawl of the current site with all URLs, titles and meta descriptions
• Existing redirects on the old platform
• AI visibility: how often are you named for relevant questions in ChatGPT, Perplexity or Google AI Mode? Tools like Peec AI help here. You check the same questions again after launch.

Content audit

Build an inventory of all content: which pages exist, what they deliver, how they're built. Score every page on traffic, rankings, conversions and strategic relevance. That tells you what you carry over 1:1, what you rework and what can go.

Be careful with purely data-driven audits. We've seen an audit recommend deleting a page because it had barely any visits in three months. It had only been online for three weeks. Data always needs context.

Understand your ICP and buyer personas

Check whether your buyer personas are still current. As your product evolves, your ICP often does too. Ask customers and your sales team what visitors look for on the website, where they get stuck and which questions keep coming up in sales calls. Those answers are a better foundation for the new website than any internal assumption.

Competitor analysis

Look at how your strongest competitors structure their websites: what content they offer, how they position themselves, which calls to action they use. More interesting than what they do well are their gaps. What's missing there that you can offer? Don't copy a website. A copy always looks weaker than the original. AI tools speed this analysis up considerably.

Common mistakes in this step

• Starting with unreliable tracking and having no baseline after launch
• Not capturing the redirects on the old platform
• Judging content only by traffic, without context

Step 3: Define information architecture and page structure

In this step, you define which pages will exist, how they connect and which URLs they live under. This is where the biggest SEO risk of a relaunch arises, not with the redirects. Every decision about page types, URLs and merging pages is also a decision about rankings.

Navigation along the buyer journey

Visitors should always know where they are and reach what they're looking for in a few clicks: product information, pricing, a demo. The buyer journey is a good guide. Each stage needs the right content.

Approve the page structure first

Before anyone thinks about redirects, you need an agreed page structure: every page, its URL, title and whether it should be indexed, ideally in one sheet. That sheet gets approved and from then on only changes by agreement. The order is crucial: page structure first, then redirect mapping, then schema markup. Changing URLs after the mapping is done means doing the work twice or creating gaps.

You can copy our page structure sheet as a template. It covers page type, new URL, title tag, meta description and index status, with automatic length checks for titles and descriptions.

Keep, merge or delete?

The basis is your content audit from step 2. If several pages rank for the same topic, they're candidates for merging. But here too, foundation first applies: migrate first, merge afterwards. That way you can see the effect of every merge.

Adding new pages is uncritical. Be careful, though, about deleting large blocks of pages. Even if individual pages barely rank, their content can support your topical authority as a whole. Deleting 100 pages at once is a different decision from removing a single page.

Page types are keyword decisions

When you restructure page types, for example by replacing use-case pages with persona pages, you also change what you rank for. The most important rule: never two pages on the same topic. A feature page "Invoicing" and a use-case page "Create invoices" compete with each other. Small reused sections like a benefits strip, on the other hand, are no problem.

Overrated: solution, persona and feature pages. Almost every SaaS website has ten or more solution pages, plus persona, industry and feature pages. In our clients' data, most of them barely rank, because hardly anyone searches for "Tool XY for accountants". They can still make sense as campaign landing pages or as orientation for specific roles. Just don't build them expecting SEO traffic. And if you do, base them on keyword research, not on your internal use-case list. Pages like these are easy to build after launch.

Underrated: good comparison pages. Comparison pages are usually tables full of checkmarks meant to show why your own tool is better. That has two problems. First, search engines and AI assistants can't cite a checkmark. Write one or two sentences in each cell, such as "set up in 10 minutes, no prior knowledge needed". For paid landing pages, checkmarks work well, though. Second, the framing is often off. A good comparison is fair, like a referee describing the differences. Your differentiation comes from your product and positioning and doesn't need exaggerating.

Common mistakes in this step

• Redirect mapping based on a page structure that hasn't been approved yet
• Two pages on the same topic, such as a feature page and a use-case page
• Deleting large blocks of pages just because individual pages get little traffic

Step 4: Develop design and UX

In this step, the page structure turns into concrete layouts. Visitors form a first impression of a website in a fraction of a second. At the same time, the design has to do more than look good: it has to carry your content and let your marketing team build new pages quickly.

From wireframes to design

Start with wireframes, rough layouts without colors and images. That way you discuss structure and content first, not color shades. The final design only comes once the wireframes are approved. Think about the mobile experience from the start, because a growing share of your traffic comes from smartphones.

A design system instead of individual pages

Don't design individual pages. Design a system of reusable components: hero sections, feature blocks, testimonials, comparison tables, CTA sections. In Webflow, these become components with variants that your team can combine on its own. That's the basis for foundation first: new use-case pages or landing pages get built in hours instead of weeks after launch. See how we approach B2B SaaS web design as a system.

Usability and accessibility

Visitors should intuitively find what they're looking for and be able to request a demo or try the product in a few clicks. Pay attention to clear navigation, unambiguous CTAs and sufficient contrast. Accessibility according to WCAG is standard today. It improves usability for everyone and helps search engines understand your pages.

Templates have to carry the content

Test every template with real content, not placeholder text. A beautiful layout that no longer has room for the existing copy of a well-ranking page is an SEO risk. The new page has to hold at least as much content as the old one.

Manage feedback

Design feedback is one of the most common causes of delays. Consolidate it with the owner from step 1, plan fixed feedback loops, ideally no more than two per page, and give feedback directly on the design instead of in long lists.

Common mistakes in this step

• Jumping straight into final design and debating colors before the structure is settled
• Testing templates with placeholder text instead of real content
• Designing individual pages instead of a component system

Step 5: Create and migrate content

In this step, content moves into the new website: existing content gets carried over, new content gets written. Content migration is the phase that's most often underestimated and most often causes delays. The range is huge. Sometimes you download a CSV, map the fields in Webflow, and after fifteen minutes of QA everything is in. Sometimes it's two weeks of manual work.

Migrate legacy content 1:1 first

Content that ranks well gets moved into the new design unchanged. Only rewrite what's weak anyway or strictly necessary for the new positioning, such as the homepage. Everything else gets optimized after launch. That saves time, lowers risk and keeps effects measurable. Also plan time for approvals on new copy: they almost always take longer than the writing.

The migration check before the project starts

Clarify early how your content is built today, because the effort depends on it. Three questions:

1. Is the content structured or built as static pages? Content like glossaries, guides or knowledge articles belongs in a CMS. In the old system, though, it was often built as static pages, each with a different layout. Moving it into a uniform template means a lot of manual rework.
2. Can the content be exported cleanly? Even when content is set up as articles, the export can fail. If you use page builders like Elementor in WordPress, you'll often have embedded elements that can't be exported as structured data.
3. Does the template really know every element? Often a single example page serves as the blueprint for the new template. But it doesn't contain every element that actually occurs: tables, embeds, downloads, accordions, info boxes. So check all pages of a type, for example with a crawl.

Test the migration with three to five real pages before you plan the overall effort, and agree who handles the rework: the agency or your team.

Other underestimated areas

• Multiple languages. If language versions live in subfolders of the same website, migration is usually simple. But we've also had clients whose language versions sat on separate websites with separate hosting. That's not solved with an export.
• Downloads. A SaaS company quickly has 300 whitepapers, datasheets and PDFs. If they live in the old CMS, the question is whether the old system stays reachable or all files have to move. If they live in a marketing tool like HubSpot, it's easier, and you can track downloads better.
• Hard-coded links. Migrated content often still contains links to old URLs. You have to find and fix them.

Where AI helps and where it doesn't

AI takes a lot of work off your hands in migration today. It's very reliable with structured data: remapping fields, merging several fields into one, translating content in bulk. For one client, we translated more than 400 FAQs with AI, a task that used to take days. AI also helps review and prioritize content in the content audit.

We're careful as soon as AI doesn't just reorganize content but changes it. Every text has to be checked then. That's why every piece of AI work at our agency goes through a second agent that QAs the result. And the decisions are always made by a human who keeps the strategic goal of the relaunch in view.

Common mistakes in this step

• Trying to rewrite all content at once
• Estimating the migration effort without testing the export
• Building the template from a single example page

Step 6: Implement tech and SEO migration

In this step, the website gets built and set up technically so that rankings, tracking and leads survive the move. The centerpiece is redirects.

CMS and integrations

Choose a CMS your marketing team can work with without developers: building new pages, maintaining content, running tests. As a Webflow Enterprise Partner, we use Webflow for this. Connect the systems that depend on the website: CRM, marketing automation, forms, chat, meeting booking.

Rebuild your tracking

Tracking is what breaks most easily in a relaunch. If you use Google Tag Manager, for example, you don't just have to add the code, you also have to set up tags and triggers for the new page structure. If the code is missing on some pages or an event doesn't fire, your data is useless. Define upfront which events you measure, such as demo requests, trial sign-ups and downloads, and make sure tracking and cookie consent work together. Also switch every system that points to your website to the new URLs, Google Ads campaigns first.

Redirects: the centerpiece of SEO migration

Every permanently changed URL needs a 301 redirect to the most relevant new page. Only a 301 tells Google that the new URL permanently replaces the old one. How to plan, map and test redirects in detail is covered in our guide to a website relaunch without losing SEO.

• The best redirect is no redirect. Migrations often create new URLs by accident, for example because the new system handles hyphens differently. If the change isn't intentional, match the new URL to the old one.
• Bring over the old platform's redirects. The old website usually already has redirects of its own, often with important URLs behind them. Forget them and lots of URLs end up nowhere.
• Resolve chains. Every old URL should point directly to its final destination, with no stops in between.
• Don't send everything to the homepage. Google treats mass redirects to the homepage like missing pages. Every URL needs a relevant destination. For pages that no longer exist, someone from your content team is best placed to decide which one.
• Patterns instead of single rules. Check whether you can redirect entire folders with a wildcard, for example everything under /blog/.
• Don't forget files. PDFs and images with backlinks need a redirect too.
• Prevent URL changes after the mapping. We had a case where the blog was renamed to "Resources" shortly before launch. Nobody thought about the redirects, and the old blog URLs led nowhere.

AI helps a lot with mapping, for example in checking whether a redirect already exists for a URL. A human still reviews the final mapping.

Redirects in Webflow: three things to know

1. Webflow only supports 301 redirects. For permanent moves, that's correct. But sometimes you need temporary redirects (302 or 307), for example for transition phases you still want to change later. Browsers cache a 301, and it's hard to undo. If your host can't do temporary redirects, move the domain to Cloudflare beforehand. The final redirects are always 301s, though.
2. A CSV import replaces all existing redirects. If you upload a list that's missing the previous entries, you delete them. So always upload the complete list.
3. Multiple languages. For websites using Webflow Localization, check how redirects affect translated URLs and test every language version separately.

Technical SEO and AI visibility

• Carry over metadata: title tags and meta descriptions of existing pages, especially those that rank well.
• Internal links pointing directly to the new URLs, not to redirects.
• Canonicals and domain variants: one version of the domain (with or without www) is canonical, the other redirects.
• hreflang for all language versions.
• Schema markup: global markup such as organization, name and address is standard. Content markup like FAQ or pricing needs alignment, because whoever changes FAQs or prices on the page also has to maintain the markup. Since 2026, Google no longer shows FAQ rich results. FAQ markup still helps machines understand your content.
• XML sitemap and robots.txt: in Webflow, the auto-generated XML sitemap is usually enough. A custom sitemap only pays off for very large websites.
• Accessibility and semantic HTML as the technical foundation.
• Images compressed, for example as AVIF or WebP, with alt text.
• Readable for AI search: don't block AI crawlers, and serve content as text in the HTML, not in images or checkmarks. You don't need a special AI file or a separate GEO schema. But a relaunch is a good moment to structure content so AI assistants can cite it: clear questions as subheadings, direct answers underneath.

Common mistakes in this step

• Forgetting the old platform's redirects
• Uploading only the new redirects in Webflow and deleting the old ones in the process
• Tracking code or events missing on some pages

Step 7: Test and launch

Technically, the launch is almost unspectacular: switch the DNS, take the website live. If the previous steps went well, everything is already decided by launch day. What counts now is thorough QA and a clear plan for the day itself.

QA in the right order

Separate checks that depend on content from those that don't.

• Early, independent of content: broken links, load times, forms, tracking, rendering across devices and browsers, 404 page, favicon and social preview images.
• Only once content is final: headlines, title tags, meta descriptions, alt text, internal links, schema markup.

Check content-dependent items too early and you'll check them twice. It helps to finish pages in clusters, for example the entire blog first, then all feature pages.

Three checks that often get skipped:

• Test forms all the way into the CRM. A success message in the browser doesn't mean the demo request actually landed in the CRM and was assigned correctly.
• Check tracking and consent together. Do the conversion events fire, and only after consent is given?
• Evaluate page speed correctly. Lab tests like Lighthouse get worse because of your own marketing tags. After go-live, evaluate real user data (Core Web Vitals in Search Console) and use lab tests for diagnosis.

Launch day

1. Define launch-critical vs. fix-later. A "Start free trial" button that doesn't work gets fixed immediately. A wrong image on a subpage can wait. Set this line in advance.
2. Pick the time window based on your data. Analytics shows when traffic on your website is lowest.
3. Assign ownership. Who switches the DNS, who points Google Ads campaigns to the new landing pages, who tests conversions? Paid landing pages have priority, because that's where paid traffic lands.
4. Check right after go-live: noindex removed, robots.txt correct, redirects working (the most important URLs in full, the rest by spot check), sitemap submitted in Search Console, forms and tracking tested live.
5. A quick check the next morning: indexing, errors in Search Console, conversions from the first hours.

By the way, the most common mistake after launch is a leftover noindex tag from the staging environment. Nobody notices until traffic drops.

Announce the launch

A new website is a good reason to reach out to customers, partners and prospects, for example via newsletter, a LinkedIn post or an in-product notice. That brings real visitors to the site in the first few days and gets you early feedback.

Common mistakes in this step

• Running content-dependent checks before content is final
• Testing forms only in the browser, not in the CRM
• No agreed definition of what's launch-critical

Step 8: Monitor and optimize after launch

Launch is day one. In the first few weeks, you check whether the migration took hold properly. Then the real work begins.

Monitoring: what's normal when

Google processes changed URLs gradually. So rankings holding steady in the first few days doesn't mean everything worked. If a drop persists, look for the cause in this order: are the pages indexed? Are the redirects working? Does the new page have less content than the old one? Or has demand simply gone down, seasonally for example? We walk through each of these causes in how to relaunch without losing SEO.

Clean up after launch

• Update external links: profiles on G2 and Capterra, partner pages, LinkedIn, your docs and help center.
• Internal links pointing to redirects should be switched directly to the new target URLs.
• Measure AI visibility again: the same questions as in your baseline, within the first 30 days.
• Gather feedback: how do customers and prospects respond to the new website? What does your sales team say?
• Keep redirects permanently: Google recommends at least a year. We recommend never removing them.

Beware of pretty numbers

Agencies love to advertise percentages after a relaunch. We've also seen around 30% more visibility after relaunches. But what does that mean? More impressions don't automatically mean more clicks. More traffic doesn't automatically mean more MQLs and SQLs. What counts in the end is whether the website brings in more qualified pipeline. So measure the relaunch against the goals you set in step 1. Our case studies show what that looks like in practice.

Launch is day one

Many companies relaunch their website and then don't touch it for years. You wouldn't treat any other channel that way. Nobody launches Google Ads and never looks at them again. Your company, your market and your customers change. Your website should too.

After two to three months, you have enough data for an optimization plan, which for us is the Growth Plan. Prioritize by impact: that might be a pillar page on a core topic with more content built underneath it, optimizing your most important conversion pages, or the use-case pages you deliberately postponed during the relaunch. Templates and components are ready, so new pages get built quickly.

Common mistakes in this step

• Stopping monitoring after a stable first few days
• Measuring success by impressions instead of leads and pipeline
• Not developing the website further after launch

How much does a website relaunch cost, and how long does it take?

With us, a B2B SaaS relaunch costs between around €20,000 for a pure technical migration and €100,000 or more for enterprise projects. It takes between 6 weeks and 6 months. The range depends almost entirely on the relaunch type.

General guides often quote entry prices of a few thousand euros. Those apply to small, template-based websites. A SaaS website with product and feature pages, a blog, multiple languages and a CRM integration is in a different league.

What drives the cost

• Number of pages to migrate and how they're built today (see the migration check in step 5)
• Number of new templates and new pages
• Custom design instead of a template solution, possibly a branding project
• Multiple languages
• Integrations such as CRM, marketing automation or product APIs
• Scope of QA and testing, especially for enterprise projects

If the proposal exceeds your budget, split the work into must-haves and nice-to-haves. Following foundation first, a lot of it can sensibly happen after launch.

What drives the timeline

In full relaunches, the biggest time factor is usually not the agency but the content. Your team has to write, align and approve it, on top of day-to-day work. The most common reasons for delays:

1. Unresolved fundamentals: positioning or pricing discussions that break out mid-project.
2. Unclear scope: requirements that change during the project.
3. Late content: copy and images that are only ready on the planned launch date.
4. Too many approval loops: several stakeholders signing off on every page individually.

So always plan buffer for approvals and revisions. The final alignment rounds take longer than expected in many projects. The more you settle in step 1, the faster and cheaper the project gets.

In-house or with an agency?

It depends on which skills you have in-house: strategy and messaging, design, development, tracking, SEO and project management. A strong in-house team with Webflow experience can handle a pure platform migration on its own. For full relaunches, multiple languages or complex content migrations, outside support usually pays off. For a domain change, you also need a specialized SEO agency.

When choosing an agency, aim for a long-term partnership. Questions and issues almost always come up after go-live, and an agency that knows your website and your company responds faster.

How to spot a good relaunch agency

A good agency also tells you things in the sales call that you don't want to hear. These questions help you choose:

• Do they ask about your best pages before talking design? If they don't want to see Search Console and Analytics, they're planning without a foundation.
• Do they ever advise against something? For example, against rewriting every feature page during the relaunch.
• Can they explain how they handle legacy content? If all they say is "we'll migrate everything", they usually haven't tested the export.
• Do they know the platform's limits? In Webflow, for example, how redirects and multiple languages work.
• Do they know when they're not the right fit? For a domain change, a website agency should bring in an SEO agency.
• What happens after launch? An agency that disappears after go-live sees the relaunch as the end instead of the beginning.

Pay less attention to percentages in case studies and more to how well they answer your follow-up questions.

Planning a relaunch? See how we approach a website relaunch for B2B SaaS, or book a free strategy call and we'll take a look at your current website together.

Website relaunch checklist: the short version

The most important points per step at a glance. You'll find the detailed working version, with timing, ownership and a done-criterion for every item, in our website relaunch checklist with 100+ items, also as a Google Sheet you can copy. The page structure sheet is available as a template too.

• Step 1: goals prioritized, relaunch type defined, positioning and pricing decided, owner named
• Step 2: tracking checked, baseline secured (Search Console, conversions, backlinks, crawl, AI visibility), old redirects exported
• Step 3: page structure with all URLs approved, no two pages on the same topic
• Step 4: wireframes before design, component system, templates tested with real content
• Step 5: well-ranking pages migrated 1:1, export tested with real pages, all elements per page type captured
• Step 6: tracking and consent set up, redirect mapping complete, full list uploaded in Webflow
• Step 7: forms tested all the way into the CRM, launch-critical issues defined, noindex removed and sitemap submitted after go-live
• Step 8: Search Console closely monitored, baseline compared, optimization plan set up after 2 to 3 months

Website relaunch FAQ

Do you lose rankings in a website relaunch?

Not necessarily. With a pure platform migration or a design relaunch with unchanged content, rankings usually stay stable or even improve. The risk rises when content, page structure and URLs all change at once. It's highest with a domain change.

What's the difference between a relaunch and a redesign?

A redesign changes how a website looks. A relaunch is the fundamental rebuild and can include technology, design, content, structure and the domain. A redesign can be part of a relaunch.

How long does a website relaunch take?

A technical migration takes 6 to 10 weeks, a migration with a new design around 3 months, a full relaunch with new content 3 to 6 months. The biggest time factor is usually content and its approval.

How much does a website relaunch cost for a SaaS company?

From around €20,000 to €25,000 for a technical migration, from around €30,000 with a new design, and €40,000 to €60,000 for a full relaunch. Enterprise projects can cost €100,000 or more.

How often should you relaunch a website?

There's no fixed cycle. Better than a relaunch every few years is a website that's continuously improved based on data. A relaunch is needed when the foundation itself is outdated: platform, design system or information architecture.

Should you rewrite all content during a relaunch?

No. Pages that rank and convert well should be migrated 1:1 first. That keeps the effect of the migration measurable, and you can optimize specifically after launch. Weak pages, on the other hand, can be improved right away.

How long should redirects stay in place?

Google recommends at least a year. We recommend keeping them permanently, since external links and bookmarks often point to old URLs for years.

When do you see first results after a relaunch?

A possible dip after a migration should be over after 1 to 2 weeks. First effects of optimizations show after 4 to 6 weeks, clear results after 3 to 4 months.

How does AI help with a website relaunch?

AI mainly speeds up work with structured data: content audits, competitor analysis, redirect mapping, translations and remapping CMS fields. Content changes made by AI should always be reviewed, and strategic decisions are made by a human.

Which CMS is right for a SaaS relaunch?

One your marketing team can work with without developers. We use Webflow, because marketing teams can build landing pages, CMS content and tests themselves, without compromising on technical SEO.