Repair a website maintenance plan when the site still needs the same care and the problem is a missing owner, stale checklist, untested backup, or incorrect schedule. Replace the plan when its structure cannot represent the site's actual systems, risks, and approval boundaries. Retire it only when the website is decommissioned or its duties are fully absorbed into another controlled plan.
Test the current plan against reality
List the domain, DNS, hosting, content system, source repository, deployment path, analytics, search tools, forms, email delivery, commerce services, backups, monitoring, and renewal dates. Compare that inventory with the plan. Then test whether the named owner and backup can access each system, locate recovery instructions, and produce evidence of the last completed check. A plan that cannot be followed by an authorized backup is not operationally complete.
Repair bounded gaps
Repair is appropriate when the plan's basic model is sound but one or more entries are missing, outdated, or untested. Add the owner, correct the interval, update the setting path, restore a broken alert, document the rollback, or run the overdue restore test. Record the change and set a short verification date. Avoid rewriting the entire plan when a narrow correction will address the observed failure.
Search Console provides a useful ownership example. Google says verification lasts while it can confirm a valid verification token, and permissions may expire if verification cannot be confirmed. It also permits multiple verification methods and notes that an additional method can help if one method fails (Search Console ownership verification). A maintenance-plan repair might therefore document existing tokens, assign their owners, and verify a backup method without disturbing a working token.
Replace a structurally inadequate plan
Replace the plan when it covers only content updates but omits infrastructure, security, forms, commerce, renewals, monitoring, or recovery; when every task depends on one person; or when evidence and approvals cannot be traced. Build the replacement beside the old plan. Map every old task to the new plan, assign primary and backup owners, define completion evidence, and run one full cycle before declaring the old version superseded. Preserve the decision history and any still-valid recovery details.
Google distinguishes verified owners, delegated owners, full users, restricted users, and associates in Search Console. It also says a property needs at least one verified owner for users to retain access (Search Console users and permissions). This illustrates why a replacement plan should record permission level and verification method, not simply a person's name.
Retire with a decommission checklist
Retire the plan only when the site has been intentionally closed or every responsibility has moved to another active plan. Confirm the authorized decision, preserve required records, handle domain and DNS ownership, stop forms and integrations safely, remove secrets and access, settle renewals at the approved time, retain or redirect public URLs where appropriate, and name the archive custodian. If the site continues to resolve or collect data, its maintenance obligations have not disappeared.
Record the lifecycle decision
A repair approval needs a bounded defect, owner, completion evidence, and retest date. A replacement needs a complete asset map, transition matrix, parallel test, approval, and rollback. Retirement needs a decommission record, retention decision, access review, and final verification. Keep the old plan read-only with a pointer to its successor so future operators can understand why the change occurred.
Sources
- Verify your site ownership — Google
- Managing owners, users, and permissions — Google