What to Do If Your Website Gets Hacked (And How to Prevent It)

Last updated: August 15, 2026 · By Joseph Olivas, Founder, MEAN Consultors · 9 min read

I get a version of this call every few months. A business owner opens their own site and sees pharmaceutical links in the footer, or a customer forwards a screenshot of a browser warning, or Google Search Console fires off a “Security issues detected” email at 2am. The panic is understandable. What follows next usually determines whether this is a two-day inconvenience or a three-month recovery.

The good news is that a website compromise is a solved problem. There is a sequence, it works, and it is not especially expensive if you follow it. The bad news is that almost everyone gets the order wrong — and the order is the entire game. This guide is the exact process my team at MEAN Consultors runs when a client site is compromised, plus the preventive work that keeps it from happening twice.

What actually happens when a site gets hacked

Most small business owners picture a hacker sitting at a keyboard targeting them personally. That is almost never what happens. The overwhelming majority of website compromises are automated: a bot scans millions of sites for a specific outdated plugin version or a reused admin password, finds yours, and exploits it without a human ever looking at your business.

That matters, because it tells you what the attacker actually wants. They rarely want to deface your homepage — that would get the compromise noticed and cleaned. They want quiet, persistent access they can monetise: injecting spam links to boost someone else’s rankings, redirecting your mobile visitors to a scam page, skimming card numbers at checkout, or using your server as one node in a spam-sending network.

Figure 1: The most common artefacts found on compromised sites. Percentages exceed 100 because a single hacked site typically carries several at once. Source: Sucuri hacked website and SiteCheck scan data.

Sucuri’s scan data makes the pattern clear. Injected malware and redirect scripts show up on roughly seven in ten infected sites. SEO spam — hidden links for counterfeit pharmaceuticals, gambling and knockoff goods — appears on around four in ten. And backdoors, the small scripts that let an attacker walk back in after you clean up, were found in a comparable share of compromised environments. That last number is the one to sit with. It means that on most hacked sites, the attacker has already planted a way back in before you notice anything is wrong.

How to tell whether you have actually been hacked

Before you start tearing your site apart, confirm the diagnosis. A slow site is not necessarily a hacked site, and a spam-looking referral in analytics is usually just spam traffic. Here are the signals that genuinely indicate compromise:

• Google Search Console shows a Security Issues report, or your pages carry a “This site may be hacked” label in search results.
• Searching site:yourdomain.com in Google returns pages you never created — often in another language, or about pharmaceuticals, loans or streaming.
• The site behaves differently for visitors arriving from Google or on mobile than it does for you when you type the URL directly. Conditional redirects are deliberately designed to hide from the owner.
• There are admin users, scheduled tasks or FTP accounts you do not recognise.
• Recently modified files with timestamps you cannot account for, especially in theme directories, wp-includes, or anywhere .php files sit inside an uploads folder.
• Your host has suspended the account or flagged outbound spam.
• Customers report card fraud after purchasing from you — treat this as an emergency, not a maybe.

If two or more of these are true, stop investigating and start containing. Every additional hour a compromised site stays live is more indexed spam pages, more exposed customer data, and more reputational damage to unwind later.

The first 72 hours: a response sequence that works

This is the part people get wrong. The instinct is to delete the bad-looking files immediately and get the site back up. That instinct destroys the evidence you need to find the entry point, which guarantees the attacker returns. Work through these stages in order.

Figure 2: The MEAN Consultors incident-response sequence for a compromised website. The stages run in order — step 2 is the one most commonly skipped.

Stage 1 — Contain (0–1 hour)

Put the site into maintenance mode or take it offline at the host level. If you process payments, disable checkout first. Then rotate credentials — all of them, not just the one you think was breached: CMS admin accounts, database user, hosting control panel, SFTP/SSH keys, API keys for payment and email providers, and any third-party service with write access to your site. Given that stolen credentials drive the large majority of web application attacks, assume every secret in that environment is compromised.

Stage 2 — Preserve (1–4 hours)

Take a full snapshot of the file system and a database dump before you clean a single file, and store it somewhere isolated. Pull your web server access logs and error logs for at least the preceding 30 days. This archive is how you answer the only question that matters: how did they get in? Skip it and you will be guessing.

Stage 3 — Eradicate (4–24 hours)

Now remove the infection. Compare your file tree against a clean copy of the same CMS and plugin versions and treat anything that differs as suspect. Look specifically for backdoors: obfuscated PHP in uploads directories, unfamiliar scheduled tasks, modified .htaccess rules, injected database rows in options or post-content tables, and admin users created outside your normal process. Then patch the entry point — the vulnerable plugin, the exposed admin panel, the reused password.

Stage 4 — Restore (24–48 hours)

Where a known-clean backup predating the compromise exists, restoring it is usually faster and safer than cleaning in place. Reapply any legitimate content created since that backup by hand. Before you go live, run a full malware scan and manually verify the site behaves identically for a direct visitor, a visitor arriving from Google, and a mobile visitor.

Stage 5 — Recover in search (48–72 hours)

Once the site is genuinely clean, request a review in Google Search Console under Security Issues. Reviews typically take a few days. Meanwhile, check site:yourdomain.com for spam pages that made it into the index and remove them properly — return a 410, then use the Removals tool to speed up de-indexing. If your rankings dipped, expect recovery over weeks rather than days.

What a compromise actually costs

Owners tend to think of a hack as a cleanup bill. The cleanup is usually the smallest line item. The table below breaks down where the real cost lands, based on the recovery projects we take on.

The search recovery line is the one that surprises people. A hacked site that spent three weeks serving spam to Googlebot does not simply resume its old rankings when you clean it. You are asking a search engine to re-trust a domain it recently flagged, and that takes time you cannot buy back. If organic traffic is a meaningful revenue channel for you, prevention is not an IT expense — it is protecting a marketing asset.

Preventing the next one: what actually moves the needle

Website security advice tends to arrive as an intimidating list of forty items. In practice a small number of controls prevent the overwhelming majority of real-world compromises, because the overwhelming majority of compromises exploit the same handful of weaknesses. Prioritise in this order.

• Enforce multi-factor authentication on every admin account. Since stolen credentials are the dominant attack path, this single control removes most of the risk. No exceptions for “just the one contractor account.”
• Patch on a schedule, not on a whim. Core, plugins, themes and server packages. If a plugin has not been updated by its developer in over a year, that is a vulnerability with a countdown timer — replace it.
• Reduce your plugin surface area. Every plugin is third-party code running with your site’s privileges. Audit quarterly and delete anything you are not actively using. Deactivated is not deleted.
• Run automated off-site backups and test a restore. A backup you have never restored is a hypothesis. Backups stored only on the same server are worthless in a real compromise.
• Put a web application firewall in front of the site. It blocks the automated scanning traffic that finds vulnerable sites in the first place, and buys you time between a vulnerability disclosure and your patch window.
• Apply least privilege to user accounts. Most people with a login do not need administrator rights. Contributors should be contributors.
• Verify your host’s isolation. On cheap shared hosting, a neighbouring compromised site can sometimes reach yours. If your site matters to your revenue, its hosting should reflect that.
• Monitor for change. File-integrity monitoring and uptime alerts mean you find out from a tool, not from a customer.

None of this is exotic. It is maintenance — which is exactly why it gets skipped. We cover the underlying vulnerability categories in more depth in our website security checklist for small businesses, and the ongoing cost of doing this properly in our breakdown of what website maintenance really costs per year.

When to handle it yourself and when to call someone

If you run a brochure site with no customer accounts, no payment processing and a recent clean backup, restoring that backup and patching what was outdated is a reasonable weekend project. Be honest about the backdoor risk and scan thoroughly afterwards.

Bring in help when any of the following is true: you process payments or store personal data; the compromise is more than a few days old; you have already tried cleaning and it came back; your host has suspended you; or Google has applied a manual action. Those situations involve evidence handling, potential disclosure obligations and search recovery work where a wrong move is expensive. The cost of a professional response is almost always lower than the cost of a second compromise.

Frequently Asked Questions

How do I know if my website has been hacked?

The clearest signals are a Security Issues report in Google Search Console, unfamiliar pages appearing when you search site:yourdomain.com, redirects that only affect visitors arriving from search or on mobile, admin users you did not create, and recently modified files you cannot account for. If two or more of these are present, treat it as a confirmed compromise and begin containment.

What is the first thing I should do if my website gets hacked?

Take the site offline or into maintenance mode and rotate every credential associated with it — CMS, database, hosting panel, SFTP/SSH and third-party API keys. Do this before cleaning anything. Then snapshot the files and database so you preserve the evidence needed to identify the entry point.

Should I delete the infected files immediately?

No. Take a full snapshot of the files and database first, and pull your server logs. Once you delete the artefacts you lose your ability to trace how the attacker got in, and without that you will patch the symptom rather than the vulnerability. That is the single most common reason sites get reinfected.

How long does it take to recover from a website hack?

Technical cleanup on a straightforward compromise typically takes one to five days. Search recovery takes longer: a Google security review usually takes a few days after you request it, and if spam pages were indexed or rankings dropped, the organic traffic recovery generally runs over several weeks.

Will being hacked hurt my Google rankings?

It can, significantly. If Google flags your site with a security warning, click-through collapses even while you still rank. If the attacker injected spam pages or cloaked content, you may also see ranking losses on your legitimate pages. Cleaning quickly and requesting a review limits the damage, but recovery is measured in weeks rather than days.

Can a hacked website be fully cleaned, or do I need to rebuild?

Most sites can be fully cleaned. A rebuild becomes the better option when the compromise is old and deeply embedded, when the site runs on unsupported software you were going to have to replace anyway, or when cleanup costs approach the cost of a modern replacement. Where a clean pre-compromise backup exists, restoring it and patching is usually the fastest safe path.

How much does it cost to clean up a hacked website?

It varies with the depth of the compromise and the complexity of the site, so any single figure would be misleading. What is consistent is the shape of the bill: the technical cleanup is usually the smallest component, while lost revenue during downtime and the slow recovery of organic search visibility account for most of the real cost.

Does an SSL certificate protect my site from being hacked?

No. HTTPS encrypts data in transit between a visitor’s browser and your server. It does nothing to stop an attacker exploiting a vulnerable plugin or logging in with a stolen password. It is necessary but nowhere near sufficient — a hacked site with a valid certificate is still a hacked site.