A food-truck owner checks his business website on a phone beside a turquoise truck in warm afternoon light.

Begin with the task your website is failing to support. If customers cannot send an inquiry, identify where that path breaks before committing to a replacement.

Before deciding to replace the whole site, name the problem you are trying to solve.

“I do not like it anymore” is a starting feeling. “Customers cannot find our service area on their phones” is a problem you can investigate.

You do not need to know how the site was built to begin. You need a clear description of what is working, what is failing, and what the business needs next.

The Short Version

  • Repair a specific problem when the underlying site still supports your needs.
  • Reorganize content or gather missing access and facts when the evidence is incomplete.
  • Consider a rebuild when the structure repeatedly prevents necessary changes.
  • Preserve what works before changing what does not.

Those are decision prompts, not a diagnosis. Several visible problems can share one cause. One small-looking problem can also have a complicated cause.

Start With One Customer Task

Choose something a visitor should be able to do: understand a service, find your hours, request an estimate, or reach the correct person.

Try it on a phone and a computer. Write down where the task stops.

For example, a home-service business may have clear service descriptions and useful photographs, but its inquiry button leads to an old email address. That suggests investigating the contact path before replacing every page.

Another business may need separate pages for several services. Repeated layouts alone do not show that the platform cannot support them. Ask someone familiar with the system to check whether its templates, settings or implementation can be adjusted before treating the limitation as permanent.

When a Repair Is Worth Investigating

A repair may be a sensible starting point when:

  • The main information is accurate and organized reasonably well.
  • The problem affects a limited page, feature, or device size.
  • You can access the site and make supported changes.
  • The current platform can handle the features you actually need.

Examples include correcting a broken link, fixing a form, resizing an image, clarifying a heading, or repairing a mobile menu. The amount of work still depends on the cause. A short symptom does not always mean a short repair.

Ask for the proposed fix and how it will be checked. “Update the website” is too vague to tell you whether the original problem was solved.

When a Rebuild Deserves a Closer Look

Consider the larger structure when routine updates repeatedly break other pages, essential features cannot be supported, or the organization no longer matches the business.

For example, a site built around one service may become difficult to navigate after several services are added. Reorganizing pages and labels may solve it within the current system. Navigation confusion alone is not evidence that a rebuild is necessary.

A rebuild should have a purpose you can describe in ordinary language. “Customers will be able to find each service and its inquiry path” is more useful than “We need something modern.”

Be cautious about deciding from appearance alone. A new theme does not automatically fix unclear information, missing access, or an untested contact form.

Compare Two Practical Cases

In a hypothetical repair case, a shop's service pages work well, but one inquiry button uses an old address. A supported link correction followed by a delivery test may be enough. That recommendation changes if the form itself cannot be maintained or the same failure keeps returning for an unresolved technical reason.

In a possible rebuild case, a business needs an essential booking feature that a technical assessment finds its current system cannot support. Compare a supported integration, a smaller site reorganization and a replacement. If nobody has checked the feature or the account access is missing, gather those facts first. The owner can describe the need; technical assessment establishes the constraint.

Make a Keep, Fix, Replace List

Before requesting a quote, make three short lists:

  • Keep: Accurate service copy, useful photographs, recognizable branding, and pages that already answer customer questions.
  • Fix: Specific broken tasks, outdated details, confusing labels, and mobile reading problems.
  • Replace: Structures or features that cannot reasonably support the business's current needs.

Add the reason beside every item. If you cannot explain why something belongs under Replace, leave it open until you have more information.

Also confirm who controls the domain, hosting, website account, and business email. The business account map helps organize that check without sharing passwords or sign-in codes. Use the website walkthrough if you need clearer observations before requesting a quote.

Compare upfront cost, ongoing maintenance, disruption during the work and uncertainty about hidden problems. Ask what each option includes and who maintains it afterward. The cheaper initial quote may leave more continuing work; a rebuild may introduce migration work a repair avoids. Neither is automatically the better value.

Protect the Working Parts During a Change

If page addresses change, plan where the old addresses should lead. Google recommends mapping old URLs to relevant new destinations and using appropriate redirects during a site move. Do not send every old service page to an unrelated homepage. Its site-move guidance also describes testing and monitoring the change.

Before launch, confirm a current backup, what it covers and how the responsible person can restore the previous working site. Review changes in a preview where practical. After launch, test forms through to the intended inbox, phone links, navigation and mobile layout. Check business email separately if hosting or domain settings are involved.

Neither a repair nor a rebuild can promise more sales by itself. The useful question is whether the work removes a real obstacle and leaves you with a site you can maintain.

If you are unsure which category a problem belongs in, you can describe the problem to Friendly Tech Guide. Include your Keep, Fix, Replace notes so the conversation starts with what the site needs to do.