TL;DR
A complete website redesign checklist has eight steps: (1) audit the current site for analytics, SEO, and performance data; (2) capture the existing design into Figma with html2design to create an editable baseline; (3) identify design debt from the baseline; (4) plan the new information architecture; (5) design in Figma from the baseline; (6) implement; (7) test for cross-browser, accessibility, and performance; (8) launch with 301 redirects and monitor. The critical step most teams skip is Step 2 — without a captured baseline, designs drift away from production reality and implementations take longer to reconcile.
Why Most Redesigns Go Wrong
A website redesign sounds straightforward: look at the existing site, decide what's broken, and design something better. In practice, most redesigns encounter the same set of problems: the new designs don't account for real content lengths, the implementation takes twice as long because the designs didn't reflect what the codebase actually does, and teams discover post-launch that SEO rankings dropped because redirects weren't set up properly.
These failures have a common root cause: teams start designing before they've captured what they already have. They work from memory and screenshots rather than an accurate Figma representation of the current site — and they pay for it in rework.
This checklist is organized to prevent that. It front-loads the audit and baseline capture before any new design work begins. Each step builds on the previous one.
The 8-Step Website Redesign Checklist
Step 1
Audit the Current Site
Before designing anything, understand what you're working with. The audit has four tracks:
- Analytics: Which pages get the most traffic? Where do users drop off? Which conversion paths actually convert? Use Google Analytics (or your analytics platform) to answer these questions. The top 20% of pages by traffic typically drive 80% of business value — those pages get the most careful redesign attention.
- SEO: Which keywords are you currently ranking for? Export your top 50 ranking pages from Google Search Console. These pages must maintain their URL structure or get proper 301 redirects — losing these rankings is the most common post-redesign disaster.
- Performance: Run Lighthouse on the five highest-traffic pages. Document LCP, CLS, and INP scores. If the redesign is partly motivated by performance improvements, these baseline scores let you measure success post-launch.
- UX: Review heatmaps and session recordings (Hotjar, Microsoft Clarity, or similar). Note where users click unexpectedly, where they rage-click, and which sections they scroll past. This is qualitative signal that analytics alone doesn't provide.
Document this rigorously. The audit findings are your success criteria for the redesign. Post-launch, you'll use these same metrics to answer "did the redesign work?" If you don't document baseline numbers before you start, you can't answer that question later.
Step 2
Capture the Existing Design into Figma
This is the step most teams skip — and the most valuable one. Before any new design work begins, import the current site into Figma as editable layers using html2design. Open each key page in a browser, run the plugin, and it generates native Figma frames that reflect the actual computed styles: real font sizes, real spacing, real colors, real component structure.
What you get is a truthful Figma representation of what your site currently is — not what you think it is. This matters more than it sounds. Teams consistently discover, when they look at a browser-accurate Figma import, that the site is inconsistent in ways they didn't notice in daily use: buttons with three slightly different border radii, heading sizes that don't follow a type scale, section padding that varies by six pixels between pages.
See the legacy website redesign guide for a detailed walkthrough of this import process, including how to handle multi-page sites and authenticated sections. For the general import workflow, the import website into Figma guide covers both approaches (Chrome extension and code paste).
Organize the import by page type: home page, key landing pages, the blog/content hub, product pages, and the checkout or conversion flow (if applicable). Import each as a separate section in a single Figma file. This becomes your redesign reference file for the entire project.
Step 3
Identify Design Debt from the Baseline
With the existing site in Figma, audit the imported layers for inconsistency. Design debt is the accumulation of visual decisions made without a shared system — it shows up as duplicate components with slight variations, multiple type styles doing the same job, color values that almost-match but don't, spacing that doesn't follow a consistent scale.
Go through each imported frame and annotate the issues:
- Mark duplicate components — buttons that look the same but have different padding or font size
- Flag off-scale spacing — a 14px gap where the rest of the page uses 16px or 12px
- Identify color near-misses —
#2461EBand#2563EBused interchangeably for "the blue" - Note inconsistent heading hierarchy — an H2 on one page that's styled identically to an H3 on another
This inventory is your design debt list. The redesign should eliminate it, not carry it forward. Every inconsistency you document now is one you'll resolve in the new design system rather than discovering in QA.
See the legacy migration use case for how teams have used this process to modernize production sites systematically.
Step 4
Plan the New Information Architecture
Before opening a design tool for new work, define the new site structure. Information architecture decisions are cheap to revise in a spreadsheet and expensive to revise in Figma — and extremely expensive to revise after implementation.
Work through:
- Navigation structure: What are the top-level nav items? What lives in dropdowns? What gets a dedicated landing page vs. an anchor on an existing page?
- URL structure: If URLs are changing (often they should — a redesign is a good time to clean up URL patterns), document the old-to-new mapping. Every changed URL needs a 301 redirect. This list is critical for Step 8.
- Content hierarchy: For each key page, decide what's above the fold, what's the primary CTA, and what secondary information supports it. Document this as annotated wireframes or a simple text outline — not full designs yet.
- New pages or removed pages: Is anything being added or cut? New pages need new content; removed pages need redirects.
Don't skip the URL redirect mapping. It's the most skipped step and the most consequential. A redesign that changes URLs without redirects can cause significant drops in organic search traffic that take months to recover from.
Step 5
Design in Figma from the Baseline
Now design the new site. Start from the baseline you captured in Step 2 — duplicate the imported frames and redesign on top of them. This approach keeps designs anchored to real content lengths and real component sizes, which means fewer surprises during implementation.
Use the design debt list from Step 3 as a design system specification. For each inconsistency you documented, make a deliberate decision: establish the canonical value and apply it uniformly. By the time key pages are designed, you should have an implicit (or explicit) design system that resolved the debt.
- Define a limited color palette with named tokens (primary, secondary, surface, text, border)
- Define a type scale with five or fewer sizes, each with a semantic role (headline, subhead, body, label, caption)
- Define a spacing scale (4px base is common) and use only values on the scale
- Design a shared component set (button variants, card, input, nav) before designing pages — pages should be composed from components, not defined independently
Design with real content. The imported baseline has real copy and real images from the current site. Use them in the redesigned frames instead of placeholder text — it's the fastest way to catch layouts that break with actual content lengths.
Step 6
Implement the New Design
Hand off the Figma designs to the development team. If the design-to-code workflow uses a tool like Figma Dev Mode, the measurements and token values from the design files are directly accessible.
For the implementation, build the component library first — the shared button, input, card, and navigation components defined in Step 5. Implement each component in isolation (Storybook is useful here), verify it against the Figma design, then compose pages from the components. This component-first sequence is the most reliable way to maintain design fidelity through a large site.
During implementation, use the URL redirect map from Step 4 to configure 301 redirects in parallel with building new pages. Don't leave redirects as a post-launch task.
Step 7
Test Before Launch
Test thoroughly before going live. A compressed test plan for a redesign covers:
| Test type | What to check | Tools |
|---|---|---|
| Cross-browser | Chrome, Firefox, Safari (macOS + iOS), Edge, Samsung Internet | BrowserStack, manual testing |
| Accessibility | WCAG 2.2 AA: color contrast, keyboard navigation, focus indicators, alt text, ARIA labels | axe DevTools, Lighthouse, screen reader (NVDA/VoiceOver) |
| Performance | LCP < 2.5s, CLS < 0.1, INP < 200ms on the five highest-traffic pages | Lighthouse, PageSpeed Insights, WebPageTest |
| Redirects | Every changed URL returns 301, not 404 or 302 | Screaming Frog, curl batch test |
| Forms & conversions | All forms submit, confirmation flows work, analytics events fire | Manual QA, GTM preview mode |
| Mobile | Tap targets ≥ 44×44px, no horizontal scroll, text legible without zooming | Real devices (iOS + Android) |
Step 8
Launch and Monitor
Deploy to production. In the first 30 days post-launch, actively monitor:
- 404 errors: Set up an alert for new 404s in Google Search Console or your analytics tool. Missing redirects typically show up within 48 hours of launch.
- Organic traffic: Compare week-over-week and month-over-month organic sessions to the pre-redesign baseline you documented in Step 1. A significant drop (more than 15%) on a specific page group suggests a redirect or indexability problem.
- Core Web Vitals: Monitor LCP, CLS, and INP in Google Search Console's Core Web Vitals report. Field data takes 28 days to accumulate — check it at 30 days post-launch.
- Conversion rate: Compare the redesigned conversion funnels against the Step 1 baseline. If the redesign was intended to improve conversion, this is where you validate whether it worked.
Submit your updated sitemap. Go to Google Search Console → Sitemaps and submit the updated sitemap.xml. This tells Googlebot to crawl the new URL structure. New pages and changed URLs typically get indexed within 2–4 weeks of sitemap submission.
The Step Most Teams Skip (and Why It Matters)
Step 2 — capturing the existing design into Figma — is the single highest-leverage item on this checklist, and the one most often omitted. Teams skip it because it feels redundant: they already know what the site looks like, and capturing it seems like a delay before the "real work" begins.
The problem is that knowing what a site looks like is not the same as having an accurate, editable representation of it. When designers work from memory or browser screenshots, they make assumptions about spacing, type sizes, and component structure that don't hold up against the actual codebase. Developers then spend implementation time reconciling the new designs against the old code — work that compounds with every page.
When a browser-accurate import exists in Figma, both designers and developers work from a shared truthful reference. Designers iterate on real component sizes. Developers have a clear picture of what's staying, what's changing, and what's being eliminated. The redesign moves faster and produces fewer surprises.
The import itself takes a few hours for a typical marketing site. That's the investment. The return is a cleaner design process, fewer implementation surprises, and a post-launch codebase that actually matches the Figma files.
Redesign Timeline by Site Size
As a rough planning guide:
| Site size | Typical timeline | Biggest time variable |
|---|---|---|
| Small (< 20 pages) | 4–6 weeks | Content review and copy approval |
| Medium (20–100 pages) | 8–12 weeks | Design approval cycle |
| Large (100+ pages) | 16–24 weeks | Integration complexity and stakeholder alignment |
| E-commerce (with catalog) | 12–20 weeks | Product data migration and checkout QA |
The biggest driver of schedule variance in redesigns is the design approval cycle — not implementation. Teams that front-load the audit and IA planning (Steps 1–4) before design begins tend to have smoother approval cycles because stakeholders aren't seeing entirely unexpected structural changes partway through the project.