A break-in rarely looks like it does in films - more often it is odd redirects, foreign links in Google and an email from your host. The site seems to work, but customers get sent from it to a dodgy pharmacy shop, subpages in Chinese show up in search results, and Chrome starts throwing up a red warning screen. All of that points to the same thing: someone has added their own code to your site and is using it for their own purposes.
The good news: the overwhelming majority of WordPress break-ins are bots exploiting vulnerable plugins, not a targeted attack on your business. It can be cleaned up and life can go back to normal. The bad news: simply deleting what you can see is almost never enough, because the intruder leaves themselves back doors.
How to tell it is a break-in
- Redirects to unfamiliar sites (sometimes only from a phone, or only from Google - that is deliberate camouflage)
- Foreign content and links nobody added; new administrator accounts
- A “This site may be dangerous” warning in Google or a red screen in the browser
- An email from your host about malicious code or about the account being suspended
- A sudden drop in Google traffic with no other explanation
- Spam going out from your domain - customers receive strange emails “from you”
If the site is simply down with an error message but none of the above symptoms, it is more likely an ordinary failure; start with the piece on the critical error or on error 500.
The recovery plan - the order matters
- Secure access. Change the passwords: to the WordPress admin (all administrator accounts), to the hosting, to FTP and to the database. An intruder with a working password will come back faster than you can clean up. Check the user list and delete any accounts you do not recognise.
- Take a copy of the current state. It sounds backwards - why copy an infected site? First: it is evidence and material for working out how they got in. Second: if the cleanup goes wrong, you have a reference point. The copy sits alongside; it overwrites nothing.
- Work out when it happened. The date of the last “clean” backup is your single most important piece of information. If you have a backup from before the infection, restoring it is the safest route - followed immediately by patching the hole (updates!), otherwise you will be back in the same place in a week. How to keep backups that actually save you, I describe in the safe update checklist.
- No clean backup: scan and clean. A scanner (a security plugin, or a scan on the hosting side) will find replaced core files and suspicious injections. WordPress and plugin files can safely be overwritten with fresh copies from official sources - that removes most of the appended code. The hardest part is back doors hidden in the
uploadsfolder, in the theme and in the database itself; here automation is often not enough, and this is usually the moment to hand the case to a specialist. The whole detection and cleaning stage I laid out in detail in a separate piece on WordPress malware. - Update everything. WordPress, plugins, theme, PHP version. The break-in almost certainly came through a known hole in something out of date - if you leave the old version in place, the cleanup was for nothing.
- Appeal in Google. If Google has flagged the site as dangerous: in Search Console (the “Security Issues” tab) submit the site for review after cleaning. The warning usually disappears within a few days. Without this step even a clean site keeps scaring customers off with a red screen.
What helps: on a store holding customer data, a break-in is also a data protection matter - if personal data could have leaked, you have 72 hours to assess it and, if needed, report it to UODO, the Polish data protection authority, under RODO (Poland’s implementation of GDPR). Do not panic, but do not sweep it away either: record what happened, when, and which data could have been accessible.
What not to do
- Do not delete the whole site on the grounds that “it is easier to build it again” - you lose content, orders and Google rankings, and the hole can just as easily be reopened on a fresh install
- Do not restore a backup without patching - you go back to the state before the break-in together with the hole they came in through
- Do not leave it “because it works” - a site with a back door will sooner or later send spam from your domain or land on blocklists, and that hurts longer than the break-in itself
How not to go through this a second time
Almost every break-in I have cleaned up had the same pedigree: plugins not updated for months, no backups and a password like “company2019”. The remedy is boring, and that is exactly why it works: regular updates on a fixed rhythm, backups kept off the site’s own server, strong passwords with two-factor login for administrators, and an annual plugin review - what is actually being used and what is sitting there “in case it comes in handy”. For clients on ongoing maintenance that rhythm runs automatically, together with monitoring that catches replaced files before Google notices them.
Frequently asked questions
How long does cleaning a hacked site take? Simple cases (a fresh infection, good backups) - hours. Neglected ones (an infection months old, no copies at all) - a day or two, because there is far more to go through. I give the quote after looking at it, in writing.
Could customers have lost anything? It depends on the type of infection. Most mass break-ins replace content and send spam rather than steal data. But on a store taking payments this has to be checked, not assumed.
Will the site come back in Google after cleaning? Yes. Once the code is removed and you have submitted the site in Search Console, the warnings disappear within days and rankings usually return within a few weeks - provided the site was not sitting there infected for half a year.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.