A slow or hard-to-edit website does not always need replacing. Seven practical checks can reveal whether improvement or a rebuild will deliver the most business value.
Three separate interventions—a CMS change, custom-written code and manual support from a developer—to publish a single campaign form are a clear warning sign. The problem is then unlikely to lie in the website’s colours, typography or homepage, but in a structure where content, design and functionality have become entangled. For a small or medium-sized business, this means that even simple marketing initiatives can become slow, difficult to estimate and dependent on a particular supplier.
Many business websites can still be improved incrementally, especially if working integrations can be left untouched while the navigation, templates and front end are replaced. Others have legacy WordPress themes, page builders and plugins that trigger knock-on errors as soon as someone updates PHP, changes a form or adds a language. The difference is rarely visible in a screenshot; it only becomes apparent when you review dependencies, the information structure and the cost of the changes the business is planning over the next two years.
The decision should therefore not begin with whether the website looks old, but with whether its weakest parts can be replaced without affecting the rest. A technically sound but visually outdated website can often be improved at a reasonable cost. However, if the publishing workflow, page structure and integrations are all working against the business, a cosmetic refresh risks becoming an expensive layer on top of the same limitations.
Can the website’s weakest parts be replaced without breaking everything else?
Start with a technical review of the CMS version, PHP or server environment, theme, templates, forms, plugins, external APIs and connections to systems such as CRM, order flows and login services. A dependency map should show which functions use custom plugins, specific database fields or code that lacks documentation and a clear owner. Incremental improvement is reasonable when the navigation, page templates and front end can be changed separately while business-critical flows can be tested and left intact. When a routine CMS or PHP update breaks critical plugins, or when the same contact details must be changed manually on dozens of pages because they are hard-coded into the theme, the technical debt has become systemic. Ask the supplier to show which dependencies can be retained, replaced or retired, and how each option affects testing, operations and future updates.
When the information structure works against business goals, a new design is not enough
Review how a visitor moves from a landing page to the right offer, proof points and contact route—not just how individual pages look. If the menu uses internal department names such as “Process”, “Solutions” and “Advisory” while customers are searching for a specific problem or service, the navigation needs to be rebuilt around real search and purchase intent. A company that has moved from one core service to several customer segments may also need a new content model in which languages, industries and offers can be combined without building every page by hand. Standalone bespoke layouts make every new offer expensive, while reusable page types with structured fields for audience, problem, proof and CTA make publishing faster and results easier to compare. An improvement is often sufficient, however, when the main structure still reflects the business and the shortcomings mainly involve weak copy, unclear calls to action or unnecessary steps in forms.
Calculate the cost of two years of changes—not just the next launch
Compare the options over 24 months and include recurring developer hours, licences for overlapping plugins, operational incidents, internal content time and delays in publishing campaigns. An improvement with a low launch price quickly becomes expensive if every landing page continues to require custom code, testing across multiple templates and help from an external developer. Therefore, include the business’s planned changes—such as a new language, a CRM integration and a new service area—in both the improvement and rebuild calculations, and assess whether the platform can support them without modifications to its core. A rebuild also needs a concrete migration plan with exported URLs from the sitemap and analytics data, a map of inbound links and organic landing pages, and defined 301 redirects before the old structure is removed. Set the decision criteria before requesting proposals: if the existing solution fails to meet several business-critical requirements, a rebuild is easier to justify, but if the problems can be isolated, incremental change may offer lower risk.
Three paths: incremental improvement, replatforming or a complete rebuild
The right path depends less on how the website looks and more on its dependencies, information structure and future need for change. Compare the cost, launch risk and internal workload over at least two years, including any period during which old and new technology may need to operate in parallel.
Strangler Fig Pattern
With the Strangler Fig Pattern, the website is replaced one part at a time rather than through a single major launch. For example, the company can begin with forms or product pages, measure the results and then migrate the next clearly defined function.
- Reduces launch risk because forms, search or product pages can be replaced and measured separately.
- Spreads investment and content work over time instead of requiring one large upfront effort.
- Old and new solutions often need to coexist, which can result in duplicate templates, integrations and analytics flows.
- Does not fix a flawed information structure if the team only replaces components without reconsidering the navigation and content.
Best for: A business-critical website where some parts work well, but clearly defined functions create costs or risks.
Replatforming to WordPress with Gutenberg
Replatforming moves content and functionality to a more modern WordPress foundation without requiring the business to choose an advanced, fully decoupled architecture. Custom Gutenberg blocks can give editors clear building blocks while keeping brand rules and conversion patterns consistent.
- Gutenberg and custom blocks can give the marketing team greater independence without requiring development for every new landing page.
- The large ecosystem makes it relatively easy to find expertise and standard integrations for forms, SEO and CRM.
- Too many third-party plugins can lead to higher maintenance costs, security risks and hard-to-manage dependencies after two years.
- Migration normally requires more content clean-up, redirect work and quality assurance than the initial technical proposal suggests.
Best for: Organisations where the current CMS is slowing down publishing and further development, but where the requirements can be met with a well-managed WordPress installation.
Greenfield Rebuild with Content-First Information Architecture
A greenfield rebuild begins with customer journeys, content types and business goals before page templates and technology are selected. The method offers the greatest freedom, but requires the business to make more decisions about content, ownership and future ways of working before development begins.
- Makes it possible to structure the website around customer journeys and business goals instead of inheriting old departmental and menu systems.
- Can eliminate technical debt and create a clearer foundation for new markets, languages, services and integrations in the years ahead.
- Has the highest initial cost and requires extensive decisions about content, responsibilities, SEO migration and future ways of working.
- Big-bang launches involve greater risk; delays often occur when content production and internal approvals are underestimated.
Best for: Companies where both the technology and information structure work against the business, or where the changes planned for the next two years cannot be accommodated by the current solution.
Choose the Strangler Fig Pattern when the problems can be isolated and the business needs a low-risk launch. If the editorial workflow is the main problem, replatforming to WordPress is often a sensible choice, while a greenfield rebuild should be reserved for situations where the structure, technology and future business requirements all need to change at the same time.
How to decide whether to improve or rebuild your website
-
Test a clearly defined change before approving an improvement project
Ask the supplier to replace a critical component, such as the contact form or header, in a staging environment created with WP Staging, Local or an equivalent tool for your CMS. Track which templates, stylesheets and integrations need to be changed while also testing other key flows. If the test requires changes to more than three templates, creates CSS conflicts or disables other functions, the website is probably too tightly coupled for a cost-effective improvement.
-
Map dependencies with a technical inventory
Export all URLs with Screaming Frog and record the CMS version, integrations, forms, tracking scripts, custom code and plugins in a spreadsheet. Mark each component as retain, replace or retire, and request a time estimate for analysis, development and testing for each dependency. More than ten business-critical plugins or integrations without a clear owner is a strong sign that a controlled rebuild may be safer than continued piecemeal fixes.
-
Redesign the structure around the customer’s task
Use GA4 and Google Search Console to identify the 20 landing pages that generate the most organic traffic and enquiries, then follow each path through to contact or purchase. Check whether visitors encounter relevant services and proof points or are forced to interpret the company’s internal organisation. If key offers require more than three clicks from the homepage or sit beneath department names, first create a new sitemap in FlowMapp or Octopus.do rather than commissioning a new visual design.
-
Prototype the navigation before building a single template
Create a clickable structure in Figma and ask five people from the target audience to complete three specific tasks, such as finding the right service, understanding the pricing level and booking a meeting. Test with Maze or Lookback and note where participants hesitate, go back or choose the wrong menu path. If fewer than four out of five complete the tasks without assistance, the information structure needs to be adjusted before development begins.
-
Compare the two-year cost across three scenarios
Calculate the costs of improvement, incremental rebuilding and a complete rebuild separately, including development, hosting, licences, security updates, content migration and at least two major business changes. Add a risk contingency of 15–25 per cent for legacy code and apply an internal hourly rate to editors’ manual work. An improvement costing SEK 120,000 that continues to require eight hours of additional manual work each month can become more expensive within two years than a rebuild costing SEK 220,000, especially when campaign delays and incidents are also included.
Begin with a technical inventory, a test change and a prototype of the desired structure before requesting a fixed price. This allows suppliers to quote for the same actual scope and enables you to choose based on two years of business value and the cost of change rather than the lowest launch price.
