Choose the change that addresses the problem
A redesign makes sense when your website’s main weaknesses are its content, navigation or presentation and the underlying system remains suitable. A rebuild deserves consideration when confirmed technical limitations make important requirements difficult to deliver or maintain. Sometimes a targeted repair is enough.
Start with the problem you can demonstrate. Falling enquiries or disappointing analytics do not, by themselves, tell you which route to choose. A tracking change, a broken form or a different audience could explain the result without requiring a new website.
Define what redesign, rebuild and repair mean
Project labels vary between suppliers. A redesign can include substantial work on structure, accessibility and user journeys; it is more than changing colours. A rebuild replaces a significant part of the implementation, but it can retain the same CMS, content and URLs.
Ask each supplier to identify what stays, what changes and why. A platform decision and a design decision are related, but they are not interchangeable.
| Approach | Typical scope | Evidence to request |
|---|---|---|
| Targeted repair | Fix a form, integration, template or performance bottleneck | A reproducible problem and a test showing whether the fix resolves it |
| Redesign | Revise content, navigation, page layouts and visual identity | User-journey findings and confirmation that the retained system supports the changes |
| Rebuild | Replace substantial application code or platform components | Documented limitations, alternatives considered and a migration plan |
Establish a baseline before approving the project
Record the important tasks: finding a service, submitting an enquiry, completing checkout or updating a product. Test them on representative devices. Check whether successful submissions actually arrive and whether the team can complete routine content changes.
Compare traffic sources, enquiry quality and relevant time periods. Keep measurement changes and seasonal demand in mind. Record the count of genuine enquiries alongside any conversion rate.
Collect recurring errors, maintenance effort and hosting incidents too. An audit should connect each proposed change to evidence, rather than turn every imperfection into a reason to replace the site.
When a redesign is the stronger starting point
Consider a redesign when the offer has changed, the brand feels inconsistent or visitors struggle to understand the next step. If the existing system supports publishing, integrations and maintenance, retaining it can avoid unnecessary migration work.
Prototype the most important journey with realistic content. Can visitors identify the right service, understand the evidence and complete the contact step? Include mobile layouts, keyboard use and clear form errors.
Compare a focused redesign with smaller improvements. There is no fixed cost advantage: a large redesign with extensive content work may exceed the scope of a small rebuild. Ask for costs and dependencies for the actual work.
When rebuilding becomes a reasonable option
A rebuild may be justified when essential requirements conflict with the current architecture, or keeping unsupported components creates an unacceptable maintenance burden. Repeated failures, difficult data changes and unreliable integrations are reasons to investigate, not automatic verdicts.
Ask whether an upgrade, component replacement or focused refactoring would solve the problem. For a major new workflow, test the hardest requirement in a prototype before committing to a platform.
New code is not inherently safer, faster or easier to scale. Specify access controls, supported dependencies, backup recovery, monitoring and realistic load tests. Address confirmed security issues promptly while planning the longer project. Headless architecture is one possible approach; its extra systems and maintenance need a business reason.
Use performance measurements to identify the cause
Google’s PageSpeed Insights combines real-user data, where available, with simulated lab tests. Use field data to understand the experience people receive and lab diagnostics to investigate repeatable problems. A small website may not have enough public field data.
Core Web Vitals cover loading, responsiveness and visual stability. Assess field results separately for mobile and desktop; a lab score is not a substitute for those measurements.
Ask what is causing the delay before approving a rewrite. Large media, third-party scripts or a slow integration may need targeted work. Agree which pages and customer tasks must improve, and test the proposed implementation against that baseline.
Two hypothetical examples
These scenarios illustrate the decision process. They are not Pixel Shield case studies or promised results.
A consultancy with a confusing service website
Suppose a consultancy has a supported CMS and a reliable form, but its service pages are vague and difficult to use on mobile. A redesign could clarify the offer and improve the enquiry journey. Establish the baseline first, then assess task completion and qualified enquiries. Compare the results against similar traffic sources and time periods.
A retailer with campaign failures and manual stock updates
Imagine a retailer whose website fails under campaign traffic while staff repeatedly copy stock data between systems. Investigate capacity, database behaviour and integration failures. A targeted fix, partial replacement or rebuild could be appropriate. Success criteria might include reliable test purchases at an agreed load and less measured time spent correcting stock records.
Treat automation as a separate requirement
Manual copying from a contact form to a CRM does not necessarily require a rebuild. A supported connector or a small integration may solve it. Specify which data moves, when it moves, who can access it and what happens when the receiving service fails.
Test retries, duplicates and human review where needed. Include ownership of the integration after launch. Rebuild only when the wider system makes a suitable solution impractical, not simply because automation is desirable.
Plan search visibility and data migration around the actual changes
Risk depends on the changes, not the project label. Google’s URL-migration guidance recommends mapping old pages to relevant destinations, using permanent server redirects where possible, updating internal links and canonical references, and submitting the new sitemap. It also advises monitoring the move and expecting possible temporary ranking fluctuations. Avoid combining unrelated major changes where practical.
Even if URLs remain unchanged, test the new environment. Google’s hosting-migration guidance covers checking pages, forms and files before switching, then monitoring delivery and crawler access.
Separately, agree who checks migrated records, content completeness and access permissions. Rehearse the switch and define a recovery plan, including how to handle submissions or orders received during the transition.
Compare proposals against the same decision checklist
Ask for a written recommendation covering repair, redesign and rebuild where feasible. Compare implementation, content work, testing, migration, training and ongoing maintenance. Include your team’s time and the cost of operating old and new systems during the transition.
Choose the next useful step
Start with your website, the problems you can demonstrate and the work your business needs it to support. Pixel Shield can help assess the design and development scope. Contact the team to discuss the evidence and a proportionate next step.
Frequently asked questions
Is a redesign always cheaper than a rebuild?
No. Compare the actual scope, content work, integrations, testing and ongoing costs. The project label does not establish which option requires less work.
Does a slow website need to be rebuilt?
Not necessarily. Diagnose the cause and test targeted fixes first. A rebuild becomes relevant when confirmed limitations make the required improvements impractical within the existing system.
Can we retain our CMS and existing page addresses?
Often, yes. Agree this explicitly in the brief and test the delivered site. Retaining a CMS or URL does not remove the need to check content, functionality and search accessibility.
