Typical website rebuild timelines across the UK market
How long does a website rebuild take? Anyone quoting a single number without seeing your site is guessing, so treat everything below as typical market ranges rather than promises. Timelines vary with page count, content readiness, integrations, and above all how quickly decisions get made on the client side. With that hedge stated plainly, rebuilds across the UK market tend to cluster into recognisable bands by project type:
| Project type | Typical UK market timeline | What usually sets the pace |
|---|---|---|
| Small brochure site (up to ~8 pages) | 2 to 4 weeks | Content readiness, single-round feedback |
| Standard service business site (~8 to 25 pages) | 4 to 8 weeks | Copywriting, proof gathering, sign-off speed |
| Content-heavy site (25 to 100+ pages, blog archives) | 8 to 12 weeks | Content migration, redirect mapping |
| E-commerce or booking-driven site | 8 to 16 weeks | Product data, payments, integrations, testing |
| Large or multi-site estate | 3 to 6 months+ | Stakeholders, compliance, phased launches |
Two honest notes on that table. First, the ranges describe elapsed calendar time, not effort: a four-week project might contain two weeks of actual production, with the rest spent waiting on words and approvals. Second, productised rebuilds at fixed scope can land under these ranges precisely because they refuse the things that stretch timelines. That is a trade worth understanding rather than a trick. For how these timelines map to UK price bands and the five-stage process behind them, see our website redesign cost and process guide.
What actually happens during a rebuild, phase by phase
A rebuild that ends well runs through five phases, whatever labels a studio puts on them. Discovery and audit first: understanding what the current site does, what it fails at, and what must survive the move, which is why we start every project with a scored audit rather than a moodboard. Then structure: deciding the pages, the navigation, and the URL map, including which old URLs redirect where. Then design: how each template looks and persuades. Then build: templates coded, content loaded, integrations wired. Finally launch and stabilisation: redirects live, analytics verified, and the first weeks watched for anything the plan missed. Our process page sets out how we run these phases and what happens in each week.
The phases matter for timeline questions because they do not compress equally. Build time is the most predictable of the five. Discovery and structure are where good projects spend generously, because a wrong decision there costs multiples of itself later. The public sector learned this lesson expensively, which is why the GOV.UK service manual insists on a discovery phase before anything gets built at all.
Where the weeks really go: content and decisions, not code
Here is the part most timeline articles skip. On a typical service business rebuild, the coding is days of work. What consumes the calendar is everything the code depends on: the words for each page, the choice of what to claim about each service, the case studies and testimonials that need chasing, the photography that needs taking or finding, and the approvals that need someone senior to sit down and actually approve.
Content is the most reliable bottleneck in the industry, to the point where "waiting on copy" is a standing joke among developers. It is not because writing is slow; it is because writing forces decisions that the business has been comfortably deferring. What exactly do we offer? Who is it for? What do we charge? A rebuild surfaces every one of those questions at once, usually to people whose diaries are already full. The second bottleneck is feedback: three stakeholders with opinions and no deadline can add more weeks than any technical problem. None of this is a criticism of clients. It is a description of where the time goes, so you can budget for it honestly.
Why rebuild projects overrun, and the overruns you can prevent
Overruns cluster around five causes, and almost none of them are build speed. Scope growth: the eight-page site that becomes eighteen pages once everyone sees the designs. Late content: templates finished, pages empty. Feedback drift: rounds of revisions with no owner and no end. Technical archaeology: the old site turns out to have undocumented forms, integrations, or thousands of URLs nobody mentioned. And launch fear: a finished site sitting unlaunched because going live feels riskier than waiting, which it usually is not if redirects and search have been planned properly. That last anxiety is worth taking seriously rather than dismissing: changed URLs handled carelessly do cost search visibility, which is why Google publishes specific guidance on site moves with URL changes, and why redirect mapping belongs in the structure phase, not the launch week.
Notice that every cause on the list except archaeology is preventable before the project starts. Agreed scope in writing, content started before design, one named decision-maker, and a redirect plan owned from day one removes most of the risk. The remaining overruns are the honest kind: genuine discoveries that deserve the extra time.
How to prepare so your rebuild moves faster
If you want the short end of the timeline ranges, the highest-leverage work happens before the kickoff call. Appoint one decision-maker with real authority, and let everyone else be consulted rather than deciding. Start the content early: a rough draft of every page, however imperfect, beats polished copy that arrives in week six. Gather your proof now: testimonials, client names you can use, numbers you can stand behind, because chasing permission mid-project is a classic silent delay. Collect your logins: domain registrar, hosting, analytics, and anything the old site integrates with. And decide what the site must achieve in one sentence, because scope discipline flows from a clear goal.
It also pays to know which project you are actually buying before you brief anyone. If the problems are visual rather than structural, you may need less than a full rebuild, a question we walk through in redesign versus rebuild. A scored audit of your current site settles it with evidence in about a minute, and it doubles as the baseline you will measure the new site against.
Reading timeline promises when you compare quotes
When quotes arrive, the timeline line deserves as much scrutiny as the price. A studio quoting dramatically under the market ranges above is either scoping less than you think, assuming your content is ready when it is not, or planning to be late. Ask three questions of any timeline: what do you need from us and by when, what happens to the date if content is late, and how many feedback rounds are included. Precise answers signal a studio that has shipped enough projects to know where they slow down. Vague reassurance signals the opposite.
Also ask what happens after launch, because a rebuild is not finished the day it goes live. Redirects need verifying, analytics need checking against real traffic, and the first weeks of search data need watching. A studio that budgets stabilisation time is telling you the truth about how rebuilds actually behave; one that ends the schedule on launch day is showing you a timeline built to win the quote. The fastest project is not the one with the shortest number in the proposal. It is the one that only has to be done once.
A useful schedule should also expose dependencies rather than hiding them inside one finish date. You should be able to see when content freezes, who approves design, when integrations are tested, and what must be true before launch. That makes delay visible early enough to manage. It also protects quality, because testing time cannot quietly disappear when an earlier decision takes longer than planned.
Frequently asked questions
Can a website rebuild be done in a week?
A very small site can be rebuilt in days if the content is genuinely ready and one person makes decisions quickly, and some studios sell exactly that as a productised sprint. What compresses is the calendar, not the work: those projects succeed by ruthlessly limiting scope and requiring everything prepared up front. A rushed rebuild with unready content just ships the old confusion in new templates.
What takes the longest in a website rebuild?
Content and decisions, in almost every project. Writing the pages, choosing what to say about each service, gathering proof, and getting sign-off from busy people routinely consume more calendar time than design and development combined. Code is predictable; approvals are not. If you want a shorter project, prepare content early and appoint one decision-maker, because those two moves attack the actual bottleneck.
Why do website rebuild projects overrun?
The recurring causes are scope growing mid-project, content arriving late, feedback loops with too many voices and no deadline, and technical surprises discovered inside the old site, such as undocumented integrations. Almost none of the common causes are build speed. A project that starts with agreed scope, ready content, and a named decision-maker removes most overrun risk before any design work begins.
Should the whole site be rebuilt at once, or in stages?
Both approaches are legitimate. A single cutover suits smaller sites and gets the disruption over in one launch. Staged rebuilds, shipping the most important pages first, suit larger estates because value arrives earlier and lessons from the first pages improve the later ones. What matters more than the approach is that redirects, analytics, and search considerations are planned for whichever launch pattern you choose.