My WordPress Site Was Hacked, What Do I Do First? (Hour-by-Hour Playbook)

If you have just discovered that your WordPress site was hacked, the first thing to do is take the site offline by enabling maintenance mode, and then take a full snapshot of files and database before you touch anything else. That sequence matters more than your instinct to start deleting suspicious files, because the moment you begin cleaning you destroy the evidence you need to find how the attacker got in, and a clean that does not find the entry point is a clean that gets undone within a week. Stay calm. A hacked WordPress site is a bad afternoon, not a lost business. Almost every infection we have handled across roughly 250 sites at WitsCode follows the same shape and has the same fix.

This article is the playbook we run, written as an hour-by-hour timeline so you can find your place in it depending on when the alarm went off. Each phase below is a set of decisions rather than a checklist, because the order is the part that gets people into trouble. People who restore a backup before identifying the vector reinfect themselves within days, and people who change passwords but never rotate the secret keys leave a logged-in attacker logged in. The point of a timeline is that it stops you skipping the step that the next step depends on. Read it once before you start, then work it from the top.

The first hour: isolate and snapshot

The first hour is about containment, and containment means two things done in order. First, put the site into maintenance mode so the public, Google's crawler, and your customers stop seeing whatever the attacker has injected, whether that is a spam pharmacy page, a phishing form, or a redirect that sends mobile visitors to a scam. If you can reach wp-admin, a maintenance plugin does this in one click; if you cannot, drop a .maintenance file into the site root or have your host flip the site to a holding page. The goal is to stop active harm to visitors and to stop Google indexing the malicious content while you work, because a site that keeps serving malware for another six hours collects search penalties that take weeks to clear.

The second half of the first hour is the snapshot, and this is the step people skip when they are panicking. Before you delete a single file, take a complete copy of the entire site as it currently is, infected and all. That means a full archive of the file system, including wp-content, the root, and any files that look obviously malicious, plus a complete export of the database. Most managed hosts can produce this snapshot from the control panel in a couple of minutes. Store it somewhere off the server. This infected snapshot is not something you will ever restore, but it is the only record of how the attack looked, and in the next phase you will read it like a crime scene. Cleaning first and snapshotting never is the single most common reason a recovery has to be done twice.

While the snapshot runs, do one more thing: change the hosting account password and the SFTP or FTP password at the host level, and if your host offers it, force a logout of all active sessions. This does not fix anything yet, but it closes the door behind the attacker so nothing new arrives while you work. Do not yet touch WordPress user passwords or secret keys; that belongs in the harden phase, and doing it now can tip off an attacker who is watching or lock you out of a step you still need.

Hours two to four: identify the vector

With the site contained and snapshotted, the next two to three hours go to the question that the whole recovery hinges on. How did they get in? You cannot answer this by guessing, and you cannot skip it, because a clean that does not close the entry point is temporary. There are four common vectors and you are looking for evidence of which one applies. The most frequent by a wide margin is a vulnerable plugin or theme, usually one that was several versions out of date and had a known exploit published against it. The second is a weak or reused administrator password that was brute-forced or found in a credential dump. The third is a compromised hosting neighbour on cheap shared hosting, where another infected site on the same server reached across into yours through loose file permissions. The fourth is stolen SFTP or FTP credentials, often lifted from an infected laptop by malware that scans for saved logins.

Start the investigation with the security scanners, because they do the first pass of pattern matching for you. Install or open Wordfence and run a full scan, or use Sucuri's scanner, and read the results as a map rather than a to-do list. The scan will name modified core files, files that do not belong to any known plugin, and code signatures that match known malware. Cross-reference what it finds against the file modification dates in your snapshot. A cluster of files all changed at the same timestamp tells you when the breach happened, and the modification time of the very first changed file usually points straight at the entry point. If that first file lives inside a specific plugin directory, that plugin is your prime suspect; check its installed version against the changelog for a security release dated before the breach.

Pull the server access logs for the hours around that first file modification, which your host can provide. Repeated POST requests to wp-login.php from a single address indicate a brute-force run and point at the weak-password vector. Suspicious requests to a plugin's AJAX endpoint or REST route point at a plugin vulnerability. File writes that arrived over FTP rather than HTTP point at stolen credentials. By the end of this phase you should be able to write one sentence: the attacker got in through X on this date. If you genuinely cannot determine the vector after a thorough look, treat it as a stolen-credential and unpatched-plugin compromise simultaneously and harden against both, because assuming the worst is cheaper than a second infection.

Hours four to twelve: clean the infection

Now you clean, and the cleaning is methodical rather than dramatic. Begin with WordPress core. Do not try to pick malicious lines out of core files by hand. Delete the entire wp-admin and wp-includes directories and every core file in the root except wp-config.php and the wp-content directory, then drop in a completely fresh copy of WordPress at the matching version downloaded straight from wordpress.org. This single move replaces every infected core file with a known-good original and is far safer than editing. Open wp-config.php in a plain text editor and read every line, because attackers love to hide a single base64-encoded include in it; if anything looks unfamiliar, compare it against a fresh wp-config-sample.php.

Then move to the themes and plugins, which is where most of the live infection sits. Delete every theme and plugin you are not actively using, with no sentimentality. For the ones you keep, the safe approach is the same as core: delete the plugin folder entirely and reinstall a fresh copy of the current version from the official repository or the developer's site, rather than trying to surgically remove injected code. Pay specific attention to anything nulled or pirated; pirated premium plugins are a leading malware source and should be removed permanently, not reinstalled. Anything the scanner flagged as a file with no legitimate home, often sitting in the uploads directory with a .php extension, gets deleted, because nothing legitimate runs PHP from inside wp-content/uploads.

The hardest part is wp-content/uploads and the database, because both can carry infected content that is not a plugin or a theme. In uploads, search for any file with a PHP or executable extension and remove it; legitimate uploads are images, documents, and media, never scripts. In the database, use a scanner or a careful search for known malicious patterns such as injected <script> tags in post content, suspicious entries in the wp_options table, unfamiliar rows in wp_users, and any administrator account you do not recognise. Delete rogue admin users, and check the wp_users table for an account created during the breach window. Run a final full Wordfence or Sucuri scan and do not stop cleaning until it returns completely clean. A scan that is ninety percent clean is a site that is still infected.

Hours twelve to twenty-four: restore and harden

Cleaning removes the infection. Hardening is what stops it coming back, and skipping it is why some sites get hacked three times in a month. The first hardening move is to rotate every credential and every secret. Change the password on every administrator account, and ideally on every user account, to a long unique password from a manager. Change the database password in your hosting panel and update it in wp-config.php to match. Then regenerate the WordPress secret keys and salts by replacing the eight AUTH_KEY style lines in wp-config.php with a fresh set from the official secret-key generator. Rotating the salts is the step people forget, and it matters because it instantly invalidates every existing login session cookie, which means any attacker still holding a valid session is logged out at that moment.

With credentials rotated, close the vector you identified in phase two. If it was an outdated plugin, the fresh reinstall already fixed it, but now enable automatic updates so it cannot drift out of date again. If it was a weak password, you have already replaced it, so now add a login limiter and two-factor authentication on every admin account so brute force cannot work even against a future weak password. If it was a compromised hosting neighbour, the real fix is to leave shared hosting for a properly isolated managed environment, because no amount of application hardening protects you from a server you do not control. If it was stolen FTP credentials, scan the laptop those credentials were saved on for malware, switch from FTP to SFTP, and stop saving the password in the client.

Then add the baseline that should have been there before the breach. Put a web application firewall in front of the site, whether that is the Wordfence firewall, Sucuri's cloud WAF, or Cloudflare's. Set file permissions correctly, with directories at 755 and files at 644, and make wp-config.php stricter at 600. Disable file editing inside wp-admin by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php, which removes a tool attackers use to inject code through a stolen login. Only now, with a clean and hardened site, do you bring it back. Take the site out of maintenance mode, click through the key pages and forms as a real visitor, and confirm nothing is broken before you tell anyone the emergency is over. If your only available backup predates the breach and you are confident the vector is closed, restoring that clean backup onto the hardened environment is a valid alternative to a manual clean, provided you still rotate every credential afterward.

Days two to fourteen: post-mortem and monitor

The first twenty-four hours end the emergency. The next two weeks decide whether it stays ended. The day after recovery, deal with the consequences that live outside your server. If Google flagged the site, request a malware review through Search Console so the warning is removed from search results, and check whether your host's security team placed a separate suspension that needs lifting. If the infection sent spam email, your domain may be on a blacklist, so check it against the common reputation lists and request delisting. If customer data was in scope, take advice on your disclosure obligations rather than hoping no one noticed. None of this is technical, and all of it is part of a real recovery.

For the following fortnight, watch the site closely, because reinfection almost always shows up inside fourteen days if the vector was missed. Run a daily security scan. Watch for new admin users, for unexpected file changes, and for any return of the redirect or spam behaviour that first tipped you off. Keep an eye on outbound email volume and on the server logs for a repeat of the request pattern you found in phase two. If the site comes back infected within this window, the vector was not fully closed, and the honest move is to repeat the investigation more carefully rather than just cleaning again. A second clean without a better diagnosis is the definition of doing the same thing twice.

Finally, write the short post-mortem, even if it is three sentences in a document only you will read. Record how they got in, what you changed, and what was missing that let it happen. Almost every site we recover was hacked because of something dull and preventable: an unattended plugin two years out of date, a password reused on six other sites, a backup that had quietly stopped running months earlier. The post-mortem turns a bad afternoon into a fixed weakness. The sites that never get hacked again are the ones where someone is responsible for keeping the boring things current.

When you would rather not do this alone

This playbook works, and a calm operator with a few hours can run it end to end. But a hack rarely arrives on a calm afternoon, and the cost of a missed vector is the whole thing again next week. If your site is down right now and you would rather hand the timeline to a team that has run it across 250 sites, the WitsCode emergency hack recovery service starts within hours: we isolate, snapshot, find the vector, clean to a verified zero-detection scan, harden, and handle the Google and blacklist cleanup. The deeper fix, though, is the one the post-mortem always points to. Sites get hacked because nobody owns the maintenance, so the recovery engagement rolls into an ongoing managed retainer where we keep core, plugins, and themes patched, run the firewall and the monitoring, and hold tested backups, so the next vulnerability is closed before an attacker finds it rather than after. The emergency clean buys back today. The retainer is what stops you reading this article a second time.