How to Remove Malware from a WordPress Site

How to Remove Malware from a WordPress Site

You open your store before the first customer arrives and see visitors redirected to an unfamiliar page. Strange links fill your product descriptions, or your password no longer gets you into wp-admin. If you're working out how to remove malware from a WordPress site, you may be dealing with compromised files, a poisoned database, stolen credentials, unsafe hosting access, or another infected site in the same account.

Most site owners don't have a bad-file problem. They have an uncontrolled incident-response problem. Deleting the file that looks suspicious can destroy evidence while the attacker keeps access elsewhere. You need a calm sequence, not a rushed scanner tutorial.

What a safe WordPress malware response covers

The safe response starts with containment and evidence preservation, then moves through backup inspection, file and database scanning, persistence removal, credential rotation, patching, verification, and monitoring. ShieldThemes can handle WordPress maintenance, hosting, security, and recovery when you lack safe access or time, although an internal technical team may still need to approve business and account decisions.

Contain the Infection Before Lost Sales and Search Visibility Compound

A compromised WordPress site is a business incident before it becomes a repair task. If you keep serving infected pages, accepting logins, or changing files without a record, you can lose customer trust while destroying clues about the entry point.

Start by restricting access, preserving a usable copy, and identifying every site in the same hosting account. That sequence limits damage and gives you evidence for a cleaner recovery.

Signs your WordPress site may be hacked

Redirects, unfamiliar links, lost administrator control, and unexplained content changes are strong indicators that your site may be hacked, although inspection is still required for confirmation. Treat a sudden redirect to an unfamiliar domain or a new administrator account as urgent, not as a minor display fault.

Patchstack reported that WordPress malware removal can cost more than $150, before lost revenue, wasted advertising spend, or longer-term search visibility damage. That figure is a practical warning: acting blindly can cost more than the cleanup itself.

Visible symptoms that justify treating the site as hacked

Put the site behind maintenance mode or restricted access, stop nonessential logins, and use a clean device for administrative work. Don't edit infected files immediately. First preserve a full copy of the site files, export the database, and save relevant access and server logs when your host provides them.

Weak: “The site is in maintenance mode,” while administrators continue signing in from several devices and customers can still reach cached infected pages.

Strong: “Maintenance mode is active, public access is restricted, and only one approved administrator is using a clean device during the investigation.”

Preserve first, clean second

Preserving a snapshot protects timestamps, injected content, logs, and the original file state that may reveal how the attacker entered. A usable copy also lets you compare later changes instead of guessing which files were altered.

Practical rule: Preserve a complete, usable snapshot before deleting, overwriting, or restoring any suspicious file.

“Malware can move from one site to another and infect an entire hosting environment.” Patchstack reported this warning on September 3, 2024.

Why shared hosting can turn one infected site into several

List every domain, staging site, subdomain, and WordPress installation sharing the hosting account. Malware may move between sites in one hosting environment, so checking only the visibly damaged domain is unsafe. Patchstack says every site in the same hosting environment needs the malware-removal process reviewed, even when only one site shows symptoms.

During cleanup, nobody besides you and the approved technical responders should retain access. Once the snapshot is secured, continue from a clean device with controlled access, not from the compromised browser session that may still expose passwords or active sessions.

Choose the Free, Restore, or Manual-Cleanup Route From Evidence

You may know your WordPress site is compromised without knowing whether restoration, investigation, or hands-on cleanup is safest. Your next move depends on what you can preserve, which access remains trustworthy, and whether your current data changes too often for a backup rollback.

Before altering the site, create a recoverable evidence set. Sucuri recommends backing up both your website and database before malware removal so you can recover if cleanup causes damage. Free tools can reveal leads, but your evidence must decide the route.

What to collect before changing the site

Gather the access details, exports, logs, and clean equipment you need before changing the site. Sucuri also advises preserving a backup of the files and database before removal work begins.

• Hosting access: Confirm access to your hosting control panel, or verify SSH and SFTP credentials from a clean device.
• Database export: Export the WordPress database through phpMyAdmin or Adminer, and save the untouched export separately.
• Site files: Copy the WordPress files, uploads, configuration file, and server rules without overwriting the originals.
• Logs: Download hosting, server, firewall, WordPress security, and authentication logs while they are still available.
• Clean device: Use a device checked for malware, with updated security software and no active session from the suspected site.
• Access record: List administrators, hosting users, SSH keys, SFTP accounts, database users, and connected services for later rotation.

Remove malware from your WordPress site safely

You can remove malware from your WordPress site through verified restoration, controlled manual cleanup, or scan-led investigation after preserving evidence. A genuinely clean and functional backup may be the safest route, but restoring it can discard legitimate orders, customer records, posts, or configuration changes.

situation	better move
A verified clean and functional backup exists	Restore it after preserving the infected files and database as evidence, then patch the original entry point.
The site has frequent content, orders, or configuration changes	Prefer a controlled manual cleanup or staged rebuild so current legitimate data is not discarded.
No clean backup is available and budget is limited	Use free scans and file, database, log, and timestamp review to investigate, but validate every finding manually.

Sucuri says a clean, working backup may let you skip the malware-removal process altogether. You still need to preserve the infected version first and investigate how the attacker entered.

Remove malware from a WordPress website for free

You can investigate malware on a WordPress website for free with scanner results, file comparison, database searches, and log review, but no automated scan alone proves your site is clean.

Use the supplied command as an investigation aid when SSH is available: find . -type f -mtime -90. Sucuri describes this command as a way to find files modified within the last 90 days. Recent modification is a lead, not proof of maliciousness.

Weak conclusion: “The scanner found no malware, so your store is clean.”

Stronger conclusion: “The scanner found no known malware, so you still need manual checks of files, database content, logs, users, and scheduled tasks.”

If your site needs staging, forensic review, or safe restoration, ShieldThemes can provide an accountable technical partner. That route costs more than a free scan, but it gives you controlled handling when lost data or recurring infection carries a higher cost.

Clean WordPress Files and Database in a Controlled Sequence

A hacked WordPress site needs controlled handling, not frantic file deletion. If you clean one visible redirect while a hidden backdoor remains in your uploads, database, or scheduled tasks, you may reopen the same infection.

Keep a record of the original state, use clean replacements for trusted code, and test the result before public access returns. The sequence below gives you a defensible way to fix a hacked WordPress site without guessing.

Fix a hacked WordPress site

You fix a hacked WordPress site by restricting access, preserving evidence, scanning every layer, replacing compromised code, rotating credentials, patching the entry point, and verifying the result before reopening it.

1. Restrict public access and capture a forensic copy

Put your site behind a maintenance page or hosting-level restriction before changing files. Capture a full copy of your files, database, access logs, error logs, scheduled tasks, and relevant timestamps. Keep the copy read-only so you can compare it if the infection returns.

Done looks like: You have a dated archive, a database export, server logs, and a record of active administrators, hosting users, and scheduled jobs.

Failure point: If you clean first, you may erase evidence showing which account, plugin, or request introduced the malware.

After you close the site to the public and scan the computer you will use, change hosting, SSH, FTP, MySQL, and WordPress-user credentials, following Patchstack’s September 3, 2024 malware-removal guidance. Do this from a clean device, not from a computer that may also be infected.

2. Scan core, plugins, themes, uploads, and the database

Scan your frontend and wp-admin area, then inspect WordPress core, plugins, themes, hidden files, uploads, configuration files, database content, cron jobs, and access logs. Search for injected scripts, unexpected administrator accounts, altered options, obfuscated PHP, and redirects. A random filename is a lead, not proof, so compare suspicious items with a trusted release before removal.

Done looks like: You have a written list of confirmed malicious files, database entries, users, scheduled tasks, and indicators that require removal.

Failure point: A scanner that reports no known signature does not prove that your database, logs, or backdoors are clean.

3. Replace or remove compromised code instead of guessing at edits

Replace your WordPress core with a fresh copy matching your installed release rather than editing compromised core files in place. Reinstall trusted plugins and themes from known sources, remove abandoned or unauthorized packages, and clean confirmed injected database content. Never delete an unfamiliar file solely because its name looks random.

Before: You edit a suspicious line inside a modified wp-includes file and leave the rest untouched.

After: You replace the matching WordPress core package, reinstall approved extensions, and verify that your configuration and uploads remain intact.

Done looks like: Your core files match a trusted release, every extension has a known source, and confirmed backdoors no longer appear in files, tables, users, or scheduled tasks.

Failure point: If you preserve a compromised plugin because the site depends on it, the attacker may regain access as soon as you reopen the site.

4. Rotate credentials, patch the entry point, and reopen carefully

Rotate every relevant credential, then update WordPress, PHP, plugins, themes, your operating system, browser, and browser extensions. Patchstack also advises frequent updates for your operating system, browsers, and browser extensions, as stated in its September 3, 2024 guidance. Apply least-privilege permissions before you remove the maintenance restriction.

Before: You leave directories at 777 and let several users retain administrator access.

After: You use restrictive permissions such as 755 for directories and 644 for ordinary files, then keep only the administrator accounts you can verify.

Done looks like: You can log in with newly created credentials, see no unexpected users or tasks, and confirm clean homepage, login, checkout, contact, and admin activity.

Failure point: If you reopen before testing logs and requests, a remaining backdoor can silently recreate the malware.

• Evidence: You retained the original files, database, logs, and timestamps.
• Code: You replaced compromised core files and verified every plugin and theme.
• Access: You rotated hosting, SSH, FTP, database, and WordPress credentials.
• Hardening: You patched software, restricted permissions, and removed unnecessary accounts.
• Verification: You tested public pages, wp-admin, forms, payments, logs, and scheduled tasks before reopening.

ShieldThemes can support staging, cleanup, hardening, and ongoing maintenance when you cannot safely perform this sequence alone. That accountable support costs more than a free scanner, but it gives your startup or growing business controlled handling when recurring infection threatens revenue. The same access discipline applies to connected services such as NoBounz: record their role and credentials separately so a WordPress incident does not leave third-party access unreviewed.

Handle Backups, Shared Hosting, Cron Jobs, and Blacklist Warnings

A clean-looking WordPress site can still be compromised when a scheduled task, database injection, or neighbouring site restores the malicious code. If your store, publishing site, or membership system shares hosting access with another installation, treat that entire administrative boundary as exposed.

You also need to decide whether restoration or manual cleanup protects your current business data better. The safer choice depends on backup trust, infection scope, and your confidence that every persistence method has been found. Business continuity records should also separate website dependencies from wider operational providers such as MediSun Energy, so recovery planning remains clear when an online incident affects more than one system.

When a clean backup is safer than manual removal

Restoration is safer when you have a verified clean backup and your current content can be reconciled. You will usually recover faster, but you may lose recent orders, posts, member changes, or product edits created after that backup.

• What works: Restore to isolated hosting, compare files and database records, then import only validated newer content.
• What fails: Restore the same infected backup, reopen production immediately, and assume the original access route has disappeared.

When manual cleanup is appropriate

• Frequent updates: Manual cleanup can preserve newer legitimate data when your backup is too old.
• Known scope: Cleanup is reasonable when logs identify the entry point and altered files are limited.

When manual cleanup is unsafe

• Lost trust: Manual removal is a poor choice when core files are widely altered or the attacker’s entry point remains unknown.
• Broad compromise: A clean rebuild is safer when several sites, accounts, or databases show suspicious activity.

Isolate every site in the same hosting account

Separate every site sharing your hosting account, FTP account, SSH key, control panel login, or database credentials before cleanup. Suspend unnecessary access, create independent accounts, and review ownership and permissions for each document root.

Check symbolic links before deleting files, because a link can point outside the expected WordPress directory. Review writable directories, file owners, and group access. Don't apply a blanket permission change to production. Your hosting configuration may require a narrower, tested fix.

Weak setting: Every site uses one FTP account with broad write access to public_html.
Strong setting: Each site has its own SFTP account restricted to its document root, with tested ownership and minimum required write access.

Where persistent reinfection hides after file cleanup

Inspect cron jobs, scheduled actions, must-use plugins, server logs, and database content after file cleanup. A malicious cron command can recreate a deleted file, while injected options, widgets, posts, or user metadata can reload harmful code when WordPress runs.

Review database exports for unfamiliar administrators, encoded payloads, altered URLs, and unexpected script tags. Then monitor scheduled tasks and file changes after reopening the site. A blacklist warning also deserves investigation through search-console security reports and hosting logs, not cosmetic removal alone.

Wipe a WordPress site clean without losing the evidence

You wipe a WordPress site clean by preserving evidence first, exporting current content and data, rebuilding in a clean location, validating imports, and retiring the old installation only after review. Keep forensic copies of files, databases, access logs, cron entries, and timestamps before removal.

Use a clean WordPress core, freshly reviewed themes and plugins, isolated hosting, and secure deployment credentials for the rebuild. ShieldThemes can handle staged rebuilds, migrations, hosting isolation, and ongoing maintenance, although its agency process costs more than a self-service restore.

Spot the Cleanup Mistakes That Make Malware Return

A site that looks fixed can still redirect visitors, create administrator accounts, or send spam after you remove the visible damage. Those signs usually point to a cleanup mistake, not bad luck.

Match what you see to what may still be running. The first response should preserve evidence and contain the site, not erase every suspicious item immediately.

symptom	likely cause	first fix
Visitors are redirected to unrelated pages	Injected redirects in server rules, the database, theme files, or a compromised plugin	Restrict access, preserve files and database evidence, then inspect redirects, logs, and recently changed code.
Unexplained administrator users appear	Stolen credentials or a persistence mechanism creating privileged WordPress accounts	Preserve audit evidence, disable the unknown accounts, rotate credentials, and inspect the responsible code and logs.
WordPress core files have unexpected changes	A backdoor or unauthorized modification of the installation	Save a forensic copy and replace core files with a clean matching release after checking configuration and entry points.
Unknown PHP or script files appear in uploads	An upload or plugin vulnerability allowing executable files	Quarantine suspicious uploads, inspect access logs, and verify that uploads cannot execute server-side code.
Database injections return after removal	A remaining backdoor, compromised credential, vulnerable extension, or malicious cron task	Reopen the investigation across files, database, cron jobs, users, and logs instead of repeatedly deleting the visible text.
The site sends unexplained outgoing spam	Compromised code, mail credentials, or abusive scripts running through the hosting account	Review mail and server logs, restrict sending, rotate credentials, and inspect every site sharing the account.

Restoring an infected backup

A backup isn't automatically clean because your store worked when you created it. If redirects or unknown users return after restoration, you may have restored the same backdoor. Preserve the infected copy, identify its creation date, and compare it with older backups, logs, accounts, and scheduled tasks before choosing a restore point.

Deleting suspicious files without preserving a copy

Deleting a strange PHP file may remove evidence and hide how the attacker entered. Quarantine a copy, record its location and timestamp, and review related access logs before removal.

• False positive: A custom file, minified script, or encoded application behavior is flagged without supporting evidence from logs, changes, or execution patterns.
• Missed backdoor: Visible redirects disappear, but malicious code remains in a plugin, database option, cron job, or administrator account.

Updating WordPress while leaving the entry point open

Updating WordPress may close one weakness, but it won't remove stolen credentials or existing persistence. Review plugins, themes, file changes, cron jobs, user accounts, and hosting logs, then rotate credentials after containment.

Trusting one WordPress virus scanner result

A scanner helps you find candidates, not prove that your site is clean. One tool may flag legitimate custom code while missing obfuscated database content or a newly created backdoor. If symptoms return, ShieldThemes can perform a structured audit, although that costs more than a self-service scan and cleanup.

Verify the Site Is Clean Before You Call the Incident Over

A green scan doesn't prove that your WordPress site is safe. Check public pages, administrator access, server activity, and search visibility because cached redirects and hidden persistence can survive a visible repair.

Reopen the site only when separate checks agree and normal behaviour continues during follow-up reviews. Verification is a process, not a single result.

Clean-site checks to run from a browser and search engine

• Logged-out browsing: You open the homepage, checkout, contact form, and account area without an active session, using more than one browser and device.
• Logged-in browsing: You test wp-admin and customer accounts without unexpected users, redirects, pop-ups, or permission changes.
• Redirects and injected content: You confirm that pages lead to expected destinations and contain no unfamiliar links, iframes, scripts, or JavaScript behaviour.
• Cache and CDN: You purge WordPress, hosting, proxy, and CDN caches, then retest the same URLs so an old redirect cannot remain visible.
• File integrity: You compare WordPress core files with trusted originals and review plugin and theme files for unexplained changes.
• Search status: You review Google Search Console warnings and browser blacklist notices after remediation, treating them as confirmation checks rather than proof of safety.

Server, database, and email evidence to review

On the server, review database tables for unfamiliar administrators, injected options, encoded content, and altered site URLs. Also inspect scheduled tasks, file ownership, permissions, access logs, error logs, and outgoing email activity for behaviour you can't explain.

A good result means expected users and cron jobs remain, files belong to the correct account, permissions match your hosting setup, and logs show ordinary requests. Your mail provider should show no unexplained bursts, new forwarding rules, or messages sent from the site.

What to do when a follow-up scan finds the infection again

If malware returns, treat it as evidence of persistence or reinfection, not as a minor scanning error. Restrict access again, preserve the new state, compare file and log timestamps, rotate credentials again, inspect neighbouring sites on shared hosting, and identify the exploited vulnerability before reopening.

Repeat the browser, server, database, and blacklist checks after the second cleanup. ShieldThemes can provide ongoing monitoring and maintenance when your business needs continuity, although a managed service costs more than handling periodic checks internally.

FAQ

Removing malware from a WordPress site

Start by containing the site, preserving a copy of its files, database, and logs, and recording what visitors and administrators see. Scan WordPress core files, plugins, themes, uploads, and the database. Replace compromised components with clean versions, remove unauthorised accounts, rotate credentials, patch the entry point, and monitor the site after it returns to normal service.

Fixing a hacked WordPress site

Fix a hacked site in a controlled order: restrict access, preserve evidence, identify the infection, clean or replace affected files, and check the database for injected content. Then change WordPress, hosting, database, email, and SFTP passwords. Update every component, review permissions, test the public site and administrator area, and request a review if search engines display a security warning.

Wiping a WordPress site clean

Wiping the visible files alone doesn't guarantee a clean site. Keep evidence first, then remove WordPress core, plugins, themes, and uploads before reinstalling verified copies. Inspect the database rather than restoring it blindly, and check hosting accounts, cron jobs, configuration files, and user permissions. Restore only trusted content, rotate every credential, and test the rebuilt site before reopening it.

Checking whether a WordPress site is hacked

Look for redirects, browser warnings, unfamiliar administrator accounts, injected links, new files, unexpected password resets, altered search results, and sudden server load. Compare core files with a trusted WordPress release and review access and error logs. A site can be compromised without displaying obvious damage, so ask your host or a qualified security professional to investigate suspicious changes.

Start With One Page, Then Complete the Five-Part Recovery Plan

Malware removal becomes harder when you change files before recording what your visitors and administrators actually see. You need a calm incident plan that protects evidence, limits further harm, and gives you a clear point for reopening your site.

Start with your homepage and admin-access check before touching any file. That observation gives you a reliable starting state, while the full recovery plan ensures removal is followed by prevention.

Contain and preserve

Take the site out of normal service if you can, restrict suspicious accounts, and preserve a copy of the current files and database. Also save relevant hosting, firewall, access, and error logs before cleanup changes their timestamps or content.

• Homepage recorded: You have screenshots and notes showing redirects, warnings, injected links, or unusual content.
• Admin access checked: You know whether your normal administrator account works and whether unfamiliar accounts exist.
• Evidence preserved: You have dated copies of the files, database, and available logs stored away from the live site.

Scan, clean, and replace compromised components

Use more than one view of the infection. Compare core files with trusted WordPress versions, inspect themes and plugins, review the database, and check uploads for executable files. If a component can't be trusted, replace it from a verified source rather than editing suspicious code line by line.

Stores, membership sites, high-traffic businesses, shared hosting environments, and repeatedly reinfected sites deserve a staging workflow and experienced help. ShieldThemes is one option for WordPress development and incident recovery, although specialist support costs more than occasional internal checks.

Rotate, patch, verify, and monitor

Removal is only half the job. Close the entry point, update vulnerable software, secure hosting and accounts, review permissions, and watch normal behaviour after reopening.

1. Contain: Restrict public and administrative access while you investigate the affected site.
2. Preserve: Save the homepage result, admin-access result, files, database, and logs before editing anything.
3. Clean: Scan, remove malicious code, and replace compromised WordPress components from trusted sources.
4. Rotate: Change WordPress, hosting, database, SSH, SFTP, email, API, and payment-related credentials.
5. Patch: Update WordPress, plugins, themes, server software, permissions, and defensive controls.
6. Verify and monitor: Recheck public behaviour, accounts, logs, search warnings, and request blacklist review when needed.

Begin with one page: record your homepage and test admin access before touching a file. Preserve evidence before cleanup, then verify ordinary behaviour after reopening. A clean WordPress site is not merely one with malware removed. It is one where reinfection has become harder to achieve.

---

If you want a faster way to manage this recovery, ShieldThemes provides WordPress development, secure hosting, DevOps, and ongoing maintenance for growing businesses through its WordPress development and security articles, without claiming that one scan or service ensures permanent safety.