What website rescue means
Website rescue is about sites that are slow, fragile, confusing, or clearly not built with care. Sometimes we fix what's there. Sometimes we rebuild. Either way, the outcome is the same: a site you can trust.
This guide helps you decide whether to fix or rebuild. The right choice saves time, money, and stress.
When to fix what you have
Fixing makes sense when the foundations are solid and the problems are specific.
Good foundations
- Stable codebase: Updates do not break things unexpectedly.
- Reasonable structure: Content is organised logically, URLs make sense.
- Decent performance baseline: Pages load in under 4 seconds, even if not ideal.
- Accessible structure: Basic markup is sound, even if some components need work.
- You know how it works: You or your team understand the codebase.
Specific problems
- Performance issues: Slow pages from heavy images or too many scripts. Fixable with optimisation.
- Accessibility gaps: Missing labels, poor contrast, keyboard navigation issues. Fixable with targeted improvements.
- Content problems: Unclear messaging, weak structure. Fixable with content work.
- Form issues: Forms that fail or deliver poorly. Fixable with form improvements.
- SEO basics: Missing meta tags, poor headings, broken redirects. Fixable with SEO improvements.
If your site has good foundations and specific problems, fixing is usually faster and cheaper than rebuilding.
When to rebuild
Rebuilding makes sense when the foundations are broken or the site cannot support your goals.
Broken foundations
- Fragile codebase: Every update breaks something. You avoid updates because they feel risky Source 4 .
- Platform limitations: The CMS, theme, or builder cannot do what you need without workarounds.
- Performance is capped: The stack itself limits how fast you can go, even with optimisation.
- Accessibility requires endless workarounds: Fixing issues means fighting the platform, not improving it.
- Nobody understands it: The original developer is gone, and the code is a mystery.
Goals the site cannot support
- Structure does not match your business: You sell services, but the site is built for products.
- Content workflow is broken: Editing is slow, fragile, or frustrating.
- Mobile experience is poor: The design cannot be fixed for mobile without rebuilding.
- You need features the platform cannot provide: Custom functionality that requires a rebuild.
If your foundations are broken or the site cannot support your goals, rebuilding is usually the better long-term choice.
Quick decision framework
Answer these questions:
Foundation questions
- Do updates break things, or do you avoid updates because they feel risky?
- Is the codebase stable, or does it feel held together with workarounds?
- Do you understand how the site works, or is it a mystery?
- Can the platform support your goals, or are you fighting limitations?
If you answer "yes" to two or more, lean rebuild. If you answer "no" to most, lean fix.
Problem questions
- Are the problems specific (performance, accessibility gaps, content), or fundamental (structure, platform, codebase)?
- Can you fix issues by improving what's there, or do fixes require workarounds?
- Will fixing solve the problem long-term, or will you hit the same issues again?
If problems are specific and fixable, lean fix. If problems are fundamental or require workarounds, lean rebuild.
Cost comparison
Fixing costs
- Performance fixes: £500-2,000 (optimisation, script removal, image work)
- Accessibility fixes: £500-2,000 (targeted improvements, testing)
- Content improvements: £500-1,500 (rewriting, restructuring)
- Form fixes: £300-1,000 (form improvements, email delivery)
- Total (typical): £1,800-6,500
Rebuild costs
- Design and build: £2,000-15,000 (depending on complexity)
- Content migration: £500-2,000 (if reusing content)
- Redirects and SEO: £300-1,000 (preserving search value)
- Total (typical): £2,800-18,000
Fixing is usually cheaper upfront. But if you need to fix the same problems repeatedly, or if fixes require workarounds, rebuilding can be better value long-term.
Time comparison
Fixing timeline
- Performance fixes: 1-2 weeks
- Accessibility fixes: 1-3 weeks
- Content improvements: 2-4 weeks
- Total (typical): 4-9 weeks
Rebuild timeline
- Planning and design: 2-4 weeks
- Build: 4-8 weeks
- Content and testing: 2-3 weeks
- Total (typical): 8-15 weeks
Fixing is usually faster. But if you need multiple rounds of fixes, or if fixes keep breaking, rebuilding can be faster overall.
Making the decision
Use this process:
- Assess foundations: Is the codebase stable? Can the platform support your goals?
- Identify problems: Are they specific and fixable, or fundamental?
- Estimate costs: What would fixing cost? What would rebuilding cost?
- Consider long-term: Will fixes solve problems permanently, or will you hit the same issues again?
- Get a second opinion: If you are unsure, ask a developer to assess the site.
What rescue work includes
If fixing
- Stop breakages and remove obvious bloat.
- Fix specific performance, accessibility, or content problems.
- Improve forms, navigation, or user journeys.
- Make updates safer so you are not afraid to touch anything.
- Document what was fixed and why.
If rebuilding
- Plan the new structure based on your goals.
- Build on proper foundations (performance, accessibility, maintainability).
- Migrate content and set up redirects to preserve SEO Source 5 .
- Test thoroughly before launch.
- Hand over with documentation and training.
When to get help
If you are unsure whether to fix or rebuild:
- Get an assessment: A developer can review your site and give you an honest recommendation. See the website rescue problem page.
- Compare options: Get quotes for both fixing and rebuilding, then compare costs and timelines.
- Consider your goals: What do you need the site to do? Can the current site support that, or do you need a rebuild?
For more on the rebuild vs fix decision, see website rebuild vs fix: a decision guide.
Summary
Fix when foundations are solid and problems are specific. Rebuild when foundations are broken or the site cannot support your goals.
Fixing is usually cheaper and faster upfront, but rebuilding can be better value long-term if fixes require workarounds or keep breaking.
If you need help deciding or implementing rescue work, see the website rescue problem page or rescue services. You can also get in touch to discuss your specific situation.
Sources
- [1] web.dev. Why does speed matter?. Back to article
- [2] web.dev. Web Vitals. Back to article
- [3] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Back to article
- [4] OWASP. OWASP Top 10. Back to article
- [5] Google Search Central. 301 redirects. Back to article