Repair a local business website when its platform and ownership are sound and defects are bounded. Replace or rebuild it when recurring failures come from an unsupported stack, lost control, inaccessible design, or unportable data. Retire it only when the business no longer needs the site or a verified replacement serves the same public purpose. Keep contact continuity throughout the decision.
Measure the real customer journey
Test how a signed-out visitor discovers the business, understands the offer, confirms location or service area, checks hours, calls, emails, submits a form, books, or purchases. Segment by mobile and desktop, major page type, and new versus returning visitor. Record broken links, failed submissions, slow or shifting pages, inaccurate details, inaccessible controls, security warnings, and customer reports.
Inventory domain ownership, DNS, hosting, repository, deployment access, content, media rights, analytics, business profiles, forms, consent records, integrations, payment links, and recovery contacts. A visually acceptable site with unclear ownership may need urgent governance repair.
Repair when the foundation remains supportable
Repair is appropriate when the domain and accounts are controlled, the software receives security updates, content can be edited, backups or exports work, and the failure can be isolated. Examples include one redirect, form endpoint, deployment, cache, content error, layout regression, or analytics tag.
Chrome's Network panel reference documents status, timing, initiators, preserved request logs, and sanitized HAR export. Use that evidence to locate a failing resource or request without leaking cookies or authorization headers. A repair should have an exact old state, new state, test, public verification, and rollback.
Replace when constraints are structural
Replacement may be justified when administrators cannot recover ownership, the platform is unsupported, security patches are unavailable, essential content or submissions cannot be exported, accessibility fixes are blocked by the theme, performance remains poor after reasonable repair, or routine changes require risky specialist intervention.
Before migration, export and reconcile pages, media, metadata, redirects, structured data, form destinations, consent language, analytics identifiers, and search settings. Rebuild the highest-value customer journeys first. Do not copy images or text without confirmed rights.
web.dev's field-performance guidance distinguishes aggregate real-user data from controlled lab tests such as Lighthouse. Use both: field data shows what actual visitors experienced, while lab runs help reproduce specific load problems. One favorable score should not determine an entire replacement.
Retire only with a verified public handoff
Retirement can be appropriate when the business closes, merges, abandons an offering, or moves to a durable profile or platform that genuinely provides the required information and contact route. A social account alone may not replace owned contact, accessibility, policy, and archival needs.
Publish the new route, preserve required records, redirect appropriate URLs, update profiles and citations, monitor old contact points, and keep the domain controlled for a defined period. Remove forms before nobody is available to answer them. Do not let an expired site become a security or impersonation risk.
Protect search continuity and public truth
Google's URL Inspection guidance separates indexed information from a live test and exposes crawl, indexing, rendered-page, and resource details. During repair or migration, verify the current public URL, canonical, redirects, robots rules, sitemap, and indexed state. A live page and an indexed page can differ, and indexing requests do not guarantee search visibility.
Score options for customer continuity, content accuracy, accessibility, security, domain and account ownership, export, maintainability, performance, integrations, privacy, total cost, migration effort, search continuity, and rollback. Mark unknowns instead of awarding optimistic points.
Pilot and verify before switching
Build the candidate in a non-public environment with invented form data. Test navigation, phone and email links, contact form, booking or payment handoff, confirmation, mobile layout, keyboard and screen-reader basics, analytics consent, structured data, redirects, error pages, and recovery. Define a cutback plan and live-hash or deployment verification where the host supports it.
The decision is ready when an authorized owner can demonstrate control, show why failures are bounded or structural, keep customers informed during the transition, verify the public and search states, and restore the prior site if the new path fails.
Sources
- Network features reference — Chrome for Developers
- Debug performance in the field — web.dev
- Inspect and troubleshoot a single page — Google Search Console Help