This checklist helps you decide what actually needs to change, keep what already works, and check that an enquiry reaches the right place and the right person. It includes a decision table, a copyable launch worksheet, an old-to-new URL list and a manual enquiry test you can run with your web supplier. It is useful whether you end up refreshing a few pages or replacing the whole site.

1. Decide what needs to change before choosing a new design

Start with the problems, not the look. For each one, ask:

What is a customer trying to do that currently fails, or is harder than it should be?
What evidence do you have? For example, a missed enquiry, a confusing page, or feedback from a customer or colleague.
What already works and should be kept?

It helps to agree two working terms with your supplier. A refresh means targeted changes to content, design or a particular journey on the site you already have. A rebuild means broader structural or platform replacement. These are not fixed industry categories, but they make it easier to discuss scope and cost.

Do I need a whole new website?

Not necessarily. There is no single answer: it depends on what is failing and whether it can sensibly be fixed where it is. The table below is a practical decision aid, not a diagnosis.

What you have noticed	First useful action	When broader work may be justified
Services or contact details are out of date, but the editor still works	Update the key copy and contact details, then test the next step	The site structure cannot show your current services without confusing workarounds
The form shows a success message, but nobody can find the enquiry	Trace where it is sent, whether it arrives and who is responsible, then test again	A reviewed platform limitation prevents a reliable, maintainable route. One failed notification is not, on its own, that reason
A few pages are hard to use on a phone	Test and correct the affected layouts and forms	The problems run across the site and targeted repair is not a sensible option to maintain
The current platform is unsupported or difficult to maintain	Ask for a technical assessment with repair and replacement options	A supported, maintainable fix is not available, or is not justified compared with a clearly scoped rebuild
Enquiries arrive, but nobody owns the follow-up	Assign an owner, a backup and a next action within your existing way of working	This alone is not a reason to rebuild the website

If you think the site may have been compromised or has a security problem, get a competent assessment promptly. Do not leave a potentially compromised site running while you compare designs.

2. Record the pages and access you must keep

Before anything changes, write down what you already have:

current page addresses (URLs), especially service pages, the contact page and any page people often arrive on
content that is still useful, such as service descriptions, answers to common questions, and genuine reviews or accreditations
any evidence of which pages people find through search, if you have it
every form, and where each one currently sends its enquiries
important downloads, such as price lists or guides
who holds access to the domain, the website editor (CMS) and the hosting. Record the person or organisation responsible, never the passwords

Keep useful existing URLs where you can. There is no need to change a page address just to fit a keyword.

Where an address does have to change, you will need a redirect: an instruction that sends visitors and search engines from the old address to its proper replacement. Each old URL should point to the most relevant new page, rather than every old address pointing to the homepage, and each redirect should be tested.

Google's guidance on moving a site with URL changes covers mapping old URLs to new ones with redirects, and notes that rankings can fluctuate temporarily after a significant change. Planning the mapping reduces risk. It does not guarantee your rankings will stay the same.

3. Make the service and next step clear

When someone lands on a service page, they should be able to tell quickly:

what you do, and who or where you do it for
why they can trust you: genuine reviews, accreditations or examples you have permission to use
how to contact you, with accurate phone numbers, email addresses and opening hours
what the next step is, and what happens after they take it

Check this on a phone as well as a computer. Then try moving through the page and form using only the keyboard (Tab, Shift+Tab and Enter) to see whether you can reach every link, field and button.

Every form field should have a visible label. The GOV.UK Design System guidance on text inputs explains that labels should normally be visible, and that placeholder text inside a box should not be used in place of a label. Ask only for the information you genuinely need to respond well; there is no ideal number of fields.

You do not need to add new service or location pages to have a good redesign. Make the pages you already have clear first.

4. Agree where each enquiry goes and who handles it

A polished "thank you" message tells the visitor the form was submitted. It does not prove that a colleague received the enquiry. For each form, agree and write down:

Destination: the monitored inbox or existing queue where enquiries arrive
Owner: the person responsible for picking up new enquiries
Backup: who covers when the owner is away
Information needed: what the owner needs to respond without chasing
Next action: what happens next, for example a reply, a call-back or a quote request logged in your usual system

Keep three things separate, both on the website and within your team: the request has been received; a person will follow it up; and a booking has been confirmed. Sending a form does not book a call unless a separate booking step confirms one. If your confirmation message promises a reply time, check that your team can actually meet it.

If enquiries already arrive but nobody owns the follow-up, that is a working-practice fix, not a reason to rebuild the website.

5. Use the launch worksheet and run a manual test

Copy the worksheet below into a document or spreadsheet and fill it in with your supplier. Each check needs an accountable owner, evidence with a date, and a status: pass, fail or not tested. If a check has not been done, mark it "not tested" rather than guessing.

Work through it on the preview (staging) site first. Then repeat the critical checks, especially forms and important old URLs, on the live site after release. A check that passed on preview has not passed on the live site until it has been repeated there.

Launch worksheet, part 1: what is changing

Check	Current URL or route	Keep or change	Destination or replacement
1. Main service content and next action are accurate
2. Important existing URLs are kept, or mapped to relevant replacements, and the destinations open correctly
3. Domain, CMS and hosting access and recovery responsibility confirmed (record the owner, never passwords)
4. Enquiry form fields, labels, error messages and confirmation checked
5. Enquiry arrives in the agreed destination with the required details; the owner acknowledges it and records the next action
6. Phone and keyboard journey checked; telephone and booking links checked, if present
7. Supplier has checked launch indexing settings, internal links, and relevant sitemap and canonical settings; preview site stays protected
8. Recovery or rollback responsibility, and ongoing update and support boundaries, agreed

Launch worksheet, part 2: who checked it and what happened

Check	Accountable owner	Evidence and date	Pass, fail or not tested	Next action
1. Service content and next action
2. Existing URLs and redirects
3. Access and recovery
4. Form fields and confirmation
5. Enquiry received and owned
6. Phone and keyboard journey
7. Indexing, links and sitemap
8. Rollback and support boundaries

URL mapping

Old URL	Keep, change or remove	New relevant URL if changed	Redirect or test result	Owner

If a page is being removed and there is no genuinely relevant replacement, ask your supplier to handle the removal properly rather than redirecting it somewhere misleading.

Illustrative example only, not a completed test or a client result: /contact → existing enquiries queue → office coordinator → locate the TEST marker and assign a reply task → not tested.

Manual enquiry test

Agree a time with the person responsible for enquiries. Use clearly invented text marked TEST — website enquiry check, and an email address or phone number the tester controls. Never use a real customer's details or anyone else's contact information.
Test from a phone. Start on a normal service page and follow its main call to action. Check the field labels, then try one safe mistake, such as leaving a required field empty, to see whether the error message is clear. Then submit one valid test. Repeat the essential steps on a computer using the keyboard.
Record the details: the time, the page you started from, the device and browser, whether you are on the preview or live site, and the unique test marker. Note what the visitor saw after submitting. A success screen on its own does not count as a pass.
Confirm receipt. Ask the named owner to find that exact marker in the agreed inbox or queue and confirm the required details arrived. If an acknowledgement email is promised or set up, check that it arrived too. Confirm who owns the next step and who covers for them.
Do not resend blindly. If the form times out or you cannot tell whether it sent, check the destination before trying again, so you do not create duplicates. Treat "rejected", "unknown" and "confirmed received" as different results.
Record the result honestly. Mark a pass only for the path you actually verified. Otherwise record "fail" or "not tested", with an owner and a corrective action. Keep test records separate from real leads, and remove or archive them in line with your usual policy. Repeat the test on the live site after release.

6. Keep a short after-launch review

Launch is not the end of the checklist. Agree who will check, and when:

live forms still reach the agreed destination and owner
key old URLs still redirect to the right pages
broken links found after launch are fixed
pages meant to be public can be indexed. Google's site-move guidance includes removing any "noindex" setting used during development from those pages at launch
who makes routine content updates, and what support your supplier provides

If you recorded a baseline before launch, such as enquiry numbers or popular pages, compare it afterwards, but read any change in context. Seasonal patterns, campaigns and other changes all play a part, and rankings can move after significant changes. A before-and-after difference does not, by itself, show that the redesign caused it.

ScalePass helps service businesses connect their website, enquiries and everyday work. We start with one useful improvement, keep the tools that already work for you, and agree scope and cost before work begins.

Not sure whether to fix or rebuild? Explore how ScalePass can help with your website.