WordPress maintenance checklist: weekly, monthly and quarterly

The maintenance schedule at a glance

Use this as a starting schedule, then adjust it to how often the site changes and what an interruption would affect. A store taking orders needs more frequent database backups than a brochure site with occasional edits.

Weekly checklist: confirm the site can serve visitors

Monthly checklist: performance, cleanup and expiry

Quarterly checklist: prove you can recover

How to update WordPress with a recovery path

Minor core releases usually address maintenance or security; major releases can introduce broader changes. Both require verification, and a plugin patch can still change a critical checkout or form behavior.

1. Step 1

   Inventory changes and read changelogs

   Record installed and target versions of core, plugins and themes. Check compatibility, dependency order, PHP requirements, security urgency and any irreversible database changes before selecting a maintenance window.

2. Step 2

   Take and verify a fresh backup

   Before every update, capture matching files and database and verify the off-site copy is accessible. Identify the restore procedure, person responsible and any new orders or submissions a database rollback could erase.

3. Step 3

   Clone production to protected staging

   Use a current clone with matching PHP and relevant hosting settings. Isolate mail, payments and integrations, then run baseline tests so existing faults are not mistaken for update failures.

4. Step 4

   Apply updates in the supported order

   Follow vendor dependencies rather than assuming one universal update order. Update risky plugins such as commerce, builders, forms and integrations one at a time, testing between changes; record each version and result.

5. Step 5

   Test the changed site

   Check desktop and mobile layouts, login, forms, search, checkout and scheduled tasks where used. Inspect the browser console and PHP error log, then compare key pages with the baseline; stop if a critical test fails.

6. Step 6

   Deploy the tested changes carefully

   Take a fresh live backup before applying the tested versions or selectively deploying code. Never push a staging database over live orders or form entries; database migrations need a deliberate deployment and recovery plan.

7. Step 7

   Verify live and finish the record

   Purge relevant caches, repeat critical live tests and confirm monitoring and scheduled backups still work. If a change fails, stop deployment and use the prepared rollback or repair plan while preserving new live data, then document the failure and next action.

Find a plugin conflict without guessing

1. Reproduce

   Write down one failing action

   Record the page, click path, account role, browser, error and recent changes. Reproduce on staging and compare with a clean browser session before changing plugins.

2. Isolate

   Use session troubleshooting or staging

   Use staging by default, especially for checkout and anything that changes data. On live sites, the Health Check & Troubleshooting plugin's troubleshooting mode disables plugins and switches to a default theme only for your logged-in session, so visitors keep seeing the normal site.

3. Narrow

   Deactivate half on staging

   Keep required dependencies together, disable half the candidate plugins and repeat the same test. Test the other half or smaller groups until you identify a suspect, then test it alone and with its interacting plugin or theme.

4. Inspect

   Read console and PHP errors

   Use browser Developer Tools > Console and Network for script failures or failed requests. On staging, enable WP_DEBUG and WP_DEBUG_LOG with WP_DEBUG_DISPLAY false; capture the matching PHP error and timestamp in the protected log.

5. Resolve

   Retest the complete stack

   Try a supported vendor fix, configuration change or compatible version, then re-enable all required plugins and rerun visitor tests. Exit troubleshooting mode, turn temporary debugging off and remove or restrict diagnostic logs before closing the ticket.

// Edit existing definitions before the stop-editing comment; avoid duplicates.
// Replace the sample path with a private location writable by PHP.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/absolute/private/path/wp-errors.log');
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

Verify form delivery and fix broken visitor routes

Security controls to verify, not just install

• 2FA and unique accounts

  Require two-factor authentication for privileged WordPress, hosting and registrar accounts where supported. Verify enrollment and secure recovery codes, remove shared admin logins and give each person a named account.

• Least privilege

  Review Users > All Users monthly and after staffing changes. Remove former users with content reassigned as needed, investigate unknown administrators, and use Editor or another limited role when administrator rights are unnecessary.

• Less unused code

  Remove unused plugins and themes after checking dependencies. Keep the active theme's parent if required and a maintained fallback theme if it is part of your recovery plan; review all remaining components for updates.

• Login protection

  Configure rate limiting or login protection at the host or security tool. Test failed-login controls and recovery access, inspect suspicious login patterns and avoid rules that lock out legitimate users or block required integrations.

• Disable dashboard file editing

  Set define('DISALLOW_FILE_EDIT', true); in wp-config.php before the stop-editing comment, avoiding duplicate definitions. Verify theme and plugin file editors are unavailable; this reduces one editing route and does not prevent every compromise.

• Supported runtime and scanning

  Check Tools > Site Health > Info > Server for PHP details, confirm the version still receives upstream security fixes and test upgrades on staging. Schedule malware scans, review their results and investigate unexpected users or files even when a scan is clean.

Run the same checklist across client sites

Use a standard runbook with site-specific exceptions: hosting, credentials owner, critical forms, plugins, backup schedule, retention, deployment method and recovery contact. A central dashboard helps track work, but a successful bulk update does not prove each client's site works.

Site / reporting period / responsible person: [fill in]
Updates: [component, old version, new version, test result]
Deferred updates: [reason, owner, next review date]
Backups: [schedule, last verified off-site copy, retention]
Restore test: [last date, staging result, next drill]
Security: [scan result, user/access changes, open findings]
Availability: [monitor source, incidents, SSL/domain renewal status]
Visitor tests: [forms, inbox confirmation, links, checkout if used]
Performance: [pages, field/lab results, changes, remaining issues]
Next actions: [ticket, owner, priority, agreed date or approval needed]

For delegated delivery, agree branding, access, review and client communication in the white-label WordPress workflow. Scope development or larger repairs through white-label web development, rather than letting them silently expand the maintenance plan.

Site down or hacked: priorities for the first hour

This is an order of operations, not a promised recovery time. A suspected compromise needs containment and evidence preservation as well as getting the site back online.

1. Confirm

   Check from outside your network

   Use the external monitor and a separate connection to confirm the failure. Check hosting status, DNS, certificate validity and recent changes; record the first observed failure and notify the designated owner.

2. Preserve

   Save evidence before destructive changes

   Ask the host to preserve logs and take a quarantined snapshot of files and database. Treat it as potentially compromised evidence, keep it separate from clean backups and avoid repeated untracked changes.

3. Contain

   Limit the impact

   Work with the host to restrict access or serve a clean maintenance page if the site is malicious. Revoke suspicious sessions and accounts, secure privileged access from a trusted device, and pause jobs that could send malicious mail or spread changes.

4. Recover

   Choose a known-good recovery path

   For an update fault, use the documented rollback while preserving new live records. For compromise, involve qualified help to identify the entry point, clean or restore a verified pre-compromise backup, patch the cause and rotate affected secrets before reopening.

5. Verify

   Test and keep the incident open

   Recheck forms, delivery, login and commerce where used, then monitor for recurring errors or indicators of compromise. Record what is confirmed, what remains uncertain and the next update for the owner; assess whether exposed data requires specialist review.

When to maintain it yourself and when to hire help

Fer Marketing's WordPress maintenance starts from $250 per site per month, with agency volume pricing. It covers updates, security, off-site backups, tested restores, uptime monitoring and a monthly report; agencies can resell the service white-label under their own brand.

For new pages, content edits, forms and integrations, use WordPress site management. Confirm the site's scope, coverage and exceptions in writing, then contact Fer Marketing with the site details and any open issues.