Website Redesign Checklist for UK Small Businesses

A practical guide from the first brief to the weeks after launch

A website redesign can start with a simple frustration. The business has changed, but the website still describes the old services. Updating a page takes too long. Customers keep calling to ask questions that the site should answer.

The design may need attention, but a successful project also depends on decisions about content, existing search traffic, enquiry forms and the people who will manage the finished site. These details are easier to deal with before development begins.

This website redesign checklist is for UK small businesses planning to replace or substantially improve an existing website. It explains what to prepare, what to ask your developer and what to check before launch. You do not need to carry out every technical task yourself, but someone needs to own each one.

The website redesign checklist at a glance

Use this short list to keep the main stages in view. The sections below explain what each stage involves.

Agree the business problems the redesign needs to solve.
Record how the current website performs.
Confirm access to the domain, hosting and connected accounts.
Review existing pages and decide what to keep, improve or remove.
Agree the new page structure and essential visitor journeys.
Assign responsibility for copy, images and approvals.
Plan the design, mobile experience and editing tools.
Define accessibility checks and review data collection.
Prepare the SEO migration and redirect plan.
Test forms, integrations, tracking and key pages.
Agree the launch process, backup and recovery arrangements.
Check the live website and review results after launch.

Keep this list in the project document and give each item an owner. A task marked “the agency will handle it” is only useful if the agency has included it in the scope.

1. Define what the redesign needs to achieve

Write down the problems before discussing colours, fonts or layouts. “We need a more modern website” leaves plenty of room for interpretation. “Visitors cannot tell which service they need” gives the project a specific problem to solve.

Choose a small number of priorities. A local consultancy might want more relevant enquiries and clearer service information. A venue might need visitors to find availability or reach the booking system more easily. A shop might need better product information and a simpler checkout.

Separate business outcomes from delivery requirements. “Staff can update opening hours without contacting the developer” is a useful requirement. “Increase qualified enquiries” is an outcome that needs measurement after launch. The new site can support that outcome, but design alone cannot guarantee it.

Agree what is essential for launch and what can follow later. A long wish list can make it difficult to finish the work that matters most.

Before moving on, confirm:

The main audiences and what they need from the site.
The problems the project will address.
The features required for launch.
The budget range and any fixed deadline.
Who has the final say when decisions are needed.

2. Record what is already working

Before replacing the website, take a snapshot of its current performance. Otherwise, you may remove something valuable without realising it, or struggle to judge whether the new site has helped.

Review available analytics, search data and actual enquiries. Which pages bring people to the site? Which services generate useful leads? What questions do customers ask before buying? If tracking is incomplete, record what you can and note the gaps.

Look beyond the homepage. An older service page or a detailed guide may attract people who are ready to enquire, even if the page receives little attention internally.

Record the period covered by your figures. A quiet January and a busy December are not a fair before-and-after comparison for a seasonal business. Marketing campaigns, opening hours and changes in demand also affect the results.

Keep a baseline that includes:

Important landing pages and search queries.
Enquiry or sales figures where they are available.
Known problems with forms or booking journeys.
Screenshots of representative pages.
Feedback from customers and staff.

Do not discard useful content simply because the design around it looks dated. It may only need editing and a better layout.

3. Check account access and ownership

Account access can delay a redesign more than a difficult design decision. Find out who controls the domain name, hosting and website administration before setting a launch date.

Also identify access to analytics, Google Search Console and any booking, payment or mailing-list services. Use account invitations and appropriate permissions where available rather than sharing passwords through ordinary email.

Make sure the business can recover access if a supplier or member of staff leaves. Check which email address receives account notices and renewal reminders. An account attached to a former employee’s personal address needs resolving early.

Explain how business email is hosted. A website move may involve changes to domain settings, so the developer needs to know which records support email and other services. Moving the website does not necessarily mean moving email.

Confirm what you will receive at handover, including administrator access, documentation and information about paid licences. Ask how the website could be moved to another provider in future.

4. Review every important page

Create a content inventory before writing the new menu. For a small website, a spreadsheet may be enough. Include the current address, page purpose, content owner and proposed action.

Current content	Decision to make
Service pages	Is the service still offered and explained accurately
About and team pages	Are people, roles and photographs current
Articles and guides	Is the information useful, accurate and worth retaining
Contact and location pages	Are the details, opening hours and directions correct
Downloads	Are files current, readable and still needed
Products or events	Which records must be migrated or archived

Use clear decisions such as keep, rewrite, combine or remove. Record the intended destination when pages are combined. This helps the developer distinguish a deliberate removal from content that has been missed.

Check details that are easy to carry over without reading: old prices, discontinued services, former staff, expired offers and links to outdated documents. Confirm that you have permission to use the photographs and testimonials you plan to retain.

A redesign is also an opportunity to remove repetition. If three pages explain almost the same service, decide whether each serves a different audience or whether one stronger page would be clearer. Consider their existing traffic and links before making that decision.

5. Plan the page structure around customer tasks

Your navigation should help visitors find answers using language they recognise. Internal department names or clever labels can make a simple task unnecessarily difficult.

Write down a few realistic journeys. A potential customer might need to find a service, check whether you cover their area, see relevant work and send an enquiry. An existing customer might only need a phone number or a document.

Walk through those journeys using a rough page plan. You do not need finished designs to notice that a useful answer is missing or that a booking link is buried.

For each main page, agree its purpose and next step. A service page might lead to an enquiry form. An event page might link to ticket booking. Avoid making every page compete for several equally prominent actions.

Our web design service in Brighton includes planning the structure and visitor experience alongside the visual design. These decisions should be settled together, because the content determines what the layout needs to support.

6. Prepare the content before final design approval

A page designed around a short placeholder paragraph may not work when the final text arrives. Real content reveals the space, structure and editing options the website needs.

Agree who writes the copy and who approves it. If several people need to contribute, appoint one person to combine feedback and resolve conflicting comments. Give content deadlines the same attention as design deadlines.

Supply images in organised folders with clear filenames. Tell the designer which photographs are essential and which are only references. Check that the available images work at different screen sizes, especially if a wide photograph will also appear on a narrow mobile screen.

Before approving a page, check that it answers the questions a customer would bring to it. A service description should explain what is offered, who it is for and how to take the next step. Useful examples and precise details carry more weight than broad claims about quality.

Content preparation should include:

Approved text for the main pages.
Current contact details and service areas.
Usable photographs, logos and supporting files.
Agreed testimonials or project examples.
A named person responsible for each outstanding item.

7. Check mobile layouts and everyday editing

Review designs on a phone as well as a large screen. Look at the pages your customers will use, including services, forms and booking information. A homepage screenshot cannot demonstrate how the whole website behaves.

Try the main tasks with one hand on a small screen. Can you open the menu, read the text and complete the form without repeatedly zooming or scrolling sideways? Does a banner cover an important button? Is a telephone link easy to use?

Ask for a demonstration of the editing interface before the project is complete. If staff will add services, news or events, test those jobs using realistic content. Check how a long title, missing image or extra paragraph affects the layout.

For WordPress, agree which parts should be freely editable and which should follow a consistent structure. Clear fields and reusable layouts can reduce the chance of accidental formatting problems. The right approach depends on what your team needs to publish.

8. Build accessibility into the review

Accessibility needs attention while layouts and interactions are being developed. Leaving it until launch can turn basic corrections into expensive rework.

Start with practical checks: navigate without a mouse, confirm that keyboard focus is visible, enlarge the text and check that forms have meaningful labels and useful error messages. Review text contrast and provide appropriate alternatives for informative images and media.

The W3C accessibility checks are a useful starting point. They are an initial review, not evidence that a website is fully accessible. Automated tests also need to be supported by manual checks.

Agree the evaluation scope with your developer, including third-party booking or payment journeys. Record problems and assign fixes before approval. If you need a formal assessment, include that explicitly in the project scope.

9. Review forms and personal data

A redesign can change what information the business collects and which services receive it. Review each form and integration, particularly when introducing analytics, embedded media or marketing tools.

Ask whether each field is necessary. A first enquiry may not need a postal address, date of birth or a lengthy questionnaire. Make sure people understand what they are submitting and what happens next.

Check that the privacy information reflects the actual website and services in use. Review cookies and similar technologies against the ICO’s current guidance, including which purposes require consent and which may qualify for an exception. A visible banner alone does not establish that the implementation meets the applicable rules.

Test any consent controls against the website’s actual behaviour. Assign responsibility for the wording, configuration and review rather than assuming that installing a plugin completes the work.

10. Plan URL changes before development finishes

Preserve useful existing page addresses where practical. When an address must change, record the old URL and its relevant replacement. Have the developer implement permanent server-side redirects and test the mapping.

Avoid sending every removed page to the homepage. Redirect to a genuinely relevant replacement; if none exists, a proper not-found response may be appropriate. Update internal links to point directly to the final addresses.

Google’s site move guidance recommends preparing the new site, mapping changed URLs and monitoring after the move. Check canonical URLs, the sitemap and indexing controls as part of that work. Remove launch-blocking noindex settings from pages intended for search, and ensure public pages are accessible to crawlers.

Search visibility can fluctuate after URL changes. A migration plan reduces avoidable mistakes but cannot guarantee unchanged rankings. Retain the URL map so unexpected problems can be investigated after launch.

11. Test complete journeys on the staging website

A staging website is a separate version used for development and review. It allows the new site to be checked before it replaces the live one. Ask the developer to restrict access appropriately, particularly if it contains copied customer information.

Test complete tasks rather than simply opening pages. Submit an enquiry and confirm that it reaches the intended inbox. Check the confirmation shown to the visitor and any reply email. Try incorrect or incomplete entries to see whether the form explains how to fix them.

If the website takes bookings or payments, use the provider’s test environment where appropriate. Check successful and unsuccessful journeys, confirmations and the records received by the business. Repeat essential checks after switching to the live configuration.

Test representative pages for loading performance, including a page with several images and any page with external embeds. Ask the developer to investigate slow responses, oversized images or unnecessary scripts. A good result on one empty test page does not establish how the finished site performs.

Keep one issue list with the page, steps to reproduce the problem, expected behaviour and owner. Separate faults that block launch from small improvements that can be scheduled afterwards.

12. Confirm measurement and launch responsibilities

Agree what you will measure and how it will be recorded. Useful actions might include completed enquiry forms, bookings or sales. A click on a submit button is not always a successful submission, and a click on an email address is not proof that an email was sent.

Ask whoever configures tracking to demonstrate that it records the intended action without counting it repeatedly. Check the setup alongside any consent controls. Preserve access to historic data so future comparisons are possible.

Choose a launch time when the people needed to resolve problems are available. Avoid launching immediately before a major campaign or a period when nobody can monitor the site, unless there is a clear operational reason and support is arranged.

Before launch, agree:

Who takes and verifies the backup.
Who deploys the new website and changes domain settings if needed.
How recent content, orders or enquiries will be preserved during the change.
Who runs the live checks and records the results.
What would trigger a rollback and who can carry it out.
Who makes the final decision to proceed.

For a busy shop or booking site, recovery needs particular care. Restoring an older database can remove records created since the backup. The plan must account for new transactions rather than treating rollback as a simple undo button.

13. Check the live website immediately

Approval on staging is not the final check. The live site may use different service keys, email settings, domain restrictions or caching. Test the important journeys again on the public address.

Live check	What to confirm
Main pages	Correct content, images and navigation appear
Enquiry forms	A real submission reaches the intended destination
Bookings or checkout	The live journey and confirmations work
Old page addresses	Agreed redirects reach the correct replacement
Search access	Public pages have the intended indexing settings
Tracking	Agreed actions are recorded correctly
Email and connected services	Existing services still work after domain changes
Editing	Staff can log in and make an ordinary update

Check from a phone and a desktop browser, including a browser where you are not logged in. Confirm that visitors see the intended version rather than an old cached page or a maintenance screen.

Record the launch date and any known issues. Give each unresolved item a person responsible and a target date.

14. Review the first month after launch

Keep checking enquiries, customer feedback and technical issues during the first few days. If submissions suddenly disappear, test the form before assuming demand has changed.

Over the following weeks, review key landing pages and search visibility alongside the baseline. Investigate significant changes by page and query rather than relying only on a site-wide traffic total. Confirm that measurement is working before drawing conclusions.

Ask the people who update the website what is difficult. Small improvements to instructions or editing fields can prevent repeated mistakes. Record any new customer questions that the content should answer.

Finally, establish ongoing responsibility for updates, backups and support. A redesign does not remove the need for routine care. Our website maintenance service can support that work after launch.

Common questions about website redesigns

Do we need a complete rebuild

Not necessarily. If the underlying website is maintainable and the problems are limited to content or a few templates, targeted improvements may be sufficient. Ask for an assessment of the existing site before committing to a rebuild. The proposed work should follow from the problems identified.

How long does a small business website redesign take

The schedule depends on the scope, content readiness, integrations and approval process. Ask for a timetable showing your responsibilities as well as the developer’s work. A launch date based on content arriving promptly will need revisiting if that content is delayed.

Can we keep the existing domain name

Usually, yes. A new design does not require a new domain. If you are also changing the business name or domain, make that part of the brief because it adds migration and communication work.

Will a redesign improve our search rankings

It may help if it addresses issues with content, usability or technical implementation, but a redesign is not a ranking guarantee. Removing valuable content or mishandling changed URLs can create problems. Agree the search-related work explicitly and monitor the results.

Who should approve the finished website

Appoint one person to give final business approval after collecting feedback from the relevant colleagues. The developer should confirm completion of the agreed technical checks. Keep both responsibilities visible so visual approval does not accidentally substitute for functional testing.

Planning a website redesign

If your website no longer reflects the business or makes everyday tasks difficult, start with a review of what needs to change. Bring the current website address, the problems you have noticed and the tasks customers need to complete.

Contentscape provides web development and website design for businesses and organisations. Book a website review to discuss the existing site, the priorities for a redesign and a practical scope for the work.