How Long Does a Website Redesign Take?

Most service-business redesigns land somewhere between eight and sixteen weeks from kickoff to a controlled launch — when scope is clear, content has an owner and SEO migration is planned. Smaller brochure rebuilds can finish faster. Complex multi-template sites with integrations, many stakeholders or heavy URL change often take longer.

“It depends” is true and unhelpful. What matters is which dependencies you are buying time for.

A useful range, not a fake schedule

Treat the following as planning ranges, not promises:

Calendar time stretches when decisions wait. Build time stretches when scope changes after templates are underway. A quote that ignores those stretches is not aggressive — it is incomplete.

What each phase actually does

Discover. Goals, audiences, analytics, technical constraints, competitors and what must be protected. Skipping this may save a week and reopen foundational decisions later — usually after design has already burned budget on the wrong assumptions.

Structure. Sitemap, page purposes, content inventory, URL and redirect strategy. This is where redesigns quietly succeed or fail. If URLs change without a redirect plan, you are scheduling an SEO emergency for launch week. See the website redesign checklist before design lock-in.

Design + build. Patterns and components first, then page assembly. Development can overlap once the system is stable — not while the homepage concept still changes weekly. Parallel work only helps when the design system and content model stop thrashing.

Migrate + QA. Redirects, metadata, forms, analytics, accessibility, responsive checks and production configuration. Compressing this into the last afternoon is how launches create emergencies. Pair with the website migration checklist and SEO during a website redesign.

Launch. Cutover, monitoring and ownership. Someone must own forms, Search Console and the first critical-journey checks. A launch without named owners for those three items is not controlled — it is hopeful.

Phase risks that stretch the calendar

Discovery that never ends — endless competitor tours without decisions — delays structure. Structure that stays vague — “we’ll figure URLs later” — creates migration debt. Design that keeps reinventing every page type after components were approved forces rebuilds. QA that starts after marketing has already announced a date turns into weekend fire drills.

The risk pattern is consistent: later phases absorb earlier unfinished decisions. Budget and calendar both pay for that absorption.

What usually slows a redesign

Design itself is rarely the longest path. More often:

• Content readiness — copy does not exist, or nobody can approve it. Pages sit in “design approved, waiting on words” for weeks while the calendar still looks active.
• Decision latency — stakeholders unavailable, conflicting feedback, no single decision owner. Two rounds of conflicting homepage notes can cost more calendar time than the design work itself.
• Late technical requirements — CRM fields, booking tools, auth or localization appearing mid-build after templates were already assembled
• Migration surprises — undocumented URLs, brittle redirects, forgotten campaign landings that sales still uses in proposals
• Scope creep — “while we’re at it” features without timeline trade-offs. Every new integration should buy an honest date move or an explicit cut.

If content and ownership are unclear at kickoff, add time before you add designers. Hiring more designers does not invent missing copy or missing approvals.

Drivers that change the calendar

Beyond the phase list, these variables usually move a project between the ranges above:

• Number of page types — a handful of templates finishes faster than a unique layout for every service
• Integrations — booking, CRM, portals and payments add build and QA time
• CMS and editor model — structured components are faster to stabilize than fully freeform page builders
• Review cycles — two named approvers beat a committee that rediscovers feedback every round
• SEO migration depth — keeping URLs is faster than remapping hundreds of redirects carefully (and carefully is required if traffic matters)
• Content volume — rewriting twenty service pages is a different project than polishing five

None of these are reasons to skip quality. They are reasons to stop pretending every redesign is an eight-week fixed package.

How to get a credible timeline from an agency

Ask for phases with owners, not only an end date. Useful questions:

• What must be true before design starts?
• Who writes and approves content, and by when?
• Which URLs are keep / merge / redirect?
• What is out of scope if the date is fixed?
• What QA happens on production, not only staging?
• Who owns post-launch form, analytics and Search Console checks in the first week?

A shorter quote that assumes perfect content and instant approvals is not a shorter project — it is an optimistic model. Compare proposals on dependencies and decision points, not on who promises the earliest Friday — and score the document itself with what a website proposal should include.

If two agencies quote the same end date with very different assumptions about your content readiness, believe the assumptions, not the date.

The practical takeaway

A redesign timeline is a dependency map. Design and development move as fast as decisions, content and migration discipline allow. If you need a scoped plan for your site, start with website redesign and treat the schedule as something you manage, not something you hope for.