Security

Your WordPress store was hacked

What to do, in order, from the first hour to the day the browser warning disappears — and where the job stops being yours.

Get a free speed audit See what it costs

Compromised website marked by an urgent security shield

Finding out that your store has been compromised is a bad hour, and most of the damage that follows comes from acting out of order. People delete suspicious files before they know what was touched, reinstall WordPress over the top of the problem, change one password and call it finished. What follows is a sequence rather than a checklist: recognise it, contain it, preserve what you will need later, restore or clean, prove the way in is actually closed, handle the customer and payment side honestly, then ask Google to look again. Work down it in order and resist the urge to jump ahead. Skipping a step usually means doing the entire thing a second time three weeks later.

1. How you usually find out

Almost nobody discovers this by reading their own files. The signal arrives from outside: a red interstitial telling visitors the site ahead is deceptive, a Security Issues notice in Search Console, your host suspending the account, your payment provider asking questions, or a customer forwarding a screenshot of a page you did not write. Two patterns are worth naming because they hide well. The first is conditional behaviour — a redirect that fires only for visitors arriving from search, or only on mobile user agents, so the site looks perfectly normal when you check it on your desktop while logged in. The second is index pollution: search your own domain with a site: query and look for pages selling things you do not sell. Both mean the compromise has been live long enough for Google to have crawled it.

Search Console: Security Issues, plus a sudden spike in indexed URLs
Open the store in a private window, on mobile, arriving from a search result
Check host, gateway and email-sender notices before dismissing them
Run a site: query and read the page titles you do not recognise

2. The first hour is containment, not cleaning

The instinct is to start deleting. Do the opposite. If there is any chance that payment or account data has been exposed — a modified checkout, unknown code loading on the payment step, admin accounts you did not create — put the store into maintenance mode or take it offline before you touch anything else. A store that keeps taking orders while compromised keeps producing victims, and every hour of that is harder to explain later than an afternoon of downtime. Then preserve evidence, because cleaning destroys it. Take a full snapshot of the site exactly as it is, files and database together, and copy the server access logs, error logs and any security plugin logs off the machine. Logs rotate on a schedule that does not care about your incident, and the timestamps in them are frequently the only way to find the way in.

3. Rotate every credential, not just the WordPress password

Attackers rarely leave through the door they came in by. Assume every secret the site could reach is known and rotate all of them: hosting control panel, SSH and SFTP, the database user, every WordPress administrator, the email account used for password resets, and the API keys and webhook secrets for payments, shipping, email and analytics. Force a logout of all sessions so stolen cookies stop working. There is an ordering trap here worth stating plainly. Rotating credentials into a system that is still compromised simply hands over the new ones, so the honest approach is two passes: change the outermost keys first — hosting, DNS registrar, email — then change everything else once the site itself is clean and you understand the entry point.

Hosting panel, SSH, SFTP and the DNS registrar account
Database user, plus every WordPress admin and editor account
Payment, shipping and email API keys and webhook secrets
Any reused password: a store breach is a personal-account breach

4. Restore from a clean backup, or clean in place

Restoring is usually faster and always more trustworthy — provided you have a backup taken before the compromise, and you can name the date the compromise started. That second condition is the one people skip. If a defaced page appeared on Tuesday, the code that produced it may have been sitting there since March, in which case your February backup is the only clean one and it predates several months of orders. Reconcile the gap deliberately: export recent orders and customer records from the live database, restore the clean site, then reimport the transactional data rather than the code. Cleaning in place is the fallback when every backup is suspect. It is slower, easier to get wrong, and demands file-level comparison against known-good sources rather than eyeballing directories.

5. An unexplained entry point means you are not finished

The single most common failure is declaring victory after removing the visible symptom. If you cannot say how they got in, the same route is still open and the site will be reinfected, often within days. Compare WordPress core and plugin files against official checksums rather than trusting how they look. Then check the places persistence usually lives: administrator accounts created outside your team, scheduled tasks in WP-Cron and system cron that call code nobody recognises, the must-use plugins directory, the active theme's function files, and executable files sitting in the uploads folder where only images belong. Pay particular attention to plugins nobody has opened in a year — abandoned and unmaintained extensions are the usual entry point, and thinning them out is worth doing anyway for reasons that have nothing to do with security. Plugin bloat covers that side of it.

6. When this is not a do-it-yourself situation

If card data could have been exposed, stop. That means any store where card fields are rendered by your own site rather than by a hosted field or a redirect to the provider, and any store where unknown code was found loading on the checkout page. At that point you are not cleaning a website, you are handling a payment-data incident, and the sequence is: preserve everything, contact your payment provider, and bring in people who do incident response for a living. The cheaper path is legitimate in the ordinary case — a defaced page or spam injection on a store using hosted payment fields, with a known-clean backup from yesterday, is a restore and an afternoon. And sometimes the right move is nothing: a security plugin flagging a file it does not recognise is not evidence of a breach. Verify before you act. If you would rather hand the whole thing over, hiring a developer for this is a different brief from building features.

7. Customers, your provider, and the Google warning

Two obligations run in parallel with the technical work, and neither is something to guess at. Your payment provider's merchant agreement will say what you must report and how quickly, and your jurisdiction may impose its own disclosure duties with their own deadlines — in the US that varies by state and by the kind of data involved. Ask your provider directly and ask a lawyer; treat anything you read online, including this page, as background rather than advice. Once the site is genuinely clean, request a review in Search Console under Security Issues. Reviews are done against the live site, so a premature request that fails costs you days. Expect the warning to persist for a short while after approval as browser lists refresh, and expect rankings to take longer than the warning does — recovering visibility in Google is its own process.

8. Hardening, so the next attempt fails quietly

Cleanup restores yesterday. Hardening is what changes the odds, and most of it is unglamorous maintenance rather than security products. Keep WordPress core, plugins and PHP on supported versions, because the majority of compromises exploit something patched months earlier. Give every person the smallest role that lets them work, and delete accounts when people leave. Turn on two-factor authentication for every administrator without exception. Remove plugins and themes you no longer use instead of deactivating them, since inactive code is still reachable code. Make backups you have actually restored at least once — an untested backup is a belief, not a plan. Then add monitoring that tells you about file changes, new admin users and downtime before a customer does. That steady, boring work is the substance of a maintenance and support arrangement, and it costs far less than a second incident.

Two-factor authentication on every administrator account
Least-privilege roles, and accounts removed when people leave
Unused plugins and themes deleted, not just deactivated
Backups restored to a staging site on a schedule, so you know they work

Frequently asked questions

Still have questions?

Reach out and we'll get back to you within 24 hours.

What does it cost to have this handled properly?

It depends almost entirely on whether payment data is involved. A spam injection on a store with hosted payment fields and a clean backup is a short, contained piece of work. A suspected payment-data incident involves your provider and specialist responders, and that is a different budget. Our own engagements start at $1,999, and we will tell you plainly when the right call is a specialist rather than us.

What is the real risk if I just delete the bad files?

Reinfection, usually within days. Removing the symptom without finding the entry point leaves the route open, and it also destroys the log evidence that would have identified that route. The second cleanup is always more expensive than the first, because by then the logs are gone.

How long until the browser warning is gone?

Cleaning a straightforward compromise is typically days rather than weeks once you have access and backups. The Search Console review after that is usually resolved within a few days when the site is genuinely clean, and browser warning lists take a little longer to refresh. Search rankings recover on their own schedule and lag well behind the warning.

What happens to my WooCommerce setup and my orders?

Nothing needs to be rebuilt to recover from a compromise. Products, stock, orders, coupons, tax and shipping rules and payment gateways stay in WordPress, and the goal is to return that installation to a known-good state. Where a restore would lose recent orders, transactional data is exported from the live database and reimported into the clean site rather than being written off.

See how many sales your store is losing

Start with a free speed audit. You'll get your store's real numbers and an honest recommendation — even if it's "you don't need us".

See design examples