The order matters more than most teams expect. Skipping the audit to get to the fun part, the visual design, is the single most common reason redesigns underperform the site they replaced.

1. Audit your current site

Pull every indexed URL, using Google Search Console or a crawler like Screaming Frog, before anyone touches a wireframe. Note which pages actually drive traffic and conversions, which are dead weight, and which have backlinks worth preserving.

Layer in analytics on top of the crawl: exit rates by page, where mobile users drop off compared to desktop, and which paths convert versus which just get traffic. This audit becomes the map for every redirect decision later, so treat it as the foundation, not a formality you rush through.

2. Define goals and KPIs

Write down what the redesign needs to move: signup rate, average order value, demo requests, support ticket volume, whatever is specific to the business. Assign a current baseline and a target to each one, since a goal without a number attached is just a preference.

Vague goals like "make it feel more modern" produce a site that looks different and performs identically, because there's nothing to design toward and nothing to measure against after launch. Get sign-off on these numbers from whoever owns the budget before design work starts, not after. This is also the point where it's worth connecting the redesign to a broader UX strategy rather than treating it as an isolated project, so the next redesign doesn't start from zero again.

3. Research users and competitors

Talk to five to eight real users about where they get stuck on the current site, and pull the same information from support tickets and session recordings if you have them. A short, unmoderated usability test on the existing site often surfaces the same friction points a full research program would, just faster.

Look at two or three competitors too, not to copy their layout, but to see what they've solved that you haven't. This step is where a lot of the "why" behind later design decisions actually comes from, rather than someone's opinion in a design review.

4. Rework information architecture and content

Redraw the sitemap before touching layout. Decide what gets merged, what gets cut, and what new pages the goals from step two actually require. A card sort with a handful of real users, even an informal one, will often reveal that the current navigation makes sense to the team and nobody else.

Content should get rewritten or restructured here too, since a beautiful new template wrapped around old, unfocused copy just makes the same problem look nicer. This is also where old blog posts and product pages get flagged for consolidation instead of dragging forward as-is.

5. Wireframe and prototype

Low-fidelity wireframes let you test structure and flow before anyone argues about color. Build a clickable prototype for the core paths, homepage to product page to checkout, or homepage to demo request, and test it with a handful of real users before development starts.

Catching a confusing flow here costs an afternoon of rework. Catching it after launch costs a rebuild, and by then it's competing for budget against whatever the team wants to do next quarter.

6. Design the UI

This is where color, typography, imagery, and component design happen, built on the structure the wireframes already validated. Building or extending a design system at this stage, rather than one-off screens, pays off the moment a second page type or a new feature needs the same components.

Keep an eye on accessibility here: sufficient color contrast, readable type sizes, keyboard-navigable components. Retrofitting accessibility after development is far more expensive than designing for it from the start, and it's the kind of gap that shows up in a legal complaint before it shows up in a support ticket.

7. Build and test

Develop on a staging environment, never directly on the live domain. Test across real devices and browsers, not just the emulator in your browser's dev tools, since a layout that holds up in Chrome on a laptop can quietly break on an older Android phone.

Run a full QA pass on forms, checkout flows, and any interactive element before anyone talks about a launch date. This is also the stage to build out your redirect map, which the SEO section below covers in detail, and to confirm analytics and conversion tracking are firing correctly on the new pages before they go live.

8. Launch and monitor

Launch during a low-traffic window, and watch Google Search Console, analytics, and error logs closely for the first two weeks rather than assuming everything is fine because nothing broke visibly. Check that redirects are resolving correctly, that forms are submitting, and that the pages you flagged as high-value in the audit are actually indexing.

A redesign isn't finished at launch; it's finished once the data confirms the new site is doing what the goals in step two said it should. Revisit those KPIs at 30, 60, and 90 days, not just once and never again.