Gantt Chart for Website Redesign Projects

A website redesign is one of the most scope-creep-prone projects in digital marketing. It starts as "update the homepage" and 12 weeks later involves a new CMS migration, a brand refresh, a blog restructure, 14 new landing pages, and a HubSpot integration — none of which were in the original brief, all of which are now on the critical path before launch.

The Gantt chart for a website redesign is the structural tool that keeps scope visible, assigns phases to calendar time, and creates a forcing function for the decision that kills more redesigns than any other: stakeholder sign-off on information architecture and design direction before a single line of code is written.

This guide covers a corporate website redesign — 20 to 60 pages, new CMS or CMS migration, full design system, SEO continuity, and third-party integrations. Total timeline: 18 to 30 weeks depending on site complexity and client content delivery.

Phase 1: Discovery and Strategy (Weeks 1–4)

Discovery is not a formality. Skipping or compressing discovery produces a redesign that is aesthetically new but functionally unchanged — different colors on the same broken user experience.

Stakeholder interviews: Interview all primary stakeholders — marketing, sales, product, and leadership — in the first two weeks. The critical questions are not aesthetic preferences but business objectives: what does the website need to accomplish for the business in the next 12–18 months? Which pages drive pipeline? Which pages do sales reference during deal cycles? Where does traffic arrive that converts poorly? What does the current site fail to communicate? Conflicts between stakeholders surface here, not after design begins.

Analytics review and SEO baseline: Pull the current-state analytics from GA4 before any redesign decisions are made. Establish the baseline: top 20 pages by organic traffic, conversion rates by page and traffic source, average engagement time, Core Web Vitals scores, and mobile vs. desktop split. Every redesign risks SEO regression. You cannot measure regression without a pre-redesign baseline. Separately, pull a keyword ranking report — which terms rank on page 1, page 2, and page 3 — and document the backlink profile. These rankings must survive the redesign.

Content audit: Catalog every page on the current site. For each page, make a keep/rewrite/cut decision and document why. Most corporate sites have 30 to 50 percent of their pages that receive no meaningful traffic, contribute no conversions, and should simply not exist on the new site. Migrating them adds development time, dilutes site quality signals, and creates ongoing maintenance burden. The content audit decision must be made before the sitemap is finalized.

Competitor analysis: Analyze 5 to 8 direct competitors' websites from a user experience and conversion perspective, not an aesthetic one. Which competitors communicate value proposition clearly above the fold? Which have pricing pages? Which use interactive demos vs. static screenshots? Which have social proof strategies (customer logos, G2 ratings, named case studies) that are more credible than yours? The output is a benchmark, not a copy brief.

Sitemap and information architecture (IA): Produce the new sitemap based on business objectives, content audit decisions, and user research findings. The sitemap is the first formal document that requires stakeholder sign-off — and it is the correct moment to have the argument about which pages to include, not after wireframes are designed. IA decisions that change after wireframing cause cascading rework across UX, design, and development.

Phase 2: UX and Wireframing (Weeks 4–9)

Wireframing is the phase most often skipped on small projects and most often regretted. Wireframes communicate page structure, content hierarchy, and user flow — the things that determine whether the site works — without the visual style that distracts stakeholders into font opinions.

User flows: Map the primary user journeys through the new site before wireframing individual pages. A B2B SaaS company typically has 3 to 5 primary user flows: organic searcher → product page → pricing → demo request; paid ad visitor → dedicated landing page → demo request; referred visitor → homepage → case study → pricing → demo request; existing customer → login or support; partner/analyst → about/company → contact. Each flow must resolve to a clear conversion action or the design cannot optimize for it.

Wireframes for key page types: Produce wireframes for each distinct page template — not every page on the site, but every unique layout. For a corporate site this typically includes: homepage, product or service page, solution or use-case page, pricing page, case study or customer story page, about page, blog index, blog post, and gated landing page. The number of unique templates, not the number of total pages, determines wireframing effort.

Accessibility and mobile-first requirements: Establish WCAG 2.2 AA compliance as a non-negotiable requirement during the UX phase — not during QA. Identify which interactive elements (forms, modals, navigation, accordions) require keyboard navigation and screen reader support. Define the responsive breakpoints: 375px (mobile), 768px (tablet), 1024px (small desktop), 1440px (standard desktop). Wireframes should be designed at 375px first, not adapted to mobile after the fact.

Stakeholder review and IA sign-off: Wireframe review is the second formal sign-off checkpoint. The rule: once wireframes are approved and design begins, IA changes require a design revision. If a stakeholder wants to add a page or change the navigation structure after design has begun, the impact must be scoped and either accepted or deferred to a post-launch iteration.

Phase 3: Visual Design (Weeks 9–15)

Design translates approved wireframes into the visual language of the brand. The Gantt risk in this phase is scope expansion — stakeholders who approved the wireframe but want different visual treatment for every element once they see it.

Brand alignment and design system: Establish or refresh the design system before designing pages. The design system defines: color palette with semantic token names, typography scale (heading sizes, body sizes, line heights), spacing scale, component library (buttons in all states, form fields, cards, badges, icons), and grid system. Pages built from a design system are consistent by default; pages designed ad hoc diverge across the site.

Key page mockups: Design the approved wireframes in high fidelity, starting with the homepage, a product page, and the pricing page — the three pages that carry the most conversion weight on most corporate sites. Design in Figma or the team's agreed design tool with components linked to the design system.

Responsive design across breakpoints: Every page design must be delivered at all defined breakpoints. Responsive design is not the developer's responsibility to figure out — it must be specified in the design file. Leaving responsive behavior undocumented produces inconsistent implementations, requires developer interpretation decisions, and creates QA cycles to correct them.

Design QA and accessibility check: Before handing off to development, run a design QA pass: color contrast ratio checks for all text (WCAG AA requires 4.5:1 for normal text, 3:1 for large text), focus state specification for all interactive elements, and an accessibility review of the design file. Catching these in design is hours of work; catching them in QA is days.

Stakeholder review rounds: Plan for two rounds of design review. The first round should produce significant feedback; the second round should produce minor refinements. If a third round is needed, it is a signal that approval authority is unclear — escalate to a single decision-maker before beginning the third revision.

Phase 4: Development (Weeks 14–24)

Development is the longest phase in hours of effort and the one where scope expansion is most expensive. A new feature added to the design after development has begun is not the cost of designing the feature — it is the cost of designing it, plus breaking the existing implementation, plus re-testing the affected components.

CMS setup and configuration: Select and set up the CMS — WordPress (with or without a page builder), Webflow, Contentful, Sanity, or a static site generator like Next.js — in the first week of development. CMS architecture decisions made during setup (taxonomy structure, content model, custom fields, editor experience) are expensive to change mid-project. Document the content model from the sitemap and design so that the CMS structure matches what editors will actually need.

Component development: Build the design system components in code before building pages. A component-first approach means that each page is assembled from tested, reusable components — reducing both development time for subsequent pages and QA scope, since a component tested once works consistently across all instances.

Content migration: Content migration is the activity most consistently underestimated in website redesigns. The assumption — "we'll just copy and paste" — encounters the reality: 300 blog posts need URL redirects, metadata rewrites, and image re-optimization; existing pages have inconsistent formatting that must be cleaned before migration; customer case studies need permission review before migration to the new site. Allocate a content migration workstream with a dedicated owner and realistic hours. For sites with 50+ pages, automated migration scripts reduce manual effort but require developer time to write and test.

Form development and CRM integration: Every form on the site requires development, testing, and CRM integration verification. For HubSpot, Salesforce, or Marketo integrations, test the full data flow: form submission → field mapping → record creation → contact property population → workflow enrollment. Form-to-CRM integration failures are invisible to visitors but result in sales teams losing leads.

Analytics and tracking implementation: Implement GA4, Google Tag Manager, conversion event tracking, and all ad platform pixels (Meta Pixel, LinkedIn Insight Tag, Google Ads conversion tag) as part of development — not as a post-launch task. Verify that custom events fire on form submissions, PDF downloads, video plays, scroll depth milestones, and any other micro-conversions defined in the measurement plan.

Phase 5: QA and Testing (Weeks 23–26)

QA is non-negotiable and non-compressible. Cutting QA time is one of the most reliable ways to launch a broken site.

Cross-browser testing: Test in Chrome, Safari, Firefox, and Edge on desktop. Test in Safari and Chrome on iOS; Chrome on Android. Use BrowserStack or a physical device lab for browsers you do not have natively. Document browser versions tested. CSS rendering differences between browsers — especially Safari on iOS — consistently produce layout bugs that are invisible in Chrome.

Mobile device testing: Device testing on physical hardware catches issues that responsive design previews in the browser do not. iOS Safari handles touch interactions, fixed positioning, and viewport units differently from Chrome on Android. Test all primary user flows on iPhone and Android before signing off.

Load testing: Test page load performance using Google PageSpeed Insights and Web Vitals field data. Core Web Vitals targets: Largest Contentful Paint (LCP) under 2.5 seconds, Cumulative Layout Shift (CLS) under 0.1, Interaction to Next Paint (INP) under 200ms. Sites that fail Core Web Vitals are disadvantaged in Google search rankings independent of content quality.

Accessibility audit: Run an automated accessibility scan using axe DevTools or WAVE, then conduct a manual keyboard navigation and screen reader test. Automated tools catch approximately 30 to 40 percent of WCAG violations — manual testing is required for the remainder. Common failures: form labels not programmatically associated with inputs, images missing alt text, skip navigation link absent, modals that trap keyboard focus.

SEO technical audit: Before launch, verify: all redirect mappings from old URLs to new URLs are complete (every page that had search traffic needs a 301 redirect), canonical tags are correct, meta titles and descriptions are set for all pages, structured data markup is implemented where applicable, XML sitemap is generated and accurate, robots.txt does not block any pages that should be indexed.

Redirect mapping completeness: Generate a crawl of the current live site using Screaming Frog and export all indexable URLs. Map every URL with organic traffic or backlinks to its new destination. Missing redirects result in 404 errors that destroy link equity and organic ranking. This is the most consequential SEO task in any migration.

Phase 6: Launch (Weeks 26–28)

DNS cutover and deployment: Coordinate DNS cutover for a low-traffic period — Tuesday through Thursday between 10 PM and 2 AM local time is typical. Have rollback capability confirmed before cutting over. After deployment, verify the site is resolving correctly, SSL certificate is valid across all pages, and the old site is no longer accessible.

Post-launch verification checklist: In the first 24 hours: verify all forms submit and sync to CRM, verify all tracking tags fire (use GA4 DebugView and Tag Manager Preview mode), verify redirect chains resolve correctly with no redirect loops, verify Google Search Console is receiving data from the new site, verify Core Web Vitals are within acceptable ranges.

Search Console and sitemap submission: Submit the new XML sitemap to Google Search Console and Bing Webmaster Tools. Request indexing for the homepage and top priority pages. Monitor the Coverage report for crawl errors, excluded pages, and indexing status over the first two weeks.

Post-launch monitoring window (Weeks 28–30): Monitor organic search rankings daily for the first 14 days using a rank tracking tool. A well-executed migration with complete redirects should show minimal ranking disruption within 4 to 6 weeks. Significant ranking drops for high-value keywords require immediate investigation — check redirect implementation, canonical tags, and whether the affected pages were inadvertently modified.

Content delivery from the client remains the top schedule risk in agency website redesigns. The mitigation is a content delivery deadline in the project schedule with explicit consequences: if page copy is delivered two weeks late, development start shifts two weeks and launch moves accordingly. Building that commitment into the project plan — before work begins — is the difference between a launch that hits the calendar date and one that slips by a month.