Websites

WordPress maintenance your co-op can plan

Keep a WordPress site useful with clear ownership, tested backups, deliberate updates and checks of the journeys that matter.

In this guide

A WordPress site needs somebody to look after its software and its purpose. A homepage can load normally while a membership form stops delivering, a payment route breaks or an old committee contact remains published. Maintenance should include the tasks visitors rely on as well as the update screen.

Begin by identifying who is responsible for hosting, domain registration, WordPress administration, plugins, content and support. These may be different people or suppliers. Record where responsibilities meet so an urgent fault does not lead to a chain of referrals.

Establish a short maintenance record

  • Hosting provider, support route and authorised account holders.
  • Domain registrar, renewal owner and DNS-change contact.
  • WordPress administrator accounts and editorial roles.
  • Active theme and plugins, their purpose and any renewal arrangements.
  • Backup scope, location, recovery method and latest restore result.
  • Important integrations, including forms, email delivery and payments.
  • Staging or test arrangements and the agreed change window.

Check domain control separately from website access. A WordPress administrator may be unable to renew the domain or recover the hosting account. Keep credentials securely managed and give ordinary editors only the permissions required for their work.

For each plugin, ask why it is there and who would notice if it stopped working. Investigate abandoned or duplicate functionality with the maintainer. Removing unfamiliar components without checking dependencies can break a site just as an update can.

Use a deliberate update process

WordPress documentation recommends backing up before updates. Build that into a repeatable process rather than clicking every available update in production and hoping nothing changes.

  1. Review the update and any known compatibility requirements.
  2. Confirm a current, usable backup of the site files and database.
  3. Test significant changes in a suitable staging environment where practical.
  4. Check the important visitor journeys and administrative tasks.
  5. Apply the approved change to the live site within the agreed window.
  6. Repeat the live checks and monitor for errors or failed submissions.
  7. Record what changed and any follow-up needed.

Keep staging access restricted and prevent it from sending real campaign messages or taking live payments. Use appropriate test data and payment test modes. Copying a production site can also copy personal information and secrets; treat that environment accordingly.

Set a policy for automatic updates with the maintainer. Security fixes need prompt attention, while complex changes may need more testing. The official plugin and theme guidance explains the available feature. Automatic updates still require monitoring and a recovery plan.

Test the co-op's real journeys

An illustrative local food co-op might prioritise opening hours, ordering, joining and volunteer enquiries. Write a short check for each: start from the homepage, follow the route, complete a fictional submission where appropriate and confirm it arrives at the intended destination.

Include mobile and keyboard use, clear form errors and access to important documents. W3C's Easy Checks can help identify basic accessibility issues, although they do not amount to a full accessibility evaluation.

Check content dates and ownership. If an event is over, remove or clearly archive its booking route. If a worker leaves, update contact details through the approved process. A routine editorial review can prevent visitors acting on information that was once correct.

Know how to recover without losing new work

Agree who decides when to restore and how recent orders, submissions or edits will be preserved. Restoring yesterday's database may remove today's legitimate activity. A rollback needs to consider the work completed after the backup, not only whether the homepage returns.

Follow the backup and restore-test guide and keep the result in the maintenance record. Test recovery into a separate environment before relying on it during a fault. Record a support route that remains reachable if the site is offline.

If your maintenance responsibilities are unclear, use a technology support discussion to define the work, ownership and recovery arrangements your site needs.

Suggest a correction or improvement →