My website was hacked. What do I do?

A slow site, a weird plugin error, or one strange email is not proof of a hack — sites break for boring reasons all the time. Before you treat this as an incident, look for concrete signs that point specifically to compromise:

• Your browser, Google, or Google Search Console shows a “Deceptive site ahead” or “This site may be hacked” warning — see our dedicated guide on that exact warning if that’s what brought you here.
• Search results for your own site show spam text, pharmacy ads, or foreign-language pages you never published.
• An admin user, plugin, or theme exists in your CMS that nobody on your team added.
• Visitors report being redirected to a different site, or your host emails you about an abuse complaint.
• Your site suddenly sends outbound spam email, or your server load spikes with no traffic increase to explain it.
• Files have modified timestamps you can’t account for, especially in upload folders that shouldn’t contain code.

One item on its own can have an innocent explanation. Two or more together, especially the search-warning and spam-content signs, mean you should treat this as a real incident and move to Step 2.

Once you’re confident it’s real, order matters. Doing these out of sequence — especially deleting files before preserving evidence — is the single most common mistake that turns a one-day fix into a week-long mess.

1. Don’t panic, and don’t make it worse

Resist the urge to start clicking “delete” on anything that looks suspicious. Malicious code is often a symptom, not the whole story — if you remove the visible part without finding how it got there, whatever let the attacker in is still open, and they can walk right back in. Take five minutes to breathe and read this list before you touch anything.

2. Take the site to maintenance mode (or offline)

If the site is actively serving malware, spam redirects, or defaced content to visitors, get it out of the public eye immediately — most hosts and CMS platforms have a one-click maintenance mode, or you can point DNS at a static “back soon” page. This protects your visitors and stops search engines from crawling the compromised content while you work. If the damage looks contained (a single odd file, no visible spam), you may be able to leave it live while you investigate — use judgment, but when in doubt, take it down.

3. Change every password — from a clean device

Change your hosting account password, CMS admin password (WordPress, Shopify staff accounts, etc.), FTP/SFTP credentials, and database password. Do this from a device and network you trust, not the computer you normally use to manage the site — if that machine is itself infected with malware that logged your keystrokes, changing passwords on it just hands the attacker your new ones too. While you’re at it, revoke and reissue any API keys or third-party integration tokens the site uses.

4. Contact your host and tell them plainly

Hosts deal with compromised sites constantly and often have tools you don’t: server-level access logs, the ability to isolate your account from others on shared hosting, and sometimes a malware-scanning service included in your plan. Tell them exactly what you observed and when you first noticed it — don’t downplay it. Many hosting abuse teams will temporarily suspend a badly compromised site to protect their network; better to hear that from them proactively than get surprised by a suspension notice.

5. Preserve evidence before you clean anything

Before deleting or modifying a single file, take a full backup of the site exactly as it currently is — files and database both — and, if your host allows it, export the access and error logs covering the last few weeks. This copy is what lets you (or whoever you hire) actually find the entry point instead of guessing. Store it somewhere separate from the live site. Only after this backup exists should cleanup begin.

A few reactions feel productive in the moment but usually make recovery slower, more expensive, or both. Avoid these:

• Don’t delete files blindly. Removing suspicious code without understanding how it got there destroys your best evidence and leaves the actual entry point open for a repeat infection.
• Don’t restore an old backup and assume you’re done. If the backup predates the breach it may be clean, but if the vulnerability that let attackers in is still present, restoring just buys you a few days before it happens again. Fix the hole, then restore.
• Don’t log in to the compromised admin panel from a possibly-infected device to “take a quick look.” If your own computer has malware, you can hand over fresh credentials the moment you type them.
• Don’t stay quiet if customer data may be involved. Delaying notification when personal data was exposed can turn a technical incident into a legal and trust problem on top of it.
• Don’t assume one plugin update fixes it. If attackers got in, they often leave a backdoor (a hidden file granting future access) that a simple update won’t remove. A proper cleanup checks for backdoors, not just the original hole.
• Don’t pay a ransom or “unlock fee” demanded through the defaced site or a threatening email without independent verification — these are frequently bluffs, and paying doesn’t guarantee the attacker actually leaves.

Whether you can safely clean this up yourself depends on how deep the compromise goes, not on how confident you feel with a keyboard. Here’s a rough guide:

If you land in “bring in a human,” that’s exactly what a manual security audit is for — a real engineer looks at your actual site, finds how the attacker got in, and tells you precisely what to fix. Bug Circuit runs this as a $49 one-time audit with a full written report, or $299 for the audit plus we fix the high and critical issues ourselves and cover you for 3 months after — currently 55% off as a launch offer. See a sample report before you decide, and compare full pricing — no quote calls, no sales pressure.

Everything Bug Circuit does is authorized, consent-based testing — not a stranger poking at your live site. Before any hands-on work, we verify you own or control the domain and record a signed Authorization to Test. We productize this for small websites — WordPress, Shopify, small SaaS — and we say plainly what we are not: a five- or six-figure enterprise penetration-testing engagement. If your situation needs that (regulatory mandate, large custom platform, cyber-insurance requirement), we’ll tell you honestly rather than oversell.

Once the immediate incident is contained, understanding how you got hit prevents a repeat. The most common root causes we see are platform-specific:

• WordPress — an outdated plugin or theme with a known vulnerability, a weak or reused admin password, or a nulled/pirated plugin with malware baked in. If this keeps happening on the same site, read why WordPress sites keep getting hacked for the specific patterns and permanent fixes.
• Search results full of Japanese, Chinese, or foreign-language spam pages — this has a name, the Japanese keyword hack, and it’s one of the most common WordPress-specific infections. It generates thousands of spam pages search engines index under your domain, usually invisible to normal visitors.
• Shopify / hosted platforms — usually a compromised staff account (reused password, no two-factor) or a malicious third-party app with excessive permissions, rather than a platform vulnerability itself.
• Small SaaS / custom apps — most often a business-logic or access-control flaw (one user can reach another user’s data by changing an ID in the URL, for example) rather than a missing security patch.