A contact form that suddenly redirects visitors to a gambling site is not a minor WordPress fault. It is a business risk. In this WordPress malware cleanup case study, an anonymised UK small business website went from an apparently isolated redirect to a fully cleaned, hardened and monitored site within 48 hours.

The site was a brochure website built on WordPress, with service pages, a quote form and a small blog. It did not take payments directly, but it generated valuable enquiries. That distinction mattered: the immediate concern was not only data loss, but lost leads, reputational damage and the possibility of search engines flagging the domain as unsafe.

The incident: a redirect that did not happen every time

The owner first noticed the problem after a prospective customer reported being sent elsewhere after opening a page from a Google result. The issue could not be reproduced consistently. On some visits the site loaded normally. On others, it redirected to an unrelated and unsafe-looking website.

That inconsistency is common with malicious code. Attackers often configure redirects to trigger only for visitors arriving from search engines, on certain devices, or after a delay. It helps the infection stay hidden from the site owner while still exploiting ordinary visitors.

Initial checks found four warning signs:

• unexpected JavaScript loading from an unfamiliar external domain;
• recently modified WordPress files outside normal update activity;
• administrator accounts the business could not identify; and
• outbound messages queued from a compromised mailbox linked to the website.

The site was still online, but leaving it untouched while investigating would have created more risk. A good response needed to preserve evidence, protect visitors and avoid making the site unavailable for longer than necessary.

WordPress malware cleanup case study: the first response

The first decision was not to start deleting files. Removing the visible redirect without identifying the entry point can leave a backdoor behind. That is how a site appears fixed, only to become infected again days later.

We began by taking a complete snapshot of the hosting account, including files, databases and logs. This created a recovery point and allowed the investigation to continue without relying on a potentially altered live environment. Access credentials were then reset, starting with hosting control panel access, SFTP, WordPress administrator accounts and associated email accounts.

The affected site was placed behind a temporary maintenance page while the clean-up took place. For a high-volume ecommerce site, a different approach may be preferable, such as restricting access by IP address or restoring a clean staging copy while keeping essential checkout functions live. In this case, a short, controlled interruption was safer than continuing to expose visitors to malicious redirects.

Next came a comparison of the WordPress core files against clean, official versions. WordPress core, active plugins and themes were reviewed separately because each has different risks. Core files can usually be replaced cleanly. Plugins and themes need closer attention, especially where a site relies on customised templates or older components that may not be supported.

Finding the real source of the infection

The redirect script was not sitting neatly in a single plugin folder. Malicious code had been injected into a modified theme file and concealed in an unfamiliar PHP file within the uploads directory. PHP files in uploads are not always malicious, but they deserve immediate scrutiny because that directory should normally hold media files rather than executable code.

A second backdoor was found in a plugin directory. It used an innocent-sounding filename and heavily encoded code designed to evade a quick visual check. This explained why simply removing the redirect would not have been enough. The attacker had retained a route back into the site.

The database was also checked for injected scripts in posts, widgets and site options. No malicious database entries were found, which reduced the amount of restoration work required. The investigation pointed instead to a vulnerable, outdated plugin as the likely initial entry point. It had not been updated for a long time and was no longer needed for the website’s current functionality.

This is where website owners can make an expensive mistake. A backup from before the visible problem is useful, but it is not automatically clean. Malware can sit quietly for weeks. Restoring an old backup without scanning it may simply reinstate the infection and erase more recent enquiries, content or configuration changes.

Cleaning, restoring and testing safely

The remediation work followed a clear order. Infected core files were replaced with known-clean WordPress files. The obsolete vulnerable plugin was removed rather than updated, as the site no longer depended on it. The compromised theme files were cleaned using a verified copy, while legitimate customisations were checked and restored carefully.

All unauthorised administrator accounts were deleted. Existing users were reviewed to confirm they had only the access they needed. The database credentials were changed, WordPress security keys were refreshed and the site configuration file was checked for unexpected instructions.

A full malware scan was then run across the account, followed by a manual review of the locations most often abused in WordPress compromises: uploads folders, cache directories, temporary folders, plugin and theme directories, scheduled tasks and configuration files. Scheduled tasks are easy to overlook. A malicious cron job can recreate a deleted file or continue sending unwanted messages after the visible infection has gone.

Before the site returned to public view, it was tested in a clean browser session across desktop and mobile devices. We checked key pages, forms, search-result landing pages and administrative functions. Redirect behaviour was tested repeatedly because the original infection had been selective.

The website was restored without losing its recent content. More importantly, it was restored with a documented record of what had changed. That gives the owner and support team a clearer basis for future troubleshooting than a rushed, unexplained fix.

Hardening the site after malware removal

Clean-up is only half the job. The next priority was reducing the chance of a repeat incident without making routine site management difficult.

The owner removed unused plugins and themes, updated the remaining components and introduced a simple update routine. Automatic updates can be sensible for WordPress core and trusted plugins, but they are not a substitute for oversight. Sites with custom functionality should be tested after major updates, ideally in a staging environment first.

Daily backups were enabled and checked for successful completion. A backup policy is only useful when restoration is practical, so the business also documented who could request a restore and what information they would need to provide. Malware scanning, a web application firewall and login protection were added to provide earlier warning of suspicious activity.

Hosting security matters here as well. A secure, fast and reliable hosting environment with regular backups, malware scanning, DDoS protection and responsive technical support gives small businesses a stronger starting point. At Blended Hosts, those protections are designed to help website owners manage risk without adding enterprise-level complexity or long-term contracts.

What this case tells WordPress site owners

The owner had assumed that a small brochure site would be of little interest to attackers. In practice, compromised websites are often used as infrastructure for redirects, spam, phishing or distributing further malware. Traffic volume and company size do not provide protection.

The most useful lesson was that the warning arrived from a customer, not a monitoring alert. That is not a criticism of the customer. It is a reminder that intermittent malware is designed to avoid detection. Regular scans, timely updates and tested backups make the difference between a contained incident and a longer, more damaging recovery.

If your WordPress site behaves differently for visitors than it does for you, treat it as urgent. Preserve a backup, change access credentials, investigate the cause and verify the result properly. A quick fix may remove the symptom; a careful clean-up gives your website a credible route back to earning trust.