You cleaned the site. The spam links disappeared, the security scan came back clear, and you changed your admin password. A few days later, the same spam is back, or a visitor tells you they were sent to a strange page again. If this has happened more than once, you are probably not facing a new attack each time. You are facing the same infection, which never fully left.
This guide is about that second problem: when your WordPress site keeps getting hacked after cleanup. It explains, in plain language, the three reasons an infection returns, the places a leftover hides, and the cleanup order that makes the fix stay fixed. If your site has just been hacked for the first time, start with our emergency recovery guide first, then come back here when the first cleanup is done and you want it to hold.
Is it really the same infection?
Before you clean again, it helps to know whether you are dealing with a leftover or a genuinely new break-in. The timing usually gives it away. Use this table as a first clue, not as proof, and then check the places listed below.
| What happens | What it usually points to |
| The same bad file, link, or redirect returns within hours of deleting it | Another copy is rebuilding it, often from the database or from a file that loads very early |
| The site stays clean until you change a password, then gets hacked again soon after | The attacker still has a way in, such as a hidden admin account or a password captured while you were logged in |
| The site stays clean for days, then the infection returns all at once | Another site on the same hosting account is still infected, or a scheduled task wakes up and restores it |
| Only one kind of spam returns, such as fake pages for one product type | The leftover belongs to that one hack family, and the rest of the cleanup may have worked |
One timing clue matters more than the rest. If you changed passwords during an earlier cleanup and the site was still infected at that moment, treat those new passwords as already known to the attacker. Some malware records the password typed at login, so a password set on an infected site is not a fresh start. That is why the cleanup order below puts the final password change near the end, not at the start. It does not contradict the emergency advice to lock accounts down in the first minutes of a fresh hack. Locking down first is containment. Rotating everything again after a complete cleanup is what makes the fix permanent.
The three reasons an infection returns
Almost every reinfection comes down to one of three causes, and a cleanup that sticks has to deal with all three. Miss one, and the other two fixes will not hold.
1. A hidden copy survived
Modern malware rarely lives in one file. It keeps spare copies in places a normal cleanup does not check, and one surviving copy can rebuild the rest. Delete the visible file and the hidden copy writes it back, sometimes within the hour, sometimes on the next scheduled task. This is the most common reason for the complaint that a deleted file keeps coming back.
2. The attacker still has a key
A key means any way back in that does not need a fresh break-in: a hidden administrator account, a password captured at login, a stolen hosting or file-transfer password, or a payment or service key stored on the site. As long as one key works, the attacker can return whenever they like, without finding a new weakness. This is also why changing only your own WordPress password is rarely enough.
3. The original door is still open
The door is whatever let the attacker in the first time: a plugin or theme with a known weakness that was never updated, an abandoned plugin that no longer receives fixes, a weak or reused password, or a neighbouring site on the same account. A perfect cleanup changes nothing if that door stays open, because the same weakness can be used again the next day.
When you investigate a reinfection, keep these three causes in mind and ask, for each one, whether you have actually closed it or only assumed you did. The sections below show where to look.
Where the leftover hides
Most cleanups check the obvious places: the files a scanner flags, the plugins page, and the user list in the dashboard. The leftovers below hide outside those views, which is exactly why they survive. You do not need to understand code to check them, but some checks need your hosting panel or your host’s help, and the steps say so where that is true.
Files that load before everything else
WordPress loads a few special files before ordinary plugins and themes. Two folders matter most. The must-use plugins folder, inside wp-content, loads every file in it on every visit, and those files cannot be switched off from the normal plugins screen. A small set of drop-in files in wp-content itself, used normally by caching plugins and custom database setups, also load very early. If you do not use the caching plugin or database setup that a drop-in belongs to, that file should not exist at all. Open these folders through your hosting file manager, not only through the dashboard, and ask whether you recognise every file there. A file with a scrambled-looking name, or a name that imitates a WordPress core file, deserves a closer look, and your host can confirm whether it belongs to their own tooling.
A copy stored in the database
The database can hold a copy of the malicious code, usually as a large option value full of encoded text. On each visit, an early-loading file checks whether its partner file is still on disk, and if it is missing, writes it back from the database copy. This is the mechanism behind the classic symptom of a file that returns after deletion. Check the database through your hosting panel’s database tool, and look for option names that no plugin of yours would use, or unusually large option values holding encoded code. Do not delete a database row just because it is large. Page builders and caching plugins store large values legitimately. Open the suspicious ones first, or ask your host or a developer to confirm them.
A hidden administrator account
Almost every serious infection creates its own administrator account, because it is the simplest way back in. Some infections then hide that account from the users screen in the dashboard, and even adjust the user counts at the top of the screen so the numbers still add up. A clean-looking users page is therefore not proof. Check the users table directly in the database tool, and compare it with the people who should really have admin access. Any account you do not recognise, especially one created around the date of the first hack, needs investigating before you delete it, because its creation date often points to when the attack started.
Passwords and keys captured at login
If malware was running while you logged in to clean the site, it may have recorded the password you typed, including a brand new one. The same applies to keys stored on the site: database passwords, file-transfer passwords, hosting panel passwords, and payment or service keys kept in the site’s settings or configuration file. Treat every password and key that existed while the site was infected as exposed, and plan to replace them all at the end of the cleanup, in one careful pass. Changing them earlier, while the malware still runs, hands the attacker the replacements.
Scheduled tasks that wake the infection up
WordPress has its own scheduler for timed jobs, and the server itself has one too. Malware can register a job in either place, so it wakes up on a timetable and restores itself or checks in with its operator. These jobs do not appear on any normal dashboard screen. List the scheduled tasks through a cron viewer plugin or your hosting panel’s cron section, and look for job names you do not recognise. A job named after no plugin you use, or a server cron entry that downloads a file from an unfamiliar address, should be removed, and your host can confirm whether a server-level entry belongs to them.
Another site on the same account, or a hiding place outside WordPress
If you host several WordPress sites under one hosting account, this is one of the most common reasons a cleanup appears to fail. You clean one site, while another site on the same account is still infected, and it writes the infection straight back. List every folder on the account that holds a WordPress installation, including staging copies, test sites in subfolders, and old sites you set up years ago and forgot. Every one of them is in scope, and every one needs the same treatment on the same day. If you cannot clean an old test site properly, delete it entirely.
There is one more layer worth knowing about. Some infections keep their active copy outside the WordPress folder altogether, in the hosting account’s home directory or in a server scheduled task, where no WordPress scanner ever looks. If you have cleaned the files, the database, and every install, and the infection still returns, ask your host to check outside the WordPress folder and at server level. That check belongs to the host, not to a dashboard plugin, and naming it in your support request saves several rounds of questions.
As a recent example of how far this can go, security researchers reported in late 2026 on a WordPress backdoor that kept copies of itself in files, the database, and server memory at the same time, so that each copy could rebuild the others. You do not need to understand that particular case to fix your own site. The lesson is the same: treat files, database, scheduled tasks, and every install on the account as one problem, not as separate cleanups.
The cleanup order that sticks
Order matters more than any single tool here. Work through these steps in sequence, and do not skip ahead to passwords. If any step is beyond what you are comfortable doing, stop at that step and hand the list to your host or a developer. A half-finished cleanup in the wrong order is how most reinfections happen.
Step 1: Take a snapshot, and label it infected
Before you change anything, take a full backup of files and database, even though it is infected. Label it clearly as infected, so nobody restores it by mistake later. It protects you if a cleanup step goes wrong, and it preserves evidence of how the attacker got in.
Step 2: List every WordPress install on the account
Open your hosting file manager and write down every folder that contains a WordPress installation. Include staging sites, subfolder installs, and old copies. This list defines the scope of the cleanup. A cleanup that covers one site out of several is a pause, not a fix.
Step 3: Check the database and the scheduled tasks first
Because the database can rebuild the files, check it before you clean the files. Look at the users table directly for admin accounts you do not recognise, look for unfamiliar large option values, and list the scheduled tasks for job names you do not recognise. Write down what you find, with dates, before you delete anything. If you are unsure about a database row or a scheduled job, ask your host to confirm it rather than deleting on a guess.
Step 4: Replace files from clean sources, do not repair them
Replacing files is faster and more reliable than editing infected files line by line. Reinstall WordPress core from a fresh copy of the same version, delete each plugin and theme and install a fresh copy from its official source, and go through the must-use plugins folder and the drop-in files by hand, keeping only what you can identify. Check the uploads folder for script files too. It should hold images and documents, not code, so any script file there deserves a close look. Only after the files are clean should you delete the hidden admin accounts, the malicious database entries, and the rogue scheduled jobs you found in step 3. Doing it in this order stops the infection from restoring one piece from another while you work.
Step 5: Clean every other install the same day
Repeat steps 3 and 4 on every install from your step 2 list, on the same day. If an old test site cannot be cleaned properly, delete it. Leaving one infected install on the account leaves the whole cleanup unfinished.
Step 6: Now rotate every secret
Only now, with the malware gone, change passwords and keys. Work through the full list: every WordPress administrator password, the WordPress salts in the configuration file (which log everyone out and invalidate stolen login sessions), the database password (updated in the configuration file at the same time), your hosting panel, file-transfer, and domain account passwords, and any payment or service keys stored on the site. If the site takes payments, tell your payment provider as well. Switch on two-factor authentication for every admin account while you are here. A stolen password is far less useful when it is not enough on its own.
Step 7: Close the entry point
Update everything that is out of date, and remove any plugin or theme that is abandoned, unused, or installed only just in case. Fewer plugins mean fewer doors. If you found the specific plugin that was exploited, check whether a fixed version exists before you reinstall it, and replace it if it does not. This step is what stops a genuinely new attack from walking through the same door next week.
Step 8: Watch closely for two weeks
Reinfection usually shows itself within days, so the first two weeks after a cleanup are when to watch. Repeat the database checks from step 3 a few times, check the must-use plugins folder again, and look at your security plugin’s log for new admin accounts, file changes, and failed logins. If the same kind of admin account or the same kind of database entry reappears, something was missed, and it is time to bring in help rather than clean a third time on your own.
Should you restore a backup instead of cleaning?
Restoring a backup from before the infection is often the fastest way back to a working site, but it is not a complete fix on its own. The backup holds the same weak plugin, theme, or password setup that let the attacker in, so the attack can succeed again within days, and any passwords or keys stolen since the backup are still valid. If you restore, do it as step 4 of the order above, not instead of it: restore, then update everything, check every other site on the account, and rotate all secrets. If you have no backup, or none old enough to trust, skip the restore and work through the cleanup order instead. For a fuller picture of what a professional cleanup usually covers, see our guide to what affects a malware removal quote.
When to get professional help
You can handle a lot of this yourself, especially with the steps above. It is time to call in a professional if any of these are true: the site has been reinfected twice or more after your own cleanups; the site takes payments or stores customer data, so leaked keys and records bring obligations beyond the website itself; you host several sites on one account and cannot clean them all at the same time; or you find signs of malware you do not understand, such as scrambled code, unknown database entries, or admin accounts you cannot delete. A good cleanup service does more than delete files. It finds how the attacker got in, checks the database and every install on the account, and tells you which secrets to rotate. Our WordPress security services and maintenance plans cover that kind of work, and our maintenance checklist turns the watch routine above into a regular habit.
Frequently asked questions
Why does my WordPress site keep getting hacked after I clean it?
Because part of the infection survived. The most common reasons are a copy of the malware stored in the database that restores the file, a hidden admin account, passwords captured while you were logged in, another infected site on the same hosting account, or the original weakness still being open. Clean the database and every install before you change passwords, then close the entry point.
Why should I change passwords last, when the emergency guide says to lock accounts down first?
Both are right, for different moments. In the first minutes of a fresh hack, locking accounts down limits further damage. In a reinfection cleanup, changing passwords while malware still runs can hand the attacker the new passwords, because some malware records what you type at login. So lock down first in an emergency, then, once the full cleanup is done, rotate everything again. Treat any password set while the site was infected as exposed.
Is a clean security scan enough to know the site is safe?
No. Scanners match known patterns, and malware that changes its file names and code between copies can be missed, especially by a new variant. Treat a clean scan as one signal, and back it up with the manual database and file checks in this guide. A scan that finds nothing does not prove that no hidden copy remains.
Can I just restore a backup and skip the rest?
Restoring helps only if the backup predates the infection, and even then it is not a complete fix. The weakness that let the attacker in is still in that backup, and stolen passwords and keys are still valid. Restore, then update everything, check every other site on the account, and rotate all secrets.
Does updating all my plugins stop reinfection?
Updating closes the door that a known weakness leaves open, which is essential, but it does not remove a hidden copy, a hidden admin account, or stolen keys that are already in place. Updates belong in step 7 of the cleanup order, after the infection itself is fully removed. On their own, they will not stop a leftover from rebuilding itself.
What if the same infection returns even after I follow this order?
Then something outside the usual scope is still in place, most often a hiding place outside the WordPress folder, a server-level scheduled task, or an install on the account you missed. Ask your host to check outside the WordPress folder and at server level, and bring in professional help rather than repeating the same cleanup. Each repeat without new information costs time and leaves visitors exposed in between.
Conclusion
A WordPress site that keeps getting hacked is rarely a run of bad luck. It is an infection doing what it was built to do: keep a spare copy, keep a way in, and hide from the places most cleanups look. Stop cleaning only the symptom, and clean the whole system in the right order instead. Check the database and every install first, replace files from clean sources, then rotate every secret and close the door that let the attacker in. Do that once, properly, and the cycle of cleaning the same hack again should stop.
If you would rather have an experienced team handle the cleanup and the watch routine, Raozan IT can help. We are a WordPress and digital marketing team based in Noapara, Raozan, Chattogram, founded in 2017, with 800+ projects completed. Talk to us on WhatsApp at +8801735127127, through our contact page, or by email at [email protected]. You can also explore our services to see what else we look after.
