A practical website maintenance checklist

Start with a log you can use again

A useful maintenance record explains what happened. “Website checked” gives the next person little to work with. “Contact form test received in the shared inbox; confirmation displayed; no follow-up issue” records a specific result.

Download the editable maintenance log (CSV) and open it in your spreadsheet application. It contains suggested tasks with empty owner, date and evidence fields. Every result starts as Not checked. Add the actual website and review period to your working copy, remove inapplicable tasks, and choose a responsible person for each remaining row.

Use Pass, Needs attention, Not checked or Not applicable. For an exception, record the unresolved issue, next action and follow-up date. Keep earlier review rows so you can see recurring problems. Record evidence references and account owners, never passwords, secret keys or real customer messages.

Choose a schedule that fits the website

The schedule below is a starting point for a small informational or inquiry website. A store receiving orders, a frequently updated publication or a site with a critical booking process may need more frequent checks and a different recovery plan. Monthly review is a reporting rhythm; it is not a reason to leave an outage or important security notice waiting.

Set the recovery-copy frequency separately: how much new content or data could you afford to recreate? A monthly copy is a poor match for a site receiving important new records every day. Confirm the available method and retention with whoever maintains the platform.

Check the path from arrival to inquiry

1. Open the public website. Check the homepage, a key service or information page, and the contact path in a fresh browser window. Look for unavailable pages, certificate warnings, missing images and unexpected redirects. An availability check confirms that moment, not a month of uninterrupted service.
2. Use the navigation. Follow the main action on a narrow and a wide screen. Check a representative download or booking link. Use the keyboard to reach controls and confirm you can see focus.
3. Test the inquiry path deliberately. Coordinate with the recipient, use a clearly labeled test and an address you control, and avoid real customer data. Test required-field feedback and a successful submission. Confirm the expected inbox or system receives it with usable field values.
4. Check the follow-up. Record whether the visitor sees the right confirmation, whether a receipt is expected and whether the responsible person can find and act on the request. Check relevant spam or quarantine folders when delivery is missing.

A thank-you message does not prove delivery. If a record reaches the form platform but its email notification fails, record those as separate outcomes. Use the contact-form planning guide to document the intended destination and follow-up owner.

A staging or preview site can still send real notifications or share production services. Confirm how its forms work before testing. For purchases, bookings or payments, use the provider's supported test mode and an agreed test procedure.

Review current information and applicable updates

Compare published information with the business's current offer. Check contact details, hours, prices you choose to show, service descriptions, staff or author details, downloadable documents and expired promotions. Assign a content owner to decisions you cannot verify yourself. Review the public result after an approved correction using the business-page publishing checklist.

Technical maintenance depends on how the site is built. Ask the maintainer to name the platform, integrations and update responsibilities; do not copy a plugin checklist onto every website.

WordPress's automatic-update documentation describes success and failure notices and the need for a way back if an update causes trouble. Automatic updates still need a responsible person to review failures. For a significant change, use a suitable preview and check the visitor path again after release.

If an urgent platform notice applies, ask the maintainer to assess it promptly instead of waiting for the next routine review. Record a postponed update with its reason, owner and revisit date; an unexplained backlog is not a maintenance plan.

Check what a recovery copy actually contains

“Backups enabled” leaves several questions unanswered. Find the latest successful copy, its retention period, who can restore it and which parts of the website it includes. Include separately stored content, uploaded media, forms or orders where applicable. Store access instructions securely; the maintenance log only needs a reference.

• WordPress: the official backup guide distinguishes the database from the files needed to reconstruct the site. Keep a corresponding set, especially before an update.
• Webflow: its backup documentation explains restore points, access and plan limits. Restoring can affect publishing and form-protection settings, so check the provider's current instructions and retest afterwards.
• Cloudflare Workers: a version rollback changes the deployed application; it does not restore connected resources. Code recovery and data recovery need compatible plans.

Have the appropriate maintainer periodically restore to a safe test location and verify the result. Confirm that test copies cannot trigger real payments, notifications or customer actions. Record what was exercised and what was not. Finding a backup file is useful evidence, but it does not establish that a complete recovery was tested.

Keep renewals and access from becoming surprises

List the domain registrar, hosting provider, website platform and important paid services. For each, record the business account owner, renewal date, billing contact and the person who checks renewal completion. Confirm contact information and payment arrangements in the actual account. Auto-renew is a setting to verify, not proof that a future payment will succeed.

Open the provider through a known address when checking a renewal. ICANN's domain-security advice (PDF) highlights false renewal requests and recommends knowing the domain's expiration date. Keep important accounts under the business's control, with appropriate individual access for maintainers.

When someone leaves or responsibilities change, review their access and confirm another authorized person can manage the site. Record the location of recovery instructions without copying recovery codes into the checklist.

When taking over an existing site, start with the website handoff checklist and account inventory. Confirm which accounts, files and instructions are available before agreeing on the ongoing care responsibilities.

Finish with a report that identifies the next action

Use the fictional maintenance report (Markdown) as a writing example. It distinguishes completed checks from outstanding work instead of assigning a vague website health score.

Escalate a broken primary action or unavailable site through the agreed support channel when found. Keep routine content decisions in the next-work list. If a proposed repair adds a feature, changes a workflow or becomes a redesign, scope that work separately from upkeep.

If you are organizing an upcoming build, the website project preparation guide helps establish who will supply content and own the important accounts before launch.

Agree what ongoing care covers

The checklist helps you choose responsibilities with your maintainer. Put the supported site, checks, frequency, recovery method, routine edits and reporting in writing. Ask what happens when an issue falls outside that agreement.

Plainview's Website Care starts at $99 per month for a compatible website and an agreed routine scope. New pages, features, integrations, substantial redesigns and urgent or after-hours support need separate arrangements. The checklist does not promise continuous security monitoring or a provider's restoration time.