My WordPress Site Was Hacked: What to Do First, Hour by Hour

If your WordPress site has been hacked, take it offline behind a 503 holding page first, then take a full copy of the infected files and database before you delete anything. Next, find out how the attacker got in, clean from fresh copies of WordPress and your plugins, rotate every password and secret key, and ask Google to review the site. Google says to fix the security issue that let the attacker in, or the site is likely to be reinfected.³

Order is where most recoveries go wrong. Delete suspicious files first and you destroy the evidence of how the attacker got in. Restore a backup before finding the vector and you reinfect yourself. Change passwords without rotating the secret keys and a logged-in attacker stays logged in. Find your place in the timeline below, read it once, then work it from the top. WordPress.org's own advice for this moment starts with two words: stay calm.¹

The short version

• First hour: take the site offline (a 503 maintenance page), back up the hacked files and database, and change your hosting and SFTP passwords.⁶¹¹
• Hours two to four: find how they got in. Plugins are the usual suspect: 91% of the 11,334 WordPress vulnerabilities Patchstack logged in 2025 were in plugins.¹³
• Hours four to twelve: replace WordPress core, plugins and themes with fresh copies, delete PHP files from uploads, and remove users you don't recognize.¹¹²
• Hours twelve to twenty-four: close the vector, change every password again, regenerate the secret keys in wp-config.php, add two-factor login and a firewall, then bring the site back.¹²
• Days two to fourteen: request a review in Google Search Console, check email blocklists, scan daily and write a short post-mortem.⁴⁵
• If it keeps getting hacked, something was missed: a backdoor, a rogue user, an old copy of the site, a vulnerable plugin, or the server itself.

The first hour: isolate and snapshot

First, take the site offline so visitors and Google's crawler stop seeing whatever the attacker injected, whether that is a spam pharmacy page, a phishing form or a redirect to a scam. Google's guide for hacked sites recommends a 503 status served from outside the infected files, so the best option is a holding page your host sets up outside the WordPress install.⁶ A maintenance plugin or a .maintenance file in the site root is the fallback. Both run through the hacked install, so injected code can still fire. Google says taking a site offline temporarily during recovery is unlikely to affect its future rankings.⁶

Second, take the snapshot, the step people skip when they panic. Before you delete a single file, copy the entire site as it is now, infected and all: every file plus a full database export. Store it off the server and label it infected, as Google suggests, so nobody mistakes it for a clean backup later.⁷ Take it before you report the hack to your host. Wordfence warns that many hosts immediately delete a site reported as hacked, to protect the rest of their network.¹¹ WordPress.org also recommends a snapshot of the infected environment before cleaning.¹ You will never restore this copy. It is the only record of what the attack looked like, and in the next phase you read it like a crime scene. Cleaning first and snapshotting never is how a recovery ends up being done twice.

While the snapshot runs, change the hosting and SFTP or FTP passwords and your own wp-admin password, and force a logout of active sessions if your host offers it. Google's quarantine step says to change every login at this point.⁶ Leave the database password and the secret keys for the harden phase. Both are edits to wp-config.php, and they are safer to make once, on clean files. You will change every password again then anyway, because WordPress.org and Google both say to repeat it once the site is clean.¹⁷ Then write down what you saw, when (with the time zone), and what changed recently, such as a new plugin. WordPress.org calls this your incident report.¹

Hours two to four: find how they got in

Spend the next two to three hours on the question the whole recovery hinges on: how did they get in? A clean that leaves the entry point open is temporary. Look for evidence of one of these vectors:

1. A vulnerable plugin or theme, usually several versions behind with a published exploit. Patchstack's 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and only six in WordPress core.¹³
2. A weak or reused password. Google lists compromised passwords among the top ways sites get hacked.¹⁰
3. Stolen SFTP or FTP credentials. WordPress.org warns that many attacks start on your own laptop, where trojans capture saved logins for FTP and wp-admin.¹ Google recommends scanning every computer an administrator has used to sign in, with more than one antivirus tool.⁸
4. The server or a neighboring site. WordPress's hardening guide warns that a compromised site on the same shared server can compromise yours.² Host-level flaws count too, such as the cPanel vulnerability CVE-2026-87899, which lets any logged-in cPanel account on an unpatched server run code as root.
5. A core vulnerability. Rare, but it happens. CVE-2026-87902 was under active attack in September 2026 against sites that hadn't updated to WordPress 7.1.2 or a patched backport.

Start with the scanners. WordPress.org lists Wordfence, Sucuri, Quttera and GOTMLS among them.¹ Wordfence compares your core, theme and plugin files against the originals in the WordPress repository and flags anything that changed.¹¹ Read the results as a map, not a to-do list.

Then work out the timeline. If you have SSH, Wordfence suggests find . -mtime -2 -ls to list files changed in the last two days, widening the window until changed files appear.¹¹ A cluster of files changed at the same timestamp dates the breach, and the first file changed usually points at the entry point. If it sits inside a plugin directory, check that plugin's changelog for a security release dated before the breach.

Pull the server access logs for the hours around that first change and look for repeated admin login attempts and admin actions nobody on your side made.⁸ Repeated POST requests to wp-login.php from one address point at brute force. Odd requests to a plugin's AJAX or REST route point at a plugin flaw. Files 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. Keep looking even after you find one hole, because Google notes a site can carry more than one independent compromise.⁸ If you can't pin down the vector, treat it as stolen credentials and an unpatched plugin at the same time and harden against both. Assuming the worst costs less than a second infection.

Hours four to twelve: clean the infection

Before you delete anything, confirm your phase-one snapshot opens and sits off the server. It is your undo button for everything in this phase.

If you have a backup from before the breach and you know the vector, restoring it can replace most of the manual clean. Use your logs and file dates to pick a backup older than the first malicious change.⁸ Google's order is: restore the clean backup, install every update and patch, correct the vulnerability, then copy over only new content you have checked from the infected copy.⁷ Then go straight to the harden phase. Never restore a backup taken after the breach.

Without a clean backup, clean manually. Start with WordPress core, and don't pick malicious lines out of core files by hand. Delete the wp-admin and wp-includes directories and the core files in the root, keeping wp-config.php and wp-content, then upload a fresh copy of the same WordPress version from wordpress.org. WordPress.org says to do this over SFTP rather than with the reinstall button in wp-admin, because those installers often only overwrite existing files, and hacks add new ones.¹ Use the same version you were running so nothing breaks, then update once the site is clean.¹

Read every line of wp-config.php and compare anything unfamiliar against a fresh wp-config-sample.php. Check every .htaccess file too. WordPress.org names it one of the files attackers modify most, and copies can sit in several directories.¹

Then move to themes and plugins. Delete every theme and plugin you don't use. For the ones you keep, delete the whole folder and reinstall a fresh copy from the official repository or the developer. Wordfence notes that deleting a whole plugin directory usually loses no data, because WordPress disables the missing plugin.¹¹ Remove nulled or pirated premium plugins for good. They come from people you have no reason to trust, and the ClickFix campaign showed how cracked themes feed hacked sites.

Delete old copies of the site. Wordfence often sees infections that started in a forgotten, web-reachable folder such as /old/ and spread to the main site.¹¹

The uploads folder and the database are the hardest part. In wp-content/uploads, find any file with a PHP or other executable extension and remove it. Legitimate uploads are images, documents and media, never scripts. Wordfence publishes a command that lists every non-image file in uploads.¹¹ Sucuri lists the PHP functions backdoors commonly use, including base64_decode, eval, exec, system and assert, with the caveat that legitimate plugins use some of them too.¹²

In the database, search post content for injected <script> tags, check wp_options for entries you didn't create, and read wp_users for accounts made during the breach window. Sucuri's list goes further. Remove any user you don't recognize across WordPress admins, FTP, SSH and extra database users.¹² Run a final full scan, then a Wordfence high-sensitivity scan, and keep cleaning until it comes back 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 stops it coming back, and skipping it is why some sites get hacked again and again.

First, close the vector you found in phase two:

• Outdated plugin, theme or core. Update it to the patched release, or delete it if no fix exists. Turn on automatic updates and keep core current. As of October 6, 2026 that is WordPress 7.1.3, which fixes seven core security flaws.
• Weak password. Add two-factor authentication on every admin account, as the WordPress hardening guide recommends, plus a login limiter to slow brute force.²
• Hosting neighbor or host flaw. Ask your host how your account is isolated from other sites on the server, as the hardening guide suggests.² If the answer is weak, move to an isolated environment, because no amount of plugin hardening protects you from a server you don't control.
• Stolen FTP credentials. Scan the computer those credentials lived on with more than one antivirus tool, switch from FTP to SFTP, and stop saving the password in the client.¹⁸

Then rotate every credential and every secret. WordPress.org says to change passwords again after the site is clean: every user account, SFTP, the hosting panel and the database, with long unique passwords from a manager.¹ Update the new database password in wp-config.php in the same sitting, or the site goes down. Then regenerate the secret keys and salts: replace the eight AUTH_KEY style lines in wp-config.php with a fresh set from the official WordPress key generator. That forces every logged-in user off, including any attacker still holding a valid session cookie.¹ It is the step people forget.

Then add the baseline that should have been there before the breach. The WordPress hardening guide covers it: a web application firewall (Wordfence, Sucuri or Cloudflare all appear in its list), directories at 755 and files at 644, define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php so a stolen login can't edit PHP from the dashboard, and a database user limited to SELECT, INSERT, UPDATE and DELETE. The guide notes that some plugin installs and major updates need more, so grant it temporarily, with a backup, when they do.²

Only now do you bring the site back. Take down the holding page and click through the key pages and forms in a private window before you call the emergency over.

Days two to fourteen: monitor and review

The first twenty-four hours end the emergency. The next two weeks decide whether it stays ended.

The day after recovery, deal with what lives outside your server. If Google flagged the site, request a review in Search Console (covered below). Ask your host whether it placed a suspension that needs lifting and whether other sites on the server were affected.¹ If the hack sent spam, your server's IP may be on email blocklists, so check and request delisting.¹ If antivirus products still warn visitors, follow each vendor's removal process.¹¹ If customer data was in scope, get advice on your disclosure obligations.

For the next fortnight, run a daily scan and watch for new admin users, unexpected file changes, a jump in outbound email, and any return of the redirect or spam that first tipped you off. If the site comes back infected, the vector wasn't closed. Repeat the investigation instead of cleaning again, because a second clean without a better diagnosis is the same work done twice.

Finally, write the post-mortem, even if it is three sentences only you will read: how they got in, what you changed, and what was missing. In our experience, most hacked sites trace back to something dull and preventable, like a plugin two years out of date, a password reused on six other sites, or a backup that quietly stopped running months ago. The sites that don't get hacked again are the ones where someone owns the boring maintenance, whether that is you, your developer or a WordPress care plan.

Why does my WordPress site keep getting hacked?

When a WordPress site keeps getting hacked, the last clean missed something. These are the usual causes:

• A backdoor that survived. Attackers leave code that lets them back in after you delete the visible malware. Reinstalling through wp-admin can leave it in place, because those installers overwrite existing files and don't remove new ones.¹
• Salts that were never rotated. Without new secret keys, an attacker's existing session can stay alive. New keys force everyone to log in again.¹
• A rogue admin, FTP, SSH or database user. Sucuri states that a site cleaned while the malicious admin or FTP users remain "will quickly become reinfected."¹²
• The vulnerable plugin is still installed. Cleaning the malware doesn't patch the hole. If the plugin has no fix, remove it. Patchstack found 46% of 2025's WordPress vulnerabilities had no patch at disclosure, and heavily targeted flaws saw a weighted median of five hours to first exploit.¹³
• A compromised host, neighbor account or old install. Another infected site on the same server or hosting account, or a forgotten /old/ copy of your own site, can reinfect a clean install.²¹¹
• An infected backup. Restoring a backup taken after the breach puts the malware straight back. Use your logs to date the breach and pick a backup from before it.⁸
• An infected computer. If the FTP or wp-admin password was stolen from a laptop, new passwords typed on that laptop get stolen too.¹

If your site has been reinfected more than once, go back to phase two and assume more than one way in.

How to tell if your WordPress site is hacked

You don't need to be a developer to run these checks:

1. Search Google for site:yourdomain.com. Pages you don't recognize, such as ads for drugs, pornography or illegal services, point to a hack.⁹¹¹
2. Visit your site from a private window and from a search result. Many hacks hide from the site admin and show spam or redirects only to visitors and search crawlers.¹¹ A fake "Verify you are human" page is the ClickFix pattern.
3. Open the Security Issues report in Google Search Console. Google lists sample URLs it found hacked.³
4. Check Google's Safe Browsing status for your URL in Google's Safe Browsing site status tool.¹¹
5. Look at Users in wp-admin for administrators you didn't create.¹
6. Watch for outside warnings: your host suspending the site, browser warnings, visitors' antivirus blocking you, or spam complaints that mention your domain.¹¹¹

Spam text hidden in your header or footer is another sign, often styled so humans miss it while search engines read it.¹¹

How do I remove Google's "This site may be hacked" warning?

Google shows "This site may be hacked" in search results when it believes a hacker changed existing pages or added spam pages, and browsers can show a full warning page too.³⁵ The label stays until you fix the problem and ask for a review.³

1. Verify the site in Google Search Console if you haven't.³
2. Open the Security Issues report. It groups problems into hacked content, malware and unwanted software, and social engineering, with sample URLs.⁴
3. Finish the clean and close the vector first. Google requires that the hacker's content is gone, the vulnerability is fixed and the clean site is back online before you ask.⁵ Fix every listed issue on every page, including pages missing from the sample URLs, and make sure Googlebot can crawl the cleaned pages with no leftover noindex.⁴⁵
4. Select Request Review and describe the issue, what you fixed and the result. Google's sample wording names the spam you removed and the out-of-date plugin you updated.⁴⁵
5. Wait. Google says reviews of sites hacked with spam can take up to several weeks, malware reviews a few days, and phishing about a day. After a successful review, warnings come off within 72 hours.⁵

Don't ask early. Google warns that requesting a review before the issue is fixed can slow your next request or get the site marked as a repeat offender.⁴ If Google decides the site is still hacked, the report may show more sample URLs to point your next search.⁵ The Remove URLs tool can speed up removal of spam pages the attacker created, but use it only for pages you never want in search.⁷

Frequently asked questions

My WordPress site has been hacked. What do I do first?

Take the site offline behind a 503 holding page so visitors stop seeing the malicious content, then back up all files and the database before you delete anything. Change your hosting and SFTP passwords while the backup runs. Many hosts delete a site reported as hacked, so take the backup before you tell yours.

Can I fix a hacked WordPress site myself?

Yes, if you can use SFTP, read a scan report and spend several focused hours on it. WordPress.org, Wordfence and Google all publish free guides, and the main scanners have free versions. The hard part is finding how the attacker got in. If you can't, get help before the site is reinfected.

Why does my WordPress site keep getting hacked?

Something from the first clean survived: a backdoor file, a rogue admin or FTP user, unrotated secret keys, the vulnerable plugin, an old copy of the site, or a compromised server. Restoring a backup taken after the breach also brings the malware back. Find the vector before you clean again.

Should I restore a backup of my hacked WordPress site?

Only a backup from before the breach, and only after you know how the attacker got in. Use server logs and file change dates to date the breach. Restore it in place of the manual clean, update everything, close the vector, then rotate every password and the secret keys.

How long does WordPress hack recovery take?

The emergency work usually fits in a day: isolate in the first hour, investigate for a few hours, then clean and harden. Google's review can take a day for phishing, a few days for malware and up to several weeks for spam. Plan on two weeks of monitoring after that.

Will a hacked WordPress site hurt my Google rankings?

Google can label the site "This site may be hacked" in results and show browser warnings until you fix it and pass a review. Google says taking the site offline temporarily while you recover is unlikely to affect future rankings.

If you want help

This playbook works, and a calm operator with a few free hours can run it end to end. If the site is down now, or keeps getting reinfected, send us the URL and what you're seeing through /start. You'll get a scoped estimate within 48 hours.

Sources

Facts checked on October 7, 2026.