Website redesign checklist: planning a better business site

1. Define the problem the redesign must solve

A site looking dated is a starting point, but it does not tell a developer what to improve. Describe a customer task that is difficult today: finding the right service, checking delivery information, requesting a quote or paying for an order. Include an example page and explain where the journey breaks down.

Then write a short acceptance statement. For a service business, that could be a visitor finding the relevant service and sending an enquiry from their phone. For a shop, include choosing a product variation, seeing the full delivery cost and receiving an order confirmation. A working journey is something you can test together before launch.

2. Record what your current website gets right

Before changing pages, save a list of their addresses and note which ones bring enquiries, sales or search visits. Your analytics and Google Search Console provide different parts of that picture. Take screenshots of important layouts and export the content you need to retain.

A page with an old design can still answer a valuable customer question. Keep its useful information in the brief rather than allowing it to disappear because it does not fit a new template. Include downloads, product details and answers your team regularly sends to customers, not just the pages visible in the main menu.

3. Decide between a refresh and a rebuild

Match the size of the project to the problem. A confusing menu or a broken form calls for investigation before replacing the entire website. If you retain WordPress, establish whether the existing theme and plugins can support the new design without rebuilding every function.

A custom build becomes a different proposal: the developer creates the features your business needs and must explain how you will edit and maintain them. Ask for a demonstration of routine tasks, such as changing a price or adding a service page. A platform decision affects your daily work long after the design has been approved.

For an isolated WordPress fault, review the scope of a one-off repair before committing to a redesign. If the requirements really have outgrown the current site, carry the audit forward into a proper development brief.

4. Put pages, content and features into the brief

A page count does not describe the whole job. A booking page with availability rules and payment collection needs a different specification from a page containing a telephone number. List what each feature must do, which existing service it connects to, and what should happen when something fails.

• Page inventory: identify the pages to keep, revise, combine or retire, with a reason for each decision.
• Content responsibility: assign the writing, photography, product information and approvals to named people.
• Connected services: record forms, email delivery, payments, bookings and any customer records that need to move.
• Acceptance checks: describe the customer journeys and editing tasks that must work before you sign off.

Separate essential launch requirements from later improvements. That gives the developer a defined scope to price and gives you a way to assess a proposed extra charge without reopening the entire project.

5. How BuiltToWinWeb approaches a website redesign

BuiltToWinWeb builds custom business websites, online shops and web applications. Its approach brings the design and the working features into the same project, from the pages customers browse to the forms, bookings and payments they use.

Its custom website design service includes layouts that adapt to phones and larger screens, enquiry forms, online booking and payment integrations. For a service business, those are the practical details that turn a new design into a useful route from a first visit to an enquiry or appointment.

For online retailers, BuiltToWinWeb lists product search, shopping carts, payment processing, and sales and inventory management. Businesses with more specialised requirements can also commission web applications with customer accounts, dashboards, reporting tools and connections to other software.

The offering extends beyond the build itself. Its services include technical SEO, local search support, speed improvements, hosting setup and WordPress-to-custom-PHP migration. That gives you several areas to cover in the brief, particularly when a redesign also involves moving content or changing how the site is managed.

BuiltToWinWeb publishes flat-fee project packages and states that clients receive ownership of the source code. Use the proposal to pin down the pages, features, revisions and handover included in your project, with hosting and future support costs set out separately.

Bring a real customer journey to the conversation, such as booking an appointment with a deposit or ordering a product with several delivery options. Ask the team to walk through both the customer experience and the work your staff will do behind the scenes. You will then have a concrete way to judge the proposed design and test the finished site. For a UK project, confirm availability, communication hours and the currency of the quote directly.

6. Agree ownership and the full running cost

Keep the domain, hosting and key business accounts under your organisation's control, with individual access for the people working on the project. Agree what will be handed over: source files, content, database exports where relevant, design assets and instructions for publishing changes.

Ask for the project fee and ongoing costs separately. Hosting, domain renewal, paid services and future development still need a budget, even when a website has no monthly platform subscription. Establish what happens if you change developer and whether any licensed assets or tools have transfer restrictions.

7. Plan page addresses before the redesign goes live

Changing the appearance of a page does not require changing its address. Keep existing URLs where they still fit the content. For a page that moves, record the old address and its relevant replacement so the developer can set up a permanent redirect.

A redirect sends someone using the old link to the new page. Avoid sending unrelated retired pages to the homepage. Update internal links to their final destinations, and check that the new site's preferred URLs, called canonicals, point to the public site rather than the private preview.

Google's site-move guidance recommends preparing a URL map and monitoring the change. It also warns that rankings can fluctuate while changed pages are recrawled. Build those checks into the launch plan; a new design or a redirect is not a guarantee of retaining every search position.

8. Test the finished site as a customer

Use a private preview, sometimes called a staging site, to review the build before it replaces the public website. Test with the real copy and representative images. A page filled with short placeholder text tells you little about how a long product name or a detailed service description will fit.

• Complete an enquiry on a phone and confirm it arrives in the correct inbox.
• Try menus and forms using a keyboard, checking visible focus, labels and error messages.
• Check layouts at narrow and wide screen sizes, including long headings and tables.
• Run a test purchase or booking through the provider's test mode and verify the confirmation and cancellation paths.
• Review mobile and desktop performance on representative pages, including the scripts needed for the finished site.

Record failures with the page address, device and steps needed to reproduce them. Give each issue an owner, then repeat the failed journey after it has been corrected. A screenshot of a good score cannot establish that a checkout works or an enquiry reaches your team.

9. Prepare the launch and handover together

Before switching over, take a restorable backup of the current site and agree how to return to it if the launch fails. For a shop or membership site, plan how orders and account changes made during the move will be preserved. A backup taken before those transactions is not a complete record of them.

Assign one person to approve launch and another to carry out the agreed checks. Confirm public pages are accessible to search engines, private previews remain protected, the sitemap uses live addresses and forms still deliver from the production site. If hosting or domain settings change, include business email in the checks.

Finish with a practical handover: edit a page, publish a change and locate the backup and support instructions together. Keep the agreed scope and the final issue list with your account records so the next person responsible for the site can understand what was delivered.

10. Keep a website redesign checklist for the weeks after launch

Launch is the start of observation. Watch for broken links, undelivered enquiries and unexpected changes in sales or search visits. Compare equivalent periods and account for advertising, seasonality and changes to tracking before attributing a result to the redesign.

Agree who handles defects, how long launch support lasts and which later requests count as new work. For a retained WordPress site, include updates, backups and developer support in the ongoing maintenance plan. A custom site also needs a named owner for its hosting, software and recovery arrangements.

Keep the checklist with the project brief and record the outcome of each check. That leaves you with evidence of a working website and a clear route for resolving faults after handover.