WordPress Site Maintenance: What It Includes, What Breaks Without It, and How to Judge a Plan

What does WordPress maintenance actually include?

Maintenance is the work that keeps a finished site working: nothing new gets built, and nothing visible changes. That is why it is the first thing owners stop paying for, and how a site that was fine for three years goes down on a Thursday evening. A site does not have to be badly built for that to happen. It only has to be left alone.

A maintenance plan should cover five things, and it helps to know them by name, because providers use the same word for very different amounts of work.

• Updates: WordPress itself, the plugins, the theme, and a check of the site after each round.
• Backups: files and database, kept outside the server, and restored at least once as a test.
• The server side: a supported PHP version, a current database, HTTPS.
• Renewals: the domain, the certificate, the hosting and the paid plugin licenses.
• Monitoring: is the site up, do the forms arrive, does the checkout take a payment, has Google flagged anything.

Why a site nobody touches still breaks

A WordPress site is not one piece of software. It is WordPress plus a theme plus, on most business sites, a few dozen plugins from different authors, and new security holes are found in them every week. Patchstack, a company that tracks WordPress vulnerabilities and sells protection against them, counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024. According to its report, 91% of them were in plugins and 9% in themes. Only 6 were in WordPress itself, and those were low priority.

Two more numbers from the same report explain why "I will update when I have time" does not work. About half of the high-impact vulnerabilities were exploited within 24 hours of being published. And 46% of all vulnerabilities had no fix from the developer by the time they were made public, which means that for those, updating was not enough: the plugin had to be switched off or replaced. Patchstack also tested common hosting and firewall defenses, and in its wider test only 26% of the attacks were blocked. Keep in mind who is reporting: this is a company with a product to sell. The direction, though, matches the 91% above: the usual way in is a plugin, not WordPress itself.

The practical conclusion is simple. The risk on your site is not WordPress. It is the plugin installed four years ago for one feature, which nobody remembers and nobody updates.

What WordPress updates by itself, and what it does not

WordPress has had automatic background updates since version 3.7. Its documentation says that minor releases, the ones that carry security fixes, are installed automatically by default, and that since version 5.6 new installations also receive major releases automatically. Plugins and themes are a different story. Since version 5.5 an administrator can turn on automatic updates for each plugin and each theme, one by one, and it is off until someone does. When it is on, WordPress checks twice a day and emails the site owner about what was updated and what failed.

So should you switch everything to automatic and forget about it? On a simple brochure site with a handful of well-known plugins, usually yes, as long as backups run and someone reads those emails. On a store, no. WooCommerce's own update guide says to make a current backup first and to test the update on a staging site, a private copy of the store, whenever possible, and then to place a test order and check the cart, the checkout and the emails. The reason is plain: an update that breaks a contact page costs you an inquiry, and an update that breaks the checkout costs you every order until someone notices.

• Automatic and unattended: WordPress security releases, and plugins that do one small job.
• Updated by a person, then tested: WooCommerce, the payment gateway plugin, the page builder, the theme, membership and course plugins.
• Removed, not updated: plugins that are switched off, and plugins whose author stopped releasing versions.

The server side: PHP versions and certificates have dates

WordPress runs on PHP, and every PHP version has an end date. The PHP project supports each version for two years with bug and security fixes, and for two more years with critical security fixes only; after four years the version is end of life. On the day I checked, PHP 8.0 and 8.1 are already end of life, 8.2 gets security fixes only until 31 December 2026, and 8.3 until 31 December 2027. WordPress recommends PHP 8.3 or greater, MariaDB 10.11 or MySQL 8.0 or greater, and HTTPS. It still runs on older versions, and its requirements page warns that those have reached end of life and may expose the site to security vulnerabilities.

Moving a site to a newer PHP version is a button in the hosting panel, and it is also the moment an old plugin stops working. That is maintenance work: check on a copy, replace what breaks, then switch. If nobody does it, the hosting company eventually does it for you, on its own schedule and without testing your site.

Certificates have dates too, and the dates are getting shorter. Let's Encrypt, the free certificate authority that many hosts use, issues certificates valid for 90 days. It has announced that the default will drop to 64 days on 10 February 2027 and to 45 days on 16 February 2028. With automatic renewal you never notice. Where renewal is done by hand, or the automation fails without telling anyone, visitors get a browser warning in place of your site.

Backups: the one you have restored is the one that counts

A WordPress site is two things, and both have to be backed up: the files (WordPress, themes, plugins, uploaded images) and the database, where the pages, the orders and the customers live. The WordPress documentation recommends keeping at least three to five recent backups, in different places: on the hosting server, in cloud storage and on your own computer. It suggests a weekly backup for a small site with little new content and a daily one for a busy site, and it adds that automatic backups should be checked by hand from time to time to make sure the process works.

The part that gets skipped is the restore. A backup that sits only on the same server disappears with the server. A backup nobody has ever restored is an assumption. For a store, also ask how old the newest backup can be: with a nightly backup, a restore at five in the afternoon loses a full day of orders, so a store needs either more frequent database backups or a way to re-enter the orders from the payment processor's records.

• Where are the backups stored, and is at least one copy outside the hosting account?
• How often, and how many days back can you go?
• When was the last test restore, and how long did it take?
• Who has access to the backups if the person who set them up is not available?

Monitoring: what a hacked or broken site costs you in Google

Most owners find out that the site is down from a customer. Monitoring means finding out first. The basic version is an automatic check every few minutes that the site answers. The useful version also checks the things that fail silently: a contact form whose emails stopped arriving, a checkout that shows an error at the last step, a domain that expires next week.

A hacked site has a second cost, beyond the cleanup. Google's Search Console Help says that pages or sites affected by a security issue can appear with a warning label in search results, or with a warning page in the browser when a user tries to visit them. After you fix the problem you request a review, and Google says a review can take from a few days to a few weeks. For a business that depends on search, that is weeks of visitors being told not to enter. Connect the site to Search Console, where the Security issues report shows what Google found, and make sure its emails reach someone who reads them.

Three ways to get it done

There is no single right answer here, and I am not tied to one of them. Which route fits depends on what the site earns you and on how much attention you are willing to give it yourself.

• Do it yourself: it works for a small brochure site if you are the kind of person who will really log in once a month, update, look at the site on a phone and download a backup. It costs time, and it fails the first month you are busy.
• Managed hosting: many hosts offer automatic updates and daily backups as part of the package. That covers the server and the routine. It does not cover judgment: nobody at the host knows that your checkout matters more than your blog, and nobody tests your site after an update.
• A maintenance plan with a person: a developer or a studio that updates, tests, restores and answers when something breaks. This is the right route for a store, a members area, a site with integrations, or any site where a day offline costs more than a year of maintenance.
• A fourth option exists, and it is fair to name it: on a hosted platform such as Shopify, the platform maintains the system for you, and the monthly fee includes it. If upkeep is the thing you want least, that is a real argument for a hosted platform, with the limits I describe in Shopify vs WooCommerce in Israel.

How to judge a maintenance plan: questions to ask

Two plans with the same name and a similar monthly fee can be an hour of real work a month, or a script that clicks "update all" and sends you a PDF. The report does not tell you which one you bought. These questions do.

• Who updates, and what do they check afterwards? Ask for the list: home page, a form, the checkout, the phone view.
• Are updates to a store tested on a copy first?
• Where are the backups, and when was one last restored?
• What happens when the site breaks or is hacked: who answers, within what time, and is the repair included or billed separately?
• Is small work included, such as a text change or a new banner, and how much of it?
• Who holds the accounts? The domain, the hosting and the plugin licenses should be registered to your business, with your email, not to the provider.
• What do you get if you leave: full admin access, a recent backup and the list of licenses, without a fight?

What drives the cost

I do not publish prices, and I am not quoting market prices here either, because the same word covers very different services. Every project gets a fixed quote after a short call. What makes maintenance small or large:

• The kind of site: a brochure site, a store, a members area or a course platform.
• The number of plugins, and how many of them are paid, custom or no longer maintained.
• Whether updates need a staging copy and a test order each time.
• The response time you need when something breaks, and at what hours.
• The starting condition: a site that was not updated for years needs a one-time cleanup before routine maintenance makes sense.
• Connections to other systems: payment, invoicing, CRM, stock. Each one is another thing to test.