The WordPress Agency Site Operations Checklist

A client rarely notices good site operations. They notice when an update breaks checkout, an ex-employee still has access, a consent banner does not block analytics, or nobody can explain which version was deployed.

These failures are usually not caused by one missing tool. They are caused by missing ownership and inconsistent routines.

An agency managing multiple websites needs a shared operating model that covers onboarding, access, backups, updates, deployment, consent, SEO, monitoring and handover. This WordPress agency site operations checklist provides that model.

Define the service boundary first

“WordPress maintenance” can mean anything from applying plugin updates to owning the entire production environment. Agree the boundary before work begins.

For each client, document whether the agency is responsible for:

• hosting and domain administration;
• DNS and email-related records;
• WordPress core, theme and plugin updates;
• backups and restoration testing;
• security monitoring and incident response;
• uptime and performance monitoring;
• content publishing and SEO controls;
• cookie consent and tracking configuration;
• user access and account reviews;
• custom code and deployment;
• licences and subscription renewals;
• emergency work outside normal support hours.

State the exclusions too. If the client controls DNS or an external development team deploys code, the operational record should make that dependency visible.

Create one source of truth per site

Scattered notes are a reliability risk. Keep one current record containing:

• production, staging and development URLs;
• hosting provider and account owner;
• domain registrar and DNS owner;
• WordPress administrator owner;
• repository and release source, where applicable;
• critical plugins, licences and renewal owners;
• backup location, frequency and retention;
• analytics, Search Console and tag-management properties;
• consent categories and known tracking services;
• important forms, payment flows and integrations;
• last maintenance, access review and restoration test;
• escalation contacts and approval rules.

Do not store raw passwords in an ordinary project note. Use an approved password manager and record only where access is held and who owns it.

Organise work around the client-site lifecycle

Treat operations as a continuous lifecycle.

1. Onboard

Inventory the site, capture current ownership, confirm backups, document known risks and establish a stable baseline. Do not begin by updating everything at once.

2. Standardise

Align the site with the agency’s supported configuration where the contract permits. Remove abandoned accounts, define update rules and record justified exceptions.

3. Maintain

Run scheduled updates, checks and audits. Maintain evidence of what changed and what was verified.

4. Change

Handle new features and significant configuration changes through a controlled release process with approval and rollback.

5. Respond

Use an incident process for outages, compromised accounts, failed deployments or consent failures. Preserve evidence before making speculative changes.

6. Handover or close

Transfer access and documentation, revoke agency-only credentials, explain outstanding risks and confirm responsibility after the service ends.

Access and ownership checklist

WordPress roles exist to control what users can do. WordPress documents six default roles, each with different capabilities. An Administrator account should not be the default for every editor, supplier or client contact.

For every site:

• use individual accounts rather than shared usernames;
• assign the least privilege needed for the job;
• protect administrator and hosting accounts with strong authentication;
• identify the business owner of each critical account;
• remove or downgrade access when responsibilities change;
• review users on a fixed schedule;
• avoid using an administrator account for routine content editing;
• record emergency access and recovery routes;
• confirm who owns paid licences and external services.

Menu visibility can simplify the visitor or member experience, but it is not a substitute for server-side authorisation. Hiding a link does not protect the destination. Use WpAgencyKit Menu Conditions for navigation rules, and use proper WordPress capabilities or application controls for access to protected actions and data.

Backup and recovery checklist

A backup is useful only if it can be located, restored and matched to the required recovery point.

Record:

• what is backed up: database, uploads, plugins, themes and configuration;
• where copies are stored;
• how often backups run;
• how long they are retained;
• whether copies exist outside the production hosting account;
• who can restore them;
• when a restore was last tested;
• the expected recovery time and acceptable data loss for the client.

Before a material update or deployment, confirm that a suitable recovery point exists. WordPress’s own plugin-management guidance advises having a current backup before updates because problems can occur during the process.

Update and maintenance checklist

Updates need prioritisation, not indefinite delay or blind automation.

For each maintenance cycle:

1. Review available core, plugin and theme updates.
2. Read material release notes and known compatibility information.
3. Confirm the backup and rollback path.
4. Identify high-risk components such as checkout, forms, membership or custom integrations.
5. Apply changes through the agreed environment and release process.
6. Test the critical customer journeys.
7. Verify scheduled tasks, forms, emails, payment or login flows where relevant.
8. Record versions, results and unresolved issues.

Automatic updates can be appropriate for selected low-risk components, but they still need monitoring and an owner. A setting labelled “automatic” does not remove operational responsibility.

Deployment checklist

Manual uploads can be workable for a small, rarely changed site. They become harder to audit when several people, repositories and client sites are involved.

A controlled WordPress deployment workflow should identify:

• the authoritative source repository;
• the release version and change summary;
• the target site and environment;
• the person approving production deployment;
• pre-deployment backup or recovery point;
• compatibility and smoke tests;
• deployment log and outcome;
• rollback trigger and procedure.

WpAgencyKit Deploy2WP is designed for GitHub-based plugin updates with release and webhook workflows. It can support delivery, but the agency must still decide when a release is safe and how to verify it.

Cookie consent and tracking checklist

A visible banner does not prove that optional technology waits for consent.

Audit the actual site behaviour:

• list analytics, advertising, embed, chat, font and personalisation services;
• assign each service to the correct consent category;
• confirm non-essential scripts remain inactive before the required choice;
• test accept, reject and granular preference paths;
• ensure visitors can reopen and change preferences;
• verify consent-sensitive behaviour with page caching enabled;
• maintain the privacy and cookie information shown to visitors;
• review the setup after marketing or analytics changes.

Legal requirements depend on jurisdiction and the client’s processing activities. The agency workflow should support the client’s legal advice, not replace it. WpAgencyKit Cookies provides consent categories, logging and script blocking controls that can be configured as part of this process.

SEO operations checklist

Operational changes can affect search even when no content is rewritten.

After launches, migrations or structural edits, verify:

• public pages return the intended status;
• canonicals point to the correct URLs;
• redirects do not loop or chain unnecessarily;
• indexable pages remain in the sitemap;
• operational or duplicate pages use the intended robots controls;
• internal links point to current destinations;
• titles and descriptions render correctly;
• multilingual alternates represent real translated content;
• Search Console is connected to the correct property.

Use WpAgencyKit SEO to manage page metadata, social output, canonicals, sitemaps and operational audits inside WordPress, then verify the public output rather than relying only on saved fields.

Security and incident checklist

WordPress hardening is a layered activity covering hosting, updates, accounts, code, transport and monitoring. No plugin makes a neglected system secure by itself.

Maintain a concise incident procedure:

1. Confirm the report and preserve useful logs or screenshots.
2. Identify affected sites, accounts and services.
3. Contain the problem without destroying evidence.
4. Restore service through the safest verified route.
5. Rotate affected credentials and close the underlying weakness.
6. Validate critical journeys and monitoring.
7. Document the timeline, decisions and follow-up actions.
8. Support the client’s legal or contractual notification process where required.

Avoid making several speculative changes simultaneously. A controlled response should make it possible to explain what happened and which action restored normal operation.

Client communication and evidence

An operations report should answer four questions:

• What was checked?
• What changed?
• What evidence shows it works?
• What remains open, risky or awaiting approval?

Useful evidence may include version records, tested journeys, backup status, access-review dates, consent tests, screenshots, monitoring results and links to release notes. Avoid vague statements such as “all optimised” or “security improved” without defining the control performed.

Monthly operating checklist

For every supported client site:

• review uptime, errors and security notifications;
• confirm backup completion and recent recovery evidence;
• review core, theme and plugin updates;
• test priority forms, login, checkout or booking journeys;
• review administrator and supplier access;
• check consent and tracking after marketing changes;
• inspect SEO, sitemap, redirect and 404 exceptions;
• confirm licences and renewals have an owner;
• record changes and next actions.

Quarterly or after material change:

• test a restoration path;
• review the full site and service inventory;
• reassess user roles and emergency access;
• review the standard plugin stack;
• confirm staging, repository and deployment ownership;
• update the handover and incident documentation.

Make consistency a service feature

Clients may buy maintenance because they do not want to think about updates. What they are really buying is reliable ownership.

A strong WordPress agency does not merely perform tasks. It defines the controls, applies them consistently, records exceptions and proves that critical journeys still work.

The WpAgencyKit Bundle brings together tools for deployment, consent, menu conditions, SEO and translation. Use it where it fits your operating standard, while keeping backups, approvals, security and verification as explicit agency responsibilities.