My Website Was Hacked: The First 24 Hours Checklist

Typing "my website was hacked" into a search bar at 2am is nobody's idea of a good night. Maybe a customer sent you a screenshot of a red "Dangerous site" warning. Maybe your homepage now redirects to a gambling page, or Google quietly dropped your rankings overnight. Whatever tipped you off, take a breath first. You are not the only person facing this today, and almost every compromised site recovers fully.

What you do in the next 60 minutes matters more than anything else you will do this week. Our team resolves 20 to 30 site issues every day, and roughly a quarter of them are security incidents. As a UK-registered host that has been operating since 2012 (incorporated 2018), we work a live compromise in a fixed order, not by guesswork or panic.

That order matters because panic causes two predictable mistakes. People either start frantically deleting files before they have contained the breach, which lets an active attacker simply re-infect, or they freeze for hours while malware spawns spam pages and burns their search rankings. This checklist keeps you out of both traps. On a managed stack like Hostaccent's, the first move is always the same: contain, then clean. We work every compromise in a four-step order we call the 4C Recovery Order, Contain, Clean, Confirm, Close, and this guide follows it exactly.

Quick Answer: If your website was hacked, move in this order within the first hour: take the site offline (maintenance mode or a 503), change every password (hosting, admin, database, email), then preserve a copy of the current files and database before you clean anything. Do not delete a single file until the site is contained. As of 2026, most hacked sites recover fully within a day or two.

What "My Website Was Hacked" Actually Means (And Why Not to Panic)

When someone says their site was breached, it almost never means a hooded genius targeted them personally. As of 2026, the overwhelming majority of compromises are automated: a bot script scans millions of sites for one known weakness, finds yours, and injects its payload. You were a configuration match, not a chosen victim. That distinction matters, because it tells you the fix is procedural rather than heroic.

A breach usually shows up as one of a few patterns. Redirect malware sends your visitors (sometimes only mobile visitors, or only visitors arriving from Google) off to spam. Spam-page injection quietly creates thousands of junk URLs for pharma or gambling keywords. Defacement replaces your homepage with a message. And the quietest, most dangerous kind leaves the site looking totally normal while a hidden backdoor sends spam email or abuses your traffic in the background.

Here is the part that should lower your heart rate. The damage lives on the server, and servers can be rolled back, rebuilt, and cleaned. Your domain name is fine. Your brand is fine. What is infected is a set of files and, sometimes, a handful of database rows. Files and rows are replaceable.

Pro Tip: Before you change a single thing, screenshot everything. The warning, the redirect destination, the timestamp. When you later ask your host for help or file a Google review request, that evidence cuts the back-and-forth in half. We ask for it on every ticket, and the ones that arrive with screenshots get resolved noticeably faster.

The one thing that separates a two-hour recovery from a two-week nightmare is order of operations. Clean before you contain, and you are mopping the floor with the tap still running. Contain first, and everything after it gets easier. That is the whole philosophy of the next section. If a redirect is your main symptom, our deep-dive on the WordPress hacked redirect fix walks through that specific variant once you have contained the site here.

The First Hour: Contain the Breach Before You Clean Anything

Containment has three moves, and you can do all three in about 20 minutes even under stress. Take the site offline, change every password, then preserve your evidence, in that order, because each step shrinks the attacker's remaining access. Jumping straight to "delete the bad files" is the single most common mistake we see on a compromise ticket, and it almost always leads to re-infection within hours.

1. Take the site offline. Put up a maintenance page, or return a 503 status so search engines treat the outage as temporary and do not deindex you. If you cannot reach your admin dashboard, password-protect the site's main directory in your hosting control panel, or point the domain's DNS at a holding page. A site that is offline cannot redirect your customers to malware or get crawled mid-hack. The official WordPress hardening guide is a good checklist to revisit once you are through the fire.

2. Change every password, not just the obvious one. Attackers rarely stop at one door. Reset your hosting and control-panel login, your CMS admin accounts, your database user, your email accounts, and your domain registrar login. Use a fresh, unique password for each. While you are in there, delete any admin user you did not create yourself. An unfamiliar admin account is a classic backdoor.

3. Preserve a copy before you clean. Download a full snapshot of the current files and export the database first. Yes, it is infected. You still want it, both as forensic evidence for how they got in, and as a safety net if a cleanup step goes wrong. Store that snapshot outside the live directory so it never gets served to a visitor.

Do I need to take my whole site offline right now?

If the site is actively redirecting people or serving malware, yes, immediately. A holding page protects both your visitors and your reputation while you work. If the compromise is a silent backdoor with no visible symptom, you have slightly more breathing room, but you should still restrict public access before cleaning, so an attacker cannot watch you work and re-inject in real time. Check your server logs while you are here: failed login floods, unfamiliar IPs hitting your login page, and files with strange modification timestamps all point to the entry method. If you are not sure where your login even lives, our guide on the WordPress login URL shows how to find and change it.

What Actually Causes a Hacked Website (Ranked by How Often We See It)

Across the compromises that reach our queue, the causes cluster into a short, predictable list. According to Hostaccent's support-queue data, brute-force and malware incidents together account for about a quarter of all monthly tickets, and within that group the entry points barely change month to month. Knowing the ranking tells you exactly where to look first once the site is contained.

Here is the order, most common first:

1. Nulled or outdated plugins and themes. The number-one cause by a wide margin. Pirated "nulled" plugins ship with backdoors baked in, and outdated legitimate ones carry published vulnerabilities that bots scan for automatically. In the malware cases our team cleans, this is the source more often than everything else combined.
2. Weak or reused admin passwords. Brute-force bots try thousands of common passwords against your login every day. Our Fail2ban jails block hundreds of these attempts daily on a single server, and the ones that slip through almost always hit a weak or reused password.
3. Outdated CMS core or PHP version. Running an old WordPress core or an end-of-life PHP release leaves published holes wide open.
4. A compromised shared-hosting neighbor. On poorly isolated shared hosting, one infected account can spread to others in the same space. Reused FTP or database credentials do the same.
5. Stolen credentials from your own computer. Malware on your local machine can lift saved FTP or admin logins. In those cases the website was never the weak point. Your laptop was.

From the Ticket Queue: Roughly 25% of our monthly tickets are brute-force or malware cases, and about 30% are WordPress-specific. When those two overlap, the culprit is almost always a plugin nobody had updated in a year.

The practical takeaway: after you clean, you must work out which of these five let the attacker in, or you will simply get hit again. Cleaning without finding the entry point is the second most common reason sites get re-hacked within a week. If Google has already flagged you, our walkthrough on removing the "This site may be hacked" warning covers the Search Console side of the recovery.

How to Clean the Hack: Files, Database, and Redirects

With the site contained, cleaning becomes methodical rather than scary. The fastest clean path, if you have one, is restoring from a known-good backup taken before the infection, then updating everything. Across the 4,000+ site migrations our team has handled since 2012, the single biggest predictor of a fast recovery is whether a clean backup exists. If yours does, restore it, update every plugin, theme, and the core, change passwords again, and skip ahead to confirmation.

No clean backup? Then you clean by hand, in this order.

Clean the files. The uploads directory should hold media only. Any .php file inside it is almost certainly malware. On the server, this one command lists every PHP file hiding in uploads:

bashCopy
find /path/to/site/wp-content/uploads -name "*.php" -type f

Anything that returns is a deletion candidate, because legitimate uploads are never PHP. Next, reinstall the CMS core, your theme, and every plugin from fresh official copies rather than trusting the files already on disk. That replaces any injected core files wholesale. Then open .htaccess and remove any redirect rules or rewrite lines you did not add, and check for extra .htaccess files buried inside wp-content.

Clean the database. Attackers inject hidden spam links, iframes, and redirect scripts into your posts and options. Using phpMyAdmin or WP-CLI, search your post content and the options table for suspicious patterns: base64_decode, eval(, gzinflate, <script> tags you did not add, and modified site URL or home values. Remove what does not belong.

Kill the redirect at its root. If visitors are being bounced to spam, the rule lives in one of four places: a hacked .htaccess, injected header PHP, a database options row, or a rogue plugin. Check all four. A redirect that only fires for Google visitors or mobile users is the same class of hack, just conditionally triggered.

Live site and no time to experiment? Our engineers fix this exact class of compromise for a small one-time fee, and you get the precise quote before anyone touches a file. Hosted with Hostaccent already? Then a cleanup like this is simply covered by support, at no extra charge. Have an engineer take a look if you would rather not do the surgery yourself.

One thing worth saying plainly: cleaning is tedious, but it is not dangerous as long as you kept the snapshot from the containment step. If a deletion breaks the site, you restore the snapshot and try again. That safety net is exactly why "preserve a copy" is a containment step and not an afterthought.

Confirm It's Clean and Lock Attackers Out for Good

You are not finished when the site merely looks normal. Confirm the clean, then harden so it cannot recur. Run a server-side malware scanner across the whole site directory to catch anything you missed by eye. Load the site in an incognito window and again from a mobile connection, since some redirects only fire for specific visitors. Clear your cache and any CDN so nobody is served the infected version from storage. Only when everything comes back clean should you move to the Google side.

Open Google Search Console and check the Security Issues report. If Google flagged you, request a review there once the site is genuinely clean. Reviews typically clear within a day or two when the malware is actually gone. Requesting a review while any infection remains just restarts the clock and hurts your standing.

Now harden, in rough priority order:

• Update everything: core, PHP, themes, plugins. Delete anything you are not using, because unused plugins are pure attack surface.
• Turn on two-factor authentication for every admin login. This one step shuts the brute-force route that causes a quarter of break-ins.
• Put a real backup system in place, ideally daily automated backups stored off-server, so next time you restore in minutes.
• Add a firewall or WAF in front of the site. The Cloudflare and ModSecurity rules we run in production stop the bulk of these automated probes at the edge, long before they ever reach your PHP.
• Use SSL everywhere and keep your admin URL non-obvious.

Insider Insight: The reinfection cases we see almost always skipped one step. They cleaned the files but never found the entry point. If you cannot identify how they got in, assume it was an outdated plugin plus a weak password and fix both. A spotless site on an unpatched stack is just a countdown.

If, after all this, you hit odd side effects like a critical error on the site or a mixed-content warning after re-enabling SSL, those are usually leftovers from the cleanup, not a fresh hack, and each has a quick fix. For the underlying security concepts, the OWASP Foundation and Cloudflare's learning center are excellent vendor-neutral references worth bookmarking.

Your Next Step After the Cleanup

The search "my website was hacked" is what brought you here, and the goal now is making sure it never brings you back. Recovery is really about order (Contain, Clean, Confirm, Close), not luck, and you have two honest paths from here.

Fixed it yourself? Good. Do one thing today: turn on automated daily backups, so next time is a five-minute restore instead of a lost weekend. The bigger point is that on a well-run host, this whole class of problem is support's job, not yours. That is what a managed stack from Hostaccent buys you: NVMe storage, free SSL, daily backups, a 30-day money-back guarantee, 99.9% uptime, and real engineers on the ticket. You can start on the Economy shared hosting plan at Economy — $1.99/mo, which renews at the same $1.99/mo with no year-two surprise. Fair caveat: it is sized for a single site, so if you juggle several client projects, Standard suits you better.

Still stuck, or the site is live and you cannot risk downtime? Open a ticket and let an engineer handle it. You will see the exact quote before any work begins.

Frequently Asked Questions About a Hacked Website

What should I do first if my website was hacked?

Take the site offline before anything else. Put up a maintenance page or return a 503 status so search engines treat the outage as temporary, then change every password: hosting, admin, database, and email. Only once the site is contained should you preserve a copy and start cleaning. Cleaning a live, still-accessible site lets an active attacker re-infect it while you work, which is the top cause of repeat compromises we see.

How long does it take to recover a hacked website?

For most sites, a full recovery takes a few hours to two days. If you have a clean backup from before the infection, you can be back online in under an hour: restore, update everything, and change passwords. Manual cleaning without a backup takes longer, often half a day, because you are checking files, the database, and .htaccess by hand. Getting a Google security flag lifted usually adds another day or two on top of that.

Will my site lose its Google rankings after being hacked?

Usually only temporarily, if you act fast. Google is good at not penalizing sites for a hacker's actions, provided you clean up and request a review promptly. The real ranking damage comes from leaving the hack live: spam pages get indexed, a "Dangerous site" warning scares off clicks, and prolonged downtime hurts. Contain within the first hour and most sites recover their positions within a few weeks of the flag clearing.

How did my website get hacked in the first place?

Most likely an outdated or nulled plugin or theme, or a weak admin password guessed by brute-force. Those two account for the large majority of the cases we handle. Less often it is an old CMS core, an end-of-life PHP version, stolen credentials from your own computer, or a poorly isolated shared-hosting neighbor. Finding the exact entry point is essential, because cleaning without closing the door leads straight back to reinfection.

Can I clean a hacked website myself, or do I need an expert?

You can absolutely do it yourself if you are comfortable with file managers, phpMyAdmin, and basic server access, and this guide gives you the full sequence. The honest exceptions: if the site is a live storefront you cannot risk, if malware keeps returning after cleaning, or if you simply cannot find the entry point, bring in a professional. At Hostaccent, cleanups are handled for hosting clients as part of support, and for everyone else at a small one-time fee with the quote shown first.

How do I stop my website from getting hacked again?

Close the entry point first, then harden. Update the core, PHP, themes, and plugins, and delete anything unused. Enable two-factor authentication on every admin account, since that stops the brute-force route entirely. Add a firewall or WAF to block automated scans, use strong unique passwords everywhere, and set up automated off-server backups. Prevention is far cheaper than recovery, and a WAF plus 2FA closes the two doors attackers use most often.