Skip to content

Yuvraj Raulji | WordPress maintenance

WordPress powers a large share of the web, which makes it the most systematically scanned software most organisations run. Nearly every compromised site was running something with a published patch. Maintenance here is unexciting on purpose: updates on a cadence, backups that have actually been restored, and someone who owns the plugin list.

How the work runs

Direct answer

WordPress maintenance is core, theme and plugin updates applied on a cadence rather than when something forces it, security hardening covering admin access, file permissions and the login surface, backups that are periodically restored rather than merely scheduled, uptime and error monitoring that reaches a person, and ownership of the plugin list so it does not grow by accumulation. Almost every compromised WordPress site was running a known vulnerability with a patch available, which is why cadence matters more than any individual control.

Best suited for

  • A business-critical site nobody owns technically
  • Updates deferred because the last one broke something
  • Backups that have never been restored
  • Sites where a compromise would go unnoticed

What this page is not

This is the site: core, plugins, hosting, security and backups. If there is a store on it, the update routine has to include a checkout test and the commerce plugin layer needs its own owner, which is a different arrangement.

WooCommerce maintenance, when there is a store to protect

The problem

The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.

  • Updates are deferred because the last one broke something

    What it costs

    The gap grows, the exposure compounds, and the eventual update becomes a project. WordPress is scanned constantly, so a deferred security release is a decision with a real risk attached rather than a scheduling preference.

  • Backups are scheduled and have never been restored

    What it costs

    An untested backup is a belief. The test happens during the incident, and an incomplete database dump is discovered at the worst possible moment.

  • Admin access has accumulated

    What it costs

    Old accounts, shared logins, no two-factor and a default login path being scanned continuously. Most practical WordPress exposure sits here rather than in application code, and it costs almost nothing to fix.

  • Nobody would notice a compromise

    What it costs

    Injected content and spam pages can run for months, and the usual first signal is a search engine warning or a customer. By then the cleanup includes reputation as well as files.

Approach

In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.

  1. Establish the current position

    Versions, plugin inventory, admin accounts, hosting, backup state and whether anything is already compromised. On inherited sites this last check is worth doing before anything else.

  2. Set an update cadence

    Security releases promptly, everything else on a schedule, tested on a staging copy first. Cadence is what keeps each update small enough that nobody is tempted to defer it.

  3. Harden the obvious surface

    Two-factor on every admin account, removal of accounts nobody uses, file permissions, a login path that is not the default, and disabling file editing from the dashboard. Cheap, and it removes most of the practical exposure.

  4. Make backups real

    Off-site, versioned, and restored on a schedule to prove they work. A restore rehearsal is the only thing that distinguishes a backup from a scheduled task.

  5. Monitor what actually fails

    Uptime, PHP errors, file integrity, SSL expiry and search engine warnings, alerting a person. The point is to find a problem before it is reported from outside.

Scope

  • Updates

    Core, theme and plugin updatesSecurity release handlingStaging-first routinePHP version currency

  • Security

    Two-factor and account reviewLogin surface hardeningFile permissionsFile integrity monitoring

  • Recovery

    Off-site versioned backupsScheduled restore testsRollback pathIncident response

  • Monitoring

    Uptime and error alertingSSL expirySearch Console warningsPlugin list review

Proof

A brand platform where the site is the discovery and enquiry channel, so an outage is a commercial event.

  • Web platform · Manufacturing

    Engineering manufacturer platform

    A modern engineering brand platform built for discovery and enquiry.

    Web platformTechnical SEOContent

    3x traffic growth and 45% better engagement

Outcome

  • The patch gap closed, and kept closed

    The measurable outcome is the distance between the site and current releases, and whether it stays small without anyone pushing. Nearly every compromised WordPress site was running something with a patch already available.

  • A backup you have actually restored

    The value is not in having backups, which almost everyone does. It is in having restored one recently enough to know it works, which very few have.

No uptime percentage or response-time commitment is published here. Those are contractual terms depending on the hosting and cover agreed, and no WordPress engagement on the record carries a published measurement.

Questions

How often should WordPress be updated?
Security releases promptly, and everything else on a regular cadence tested against a staging copy. The gap is what creates the danger: a site a month behind updates easily, and a site two years behind is a project that keeps getting postponed.
How do WordPress sites actually get hacked?
Overwhelmingly through known vulnerabilities in outdated plugins and themes, and through weak or excessive admin access. Targeted attacks on custom code exist and are rare by comparison, which is why update cadence and access hardening deliver more security per hour than anything else.
Is managed hosting the same as maintenance?
No. Managed hosting usually covers the server, core updates and backups, which is a good foundation. It does not own your plugin list, test updates against your site, or notice that something was injected into your templates.
How do we know our backups work?
By restoring one, on a schedule, into a staging environment. Until a backup has been restored it is an assumption, and the failure modes, incomplete database dumps, missing uploads, are not visible from the backup log.
What if we already have an in-house team?
Then what is often missing is the routine rather than the capability: a cadence, a staging step, a restore test and an owner for the plugin list. That can be set up and handed over rather than held indefinitely.

Next step

Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.

WordPress overview