Steps to Redesign a Website

The steps to redesign a website follow a dependency chain where each step produces the inputs the next one requires.

Skip any step and you skip either a required output or the protection that step provides against a specific, predictable failure.

That framing matters because the steps most often skipped, including redirect mapping, user testing, and pre-launch analytics setup, are the ones responsible for the most common and most expensive post-launch problems.

This guide covers every step in sequence so you can run the process correctly the first time.

Key Takeaways

• Order is not optional: The steps follow a dependency chain; running them out of sequence creates rework that costs more than the time saved by skipping ahead.
• Steps 1 through 5 happen before any design: Research, goals, brief, requirements, and sitemap must all be complete before a wireframe or mockup is drawn.
• Content is a step with an owner: Writing and loading content must be planned as a specific step with a named person and hard deadlines, not assumed to happen automatically.
• QA happens before client preview: Quality assurance is completed before the client views staging; client preview is a sign-off step, not a discovery step.
• Post-launch has four distinct steps: Redirect verification, analytics confirmation, monitoring setup, and performance review are four separate steps with different timelines and owners.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

Steps 1-3: Research, Goals, and Brief

Start by planning the redesign first with a thorough research phase before any brief is written or agency is briefed. The quality of this phase determines every step that follows.

These three steps are frequently compressed or skipped by businesses eager to get to the design work. Compressing them is the single most reliable predictor of a redesign that fails to improve business performance.

Step 1: Audit the Current Site

Pull three to six months of GA4 data, run a Lighthouse audit on key pages, review heatmaps, and document what is working and what is not before writing the brief.

This audit produces the evidence base for the brief. Every redesign decision made later should be traceable back to a specific finding in the audit.

Without this step, the brief is built on assumptions rather than data.

• Export all page-level organic traffic data: Identify the 20 to 50 pages driving the most organic traffic so these are explicitly protected throughout the redesign process.
• Run a mobile Lighthouse audit on key pages: Mobile performance scores below 60 indicate architectural problems that the platform or build approach must address, not just CSS fixes.
• Review user flow data in GA4: Identify where users drop off in the conversion funnel so the new site's architecture explicitly addresses these friction points.
• Document current conversion rate as the baseline: The pre-redesign conversion rate is the metric against which the redesign's success will ultimately be measured; document it before anything changes.

Allocate two to three weeks for a thorough audit on a site of typical business complexity.

Step 2: Define Measurable Goals

Document three to five specific, measurable redesign goals with current baselines and targets. These goals drive every subsequent decision in the project. Without them, design is guesswork and success is unmeasurable.

Goals must be specific and time-bound. "Improve lead generation" is not a goal.

"Increase monthly organic enquiries from 45 to 75 within 90 days of launch" is a goal. The difference determines whether the redesign can be evaluated objectively.

Step 3: Write and Approve the Brief

The brief documents audience profiles with ICP definitions, competitive context, brand guidelines, content requirements per page type, technical constraints, integration requirements, accessibility standards, budget range, and launch timeline with key milestones.

Every stakeholder who will have sign-off authority at any point in the project must approve the brief before Step 4 begins. Late-stage changes that contradict an approved brief are a preventable and expensive project failure.

Steps 4-6: Requirements, Architecture, and Wireframes

These steps translate the brief into a structural commitment that design and development work from. Rushing through these to reach the "creative" work is the most common cause of expensive mid-project rework.

See the full redesign process overview for context on how these steps fit into the complete project arc.

Step 4: Document Functional and Technical Requirements

List every required site feature: CMS and editorial workflow needs, form types and destinations, third-party integrations, accessibility standards (WCAG 2.1 AA minimum), Core Web Vitals performance targets, and security requirements.

Stakeholder sign-off on requirements is mandatory before Step 5. Requirements that emerge after the sitemap or wireframes are complete create scope changes that cost time and money.

• Include CMS editorial workflow requirements: Specify exactly what the site's editorial team must be able to update without developer help and verify the chosen platform supports this.
• Document every integration with its API requirements: Integrations that seem simple sometimes have significant technical complexity; discover this in requirements, not in development.
• Specify performance acceptance criteria: LCP under 2.5 seconds, CLS under 0.1, and FID under 100ms must appear as explicit requirements, not aspirational goals.

Step 5: Build the Sitemap and Navigation Architecture

Define every page, its hierarchy in the navigation, how it connects to other pages through internal linking, and what keyword it targets from an SEO perspective.

The sitemap is a structural commitment. It defines the scope of the development work and the redirect requirements for any URL changes. Once approved, it should not change without a documented scope change process.

Step 6: Wireframe Key Page Templates

Low-fidelity wireframes define the content blocks, conversion flow, and UX logic for each page template type.

They answer: what content goes where, what is the hierarchy of information, where does the CTA appear, and how does the user progress through the page.

Approved wireframes give the visual design phase a validated structural foundation to work from. Without them, designers make structural UX decisions that should have been made and signed off at the requirements stage.

Steps 7-9: Visual Design, Content, and Build

This is the phase most people think of as "the redesign." It is, but it is also the phase most dependent on the quality of the work done in Steps 1 through 6.

See design phase steps in detail for a full breakdown of what each creative step produces.

Step 7: Design the Visual System and Key Mockups

Develop the design system first: color palette, typography scale, component library, spacing system, and interactive state definitions. Then produce high-fidelity mockups for the homepage, primary service or product page, and blog template.

Client approval of the design system and key templates on desktop and mobile occurs before development begins. This is a hard gate, not a courtesy review.

• Present desktop and mobile designs simultaneously: A design that works on desktop frequently requires significant adaptation for mobile; review both together, not sequentially.
• Define the component library before designing all pages: Building pages from a consistent component set is faster, more consistent, and produces a more maintainable CMS output than designing each page independently.
• Obtain explicit design sign-off before development: "We'll sort it in development" is the most expensive phrase in any redesign project; development should follow approved designs, not interpret them.

Step 8: Write and Prepare All Content

Page copy, imagery, brand assets, and any other content that will appear on the site must be written, reviewed, approved, and formatted before content is loaded in development.

Late content is the top cause of launch delays in every type of web project.

This step must have a hard deadline, a named content owner, and a named approver. It is not a passive step.

Step 9: Build, Integrate, and Configure the CMS

Development builds all approved page templates, connects all integrations, loads all content, and configures the CMS for the client's specific editorial workflow. This step produces the staging site that enters QA in Step 10.

Content loading is part of development, not a post-development activity. Every page should have its real content in place before QA begins.

Steps That Most Teams Skip (and Shouldn't)

The best practices often overlooked in redesign projects cluster in this section. These steps seem optional when everything else is going well. Their absence is felt immediately when they're skipped.

Redirect Mapping (Skipped Most Often)

Every URL that changes between the old site and the new one must have a 301 redirect mapping the old URL to the new destination.

This is skipped in a significant proportion of redesigns, and the resulting organic traffic loss is the most common post-launch complaint.

Research suggests redirect mapping failures are responsible for an average 25 percent organic traffic drop when skipped in redesigns that involve URL structure changes.

Build the redirect map during the pre-design phase and test every redirect on staging before launch day.

• Map every URL from the Screaming Frog export: The pre-redesign site crawl is the source list; every URL on that list needs either a preservation decision or a redirect destination.
• Test redirects with a bulk checker on staging: Don't test a sample; test every redirect in the map and confirm each one returns a 301 status code landing on the expected destination URL.
• Verify priority redirects manually after launch: High-traffic and high-backlink URLs need individual post-launch verification, not just bulk crawl confirmation.

User Testing the Information Architecture

Testing the sitemap and wireframes with real users before design is locked is inexpensive and prevents structural UX problems from being built into the site permanently.

Five to eight unmoderated user tests on the wireframes reveal navigation failures, confusing information hierarchy, and conversion flow gaps before they cost development time to undo.

Setting Up Analytics and Goals Before Launch

GA4 conversion goals, form tracking, and source attribution must be configured and tested before the site goes live. Not after the first week. Not in the first month. Before launch.

Data collected from day one is the only way to run a valid before-and-after comparison. Starting analytics after launch means the post-launch performance review is based on incomplete data.

QA Steps Before Launch

Quality assurance before going live covers the complete QA checklist. These three steps must all pass before the client is asked to review the staging environment.

Client preview is a sign-off step, not a discovery step. Presenting a staging site with unresolved QA issues wastes stakeholder time and erodes confidence in the team's professional standards.

Cross-Device and Cross-Browser Testing

Test every page template on real iOS and Android devices, and on Chrome, Safari, Firefox, and Edge browsers.

Desktop browser emulators are not a substitute for real device testing; they miss touch interaction issues, font rendering differences, and real-world network performance.

Allocate one full day for device and browser testing on a typical project. Discovery during this step is expected and normal. Discovery during client review is not.

• Test forms and CTAs on every device: Form fields, submit buttons, and click-to-call links behave differently across devices and browsers; verify each one works correctly on each platform.
• Check all animations and transitions: CSS animations that perform smoothly on a high-performance desktop may stutter on a mid-range mobile device; test on the mid-range device, not the latest flagship.
• Verify image loading on cellular connection: Images that appear instantly on Wi-Fi may cause significant load delay on a 4G connection; test this explicitly before sign-off.

Form and Integration Testing

Submit every form and verify data arrives in the correct destination: CRM record creation, email notification, spreadsheet row, or wherever the form data is supposed to go.

Test every integration the site uses and verify tracking pixels fire correctly in browser developer tools. A broken integration discovered post-launch disrupts business operations immediately.

Performance and Accessibility Checks

Run Lighthouse on every key page template. Performance should score above 85 on both desktop and mobile. Accessibility should meet WCAG 2.1 AA minimum as a prerequisite for launch.

Both checks happen before the client views the staging environment. Both are non-negotiable launch gates, not aspirational targets.

Post-Launch Steps

Post-launch tasks to complete are often treated as a single "go live" event. They are four distinct steps with different timelines and different owners.

Launch Day Verification

Within the first hour of DNS cutover, verify SSL is active, test all redirects return 301 status codes, confirm GA4 is tracking, verify forms submit correctly, and check for console errors on key pages.

This checklist takes 30 to 60 minutes. Skipping it means discovering launch-day problems from users, not from proactive verification.

30-Day Monitoring Protocol

Monitor Google Search Console for crawl errors and ranking changes weekly for the first 30 days. Check GA4 for organic traffic anomalies against the pre-launch baseline. Verify all integrations continue functioning correctly.

Report to the client at day 30 with a formal comparison of organic traffic, conversion rate, and lead volume against pre-launch baselines. This report is a project deliverable, not an optional courtesy.

90-Day Performance Review

Compare conversion rate, organic traffic, and bounce rate against pre-launch baselines at 90 days post-launch. This review either confirms the redesign achieved its defined goals or produces an iteration brief for Phase Two.

A 90-day review is the minimum period required for organic SEO performance to stabilize after a redesign. Reviewing performance earlier produces misleading conclusions.

Conclusion

Every step in this sequence exists for a reason. The steps that seem optional, redirect mapping, user testing, pre-launch analytics setup, are the ones most likely to cause expensive, time-consuming problems if they are skipped.

Map your current redesign plans against this step sequence today. Identify the first step that's missing or hasn't started. That is where to focus next.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

LOW/CODE Agency Follows Every Step, Including the Ones Most Agencies Skip

LOW/CODE Agency follows a complete 12-step redesign process with documented outputs, formal client approvals at each gate, and post-launch monitoring as a standard project deliverable. Including redirect mapping. Including user testing. Including pre-launch analytics configuration.

We operate as a strategic product team, not a dev shop.

That means every step in the process is owned by a named team member with a specific deliverable and a sign-off requirement before the next step begins.

• Structured discovery and audit phase: GA4 analyzis, Lighthouse audit, and heatmap review completed before any brief is written or design work scoped.
• Measurable goals documented before design begins: Three to five specific, time-bound redesign goals with baseline metrics agreed by all stakeholders before any visual work starts.
• Wireframe and architecture sign-off as a hard gate: No development begins until wireframes and sitemap are formally approved; scope changes after this gate follow a documented change control process.
• Redirect mapping as a standard deliverable: Complete redirect map built during pre-design, tested on staging, and verified post-launch included in every project scope without exception.
• QA before client preview, every time: All cross-device testing, form testing, and Lighthouse performance checks completed before the client sees the staging environment.
• Analytics configuration before launch: GA4 goals, form tracking, and source attribution configured and tested on staging before any DNS changes are made on launch day.
• Formal 90-day post-launch review: Written performance report comparing conversion rate, organic traffic, and lead volume against pre-launch baselines delivered as a standard project close deliverable.

LOW/CODE Agency operates as your step-by-step redesign agency for 450+ products, including projects for Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. Start with a scoping call