Website redesign timeline: what affects the schedule

A website redesign timeline is a sequence of decisions as much as a schedule of production work. The studio needs to understand the business before planning the pages. The page structure affects the copy. The copy affects the design. The approved design and platform requirements shape the build. Testing then needs a finished enough experience to inspect.

Some activities can overlap. Others depend on an answer that has not arrived yet. A launch date becomes useful when those dependencies are visible and the people responsible for them know what they need to provide.

Start with the scope and the readiness of your inputs. A date chosen before those are understood is a target to investigate, not a delivery plan. This guide explains what to map so you and a studio can discuss a realistic schedule for the actual website.

Define what needs to be ready at launch

“We need a new website before the conference” can mean several things. Perhaps the firm needs a clear homepage, a service page, and a working inquiry route. Perhaps it also needs a migrated article library, a multilingual structure, booking tools, and new case studies.

List the required launch scope and separate it from later improvements. The goal is not to cut important work arbitrarily. It is to avoid discovering a major requirement after the design has already been approved.

Record the reason for the date. An external event, a contractual requirement, or a service launch may create a real constraint. A preferred month can allow more flexibility. Discuss that distinction before deciding what can fit and what should be staged.

A phase map you can use

Use the following sequence as a planning framework. The studio's proposal should confirm the actual stages, responsibilities, and review points for your project.

1. Understand the business and existing website

Gather the offer, audience, current pages, relevant evidence, and known problems. Inspect how the current site is managed and which accounts, tools, and content will matter to the replacement.

Ready to move on when: The project has an agreed objective, an initial scope, a decision-maker, and enough information to plan the visitor routes. Unknowns are recorded rather than hidden in the schedule.

2. Plan pages and content responsibilities

Define the sitemap and the job of each important page. Decide what will be retained, rewritten, merged, removed, or created. Identify where client evidence belongs and who can approve it.

Ready to move on when: The page list and core content requirements are agreed. Every missing content item has an owner. Integrations and major platform needs are understood well enough to inform the plan.

3. Write and wireframe

Develop the page copy and arrange its information before applying the full visual design. A wireframe is useful for reviewing order, service routes, proof, and the main next step without getting distracted by decorative choices.

Ready to move on when: The structure and substantive content are approved to the level required for design. Any remaining placeholders are explicit and have a delivery plan.

4. Design and build

Apply the identity to the approved structure and develop the website in the agreed platform. Create the page types and content areas the team will use. Connect agreed forms and other tools.

Ready to move on when: The required pages and functionality can be reviewed in the separate project environment. Major content and design changes have been resolved rather than deferred into the final testing stage.

5. Test, approve, and launch

Review the visitor paths, screen sizes, content, inquiry delivery, integrations, and migration requirements. Confirm who can authorize launch and who will handle the immediate follow-up.

Ready to launch when: The agreed critical checks pass, remaining issues have an explicit decision, and the people responsible for publication and handoff are ready.

An original planning map. The stages describe dependencies without assigning the same duration to every website.

Our True Space process follows this broad progression from understanding and planning through copy, design, development, and launch. The detailed schedule belongs to the agreed scope.

The dependencies that commonly change the plan

Content readiness

A page may be waiting for much more than a paragraph. A case study can require a project description, visual assets, permission, and an accurate account of outcomes. A team page may depend on several people approving biographies and photographs.

Make a content register. For each item, record its source, current status, owner, approval requirement, and the stage that needs it. “Copy coming soon” is not enough to show what is blocking the page.

Feedback and decision-making

Review time is part of the project. Agree who will consolidate comments and who can approve the work. Schedule reviews around the real availability of those people.

Ask reviewers to respond to the purpose of the stage. At the sitemap stage, resolve page goals and audience routes. At the visual stage, assess the approved direction in use. Reopening earlier decisions can be reasonable when new information appears, but it affects what comes after them.

Integrations and access

Forms, scheduling, email, analytics, payments, and customer-management tools need requirements and appropriate account access. A tool that already exists may still need investigation before it can be connected to a replacement site.

Identify who owns each account and what the integration must do. Keep credentials out of a shared planning document. Establish access through the agreed method and test the full path rather than checking only that a widget appears.

Migration and existing URLs

A redesign can change more than the visual presentation. Pages may move, combine, or disappear. Content collections may need a new structure. Older links may still be used in search, emails, or client materials.

Inventory current URLs and important content before replacing them. Decide what to preserve and where redirects are needed. Google's site-move guidance explains URL mapping and related migration checks. The plan should account for those tasks; redesign does not guarantee stable rankings or immediate growth.

Each dependency needs an owner and evidence of readiness. A general status such as “nearly done” can conceal very different amounts of work.

A fictional launch-planning example

This consultancy and project are fictional. They illustrate schedule decisions rather than a Studio FLACH delivery commitment.

Harbor Operations Advisory wants to introduce a new service at an industry event. Its existing website explains an older offer, and its articles are spread across several page types. The team initially asks for every page to be rebuilt before the event.

The planning conversation identifies two needs: presenting the new service accurately and preserving the existing useful content. The event requires an approved service page, clear firm context, and an inquiry route. It does not itself require a new layout for every archived article.

Record the work and blockers

The managing partner approves the service description. A consultant supplies a permitted project example. The operations manager owns scheduling access and the receiving inbox. The studio plans the structure, prepares the design and build, and defines the agreed tests.

The project example cannot be published until permission is confirmed. Instead of treating that as a vague delay, the team decides whether another already-approved example can support the launch. The inquiry route remains essential and must be tested before publication.

Choose a staged scope explicitly

The team discusses retaining the existing article structure temporarily and planning its migration as a separate agreed phase. That choice requires checking the platform and URL implications; it is not simply a request to hide unfinished pages.

The important lesson is the decision record: what must launch, what remains in place, what moves later, and who has approved the plan. If the event date cannot accommodate even the essential scope, the team needs to adjust the approach before relying on the date.

Replan when a major input changes

Suppose the consultancy adds a second service midway through copy review. The team asks whether it belongs in the initial launch, which pages it changes, and whether it needs new proof or navigation. The answer affects the plan. Treating it as a small sentence change would hide its consequences.

Launch-readiness checklist

Keep this list beside the project plan and record evidence against each item:

• Content: Required copy, names, contact details, images, and permitted client evidence are approved.
• Visitor paths: Main service, work, and contact routes function on the agreed screen sizes and with keyboard navigation.
• Inquiries: Test submissions reach the responsible destination and give the visitor an appropriate confirmation.
• Tools: Agreed integrations work through the relevant path, not only their visible first screen.
• Migration: Important old URLs have an agreed destination; required redirects are prepared and checked.
• Search settings: Page titles, descriptions, indexing settings, and other agreed launch settings are reviewed.
• Access and handoff: The business can access and manage the agreed content areas and understands who handles follow-up issues.

Record the check, its evidence, and the person responsible. The list is a planning aid and should be adapted to the agreed website.

Ask for a schedule with assumptions attached

When comparing a website redesign timeline, ask what scope the estimate assumes, which client inputs it depends on, where approval happens, and how changes are handled. A single number without those conditions is difficult to evaluate.

Keep the plan current as decisions are made. If an input is late, identify which next stage it affects. If new work appears, agree its effect on scope and timing. That makes the schedule a shared working tool.

Explore True Space if your website needs a clearer structure and a coordinated redesign. Bring the launch reason, required scope, and the current state of your content. Those give us a useful starting point for discussing a realistic plan.