The honest answer depends on what redesign means.
Changing a theme and replacing several images can take days. Redesigning an established business website may require customer research, new positioning, a service architecture, original copy, responsive interaction, development, content migration, redirects, integrations, analytics and quality assurance. Both projects may be described as a website redesign, but they do not carry the same responsibility.
For planning, define the workstream and acceptance criteria before discussing the launch date. A date without an approved scope simply moves uncertainty into the final week.
Indicative timeline by scope.
These are planning ranges rather than a North Growth Lab delivery guarantee. Procurement, legal review, photography, translation, accessibility requirements and third-party systems can expand the schedule.
| Scope | Typical duration | What must already be true |
|---|---|---|
| Focused page refresh | 2–4 weeks | Offer and content are stable; platform and integrations remain |
| Small-business redesign | 6–12 weeks | Decision owner is available; content and migration scope are bounded |
| Complex website rebuild | 12–24+ weeks | Multiple services, integrations, content types or approval groups are involved |
A complete redesign moves through seven overlapping stages.
These stages should overlap deliberately, not chaotically. Development can begin on approved page patterns while later content is completed, but building every page before the message and content model are stable creates expensive rework.
- Discovery and current-site inventory: 1–2 weeks.
- Positioning, sitemap and measurement plan: 1–2 weeks.
- Copy and content production: 2–6 weeks.
- UX and visual direction: 2–4 weeks.
- Responsive development and integrations: 3–8 weeks.
- Content and SEO migration: 1–4 weeks.
- Quality assurance, launch and verification: 1–2 weeks.
Build the website rebuild timeline around acceptance gates.
A rebuild adds technical decisions, data movement and cutover risk to the redesign work. The schedule should therefore show what must be true before each stage begins and what evidence allows the team to leave it. Counting design and development weeks without these gates hides the actual critical path.
For a complex rebuild, the twelve-to-twenty-four-plus-week range is not one uninterrupted development block. Content, platform, integrations and migration can overlap, but launch remains dependent on the slowest unresolved item. Record one owner and due date for every gate before promising the public release date.
| Rebuild gate | Evidence required to enter | Acceptance evidence to exit | Common schedule warning |
|---|---|---|---|
| Foundation decision | Current constraints, ownership and roadmap are documented | Approved retain, repair or rebuild decision with explicit scope | A platform is chosen before the current system is inspected |
| Content and URL inventory | Pages, search value, proof and owners are exported | Every useful URL is marked keep, consolidate, replace or redirect | Pages are discovered only after templates are built |
| Representative production path | Content model, real copy and integration responsibilities are approved | One complete page pattern, form delivery and analytics path work end to end | Layouts multiply around placeholder content |
| Migration rehearsal | Staging content, redirect map and test records are available | A sample import, crawl, redirect and event reconciliation passes | The first realistic migration is planned for launch day |
| Launch and rollback | Window, owners, backups, access and rollback triggers are confirmed | Forms, canonicals, redirects, analytics, sitemap and lead delivery pass the go/no-go check | No named person can stop or reverse the release |
| Post-launch verification | Pre-launch search, traffic and lead baselines are saved | Errors, index signals and lead destinations have assigned checks and response thresholds | The project treats deployment as the final milestone |
Content is the most common hidden critical path.
Teams often approve the design schedule while assuming existing copy will be reused. During the project they discover that services have changed, proof is incomplete, subject-matter experts disagree and images do not support the new structure. The design then waits for decisions that were never assigned.
Create a content inventory at the beginning. For every page, name the writer, approver, evidence source and deadline. Decide which content is retained, rewritten, consolidated or removed before development depends on it.
Speed up the project by reducing decision latency.
- Choose one accountable decision owner and a small review group.
- Approve the sitemap and one representative page before multiplying layouts.
- Use real content early instead of designing around placeholder text.
- Provide platform, analytics, domain and integration access during discovery.
- Batch feedback into one prioritized response rather than several conflicting threads.
- Define launch blockers separately from improvements that can follow safely.
Do not compress migration and quality assurance to protect a date.
Redirects, forms, analytics, structured data, responsive behavior, accessibility and lead delivery are part of the product. Cutting their verification to recover time can erase the value of the redesign or leave the business unable to measure it.
If the date is fixed, reduce the first-release scope instead. Launch a smaller complete system with a documented second phase rather than a large unfinished website whose most important customer and search paths are untested.
Website redesign and rebuild timeline FAQ.
How long does a complete website rebuild take?
A focused small-business redesign or rebuild often needs six to twelve weeks when strategy, copy, production development and migration are included. A complex rebuild with several content types, integrations, approval groups or data migrations commonly needs twelve to twenty-four weeks or more. These are planning ranges, not a delivery guarantee.
What usually delays a website rebuild?
The common critical-path delays are unresolved platform or ownership decisions, late content and proof, missing account access, unclear integration responsibilities, redirects prepared after development, and launch acceptance without one accountable owner. Track these dependencies separately from design and development effort.
Can a website rebuild launch in phases?
Yes, when each phase is a complete, measurable customer and operational path with clear URL ownership. A phased release should define which content and integrations move, how old and new systems avoid duplication, what is verified after launch, and when the temporary architecture will be retired.