Earlier this month, we were asked to help with a WordPress website that had been infected. The site was not hosted by NBM, but the problem had become difficult for the client to ignore. German-language spam articles promoting casinos had appeared on the website.

The hosting environment’s Imunify360 security system detected malicious files, which was valuable. But the spam posts returned. That was the important part of the lesson: detecting malware did not, by itself, remove every route or mechanism that allowed the unwanted content to reappear.

The response therefore had to go further. Website passwords were reset. Unused users were removed. WordPress, Elementor and outdated plugins were updated. Established security and firewall controls were activated, further hardening was applied, and the site was scanned again. Following that remediation, the site remained clean.

We did not establish the original entry point with enough certainty to blame one plugin, one vulnerability or the hosting provider. It would be irresponsible to pretend otherwise. What the incident did demonstrate is something business owners often only discover when a problem occurs: proper WordPress maintenance is not the same as logging in and clicking Update.

The Update button performs an action – Maintenance manages the risk

WordPress makes software updates look simple. In many cases, the update itself is simple. Select a plugin, click a button and wait for the confirmation message.

The difficult part sits around that button. Someone still needs to understand what is being updated, why it matters, what depends on it, what could stop working, how the website would be recovered, and what must be tested afterwards.

That distinction matters because a website can appear normal while something important has failed. The homepage may load while a contact form no longer delivers enquiries. A page-builder update can leave a layout looking fine on desktop but broken on mobile. An online shop can remain visible while checkout, payment, shipping or order emails are not working correctly.

Good maintenance asks whether the website is still doing its job. It does not stop after confirming that the update screen shows a green tick.

Some updates are routine Others are urgent

A current Elementor Pro security issue provides a useful example. CVE-2026-32475 affected Elementor Pro versions up to and including 4.2.1. Under a specific configuration – a published Elementor Pro Form with at least one non-required File Upload field – the vulnerability could allow an unauthenticated attacker to upload an executable file. Elementor Pro 4.2.2 contained the patch.

Wordfence reported that its firewall had blocked more than 190,000 exploit attempts after the vulnerability was publicly disclosed. That figure refers to blocked attempts observed by Wordfence. It does not mean that 190,000 websites were compromised, nor does it mean that every Elementor Pro website was exposed.

The practical lesson is not that Elementor is uniquely unsafe. Popular software will sometimes have vulnerabilities, and responsible developers release fixes. The maintenance question is whether someone is watching for material security developments, checking whether a particular website is affected, and responding at the appropriate speed.

A feature update may be able to wait for the next planned maintenance window. A security fix being actively targeted may need to move to the front of the queue. Responsible maintenance involves making that distinction.

What should happen before an update

The first step is not always to click immediately. It is to understand the website and the proposed change.

• Know what is installed. WordPress core, the active theme, plugins, premium licences, custom code and third-party integrations all form part of the website’s working environment.
• Understand the reason for the update. A critical security fix carries a different urgency from a minor interface improvement.
• Check dependencies and known compatibility concerns. Page builders, themes, add-ons, payment gateways and custom functionality do not operate in isolation.
• Confirm that a current, usable backup exists. WordPress itself advises having a current backup before plugin updates because problems can occur during the process.
• Know how recovery will work. A backup is much less reassuring if nobody knows where it is, what it contains or how the website would be restored.

For higher-risk changes, a staging environment provides a separate place to test before the live website is affected. That is especially valuable for WooCommerce stores and websites with complex integrations. Urgent security situations may sometimes require a faster, proportionate response, but urgency should not remove the recovery and verification steps.

The update itself should be controlled

Updating everything at once may be quick, but it can make troubleshooting harder. If several components change together and something breaks, it becomes more difficult to identify the cause.

A controlled process considers update order, the relationship between components, the site’s traffic or trading schedule, and whether caches or database updates also need attention. Major changes should not be introduced casually during a busy sales period simply because an update notification appeared.

This is where experience becomes useful. The same update can represent very different business risk on a five-page brochure website and on a WooCommerce store that processes orders, calculates shipping, connects to a payment gateway and sends transactional emails.

PHP compatibility upgrades are maintenance too

The maintenance picture extends below WordPress, themes and plugins. WordPress runs on PHP, and each PHP branch has a defined support lifecycle. PHP 8.0 reached end of life in November 2023 and PHP 8.1 reached end of life in December 2025. As of September 2026, PHP 8.2 receives critical security fixes only and is due to reach end of life at the end of the year. Later PHP 8 branches have different support dates.

A website may stay on an older PHP version because a theme, plugin, integration or piece of custom code is not compatible with a newer branch. That may avoid an immediate breakage, but it is not a sound long-term maintenance strategy. Once a PHP branch reaches end of life, it no longer receives official support and may expose the site to security vulnerabilities that have been fixed in newer releases.

The responsible response is a planned compatibility upgrade: identify what prevents the move, update or replace incompatible components, test the website on a supported PHP branch, resolve errors, and then make the production change with a recovery route available. Simply changing the PHP version on a live business website and hoping for the best is no more responsible than blindly applying every plugin update.

Testing the homepage is not enough

After an update, verification should follow the functions that matter to the business. For a typical WordPress website, that may include:

• Opening important pages on desktop and mobile.
• Submitting contact, quotation or application forms and confirming delivery.
• Checking menus, popups, search, downloads and login areas.
• Reviewing page-builder layouts for obvious display problems.
• Checking the administration area for errors, failed tasks or new warnings.

For WooCommerce, the test needs to go further. WooCommerce’s own guidance recommends checking product pages, cart, checkout, payments, shipping, taxes, order emails and extension-specific functions after updates.

In practical terms, someone should follow the buying journey. Can a product be added to the cart? Does checkout open? Are delivery options correct? Can an appropriate test payment or low-risk transaction be completed? Do the customer and administrator receive the expected emails? A store is not healthy merely because its homepage loads.

Security maintenance does not end when malware is detected

The earlier client incident also illustrates the difference between detection and remediation. Imunify360 identified malicious files, but unwanted posts appeared again. That meant the response could not end with deleting the first items that were found.

A broader response was required: reset credentials, remove unnecessary users, bring outdated software up to date, add appropriate security controls, harden the installation and scan again. Depending on the evidence, a proper investigation may also need to review files, administrator accounts, scheduled tasks, logs and other possible persistence mechanisms.

Updating closes known software weaknesses addressed by those releases. It does not travel back in time and prove that an exposed website was never compromised. When there are signs of infection, the maintenance task becomes an incident-response task as well.

That is also why assigning blame too quickly is unhelpful. A compromised WordPress site can involve outdated software, stolen credentials, vulnerable extensions, excessive user access, insecure custom code or weaknesses elsewhere in the environment. The evidence should guide the conclusion.

What should a business owner expect from maintenance

You do not need to become a WordPress security specialist to ask sensible questions about how your website is being cared for.

• How often is the website reviewed for available and urgent updates?
• Who decides whether an update can wait or requires immediate action?
• Are backups current, and is there a clear recovery process?
• Which website functions are checked after maintenance?
• Is the full WooCommerce purchase journey tested where applicable?
• Are unused users, plugins and themes periodically reviewed?
• Which PHP version is the website running, is it still supported, and is there a plan to remove any compatibility blockers?
• What monitoring or security controls are active?
• What happens if malware, suspicious behaviour or a failed update is detected?
• Is there a record of what was changed and what was tested?

The answers should match the importance and complexity of the website. A small information site may not require the same process as a busy online store. It should still have an identifiable maintenance owner, a recovery route and a sensible level of verification.

Maintenance is an ongoing responsibility

A business website is not finished on launch day. WordPress core, themes, plugins, hosting environments and third-party services continue to change. New security information appears. Browsers and devices evolve. Business processes change. A website that worked perfectly six months ago can develop risk or friction without an obvious failure on the homepage.

Clicking Update remains an important part of maintenance. The mistake is treating it as the whole job.

Responsible maintenance adds judgment before the change, protection if something goes wrong, testing after the change, and accountability throughout. That is what helps keep a website secure, functional and useful to the business it represents.

If you are unsure what is currently being checked on your WordPress or WooCommerce website, NBM can help you review the maintenance, security and hosting responsibilities around it.