How Long Does a Website Redesign Take? Real Timelines by Size

A marketing lead has told her CEO the new site goes live before the spring trade show. The quote said six weeks. It is now week nine. Design was signed off in week three, and the build has sat on a staging server for a month. Her website redesign timeline did not slip in Figma or in code. It slipped in a shared folder, where the services copy is still waiting on comments from three people.

Not a design problem. Not a developer problem. Content delays and late decisions, and you can see both coming on day one. It’s why my small-site quote says 2 to 3 weeks from content, not 2 to 3 weeks from signing.

This post gives you a realistic website redesign timeline for each site size and platform, the terms I quote at Jackai Agency, and the specific things that push a launch date. For the money side, my page on what a website redesign costs in 2026 has the prices. This one is about weeks.

How long does a website redesign take?

A five-page site takes 2 to 3 weeks of build once the content is in, a marketing site of 8 to 15 pages takes 4 to 6 weeks, and a single landing page takes 1 to 2 weeks. Those are the terms on my published price table, and each one assumes the words, images and sign-offs arrive when the plan says they will.

How long does a website redesign take from the day you decide to do it? Longer, because the build is only the middle, and if you start with my Website Audit, that adds one week. Then add whatever time your team needs to write and approve copy, unless that writing runs alongside design instead of after it.

I also run user and audience research before any design starts, on every project. Ask where research sits in any quote you get, and count it when you work back from your date.

Here’s a worked example: you need a 10-page marketing site, your team writes the copy, the audit takes a week, and design and build take 4 to 6 weeks. Say the copy takes your team three weeks. If writing starts on day one, it runs next to design and costs you nothing on the calendar. If writing starts after design sign-off, those three weeks land on top of the build and your launch date moves by three weeks.

Same site. Same team. Same budget. One decision about when the writing starts changes the website redesign timeline by close to a month.

A website redesign timeline by site size and platform

The table sets out the website redesign timeline I quote by size. The build weeks come from my price table. The other two columns are what to watch, because they decide whether the build weeks hold.

Notice what the platform does and doesn’t change. On my price table, a five-page site costs less in Framer than in WordPress, but the weeks are the same: 2 to 3 weeks from content on both. On a small site, the platform changes the price more than the website redesign timeline.

It starts to matter on bigger builds, such as the Snappy Kraken HubSpot CMS project for a B2B FinTech SaaS that serves financial advisors, where I took 6 responsive pages from Figma to production in 3 weeks. Part of that build was HubL templates and a bound design system, so the marketing team could edit pages afterwards without a designer. That module work is build time you spend once and get back every time someone edits a page.

Stores run on a different clock again, because a catalogue is data work, and data work grows with the number of products, not the number of pages. For S.T. Dupont Vancouver, a luxury retailer and authorized S.T. Dupont dealer, I moved 290 products from Wix to WooCommerce with taxonomy, pricing and product copy intact. For Cubanbest, a Vancouver premium retailer, the move was 638 SKUs. Neither catalogue cared how many pages the site had.

Changing platform also adds a redirect map for every URL that moves. That’s its own piece of work, and my page on website migration without losing search traffic covers it.

When does the clock on a redesign actually start?

Every website redesign timeline runs on one of three clocks, and vendors don’t always say which. One starts when you sign, one when the design is approved, and one when the content is delivered. A quote of three weeks and a project of three months can describe the same job, depending on which clock you read.

The Snappy Kraken number above is a build clock, 3 weeks from Figma to production, because the design existed before those three weeks began. My small-site quote is a build clock too, counted from the day content arrives, so when you ask a vendor “How long does a website redesign take?”, ask which clock the answer uses.

Before you compare two quotes, ask each vendor three things:

• Which event starts the clock? Signing, design approval or content delivery.
• What pauses it? Most quotes pause while waiting on client feedback or content.
• What counts as done? Live on your domain, or handed over on a staging server.

A vendor who answers all three in one sentence each is giving you a real plan. A vendor who answers with a total number of weeks is giving you a hope.

Why content delays move the launch date more than design does

Design and code are done by people whose job that week is your site. Content is written by people whose job that week is everything else, like a head of sales writing the services page between client calls. That’s where content delays begin. If one person writes all the copy, that person’s calendar is your website redesign timeline.

The research on time estimates explains why everyone is surprised by it. Buehler, Griffin and Ross found that people underestimated how long their own tasks would take, because they focused on the plan for this task and not on how similar tasks had gone before (Buehler et al., 1994). When observers predicted other people’s completion times, they leaned the other way and gave longer estimates.

That fits what I see on my projects: the estimate for writing the copy tends to be optimistic, and my own estimate for the build can be optimistic too. A review of studies on time predictions by Halkjelsvik and Jørgensen found underestimation was reported more often than overestimation in engineering and management studies (Halkjelsvik and Jørgensen, 2012).

Content delays also compound in a way design delays don’t. I can’t set the final layout of a services page until I know how long the copy is. A heading that fits on one line in a placeholder can wrap to three lines on a phone with the real words. So late copy doesn’t only delay its own page, because it also reopens design work that was already approved.

The fix isn’t to write faster but to start the writing earlier and put the content delays on the plan where everyone can see them, instead of finding them in week six.

The other five things that stretch a website redesign timeline

Content delays are the biggest risk to a website redesign timeline. These are the next five I plan for, with the person who usually owns each one.

1. A decision-maker who arrives late: someone senior sees the site for the first time in week five and wants a different homepage. Owner: whoever runs the project on your side, who needs that person in the first review.
2. Pages added after kickoff: a new service, a new audience or a careers page each adds copy, design and testing.
3. Access: logins for the domain registrar, hosting, CRM and analytics. A launch can wait days on one password held by someone who left the company.
4. Integrations: forms that feed a CRM, booking tools and payment processors each need testing with real accounts, not test data alone.
5. Open-ended feedback: my standard terms include two revision rounds per phase, because a project without a limit on rounds has no end date.

The risk in number one grows with every audience the site serves. For W Communications, a Seattle communications and PR firm, four audiences arrived at one homepage: media, clients, event bookers and readers. The rebuild gave each audience its own path. Four paths means four sets of copy to approve, so count reviewers per audience, not per site.

Number two deserves more weight than it gets. In a survey study of software projects, Zowghi and Nurmuliani found that changing requirements had a significant effect on schedule overrun and cost overrun. Frequent contact between users and developers was one of the factors that affected how stable the requirements stayed (Zowghi and Nurmuliani, 2002).

There’s one more reason to write these down at kickoff. When Jørgensen and Moløkken-Østvold studied why software estimates went wrong, people tended to name factors outside their own control as the cause, and credited their own skill when estimates were right (Jørgensen and Moløkken-Østvold, 2004). A list of delay causes with an owner on each saves both sides an argument later.

How to build a website redesign timeline that holds

You don’t need project software for this, just a launch date, a page list and one afternoon. Each step below comes with a reason from the research on time estimates.

1. Start at the launch date and plan backward. In four experiments, people who planned from the end goal backward gave longer completion estimates than people who planned forward, and less biased ones in the study that tracked real finish times (Wiese, Buehler and Griffin, 2016).
2. Break the project into page-level tasks. “Write the copy” is one task that hides twenty. People who unpacked a task into its parts gave longer estimates, less biased in two of the experiments, and the effect grew with how many parts the task had (Kruger and Evans, 2004).
3. Put a name and a date on every page’s copy. Plans that tie a specific situation to a specific action help people follow through on goals, according to Gollwitzer’s research on implementation intentions (Gollwitzer, 1999). “The head of sales sends the services copy on 12 November” turns content delays into a date someone can chase. “Marketing will handle copy” doesn’t.
4. Check your last project’s real duration. In the fourth study by Buehler and colleagues, the optimistic bias went away when people were told to connect their prediction to how similar past tasks had gone. If your last brochure took five weeks to approve, plan for five.
5. Freeze the page list at kickoff. New ideas go on a phase-two list with a date, so nothing is lost and nothing slips in.

Here’s a website redesign timeline built backward on a real calendar. Say your launch date is Monday 1 February 2027 and you need a 10-page marketing site. Keep the week of 25 January for launch checks, which means a 4 to 6 week build has to start by 14 December at the latest.

But the weeks of 21 and 28 December usually lose most reviewers to holidays, so count them as half weeks. That pulls the latest safe build start back to 7 December. Starting at the end of November gives you one spare week, which is the room you’ll need for content delays.

The safest plan has the copy written and approved before the build starts, which means writing through November and an audit in the first week of November. That puts kickoff in the last week of October 2026, 14 weeks before a launch you might have pictured as a six-week job.

What to have ready on kickoff day

• The page list, with one owner and one due date for each page’s copy.
• Existing copy you plan to keep, marked as keep, rewrite or cut.
• Brand files: logo, fonts, photos and any brand guide.
• Logins for the domain registrar, hosting, CRM and analytics.
• Every person who signs off, by name, and which pages each one reviews.
• The hard date and the reason for it, so everyone knows which pages must make it and which can wait.

What a one-week or three-week launch actually needs

Fast launches happen, but they aren’t websites in the usual sense. The fastest launches in my case studies were narrow builds with a single job, and that’s what made them fast.

For Copy Chief, a copywriting education business, I built and launched the World of Financial Copy promo funnel in one week on ClickFunnels, ThriveCart and Keap: 56 orders, 4% conversion rate. The Crossroads Summit event funnel launched in 14 days and returned 10x on event ticket sales.

A funnel is one path with one decision at the end. No menu to agree on, no about page, no services pages for five people to approve. Fewer pages means fewer content delays. The Snappy Kraken build was larger, 6 pages in 3 weeks, but its clock started with the design already in Figma.

If your launch date is a week away, shrink the job to fit the week. A one-week website redesign timeline only works for one page that carries the decision, such as a booking page, an event page or a single offer. Launch that, and let the rest of the site follow on the normal schedule.

What I would not cut to hit a launch date

When a website redesign timeline runs late and the date is fixed, something gets cut. Cut pages, not checks. These are the checks I keep even when the launch date is close:

• Payment and checkout testing: on the S.T. Dupont Vancouver store, I connected Clover POS and tested the payment path end to end at checkout before launch. A store that can’t take money isn’t launched.
• Redirects for every moved URL: skipping them trades a launch date for lost search traffic on every old link.
• Lead source on every form: the form should carry where the lead came from into your CRM. My lead attribution method shows how that’s wired.
• Every template on a phone: real copy at real width, checked before the domain points at the new site.

What I would cut: secondary pages, old blog posts that nobody reads, and anything on the phase-two list. A site can launch with five strong pages and add three more a month later. It can’t launch with a broken form and earn back the leads it lost.

Want a dated plan before you sign anything?

Bring your launch date and your page list. On a 30-minute call with me, we can check your website redesign timeline against the list and see which pages fit and which belong in phase two. Every project gets a fixed quote, two revision rounds per phase, and a site, domain and hosting in your name. Book a call with Joshua, and I’ll reply within one business day.

Sources

Peer-reviewed research

• Buehler, R., Griffin, D., and Ross, M. (1994). Exploring the “planning fallacy”: Why people underestimate their task completion times. Journal of Personality and Social Psychology, 67(3), 366 to 381. https://doi.org/10.1037/0022-3514.67.3.366
• Gollwitzer, P. M. (1999). Implementation intentions: Strong effects of simple plans. American Psychologist, 54(7), 493 to 503. https://doi.org/10.1037/0003-066X.54.7.493
• Halkjelsvik, T., and Jørgensen, M. (2012). From origami to software development: A review of studies on judgment-based predictions of performance time. Psychological Bulletin, 138(2), 238 to 271. https://doi.org/10.1037/a0025996
• Jørgensen, M., and Moløkken-Østvold, K. (2004). Reasons for software effort estimation error: Impact of respondent role, information collection approach, and data analysis method. IEEE Transactions on Software Engineering, 30(12), 993 to 1007. https://doi.org/10.1109/TSE.2004.103
• Kruger, J., and Evans, M. (2004). If you don’t want to be late, enumerate: Unpacking reduces the planning fallacy. Journal of Experimental Social Psychology, 40(5), 586 to 598. https://doi.org/10.1016/j.jesp.2003.11.001
• Wiese, J., Buehler, R., and Griffin, D. (2016). Backward planning: Effects of planning direction on predictions of task completion time. Judgment and Decision Making, 11(2), 147 to 167. https://doi.org/10.1017/s1930297500007269
• Zowghi, D., and Nurmuliani, N. (2002). A study of the impact of requirements volatility on software project performance. Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC 2002), IEEE, 3 to 11. https://doi.org/10.1109/APSEC.2002.1182970