Website Redesign Process and Timeline: From Discovery to Launch

A website redesign is not simply a design project with a launch date attached. For a B2B or SaaS marketing site, it must protect organic visibility, lead capture, analytics, content workflows, CMS structure, and the handoffs that sales and marketing rely on.

The first things to fail are rarely the homepage visuals. Projects slip when no one owns copy approval, URLs change without a redirect plan, forms are not tested end to end, or launch week becomes the first time SEO and tracking are reviewed.

A reliable process moves through seven connected phases: discovery, strategy, content and CMS planning, design, development, SEO and QA, then launch and stabilization. The timeline varies by scope, approvals, integrations, content readiness, CMS complexity, and URL changes. The operating model should not.

How long does a website redesign take?

For a defined mid-sized B2B marketing site, an illustrative website redesign timeline is often 10 to 14 weeks. This is not a universal promise. A visual refresh with stable content can move faster. A rebuild involving new messaging, a revised sitemap, Webflow CMS migration, CRM integrations, and SEO-sensitive URL changes usually needs more time.

A marketing agency website redesign process works best when phases overlap only after their dependencies are stable. Strategy informs content. Content and CMS rules inform templates. Approved templates allow development to progress. SEO migration work begins during planning and is verified before launch.

1. Discovery and scope
2. Strategy, sitemap, content, and CMS planning
3. Design
4. Development
5. SEO migration work and pre-launch QA
6. Controlled launch
7. Post-launch stabilization

Page count is only one factor. Ten complex CMS templates can require more planning than 40 simple pages. Likewise, a small site can move slowly when multiple stakeholders approve every headline.

The schedule is usually driven by approval speed, copy ownership, number of reusable templates, CMS requirements, integrations, migration risk, and review cycles. A useful planning baseline is to reserve time for these dependencies rather than treating design and development as the whole project. For broader scope planning, see B2B Website Redesign Guide.

Phase 1: Discovery, scope, and stakeholder alignment

The redesign discovery phase defines what the project is solving and how decisions will be made. It should cover business goals, priority audiences, conversion paths, analytics baselines, existing SEO risk, page inventory, integrations, CMS needs, and approval rules.

The most useful discovery output is not a moodboard. It is a documented exit state: an approved page inventory, named owners for copy, SEO, design, and launch sign-off, known technical dependencies, and visible launch blockers. Without that, production begins with assumptions that later become delays.

In practical terms, discovery should identify pages that generate qualified traffic or leads, conversion paths that cannot break, and systems that need to receive data after launch. It should also establish who can make a final call when feedback conflicts.

A common blocker is shared ownership with no decision owner. If several people can comment on copy but nobody can approve it, design stalls. If a CRM integration is identified after development begins, QA becomes compressed. A credible website redesign scope makes these dependencies visible before they become launch risks.

Phase 2: Strategy, sitemap, content, and CMS planning

This is the most dependency-heavy stage of a marketing website redesign process. It connects the site’s message and navigation with content work, URL decisions, conversion paths, and the publishing workflow the marketing team will use after launch.

Plan the sitemap, content, and URL migration together

Sitemap planning should not be separated from content and SEO. Every page decision affects navigation, internal links, copy workload, metadata, redirects, and sometimes CMS templates.

Start with a page inventory and content audit. Classify pages to retain, rewrite, consolidate, redirect, or remove. Traffic, backlinks, conversion value, sales usefulness, and strategic relevance all matter. A visually dated page may still support valuable search intent. A low-traffic page may still be important to a sales process. The goal is intentional decisions, not keeping everything.

There is a real tradeoff. Preserving a valuable URL can reduce migration risk, but preserving weak information architecture solely because it already exists can hurt clarity and conversion. In many cases, the practical answer is to retain high-value URLs where they still fit, change the structure where needed, and map every changed URL to the closest relevant destination.

Redirects should follow user intent and page value, not merely URL patterns. Google Search Central's site-move guidance supports treating redirects as a planned migration task, not a last-minute launch setting. When the redesign includes platform migration, URL restructuring, or content consolidation, this is a core part of SEO-safe Webflow migration support.

Define CMS architecture before templates are built

CMS architecture should begin with how the marketing team will publish and maintain content, not with how a design comp looks. In Webflow, that means defining collections, fields, taxonomies, references, reusable page types, editor permissions, and migration rules before templates are locked.

For example, a resource library may need title, slug, summary, resource type, topic, author, publish date, gated status, related resources, and featured image fields. Those choices affect filtering, related-content modules, SEO fields, and the template used to publish each resource. A blog may also need categories, author references, metadata, and a clear rule for related posts.

The choice is between reusable CMS templates and hardcoded one-off pages. Reusable templates require more planning, but give editors consistency and reduce future maintenance. One-off pages can be appropriate for a genuinely unique need, but too many create fragile publishing workflows and make the next redesign harder.

This phase should end with an approved sitemap, content ownership plan, URL direction, CMS collection model, and a list of unresolved dependencies. For teams planning a scalable editorial system, Webflow CMS architecture provides the implementation context behind these decisions.

Phases 3 and 4: Design and development

Design and development can overlap safely, but only when the core inputs are stable. These phases turn strategy into an editable, conversion-focused site.

Design templates around real content and approval gates

Start with priority templates and conversion paths rather than designing every page at once. For many B2B sites, that means the homepage, service or product pages, resource templates, landing pages, and key form journeys.

Wireframes and visual concepts need representative content. Placeholder copy hides problems until real proof points, screenshots, long headings, and CTAs are inserted. Responsive behavior should be considered early for navigation, forms, comparison content, and long-form resources.

Use staged approvals: design direction first, then core templates, then controlled variations. Approving the underlying system before expanding to every page prevents expensive rework.

Build for reuse, editing, and integration testing

Webflow development should translate the approved system into reusable components, responsive templates, CMS structures, and sensible editing guardrails. It should account for accessibility basics, performance, forms, analytics, CRM connections, and the way internal teams will update pages after launch.

Development speed cannot compensate for unresolved copy or repeated template changes. Repeated changes often create more risk than the initial build because components, CMS rules, and page variations must all be rechecked. Safe overlap requires approved core templates, known content rules, and documented integration requirements.

Phase 5: SEO migration work and pre-launch QA

Pre-launch QA shifts the question from “does it look right?” to “is it safe to launch?” An SEO-safe redesign validates work started during planning. It is not the point at which the team first notices changed URLs, missing metadata, or disconnected forms.

Validate the SEO migration plan

Technical SEO QA should review final URL mapping, 301 redirects, titles and meta descriptions, canonical tags, indexability, robots directives, XML sitemap accuracy, internal links, and structured data where it is relevant and correctly implemented.

Each important old URL needs an appropriate live destination. Redirecting everything to the homepage is rarely useful. Give extra attention to pages with organic visibility, backlinks, conversions, or a role in the sales journey. If content has been consolidated, confirm the new page actually satisfies the intent of the retired one.

Also check that staging controls do not reach production. Common failures include lingering noindex tags, blocked crawl paths, incorrect canonicals, broken internal links, missing metadata, and orphaned CMS items.

Test conversion paths, analytics, and integrations

Visual QA is only one layer. Functional and technical QA must test forms, validation states, thank-you pages, analytics events, consent behavior where relevant, CRM routing, notifications, navigation, search, gated content, and key embeds. Submit a real test lead and confirm its fields reach the intended system.

This prioritization matters. A minor layout issue is not equivalent to a broken lead path. Documented low-risk defects can be handled after launch; failed lead routing, incorrect indexability, and significant redirect failures should block it. For a fuller operational checklist, use Website Redesign Pre-Launch Plan. A specialist Technical SEO audit is particularly valuable when URL changes or a migration increase the technical risk.

Phases 6 and 7: Controlled launch and stabilization

Launch is a controlled handoff from staging to production, followed by a defined verification period. It should include domain and DNS steps, redirect activation, production settings, SSL checks, form and CRM tests, analytics validation, sitemap submission, and immediate spot checks of priority pages.

Clear ownership and escalation paths are essential. If forms fail, redirects loop, or DNS behaves unexpectedly, the team should know who investigates and who can approve a fix. Launch day is not the time to route every decision through a committee.

Treat the first 72 hours as a monitoring window

Post-launch stabilization is not vague support. It is a focused monitoring window with a practical sequence:

• Immediately after launch: test priority forms and CRM routing, analytics events, redirects, production indexability, and critical navigation.
• Within 24 hours: review crawl errors, high-value redirects, sitemap status, consent behavior, template rendering, and lead notifications.
• During the following days: monitor indexation signals, analytics continuity, performance anomalies, CMS publishing issues, and unexpected template defects.

Urgent fixes include broken conversion paths, redirect loops, accidental noindex settings, tracking failures, and serious CMS or template bugs. CRO tests, additional content refinements, and performance tuning can follow once the site is stable. Organic visibility can move after a redesign, especially when content, internal links, or URLs change, so stabilization should focus on finding avoidable technical issues rather than promising instant ranking stability.

Conclusion: Evaluate the process before the project starts

A credible redesign plan connects deliverables, owners, dependencies, approval gates, SEO protection, launch criteria, and stabilization. It shows how discovery informs strategy, how content and CMS decisions shape templates, and how QA protects traffic, tracking, and lead capture.

Use the process as an agency-evaluation rule: if a proposed plan cannot name decision owners, explain URL direction, define launch blockers, and include a stabilization window, it is not ready for production. Vague timelines that cover only design and development leave the highest-risk work unowned.

Launch safety is created by earlier decisions, not by a last-minute checklist.