Website Redesign Process and Timeline: 7 Phases, How Long Each Takes, What the Client Prepares, Why Projects Slip, and a 90-Day Post-Launch Plan (2026)

The first question after deciding on a website redesign is "When can we launch?" Agencies answer "It depends", and the plan stays vague.

Timelines are hard to read because the long part is waiting for decisions and materials: copy is late, a decision-maker changes direction, nobody can find the hosting login. That waiting is not in the agency's estimate.

This article splits a redesign into seven phases and covers the time range, deliverables, client and agency roles, and decisions for each. It then looks at why projects slip and how to plan the first 90 days after launch. Whether to redesign at all is covered in 10 Signs You Need a Website Redesign, costs in Website Redesign Cost and How to Read a Quote, URL changes in Website Migration SEO, and CMS changes in Should You Leave WordPress?.

Main sources for this article

• Google Search Central, "Site moves with URL changes" (updated 20 August 2026), plus its guidance on the Change of Address tool and noindex
• The phase definitions in the GOV.UK Service Manual (discovery, alpha, beta, live)
• Nielsen Norman Group articles on usability testing, content audits and tree testing
• W3C's WCAG 2.2 and evaluation guidance, and the European Accessibility Act (Directive (EU) 2019/882)
• The McKinsey and University of Oxford study of more than 5,400 IT projects (2012)

1. The phases of a website redesign

Seven phases and 90 days after launch

Agencies name the steps differently, but the work follows much the same path. This article uses seven phases and a post-launch period.

The GOV.UK Service Manual splits service development into discovery, alpha, beta, live and retirement. A redesign is smaller, but the ideas carry over: research before building, test before going live, keep improving afterwards.

The right-hand column is a rough mapping. GOV.UK has larger public services in mind, so borrow the purpose of each stage rather than the names.

A Gantt chart for a medium-sized site

Figure 1 lays out the phases by week for a company site with 20–60 pages in Japanese and English, contact forms and a simple CMS. Phases normally overlap, and when a decision stalls in an overlap, the whole schedule stretches.

Here, launch comes after about 20 weeks (five months). Only about half is work the agency can do alone; the rest includes waiting for client decisions, copy and reviews.

2. How long a website redesign takes

Timeline by project size

There are no official statistics for redesign timelines. The table shows how scope changes the duration. Costs are covered in Website Redesign Cost and How to Read a Quote.

Each step up in size roughly doubles the duration, because more people and more decisions are involved, not just more pages. Two languages mean two sets of reviewers; integrations mean working around another team's calendar.

How the time is split across phases

The split across phases follows a pattern whatever the size. The table shows weeks per phase for a small and a medium project.

Because phases overlap, the total is shorter than the sum. The column to watch is the last one: the client workload peaks in phases 2 and 3. Whether the client can free up time then decides the overall timeline.

3. Phase 1: Discovery

Write the goal in one sentence

The first phase is about finding out, not making. GOV.UK says not to start building during discovery and that there is no set length, though around 4 to 8 weeks is typical. For a company website, 2 to 4 weeks is often enough.

Start by writing the goal in one sentence. "The site looks old" gives you nothing to decide against later. Write something that tells you what success looks like, such as "double enquiries from Europe from 10 to 20 a month" or "fewer people dropping out between the careers page and the application form".

Save your current data

To judge whether the new site is better, you need pre-launch figures, and data does not keep forever. Google Search Console's performance data covers the last 16 months; anything older must be exported and stored yourself. In Google Analytics 4, retention for the event-level data used in explorations is set to 2 or 14 months.

Take a content inventory

Nielsen Norman Group recommends separating a content inventory (a list of everything) from a content audit (an assessment of its quality). Crawlers and CMS exports can automate the inventory; people review each item in the audit and mark it keep, update or remove.

The same article advises against trying to do everything at once: timebox the work, for example to six weeks, and start with the most-used content. On a site with hundreds of pages, begin with the top pages by traffic and the pages that lead to enquiries, so you can feed into the phase 3 content plan quickly.

4. Phase 2: Requirements

What to decide

Requirements decide what will and will not be built. They become the basis for the quote and the schedule. List quality standards as well as features.

Write quality standards as numbers

"A fast site" or "a site anyone can use" cannot be tested before launch. Write standards as numbers or named standards.

For speed, use Google's Core Web Vitals thresholds. web.dev rates a page as good at the 75th percentile of users when LCP (main content displayed) is 2.5 seconds or less, INP (response to input) 200 milliseconds or less and CLS (layout shift) 0.1 or less. web.dev also recommends setting a performance budget, such as limits on image weight and script size, early in the project to avoid backtracking later.

For accessibility, the usual benchmark is level AA of W3C's WCAG 2.2 (published 5 October 2023, updated 12 December 2024). If you sell services such as e-commerce to EU consumers, the European Accessibility Act (EAA, Directive (EU) 2019/882) has applied since 28 June 2025. Services provided by microenterprises, with fewer than 10 staff and annual turnover or balance sheet total of €2 million or less, are excluded. Check whether you are covered during requirements.

Write requirements and schedule together

Once requirements are set, the agency proposes a schedule. Check that it lists the client's own tasks and deadlines. A schedule showing only agency work has not allowed for waiting on copy and approvals.

Requirements end with the first decision gate ("requirements signed off", section 12). Scope is fixed here, and both sides agree that anything added later is handled as a change.

5. Phase 3: Information architecture and content

Structure and navigation

Information architecture (IA) decides how pages are grouped, ordered and named. Copying the old structure often leaves an outdated org chart in the menu. Rebuild it around what visitors look for: services, prices, case studies, contact.

Nielsen Norman Group describes tree testing, in which participants try to find things in a text-only version of a proposed menu. It needs no design or copy, and NN/g recommends it at the start of a redesign to benchmark the current structure, after a card sort to check the new one, and before content and layouts are created.

Decide the URL policy

The structure determines the new URLs. If URLs change, start the redirect map (old URL to new URL) in this phase. How to build it and which status codes to use are covered in Website Migration SEO; here we only place it on the schedule.

Plan the content

Copy is the task most likely to slip. Make a table per page of who writes, who reviews and the deadline. Reused, rewritten and new pages take very different amounts of time.

Start translation only once the source copy is final. Translating while the Japanese copy is still changing means translating twice. This queue is the main reason bilingual sites take longer.

6. Phase 4: Design

From wireframes to visual design

Design starts with wireframes that fix where information goes, then moves to colour, type and imagery. Starting with visuals means time spent debating colour, and layout problems found late.

Test small and repeat

In a 2000 article, Jakob Nielsen of Nielsen Norman Group wrote that testing with five users finds about 85% of usability problems, and that three rounds of five, with fixes between them, beat one round of fifteen. In a redesign, one test at wireframe or prototype stage and one after the build go a long way towards avoiding major rework after launch.

Test with people close to your real customers, not staff. Have European readers test pages aimed at Europe. A structure that seems clear to a Japanese team will not necessarily read the same way to local visitors.

7. Phase 5: Build and content entry

Keep staging out of search

The build happens on a staging environment separate from production. Two common accidents: staging appears in search results, and the fix for that is carried over to the live site.

Google recommends noindex for pages that should not appear in search, but warns that if robots.txt blocks crawling, Google cannot see the noindex rule, and the page can still appear if other sites link to it. The reliable approach is to restrict access to staging, for example with basic authentication.

Once the CMS is ready, copy and images go in. Entering content in-house doubles as training for later updates but takes longer. For CMS migrations, see Should You Leave WordPress?.

8. Phase 6: Testing and launch preparation

What to test

Testing has two layers: the agency's internal QA and the client's acceptance testing. The client tests against the standards in the requirements. Anything not written there cannot be passed or failed.

W3C says accessibility problems are easier and cheaper to fix the earlier and more often you evaluate during design and development. No tool alone can tell you whether a site conforms; human review and involving users with disabilities make the evaluation sound.

Before launch day

Finish the switchover preparation before the date. For a move without URL changes, Google recommends lowering the DNS TTL about a week before, and keeping the old server until its traffic reaches zero.

Finally, hold the fourth decision gate, go/no-go (section 12). If serious defects remain, this is where the launch date moves.

9. Phase 7: Launch day

Running the day

Launch early in a working week, when people can respond for several days in a row. Avoid Friday afternoons and the days before long holidays. Put the day's tasks in a table with times and owners.

Notifying Google

For moves with URL changes, Google's steps include turning on the redirects, submitting the new sitemap and, for a domain change, using the Change of Address tool in Search Console, whose effect lasts 180 days after you start. Details are in Website Migration SEO.

10. Roles: client and agency

Who does what

Many delays come from tasks nobody owns: copy, photos, domains and legal wording that each side assumes the other is handling.

How much client time it takes

The client needs at least two roles: a day-to-day contact, who gathers internal views and talks to the agency, and a decision-maker, who makes the final call at the four gates in section 12.

These are estimates from DevNJ's experience. If the contact has no time, answers are late and the project stretches accordingly. Reducing the contact's other duties for the duration is one of the most effective fixes.

11. What the client needs to prepare

Checklist with deadlines

Here is what the client prepares, in the order it is needed. Account access and copy are the items most likely to stall a phase.

12. When decisions are made

Four gates

A redesign involves many decisions, but the ones that are expensive to reverse come down to four. Place each at a phase boundary, and set the date and the decision-maker at the start.

Three conditions for gates to work

Setting dates is not enough. Three things need to be in place.

1. The decision-maker is involved from the start. An executive who first sees the work at the last gate can reopen every earlier decision.
2. Material arrives before the meeting. Otherwise nobody can decide in the room.
3. Decisions are written down on one dated page, so "nobody told me" cannot follow.

13. Why redesign projects slip, and what to do

What a study of large IT projects shows

In 2012, McKinsey and the University of Oxford studied more than 5,400 IT projects. Large ones, with initial budgets above $15 million, ran on average 45% over budget and 7% over time, and delivered 56% less value than predicted. A company website redesign is far smaller, so these figures do not transfer directly.

The lesson is that drifting from the goal costs more than lateness. Cutting scope to hit a date can remove the parts that served the goal. When you cut, choose against the one-sentence goal from phase 1.

Common causes of delay

The table lists frequent causes, warning signs, fixes and typical delay. The delay ranges are estimates from DevNJ's experience.

Put holidays and busy periods in the plan

When people in Japan and Europe are involved, add both sides' holidays and busy periods to the calendar at the start. Japan's fiscal year-end, Golden Week, Obon and New Year, and Europe's July–August summer holidays and the Christmas to New Year period are when reviews and decisions tend to stall.

14. The first 90 days after launch

Some turbulence is normal

Search traffic can fluctuate after launch. For a move with URL changes, Google says new URLs can take a few weeks or more to replace old ones on a medium-sized site, longer on large ones, and advises keeping redirects for at least a year.

Even for a server-only move, Google calls a temporary drop in crawl rate normal; it usually recovers within days. Do not restructure on the first few days' numbers.

What to watch, and when

For monitoring after a move, Google suggests using the Sitemaps report to track indexing of old and new URLs, the indexing report to confirm the old site declining and the new one growing, the search queries report to see impressions and clicks moving to new URLs, and server logs to spot unexpected errors. The table assigns these to time windows.

To avoid seasonal effects, compare with the same period last year or with periods containing the same weekdays. Search Console keeps 16 months of data, so line up your post-launch figures with the data you exported before launch to compare year on year.

What to decide at 90 days

GOV.UK describes the live phase as running a service sustainably while improving it, based on user research and reviewed against the success measures set before going live.

For a redesign, deciding three things at day 90 keeps improvement going.

15. What changes between Japan and Europe

Different working habits

For sites aimed at both Japan and Europe, scheduling habits differ too. Treat these as different conditions, not better or worse, and it becomes easier to align expectations on both sides.

Decide early on bilingual sites

For a bilingual site, decide in phase 3 the URL pattern for each language (for example a /en/ folder), how to handle pages that exist in only one language, and who reviews translations. Changing the language structure after launch means changing URLs, which is as much work as another site move.

16. Worked examples (fictional)

The three companies below are fictional and illustrate how scheduling changes with circumstances.

Case A: Japanese manufacturer expanding English pages

Machine-parts maker A has 40 Japanese and 8 English pages and wants 40 in both to win European distributors. With 32 new English pages, copy and translation set the timeline. The key is naming the European reviewer, and checking their summer holiday, during requirements.

Case B: Japanese food shop in the Netherlands adding e-commerce

Shop B in The Hague wants to add e-commerce to a five-page site and sell to EU consumers, so it checks the European Accessibility Act during requirements. With fewer than 10 staff and turnover under the threshold it may be excluded, but building to WCAG 2.2 AA anyway is a reasonable choice.

Case C: Japanese service company with a fixed launch date

Company C must launch in three months for a new service. Medium scope will not fit, so it launches with 10 key pages and adds the rest within 90 days. The redirect map and baseline data are not cut.

17. Checklist

Before you start

• The goal is written in one sentence, with a success metric and current figures
• A decision-maker and a day-to-day contact are named, and the contact has time freed up
• Search Console and analytics data are exported and saved
• Access to hosting, domain and CMS is collected
• Both sides' holidays and busy periods are in the calendar

During the project

• Dates and decision-makers are set for the four gates
• Speed and accessibility standards are in the requirements as numbers or named standards
• Content owners and deadlines are in a per-page table
• Translation starts only after copy is final
• Staging has access restrictions
• The redirect map is drafted and redirect testing is scheduled

Launch and after

• Launch is early in the week, with people available for several days
• DNS TTL was lowered about a week before
• noindex and authentication were confirmed removed on launch day
• Checks are scheduled for week 1 and days 30, 60 and 90
• The maintenance contract says redirects stay for at least a year

Summary

• Think of a redesign as seven phases (discovery, requirements, IA and content, design, build, testing, launch) plus 90 days after launch.
• Time to launch is roughly 1–4 weeks for a partial fix, 2–3 months for a small site, 3–6 months for a medium site and 6 months or more for a large one.
• Client workload peaks in requirements and IA/content. Whether the contact has time decides the timeline.
• Set dates and decision-makers up front for the four gates: requirements, structure and content, design, go/no-go.
• Delays cluster around late copy, late decision-makers and scope creep. When cutting scope, choose against the one-sentence goal.
• After launch, allow for Google's few weeks or more on a medium-sized site, and compare against your saved pre-launch figures at 30, 60 and 90 days.

Sources

Google (search and analytics)

• Site moves with URL changes — Google Search Central: move steps, timing, redirects, monitoring (updated 20 Aug 2026)
• Site moves without URL changes — Google Search Central: DNS TTL, old server, crawl rate
• Block search indexing with noindex — Google Search Central: noindex and robots.txt
• Change of Address tool — Search Console Help: 180-day forwarding
• Debugging drops in Google Search traffic — Google Search Central: 16-month comparison, data export
• Introducing the new Search Console — Google Search Central Blog: 16 months of data
• Data retention — Google Analytics Help: GA4 retention of 2 or 14 months

Performance and accessibility

• Web Vitals — web.dev: LCP, INP, CLS thresholds
• Performance budgets 101 — web.dev: setting budgets early
• WCAG 2 Overview — W3C WAI: WCAG 2.2 dates and levels
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C: success criteria
• Evaluating Web Accessibility Overview — W3C WAI: evaluate early; tools are not enough
• Directive (EU) 2019/882 — EUR-Lex: EAA text, dates, microenterprise exemption
• European accessibility act — European Commission: scope of the EAA

Process and user research

• Agile delivery — GOV.UK Service Manual: the phases
• How the discovery phase works — GOV.UK Service Manual: around 4 to 8 weeks
• How the alpha phase works — GOV.UK Service Manual: 6 to 8 weeks
• How the beta phase works — GOV.UK Service Manual: private and public beta
• How the live phase works — GOV.UK Service Manual: improving after launch
• Why You Only Need to Test with 5 Users — Nielsen Norman Group: five users, about 85% (2000)
• Content Inventory and Auditing 101 — Nielsen Norman Group: inventory and audit
• Tree Testing — Nielsen Norman Group: testing structure
• Delivering large-scale IT projects on time, on budget, and on value — McKinsey: 5,400+ projects, 45/7/56% (2012)

All sources were checked on 25 October 2026. Timeline and effort estimates are based on DevNJ project plans and are not official statistics. Rules and figures change, so check each link for the latest information before you plan.