Website redesign or a smaller refresh?
A practical way to separate content and usability problems from platform limitations, so you can decide what actually needs to change before commissioning a rebuild.
DS Agency · 21 September 2026 · Written with AI assistance
Describe the problem before choosing the solution
Write down what feels wrong about the current website, then turn each concern into something another person can observe. Instead of saying that the site looks old, note that the service page describes an offer you no longer sell, the menu is difficult to read on a phone, or the contact button is hard to find. Keep aesthetic preferences separate from broken functionality.
For every problem, record the affected page, the action a visitor is trying to take and what actually happens. A simple list is enough to begin. Ask someone unfamiliar with the site to complete a realistic task without your guidance, and record where they hesitate. Their experience can suggest questions to investigate; it does not establish what every visitor does.
Illustrative example: a local bakery wants visitors to enquire about celebration cakes. Its cake page has attractive photographs, but the only contact link is in the footer and the copy does not explain what details to send. This is a specific content and navigation problem. It does not by itself demonstrate that the whole site needs replacing.
Test the enquiry journey manually
Start from the page a prospective customer is likely to land on. Read it as someone who does not already know the business. Check whether the offer, next step and contact method are understandable. Follow the links on a phone and with a keyboard. Note clipped text, unreadable labels, broken links or controls that you cannot use.
If you own the site and can access its enquiry destination, make a clearly labelled test submission and verify its receipt. Seeing a success message in the browser is only part of that check. Record who monitors enquiries and whether the form asks for information needed to respond.
Distinguish observation from explanation. You can observe that a button is missing or a test enquiry did not arrive. You cannot conclude that a particular design choice caused lost sales from that observation alone. Existing visitor data may help you investigate, but a visual inspection is not a conversion forecast.
Separate editable problems from structural limits
Ask the person maintaining the site which problems can be fixed within the current system. Updating copy, reorganising a service page, replacing an image or making a contact link clearer may be possible without a rebuild. Request a small demonstration on a staging copy where practical, and confirm that the person responsible for future updates can maintain the result.
A broader rebuild may deserve investigation when essential requirements cannot be supported reliably by the current structure. Explain the actual requirement first: different content for several locations, a needed booking integration or a manageable translation workflow. Ask the developer to identify the constraint and compare the options.
An outdated theme or plugin is a maintenance issue to assess, not automatic evidence that a new platform is necessary. Establish whether supported updates, configuration changes or targeted repairs can address the problem. A replacement platform also needs maintenance, content migration and testing; changing technology does not remove those responsibilities.
Compare the same scope in both proposals
Prepare a short list of must-have outcomes and ask for two clearly scoped options where both are technically feasible: a targeted refresh and a rebuild. Each option should explain the pages affected, content responsibilities, review stages, testing, launch process and ongoing maintenance. Ask the provider to distinguish required work from optional improvements.
Compare the actual estimates you receive. Avoid relying on a general price multiplier or a promised return from redesign alone. A refresh can still become substantial if the underlying work is poorly understood, while a carefully limited rebuild may be appropriate in some circumstances. The scope and constraints matter more than the label.
For a rebuild, include the handling of existing page addresses, redirects, content, enquiry destinations and access ownership. For a refresh, identify the limitations that will remain. If a proposal depends on an assumption, ask what happens if that assumption proves wrong before deciding.
Choose a first step and define acceptance checks
Choose the option that addresses the observed problems and the requirements you can describe now. Record the reasons for the decision and the unresolved questions. When the uncertainty is concentrated in a small part of the site, a limited investigation or prototype may help before committing to a larger project.
In the illustrative bakery example, the owner could first clarify the cake enquiry instructions and make the contact route visible from the cake page. They would then test that journey and verify that enquiries reach the intended recipient. This is a proposed experiment, not a claim that the changes will produce more customers.
Define what completion means before work begins: the agreed information is present, the important links work, the enquiry destination has been checked and the owner knows how to update the changed content. Agree on backups, testing and a way to recover from a failed release. Use the results of the work to inform later decisions rather than treating a redesign as a one-time answer to every business problem.
Your working checklist
- List observable problems and the pages where they occur.
- Separate business requirements, broken functionality and visual preferences.
- Test the important visitor journey on a phone and with a keyboard.
- Verify receipt of a clearly labelled test enquiry when you control the destination.
- Ask what the current platform can support and what its specific limits are.
- Compare proposals with matching content, testing and maintenance responsibilities.
- Check migration and redirect requirements before replacing existing pages.
- Agree on acceptance checks, update ownership and recovery arrangements.
About this guide
This is general project-planning guidance, not a forecast of traffic or sales. Examples are illustrative. The agency links below describe our services and portfolio; they are not independent research validating every recommendation.