Website Redesign Timeline: Focused, Standard or Enterprise Plan

7 min read ยท 2026-11-11

Your website redesign timeline depends on one decision: a focused, standard or enterprise redesign. For planning, use about 6 to 8 weeks for a focused redesign, 12 to 16 weeks for a standard one and 20 weeks or more for an enterprise one. These are working estimates for a first plan. Adjust them to your own approval speed and scope.

This guide helps you pick the right size before you commit to a date. It then gives you a 12-week plan for a standard redesign, with a buffer week inside the 12 weeks.

The roadmap at a glance

Goal: Launch a redesigned website in 12 weeks, with every phase signed off by one decision maker and one week held back for real blockers. Duration: 12 weeks

  1. Discovery and baseline (Weeks 1-2)

    Agree on what the new site must achieve and record how the current site performs.

    • Write down 3 to 5 business goals and the metric for each one.
    • Export current traffic, conversions and top landing pages.
    • Name the single decision maker and book every review meeting for the 12 weeks.

    Milestone: Goals, baseline report and review calendar approved in writing.

  2. Architecture (Week 3)

    Decide what pages the new site will have.

    • Draft the sitemap and main navigation.
    • List the page templates the design team must produce.
    • Mark each old URL as keep, merge or retire.

    Milestone: Sitemap and template list signed off. Scope is frozen from here.

  3. Content production (Weeks 3-8)

    Write and gather every page so the build never waits on copy.

    • Give every page on the sitemap an owner and a due date.
    • Rewrite priority pages first: home, main product or service pages, pricing, contact.
    • Review content in weekly batches, not all at the end.

    Milestone: All priority page copy approved by the end of week 8.

  4. Design (Weeks 4-6)

    Turn the sitemap into wireframes, then a visual design for every template.

    • Wireframe the home page and each template in week 4.
    • Present one visual direction in week 5, with one round of feedback.
    • Finish all templates and mobile versions in week 6.

    Milestone: Final designs approved, with no open comments.

  5. Build (Weeks 6-9)

    Build the templates on a staging site and load approved content.

    • Build shared components first, then templates in priority order.
    • Load content as each template is ready.
    • Set up analytics, forms and conversion tracking on staging.

    Milestone: Complete staging site with all priority pages and tracking in place.

  6. QA, buffer and launch (Weeks 10-12)

    Test, keep a week in reserve, then go live on a planned day.

    • Week 10: test forms, links, speed, mobile layouts and redirects on staging.
    • Week 11: buffer week. Spend it only on blockers found in QA. If nothing blocks, run the final review early.
    • Week 12: final sign-off, change freeze and launch early in the week.

    Milestone: New site live, redirects working and tracking firing.

Which website redesign timeline fits your project?

Most redesigns that slip were sized wrong at the start. A team approves "a new look", then finds out halfway through that it also needs new pages, rewritten copy and a new platform. Choose the size first, using the three options below.

Verdict. If you change the page structure or rewrite most of the copy, you are doing a standard redesign, even if the brief says "refresh". Plan for 12 weeks and use the upper end of the range if you also change platform. Pick focused only when the URLs and the content stay as they are. Pick enterprise as soon as more than one team has to approve the same pages.

  • Focused, 6 to 8 weeks: same platform, same page structure, a new look for a few key pages. Architecture shrinks to a few days, URLs stay the same, and design and content run in the same weeks.
  • Standard, 12 to 16 weeks: new sitemap, most pages rewritten, one decision maker. You follow the full plan: discovery, architecture, content, design, build, QA, buffer and launch.
  • Enterprise, 20 weeks or more: several teams, regions or product lines, a design system, a large URL inventory or legal review. Discovery gets longer, a design system phase comes before page design, and the launch happens in stages.

Three questions that settle the size

Answer these before you put a launch date in front of anyone.

  • Do the URLs change? If yes, you need a redirect map and SEO checks. That rules out the focused plan.
  • Who writes the copy? If content owners sit in other teams, the content phase gets longer. Size up.
  • How long did your last approval take? If one review took two weeks, add two weeks to every review on the roadmap.

Why content sets the pace

Content is usually what holds the launch back. Developers can build templates with placeholder text, but nobody can launch until real pages exist. That is why content starts in week 3, right after the sitemap, and runs alongside design instead of after it.

Some work cannot overlap. A template is not built before its design is approved, and content is not loaded before it is signed off. Draw these links as arrows on the roadmap so everyone sees what moves when a review slips. The work below can run in parallel.

  • Content (weeks 3 to 8) alongside design (weeks 4 to 6).
  • Component building (from week 6) while the last pages are approved.
  • Tracking setup during the build, not during QA.

Redirects, staging and SEO: keep them short on the timeline

A redesign that changes URLs is partly a migration. On the redesign timeline, it needs only four checkpoints: the URL list in week 3, redirects loaded on staging in the build phase, redirects tested in QA week, and 4 weeks of monitoring after launch. The full redirect map, cutover runbook and post-launch metrics belong in a separate website migration plan, and detailed build and launch steps in a website development plan.

Two timing facts from Google's Search Central documentation on site moves with URL changes belong on the plan. For medium-sized websites, "it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones." Redirects should stay "for as long as possible, generally at least 1 year." Add a reminder to the roadmap one year after launch, so nobody removes them during a cleanup.

What makes a website redesign timeline slip

The causes of delay are rarely technical: slow reviews, scope that grows, content that is not ready, and approved work that gets reopened. You prevent them with how the roadmap is set up.

  • One decision maker per phase. Others comment through that person.
  • Review dates booked in week 1. A review that lands in a busy week pushes everything after it.
  • Written approval at each milestone. Changes to approved work go to a phase 2 list.
  • The buffer week stays protected. It is not extra design time.

Should you launch all at once or in phases?

A single launch suits focused and standard redesigns: one redirect switch, one QA pass, one announcement. A phased launch suits enterprise redesigns, or teams that cannot finish all content in time.

If you phase it, ship first what carries the business: home, main product or service pages and the pages that capture leads or sales. Move archives and low-traffic sections in phase 2. Give each phase its own QA week and its own milestone.

How to present the timeline for approval

People who approve a redesign want three answers: when it launches, what could move that date, and what they need to do. Show the size you chose and why, then the phase milestones, the buffer week and the launch date, each with an owner.

Put the assumptions on one slide. If an assumption breaks, the date moves, and everyone agreed to that in advance. Update the roadmap each week and mark each milestone as done, on track or at risk.

  • Content owners deliver priority pages by the end of week 8.
  • Each review is answered in the booked meeting.
  • Scope is frozen after week 3.
  • Platform and hosting are decided before the build starts.

Common mistakes to avoid

  • Calling it a refresh when the sitemap changes hides the real scope, so size it as a standard redesign.
  • Starting content after design leaves the build waiting on copy, so start it in week 3, right after the sitemap.
  • Letting five people approve each phase stretches every review, so name one decision maker per phase.
  • Skipping the baseline report leaves nothing to judge the result against, so export traffic and conversions in week 1.
  • Spending the buffer week on new ideas leaves no room for real blockers, so keep it for problems found in QA.

Frequently asked questions

How long does a website redesign take?

As a planning estimate, use 6 to 8 weeks for a focused redesign, 12 to 16 weeks for a standard redesign and 20 weeks or more for an enterprise one. Your real timeline depends on scope, who writes the content and how fast reviews are answered.

How do I know if my redesign is focused or standard?

If the URLs and most of the copy stay the same, it is focused. If you change the sitemap, rewrite most pages or change platform, plan it as a standard redesign.

Should the timeline include a buffer?

Yes. Hold back one week inside the plan, after QA and before launch, and use it only for blockers. In the 12-week plan above, that is week 11.

How long should you keep redirects after a redesign?

Google's site move documentation says to keep redirects for as long as possible, generally at least one year. Put that date on the roadmap so nobody removes them early.

Generate this roadmap with AI