A website that is not producing inquiries does not automatically need a new codebase. Start with a real visitor task and follow it from the landing page to the reply in your inbox. This worksheet helps you identify what is broken before deciding how much to replace.
When should you redesign rather than rebuild a website?
Consider a redesign when the underlying system can support the required editing, forms and integrations but the content or interface is unclear. Consider a rebuild when the platform prevents essential workflows, cannot be maintained safely or makes agreed requirements impractical. Choose targeted repairs when the problem is isolated. Confirm the decision through a technical review and a written scope.
1. Locate the failed customer journey
Check whether relevant visitors reach the service pages. Then test whether the offer is clear, the contact action works on a phone and the brief arrives at the destination. A redesign alone does not establish demand or fix missing distribution. Google's SEO starter guide explains the discovery foundations.
Try a small screen and keyboard navigation. Submit a harmless test inquiry with the owner's agreement, check delivery and verify that an unsuccessful submission is not presented as success. Record the URL, device, expected behavior and observed behavior for each issue.
2. Match the decision to the constraint
Example: the form destination is wrong, a service link is missing or a page is difficult to use on a narrow screen. Request a focused fix with a reproducible acceptance check. Keep working content and URLs where practical.
Example: the team can edit the site and the integrations work, but visitors cannot tell which service fits them. Improve information structure, copy and page layouts. Use a prototype to confirm that the new journey answers the buyer's questions before development.
Example: essential editing permissions or application features cannot be implemented or maintained reliably in the current system. Compare the cost and risks of extending it against replacing it. Ask the developer to identify the specific constraint; an unfashionable technology name alone is not sufficient evidence.
3. Preserve what already works
Record important pages, downloads and incoming-link destinations. Keep useful URLs where possible. If URLs change, map old pages to their relevant replacements and implement redirects, update internal links and submit the new sitemap. Google's site move guidance describes migration checks; search visibility can fluctuate during a move.
Identify where inquiries, customer records, content and files live. Agree the backup, migration verification and rollback plan before replacing anything. Use restricted access when sharing systems with a developer; a public project brief should contain no credentials.
4. Define launch evidence before design starts
Use repeatable lab checks to diagnose changes and real-visitor data when available. Google's Core Web Vitals cover loading, responsiveness and layout stability. A single test score does not prove every visitor's experience; see the Web Vitals documentation.
Verify navigation, the service explanation, a working form, real delivery and the team's follow-up process. Check canonical URLs, indexing settings, the sitemap and error pages. Record the release and who can roll it back. Separate implemented checks from any forecast of future leads.
5. Ask for a scoped recommendation
Share your website URL, the main visitor task and two or three observed problems. Add editing needs, integrations and deadlines. Our web development service explains the prototype, build and handover process; the studio website demo shows our own implementation choices.
Ask what can stay, what must change, what evidence supports that decision and what a useful first phase would include. Use the cost guide to compare scopes consistently rather than assuming the largest rebuild will deliver the best outcome.
Sources
- Google Search Central: SEO starter guide
- Google Search Central: site moves with URL changes
- web.dev: Web Vitals