A website redesign can take anywhere from a few weeks to several months, depending on the site’s size, the number of templates, the content workload, technical complexity, and how quickly stakeholders make decisions. A small marketing site may be redesigned in roughly 6–10 weeks. A larger B2B, ecommerce, or multi-location website often needs 3–6 months or more.
The most reliable timeline is not based on page count alone. It accounts for the work behind the visible interface: auditing the current site, defining the information architecture, planning UX, producing or migrating content, configuring the CMS, preserving SEO signals, testing integrations, and monitoring performance after launch.
This guide explains what happens in each phase and which trade-offs can shorten or extend a website redesign timeline. For a broader view of deliverables and scope, see the website redesign checklist.
Typical website redesign timelines by scope
| Project type | Typical timeframe | Common characteristics |
|---|---|---|
| Small brochure or marketing site | 6–10 weeks | Limited templates, relatively stable content, few integrations, one primary decision-maker |
| Mid-sized B2B website | 10–16 weeks | Multiple audiences, custom UX, new page templates, content revisions, CMS configuration, SEO migration |
| Large or complex website | 4–6+ months | Many page types, complex integrations, extensive content migration, multiple teams, regional or product structures |
These are planning ranges, not guarantees. A focused redesign with prepared content can move faster than a smaller project with unclear ownership, delayed approvals, or major changes to the underlying CMS.
The main phases of a website redesign
1. Discovery and audit: 1–3 weeks
The project usually begins with a review of the current website and the business requirements for its replacement. This phase should establish what needs to improve, what must be preserved, and what can be removed.
Typical activities include:
- Reviewing analytics, search performance, conversion paths, and technical issues
- Inventorying pages, templates, media, forms, integrations, and content owners
- Identifying audience needs, business priorities, and high-value user journeys
- Reviewing competitors and relevant category conventions
- Defining project goals, constraints, risks, and approval responsibilities
A useful audit separates evidence from assumptions. The website redesign audit guide can help structure this work before visual design begins.
2. Strategy and information architecture: 1–3 weeks
Once the current site is understood, the team defines the future structure. This can include a revised navigation, page hierarchy, URL strategy, content model, and priority user flows.
For a B2B website, this is where teams often clarify how services, industries, resources, case studies, and conversion paths relate to one another. The output may include a sitemap, page-type inventory, wireframes, and a list of content requirements.
Skipping this phase can create expensive rework later. A page may look polished in isolation while still occupying the wrong place in the site or failing to support the user’s next step.
3. UX and visual design: 2–6 weeks
Design time depends on how many distinct templates and interaction patterns the redesign requires. A small site may need only a homepage, standard interior page, contact page, and a few reusable sections. A larger site may require designs for service pages, resource hubs, article templates, comparison pages, product listings, forms, search results, and account or portal experiences.
UX work typically establishes layout, hierarchy, content emphasis, navigation, responsive behavior, and interaction logic. Visual design then develops the interface system: typography, color, spacing, components, imagery, and states.
Design production moves more efficiently when the project has a clear brief and an agreed approval process. The website redesign brief guide covers the information that helps teams make decisions before production accelerates.
Brand requirements can also affect this phase. If the redesign must align with a broader visual system, review the relevant design capabilities early rather than treating brand decisions as late-stage decoration.
4. Content planning and production: 2–8+ weeks
Content is one of the most common causes of schedule changes. The work may involve writing new pages, editing existing copy, approving claims, sourcing photography, creating illustrations, updating metadata, rewriting calls to action, and deciding what should be archived.
Content can run in parallel with design and development, but only if responsibilities are clear. Teams should decide:
- Which pages are being kept, consolidated, rewritten, redirected, or retired
- Who owns drafts, subject-matter review, legal review, and final approval
- Which content fields the CMS requires
- What images, downloads, videos, and structured data need to be migrated
- Whether new content is required before a template can be approved
Placeholder copy may be acceptable during early wireframes, but final content is necessary for accurate layout, accessibility review, metadata, and quality assurance.
5. Development and CMS implementation: 3–8+ weeks
Development converts approved designs and content requirements into a working website. The schedule depends on the CMS, component library, integrations, hosting environment, data model, and level of customization.
Development may include:
- Building responsive templates and reusable components
- Configuring CMS fields, permissions, workflows, and publishing rules
- Connecting forms, CRM systems, search, analytics, marketing tools, or other integrations
- Implementing accessibility, performance, security, and technical SEO requirements
- Preparing redirects, metadata fields, canonical behavior, XML sitemaps, and structured data
A redesign is not complete when the front end looks correct. Content editors also need to be able to maintain the site without introducing inconsistent layouts or missing required fields.
6. Content migration and SEO preservation: 1–4+ weeks
Migration can be straightforward when the site has a clean structure and limited content. It becomes more involved when URLs change, pages are duplicated, content types differ, or valuable search pages have unclear ownership.
A responsible migration plan should include:
- A complete URL and content inventory
- One-to-one redirects for changed URLs where an equivalent page exists
- Redirect decisions for consolidated or retired content
- Canonical tags that reflect the intended indexable version
- Preservation or recreation of important title tags, descriptions, headings, internal links, and structured data
- XML sitemap updates and robots directives
- Analytics and search-console verification after launch
Redirect mapping should not be left until the day before launch. It requires decisions about page equivalence, destination quality, and gaps in the new information architecture. Teams managing a substantial organic search footprint may also coordinate this work with SEO services.
7. Quality assurance and launch preparation: 1–3 weeks
Quality assurance tests the site as a system rather than as a collection of screenshots. Review should cover desktop and mobile layouts, common browsers, forms, navigation, search, links, media, permissions, error states, accessibility, and performance.
Before launch, confirm:
- All priority pages have been reviewed with realistic content
- Forms submit correctly and reach the intended recipients or systems
- Analytics events, conversion tracking, and consent behavior work as expected
- Redirects, canonicals, metadata, structured data, and sitemap settings are ready
- Staging protections will not carry over to production
- Backups, rollback procedures, DNS access, and launch ownership are documented
- Editors know how to publish, update, and troubleshoot common content
8. Launch and post-launch monitoring: 1–4 weeks
Launch is a transition point, not the end of the redesign. Teams should monitor uptime, analytics, search crawling, indexation, redirects, forms, conversion paths, page speed, and user feedback after release.
Some issues appear only under real traffic or after search engines recrawl the site. A post-launch review can identify broken links, missing tracking, unexpected indexing behavior, template defects, or high-friction user journeys. Fixing these quickly protects the investment and creates a more accurate baseline for future optimization.
What makes a redesign take longer?
The largest schedule risks are usually coordination and scope issues rather than visual design alone.
- Unclear decision rights: Too many reviewers or no final approver can turn simple feedback into repeated cycles.
- Late content: Missing copy, images, approvals, or subject-matter input can block design and testing.
- Uncontrolled scope: New features, integrations, page types, or brand changes introduced mid-project require additional planning.
- Complex migrations: Large URL inventories, regional sites, multiple languages, and legacy CMS data increase mapping and validation work.
- Hidden technical dependencies: Older integrations, custom scripts, hosting constraints, or undocumented workflows may surface during implementation.
- Weak stakeholder availability: A project slows when subject-matter experts and business owners cannot review work at agreed checkpoints.
How to shorten the timeline without cutting essential work
Speed should come from reducing uncertainty and rework, not from removing migration or quality checks.
- Set a definition of done. Document the pages, templates, integrations, SEO requirements, accessibility expectations, and launch criteria included in the project.
- Assign one accountable approver. Collect specialist input, but give one person responsibility for consolidating feedback and making final decisions.
- Start the content inventory early. Identify missing, outdated, duplicate, and legally sensitive content before design and development are locked.
- Use a component system. Reusable components make design and development more consistent and reduce one-off production work.
- Run parallel workstreams carefully. Audit, content planning, design, and technical discovery can overlap when their dependencies are understood.
- Prepare migration rules before build completion. Early redirect and canonical planning exposes structural problems while they are still inexpensive to fix.
- Reserve time for real QA. Compressing testing often transfers schedule risk to launch day and post-launch operations.
How to choose a realistic target date
Start with the desired launch date, then work backward from the activities that cannot be compressed safely: content approval, development, migration validation, analytics setup, and quality assurance. Add review windows for subject-matter experts, legal or compliance teams, and executives where applicable.
It is also useful to define a minimum viable launch. A site may launch with a focused set of high-priority templates and content while lower-priority enhancements follow in a documented second release. That approach is different from launching incomplete core journeys or postponing SEO safeguards.
Ask these questions before accepting a schedule:
- How many unique templates and integrations are included?
- Is content being rewritten, migrated, or both?
- Will URLs, navigation, CMS, analytics, or structured data change?
- Who approves strategy, design, content, and launch readiness?
- What work can proceed in parallel, and what depends on an earlier decision?
- What is explicitly out of scope?
Bottom line
Most website redesigns need several weeks at minimum, while complex B2B and ecommerce projects commonly require several months. The strongest timeline connects discovery, UX, content and CMS migration, redirect mapping, canonical and schema preservation, analytics, QA, launch, and post-launch monitoring.
If you are defining scope or comparing implementation approaches, use this timeline alongside the website redesign overview. The goal is not simply to launch faster; it is to launch a site that is usable, maintainable, measurable, and prepared to retain the value of the existing website.
