WordPress Hacked: What To Do Right Now

First: confirm your WordPress site has actually been hacked

Before taking any drastic action, spend five minutes confirming you are dealing with a genuine compromise rather than a plugin conflict, a hosting outage, or a false alert from a security scanner.

The most reliable confirmation signals are:

• Redirects to unfamiliar sites — visitors (especially those arriving from Google) are sent to spam, phishing, or adult content. This is a near-certain sign of a hack, not a plugin issue.
• Google warnings — search results showing "This site may be hacked" or "Deceptive site ahead" browser warnings. Check Google Search Console for security issues and manual actions.
• Hosting suspension or warning — your hosting provider has flagged or suspended the account for malicious activity or outbound spam.
• Unfamiliar admin accounts — users in your WordPress admin you did not create, often with administrator privileges and email addresses you do not recognise.
• Spam content in your pages — search Google for site:yourdomain.co.uk and look for results containing pharmaceutical spam, gambling links, or foreign-language pages you never created.
• Your site sends emails you did not write — customers or contacts receive phishing or spam emails appearing to come from your domain.

If you see any of the above, treat it as confirmed. Do not wait for multiple signals before acting — one is enough.

Step 1 — Contain the damage immediately

The most important principle in the first 15 minutes is containment. Your goal is not to fix the site yet — it is to stop the situation from getting worse.

Put the site into maintenance mode or take it offline

If you can still access WordPress admin, activate a maintenance mode plugin or set your site to "Coming Soon" mode. If you cannot access the dashboard, ask your hosting provider to temporarily take the site offline or password-protect the root directory. This protects your visitors from being exposed to malware and limits further damage to your SEO and reputation while you work.

A few hours of intentional downtime is far less damaging than leaving a compromised site live and actively harming visitors.

Change your WordPress admin password immediately

Log into WordPress and change your admin password to something long, unique, and randomly generated (use a password manager). Do this for every admin account on the site, not just your own. If you cannot log in, reset your password via the hosting panel or directly in the database through phpMyAdmin.

Revoke access for unfamiliar admin users

In WordPress admin, go to Users and look for accounts you do not recognise — especially any with Administrator role. Delete them immediately, but screenshot the user list first. That evidence matters for your post-incident review and potentially for GDPR reporting.

Contact your hosting provider

Notify your host that the site is compromised. They can confirm whether the infection extends beyond WordPress to server-level files, check for outbound malicious traffic, and may have access logs that help trace the entry point. Many hosts have a security team that can assist with initial containment.

Step 2 — Assess what has been exposed

Once the site is contained, your next task is understanding the scope — not because you need a complete answer right now, but because the scope determines how you respond, who you need to tell, and whether regulatory obligations apply.

Work through these questions quickly:

• Does your site store or process personal data? — customer names, email addresses, payment information, order history, membership data. If yes, a potential data breach is now on the table.
• Is this a revenue-generating site? — WooCommerce store, lead generation, booking system, membership platform. If yes, every hour of downtime has a direct financial cost. Escalate accordingly.
• Has this happened before? — a previous hack that was "cleaned" and came back is almost certainly a missed backdoor situation. That changes the response approach significantly. See our guide on why WordPress sites keep getting hacked for the full explanation.
• Are other sites on the same hosting account? — shared hosting means a compromised site can spread malware laterally to other sites in the same account. All sites on the account need to be checked.

You do not need precise answers yet. But knowing whether personal data is involved and whether revenue is affected determines the urgency and the regulatory path.

Step 3 — Document before you clean

This step is routinely skipped and almost always regretted. Before removing anything, take screenshots and notes of:

• Any unfamiliar admin users (name, email, role, registration date)
• Error messages, redirects, or symptoms you observed
• Hosting provider alerts or suspension notices (forward these to yourself)
• Google Search Console security issues screenshots
• Your file manager or FTP, noting any recently modified files

This documentation serves two purposes. First, it helps with the forensic investigation — knowing which files changed when narrows down the entry point considerably. Second, if personal data was exposed and UK GDPR applies, you will need a written record of when you discovered the breach, what you found, and what you did. Without it, you are reconstructing from memory under pressure.

Step 4 — Clean up in the right order

Most hacked WordPress guides jump straight to "install Wordfence and run a scan." That is the wrong starting point. Clean-up in the wrong order either destroys evidence or misses the actual problem. Here is the correct sequence:

1. Rotate every credential — before touching the files

Change all of the following before you start removing malware:

• All WordPress admin passwords
• FTP / SFTP credentials
• Hosting panel (cPanel, Plesk, or your host's dashboard) password
• Database password — and update wp-config.php to match
• Any email accounts tied to the domain, particularly those used for WordPress recovery emails

If attackers still have valid credentials to your hosting panel or database, cleaning the WordPress files is pointless — they will reinfect the site within hours.

2. Back up the compromised site before removing anything

This sounds counterintuitive, but take a backup of the infected site before cleaning. A compressed archive of the infected files gives you a forensic baseline to return to if something goes wrong during cleanup, and it preserves the evidence needed to trace the entry point. Do not rely on this backup to restore from — only to investigate from.

3. Run a thorough file-level scan

Free scanners like Wordfence or the Sucuri SiteCheck tool are a starting point, but they work by comparing file signatures against known malware patterns. Custom backdoors, obfuscated PHP, and malicious code injected into otherwise legitimate files are frequently missed. A proper scan checks every file on the server — not just the WordPress install directory — and decodes obfuscated code to analyse what it actually does.

Pay particular attention to:

• wp-content/uploads — this folder is writable by WordPress, so attackers commonly plant PHP backdoor files here disguised as images or alongside real uploads
• Recently modified files — sort by modification date in your file manager. Files changed on the day of the hack or shortly before are prime suspects
• WordPress core file replacements — compare your wp-includes and wp-admin files against official WordPress release checksums
• Database content — injected JavaScript in post content, widget settings, or theme options will not show up in a file scan

4. Remove malware and close the entry point

Remove infected files, restore clean versions of core WordPress files from official releases, and identify the vulnerability that allowed the entry — whether that is an outdated plugin, a compromised credential, or a nulled theme. Update or remove the vulnerable component before bringing the site back online. Cleaning the malware without closing the entry point means the infection will return, often within 48 hours.

5. Harden before going live again

Before restoring public access, apply these baseline hardening steps:

• Delete every unused plugin and theme — inactive plugins retain their vulnerabilities
• Enable two-factor authentication on all admin accounts
• Disable XML-RPC if you do not use it (a common brute-force and DDoS vector)
• Block PHP execution in the uploads directory via .htaccess
• Set correct file permissions: 755 for directories, 644 for files, 600 for wp-config.php
• Enable a Web Application Firewall (Cloudflare or Wordfence Premium)

6. Request blacklist removal

Once the site is clean and hardened, submit a review request through Google Search Console if your site was flagged. This process typically takes 1–3 days once submitted. Do not request a review before the site is genuinely clean — a failed review adds delay and signals to Google that the site is still a problem.

Can you fix a hacked WordPress site yourself?

Honestly: sometimes yes, often no — and it depends entirely on the type and depth of the compromise.

DIY cleanup works reasonably well when the hack is a single infected plugin on a simple site with no customer data, the site has not been hacked before, and you are technically comfortable working in file managers, phpMyAdmin, and FTP. Following the steps above methodically gives you a reasonable chance of a clean result.

DIY cleanup is likely to fail when:

• The site has been "cleaned" before and the infection returned — this almost always means a missed backdoor that basic tools do not detect
• The site runs WooCommerce, a membership platform, or any system processing personal data
• The infection involves server-level access rather than just WordPress files
• You find unfamiliar admin accounts or signs of ongoing attacker access
• The site's income means downtime or reinfection has a direct financial cost

The practical risk of a partial DIY cleanup is a surface-clean site with a missed backdoor still active. The site looks clean, you go live, and within days or weeks the infection returns — often worse than before because the attacker has had more time to embed persistence. At that point you are paying for a professional cleanup on top of the DIY time already spent.

If any of the above apply, the most cost-effective path is professional recovery from the start. Our hacked website recovery UK service is built around forensic-level cleanup — not a surface scan — precisely because surface scans are where repeat hacks originate.

UK businesses: GDPR and the ICO's 72-hour clock

If your WordPress site handles personal data — customer names, email addresses, order history, payment details, enquiry form submissions — a hack is a potential data breach under UK GDPR, and that triggers specific obligations.

Under UK GDPR Article 33, you have 72 hours from becoming aware of a breach to notify the ICO if the breach is likely to result in a risk to individuals. The clock starts when you first become aware — not when the investigation is complete.

What this means in practice:

• You do not need to wait for certainty. If you discover your site is compromised and it stores personal data, start your internal breach assessment immediately. Document what you found, when you found it, what data may be affected, and what actions you have taken.
• Not every hack requires ICO notification. If the breach is unlikely to result in a risk to individuals — for example, a simple malware injection with no evidence of data access — you may not need to notify. But you do need to document your reasoning.
• Customer notification may also be required. If the risk to individuals is high, you must notify affected individuals without undue delay.

Our full guide on ICO breach reporting for hacked websites covers the assessment framework in detail. For clients using our recovery service, we provide a written incident summary that supports your internal decision-making and any follow-up with legal or compliance teams.

What happens if you rush or skip steps

The most expensive outcome from a WordPress hack is not the initial compromise — it is a failed cleanup that leads to reinfection. Here is what typically goes wrong when steps are skipped:

• Cleaning without rotating credentials → attacker re-enters via still-valid FTP or hosting credentials within hours
• Surface scan only → backdoor in uploads folder or obfuscated in a plugin file is missed, reinfection within days
• Fixing malware without closing the entry point → same plugin vulnerability exploited again by automated bots within the week
• Requesting Google review before the site is clean → failed review, additional delay in blacklist removal, continued ranking damage
• Skipping the documentation step → if personal data was exposed, you are now reconstructing a breach timeline under pressure with no written record

If you have already attempted a cleanup and the infection has returned, the most important thing to accept is that a missed backdoor is almost certainly present. Read our guide on why WordPress sites keep getting hacked to understand exactly where backdoors hide and why basic tools miss them. At that point, a professional malware removal that includes forensic-level file inspection is the right next step — not another DIY scan.