A website redesign timeline depends on decision readiness, content, page systems, CMS, integrations, migration, review cycles and launch ownership rather than page count alone.
Build the timeline from dependencies and decision owners. Content, integrations and migration can run in parallel with design only when responsibilities and approval dates are explicit.
The schedule depends on the client more than the supplier
This is uncomfortable but checkable: in most delayed projects the supplier was waiting rather than working. Waiting for copy, for photography, for a decision, for access to the domain. Design and build effort is reasonably predictable. What is not predictable is how quickly an organisation supplies material and makes decisions.
- Supplier effort: predictable and plannable.
- Client material and decisions: the usual cause of slippage.
- An honest schedule carries dates for both sides, not only the supplier.
Discovery reduces later rework
Confirm goals, audiences, routes, content readiness, constraints and evidence before detailed design. The purpose is to make decisions visible, not to add meetings. Skipping this looks like saving a week and usually costs several, because the changes surface at the stage where they are most expensive to make.
- An inventory of current pages and their performance.
- Agreement on what stays, what merges and what goes.
- A list of integrations with a named owner for each.
Content and design should overlap deliberately
Real content should shape wireframes and components, while design can reveal missing content requirements. Waiting until development for final page purpose creates avoidable change. Designing on placeholder text nearly always leads to redesign, because real sentences are rarely the length invented in a mockup.
- Final copy for the most important template first, not for everything at once.
- One approved pattern before scaling to further templates.
- Clear marking of which text is final and which is a draft.
Development includes systems and states
Templates, components, CMS, responsive behavior, forms and integrations all need production-like content and testing. A visually complete desktop page is not a completed implementation. The states that get skipped are the awkward ones, and those are exactly the states real content produces.
- Empty, long and missing content states.
- Form success, failure and validation behaviour.
- Responsive order on narrow screens.
- Keyboard access and visible focus.
What actually extends a timeline
The causes are repetitive and nearly all can be removed before work begins. They are worth discussing at the first meeting rather than discovering halfway through.
- Copy assumed ready that is in fact written during the project.
- Feedback gathered from several people in parallel rather than one decision owner.
- An integration discovered at build rather than at planning.
- Missing access to the domain, hosting or analytics.
- New ideas added after the design was approved.
Launch requires a separate control window
Reserve time for redirects, domains, analytics, forms, indexing files, backups and acceptance checks. Avoid making launch the same moment the final page is approved. Publication is a phase rather than a moment: some problems only appear on the live site under real traffic.
- Dedicated time for redirects and their verification.
- Forms tested by real submission, not visual inspection.
- Analytics and indexing checked after publication.
- Reserved capacity for fixes in the first weeks.
Practical decision checklist
- Name one decision owner with final say.
- Map dependencies before choosing dates.
- Prepare copy and imagery before design starts.
- Gather access credentials early.
- Reserve integration and migration QA.
- Keep a post-launch monitoring period.
Frequently asked questions
How long does a website redesign take?
There is no universal duration. The answer depends on scope, readiness, approval speed and technical responsibilities.
What usually delays a redesign?
Unresolved content, unclear decision ownership, late integration access and expanding scope commonly affect timelines.
Can design and development happen together?
Yes, when the team agrees which systems are stable enough to build and how later changes are controlled.
Can a bigger budget shorten the schedule?
Only partly. More people cannot shorten the wait for your copy or your decisions. Preparing material in advance and appointing a single decision owner does.
What if the deadline is fixed?
Narrow the scope rather than compressing the phases. Launching a smaller complete site on time is safer than shipping on schedule with untested redirects.

