Your WordPress store was hacked

You almost always find out from outside, not by reading your own files: 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 behavior: 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 recognize

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. Many hosts keep only 7 to 14 days of access logs, and they 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.

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, because a store breach is a personal-account breach

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 and none of 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, which eyeballing directories is not.

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; how they look proves nothing. 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 recognizes, 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.

If card data could have been exposed, stop. That means any store where card fields are rendered by your own site and not 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 under PCI DSS. Preserve everything. Contact your payment provider within hours, not the days instinct suggests, 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 recognize 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.

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 and never as 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.

Cleanup restores yesterday. Hardening changes the odds, and most of it is unglamorous maintenance no security product sells. Keep WordPress core, plugins and PHP on supported versions, because the majority of compromises exploit something patched months earlier. Every person gets the smallest role that lets them work. Accounts go when people leave. Turn on two-factor authentication for every administrator without exception, and delete the plugins and themes you no longer use, because deactivated 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 reports 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