Imagine two quotes for the same website: one proposes a rebuild; the other proposes targeted repairs. Which should you accept?
If you’re asking, “Should I rebuild my website or fix it?” my default is repair first—unless the existing foundation prevents necessary control, editing, maintenance, or expansion. Age, dated colors, weak copy, and slow pages do not settle the question.
Use the seven questions below to separate structural limitations from fixable problems. Three evidenced structural “yes” answers justify considering a rebuild. That is a practical decision rule, not a validated industry standard, and a severe blocker can override the count.
What makes a website problem structural?
A structural problem blocks a necessary business function and cannot reasonably be resolved within the existing foundation. “Reasonably” should account for cost, disruption, reliability, and future maintenance—not just whether a developer could theoretically patch it.
For this decision:
- Repair fixes specific problems while retaining the foundation.
- Redesign changes presentation or the customer experience; it may retain the platform.
- Rebuild replaces substantial underlying templates, architecture, or platform components.
A missing service page is usually a content problem. A system that cannot accommodate separate service pages without replacing its page architecture may have a structural problem.
Before scoring, gather account access, platform and hosting details, known dependencies, required services, and the paths customers use to call, submit a form, or book. Mark unanswered questions unknown, rather than assuming the worst.
Scorecard, questions 1–3: control, editing, and support
For each question, record yes, no, or unknown, the evidence, and a bounded repair alternative: a specific change with a defined scope and completion check.
1. Is essential ownership or account control unrecoverable through a reasonable handover?
Check control of the domain, hosting, website administration, and other essential accounts. A missing password is not enough to score yes.
Evidence: Identify the inaccessible account, its business impact, and the handover or recovery options investigated.
Repair alternative: Transfer administration, recover credentials, or move the affected service into a business-controlled account where feasible. Rebuilding a website does not recover domain rights or restore access to the existing domain.
2. Are routine content edits impossible without replacing the editing foundation?
Ask someone to demonstrate changing a service description, phone number, and call to action. An unfamiliar editor or missing permission is different from an unusable editing foundation.
Evidence: Show which routine edits fail and why permissions, training, or a limited template change would not resolve them.
Repair alternative: Adjust permissions, improve editable fields, or replace a limited template. Requiring occasional developer help is not automatically structural; assess the workload your business actually needs to handle.
3. Does a critical dependency lack a viable supported upgrade or replacement path?
One outdated plugin does not establish that the whole website is unsupported.
Evidence: Name the dependency, the function it supports, and why neither an upgrade nor a contained replacement is viable.
Repair alternative: Update, replace, or remove that component and test the affected function. For WordPress sites, official security guidance recommends updates, secure server software, and backups—not automatic rebuilding when something is outdated.
If maintenance history is unclear, run a website maintenance check before treating neglect as a platform failure.
Scorecard, questions 4–7: structure and safe extension
These questions require demonstrations, not statements such as “the platform is limiting you.”
4. Is the page model unable to support required services without architectural replacement?
Can the site publish distinct service pages with useful navigation and editable content?
Evidence: Demonstrate a required page that the current structure cannot accommodate, and identify the architectural constraint.
Repair alternative: Add a page type, extend navigation, or improve an existing template. A service page nobody has written yet is not a structural failure.
5. Are essential mobile or accessibility failures rooted in templates that cannot reasonably be repaired?
Test customer tasks: reading service information, navigating, completing forms, and activating important controls, including by keyboard.
Evidence: Show the failed task, the responsible template behavior, and why a targeted correction is insufficient.
Repair alternative: Correct layouts, navigation, controls, or form behavior. A few broken mobile elements do not establish that every template needs replacing. Rebuilding also does not, by itself, establish accessibility compliance.
6. Do required booking or lead workflows exceed the platform’s extensibility?
Define the requirement before judging the technology. A basic inquiry form and a booking process with scheduling and system handoffs are different scopes.
Evidence: Trace the required customer and staff workflow, then demonstrate the specific integration or customization barrier.
Repair alternative: Repair the existing form, connect a suitable service, or add a contained integration. Score yes only when necessary functionality cannot reasonably be supported within the existing foundation.
7. Is the deployment or recovery foundation irreparable without replacement?
Can someone safely publish changes and restore the working site if a change fails?
Evidence: Identify what prevents a safe release or recovery and why it cannot be corrected without replacing the foundation.
Repair alternative: Establish backups and restoration procedures, improve the release process, or change hosting where feasible. Missing backups are a risk to address, not automatic proof that the website must be rebuilt.
The rule: three structural yes answers point to a rebuild
Count only supported yes answers. Keep unknowns on an assessment list. Do not count one underlying constraint several times merely because it affects editing, page structure, and integrations.
- Zero to two: Repair first, unless a severe blocker makes that impractical.
- Three or more: A rebuild is justified for consideration. Compare it with a scoped repair alternative before committing.
- Critical blocker: An essential function with no viable repair path can justify replacement even below three.
Contain active security risks immediately rather than waiting for a redesign decision. Rebuilding is not a substitute for dealing with compromised accounts or unresolved domain control.
Below the threshold? Fix the customer path first
Prioritize repairs in this order:
- Security and account-access risks.
- Broken forms, phone links, and bookings.
- Measurement of inquiries and important customer actions.
- Offer clarity and calls to action.
- Missing or weak service pages.
- Diagnosed speed problems.
- Cosmetic changes.
For each fix, record an owner, scope, and acceptance check. “Improve the form” is vague. “Submit the form on mobile, confirm delivery to the intended inbox, and verify the confirmation message” is testable. A test submission proves that path worked during the test—not that a real customer became a lead.
Hypothetical example: A plumbing company has outdated colors, an unclear service list, and a broken inquiry form. Its accounts are controlled, pages are editable, and dependencies have viable maintenance paths. That points toward repairing delivery, clarifying services, and improving customer actions before replacing the site.
You can also find friction in the inquiry path to make that repair backlog more specific.
Make both quotes prove what they will solve
Ask each bidder to connect proposed work to the scorecard:
- Which evidenced problems will this resolve?
- What repair alternative was considered, and why was it rejected?
- What is excluded, and what ongoing costs remain?
- Who controls the accounts and can edit service pages afterward?
- What acceptance tests demonstrate that inquiries, bookings, and editing work?
For a rebuild, require a clear account handover and a URL plan. Preserve existing URLs where appropriate. When URLs change, Google’s migration guidance recommends mapping old URLs to new destinations and using permanent server-side redirects where possible. Test the redirects and destination pages.
Significant changes can cause temporary ranking fluctuations while Google recrawls and reindexes. Neither a rebuild nor a migration plan guarantees unchanged rankings.
Re-check in 60 days before expanding the project
Before repairs, record inquiry delivery, qualified inquiries, relevant traffic, and whether staff can complete routine edits. Define what counts as a qualified inquiry for your business.
Verify each repair immediately, then review those measures after 60 days. Can customers complete the intended actions? Can staff maintain the site? Have any structural blockers remained?
Treat 60 days as a review checkpoint, not a ranking promise. Seasonality and low inquiry volume can make comparisons inconclusive.
If the score remains borderline or unclear, Kohl Digital’s optional free website audit can help identify practical improvements before you commit to a rebuild.
The decision comes back to evidence: three distinct structural yes answers justify considering a rebuild; with fewer, repair first unless a severe blocker has no viable repair path. Before accepting either quote, ask: What must be replaced, why can’t it be repaired, and how will we know the work solved the problem?