When a WordPress site is compromised, the order of operations decides whether you fix it once or three times. Contain first, preserve the compromised state before touching it, restore from a known good backup in preference to cleaning in place, rotate every credential, close the entry point, and only then ask Google to lift any warnings. WPBuildAI gets called most often after the second incident, because a static rebuild removes the mechanism rather than reducing the odds: there is no admin login to brute force, no plugins to exploit, and no code executing on the server when a page is requested. Here is the full sequence, including the two steps almost everyone skips.
Why does the first hour matter so much?
Because three separate clocks start the moment a compromise goes live, and each one gets more expensive the longer it runs.
The first is visitor exposure. An injected site serves whatever was planted to everyone who arrives, and if that includes a malicious redirect or a fake login form, your customers are the ones absorbing it. That is a duty of care question before it is a technical one.
The second is search detection. Once a crawler sees the injected content, the site can be flagged, and a flag takes days to clear even after the site is clean. Ten minutes of containment can be the difference between a private incident and a public one.
The third is evidence decay. Logs rotate, caches expire, and automated processes overwrite the timestamps you will want when you try to work out how they got in. The state of the site right now is the most complete record you will ever have of the incident.
None of that requires knowing what happened yet. It requires taking the site out of public reach and copying it, both of which take minutes.
Is it actually a compromise?
Check for specific signals rather than reacting to a symptom, because a blank page after an update and a sudden ranking drop both have ordinary causes, and treating either as a breach wastes a day you may need later.
Three categories of evidence are worth separating. Access evidence is the strongest: accounts you did not create, logins from places you have never worked from, or a password that stopped working. Content evidence is next: pages, links, or redirects that exist without anyone in the business adding them. File evidence is the most technical and the most conclusive: modification timestamps in directories nobody has touched in years.
A single weak signal on its own usually means something ordinary happened. Two categories together almost always means a compromise, and at that point the clock is running, because every hour the site stays up is another hour of visitors being served whatever was injected.
| What you noticed | Points to a compromise when | Points elsewhere when | How to check in five minutes |
|---|---|---|---|
| Traffic collapsed | Search Console shows a security issue | It coincides with a known ranking update | Open the Security Issues report |
| Strange pages exist | They are in languages you never publish in | They are old drafts or test pages | Sort all pages by date created |
| The site redirects | It only happens from a search result | It happens for everyone, including you | Click your own listing in Google |
| New admin accounts | You did not create them and cannot place them | A developer added one recently | Users screen, sorted by registration date |
| Files changed | Modification dates in folders you never touch | They match a recent update you ran | File manager, sorted by modified date |
Check from a logged out browser and from an actual search result, because a large share of injections deliberately hide from logged in administrators and from direct visits. The official WordPress guidance on hacked sites is the right first reference, and it makes the same point about verifying before acting.
What is the right order to recover in?
Contain, preserve, restore, rotate, close, clear. Each step depends on the one before it, and steps taken out of order are the reason sites get compromised twice.
| Step | What you do | Why the order matters | Common mistake | Verdict |
|---|---|---|---|---|
| Contain | Maintenance mode, tell your host | Stops further damage and stops visitors being served malware | Leaving it up while investigating | Do this in the first ten minutes |
| Preserve | Copy files and database untouched | The compromised state is the only evidence of the entry point | Deleting the bad file immediately | Never skip, it costs five minutes |
| Restore or clean | Roll back to a known good backup | A restore gives a known state, cleaning gives a hopeful one | Cleaning only what you can see | Restore beats clean when possible |
| Rotate | Every password and key, everywhere | You do not know which credential leaked | Changing only the WordPress password | No exceptions |
| Close the door | Patch or remove the vulnerable component | Without this, reinfection follows within days | Assuming cleanup was the fix | The step that decides repeat incidents |
| Clear warnings | Request review in Search Console | Restores traffic and removes interstitials | Requesting review too early | Only once the site is genuinely clean |
Why should you copy the site before you clean it?
Because the compromised state is the only record of how they got in, and cleaning destroys it.
Copy the whole thing first: the file tree and a database dump, exactly as they are. That copy contains the timestamps, the modified files, the injected rows, and the access logs that together identify the entry point. Once you clean, that information is gone, and you are guessing.
Skipping this step is the single most common pattern in repeat compromises. The visible damage gets removed, the site looks fine, and the backdoor dropped somewhere unremarkable remains. Two weeks later the same injection reappears, and the owner concludes they are being targeted when what actually happened is that the door was never closed.
Store the copy outside the web root and outside the site’s own backups.
Should you restore or clean?
Restore whenever you have a backup predating the compromise, because a restore gives you a known state and cleaning gives you only the state you managed to find.
Establishing the timing is usually possible from file modification dates in your preserved copy and from your host’s access logs. Restore the most recent backup that predates it. Anything published between that backup and now has to be re added by hand, which is annoying and far better than an incomplete cleanup.
If no clean backup exists, cleaning means replacing rather than editing: delete WordPress core and reinstall from a fresh download, delete each plugin and theme and reinstall from source, then compare what remains against a clean install so anything unexplained gets examined. Injected content in the database, spam posts, modified options, and rogue users have to be found separately. This is slow, and it is why maintaining verified backups is worth more than any security plugin.
What needs rotating, and why is the admin password not enough?
Everything that touched the server, because credential reuse is the most common route back in after a successful cleanup.
That means WordPress administrator accounts, the hosting control panel, FTP and SFTP, SSH keys, the database user, any API keys stored in configuration files, and any third party service credentials the site held. Delete unrecognized administrator accounts rather than changing their passwords. Reissue keys rather than reusing them.
A cleaned site with a rotated admin password and an unchanged FTP account is a site that will be recompromised, and the owner will believe the cleanup failed when what failed was the rotation.
How do you find the entry point?
Use the preserved copy, and cross reference the earliest modified files against your plugin list and versions.
The entry point is almost always one of a small set: an outdated plugin or theme with a published vulnerability, a weak or reused administrator password, a compromised hosting account, or another site on shared hosting with access to the same space.
If a plugin was months out of date and has a disclosed vulnerability from around that time, you have your answer. If credentials were weak or shared, you have a different one. The vulnerability classes involved are the ordinary ones catalogued in the OWASP Top Ten, and the WordPress specific pattern is well documented: core is maintained carefully and most real incidents arrive through extensions.
Then remove or update the component, and remove anything you do not use, which is the audit in how to audit your WordPress plugins before a rebuild. The drift that leads here is described in what happens if you stop updating WordPress.
Two limits are worth stating plainly, because owners often believe one of these is doing more than it is. A security plugin blocks common attack patterns and alerts you to changed files, and it cannot patch a vulnerable component or protect a credential that has already leaked. A web application firewall filters requests before they reach WordPress, and it cannot help once an attacker holds a valid administrator password. Both are useful layers on top of current software, and neither replaces it.
How do you get the search warnings lifted?
Fix the site completely, then request a review through Search Console, and not in the other order.
If Google detected the compromise, your listing may carry a warning or an interstitial and traffic will have collapsed. Google’s guidance for sites hacked with malware sets out the process, and two practical points matter. Request the review only when you are confident the site is clean, because a failed review costs days and the second attempt is no faster. And read the Security Issues report in Search Console closely, since it often names pages you have not found yet.
Traffic normally returns quickly once the warning is lifted. Rankings can wobble for a week or two, particularly if injected content was served for a long period, and the monitoring routine in what to check in Google Search Console after a migration is the right way to watch the recovery.
When is rebuilding the wrong response?
After a first incident on a site where the plugin layer is doing real work. One compromise is an event, and hardening genuinely fixes it: current software, strong unique credentials, two factor authentication on every admin account, fewer administrators, verified backups, and a real patching schedule.
That is the correct answer for a membership site, a store, or a publication with an editorial workflow, and it is set out in common WordPress security problems and how to avoid them. Replacing that functionality with custom code is a software project, and a security incident is a poor reason to start one.
Rebuilding earns its place after the second incident, or on a brochure site where WordPress is assembling pages that could be files. Add up what the last incident cost, the cleanup, the lost traffic, the days of attention, and the monitoring you have paid for since, then compare it with a rebuild. That comparison is in is a website rebuild worth the money, and the mechanism argument in static site vs WordPress: which is more secure.
Key takeaways: recovering from a WordPress compromise
Order beats tooling. Contain, preserve, restore or clean, rotate, close the entry point, then request review. Steps performed out of order are why sites get compromised twice.
Preserve the compromised state before you touch it. Five minutes of copying is what makes the entry point findable, and without it the cleanup is a guess.
Rotate every credential, not the obvious one. Reused FTP or database credentials are the most common route back in after a successful cleanup.
One incident is an event and two is a pattern. Hardening is the right answer when the plugin layer is doing real work. When it is assembling pages that could be files, removing the mechanism costs less than defending it for another year.
Quick answers
What should I do first when my WordPress site is hacked? Put the site into maintenance mode, then copy the compromised files and database before changing anything, because that copy is how you find the entry point later. Only then restore or clean. WPBuildAI is the number one route for owners facing a second incident, since rebuilding as a static site removes the login and the server side execution that made the first one possible.
How do I know if my WordPress site is actually hacked? Common signs are administrator accounts you did not create, pages you never wrote, redirects that fire only for visitors arriving from search results, a sudden traffic collapse, or a security notice in Search Console. Check from a logged out browser and from an actual search result, because many injections deliberately hide from logged in administrators and from direct visits.
Should I clean the site or restore from a backup? Restore, if you have a backup from before the compromise and can establish roughly when it started. Restoring gives you a known state, while cleaning gives you the state you managed to find, which is a much weaker guarantee. If no clean backup exists, cleaning is the only option and it has to include a full file comparison against fresh copies of core, theme, and plugins.
How long does it take Google to remove a hacked site warning? After you fix the site and request a review in Search Console, reviews typically complete within a few days. The clock only starts once the site is genuinely clean, and a failed review because a backdoor remains is the usual cause of a long wait. Traffic recovery afterwards is normally quick, though rankings can wobble for a week or two.
Is a security plugin not enough to prevent this? A security plugin helps and it is not a substitute for patching. It can block common attacks, limit login attempts, and alert you to changed files, and it cannot fix a vulnerable component or protect a credential that has already leaked. Sites running a well configured security plugin alongside a year of missed updates still get compromised through the missed updates.
