Hacked WordPress Site? 5 Ways to Remove Malware and Keep It Out

The call usually comes on a Monday. A client’s customer clicked their Google listing and landed on a casino site, or Search Console has started listing pages in Japanese that nobody wrote. Most hacked WordPress sites are spotted by someone outside the business, which means the infection has often been there for a while.

Cleaning one up is rarely a matter of deleting a single bad file. A scanner can remove the obvious code while a backdoor waits in the database, a modified plugin or a scheduled task, ready to bring everything back. This guide sets out five recovery methods, from a quick scanner clean to a full rebuild, and the checks that prove the site is clean before you hand it back.

What does WordPress malware removal involve?

It means finding malicious code in a site’s files, database and user accounts, removing it without damaging legitimate content, closing the route the attacker used and testing that everything still works. Deleting whatever a scanner flags is only one part of the job.

Small businesses are not too small to be targets. The UK government’s Cyber Security Breaches Survey 2025/2026 found that 43% of UK businesses reported a breach or attack in the previous 12 months. Any WordPress site that takes enquiries, bookings or payments sits inside that risk.

How can you tell a WordPress site has been hacked?

The usual signs are unexpected redirects, spam pages in Google, admin accounts nobody created, browser or Search Console warnings and a host suspending the account. Some infections hide from logged-in admins and only show themselves to visitors or search engines, so always check from the outside too.

• Visitors from Google or on mobile get redirected, while logged-in users see the normal site.
• A site:yourdomain.co.uk search shows spam pages about casinos, pharmacy, replica goods or in Japanese.
• Search Console lists hacked content or malware under Security issues.
• Unknown administrators, application passwords or plugins appear in the dashboard.
• PHP files turn up in wp-content/uploads, which should only hold media.
• The site slows down, server load spikes or outgoing email bounces because the server is blacklisted.

Note what you see and when. That becomes the first entry in the incident record.

What should happen in the first hour?

Contain the problem and protect the data before deleting anything.

1. Take an infected snapshot. Download the files and export the database, and store them away from clean backups. Never restore this copy; it is evidence.
2. Save the logs. Ask the host for access and error logs covering the last few weeks. They often show how the attacker got in.
3. Change every password. Hosting, cPanel, SFTP, database and WordPress admin, from a device you trust. Stolen credentials often come from an infected laptop.
4. Protect live data. On shops and booking sites, orders keep arriving while you work. Never overwrite the live database with an older copy without reconciling new records first.
5. Check for exposed personal data. If customer data may have been accessed, UK GDPR may require a report. The ICO’s breach reporting guidance says that where a risk to people is likely, you must tell the ICO without undue delay and, where feasible, within 72 hours. This is general information, not legal advice.

Which recovery method fits which situation?

Use the least disruptive method that fully explains the infection. Most cases start with a scanner. If the malware comes back or the scanner misses symptoms you can see, escalate.

Method	Best for	Access needed	Disruption
1. Scanner clean (Wordfence)	Known malware in files and the database	WordPress admin	Low
2. Manual investigation	Backdoors and infections the scanner missed	SFTP or SSH, database	Low to medium
3. Isolated clone with AI-assisted review	Complex or obfuscated infections	SSH, database export	Medium; live site untouched
4. Fresh WordPress rebuild	Installations that can no longer be trusted	SSH, database, hosting panel	Medium to high; planned switchover
5. Elementor kit rebuild	Repeat infections on Elementor sites	WordPress admin, Elementor	High; design matching needed

Methods 1 to 4 build on each other. Method 5 replaces method 4 on Elementor sites; it is not an extra step.

Method 1: Clean with a security scanner

Install Wordfence from WordPress.org, run a high-sensitivity scan and review each result before acting. Never bulk-delete everything the scan flags.

1. Install or update Wordfence and set the scan to High Sensitivity.
2. Run the scan and save the results before changing anything.
3. For modified core files, view the differences and use Repair only after a backup.
4. For modified plugin or theme files, decide whether the change is a deliberate customisation. If not, reinstall from the official source.
5. For database findings, fix the exact post, option or comment, nothing wider.
6. Scan again and recheck the original symptoms.

Take care in the database. Attackers hide scripts and redirects in wp_options, post content, post meta, theme settings and page-builder data, and a blind SQL search-and-replace can corrupt serialised settings. If you must replace a string across the database, WP-CLI’s wp search-replace handles serialised data, and its --dry-run flag previews the change.

Method 1 is enough only when the infection is limited, every change is understood and there is no sign of a backdoor or compromised account. If anything comes back, move on.

Method 2: Find what the scanner missed

Look where security plugins do not always look: must-use plugins, uploads, server config files, scheduled tasks, user accounts and the database. Compare anything suspicious with a known-good copy and trace what loads it before removing it.

Area	What to look for
Core folders	Unexpected or altered files in the root, wp-admin and wp-includes
wp-content	Unfamiliar PHP or JavaScript in plugins, themes, mu-plugins and uploads
Configuration	Unauthorised includes or redirects in wp-config.php, .htaccess, .user.ini and php.ini
Accounts	Admin users and application passwords nobody recognises
Persistence	WordPress cron events and server cron jobs that recreate deleted files
Database	Injected scripts and links in wp_options, wp_posts, wp_postmeta and custom tables

With SSH and WP-CLI, these read-only checks cover a lot of ground from the WordPress root:

# Compare core and plugin files with the official WordPress.org versions
wp core verify-checksums
wp plugin verify-checksums --all

# List administrators and scheduled events
wp user list --role=administrator
wp cron event list

# PHP inside uploads (there should be none)
find wp-content/uploads -name "*.php"

# PHP files changed in the last 7 days
find . -type f -name "*.php" -mtime -7

# Common obfuscation functions (a clue, not proof)
grep -rlE "base64_decode|gzinflate|str_rot13|eval\(" wp-content

For the database, start with read-only queries and swap wp_ for the site’s table prefix:

SELECT option_name FROM wp_options
WHERE option_value LIKE '%<script%' OR option_value LIKE '%eval(%';

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%display:none%';

Checksum verification only covers plugins hosted on WordPress.org, so compare premium plugins with a fresh vendor download. Legitimate tracking code will also match the script query, which is why every hit needs a human look. Obfuscated code is a clue rather than proof, because some genuine plugins encode their files. If the same code keeps coming back, stop deleting the symptom and find what recreates it.

Method 3: Clone the site and investigate offline

Copy the files with rsync over SSH, export the database separately and keep one untouched evidence copy. Work on a duplicate in an isolated local environment, with outgoing email, payments and API connections switched off so the copy cannot contact customers or live systems.

# 1. Copy the files (adjust user, server and path)
rsync -avz -e ssh user@yourserver:/home/user/public_html/ ./site-evidence/

# 2. Export the database (on the server)
wp db export site-evidence.sql

# 3. Work on a duplicate, never the evidence copy
cp -r ./site-evidence ./site-working

Having the files and database side by side makes it easier to connect a suspicious script to the option, widget or template that loads it. An AI model can speed this up by explaining what obfuscated code appears to do and suggesting where to look next. It can also miss malware or flag genuine code, so treat it as an assistant and verify every finding against the code, the logs and a trusted copy.

Protect confidential data while you do it. Never paste customer databases, passwords, keys or personal data into an external AI service; use redacted snippets or run the analysis locally. Clean confirmed items in the working copy and keep a change log of every file and record touched.

Method 4: Rebuild on fresh WordPress

When the existing installation cannot be trusted, do not re-upload it after cleaning. Install fresh WordPress, bring across only the content and settings you have inspected, reinstall plugins and themes from trusted sources and import the cleaned database.

Item	Action
WordPress core	Replace with a fresh download from WordPress.org
Plugins and themes	Reinstall from the official source; never copy old executable files
Child or custom theme	Keep only after a line-by-line review
Uploads	Keep after removing any PHP or script files
wp-config.php	Rebuild with reviewed settings and new salts (wp config shuffle-salts)
Database	Import the cleaned copy, then check URLs and serialised data
Credentials	Rotate every admin, hosting, SFTP, database and API credential

Before switching over, test the rebuilt site: navigation and key pages, media and downloads, forms and email delivery, logins, mobile layout, checkout or booking flows in test mode, and a final scan. Then back up the live site, reconcile any new orders or registrations, switch on maintenance mode at a quiet time, replace only the infected installation, import the clean database and retest everything on the live domain.

If the rebuild grows into replacing an abandoned theme or plugin, our white-label WordPress team can take it on. Be wary of anyone promising zero data loss or a permanently hack-proof site before they have seen the facts.

Method 5: Rebuild an Elementor site from a kit

For Elementor sites that keep getting reinfected, export a website kit, inspect it, import it into a fresh installation and compare the result page by page. A kit can include pages, templates, global styles and site settings, depending on the Elementor version and plan.

1. Export the website kit from Elementor.
2. Inspect it before importing. It is a ZIP of JSON and media, so search for <script, <iframe, base64 and unfamiliar external URLs. An export tool is not a malware scanner.
3. Install fresh WordPress, then Elementor and the required plugins from trusted sources.
4. Import only the reviewed content; never the old database or PHP files.

Then compare the new site with the original on desktop and mobile, and rebuild missing menus, forms and integrations by hand. A kit does not carry WooCommerce orders, member records or most third-party plugin settings, so plan those separately.

How do you prove the site is clean?

Sign off against six areas before handing the site back.

Area	Done means
Security	No malicious code; admins, cron jobs, hosting access and the entry point reviewed
Credentials	Passwords, salts, keys and tokens rotated; two-factor authentication on every admin
Data	Pages, media, accounts and orders reconciled against trusted backups
Functionality	Forms, email, search, caching, checkout and integrations tested
SEO	No spam pages, hidden redirects, stray noindex tags, wrong canonicals or broken sitemaps
Monitoring	Scheduled scans, uptime checks and file-change alerts switched on

Most reinfections come through the same doors: outdated plugins, unused themes, shared admin logins and no off-site backups. Keep everything updated, delete what is not used and give each person their own account with the lowest role they need. Adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php switches off the built-in file editor. That routine care is what our website maintenance plans cover, and our security and malware cleanup team handles recoveries.

Does a hack damage SEO?

It can. Spam URLs, hidden links and cloaked content erode trust and can trigger Search Console warnings. After the cleanup:

1. Open the Security issues report in Search Console and note every issue and example URL.
2. Search site:yourdomain.co.uk for spam pages and make sure they now return 404 or 410.
3. Check titles, canonicals, robots tags, redirects and sitemaps for unwanted changes.
4. Confirm the cleanup did not remove genuine pages that used to rank.
5. Request a review from the Security issues report.

Run the security and SEO recovery together. If rankings fell after the hack, our technical SEO team can audit the damage.

When should you bring in specialists?

Get help if there is no SSH or database access, the site handles payments or personal data, the malware has returned more than once, or the hosting account itself may be compromised. In those cases a wrong move can lose orders, expose data or leave a backdoor behind. No method can guarantee a site will never be hacked again; a careful recovery removes what was found, closes the way in and leaves evidence that the site is clean today.

Frequently asked questions

Can a security plugin remove all WordPress malware?

No scanner can promise that. Wordfence catches a lot of known malware, but custom code, new strains and backdoors such as rogue admins or cron jobs often need manual investigation too.

Can malware hide in the database?

Yes. Scripts, spam links and redirects often sit in wp_options, post content, post meta, theme settings and page-builder widgets. Clean record by record so you do not break serialised data.

Does reinstalling WordPress remove a backdoor?

Not on its own. Malware can survive in wp-content, wp-config.php, the database, server settings, cron jobs or stolen passwords. A reinstall works as part of a full investigation.

Can AI clean a hacked site automatically?

No. AI can speed up code review and suggest leads, but it misses things and flags genuine code. Use it to support the investigation, verify every finding and never share credentials or customer data with an external tool.

How long does a cleanup take?

A contained infection can be cleaned in hours. A repeat infection that needs investigation and a rebuild usually takes longer, depending on the site’s size, access and how much data must be reconciled.

The bottom line

Match the method to the damage: a scanner for simple cases, manual checks when it falls short, and an isolated clone, fresh rebuild or Elementor kit for stubborn ones. Whatever the route, verify findings, protect real data, close the way back in and test the whole site before calling it recovered. If a client’s site is redirecting, showing spam or getting reinfected, send SoftVolt AI a brief.