Separate observed problems from preferences

List concrete issues before discussing a new design: missing service information, broken links, an unusable contact form, or a measured loading delay. Keep appearance preferences in a separate list. Both can matter, but they do not justify the same scope of work.

Run a free website report for a public technical baseline. Read the checked URLs and coverage instead of treating the score as a complete verdict. Add manual observations from a customer task and any site-owner evidence you already have. A public report does not establish conversion performance or compatibility with every platform.

Consider a targeted repair when the foundation works

A focused repair may fit when the site can be edited safely, the main content remains useful, and the problems are confined to a few templates or controls. Examples include repairing navigation links, clarifying a service page, or fixing the contact form's error handling.

Ask what access is needed, how the change will be verified, and how it can be reversed. A manageable first fix can reveal whether the platform supports the work. Do not bundle a full redesign into a small technical finding simply because both involve the website.

Consider a rebuild when requirements exceed the current setup

A rebuild may make sense when essential customer journeys cannot be maintained, the content structure no longer reflects the business, or required changes repeatedly need fragile workarounds. Document those constraints and the desired outcome before choosing a replacement.

Make the scope concrete: which services need pages, who will update them, where inquiries go, and which current URLs must survive. A new theme is not a complete plan. Compare a repair proposal and a rebuild proposal against the same requirements so the tradeoff is visible.

Protect useful pages during any transition

Inventory existing URLs and content before removing them. Keep useful URLs where practical; when URLs change, plan relevant permanent redirects to the corresponding replacement pages. Redirecting unrelated retired pages to the homepage can confuse visitors and search engines.

Test the replacement site's links, canonical references, indexing directives, and contact journey before release, then verify the live deployment. No rebuild guarantees higher rankings or more inquiries. Share the free report and explain whether you want improvements, a rebuild, or help deciding; a human review can establish platform compatibility and the appropriate scope.

Common questions

Does a low technical score mean I need a new website?

No. Review the evidence and coverage first. Some findings can be repaired within the current site; the score does not determine redesign scope.

Can I keep my current website address?

Often that is a planning choice, but it depends on the setup. Inventory the domain and page URLs, and confirm the migration plan before making changes.

What should I bring to a website review?

Bring your saved report, important page URLs, the customer task that fails, and who controls the existing website. Do not put passwords into the public report.

Sources and further reading