Answers

You already have a website. Should you replace it?

I already have a website do I need a new one? Not necessarily. A site that looks dated may still have useful pages, search visibility, and working lead paths; a site that looks modern may be held together by fragile code or accounts you do not control. Audit what is working and what is blocking the business before you pay for a replacement.

The decision is not a vote on whether the design feels fresh. It is a question of whether the current system can support the next stage of your business at a reasonable cost and risk. Define the job first: more qualified inquiries, clearer service information, easier updates, a new booking flow, or a better mobile experience. Then measure the existing site against that job.

Start with evidence from the current site

Review the pages that bring visitors, the pages that generate contact, and the paths people take between them. Check forms, calls, booking tools, and any ecommerce steps with real test submissions. Look at mobile usability, accessibility barriers, page speed, security updates, and whether the team can edit content without asking a developer for every change. Note which problems are isolated and which repeat across the whole site.

Talk to the people who use the site for work. Sales may know which service pages cause confusion. Support may know which questions the site fails to answer. Operations may know that leads arrive without the details needed to quote. Those observations are more useful than a designer's first impression. Write down the current baseline so a rebuild can be judged against it, rather than against a vague feeling that the new version is better.

When repair is the better move

Keep the site if its structure is sound and the problems are bounded. A slow hero image can be fixed without changing every page. A weak service description can be rewritten. A broken form can be repaired and tested. If the platform is supported, ownership is clear, and the template can express the content you need, focused improvements may buy more value than a wholesale redesign.

Ask the provider to show the smallest change that would address each problem. Include the cost of testing and ongoing upkeep, not just the first edit. A series of unrelated patches can eventually cost more than a rebuild, but that conclusion should come from a written diagnosis. Do not replace working content just because it has been online for a while.

When a rebuild is justified

A rebuild becomes more reasonable when the foundation blocks ordinary work. Examples include a platform nobody can maintain safely, templates that cannot support needed page types, inaccessible navigation that recurs everywhere, brittle integrations, unclear ownership of the code or domain, and a content structure that cannot explain your services. If a major business change requires new architecture, repairing one page at a time may not solve the underlying problem.

Even then, the current site is a source of assets. Preserve effective copy, useful images, lead forms, and the pages that serve real search intent. A rebuild should begin with an inventory, not a blank canvas. Decide what will be kept, rewritten, consolidated, or retired. The migration plan should identify equivalent destinations for old URLs and a way to verify that important journeys still work after launch.

Protect what the old site has earned

Changing URLs without a map can send visitors to missing pages and make search systems relearn where content lives. Google Search Central recommends mapping old URLs to relevant new destinations and using permanent server-side redirects for a site move. That does not mean forcing every retired page to the homepage. If a page truly has no replacement, decide on its response deliberately and document why.

Before launch, export a URL inventory, record the current titles and important content, and test the new site in a private environment. At launch, check redirects, canonical URLs, navigation, forms, tracking, and the sitemap. Keep the old site's content and backups until the new path is proven. Search visibility can fluctuate during a move, so monitor what actually happens rather than promising a risk-free transition.

Make the decision in stages

Ask for a short audit with a repair option, a rebuild option, and the trade-offs of each. Each option should state what remains unsolved. If the provider recommends a new site, ask which current constraint makes a focused repair inadequate. If they recommend repair, ask what future change would make that advice expire. You are buying a decision, not just a set of pages.

The final test is whether the proposed work makes the site easier to run and more useful to a buyer. If repair clears the blockers, keep the asset you have. If the platform itself prevents the improvements you need, rebuild with a migration plan. Either path should leave your business in control of its accounts, content, and next step.