The website redesign process, step by step

The nine stages and why the order matters

A redesign goes wrong most often when stages are skipped or reordered. Design before the content is known produces pages that fit placeholder text and break with real copy. Build before approval produces rework. Launch without a redirect plan produces lost traffic.

The stages are: discovery, content and structure audit, sitemap, wireframes, visual design, build, quality assurance (QA), launch and post-launch. Each one produces something the next depends on. Before you start, confirm the redesign is justified. Our guide on when to redesign a website covers that decision.

The stages overlap in practice. Content writing runs alongside design, and redirect planning runs alongside build. But each stage has an exit: a signed-off output that the next stage can rely on.

Stage one: discovery

Discovery answers four questions. Who is the site for? What should they be able to do? How will you know it worked? What constraints exist, such as platform, budget, legal text and integrations?

Gather evidence: analytics, Search Console data, field performance data, support questions, sales call notes and a list of the pages that earn traffic and enquiries today. Set measurable goals, such as the number of enquiry form completions or the share of mobile visits that finish a booking. Nielsen Norman Group’s advice is to set clear measurable goals and success criteria before redesigning.

Record the baseline now. You cannot show that the new site improved anything without numbers from before. Also crawl the existing site and save the list of URLs, titles and status codes. That crawl becomes the basis of the redirect plan in redesigning without losing SEO.

Stage two: the content and structure audit

A content audit has two parts. Nielsen Norman Group’s article “Content Inventory and Auditing 101” (2020) defines the inventory as a catalogue of every content item with details such as URL, owner, topic, format and dates. The audit then rates each item’s quality, so you find what needs updating, what is missing and what can go.

The content audit gives each page one of three decisions: keep, update or remove. Updates need a named owner and a description of the change. Removals should be reviewed with the people who know the content. Use a spreadsheet; crawlers and CMS exports can fill the columns, but a person should make the quality calls.

Prioritise the content that people use most or that supports top tasks, and timebox the work. NN/g suggests a limit such as six weeks. Structure matters here too, and the information architecture needs the same review. A page with traffic, links or enquiries is not a removal candidate without a redirect plan.

Review the information architecture at the same time. That is how pages are grouped and labelled so people can find them. If visitors cannot find a service in two clicks, a prettier design will not fix it.

Stages three and four: sitemap and wireframes

The sitemap is a diagram of every page and how they connect. It turns the audit into a structure: which pages stay, which merge, which are new, and what each is called. Draw it before any wireframe or design, and give each page a purpose and a primary action. This is also where URL mapping begins, because every old address needs a destination.

A wireframe is a plain layout of one page type that shows where content and actions sit, without colour or imagery. NN/g’s homepage case study (2018) began with low-fidelity black-and-white wireframes for content planning, then moved to high-fidelity designs for testing. Use real copy in wireframes wherever you can, since lorem ipsum hides the problems real text causes.

Wireframe each page type once, not each page. A service business may need only six to ten templates: home, service, service category, about, article, contact and a few more. Fewer templates mean a faster, cheaper and more consistent build.

Stages five and six: visual design and build

Visual design applies the brand to the wireframes. Design the home page and two or three key templates first, then get sign-off before designing the rest. Test them with users. NN/g’s case study ran three rounds of testing on interactive prototypes, and says pre-launch testing reduces rework rather than eliminating it.

How many testers? Jakob Nielsen’s article “How Many Test Users in a Usability Study?” (2012) recommends about five users for a qualitative study and at least 20 for statistical numbers. Five people per round is enough to find the biggest problems.

The build turns approved designs into a working site on a staging site. A staging site is a private copy for testing that must be kept out of search results, usually with noindex or password protection. Build the templates first, then the content, then the integrations such as forms, analytics and booking tools.

Performance is built in, not added later. Set a budget for the Core Web Vitals thresholds in the brief, test them on staging, and check them again on the live site.

Stages seven to nine: QA, launch and post-launch

QA checks that everything works on real devices and browsers. Test every form and what happens after it is sent, every redirect from the old list, titles and descriptions, canonical tags, structured data, accessibility basics, analytics events and the 404 page. Keep a written list with a pass or fail for each item.

Launch is a short, planned event. Remove staging blocks, switch redirects on, submit the new sitemap and check that the homepage, key pages and forms work. Pick a quiet day and keep the team available. Google’s site moves documentation says small and medium sites should generally move all at once.

Post-launch is where results show. Watch Search Console, analytics, server errors and form submissions daily at first. Google says to expect ranking fluctuations for weeks or longer after a move, depending on site size. Fix errors fast, and compare against the baseline you recorded in discovery.

Realistic timelines, as ranges with reasons

No one can give an honest fixed timeline before scoping. These are typical ranges, not promises: a small brochure site of ten to twenty pages often takes about two to three months; a mid-sized site with many service pages or an online shop often takes about three to six months; a large or complex site, with integrations or several languages, can take six months or more.

The ranges move for known reasons. Content readiness is the biggest: writing and approving copy often takes longer than design. The number of approvers is next, because each added reviewer adds a round. Then come integrations, the number of templates, the quality of the old content and the migration work.

To keep to a range, fix three things at the start: a single decision maker, a deadline for content delivery and a limit on revision rounds. When one slips, the schedule slips with it, and you should be told so, not surprised.