How to tell a WordPress site is hacked
Look for a user you did not create, a plugin you did not install, or a redirect that appears for visitors but not for you while logged in. A slow page alone proves nothing; a new administrator account or a Google security warning is stronger evidence.
- A new administrator account, or your own role changed without your action.
- Files in wp-content with names or timestamps you cannot explain.
- The site redirects from search or on mobile but loads normally when you are signed in.
- Search Console reports new spam URLs, or Google shows a "site may be hacked" notice.
- The host sends an abuse or malware email about your account.
Record the misbehaving URL, the time it started and a screenshot before you delete anything. That record is what a host scan and a cleanup ticket need to work from.
Contain the hack before you delete a single file
Close the way in before you clean: put the site behind maintenance mode or a password, and sign out every session so a stolen cookie stops working. The infected file is evidence of how the attacker entered, and deleting it early hides that trail.
- Enable maintenance mode, or protect the whole site with a password in .htaccess.
- In Users → Profile, click Log Out Everywhere so old sessions expire.
- Ask the host whether outbound mail is paused; a hacked site often sends spam.
- Take the backup in the next section before you remove any file or user.
Back up the hacked site before you change anything
Download the full file tree and export the database, then store both off the server. A backup taken after the infection still helps: it shows which files changed and lets you compare your install against a clean copy of the same version.
A backup from before the hack is better, but only if you can date it. Compare its timestamp with the first infected file; if the backup predates that file, restore it and skip most of the cleanup below.
How to remove malware from WordPress files and database
Replace core files from a fresh download of the same version, delete plugins and themes you do not recognise, and search the database for injected script. Leave wp-content and wp-config.php in place until the copy is safe.
- Replace the wp-admin and wp-includes folders with the same WordPress version. Keep wp-content.
- Compare wp-content/plugins with your install list. Delete folders you cannot account for, then reinstall what you keep from the WordPress.org repository.
- Open .htaccess and remove redirect or include lines you did not write. Back the file up first.
- Search wp_posts and wp_options in phpMyAdmin for script tags or base64 blocks you did not add, and remove only the injected rows.
- Check wp-content/uploads and mu-plugins for PHP files; uploads should not contain executable code.
When a scanner names a file you do not recognise, read it before deleting it, and keep a copy for the host. Ongoing cleanup and monitoring sit with WebJi® WordPress security if you would rather not do this alone.
Change every credential the site used
Change the WordPress admin password, the database password and its entry in wp-config.php, the hosting and SFTP passwords, and the salts in wp-config.php. New salts invalidate every existing login cookie, including the attacker's.
Rotate the API keys stored in plugins, such as payment gateway, SMTP and analytics keys, because those config files were readable. Re-check the user list a week later: a second admin account is the most common way a cleaned site is re-entered.
When to rebuild instead of cleaning
Rebuild when the infection returns within a day, when the host flags files you cannot identify, or when injected rows in the database outnumber the ones you can check. Restore a clean backup, update everything, then reinstall plugins from the repository.
Deleting the site and starting over is the last option, not the first: without a backup it destroys content, orders and customer records that no cleanup needed to touch.
Harden WordPress so it does not happen again
Update core, themes and plugins, delete what you do not use, turn on two-factor for every administrator, and set DISALLOW_FILE_EDIT to true in wp-config.php. Keep a weekly backup stored off the server.
Watch the log for PHP files that appear without an update: the WordPress error log guide shows where those entries sit. On WebJi® WordPress hosting the file manager and daily backups make both the clean copy and the restore straightforward.
Frequently Asked Questions
How do I fix a hacked WordPress site?
Back up, change the admin, hosting and database passwords, delete unknown users, replace wp-admin and wp-includes from a clean copy of the same version, and remove plugins you do not recognise.
Can a hacked WordPress site be recovered?
Yes when you still have the files and the database, or a backup from before the change. If the account is re-infected at once, the host has to scan outside WordPress.
Is my WordPress site hacked?
Check Users for an admin you did not make, and compare the public URL in a private window with what you see while logged in. A redirect that only strangers see is a common sign.
Should I reinstall WordPress after a hack?
Replace core files. Do not delete wp-content until you have a copy, or you will lose uploads and the theme you actually use.
Should I delete the hacked files before taking a backup?
No. Take the backup first, because the infected file shows how the attacker got in and a clean restore needs a reference point. Delete the evidence only after the copy is off the server.
How do I stop a WordPress site being hacked again?
Update core, themes and plugins, remove unused ones, turn on two-factor for administrators, set DISALLOW_FILE_EDIT to true, and keep off-server backups. Recheck the user list for a week after cleanup.