Discovering your WordPress website has been hacked is one of the more stressful moments a business owner can face online. Pages are redirecting to sites you do not recognise. Google has flagged your domain. Your phone is ringing with customers asking what is wrong with your website. The instinct is to panic – but the situation is recoverable, and the steps to recover it are well established.
At RubyWeb, we worked through exactly this scenario with a client whose WordPress site had been compromised. Unauthorized redirects were firing across the site, and both Google and McAfee had flagged it as a security risk. Every minute the site remained in that state was reputational damage accumulating in real time.
Here is what we did, what caused it, and what it takes to make sure it does not happen again.
How It Happened
The breach was not sophisticated. It did not need to be. Three vulnerabilities had been left open long enough for an attacker to find and exploit them.
Weak login credentials were the first. Predictable usernames and passwords are the lowest-hanging fruit for automated brute-force attacks – bots that cycle through credential combinations at scale until something works.
Outdated software was the second. WordPress core, plugins, and themes all receive regular security updates. Each update patches known vulnerabilities. A site running outdated versions is running with known, publicly documented security gaps – and attackers maintain lists of those gaps.
No active security layer was the third. Without a firewall or security plugin monitoring login attempts, scanning for malware, and blocking known threat signatures, the site had no defence between the public internet and its admin panel.
None of these required a targeted attack. They were conditions that made the site an easy target for automated scanning tools that probe millions of WordPress installations looking for exactly these openings.
Step 1 – Detect and Confirm the Breach
The first priority is confirming the scope of the compromise before touching anything. On this client’s site, a combination of Wordfence and manual file inspection identified malicious code that had been injected into core template files – the code responsible for triggering the unauthorized redirects on every page load.
Signs that your site may be compromised include unexpected redirects, pages you did not create appearing in search results, your domain being flagged by Google Search Console or third-party security tools, unusual admin accounts you do not recognise, and unexplained slowdowns in site performance. Any one of these warrants an immediate investigation.
Step 2 – Back Up Before You Touch Anything
Before any cleanup work begins, take a full backup of the compromised site – files and database. This sounds counterintuitive. Why back up a site that is infected?
Because the cleanup process involves deleting files and modifying code, and if something goes wrong during recovery, you need to be able to return to a known state. A backup of a compromised site is not a backup you want to restore from – it is insurance against making the situation worse during the fix.
Step 3 – Clean the Site
With the backup in place, the cleanup can begin. On this client’s site, we used Wordfence to run a full malware scan and remove the files it identified as malicious, then followed that with a manual inspection of core files and template directories to catch anything the automated scan had not flagged.
This combination matters. Security plugins are effective at identifying known malware signatures, but manual inspection catches custom injections and modified core files that automated tools sometimes miss. For a site that has been actively compromised, doing only one and not the other leaves risk on the table.
If the infection is severe and the source of compromise is unclear, restoring from a clean backup taken before the breach is often the faster and more reliable path to a known-good state.
Step 4 – Update Everything
Once the site is clean, every outdated component needs to be updated immediately. WordPress core, all plugins, all themes – whether they are active or not. Inactive themes and plugins still present attack surfaces if they contain unpatched vulnerabilities, and they should either be updated or removed entirely.
This step closes the vulnerabilities that allowed the breach in the first place. Skipping it, or deferring it, means the cleaned site is immediately vulnerable to the same attack vector that was just exploited.
Step 5 – Rebuild the Security Layer
Cleaning and updating a site returns it to a neutral state. Securing it requires deliberate action.
On this client’s site we implemented Wordfence with firewall rules active, enforced strong password policies across all user accounts, enabled two-factor authentication on admin accounts, set login attempt limits to block brute-force tools, and established a proactive update schedule to ensure the outdated-software vulnerability could not recur.
These are not complex measures. They are the baseline that every WordPress site should have in place before it goes live – and the absence of which makes a site a straightforward target for automated attacks.
After Recovery: Getting Google’s Trust Back
A site that has been flagged by Google as dangerous does not automatically recover its standing once the malware is removed. You need to request a security review through Google Search Console, confirming that the issue has been resolved and asking Google to re-evaluate the site. The timeline for this varies, but submitting the request promptly after cleanup is the only way to begin the process.
Until Google clears the flag, the site may display security warnings to visitors in Chrome and other browsers – which means every day without the review request submitted is another day of reputational damage.
What This Client’s Experience Makes Clear
The hack was preventable. Not with sophisticated security architecture or enterprise-grade tooling – with basic, consistent maintenance that most WordPress sites simply do not receive.
Outdated plugins and themes are the most common entry point for WordPress compromises, and they are entirely avoidable. Weak credentials are the second most common, and they are trivially fixable. The businesses that get hacked are not usually targeted because they are valuable – they are caught because they are easy.
Proactive WordPress maintenance – regular updates, active security monitoring, strong credential policies, and scheduled malware scans – is not expensive relative to the cost of a breach. A hacked site costs money directly in recovery time and developer hours, and indirectly in lost traffic, lost leads, and the time it takes to rebuild search engine trust after a security flag. The math strongly favours prevention.
If your WordPress site is not being maintained proactively, it is carrying risk that compounds quietly until it does not. RubyWeb’s Monthly Care Plans exist to close that gap – regular updates, security monitoring, uptime management, and a team that knows your site before a crisis requires them to.
