WordPress maintenance: a safe site now, a better one later

I'm Yassine Seghrouchni, and together with Joey van Vliet I founded Your Tech Club in Amsterdam. Your Tech Club is certified for ISO 27001 and ISO 9001 by Kiwa, and our way of working is built around them. Running an international company from the Netherlands? Then you also get a partner who works in English and knows the Dutch and EU rules around privacy.

What you often see on older WordPress sites: plugins nobody uses any more that are still on the server, and administrator accounts nobody can place. That is where the takeover check starts.

What exactly is WordPress maintenance?

WordPress maintenance is the fixed, recurring work that keeps a WordPress site safe and working. That means updates to WordPress itself, to plugins and to the theme, plus backups, security monitoring and uptime checks. Good maintenance tests every update on a copy of your site first, so your visitors are never the guinea pigs.

It sounds dull, and it is. That is exactly why it so often goes wrong. Someone builds a site, everyone is happy, and then nobody looks at it for two years. Meanwhile, twenty plugins each want their own updates.

The numbers show why that is risky. According to Patchstack, 11,334 new vulnerabilities appeared in the WordPress ecosystem in 2025, 42% more than in 2024. Of those, 91% sat in plugins and 9% in themes, while WordPress itself had only 6. On top of that, 46% still had no fix from the developer when the vulnerability became public (Patchstack, State of WordPress Security in 2026, updated February 2026).

So the risk sits mainly in the plugins that you or your previous developer installed. Not in WordPress itself.

What is included in our WordPress maintenance?

An SLA with fixed parts: updates, monitoring, backups away from the server, security and a deadline to patch a critical vulnerability. Underneath, several monitoring tools and a website agent check versions, alerts and vulnerability news. How often we do what depends on your site. We agree those frequencies and deadlines per site in the SLA.

How is this different from cheap maintenance?

A few of these choices deserve a word of explanation, because that is where the difference with cheap maintenance lies.

An update can affect more than you think. A plugin update sometimes breaks your contact form or the checkout of your WooCommerce store. My advice, also if you do the maintenance yourself: test a major update on a copy of your site first, and make sure you have a backup you can actually restore.

Backups away from the server. A backup on the same server as your site disappears at the exact moment you need it. And a backup you have never restored is just a hope. That is why the restore procedure is in the SLA.

The server counts too. WordPress runs on PHP. If your site still runs on PHP 8.2, that version stops getting security updates after 31 December 2026 (php.net, Supported Versions, accessed November 2026). How fast something like that bites became clear on 21 October 2026. That day, servers across the Netherlands needed an urgent move to a new PHP version. Several of our client projects run on PHP. We went through them one by one and chose per project, together with the client: offline until the update was out, or online with the risks in view. You can read more about it in the PHP vulnerability on your website.

The agent warns, a person decides. The website agent is software that checks versions, vulnerabilities and alerts. It never changes anything on your live site by itself. Instead, a developer decides what happens, and when. You can see how that works on website maintenance with an SLA.

A common scenario: a plugin update goes straight onto the live site on a Friday afternoon, the contact form stops sending and nobody notices until there are no enquiries on Monday. Monitoring and a backup you can restore make the difference then.

What happens if your WordPress site breaks?

Then we follow five fixed steps: report, confirm, find the cause, restore and explain. The deadlines per priority sit in your WordPress maintenance contract. An SLA (service level agreement) is an agreement that states what your supplier does, by when and how you hear about it. So "as soon as possible" is not in it.

1. Alert. It comes from our monitoring, from the website agent or from you.
2. Confirmation. Within the deadline in the SLA, you hear that we are on it and who is picking it up.
3. Cause. We look at what changed: an update, the server or an attack.
4. Restore. If that is the fastest route, we first restore the last good backup. After that, we fix the cause.
5. Explanation. You get a short written account of what happened and what we are changing so it does not happen again.

We agree the deadlines themselves per site, because an online store with integrations needs something different from a five-page site.

My view: a maintenance contract without deadlines is a subscription to good intentions. And a response time alone says little. Ask for a promise about patching, not only about calling back.

DIY, a cheap package or WordPress maintenance with an SLA?

Doing it yourself works fine for a small site with few plugins and someone who has the time. A cheap package suits a business card site where a day of downtime costs little. However, if your site brings in leads or revenue, or connects to your accounting or stock, you want WordPress maintenance with an SLA and fixed deadlines.

Rather do it yourself? Fine. In that case, at least stick to these rules:

• Never update on a Friday afternoon or just before a busy period.
• Make a backup before every update and keep it off your server.
• Delete plugins you do not use, even if you have deactivated them.
• Write down who has access to WordPress, the hosting and the domain.

What I would not do: switch on automatic updates for an online store and hope for the best. On a simple blog that is a reasonable gamble. With a checkout, it is not.

Are you a WordPress specialist if you don't build WordPress sites?

For maintenance, yes. For new builds, not any more. We built WordPress sites ourselves in the past, and we still maintain them. We no longer build new WordPress sites: new websites we build to measure with Next.js, Strapi or Laravel, or on Shopify. Existing WordPress and WooCommerce sites we do take over. So if you want a WordPress specialist to build a brand new WordPress site, we are not the right agency.

I would rather say that now than in a quote. WordPress is fine for a simple site with a blog. But our team works in custom builds and Shopify every day, and that is where we are strongest. Maintenance is a different story, though. Your site already exists and works. It would be unwise to throw everything away just because we prefer another technology.

We also know what it feels like to leave WordPress. Our own site, yourtechclub.nl, used to run on WordPress and has run on Next.js since September 2026. According to its sitemap of 19 September 2026, the old site had 168 indexed addresses. For 115 of them the page no longer existed, so each got a redirect to the page closest in content. Blog posts without a successor point to the service they were about, not blindly to the homepage. Even so, it was not right first time. A month later an Ahrefs check still found three 404s, and old addresses with a trailing slash took two hops to reach their target instead of one. We fixed that then.

Why is maintenance our first step towards a switch?

Because you can only choose well once you know where your site stands. After a few months of WordPress maintenance, we know which plugins you need, what breaks and what your team does by hand every week. Then we make a plan together: stay on WordPress, or switch to a site that does more for you.

We call that move the WordPress switch. You get a custom site with a headless CMS, Next.js with Strapi, in which your editors work themselves. Every old URL gets a redirect, so you keep your place in Google. Forms land directly in your CRM. And your first AI employee gets to work: AI that qualifies leads, prepares quotes or answers customer questions. After that, we look after the site with a website agent and an SLA, just like now.

We usually recommend the switch when we see one of these signs:

• The site relies on plugins that no longer get updates.
• Every small change takes hours, or your editors no longer dare to touch anything.
• Leads from your forms end up in a mailbox instead of your CRM.
• Your hosting still runs PHP 8.2 or older, and upgrading breaks your theme.

What I would not do: switch because someone says WordPress is "outdated". A switch costs money and time, so it has to deliver something. That is why the bigger plan often starts with the AI Opportunity Audit: results within five working days, and a report that also tells you where AI is not a good idea.

You can see examples in the case study on a headless CMS with Strapi and Next.js and the case study from WooCommerce to Shopify.

I wouldn't make that plan too early. After the takeover check you know what is overdue. After a few months of maintenance you also know how often something breaks and how much time changes take. Then you choose between staying and switching based on what you see, not on gut feeling.

How do you move WordPress maintenance from your current provider?

In four steps, and the first is a takeover check. We look at where your site is hosted, which PHP and WordPress versions it runs, which plugins are active, where the backups are and who has access. If it shows overdue maintenance, such as a PHP version that no longer gets security updates, you hear that first. We fix it before the SLA starts.

1. Takeover check. Hosting, versions, plugins, backups and access. After that, you hear what is overdue.
2. Agree the SLA. What is included, who you call, the deadline to patch a critical vulnerability and how you hear about it.
3. Set up. Monitoring, backups away from the server, the website agent and who gets which alert.
4. Ongoing maintenance. Updates, alerts and a regular report on what we did, what monitoring picked up and what still needs attention.

Your current provider does not have to do much for this. Usually, access to WordPress, the hosting and the domain is enough. It gets trickier if your hosting is in your previous developer's name. We can sort that out too, but plan some extra time for it.