What Should You Prepare Before a Website Redesign?

Before a website redesign starts, gather the information your team will need and record the decisions that shape the work. This checklist covers what to prepare, with a fictional example to show how the pieces fit together.

1. Set goals for the redesign

Decide what the redesign should improve. You might want to make the site easier to use, improve search visibility, support sales or bring the design into line with a new brand identity. A clear goal gives the team a basis for deciding what to build and how to assess it.

If you want more people to sign up, record the current signup rate before work begins. Set a measurable target that reflects the needs of the business, and decide how you will compare results after launch.

2. Inventory and review your content

List your pages, articles, products and media files. Start with a sitemap or an export from your content management system. Review each item using its traffic, engagement, accuracy and last update, then decide whether to keep, revise, merge or remove it.

Look closely at pages people already use. Check that the new site preserves the information and actions that make those pages useful. Merge outdated or overlapping material where doing so makes the new structure easier to navigate.

3. Map the current URLs

Make a list of existing URLs using a crawl tool such as Screaming Frog or an export from your site. For every address that will change, record the appropriate destination and test the redirect before launch.

Give important pages and high-traffic URLs extra attention. Use the map to review the effect of changes on visitors and search engines and to reduce the risk of broken links during migration.

4. Review traffic and user behaviour

Use Google Analytics, Matomo or another available source to examine page visits, navigation paths, page performance and the steps where visitors leave. Use those findings to decide what needs more attention in the redesign.

If your data is incomplete, review a sample of key pages and observe a few people using the current site. Record the limits of the sample so the team can distinguish observations from questions it still needs to answer.

5. Name the decision-maker and define acceptance criteria

Agree on who makes the final decision and what the team must demonstrate before handover. Depending on the project, the decision-maker could be a founder, product manager or technical lead. Acceptance criteria can cover design, performance, search and behaviour on specific devices.

Write those criteria as checks someone can run. For example, a visitor should be able to complete the quote request on a phone and understand what to fix if a required field is missing. Agree on the checks before work starts and run them at handover.

6. Arrange access and infrastructure

List the accounts needed for hosting, the domain, the CMS and analytics. Identify who can grant each access and when the team will need it. Confirm the handoff with the technical or support team ahead of the work so missing access does not hold up a migration or launch.

7. Record constraints and plan around gaps

Identify missing documentation, incomplete access, thin analytics and limits on budget, time or staffing. Give each gap an owner and agree on a fallback. A manual review of priority pages, for instance, can provide a starting point while tracking is being restored.

Agree on how the team will assess scope changes. Adding a new integration or a second language can change both the cost and the schedule, so discuss the effect before adding it to the launch plan.

8. Worked example: Ava, a fictional retailer

Ava plans to redesign its online store. Its team exports the page and product lists from the CMS and reviews the data. Most visits come from phones, and several pages already convert well. The redesign focuses on making mobile shopping easier, with a higher purchase rate as a goal to measure after launch.

The CEO owns the final decision. The team documents what mobile shoppers must be able to do at handover, records the current purchase rate for later comparison, and arranges hosting and analytics access before kickoff.

Bring a one-page brief to kickoff

Write down the current problem, the main audience, three tasks users need to complete and the five existing pages that matter most. Add your baseline data, time and budget constraints, final decision-maker and a testable acceptance criterion.

Turn a goal such as “a more modern site” into an observable task, such as finding a product on a phone. Track sales after launch, and use testable behaviour to assess the handover itself.

Discuss your redesign with Ravand

Bring your brief to a conversation about the next version of your website. Start a conversation with Ravand, or see the Thermopex project for an example of our work.