First find out what's wrong with your site
Improving a website does not always mean rebuilding it. Clearer copy and a better layout may be enough when visitors cannot understand your services or find the information they need. A new technical foundation becomes worth considering when the existing site prevents necessary features or makes maintenance impractical. Identify the problem first, then compare a targeted fix, a redesign and a full rebuild against that specific need.
First find the breaking point. Just because there is fewer enquiries or the analytics results do not meet expectations does not mean that a new site is required. A change in measurement, a broken form, or a different audience can also lead to the same result.
Seven concrete signs to consider a redesign
1. Your site no longer describes the service you offer
If the site shows the old content even though the business's services have changed, the content needs to be renewed. Customers may be coming to the meeting with the wrong expectations. First determine which pages contradict current information. Consider whether the problem will be resolved by simply updating the text or with a new page structure.
2. Visitors cannot complete basic tasks
If it becomes difficult to find services, review samples, or submit requests, test the usage flow. Try to reproduce the problem on the device where it occurs. A single broken component may not require replacing the entire site; but widespread and interconnected problems may prompt more comprehensive changes.
3. Mobile layout not working with real content
If titles are overflowing, fixed elements cover the form, or the menu is unavailable, the mobile experience should be examined. It's not enough for the design to look good on the desktop. Try the most important pages through the task on the phone and check the completion of the process, not just the display.
4. Updating content becomes unnecessarily difficult
If a minor service change requires ongoing complex technical intervention, re-evaluate your management needs. The problem may be due to lack of training, access permissions, or content model. Start by demonstrating a routine task; don't assume that the solution is necessarily the completely new platform.
5. Repeated malfunctions take up business time
If form, connection or integration problems keep returning, the root cause should be investigated. Record the date of errors and their impact on the business. A system with accumulating temporary fixes may need a better maintenance plan or replacement of specific components.
6. Brand identity is scattered across pages
Different logo versions, inconsistent tone of voice, and random components can undermine the common look. First, determine the current identity rules. Examine whether these rules can be applied on the current site. Sometimes a common design system can be established without changing the entire infrastructure.
7. New needs cannot be met with the current structure
If adding a new language, content type, or customer action keeps getting blocked in the current structure, consider technical options. Explain the requirement with a concrete scenario. If a smaller connection or section change is not sufficient, a redevelopment plan can be prepared. The decision should be based on the actual limitation, not the age of the technology.
If you have several of these signs, you can start the renewal conversation with concrete examples. Next to each sign, write the customer task it affects and the possible small solution. This gives the business and the prospective provider a shared understanding of the problem. The review serves to determine what changes are needed, not to prove that the entire site is bad.
A minor fix, new design, new infrastructure?
Project names may vary between suppliers. A redesign can involve substantial work on structure, accessibility and user journeys, as well as changes to colours. Redevelopment changes a significant part of the application; but can keep the same CMS, content and URLs.
Ask each supplier to explain what will stay, what will change, and why. The platform decision and the design decision are related, but not interchangeable.
Three approaches to improving an existing site
| Approach | Typical scope | Evidence to be requested |
|---|---|---|
| Targeted correction | Fix a form, integration, template or performance bottleneck | Reproducible problem and test to see if the fix works |
| Design renewal | Reviewing content, navigation, page layouts and visual identity | User journey findings and verification that the current system supports the changes |
| Redevelopment | Changing a significant portion of application code or platform components | Documented limitations, evaluated alternatives and transition plan |
Record the starting position before making changes
Identify important tasks: finding a service, submitting a request, completing a purchase, or updating a product. Test these on devices representative of your usage. Check that successful submissions actually arrived and that the team was able to complete routine content changes.
Compare traffic sources, types of enquiries and relevant periods. Take into account measurement variations and seasonal demand. Record the actual number of enquiries as well as the conversion rate.
Also add up recurring errors, maintenance effort, and hosting disruptions. The audit should link proposed changes to evidence rather than turning every defect into a reason to change the site.
When is it enough to refresh the design?
The service you offer may have changed, your brand may be appearing inconsistently on the site, or visitors may be having trouble understanding what to do. If your infrastructure is still suitable for content publishing, integrations, and maintenance, you can preserve it by refreshing the design. This way, you won't have to deal with any unnecessary migration work.
First try the visitor's most important action in a prototype with real content. Can they find the service they need, understand the examples and get in touch? Check for error messages on the form, as well as for phone and keyboard use.
Compare fixing a few sections versus revamping the entire design. Don't assume one is necessarily cheaper. A refresh that requires extensive content work may be more work than a small site rebuild. Find out what things will cost and what preparations are needed.
When is it necessary to redo the site?
If you cannot develop the features you need in the current infrastructure or if out-of-support components create a serious maintenance burden, you can consider the redevelopment option. Repeated failures, difficulty in changing data, and unreliable integrations should be investigated; these issues alone do not establish that a rebuild is necessary.
First ask whether a version update, changing a component, or improving a specific part of the code would be enough. If a new and complex workflow is required, try the hardest part with a prototype before choosing a platform.
Newly written code does not automatically become more secure, faster or scalable. Access permissions, updated dependencies, recovery from backup, monitoring and realistic load tests are still required. Don't keep existing security vulnerabilities waiting while you plan the big project. Headless architecture may also be an option; however, it should be explained why the additional system and maintenance work it brings is necessary.
Use performance metrics to find the cause
Google PageSpeed Insights combines real user data with simulated lab tests when available. Use field data to understand people's lived experience and laboratory findings to investigate repeatable problems. A small site may not have enough publicly available field data.
Core Web Vitals cover loading, responsiveness to interactions, and stability of page layout. Evaluate field results separately for mobile and desktop; the lab score does not replace these measurements.
Ask about the source of the delay before approving the rewrite. Large media files, third-party scripts, or a slow integration may require targeted work. Identify which pages and visitor tasks need improvement; compare the proposed implementation with the starting position.
Let's think through two examples
These scenarios illustrate the decision process. They are not Pixel Shield case studies or promises of results.
A consultancy company that cannot explain its services well on its website
Let's say a consulting company has a supported CMS and a reliable form, but their service pages are unclear and difficult to use on mobile. The refresh can clarify the offer and enquiry process. Record the starting position, then check whether visitors can complete their tasks and whether enquiries match the services you offer. Compare results with similar traffic sources and periods.
A retailer having issues with promotions and manually updating stock
Imagine a retailer whose site is disrupted by campaign traffic and whose staff is constantly copying stock data between systems. Investigate capacity, database behaviour, and integration errors. Targeted remediation, partial replacement or redevelopment may be appropriate. Measures of success may include reliable test purchases at the agreed load and reduced measured time spent correcting stock records.
Treat automation as a separate requirement
Manually copying from the contact form to the CRM does not necessarily require redeveloping the site. A supported connection or a small integration could fix the problem. Determine what data is transferred when, who can access it, and what happens if the receiving service is down.
Test retries, duplicate records, and human checking when necessary. Assign responsibility for the integration after launch. Redevelop not just because automation is desired, but when the overall system makes a suitable solution impractical.
Plan search visibility and data migration based on actual changes
Risk depends on what changes rather than the name given to the project. Google's URL migration guide recommends matching old pages to relevant targets, using permanent server redirects if possible, updating internal linking and canonical references, and submitting the new sitemap. It also recommends monitoring the migration and taking into account that there may be temporary ranking fluctuations. Whenever possible, do not make major independent changes at the same time.
Test the new environment even if the URLs do not change. Google's hosting migration guide includes checking pages, forms and files before migration, then verifying that pages load correctly and crawlers can access them.
Also determine who will check transferred records, content integrity, and access rights. Rehearse the transition and prepare a rollback plan, including how incoming enquiries or orders will be handled during this time.
Compare proposals with the same criteria
If possible, ask for a written proposal that explains minor fixes, design refresh, and redevelopment as separate options. Compare what will be done for development, content, testing, migration, training and maintenance. Also consider your own team's time and the cost of running old and new systems together during the transition.
Summarise the redesign decision in a one-page record
At the end of the review, prepare a decision record with three columns: to be preserved, to be changed, and still to be investigated. Items to preserve might include content, addresses, or management habits that work well. Each proposed change should be linked to a specific problem. Do not present uncertain areas as definitive decisions.
For example, if the service text is outdated, the decision to update it may be obvious. However, if it is not known why enquiries have declined, record it as an issue to investigate. Checks of analytics or form delivery may be required before starting the new design. This distinction prevents all problems from automatically turning into a design project.
Include an acceptance criterion for each suggestion. Tasks such as finding a service in the new menu, sending a test message to the form, or allowing the editor to add a project can be used. Knowing when delivery will be considered successful makes the scope of the project more understandable.
Finally, list the work that needs to continue during the transition. Incoming requests, existing connections and team access should not be forgotten when preparing the new site. It should be planned which version and data to use when rollback is required. Renewal is not just about preparing a new look, but also about changing the digital systems of a business that remains in operation in a controlled manner.
You can share the decision record with all prospective providers. Thus, each provider responds to the same needs. If one proposes minor correction and the other proposes redevelopment, you can compare their justifications based on the same problems. Having a different approach is not a problem in itself; unexplained differences in scope create problems.
After the refresh, compare the old and new experience with the same task. Seeing that the problem you previously noted has actually been fixed is different from just liking the new look. Have the content management team also experiment with daily operations. If the management side is getting harder while the customer side is improving, additional adjustments may be necessary. The final evaluation should cover the use of both the visitor and the business. This check also shows which areas are prioritised for further development.
Let's examine together what your site needs
Share with us your current site, the problems you are experiencing and how you want the site to contribute to your business. Let's evaluate together whether it would be more appropriate to renew the design, change the infrastructure or fix a few problems.
Frequently asked questions
Is renewing a design always cheaper than redeveloping it?
No. Compare actual scope, content work, integrations, testing, and ongoing costs. The name of the project does not determine which option requires less labour.
Should a slow site be redeveloped?
Not always. Diagnose the cause first and test targeted fixes. Redevelopment makes sense if verified limitations make the required improvements impractical in the current system.
Can we keep our CMS and existing page addresses?
Most of the time yes. Agree this clearly in the brief and test the delivered site. Keeping the CMS or URLs does not remove the need to check content, functionality and search engine accessibility.
