Repair a website redesign when the platform and information architecture still fit and the defects are bounded. Replace the implementation when required accessibility, security, editing, performance, or ownership controls are structurally missing. Retire the old site only after content, forms, domains, redirects, analytics needs, and rollback have been verified.
Repair a viable design
Choose repair for isolated template defects, broken components, missing labels, bad redirects, incorrect metadata, or a small set of performance problems. Capture a baseline of critical pages and journeys, then fix one class of defect at a time. A home-page preference alone is not evidence that the entire system needs replacement.
If URLs changed, use the old-to-new map as the repair checklist. Google recommends mapping old URLs to corresponding destinations, updating internal links and canonical annotations, and using permanent server-side redirects for permanent moves when possible. Test response codes, final destinations, forms, and navigation instead of relying on visual inspection.
Replace when the foundation blocks requirements
Replacement is warranted when the platform cannot provide required ownership, export, accessibility, security updates, structured content, integrations, or publishing workflow without fragile workarounds. Define the requirements and migration boundaries first. Separate a platform move from optional visual changes so failures have fewer possible causes.
Build a pilot containing representative templates, a form, media, metadata, redirects, and an editor workflow. Test it with real content copies but no unapproved public release. Google advises preparing and testing the new site thoroughly and planning the URL map before starting a move. Keep the existing site available until the pilot and rollback pass.
Retire the old site deliberately
Retirement is a controlled handoff, not deletion on launch day. Preserve a content and asset archive, DNS and hosting records, form destinations, analytics requirements, domain ownership, URL map, and deployment receipt. Keep relevant redirects active and monitor errors and traffic.
Google's site-move guidance recommends avoiding irrelevant bulk redirects to the home page, submitting the new sitemap, and retaining redirects for a long period. Remove the old hosting only after the new site, redirects, certificates, and forms remain stable through the agreed observation window. Domain cancellation is a separate owner decision.
Record the decision
Score the options on user task completion, accessibility, security support, editor effort, data portability, total cost, vendor ownership, and rollback. Repair when the foundation is sound and the defect list is finite. Replace after a representative pilot proves the missing capabilities. Retire only after the handoff checklist and monitoring pass.
If control of the domain, content, or form submissions is unclear, pause. A redesign cannot be called complete while an essential asset or customer path has an unverified owner.
Sources
- Site Moves and Migrations — Google Search Central
- Redirects and Google Search — Google Search Central