How to Plan a Website Redesign Project
The Problem: Redesigns Expand Until They Fail
Website redesigns are the project type most likely to drag on for months past the original deadline. The reason is almost always the same: scope wasn't locked before work started. The client approved a wireframe, then wanted changes after design, then more changes after development, and now the project is four months in and the launch date keeps moving.
The second most common failure is underestimating dependencies. A new design can't be built until the copy is approved. Copy can't be approved until the sitemap is final. The sitemap depends on a content audit that nobody scheduled. These chains of dependencies are invisible until they're blocking you — unless you mapped them out at the start.
A clear project plan with locked phases and explicit dependencies is what separates redesigns that ship from ones that drag. Put the scope, timeline, and dependencies into a Gantt chart before anyone opens a design file. gantt-chart.io makes this fast enough that there's no excuse to skip it, even on smaller projects.
Prerequisites
- A defined scope: what pages, what features, what integrations
- A launch deadline or target window
- Clarity on who approves at each stage (client stakeholder, internal lead, or both)
- Content ownership assigned — who writes it, who approves it, by when
Template: Website Redesign Project
Phase 1: Discovery and Scope Lock
- [ ] Content audit: catalog existing pages, identify what's kept, cut, or rewritten
- [ ] Sitemap finalized and approved by client
- [ ] Technical requirements documented (CMS, integrations, SEO redirects, hosting)
- [ ] Design brief completed: brand guidelines, reference sites, must-have and must-avoid
- [ ] Scope document signed before any design begins
Phase 2: Information Architecture and Wireframes
- [ ] Wireframes for key page templates (homepage, inner page, landing page)
- [ ] Navigation structure confirmed
- [ ] Client review of wireframes — gather all structural feedback here
- [ ] Wireframes approved in writing before visual design starts
- [ ] Content outline per page (structure, not final copy)
Phase 3: Visual Design
- [ ] Homepage design (desktop + mobile)
- [ ] Inner page template design
- [ ] Component library: buttons, forms, cards, headers, footers
- [ ] Client design review — one round of revisions budgeted
- [ ] Final design approved before development starts
Phase 4: Content Production
- [ ] Final copy written for all pages (can run parallel to design)
- [ ] Images and media sourced or created
- [ ] Content freeze date set — no new copy requests after this date
- [ ] SEO metadata: titles, descriptions, alt text
- [ ] All content delivered to development team
Phase 5: Development
- [ ] CMS setup and theme/framework implementation
- [ ] Pages built from approved designs
- [ ] Integrations connected (forms, analytics, CRM, e-commerce)
- [ ] Redirect map implemented for all changed URLs
- [ ] Cross-browser and mobile QA completed
Phase 6: Review and Launch
- [ ] Client UAT (user acceptance testing) — 3 business days minimum
- [ ] Feedback consolidated and addressed
- [ ] Final sign-off from client in writing
- [ ] Pre-launch checklist: DNS, SSL, analytics, form testing, 404s
- [ ] Launch and post-launch monitoring (48 hours minimum)
Common Mistakes
Starting design before scope is locked. Any design work done before the sitemap is approved is at risk of being thrown out. Scope lock is a gate, not a formality.
No content freeze date. If clients can submit new copy requests during development, development never ends. Set a hard date — new content requests after that date go into a phase 2.
Skipping the redirect map. Changing URLs without redirects destroys SEO equity built over years. Every changed or deleted URL needs a 301 redirect documented before launch.
Compressing QA to hit a launch date. QA catches problems before clients do. Cutting it to two days to make a deadline usually means a broken launch and emergency fixes.
No post-launch window. Something always surfaces in the first 48 hours — a form that doesn't submit, an integration that breaks in production, a mobile layout that wasn't caught in QA. Budget time for it.
Quick-Start in gantt-chart.io
- Go to gantt-chart.io and create a new project
- Add the six phases above as top-level tasks with realistic durations
- Set dependencies: wireframe approval → visual design start; design approval → development start; content freeze → development completion
- Add milestones for scope lock, design approval, content freeze, and launch
- Share the view-only link with the client so they can see the full timeline before kickoff
FAQ
How long does a website redesign take?
For a small business site (5–15 pages): 6–10 weeks with a focused team. For a larger marketing site or e-commerce redesign: 12–20 weeks. These assume scope is locked at the start and client reviews don't slip.
When should content be written — before or during design?
Parallel is fine if you have a content outline locked before design starts. Real copy needs to be ready before development begins. Placeholder copy in a production build causes last-minute rework.
What if the client wants to add pages mid-project?
Scope change request, documented and signed. Estimate the added time and cost. Update the Gantt to show the impact on the launch date. Never absorb scope additions silently.
How many rounds of revisions should I budget?
One round at wireframes, one round at design. Two rounds total. More than that usually means the brief or approval process broke down — fix the process, not the budget.
What's the minimum viable redesign timeline if the client has a hard deadline?
Work backward from the deadline, cut scope to match. A hard deadline with full scope is not a constraint — it's a conflict. Resolve it at kickoff, not at launch.
A website redesign that finishes on time starts with a plan everyone has seen and agreed to. Put the timeline in front of your client before work begins, lock the scope in writing, and use the Gantt to manage the dependencies. Plan yours at gantt-chart.io.