What Sets the Timeline for a Business Website Redesign?

A website redesign timeline depends on the agreed scope, content readiness, integrations, review availability and required testing. A new website needs the same planning. Before relying on a launch date, ask what must be ready for work to start and what the team has included in the finish line.

A useful proposal connects its dates to those assumptions. It should show where a missing decision would hold up other work, who can resolve it and what happens if the requirements change. That gives you a practical way to judge the schedule before making plans around it.

Define what the start and finish dates mean

A signed agreement does not necessarily mean design starts that day. The schedule may assume that content, brand files and the required account access are available first. Ask whether the quoted period begins at signing, a kickoff meeting or confirmation that those inputs are ready.

Likewise, a completed preview and a working public website are different milestones. Identify time for review, corrections, launch checks and any agreed post-launch monitoring. If an advertising campaign depends on the site, explain that constraint before the team proposes a date.

Separate active work from elapsed calendar time. A design change may take a short work session but wait for the next available review meeting. A technical issue may need investigation before anyone can estimate the fix. Allow time for decisions and corrections on both sides, with a named person responsible for each.

Page count only tells part of the story

Five service pages that share one approved layout involve different design work from five pages with separate layouts and functions. Both still need their own accurate content and checks. Ask which pages reuse a template, which need unique design and which depend on an external system.

An enquiry form also has a different scope from live appointment scheduling. The latter may involve availability rules, a booking provider and confirmation messages. Those requirements need investigation before they can support a dependable estimate. Access to a provider account alone does not establish that the proposed integration will work.

A worked website redesign plan

Consider a fictional garden-maintenance business replacing an eight-page website: a home page, an about page, a contact page and five service pages sharing one layout. It will keep enquiry-based contact and change some page addresses. The roles and acceptance evidence below are invented to illustrate planning, not a ZXP client project or a promised delivery schedule.

Some rows can overlap when their inputs are stable and the people doing them are available. The writer can complete other service pages while the designer works with approved representative content. The developer can prepare the URL map while layouts are reviewed. But final redirect checks depend on working destination pages, and final acceptance depends on the assembled site. Overlap helps only where it removes waiting from the work that determines launch.

W3C’s accessibility planning guidance recommends assigning responsibilities and evaluating early and regularly. Put that work into design, development and review, as the example does. Leaving every accessibility question until final sign-off can uncover changes that affect already-built pages. The example is a planning aid, not a complete accessibility assessment.

A redesign must account for the existing site

An existing website brings decisions that a new build may not have. Someone must establish which pages and useful content are being retained, changed or removed. If that inventory reveals a missing service page late in the project, it can affect navigation, copy, design and the launch plan.

Where page addresses change, allow for mapping old URLs to appropriate destinations, updating internal links, testing redirects and monitoring after the move. These activities appear in Google’s guidance for site moves with URL changes. They require settled destination decisions. Google also notes that search visibility may fluctuate temporarily during a move, so a launch plan should not promise unchanged rankings or traffic.

What changes when an enquiry form becomes booking?

Suppose the fictional owner asks for live appointment scheduling after approving the enquiry-form design. Before revising the date, the team needs to understand what customers would book: an initial consultation, a site visit or the service itself. Appointment lengths, availability, cancellation rules and the confirmation process must be agreed. The developer then checks whether the proposed provider supports that flow and what setup and access are needed.

That decision affects specific work. The contact page and service-page buttons need revised wording and behaviour. The integration needs configuration and end-to-end tests covering the agreed booking and confirmation process, including relevant accessibility checks. Final acceptance of that customer journey must wait until those tests and any corrections are complete.

Other work may continue. The approved about page, service descriptions and unchanged layout components remain usable if the booking decision does not alter them. URL mapping can continue where destinations are settled. Keeping those tasks moving does not remove the booking work from the path to launch.

The owner can retain enquiries for the initial release and scope booking separately, or include booking now and accept a revised plan once feasibility and effort are understood. Keeping the original date is only a sound option if the remaining scope and required checks still fit. Essential testing should not disappear to make the calendar look unchanged.

Ask for a schedule you can use

Bring your intended launch date, page needs, available content, integrations and review availability to the proposal discussion. Ask which assumptions could change the date and when the team will revisit the estimate. Any revised schedule should explain the affected work and decisions clearly enough for you to choose what matters most.

ZXP offers website design and development. A project brief that makes those inputs visible gives the team a useful starting point for discussing your website.