Signs Your WordPress Site Is Hacked
Before you can fix a hacked WordPress site, you need to be sure it is actually hacked and not just misbehaving. A lot of what looks like a hack turns out to be a broken plugin, a bad update, or a caching problem. But a real compromise leaves fingerprints, and once you know what to look for they are hard to miss.
The most obvious sign is when your own browser or Google warns visitors that the site is dangerous. A red interstitial screen that says the site ahead contains malware is not something you can ignore, and it usually means Google's crawler found something bad on one of your pages. That warning alone can cut your traffic to almost nothing within hours.
Other signs are quieter. You might notice your homepage redirecting to a website you have never seen, often a spam page selling counterfeit goods or pills. You might find new admin users you did not create, strange files in your directories, or pages in Google's index with titles in a language you do not speak. Sometimes the only clue is a message from your host saying they suspended the account for sending spam.
Symptoms and what usually causes them
It helps to map a symptom to a likely cause, because that shortens the hunt later. The table below is a rough guide, not a diagnosis. A site can show one symptom for several reasons, so treat it as a starting point.
| What you see | What it often means |
|---|---|
| Visitors from Google land on spam, but you do not when you type the address | Conditional redirect that only fires for search traffic or specific devices |
| New pages in Google with pharma or gambling keywords | Injected spam pages, often called a pharma hack or Japanese keyword hack |
| Admin users you did not create | An attacker has full access and made a way back in |
| Site loads fine but antivirus flags it | Malicious script served to visitors, sometimes only on certain pages |
| White screen or garbled code at the top of pages | Broken injected PHP, often in the theme or a core file |
| Host disabled the account | The server is sending spam email or attacking other sites |
Confirm it is a hack, not a glitch
Before you commit to a full cleanup, rule out the ordinary problems that mimic a hack. A plugin conflict can white screen your site. A caching layer can serve an old page long after you changed it. A misconfigured redirect in a plugin can send visitors somewhere odd without any malware involved. Clear your cache, disable a suspect plugin, and check whether the problem follows a specific page or a specific type of visitor. If the strange behaviour only shows up for people arriving from search, or only on mobile, that pattern points more toward a compromise than a simple bug.
One quick test is to view your site the way an outsider does. Open it in a private browser window, and search for your brand name plus a few odd keywords to see what Google has indexed. If your listing shows pages you never made, or a description full of unrelated terms, that is a strong sign of injected spam content rather than a temporary error.
If you have confirmed one or more of these, take a breath. A hacked site feels like an emergency, and in some ways it is, but rushing tends to make things worse. The rest of this guide walks through a calm, ordered cleanup that gets the site back without leaving the attacker a way in.
Do Not Panic, and Do Not Delete Everything
The first instinct many people have is to wipe the whole site and start fresh. Resist that urge. If you delete everything before you understand how the attacker got in, you lose the evidence that tells you which door to lock. You may also destroy the only recent copy of content you have not backed up.
The second common mistake is to change nothing and hope it clears up on its own. It will not. Malware on a WordPress site is designed to spread and to reinstall itself. Left alone, it usually gets worse, and it can drag your host account and your email reputation down with it.
The right path sits between those two. Move deliberately, keep a copy of everything before you change it, and work in a set order so you do not chase your own tail. Here is the shape of the job before we get into detail.
Keep this sequence in mind as we go. Contain the problem, save a copy for evidence, find the malicious code, clean it out of both files and the database, then reset every credential and harden the site so it does not happen again. If you would rather hand the whole thing to someone who does this every week, our WordPress services include malware cleanup and monitoring, and you can request a free quote to get started.
Contain the Damage First
The moment you know the site is compromised, your goal is to stop it hurting visitors and stop it spreading. You do this before any cleaning, because a live infected site keeps serving malware and keeps damaging your search reputation with every crawl.
Put the site into maintenance mode
Take the public site offline in a controlled way. A maintenance mode page tells visitors and search engines that the site is temporarily down for work, which is far better than leaving an infected site up or throwing raw errors. Many hosts and plugins offer a one click maintenance mode. If you have server access, you can restrict the site to your own IP address so you can keep working while the public sees a holding page.
Tell your host
Contact your hosting provider early. Good hosts deal with compromised sites all the time, and they can tell you useful things you cannot see from inside WordPress, like whether other sites on the same account are also infected, whether the server is sending spam, and when the bad files first appeared in their logs. On shared hosting, a neighbour's compromised site can reinfect yours, so the host may need to look wider than your account.
Take the site down if it is attacking others
If your host says the server is sending spam or attacking other sites, the fastest safe move is often to disable the site entirely until it is clean. It feels drastic, but a site that is actively harming others can get your domain and your sending IP address onto blocklists that are slow and painful to get off. Contain first, clean second.
Work on a copy where you can
If your host offers staging, clone the site to a staging environment and do your investigation there. That way you can poke around, test theories, and even break things without any risk to what visitors see. When the staging copy is clean and stable, you push it live in one controlled move. It is not always practical during an active attack, but when it is available it takes a lot of the pressure out of the job, because a mistake on staging costs you nothing.
Back Up the Site Even Though It Is Hacked
This step surprises people. Why back up a site that is full of malware? Because that copy is your evidence and your insurance. If your cleanup goes sideways and you accidentally break the site, you can put it back to the state you started from and try again. And the infected files themselves tell the story of how the attacker got in.
Make a full copy of two things: every file in your WordPress installation, and a complete export of your database. Store that copy somewhere clearly labelled as infected so nobody restores it by mistake. Do not overwrite your good, older backups with this one. The whole point of a clean backup is that it predates the hack, so keep your history intact.
- Download the files. Use your host's file manager, SFTP, or a backup plugin to grab the entire directory, including hidden files.
- Export the database. A tool like phpMyAdmin or a database export from your host gives you a full snapshot of posts, users, and settings.
- Label it as infected. Put the date and the word infected in the folder name so there is no confusion later.
If you already keep tested, offsite backups from before the hack, you are in a much stronger position, because you may be able to restore rather than clean by hand. We cover that path below, and our guide on how to back up a WordPress website explains how to set up backups so you are never caught without one again.
Scan and Find the Malware
Now the detective work begins. You cannot clean what you cannot find, so before you touch a single file you want to know where the malicious code lives. Attackers hide it in predictable places, and a good scan surfaces most of it.
Run a security scanner
Start with a reputable WordPress security plugin that includes a malware scanner. A server side scan is stronger than a browser based one because it can read every file, not just the pages a visitor can reach. The scanner compares your core files against the known good versions published on WordPress.org, flags files that do not belong, and highlights code patterns that are common in malware.
Do not rely on a single scanner. Different tools catch different things. Run at least two, and pay attention to anything they both flag. A remote scanner that visits your site like a search engine is also useful, because it can catch redirects and injected scripts that only appear to outside visitors.
Know where malware hides
Most infections live in a small number of places. Learning these speeds up every future cleanup.
| Location | What attackers put there |
|---|---|
| Core files in the root and admin folders | Modified versions of legitimate files with extra code bolted on |
| The uploads folder | PHP files disguised among images, which should never contain code |
| Theme files, especially the functions file | Injected functions that run on every page load |
| Plugin folders, including fake plugins | Whole directories that look like plugins but only serve malware |
| The configuration file and root of the site | Backdoors and code that reinstalls the infection |
| The database | Injected scripts in posts, options, and user records |
Write down every file and location the scanners flag. That list is your worklist for the next few sections. The more careful you are here, the less likely you are to miss a backdoor and get reinfected a week later.
Clean Core, Plugins, and Themes
With your worklist in hand, the cleanest approach is usually to replace rather than repair. Instead of trying to surgically remove injected code from a file, you swap the whole file for a known good original. This is faster and far safer, because you can never be completely sure you found every hidden line in a file an attacker touched.
Replace WordPress core
Download a fresh copy of WordPress from the official source and replace the core files. The main folders that hold WordPress code, along with the loose files in your root, can all be replaced with clean originals of the same version. The only things you keep are your configuration file, which you will clean separately, and your uploads folder, which the core download does not include. Reinstalling core through the dashboard or by hand overwrites any injected core files in one move.
Reinstall plugins and themes from scratch
Do not trust the plugin and theme files that are on the hacked site. Make a note of which plugins and themes you use and which versions, then delete the plugin and theme folders entirely and reinstall fresh copies from the official directory or from the developer you bought them from. A clean reinstall guarantees you are running the real code and not a version with a backdoor tucked inside.
- List what you need first. Note active plugins and your theme before deleting anything, so you can rebuild the same setup.
- Delete, do not just deactivate. Inactive plugin files can still be executed directly by an attacker, so remove the folders.
- Drop anything you do not use. A hacked site is a good moment to get rid of plugins and themes you no longer need. Fewer components means fewer things to keep patched.
- Never reinstall pirated plugins or themes. Cracked premium software is one of the most common ways sites get infected in the first place. Buy the real thing or use a free alternative.
After replacing core, plugins, and themes, run your scanners again. A lot of infections vanish at this point, because most of the malicious code was riding inside files you have now overwritten. What remains is usually in the uploads folder, the configuration file, and the database, which we handle next.
Clean Uploads and the Configuration File
The uploads folder is where your media lives, and it is a favourite hiding spot because it is writable and rarely inspected. The important rule is simple: your uploads folder should contain media, not code. Any file that ends in a code extension inside uploads is suspicious and almost always malicious.
Go through the uploads directory and look for files that do not belong. Scanners flag most of them, but a manual look for code files mixed in with your images is worth the time. Remove anything that is executable code. Genuine media never needs to run code, so you can delete those files without losing real content.
Check the configuration file carefully
Your main configuration file holds your database details and security keys, and attackers love to append code to the bottom of it or hide includes near the top. Open it and read it line by line. It should contain settings and defined constants, and nothing that looks like obfuscated code, long strings of random characters, or functions that decode and run text. If you see anything like that, remove it. Compare against a fresh sample configuration file from the official download if you are unsure what belongs.
While you are in there, do not change the secret keys yet if you plan to, because we handle credential resets in a dedicated step. Just clean out anything that does not belong. The goal right now is to make sure no file on disk still carries a hidden way back in.
Clean the Database
File cleaning gets most infections, but the stubborn ones live in the database. This is where redirect scripts, spam content, and injected admin users often sit, and it is the reason some people clean their files, breathe a sigh of relief, and then watch the hack come straight back.
Search the database for injected code
Using a database tool like phpMyAdmin, look through the tables that store content and settings. Injected code usually appears as script tags, iframes, or blocks of encoded text inside posts, page content, and the options table. Search for the telltale patterns your scanner reported. When you find injected code inside a legitimate record, remove only the malicious part and keep the real content.
Be careful and methodical. The database holds your actual site content, so you cannot simply delete tables. Work on a copy, keep your infected export handy in case you need to compare, and change one thing at a time so you can tell what fixed the problem.
Watch for spam content and hidden pages
Some hacks add hundreds of spam pages or posts, often set to hidden or scheduled so you do not notice them in the normal editor. Sort your content by date and by author, and look for a flood of entries you did not write, especially ones full of unrelated keywords. Delete those, but confirm they are junk before you do, so you do not throw away a legitimate draft.
Do not forget the options and user tables
Two tables deserve special attention. The options table holds settings that run on every page, so a single injected value there can inject a script site wide. Check the values that control your site address and home address, because a hack sometimes points these at a domain you do not own, which breaks the site or hijacks traffic. The user table is the other one to comb through, since some attacks add an account directly in the database so it slips past the normal user screen. If you find a user there you did not create, remove it and note it as further proof the attacker had deep access.
Database cleanup is fiddly, and it is the step where a single missed line can undo all your work. If you are not comfortable editing the database by hand, this is a good moment to bring in help. Our team does this carefully and keeps your content intact, and you can get in touch if you would like us to take it from here.
Remove Backdoors and Rogue Accounts
A backdoor is code an attacker leaves behind so they can get back in even after you clean the obvious infection. Backdoors are the single biggest reason a hack returns. You can spend hours cleaning files and the database, declare victory, and get reinfected overnight because one small backdoor survived. Hunting them down is not optional.
What backdoors look like
Backdoors are usually small and disguised to look harmless. They often use functions that take input from a web request and run it, or that decode a hidden string and execute it. They hide in the uploads folder, in fake plugin directories, at the bottom of legitimate files, and in files with innocent sounding names. Your scanner flags many of them, but the sneaky ones need a manual eye.
- Look for files that do not match their neighbours. A single odd file in a folder of images or a plugin folder with one extra file is worth opening.
- Check recently modified files. Sort by modification date and review anything that changed around the time of the hack.
- Read the code, not just the file name. Attackers pick names that blend in, so the content matters more than the label.
Remove rogue admin users
Open your list of users and check for accounts you do not recognise, especially administrators. Attackers often create a hidden admin account as a backdoor of their own. Remove any account that should not be there. Be thorough, because some hacks create users that do not show in the normal list, which is another reason a database check matters. After you have cleaned the users, you will reset the passwords of the ones that remain in the next step.
Only when you are confident there are no backdoors left should you move on. This is the difference between a site that stays clean and one that gets reinfected. If the idea of hunting backdoors by hand feels beyond your comfort level, that is completely normal, and it is exactly the kind of thing a WordPress maintenance service handles as routine.
Reset Every Password, Salt, and Key
Assume the attacker saw every credential your site uses. Once you know the files and database are clean, you change all of them, because a clean site with a stolen password is still an open door.
- Reset all WordPress user passwords. Force a reset for every account, and make each new password long and unique. Two factor authentication on admin accounts is worth adding now.
- Change the database password. Update it at the host, then update your configuration file to match so the site can still connect.
- Rotate the secret keys and salts. These values in your configuration file protect login sessions. Replacing them logs out everyone, including any attacker with a stolen session. The official secret key generator on developer.wordpress.org and the WordPress project provides fresh values you can paste in.
- Change hosting and FTP passwords. The attacker may have reached your site through the server, not WordPress, so reset your host login, your SFTP or FTP accounts, and any control panel password.
- Update any API keys the site used. If your site connects to payment, email, or other services, rotate those keys in case they were exposed.
Changing salts and keys is one of the most satisfying steps, because it instantly kicks out anyone still logged in with a stolen session. Do it after the files and database are clean, not before, or the attacker simply logs back in and you have to do it again.
The Faster Path: Restore From a Clean Backup
Everything above describes cleaning a site by hand. There is often a faster route, and it is the best argument for keeping good backups in the first place. If you have a tested backup from before the hack, you can restore it and skip most of the manual cleaning.
When restoring makes sense
Restoring works well when you know roughly when the hack happened and you have a clean backup from before that point. You wipe the compromised files and database, put the clean backup in their place, and you are back to a known good state in a fraction of the time a manual clean takes. It is cleaner, too, because you are not trusting that you found every last piece of injected code.
The catch with restoring
There are two things to watch. First, if you do not know when the hack happened, you might restore a backup that is already infected, so you still need to scan the restored site to be sure. Second, restoring rolls back any content you added after the backup, so you may lose recent posts, orders, or comments. Weigh that against the time a manual clean would take.
| Consideration | Manual cleanup | Restore from backup |
|---|---|---|
| Time to complete | Longer, several hours or more | Shorter if a clean backup exists |
| Risk of missing malware | Higher, code can hide | Lower, if the backup predates the hack |
| Recent content | Kept | Lost back to the backup date |
| Needs a good backup | No | Yes |
Whichever path you take, you still reset every password and harden the site afterward, because a restore fixes the files but does nothing about a leaked password or the weakness that let the attacker in. A backup is a recovery tool, not a security fix.
Get Off Google's Blacklist and Warnings
Once your site is genuinely clean, you have one more job: convincing Google and the browsers that it is safe again. If your site was flagged, that warning does not disappear on its own just because you fixed the problem. You have to ask for a review.
Confirm the site is clean before you ask
Do not request a review until you are confident the malware is gone. If Google rechecks and still finds a problem, you go back to the end of the queue, and repeated failures make future reviews slower. Run your scanners one more time, check a few pages as a search engine would see them, and make sure no redirects fire for search visitors.
Request a review through Search Console
Use Google Search Console to see the specific security issues Google detected and to request a review once you have fixed them. The Security Issues report lists sample URLs where the problem was found, which is a helpful double check that you cleaned everything. After you submit, a review can take some time, so be patient and do not resubmit repeatedly.
If your host or a blocklist service flagged you separately, you may need to request removal from those as well. Your host can usually tell you which blocklists your domain or sending IP landed on and how to request removal from each.
Prevent It From Happening Again
Cleaning the site is only half the job. If you do not fix the weakness that let the attacker in, you will be back here soon. Reinfection is common precisely because people clean up and then change nothing about how the site is run. This section is where a hacked site becomes a more secure one.
Close the door the attacker used
Think back to what your scan and your host's logs suggested about the entry point. The usual suspects are an outdated plugin or theme with a known vulnerability, a weak or reused password, pirated software with a backdoor built in, or a poorly secured host. Whatever it was, address it directly rather than hoping it does not come up again.
Build the habits that keep a site clean
- Update everything, promptly. Keep core, plugins, and themes current, and remove anything you do not use. Most hacks exploit a hole that had a patch available.
- Use strong, unique logins. Long passphrases, no shared accounts, and two factor authentication on admin users.
- Install a firewall and a scanner. A web application firewall blocks many attacks before they reach WordPress, and regular scans catch anything that slips through.
- Keep tested, offsite backups. So that next time, if there is a next time, you can restore in minutes instead of cleaning for hours.
- Limit who has access. Give each person only the role they need, and remove accounts when people leave.
Set up monitoring so the next one is caught early
The difference between a minor incident and a full crisis is often how fast you notice. A site with monitoring in place flags a changed core file, a new admin user, or an unexpected outbound connection within minutes, which gives you a chance to act before the infection spreads or before Google flags you. Without monitoring, the first sign is usually a customer emailing to say the site looks broken, by which point the damage is already done. File change detection, a login alert, and a scheduled scan together form a quiet early warning system that pays for itself the first time it saves you.
It also helps to keep a short record of what you found and fixed this time. Note the entry point, the files that were infected, and the steps you took. If the site is ever compromised again, that record turns a frantic investigation into a quick comparison, and it helps whoever works on the site next understand its history.
None of these are exotic. They are the ordinary discipline of running a website well, and together they turn your site from an easy target into a hard one. Our full walkthrough on how to secure a WordPress website goes deeper on each of these layers if you want a checklist to work through.
When to Call in a Professional
You can do everything in this guide yourself if you are comfortable with files, databases, and a bit of code. But there are times when bringing in a professional is the smart call, and there is no shame in it. A cleanup done right the first time is cheaper in time and stress than three failed attempts.
Signs you should get help
- The hack keeps coming back after you clean it, which points to a backdoor you have not found.
- The site handles sensitive data like customer records or payments, where a mistake carries real consequences.
- You are not comfortable editing the database or reading code, which are the steps where errors do the most damage.
- The site is critical to your business and every hour of downtime costs you customers and trust.
- You simply do not have the time to do it carefully, and rushing a cleanup is how backdoors survive.
A professional cleanup does more than remove the malware. It finds the entry point, closes it, hardens the site, and often sets up monitoring so you get a warning at the first sign of trouble rather than a phone call from an angry customer. That last part matters, because the goal is not just a clean site today but a site that stays clean.
How we can help
Our team cleans hacked WordPress sites, finds and closes the entry point, and puts monitoring in place so it does not happen again. We keep your content intact, we tell you plainly how the attacker got in, and we set the site up so you are far less likely to see us for the same reason twice. If you are staring at a compromised site right now, you do not have to sort it out alone. Take a look at our WordPress services, or request a free quote and we will get your site clean and keep it that way.
A hacked WordPress site is a bad day, not a disaster. Work through it in order: contain the damage, save a copy, find and remove the malware from both files and the database, hunt down every backdoor, reset all your credentials, and then harden the site so the same thing cannot happen twice. Do that, and you come out the other side with a site that is not just recovered but genuinely more secure than it was before.