A website maintenance plan should let a new user keep the site dependable without turning every login into unrestricted authority. The plan needs a current inventory, named owners, a predictable review rhythm, and a safe way to test and reverse changes. It should also separate routine maintenance from changes that require business approval, such as pricing, legal text, payment configuration, DNS, or account ownership.

Map the site and its owners

Start with an inventory: domain registrar, DNS provider, hosting or deployment platform, content system, source repository, analytics, Search Console, forms, email delivery, payment or booking service, and third-party scripts. For each item, record the business owner, technical operator, renewal date if relevant, support route, and the type of change the new user may make. Do not place passwords, recovery codes, or private keys in the plan. Point to the approved credential manager or owner-controlled recovery process.

Capture a known-good baseline. Save the public homepage URL, important conversion paths, current deployment identifier, date of the last verified backup, and a short list of expected responses such as successful form confirmation or a blocked private route. This is evidence for comparison, not permission to change production.

Grant only the access needed

Use a named account. Enable multifactor authentication where available. CISA advises requiring MFA across business systems, beginning with administrative accounts and people handling sensitive data (CISA, Require Multifactor Authentication). NIST also recommends enabling MFA on accounts that offer it and considering phishing-resistant methods for sensitive applications and elevated privileges (NIST, Multi-Factor Authentication). Give the new user the lowest role that supports the assigned maintenance work, and retain a separate owner-controlled recovery route.

Treat each connected service separately. Google Search Console distinguishes owners from users; only owners can grant access, while a new user can be added with a chosen permission level (Google Search Console Help). A verified owner may also have an ownership token on the site, so removing the user interface entry alone may not remove every path to regain ownership. Record which account owns each verification token and review unused tokens during offboarding.

Turn maintenance into a calendar

Create small recurring checks at different frequencies. A weekly check might cover the homepage, forms, checkout or booking entry point, error logs, certificate warnings, and backup completion. A monthly check might cover dependency updates, broken links on important pages, accessibility spot checks, user and integration access, and storage or usage limits. A quarterly check might cover disaster recovery, domain and service renewals, content accuracy, privacy disclosures, analytics associations, and the continued need for third-party scripts.

CISA's small-business resources group core protections around software updates, logging, backups, MFA, and encryption (CISA, Small and Medium-Sized Business Resources). Translate those categories into named checks with evidence. “Review backups” is vague; “confirm the latest backup completed, record its timestamp, and restore one nonproduction copy according to the approved procedure” is testable. “Update plugins” is also incomplete; list how updates are staged, verified, and rolled back.

Define safe change control

Every planned change should have a requester, reason, affected component, risk level, test method, backup or rollback point, approver when required, and verification result. Routine content corrections may use a lightweight record. Updates that affect DNS, authentication, payments, legal language, account ownership, or customer data should pause at the named owner gate. The maintenance role does not itself authorize those changes.

Test on a staging or preview environment when the platform supports it. Verify the exact user path, not only the administrator screen. For a form change, submit a non-sensitive test and confirm the expected delivery or stored event. For a dependency update, run the site's automated checks, inspect key pages at common viewport sizes, and confirm logs remain clean. If the site is static or edge-deployed, record the deployed version and verify the live file or page hash when that capability exists.

Monitor search and connected services carefully

Search Console can expose ownership, permissions, and associations to other Google services. Google explains that an association can share Search Console data with another service and that owners can review, approve, deny, or remove associations (Google Search Console Help, Associations). Add association review to the quarterly checklist instead of assuming every connection is harmless. Keep analytics access, site access, and Search Console access as separate decisions.

Complete a supervised first cycle

Have the new user perform one low-risk maintenance task: inspect the baseline, create a change record, make the change in preview, run the defined checks, obtain approval if required, deploy through the approved path, verify the live result, and close the record with evidence. Also rehearse a rollback in nonproduction.

The handoff is complete when the user can explain the boundaries of authority, locate owners and recovery procedures, prove the latest backup state, identify the live version, run the maintenance checklist, and stop at a consequential gate. Review the plan after 30 days. Remove checks that produce no decision, add missing failure signals, and keep the evidence compact enough that someone else can audit what happened.

Sources

  1. Require Multifactor Authentication — Cybersecurity and Infrastructure Security Agency
  2. Multi-Factor Authentication — National Institute of Standards and Technology
  3. Small and Medium-Sized Business Resources — Cybersecurity and Infrastructure Security Agency
  4. Managing owners, users, and permissions — Google
  5. Associations — Google

Related reading